云监控

先理清你要解决什么问题

很多团队把监控做成了“指标大盘”，却依旧回答不了三个问题：用户是否受影响、问题该由谁处理、排查要花多久。该技能的目标不是堆图表，而是围绕可观测性三支柱——metrics、logs、traces——把服务行为变成可判定的工程问题。

它具体怎么工作

1. 先定义监控对象与目标：识别关键服务，定义 SLI（请求延迟、错误率、吞吐）和 SLO，再把对外承诺写成 SLA。
2. 按架构选择工具栈：指标可用 Prometheus、CloudWatch、Datadog；可视化用 Grafana 或厂商 Dashboard；日志聚合用 Loki、CloudWatch Logs、EFK、Splunk；链路追踪可用 Jaeger、AWS X-Ray、Tempo。
3. 采集与仪表盘配置：部署 scraper/exporter、自定义指标，并按服务层级组织 Dashboard，重点呈现 golden signals（延迟、流量、错误、饱和）以及 CPU/内存/磁盘/网络。
4. 告警按影响设计：不仅看原始阈值，而是围绕错误预算燃烧率、持续延迟和 Pod 重启等有意义条件触发，用多窗口 burn rate 平衡响应速度与误报抑制。
5. 日志与追踪打通：统一 JSON 结构化日志字段，并用 trace_id 关联请求链路与日志；告警可直接跳到对应 trace 与日志。
6. 持续审计与迭代：定期检查告警噪音、Dashboard 使用情况与 SLO 达成率，删除不可执行告警，按基线调整阈值，并把新服务纳入体系。

适用边界与注意点

• 适合云上单体到微服务体系；是否能落地取决于你能否统一 service/env/team/version 标签，以及是否已有 SLO 基线。
• 高基数标签（如 user_id、URL 原文）可能导致 Prometheus 内存压力，需要限制取值并用 recording rules 预聚合。
• 分布式追踪对主机时间敏感；若 NTP 不同步，可能出现乱序或负耗时。
• 故障时容易触发告警风暴，建议在 Alertmanager 配置分组与抑制规则。
• 滚动发布会造成抓取缺口，需使用容忍缺失的 rate() 并设置合理的 for 时长。
• CloudWatch 自定义指标过多时可能触发限流，应改用 GetMetricData 批量查询并缓存 Dashboard 数据。