监控先要有动作
监控的目标不是把指标堆进仪表盘，而是让异常能被发现、有人处置。每个库都有稳定的入口：延迟分位看用户体验，连接与排队看容量，复制延迟看数据一致性风险，缓存命中与磁盘水位看资源趋势。采集之前先约定阈值与处置动作，采集之后定期复核阈值是否还贴合业务。
指标与入口
| 类别 | 关注点 | 采集入口示例 |
|---|---|---|
| 延迟 | p95/p99 与慢操作数量 | MongoDB opLatencies；ES _nodes/stats；CH system.query_log |
| 容量与排队 | 连接数、队列、拒绝数 | ES _cat/thread_pool；MongoDB connections；Redis INFO clients |
| 复制 | 延迟秒数与中断 | MongoDB rs.status()；CH system.replication_queue |
| 缓存与内存 | 命中率、内存与碎片 | Redis INFO stats；WiredTiger 缓存指标 |
| 磁盘与合并 | 水位、合并积压 | CH system.parts；ES _cat/segments |
| 可用性 | 探活与错误率 | HTTP 探针、驱动错误计数 |
采集示例
采集示例
# MongoDB：复制集成员状态与连接数
mongosh --eval "rs.status().members.map(m => [m.name, m.stateStr]); db.serverStatus().connections"
# Elasticsearch：健康状态与线程池拒绝
curl -s "localhost:9200/_cluster/health?pretty"
curl -s "localhost:9200/_cat/thread_pool?v&h=node_name,name,active,queue,rejected"
# ClickHouse：表的磁盘占用
clickhouse-client -q "SELECT table, formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active GROUP BY table"采集怎么接进监控系统
常见做法是用对应的采集器把指标拉到 Prometheus 一类时序库，再由告警规则触发通知；也可以用应用层埋点直接上报。无论哪种方式，都要统一标签口径，让同一条指标能按实例、库、接口维度下钻，否则出问题时只能看总量。
典型使用场景
- 容量评估：按连接数与队列长度判断是否需要扩节点
- 故障复盘：用延迟分位与拒绝数还原问题时间线
- 复制告警：复制延迟超阈值时先确认网络还是写入压力
- 巡检报表：按周对比水位与增长趋势
- 告警调优：按历史基线复核阈值，减少噪声与静默
告警要分级：p99 超阈值与节点离线走不同通道；阈值先按历史基线加缓冲，再随容量变化定期复核，避免长期噪声或长期静默。
只采集不定义动作等于没监控：告警规则要与值班手册里的处置步骤一一对应，否则收到通知的人只能凭感觉处理。