Grafana构建监控大屏太难了

最近在做一个基于 Spring Integration 的数据采集系统，系统里面有各种各样的数据接入流程：结构化数据采集、文件采集、DICOM 拉取、一级路由、二级路由、业务处理通道等。

一开始我只是想做一件很简单的事情：

把系统运行状态和业务采集情况可视化出来。

比如：

• 应用是否在线；
• JVM 内存是否正常；
• 数据库连接池是否健康；
• 哪个通道发生了积压；
• 哪个 Spring Integration Flow 执行慢；
• 采集了多少患者信息、检查信息、报告信息；
• DICOM 拉取成功了多少次；
• DICOM 平均耗时是多少；
• 哪个业务分类数据量最大。

听起来不复杂，但真正打开 Grafana 的时候，第一感觉是：

这东西太难了。

---

难在哪里？

Grafana 本身很强大，但它并不会自动知道你想看什么。

它需要你先解决几个问题：

第一，系统有没有暴露指标？

第二，Prometheus 有没有采集到这些指标？

第三，每个指标叫什么名字？

第四，每个指标有哪些标签？

第五，这些指标应该用什么 PromQL 查询？

第六，不同指标应该用什么图表展示？

第七，怎么把这些图表组织成一个清晰的大屏？

对于刚接触的人来说，Grafana 页面上到处都是配置项：Panel、Query、Legend、Variable、Data source、Transformation、Threshold、Unit、Dashboard JSON......

看起来每一步都不难，但组合在一起，就很容易让人放弃。

---

正确的思路不是先画图，而是先整理指标

我这次的体会是：

构建 Grafana 大屏，最重要的不是拖控件，而是先理解指标体系。

我的系统是 Spring Boot 应用，使用 Micrometer 做指标埋点，通过 Actuator 暴露 Prometheus 格式指标。

所以完整链路是：

Spring Boot / Micrometer
        ↓
/actuator/prometheus
        ↓
Prometheus 定时采集
        ↓
Grafana 查询 Prometheus
        ↓
形成监控大屏

我先访问应用的指标接口：

http://localhost:8080/actuator/prometheus

看到里面已经有很多指标，例如：

collect_adapter_message_received_total
collect_route_message_total
collect_dicom_retrieve_success_total
collect_dicom_retrieve_duration_seconds
spring_integration_channel_queue_size
spring_integration_handler_seconds
jvm_memory_used_bytes
hikaricp_connections_active
http_server_requests_seconds_count
logback_events_total

这些指标一出现，事情就清楚了。

Grafana 不是凭空画大屏，而是把这些指标转换成可视化图表。

---

我把监控大屏分成了五类

为了让大屏不是"指标堆砌"，我把它拆成了五个区域。

一、系统健康总览

这一部分主要看系统是不是活着，资源有没有异常。

包括：

• 应用在线状态；
• 应用启动耗时；
• 进程运行时长；
• CPU 使用率；
• 磁盘使用率；
• WARN / ERROR 日志速率。

这一层回答的是：

系统还好吗？

---

二、JVM 与数据库连接池

Spring Boot 系统最常见的问题，很多都能从 JVM 和连接池看出来。

这一部分包括：

• JVM 堆内存使用量；
• JVM 堆内存使用率；
• JVM 线程数；
• GC 暂停耗时；
• HikariCP 活跃连接数；
• HikariCP 空闲连接数；
• HikariCP 等待连接数。

这一层回答的是：

应用运行资源是否健康？

---

三、HTTP 与接口访问

虽然这个系统主要是采集接入层，但只要是 Spring Boot 应用，HTTP 指标仍然很有价值。

这一部分包括：

• HTTP QPS；
• HTTP 5xx 错误速率；
• HTTP 平均耗时。

这里要注意，最好排除 /actuator.*，否则 Prometheus 定时访问 /actuator/prometheus 的请求也会被统计进去，导致监控数据被"监控本身"污染。

---

四、Spring Integration 流程与通道

这是这次大屏中最核心的部分。

因为我的系统是基于 Spring Integration 做流程编排的，业务数据会经过不同的 Channel、Router、Handler 和 Flow。

这一部分包括：

• 通道积压数量；
• 通道使用率；
• 消息接收速率；
• Handler 调用速率；
• Handler 平均耗时。

这几个指标非常关键。

例如 spring_integration_channel_queue_size 可以告诉我哪个 QueueChannel 中积压了消息。

如果某个通道的积压数量持续升高，说明后面的消费能力可能不足。

如果某个 Handler 平均耗时明显变高，说明这个处理节点可能出现性能瓶颈。

这一层回答的是：

流程有没有堵？堵在哪里？哪个节点慢？

---

五、业务采集监控

系统监控只能告诉我们"机器是否正常"，但业务监控才能告诉我们"系统是否真正完成了业务"。

所以我专门做了一组业务采集面板。

包括：

• 采集消息总量；
• 采集消息速率；
• 按业务分类统计采集量；
• 按数据类型统计采集量；
• 按适配器类型统计采集量；
• 按数据源统计采集速率；
• 一级 / 二级路由消息量；
• DICOM 拉取成功总数；
• DICOM 平均拉取耗时；
• DICOM 拉取成功速率；
• DICOM 任务通道积压。

这一层回答的是：

系统到底采了多少数据？哪个业务在采？哪个数据源在采？DICOM 拉取得是否正常？

---

真正让我震惊的是 Dashboard JSON

如果一个一个手工创建 Panel，确实很麻烦。

但是 Grafana 有一个非常强大的能力：

整个 Dashboard 可以用 JSON 描述。

也就是说，我们可以先把监控面板设计好，包括：

• Dashboard 标题；
• 数据源；
• 变量；
• Panel 布局；
• PromQL 查询；
• 图表类型；
• 单位；
• 阈值；
• 分组；
• 刷新频率。

然后直接导入 Grafana。

我把这些指标整理后，生成了一份 Dashboard JSON。

接下来只需要：

Dashboards → New → Import

上传 JSON 文件，选择 Prometheus 数据源。

几乎一瞬间，一个完整的监控大屏就出来了。

这也是我最震惊的地方：

Grafana 难的不是画图，而是把指标、查询和大屏结构想清楚。

一旦这些内容结构化了，Dashboard 本身完全可以快速生成。

---

我的构建流程

这次我总结出一套比较标准的流程。

第一步：应用暴露指标

Spring Boot 应用通过 Actuator 暴露：

/actuator/prometheus

第二步：Prometheus 采集指标

Prometheus 配置采集目标：

scrape_configs:
  - job_name: "spring-integration-app"
    metrics_path: "/actuator/prometheus"
    static_configs:
      - targets: ["host.docker.internal:8080"]

第三步：Grafana 接入 Prometheus

Grafana 数据源配置为：

http://prometheus:9090

因为 Grafana 和 Prometheus 在同一个 Docker Compose 网络里，所以 Grafana 访问 Prometheus 用服务名，而不是 localhost。

第四步：分析指标名称和标签

重点看：

指标名
标签名
标签值
指标类型
业务含义

例如：

collect_adapter_message_received_total

可以按这些标签拆分：

businessCategory
collectDataType
adapterType
sourceId
application
module

这就天然适合做业务分类、数据类型、适配器类型、数据源维度的大屏。

第五步：设计大屏结构

不要一上来就堆图表，而是先设计分组：

系统健康
JVM 与数据库
HTTP 访问
Spring Integration 流程
业务采集
DICOM 专项

第六步：生成 Dashboard JSON

把 Panel 和 PromQL 都写入 JSON。

导入之后，Grafana 自动生成完整大屏。

---

最终效果

导入之后，大屏可以直接看到：

• 应用是否在线；
• CPU、内存、磁盘是否正常；
• 数据库连接池是否健康；
• HTTP 请求是否异常；
• Spring Integration 通道是否积压；
• Handler 是否变慢；
• 采集消息是否持续增长；
• 不同业务分类的数据量；
• 不同数据类型的数据量；
• 不同 Adapter 的采集量；
• DICOM 拉取成功数和耗时。

这时候，系统不再是一个黑盒。

原来只能通过日志猜测系统状态，现在可以通过大屏直接观察。

---

我的感受

一开始我以为 Grafana 构建监控大屏很难。

后来发现，它确实难。

但难点不是 Grafana 本身，而是：

你是否知道自己要监控什么。

如果没有指标体系，再漂亮的大屏也只是装饰。

如果指标体系清楚，Grafana 反而会变得非常高效。

特别是对于 Spring Boot + Micrometer + Prometheus + Grafana 这一套技术栈，只要应用指标暴露规范，Prometheus 能正常采集，Grafana 就可以非常快地构建出漂亮、实用、可复用的大屏。

这次最大的收获是：

可观测不是最后加一个监控页面，而是把系统运行过程用指标表达出来。

当业务采集量、通道积压、Handler 耗时、DICOM 拉取耗时都能被看到时，系统的运行状态就从"感觉正常"变成了"数据证明正常"。

这才是监控大屏真正的价值。