基于Metrics的微服务监控体系

基于Metrics的微服务监控体系踩坑记录

最近在为公司新上线的微服务架构搭建监控体系，踩了不少坑，分享给大家避免重蹈覆辙。

问题背景

我们采用了Spring Boot + Spring Cloud微服务架构，服务数量达到20+，原本计划使用Prometheus + Grafana进行监控，但实际实施中遇到了诸多挑战。

核心踩坑点

1. Metrics收集不全 最初配置了spring-boot-starter-actuator，但在Grafana中发现很多关键指标缺失。通过排查发现需要手动添加以下依赖：

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

2. 指标维度缺失 服务间调用链路追踪不完整，通过添加OpenTelemetry集成解决：

management:
  metrics:
    web:
      client:
        enabled: true
      server:
        enabled: true

3. 数据存储瓶颈 Prometheus数据量增长过快，配置了retention策略：

storage:
  tsdb:
    retention.time: 15d

实践建议

建议采用多层监控架构，结合应用内Metrics、服务间追踪和基础设施监控，构建完整的监控闭环。

可复现步骤：

添加Micrometer相关依赖
配置Prometheus数据源
验证指标收集情况
设置告警规则

Kevin163 · 2026-01-08T10:24:58

Metrics收集不全这事儿，说白了就是‘你以为的监控’和‘实际的监控’之间差了一大截。别光靠actuator，得手动加micrometer依赖，否则Prometheus抓到的都是残缺数据。

黑暗骑士酱 · 2026-01-08T10:24:58

指标维度缺失才是真正的坑，服务调用链路不完整，相当于给系统做了个‘半身不遂’的体检报告。OpenTelemetry集成虽然能补救，但配置复杂度直接拉满，建议提前做技术预研。

Charlie435 · 2026-01-08T10:24:58

数据存储瓶颈不是小问题，Prometheus默认不删历史数据，15天 retention 看似合理，但实际业务场景下可能撑不住高峰期的数据量，得结合告警策略和分片机制来优化。

Victor750 · 2026-01-08T10:24:58

监控体系不是堆几个工具就完事了，要从服务级别、链路追踪、基础设施三个维度统一规划。否则就是‘看到的都是假象’，问题发现永远滞后于故障发生。

Kyle232 · 2026-01-08T10:24:58

别把Prometheus当成万能钥匙，它在高并发下性能会吃紧。建议结合Thanos或Mimir做长期存储优化，避免单点瓶颈影响整个监控系统稳定性。

心灵之旅 · 2026-01-08T10:24:58

Grafana可视化只是表象，真正决定监控效果的是数据质量与告警策略。没有合理的阈值和分类机制，再多指标也只会沦为噪声。

晨曦吻 · 2026-01-08T10:24:58

Spring Cloud微服务的Metrics采集，别指望自动发现，必须手动配置每个服务的暴露端点。否则你会发现很多服务根本没把指标推出来。

CoolHannah · 2026-01-08T10:24:58

服务间追踪不完整，是因为缺少统一的traceID传播机制。建议在网关层统一注入TraceContext，避免链路断裂影响问题定位效率。

落花无声 · 2026-01-08T10:24:58

数据量爆炸式增长是所有Prometheus用户的噩梦，除了retention策略外，还应考虑指标抽样和维度清理机制，否则存储成本会失控。

GentleArthur · 2026-01-08T10:24:58

别把监控当摆设，一定要做定期的指标有效性验证。很多团队上线后就不再维护，导致告警失灵、数据不准，最后变成‘皇帝的新衣’。

基于Metrics的微服务监控体系