RustPBX 操作手册
本章节面向日常运维/值班同学,聚焦“如何保持系统稳定运行”。如需了解功能原理,请参考《概览》《基础配置》《路由、Trunk 与计费》等章节。
1. 日常巡检
- 早班巡检:登录控制台首页查看节点健康、并发呼叫、失败率,如异常立即进入 Diagnostics。
- 日志核查:关注
callrecord、proxy、console三类日志;建议通过集中化日志平台设置关键字告警。 - 容量余量:记录上一日的峰值 CPS、并发数,与可承载上限对比,作为扩容依据。
- 告警处理:建立告警分级 SOP(P1/P2/P3),保证 5 分钟内响应。
2. 变更与发布流程
- 配置准备:在 Git 仓库(
config/、config.toml)创建分支,提交 MR/PR,并触发自动化语法校验。 - 灰度策略:
- 路由变更:先在低权重 DID 上验证;
- 分机/队列:利用测试账号演练;
- 计费模板:使用沙箱号段对比旧模板。
- 执行 Reload:严格按照《诊断工具》章节进行 Preflight 检查,再在控制台或 API 执行 Reload。
- 回滚:如出现异常,立即恢复上个 Git Tag,并重新 Reload;在 Diagnostics → Routing/Trunks 再次验证,直至测试结果与变更前一致。
3. 运行中常用操作
- 紧急封禁:通过
config/acl/或控制台快速封 IP/分机,防止恶意呼叫;操作完成后记得 Reload ACL。 - 限流/限额:借助频率限制或队列容量控制按需降载。
- 录音调取:在 Call Records 中按 call_id 搜索,导出录音与信令,满足合规或客户投诉调查。配置 S3 存储后,下载链接以 presigned URL 形式提供,大文件不再经由控制台中转。
- 优雅重启:
SIGTERM/SIGINT(或 AMIPOST /shutdown)会先排水进行中的通话再退出——滚动重启不会切断在线通话。集群环境下逐节点重启,由会话注册表自动接管流量。 - 批量任务:可使用自研脚本调用 API,批量重置分机密码、同步计费模板等。
4. 备份与合规
- 配置:将
config/与config.toml纳入 Git,搭配 CI 做格式与安全检查。 - 数据库:若使用 PostgreSQL,建议每日逻辑备份 + 每周全量快照;SQLite 部署需确保文件在可靠存储上。
- 录音/CDR:按法规保留 180/360 天,推荐同步到对象存储并建立生命周期策略。
- 审计:记录所有 Reload/变更操作,可在控制台或 Git commit 中追溯责任人。
5. 自动化与可观测性
- 健康探针:
GET /health(由handler::ami实现)监控数据库、SIP 线程和配置状态;接入负载均衡器或 Prometheus blackbox 导出器。 - Prometheus 指标:
GET /metrics导出实时计数器和直方图,涵盖 SIP 注册、活跃对话、Trunk 呼叫/失败/延迟、RTP 数据包统计、队列等待时间和系统资源使用(CPU、内存、FD)。配合 Grafana 仪表盘实现主动监控。 - 日志/Tracing:通过
log_level、log_file和log_rotation(hourly/daily/never)控制tracing输出;将访问日志和callrecord事件集中收集并配置告警条件。 - 商业版许可证校验:商业插件需要向
https://miuda.ai/api/verify验证许可证。许可证在本地缓存并在启动时验证。在控制台的 License 页面查看状态、过期时间和各插件有效性。 - 合成监控:通过
examples/perfcli.rs或第三方拨测工具定期发起呼叫,与 Diagnostics Evaluate 结果对比。 - 告警联动:将
/health、日志关键词和数据库指标接入 ChatOps/NOC 频道,自动分配 P1/P2 告警。 - API Token 认证:无需浏览器会话的 REST API 脚本化访问,可在
[console] api_tokens中配置 Bearer 令牌和基于 scope 的权限控制。详见基础配置 → API Token 认证。
6. 操作安全红线
- 禁止在生产环境直接修改编译后的二进制或数据库结构,所有变更必须通过 Git 交付。
- Reload 前必须有两人复核关键配置(Trunk、Routing、计费)。
- 非工作时段的重大变更需提前报备并预留回滚窗口。
遵循以上操作准则,可确保 RustPBX 在 7x24 的语音业务中保持稳定与可预测性。