Miuda.ai

RustPBX Operations Guide

This chapter targets on-call and operations engineers with a focus on “keeping the system healthy.” For feature fundamentals, see Overview, Basic Setup, and Routing/Trunks/Billing.

1. Daily checks

  • Morning patrol: review the console homepage for node health, concurrent calls, and failure rates; escalate to Diagnostics if anything drifts.
  • Log review: watch callrecord, proxy, and console logs; configure centralized log alerts for critical keywords.
  • Capacity headroom: capture peak CPS and concurrent calls from the previous day and compare against your limits to plan scale-out.
  • Alert workflow: keep a graded SOP (P1/P2/P3) with a five-minute response SLA.

Operations Dashboard

2. Change & release process

  1. Prepare configs: branch your Git repo (covering config/ and config.toml), submit MR/PR, and run automated linting.
  2. Canary policies:
    • Routing: validate on low-priority DIDs first.
    • Extensions/queues: exercise with test accounts.
    • Billing templates: compare against old templates using sandbox prefixes.
  3. Execute Reload: follow the Diagnostics chapter for preflight checks, then trigger Reload via console or API.
  4. Rollback: if issues appear, revert to the previous Git tag, reload again, and validate via Diagnostics → Routing/Trunks until parity is restored.

3. Common runtime actions

  • Emergency blocking: use config/acl/ or the console to block IPs/extensions; remember to reload ACL afterward.
  • Rate limiting: apply frequency limits or queue capacity caps to shed load.
  • Recording retrieval: search Call Records by call_id, export recordings/signaling for compliance or customer investigations.
  • Batch jobs: automate with in-house scripts that call APIs for password resets, billing template syncs, etc.

4. Backup & compliance

  • Configuration: store config/ and config.toml in Git with CI enforcing format/security checks.
  • Database: for PostgreSQL, run daily logical backups plus weekly full snapshots; for SQLite ensure the file sits on reliable storage.
  • Recordings/CDR: retain 180/360 days per regulation, preferably mirroring to object storage with lifecycle policies.
  • Audit trail: log every Reload/change so the console or Git commits identify the operator.

5. Automation & observability

  • Health probe: GET /health (implemented by handler::ami) monitors database, SIP threads, and config state; feed it into load balancers or Prometheus blackbox exporters.
  • Prometheus metrics: GET /metrics exports real-time counters and histograms for SIP registrations, active dialogs, trunk calls/failures/latency, RTP packet stats, queue wait times, and system resource usage (CPU, memory, FDs). Use with Grafana dashboards for proactive monitoring.
  • Logging/tracing: control tracing via log_level, log_file, and log_rotation (hourly/daily/never); centralize access logs and callrecord events with alert conditions wired to the NOC.
  • Commercial license verification: commercial addons require license validation against https://miuda.ai/api/verify. Licenses are cached locally and verified on startup. Check the console’s License page for status, expiry, and per-addon validity.
  • Synthetic monitoring: schedule calls via examples/perfcli.rs or third-party dial testing and compare with Diagnostics Evaluate output.
  • Alert routing: subscribe ChatOps/NOC channels to /health, log keywords, and DB metrics so P1/P2 alerts auto-assign.
  • API token auth: for scripted access to REST APIs without browser sessions, configure [console] api_tokens with Bearer tokens and scope-based authorization. See Basic Setup → API Token Authentication.

6. Operational guardrails

  • Never modify production binaries or database schema by hand—ship every change through Git.
  • Require dual reviews for trunk, routing, and billing changes before Reload.
  • Announce high-risk changes outside business hours and reserve a rollback window.
Operations

Following these rules keeps RustPBX predictable in a 24×7 voice environment.