请设计一个系统监控与告警系统，用于实时监控服务状态（如CPU、内存、QPS、错误率），并自动告警（如邮件、短信、钉钉），说明监控指标采集、告警规则、链路追踪的实现。
Tencent软件开发-后台开发方向难度：困难
答案
1) 【一句话结论】系统监控与告警系统需分层设计，包含指标采集层（收集服务状态数据）、规则引擎层（定义告警规则）、告警执行层（触发多渠道告警），通过结合实时指标、灵活规则与链路追踪，实现精准、及时的服务状态监控与告警。
2) 【原理/概念讲解】老师口吻，解释各部分：
- 指标采集：系统状态指标（CPU、内存）可通过Agent（如Prometheus的node_exporter）或自增自减计数器（如QPS）收集，类比“传感器”实时感知服务状态；
- 告警规则：基于阈值（如CPU > 80%）、时间窗口（如5分钟内错误率 > 5%）或组合条件（如CPU+内存同时告警），通过规则引擎（如Prometheus的Alertmanager规则）判断是否触发告警，类比“裁判”根据规则判断是否违规；
- 链路追踪：通过分布式追踪技术（如Jaeger/SkyWalking），在请求链路中注入Span，记录请求经过的服务节点、耗时、错误信息，定位问题根源，类比“GPS”定位问题发生的路径。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Prometheus（指标采集） | 开源监控系统，基于拉取模式收集指标 | 高扩展性、多数据源支持、强大的查询语言 | 大型分布式系统、云原生环境 | 需要维护Prometheus服务器，数据存储压力大 |
| 自研Agent（指标采集） | 自定义Agent收集指标，推送到监控中心 | 灵活性高、可定制化 | 小型系统、特定指标需求 | 开发成本高，维护复杂 |
| Alertmanager（告警规则） | Prometheus的告警管理组件 | 支持多渠道告警、告警抑制、静默规则 | 大型系统、多团队协作 | 需要配置告警抑制逻辑，避免重复告警 |
| 自定义规则引擎（告警规则） | 自定义逻辑判断告警 | 灵活性高、可扩展 | 特定业务场景 | 开发成本高，维护复杂 |
| Jaeger（链路追踪） | CNCF开源分布式追踪系统 | 支持多种语言、可视化界面、可扩展 | 云原生、微服务架构 | 需要部署追踪代理，增加系统开销 |
| SkyWalking（链路追踪） | 商业化分布式追踪系统 | 更强大的可视化、AI分析、可扩展 | 企业级、复杂系统 | 成本较高，但功能全面 |
4) 【示例】
- 指标采集：用Prometheus的node_exporter收集CPU、内存指标，QPS通过自定义计数器（如
http_requests_total{method="GET", service="api-service"}）统计； - 告警规则：定义规则文件（alertmanager的rule文件）：
groups: - name: system-monitoring rules: - alert: HighCpuUsage expr: cpu_usage > 80 for: 5m labels: severity: critical annotations: summary: "High CPU usage detected on {{ $labels.instance }}" description: "CPU usage is above 80% for 5 minutes." - alert: HighErrorRate expr: error_rate > 5 for: 5m labels: severity: warning annotations: summary: "High error rate detected on {{ $labels.instance }}" description: "Error rate is above 5% for 5 minutes." - 链路追踪：使用Jaeger，在服务中注入Span（如Spring Cloud的Tracing），当请求经过多个服务时，Span记录每个服务的耗时、错误信息，通过Jaeger UI查看请求链路。
5) 【面试口播版答案】
面试官您好，我来设计一个系统监控与告警系统。核心思路是分层设计，包含指标采集、规则引擎、告警执行三部分。首先指标采集，通过Prometheus的node_exporter收集CPU、内存等基础指标，QPS通过自定义计数器统计，类比传感器实时感知服务状态。然后告警规则，基于阈值（如CPU>80%）和时间窗口（5分钟内错误率>5%），用Prometheus的Alertmanager规则定义，像裁判根据规则判断是否违规。接着链路追踪，用Jaeger追踪请求链路，注入Span记录服务节点和耗时，定位问题根源，像GPS定位问题路径。最后告警执行，通过Alertmanager的多渠道（邮件、短信、钉钉）发送告警，结合告警抑制避免重复告警。这样就能实现精准、及时的服务状态监控与告警。
6) 【追问清单】
- 高并发场景下如何优化告警性能？<回答要点：使用告警抑制（Alertmanager的抑制规则）、分片处理（按服务实例分组）、异步处理（消息队列）。>
- 如何避免误报？<回答要点：设置合理的阈值、时间窗口，结合业务上下文（如非业务高峰期忽略告警）。>
- 链路追踪的采样率如何设置？<回答要点：根据系统流量和资源消耗，设置合理的采样率（如1%），平衡性能和精度。>
- 如何处理告警后的自动恢复？<回答要点：结合自动化运维工具（如Ansible、Kubernetes的自动扩容），实现告警后的自动处理。>
- 系统的可扩展性如何保障？<回答要点：指标采集采用分布式架构（如Prometheus的多实例），规则引擎支持动态加载，告警执行支持水平扩展。>
7) 【常见坑/雷区】
- 只讲指标采集，忽略告警规则和链路追踪，导致设计不完整；
- 链路追踪只提技术，没提业务场景，比如没说明如何结合业务逻辑定位问题；
- 忽略误报处理，比如没提告警抑制、阈值调整，导致告警泛滥；
- 架构设计太复杂，比如过度依赖自研组件，没考虑成熟方案；
- 没考虑可扩展性，比如指标采集只支持单节点，无法应对高并发场景。