告警太多？从开发转运维的Prometheus+Grafana监控“寻宝”清单
68
0
0
0
你好，从开发转运维，面对Prometheus和Grafana的监控海洋确实容易感到无所适从，这是一种非常普遍的经历。你提出“如何从海量数据里找到真正重要的‘信号’”以及“如何判断告警是误报还是真问题”，这恰恰是运维工作中至关重要也最具挑战性的部分。别担心，很多经验丰富的运维工程师也是从这个阶段走过来的。
我们可以建立一套“核心服务监控指标筛选与告警Triage清单”，帮你系统性地梳理思路，快速定位关键信息。这不仅仅是一份清单，更是一种思考和处理问题的方法论。
第一步：理解核心服务监控的“思维模型”
在跳入具体指标之前，我们需要明确监控的目的：确保业务的稳定性和用户体验。不是监控越多越好，而是要监控那些能直接反映业务健康状况和用户体验的指标。
两个核心概念将指导我们：
“黄金信号”法则 (Four Golden Signals)：尤其适用于面向服务的应用。
- 请求率 (Rate)：服务每秒处理的请求数。反映服务繁忙程度。
- 错误率 (Errors)：服务返回错误（如HTTP 5xx）的请求比例。直接反映服务质量。
- 延迟 (Duration/Latency)：服务处理一个请求所需的时间。影响用户体验的关键指标。
- 饱和度 (Saturation)：服务资源（CPU、内存、网络、磁盘）的利用率或瓶颈程度。预警潜在性能问题。
“USE 方法” (Utilization, Saturation, Errors)：主要用于监控基础资源（如服务器、数据库等）。
- 利用率 (Utilization)：资源繁忙的时间百分比（如CPU利用率、磁盘IOPS利用率）。
- 饱和度 (Saturation)：资源达到容量限制的程度，等待队列的长度（如CPU负载、内存交换区使用量、网络队列）。
- 错误 (Errors)：资源处理过程中出现的错误（如网络丢包、磁盘I/O错误）。
这两种方法互补，帮助我们从应用层面和基础设施层面全面地理解服务状态。
第二步：核心服务监控指标筛选与告警Triage清单
现在，我们把理论落地到你的Prometheus + Grafana实践中。
清单A：核心服务与业务关键流识别
这是所有监控工作的基础。
- A1. 识别你的“核心服务”：
- 哪些服务停机或性能下降会直接导致公司营收损失或用户大规模投诉？（例如：用户登录服务、支付服务、商品交易服务、核心数据查询服务）
- 这些服务之间有何依赖关系？（上游、下游）
- A2. 描绘“业务关键路径”：
- 用户完成一个核心业务操作（如“下单并支付”）需要经过哪些服务？（例如：前端 -> 网关 -> 用户服务 -> 商品服务 -> 订单服务 -> 支付服务 -> 消息队列 -> 仓储服务）
- 明确这些路径上的关键步骤及其健康状态。
清单B：基于“黄金信号”的Prometheus指标筛选
针对你识别出的核心服务，优先关注以下类型的Prometheus指标。
B1. 应用/服务层（关注请求与响应）
| 指标类型 | 描述 | 常见Prometheus指标/表达式示例 | 告警关注点 |
|---|---|---|---|
| 请求率 (Rate) | 服务每秒处理的请求数 | rate(http_requests_total[5m]) 或 sum(rate(grpc_requests_total[5m])) by (service) |
短时内请求骤降/骤升（可能服务异常或流量突增） |
| 错误率 (Errors) | 错误响应（如5xx）占总请求的比例 | `sum(rate(http_requests_total{code=~"5.. | 404"}[5m])) / sum(rate(http_requests_total[5m]))` |
| 延迟 (Latency) | 请求处理时间（中位数、90线、99线） | histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, path)) |
90线/99线延迟升高，影响用户体验 |
| 服务实例健康 | 服务实例是否正常运行 | up{job="my-service"} == 0 (监控服务实例是否宕机) |
任何实例宕机都应告警 |
| 特定业务指标 | （可选）与业务强相关的成功率、失败率 | rate(payment_success_total[5m]) / rate(payment_request_total[5m]) |
业务成功率骤降 |
B2. 资源层（关注服务器、数据库、消息队列等）
| 资源类型 | 指标类型 | 描述 | 常见Prometheus指标/表达式示例 | 告警关注点 |
|---|---|---|---|---|
| 服务器 (Node) | CPU利用率 | CPU使用情况 | 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) |
持续高利用率 (>80-90%) |
| CPU饱和度 | CPU运行队列长度 | node_load5 (5分钟平均负载) |
负载值过高，且持续不下降 | |
| 内存利用率 | 内存使用情况 | node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes / node_memory_MemTotal_bytes * 100 |
内存占用过高，可能导致OOM或频繁SWAP | |
| 磁盘I/O | 磁盘读写、I/O等待时间、使用率 | rate(node_disk_read_bytes_total[5m]) node_disk_io_time_seconds_total |
磁盘I/O高，且等待时间长 | |
| 网络流量 | 网卡进出流量、错误包、丢包 | rate(node_network_receive_bytes_total[5m]) rate(node_network_errs_total[5m]) |
流量异常、丢包率升高 | |
| 数据库 | 连接数 | 当前活跃连接数 | mysql_global_status_threads_connected (MySQL) |
连接数接近最大值，可能阻塞 |
| QPS/TPS | 每秒查询/事务数 | rate(mysql_global_status_queries_total[5m]) |
QPS/TPS异常（骤降/骤升） | |
| 慢查询 | 慢查询数量 | mysql_global_status_slow_queries_total |
慢查询数量持续增加 | |
| 锁 | 锁等待情况 | mysql_global_status_innodb_row_lock_waits |
锁等待数量增加，影响并发 | |
| 消息队列 | 堆积量 | 未消费消息数量 | rabbitmq_queue_messages (RabbitMQ) 或 Kafka Consumer Group Lag 指标 |
消息堆积持续上涨，消费延迟 |
| 消费延迟 | 消息从生产到消费的时间 | （需定制化指标） | 消费延迟过高 |
清单C：告警配置与Triage流程优化
有了关键指标，下一步是有效地利用它们来发出有意义的告警并快速响应。
C1. 告警配置优化
- C1.1 设置合理的阈值：
- 基于历史数据：分析指标的日常波动范围。
- 基于业务SLA/SLO：你的服务承诺的可用性、性能指标是什么？例如，99%的请求延迟不能超过200ms。
- 动态阈值/多级告警：例如，延迟超过200ms持续1分钟发“警告”，超过500ms持续30秒发“严重”告警。
- C1.2 配置告警抑制与分组：
- 抑制 (Silence)：当已知某个服务或机器正在维护时，暂时禁用相关告警，避免“告警风暴”。
- 分组 (Grouping)：将相似的、可能由同一根源问题引发的多个告警聚合为一个通知，避免被大量重复告警淹没。例如，多个服务实例同时出现CPU高，可能是一个集群问题。
- C1.3 定义告警升级路径：
- 谁（On-call人员）会在什么时间收到哪些告警？
- 告警的优先级（P0/P1/P2...）如何定义？
- 接收方式（电话、短信、邮件、企业IM）。
C2. 告警Triage（分诊）流程
当你收到一个告警时，不要慌张。按照以下步骤快速定位问题：
- T2.1 确认告警的“上下文”：
- 告警的服务是什么？（是核心服务吗？）
- 告警的指标是什么？（是黄金信号吗？）
- 告警级别？（警告、严重？）
- 持续了多久？
- T2.2 快速确认“影响范围”：
- 最重要的问题：用户是否受到影响？有多少用户受影响？
- 业务方是否已经发现问题并反馈？
- 通过Grafana面板，查看告警指标附近的关联指标，如请求率、错误率、下游依赖服务的状态，判断影响是局部的还是全局的。
- T2.3 核心指标快速排查：
- 如果是应用服务告警：首先检查该服务的“黄金信号”（请求率、错误率、延迟）。它们有异常吗？
- 如果是资源告警：检查该资源的“USE方法”指标（利用率、饱和度、错误）。
- 通过Grafana的Dashboard，快速切换到与该服务/资源相关的几个核心面板，一目了然。
- T2.4 深入日志与追踪（如果指标不足以说明问题）：
- 当监控指标给出“发生了什么”的线索后，日志可以告诉你“为什么会发生”。
- 使用日志系统（如ELK Stack, Loki）查看告警时间点前后服务的详细日志，寻找异常堆栈、错误信息。
- 如果公司有链路追踪系统（如Jaeger, Zipkin），查看受影响请求的完整链路，定位是哪个服务或哪个内部调用出现了问题。
- T2.5 判断误报或真实问题：
- 如果发现指标恢复正常，且没有对业务造成实际影响，可能是瞬时抖动或误报。记录下来，并思考是否需要调整告警阈值或规则。
- 如果确认是真实问题，立即启动应急响应流程，并知会相关团队。
清单D：持续优化与复盘
监控和告警系统不是一劳永逸的，需要持续的迭代优化。
- D1. 定期复盘告警：每周/每月回顾收到的所有告警。
- 哪些是误报？为什么？如何优化？
- 哪些告警很有用，帮助我们及时发现了问题？
- 有没有漏掉重要的告警？
- D2. 更新监控面板和告警规则：
- 根据业务发展和系统架构变化，及时调整监控项。
- 将从故障中学习到的经验反映到监控和告警规则中。
- D3. 故障演练：定期进行故障演练，测试告警系统的有效性和团队的响应能力。
从现在开始，你可以尝试根据这份清单，从你负责的核心服务入手，一步步梳理和优化你的监控体系。记住，这是一个持续学习和改进的过程。随着你经验的增长，你会越来越驾轻就熟地在监控数据中找到那些真正的“信号”。祝你顺利！