如何做监控和告警

如何做监控和告警

1️⃣ 考察意图

面试官想看的不是你会用Prometheus配个CPU告警，而是你能否从系统设计和SRE工程视角，构建一个可观测性体系。考察类型：系统设计 + 工程取舍。刁钻点在于：① 指标选取是否覆盖“黄金信号”+业务信号（如RAG的检索召回率）；② 告警规则是否避免“告警风暴”（如动态阈值 vs 静态阈值）；③ 是否有告警完整流程（自动诊断+工单联动）。答好了能展示你从“写代码”到“运维大规模系统”的硬实力。

2️⃣ 标准答

监控告警不是堆工具，而是分层设计。我按“指标采集 → 可视化 → 告警规则 → 分级通知 → 完整流程诊断”五层展开。

1. 指标采集：黄金信号 + 业务信号

• 黄金信号（Google SRE书）：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
• 延迟：P50/P95/P99请求耗时，用Prometheus Histogram采集，bucket分桶（如100ms, 500ms, 1s）。
• 流量：QPS/RPS，按接口维度打标签（如/search, /generate）。
• 错误：HTTP 5xx、业务错误码（如检索超时、生成空结果），用Counter累加。
• 饱和度：CPU/内存/磁盘IO/连接池使用率，重点看数据库连接数和GPU显存（RAG场景）。
• 业务信号（RAG特有）：检索召回率（Top-5命中率）、生成质量（用户反馈评分）、端到端延迟分解（检索耗时 vs 生成耗时）。这些需要埋点上报到Prometheus或自定义Exporter。

2. 工具链选型与取舍

• Prometheus：拉模式，适合指标采集；但不支持长期存储（默认15天），需搭配Thanos或VictoriaMetrics做持久化。
• Grafana：可视化，支持告警规则配置（Grafana Alerting v8+），但告警规则管理不如Prometheus原生Alertmanager灵活（如静默、分组）。
• ELK：日志聚合，用于排查错误根因；链路追踪用Jaeger或OpenTelemetry，定位慢调用（如RAG中检索服务慢）。
• 取舍点：Prometheus拉模式 vs 推模式（如InfluxDB）。拉模式更可靠（避免客户端故障导致数据丢失），但需保证服务端可达；推模式适合边缘设备。我选拉模式+Thanos做跨集群聚合。

3. 告警规则设计：动态阈值 + 多维度

• 静态阈值：P99延迟 > 500ms 持续5分钟 → P1告警。但静态阈值容易误报（如促销流量突增）。改用动态基线：基于过去7天同时间窗口的P99值，用3σ或移动平均计算阈值（Prometheus predict_linear 函数）。
• 多维度规则：按服务、地域、用户等级分。例如：核心服务（检索）P99 > 1s 持续1分钟 → P0；非核心（日志分析）P99 > 2s 持续5分钟 → P2。
• 实际坑：告警风暴。解法：告警分组（Alertmanager group_by 按alertname+instance分组，5分钟内相同告警只发一次）；告警抑制（如果上游服务挂了，抑制下游所有告警）。

4. 告警分级与通知

• P0（核心功能不可用，如检索服务宕机）：电话+短信，5分钟内响应。自动触发诊断脚本（dump线程栈、抓取慢查询日志）。
• P1（性能下降，如P99延迟 > 1s）：邮件+钉钉/飞书，15分钟内响应。自动拉起扩容（K8s HPA）。
• P2（非关键，如磁盘使用率 > 80%）：记录到工单系统，次日处理。
• 通知去重：Alertmanager repeat_interval 设为1小时，避免重复轰炸。

5. 告警完整流程：自动诊断 + 工单联动

• 告警触发时，Webhook调用诊断脚本（如curl localhost:8080/dump），收集线程栈、数据库连接状态、慢查询日志，存入S3。
• 自动创建Jira工单，附上诊断报告和Grafana Dashboard链接。SRE只需确认或升级。
• 取舍点：自动诊断增加系统开销（如dump线程会暂停JVM），所以只对P0/P1告警启用，且限制频率（每小时最多1次）。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从指标采集、告警规则、完整流程诊断三个层面回答。指标层：用Prometheus采集黄金信号（延迟、错误、饱和度）加业务信号（检索召回率），搭配Thanos做长期存储。告警层：用动态基线代替静态阈值，通过Alertmanager分组抑制避免风暴。完整流程层：告警触发后自动执行诊断脚本并关联工单。总结一句：监控告警的核心不是工具，而是从‘发现问题’到‘自动恢复’的完整流程设计。”

4️⃣ 高频追问 & 应对

追问 1：如果告警规则误报率很高，你怎么优化？

误报通常来自静态阈值或业务波动。解法：① 改用动态基线，用Prometheus predict_linear 预测未来趋势，或引入机器学习（如Facebook Prophet）做异常检测。② 增加告警确认：告警触发后先发一条“疑似告警”到低优先级通道，如果5分钟内未自动恢复再升级。③ 对历史告警做事后分析：统计误报率，调整规则参数（如延长持续时间、放宽阈值）。例如，某接口P99延迟偶尔突增到600ms但很快恢复，就把持续时间从1分钟改为3分钟。

追问 2：你的监控系统如何应对大规模集群（1000+节点）？

核心瓶颈在Prometheus单机性能（单机约100万时间序列）。解法：① 分片采集：按服务或地域拆成多个Prometheus实例，用Thanos或Cortex做全局聚合查询。② 降采样：原始数据保留7天，降采样后保留30天（如1分钟粒度→5分钟粒度）。③ 标签优化：避免高基数标签（如user_id），改用tenant_id聚合。④ 告警规则下推：在边缘Prometheus实例上执行告警计算，只把结果上报到中心，减少网络传输。

追问 3：RAG场景下，如何监控“检索质量”这个业务指标？

检索质量不能直接通过系统指标反映，需要业务埋点。方案：① 在检索服务中记录Top-5召回命中率（用户点击的文档是否在召回结果中），上报为Prometheus Gauge。② 对生成结果做离线评估：用BLEU/Rouge或LLM-as-Judge打分，写入时序数据库。③ 设置告警规则：如果召回命中率连续1小时低于80%，触发P1告警，自动触发索引重建或向量库健康检查。④ 注意：业务指标有延迟（用户反馈需时间），所以告警阈值要放宽（如持续30分钟而非5分钟）。

5️⃣ 避坑 · 常见错误答法

• ❌ 只堆工具名：“我用Prometheus+Grafana+ELK+Jaeger” → ✅ 讲清楚每个工具解决什么问题、有什么取舍（如Prometheus拉模式 vs 推模式，Thanos vs VictoriaMetrics）。
• ❌ 告警规则只写静态阈值：“P99延迟超过500ms告警” → ✅ 提到动态基线、分组抑制、告警风暴预防，并给出具体参数（如group_by: ['alertname']）。
• ❌ 忽略业务指标：“只监控CPU和内存” → ✅ 针对RAG场景加入检索召回率、生成质量等业务信号，并说明如何埋点。

6️⃣ 简历呼应

• 如果你有RAG项目：从“检索延迟和召回率监控”切入，讲如何用Prometheus采集业务指标，并配置动态告警规则（如召回率<80%持续30分钟告警）。强调你踩过的坑：告警风暴（分组抑制）和误报（动态基线）。
• 如果你只做过传统后端：用“微服务监控”类比，讲如何将黄金信号应用到RAG系统。强调工具链选型（Prometheus+Thanos）和告警分级（P0/P1/P2），展示你从单体到分布式系统的迁移能力。
• 如果你是校招无项目：聚焦SRE经典论文（Google《Site Reliability Engineering》），讲黄金信号和告警完整流程设计。可以提一个demo：用Prometheus+Grafana监控本地RAG demo的延迟和错误率，并配置飞书告警。
• Google SRE Book: "Monitoring Distributed Systems" (Chapter 6)
• Prometheus官方文档: "Alerting Rules" 和 "Recording Rules"
• Thanos: "Global Query View" 和 "Downsampling" 设计
• 论文: "Anomaly Detection in Production Systems" (Netflix, 2020)
• 博客: "How to Avoid Alert Fatigue" (PagerDuty Engineering Blog)