Prometheus+Grafana监控体系：这5个Dashboard必配

在现代微服务架构与云原生环境中，Prometheus + Grafana 已成为事实上的监控标配组合。Prometheus 负责高效采集与存储时序数据，Grafana 提供灵活的可视化能力。很多团队部署了这套体系，却仍然陷入“图表太多、价值太低”的困境：仪表盘冗杂、不知重点何在、报警噪声大。

作为经历过多次Prometheus+Grafana监控体系落地与重构的技术负责人，我发现高质量的Dashboard不是“越多越好”，而是“恰到好处”。本文将分享在实践中总结出的 “五个必配Dashboard” ，帮助你快速构建一套既简洁又高效的监控体系，从“看热闹”到“看门道”。

---

一、为什么Prometheus+Grafana成为“黄金组合”

在选择监控方案时，许多团队都做过横向对比：Zabbix、Nagios、Datadog、SkyWalking……最终仍回到Prometheus+Grafana。其原因有三：

1. 生态成熟：Prometheus具备强大的Exporter生态，覆盖数据库、消息队列、容器、K8s等各种组件。
2. 灵活查询：PromQL强大灵活，可支持多维度聚合分析。
3. 可视化丰富：Grafana支持多数据源、多种图表，且扩展性强。

但也正因为“能力强”，很多团队在落地时容易掉入“面板膨胀”陷阱：一个系统几十个Dashboard，关键问题反而不易发现。

---

二、五个必配Dashboard全景

1. 基础资源监控Dashboard（CPU/内存/磁盘/网络）

这是所有监控体系的底盘。没有基础资源的稳定，所有应用指标都无从谈起。

• 关键指标：CPU使用率、Load Average、内存占用率、磁盘I/O、磁盘空间、网络带宽。

• 最佳实践：

  • 按服务/节点分组展示，支持快速筛选。
  • 设置动态阈值或百分位（如95%）而非固定值。
  • 结合告警：如磁盘使用率>80%触发预警，>90%触发致命告警。

该Dashboard可作为“首站”，一旦业务异常，先看基础资源是否健康。

2. 应用性能监控Dashboard（延迟/吞吐/错误率）

在微服务场景下，应用性能指标比资源指标更能反映用户体验。我们通常采用 RED模型（Rate, Errors, Duration）：

• Rate（吞吐量）：每秒请求数（RPS）、消息消费速率等。
• Errors（错误率）：HTTP 5xx/4xx比例、异常抛出次数。
• Duration（延迟）：请求平均延迟、P95/P99延迟。

最佳实践：

• 按服务、接口、版本分组。
• 把业务关键路径（如支付、下单）的延迟和错误率放在最显眼的位置。
• 利用Grafana的Annotations标记发布事件，方便关联问题。

这样可以快速回答：“是CPU高了导致慢，还是代码bug导致错误率飙升？”

3. 数据库/缓存监控Dashboard

数据库和缓存是系统的“心脏”，一旦出问题影响范围极广。Prometheus有成熟的Exporter（如MySQL Exporter、Postgres Exporter、Redis Exporter）可直接用。

• 数据库关键指标：

  • QPS/Transactions per Second
  • 慢查询数、锁等待时间
  • 连接数/连接池使用率
  • Buffer/Cache命中率

• 缓存关键指标：

  • 命中率、过期率
  • 内存使用率
  • 主从延迟

最佳实践：

• 按实例/集群聚合展示。
• 对慢查询和锁等待设置告警并链接到SQL分析工具。
• 标记主从延迟，防止读到旧数据。

4. 容器/Kubernetes集群监控Dashboard

在K8s环境下，单纯看节点CPU内存已无法反映Pod状态。这里推荐两个维度：

• 集群维度：

  • 节点数、Pod数、DaemonSet/Deployment状态
  • 资源请求/限制与实际使用对比（Capacity vs Requests vs Limits）

• Pod维度：

  • Pod重启次数、Pending状态持续时间
  • 容器CPU/内存用量、OOM事件

最佳实践：

• 使用kube-state-metrics+node-exporter采集。
• 将关键命名空间单独展示，支持下钻到Pod。
• 在Grafana设置Link到K8s Dashboard或日志系统，快速跳转。

5. 业务健康&SLA Dashboard（从技术到业务的桥梁）

前四个Dashboard偏技术，最后这个Dashboard是面向业务/管理层的“汇报面板”。

• 业务关键指标：

  • 成功率、交易量、支付转化率
  • 关键