监控是生产环境里不可缺少的一环。当接口突然变慢、内存持续上涨或者某个服务节点失联时，如果没有一套可视化的监控体系，运维人员只能登录服务器翻日志，定位问题的效率会非常低。Prometheus 负责采集和存储指标数据，Grafana 负责把这些数据变成直观的图表，两者组合起来几乎是 Java 应用监控的事实标准。Spring Boot 从 2.x 开始内置了 Micrometer 库，只要少量配置就能把应用内部的运行指标暴露出来，整个搭建过程并不复杂。
一、Spring Boot 暴露监控指标的原理与配置
Micrometer 是 Spring Boot 官方推荐的度量门面库，作用类似于日志领域的 SLF4J。它在上层提供统一的 API，底层可以对接 Prometheus、InfluxDB、Datadog 等多种监控系统。当我们在项目中引入 micrometer-registry-prometheus 依赖后，Spring Boot 会自动配置一个 PrometheusMeterRegistry，把所有注册到 Micrometer 的指标转换为 Prometheus 认识的文本格式，并通过 Actuator 的 /actuator/prometheus 端点对外输出。
先在 pom.xml 中添加必要的依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId;gt;micrometer-registry-prometheus</artifactId>
</dependency>接着在 application.yml 中放开对应端点：
management:
endpoints:
web:
exposure:
include: health,info,prometheus
metrics:
tags:
application: ${spring.application.name}这里的 metrics.tags.application 配置很关键，它会给每一条指标打上应用名标签。当后续有多个服务同时被 Prometheus 抓取时，这个标签就是区分不同应用数据的唯一标识，漏配的话所有服务的曲线会混在一起。启动应用后访问 http://127.0.0.1:8080/actuator/prometheus，能看到类似 jvm_memory_used_bytes、http_server_requests_seconds_count 这样的指标文本，说明数据已经成功暴露。
二、配置 Prometheus 定时抓取与 Grafana 数据源接入
Prometheus 采用拉取模式获取数据，也就是它主动定期访问应用的指标端点，而不是应用推送数据过来。这种模式的好处是应用侧无需关心监控系统是否在线，即使 Prometheus 短暂宕机，应用也完全不受影响。下面是一份常见的 prometheus.yml 配置：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'springboot-app'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['192.168.0.10:8080', '192.168.0.11:8080']
labels:
env: 'prod'scrape_interval 决定了数据的采样粒度，15 秒是监控实时性和存储压力之间的平衡点。如果需要对某些关键接口做秒级监控，可以单独为某个 job 设置更小的间隔。启动 Prometheus 容器后，访问其自带的状态页面，在 Targets 菜单里确认目标状态为 UP，即表示抓取正常。
接下来安装 Grafana。用 Docker 一行命令即可启动，默认端口 3000，首次登录使用 admin/admin。登录后进入 Configuration 中的 Data Sources，选择 Prometheus 类型，地址填写 http://127.0.0.1:9090。如果 Grafana 也跑在 Docker 里，注意不要写 localhost，应该写容器网络中 Prometheus 的服务名，比如 http://prometheus:9090，这是新手最容易踩的坑。数据源保存后点击 Save and Test，出现绿色提示即表示连通成功。
三、导入官方仪表盘并配置告警
自己从零画仪表盘比较费时间，Grafana 社区有大量现成模板可以直接复用。进入 Dashboards 的 Import 页面，输入模板编号 4701（JVM 专用的 Micrometer 仪表盘），选择刚才创建的数据源，几秒钟就能得到一份包含堆内存、GC 次数、线程状况的完整面板。如果需要观察 HTTP 层面的数据，编号 11378 的模板也很流行，覆盖了请求 QPS、错误率、响应时间分位数等维度。
导入之后建议针对模板做两点定制：一是把顶部变量切换为 application 标签，方便按服务名筛选；二是把时间范围调整为最近 1 小时，更符合日常巡检习惯。仪表盘能看趋势，但盯屏幕毕竟不能代替告警。Prometheus 的 Alertmanager 组件可以把规则命中的告警推送到邮件、钉钉或企业微信，规则示例如下：
groups:
- name: springboot-alerts
rules:
- alert: HighErrorRate
expr: sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) by (application)
/ sum(rate(http_server_requests_seconds_count[5m])) by (application) > 0.05
for: 3m
labels:
severity: warning
annotations:
summary: "应用 {{ $labels.application }} 5xx 错误率超过 5%"这条规则的含义是：任意应用在过去 5 分钟内 5xx 响应占比超过 5%，且持续 3 分钟，就触发告警。rate 函数把累计计数器换算成每秒增速，for 字段过滤掉瞬时抖动，这两个细节是编写告警规则时必须理解的核心概念。
四、自定义业务指标与常见问题
系统指标只能告诉你机器层面的状况，业务层面的异常还得靠自己埋点。借助 Micrometer 提供的 Counter 和 Gauge，几行代码就能把订单量、支付成功率等业务数据纳入监控：
@Service
public class OrderMetricsService {
private final Counter orderCounter;
private final AtomicInteger pendingOrders = new AtomicInteger(0);
public OrderMetricsService(MeterRegistry registry) {
this.orderCounter = Counter.builder("business.order.created")
.description("下单总次数")
.tag("channel", "app")
.register(registry);
Gauge.builder("business.order.pending", pendingOrders, AtomicLong::doubleValue)
.description("待处理订单数")
.register(registry);
}
public void recordOrder() {
orderCounter.increment();
}
public void updatePending(int count) {
pendingOrders.set(count);
}
}自定义指标命名建议统一加业务前缀，比如 business. 或公司约定的命名空间，避免与系统指标混淆。Counter 只增不减，适合统计累计发生量；Gauge 反映瞬时值，适合展示队列长度、在线人数这类状态数据。类型选错会导致曲线看起来很奇怪，比如把瞬时值误用 Counter 就会出现只涨不跌的诡异图形。
实践中有几个高频问题值得注意。第一，指标端点泄露敏感信息，生产环境务必通过 Spring Security 对 /actuator/** 做鉴权，或者只在内网暴露。第二，标签基数失控，如果把用户 ID 当作标签值，Prometheus 的时间序列数量会爆炸式增长，最终拖垮存储，标签只能使用有限枚举值。第三，Grafana 面板无数据，多数原因是数据源地址写错或者抓取目标处于 DOWN 状态，优先排查这两处即可。把这几个点处理好，一套稳定的应用监控体系就基本成型了。
GrafanaPrometheusSpring Boot监控修改时间：2026-09-13 20:32:50