Linux第24篇：Java应用监控体系搭建：Prometheus+Grafana可视化运维

做个文艺程序员2026-07-22 16:13

一句话定义：本文系统讲解如何使用Prometheus + Grafana构建Java SaaS应用的全方位监控体系------从Spring Boot应用通过Micrometer暴露指标，到Prometheus采集存储，再到Grafana可视化展示与告警配置，实现从"被动救火"到"主动预防"的运维转型。

一、引言：从"盲人摸象"到"全息透视"

经过第19篇的性能调优，你已经掌握了在系统变慢时如何定位瓶颈。但有一个更关键的问题摆在你面前------你怎么知道系统什么时候会变慢？

在真实的运维场景中，最怕的不是"系统出故障了怎么办"，而是 "系统出故障了，你是最后一个知道的" 。用户投诉上门了、老板来问了，你才匆匆登录服务器去看日志------这是典型的 "被动救火"模式。

监控体系的价值，就是把"被动救火"变成"主动预防"。

在Java SaaS部署的全链路中（第13篇JDK → 第14篇应用部署 → 第15篇Nginx → 第16篇数据库 → 第17篇Redis → 第18篇Docker → 第19篇性能调优 → 本篇监控体系 ），监控是从"运维"走向"可观测性"的关键一步。有了监控，你才能：

  • 实时感知：JVM内存使用率、GC频率、接口响应时间------一切尽在掌握
  • 提前预警：内存使用率超过85%时收到告警，在OOM发生前介入
  • 快速定位：故障发生时，通过监控数据快速判断问题维度
  • 容量规划：基于历史趋势数据，预判什么时候该扩容

二、监控体系架构：四层模型

为什么这样写：在动手部署之前，先搞清楚整个监控体系的架构------知道每一层是干什么的，后面配置的时候才不会晕。

一个完整的Java监控体系包含四个层次：

层级 功能 本文选型
采集层 从Java应用中获取指标数据 Micrometer（Spring Boot）/ JMX Exporter（传统Java）
传输层 将指标数据传递给存储系统 Prometheus Pull模型（HTTP拉取）
存储层 持久化时间序列数据 Prometheus TSDB
展示层 可视化展示与告警 Grafana + Alertmanager

核心工作流程：

bash 复制代码 
Java应用（暴露 /actuator/prometheus 或 JMX Exporter端口）
        ↓ （Prometheus定期拉取）
Prometheus（存储时间序列数据）
        ↓ （Grafana查询展示）
Grafana（仪表盘可视化 + 告警规则）
        ↓ （触发告警）
Alertmanager（发送邮件/钉钉/企业微信通知）

踩过的坑：

  • 坑1：把Prometheus和Grafana装在了同一台服务器上，结果Prometheus的磁盘IO影响了Grafana的展示性能
  • 坑2：采集频率（scrape_interval）设得太短（5秒），导致Prometheus压力过大

注意事项：

  • 生产环境建议将Prometheus和Grafana部署在独立于业务服务器的监控专用机器上
  • 采集频率设为15-30秒即可满足绝大多数场景

三、方案一：Spring Boot应用接入（Micrometer + Actuator）

3.1 为什么推荐Micrometer

为什么这样写 ：如果你的Java应用是Spring Boot框架，那么Micrometer + Actuator是接入Prometheus监控的最优雅方式------无需引入额外进程，只需添加几个依赖和配置，就能自动暴露JVM、HTTP、系统等全方位指标。

Micrometer是Spring Boot官方推荐的指标采集库，它提供了一个供应商中立的API------你的代码只用Micrometer的API埋点，底层可以切换成Prometheus、Graphite、InfluxDB等任意监控系统，无需修改业务代码。

踩过的坑：

  • 坑1：只加了spring-boot-starter-actuator依赖，没加micrometer-registry-prometheus，访问/actuator/prometheus返回404
  • 坑2：生产环境没做安全控制，/actuator/prometheus端点暴露在公网，任何人都能看到监控数据

注意事项：

  • 本文示例基于Spring Boot 3.x + JDK 17
  • 生产环境务必对/actuator/prometheus端点做访问控制

3.2 添加依赖与配置

代码块：pom.xml添加依赖

xml 复制代码 
<!-- Spring Boot Actuator（提供监控端点基础设施） -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<!-- Micrometer Prometheus注册表（将指标转换为Prometheus格式） -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <version>1.11.5</version>
</dependency>

执行后说明 ：spring-boot-starter-actuator是Spring Boot的监控模块，提供了/actuator端点系列。micrometer-registry-prometheus是Micrometer的Prometheus适配器------它会自动将Micrometer的MeterRegistry中的指标转换为Prometheus可识别的文本格式，并通过/actuator/prometheus端点暴露出来。

代码块：application.yml配置

yaml 复制代码 
management:
  endpoints:
    web:
      exposure:
        include: prometheus, health   # 只暴露必要端点
  metrics:
    export:
      prometheus:
        enabled: true                 # 启用Prometheus格式输出
    tags:
      application: ${spring.application.name}  # 全局标签，便于区分不同应用
      environment: prod               # 环境标签
  endpoint:
    prometheus:
      enabled: true
    health:
      show-details: when-authorized   # 健康检查详情控制

执行后说明 ：management.endpoints.web.exposure.include控制哪些Actuator端点对外暴露------生产环境只暴露必要的端点 （prometheus和health），避免将shutdown等危险端点暴露出去。management.metrics.tags为所有指标添加全局标签，在Grafana中可以通过application标签筛选不同服务的指标。

代码块：安全控制（Spring Security配置）

java 复制代码 
@Configuration
@EnableWebSecurity
public class MetricsSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.authorizeHttpRequests(auth -> auth
            // 只允许特定角色访问Prometheus端点
            .requestMatchers("/actuator/prometheus").hasRole("METRICS_READER")
            // 健康检查可以公开（便于K8s探针）
            .requestMatchers("/actuator/health").permitAll()
            .anyRequest().authenticated()
        );
        http.httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

执行后说明 ：这个配置确保只有拥有METRICS_READER角色的用户才能访问监控指标。在application.yml中配置Spring Security的用户名密码，Prometheus的prometheus.yml中通过basic_auth配置认证信息。

3.3 验证指标暴露

代码块：验证Prometheus端点

bash 复制代码 
# 1. 启动Spring Boot应用后，访问Prometheus端点
curl http://localhost:8080/actuator/prometheus

# 2. 如果配置了Spring Security认证
curl -u metrics_user:password http://localhost:8080/actuator/prometheus

# 3. 查看关键JVM指标（输出示例）
# jvm_memory_used_bytes{area="heap",id="G1 Eden Space",...} 2.5E8
# jvm_gc_pause_seconds_count{action="end of minor GC",...} 42
# http_server_requests_seconds_count{method="GET",status="200",...} 1523

执行后说明 ：如果能看到大量以jvm_、http_、tomcat_、process_开头的指标行，说明配置成功。jvm_memory_used_bytes显示堆内存使用量，jvm_gc_pause_seconds_count显示GC次数，http_server_requests_seconds_count显示HTTP请求计数------这些就是Grafana仪表盘的数据来源。

3.4 自定义业务指标埋点

为什么这样写 ：Actuator自动暴露的指标是"通用"的------JVM内存、GC、HTTP请求等。但你的SaaS应用还有业务特有的指标需要监控：比如"订单创建量"、"用户登录失败率"、"缓存命中率"等。这些需要你自己埋点。

踩过的坑：

  • 坑：每次请求都创建新的Counter或Timer对象，导致内存泄漏
  • 坑：标签（Tags）设计不合理，导致时间序列爆炸（Cardinality爆炸）

注意事项：

  • Counter/Timer应该作为Bean注册，全局复用，不要每次请求都new
  • 标签的值应该是有限集合 （如状态码、方法名），不要把用户ID、订单ID等高基数数据作为标签

代码块：自定义业务指标埋点

java 复制代码 
@Service
@Slf4j
public class OrderMetricsService {

    private final Counter orderCreatedCounter;
    private final Timer orderProcessTimer;
    private final Gauge activeOrderGauge;
    private final AtomicInteger activeOrderCount = new AtomicInteger(0);

    public OrderMetricsService(MeterRegistry registry) {
        // 1. 计数器：统计订单创建总量（只增不减）
        this.orderCreatedCounter = Counter.builder("order.created.total")
            .description("Total number of orders created")
            .tag("service", "order-service")
            .register(registry);

        // 2. 计时器：统计订单处理耗时（含分位数）
        this.orderProcessTimer = Timer.builder("order.process.duration")
            .description("Order processing latency")
            .publishPercentiles(0.5, 0.95, 0.99)  // 输出P50、P95、P99
            .sla(Duration.ofMillis(100), Duration.ofMillis(500))  // SLA阈值
            .register(registry);

        // 3. 仪表盘：统计当前活跃订单数（可增可减）
        this.activeOrderGauge = Gauge.builder("order.active.count", activeOrderCount, AtomicInteger::get)
            .description("Current active orders count")
            .register(registry);
    }

    public void createOrder(Order order) {
        long startTime = System.nanoTime();
        try {
            // 业务逻辑...
            activeOrderCount.incrementAndGet();
            orderCreatedCounter.increment();
        } finally {
            // 记录处理耗时
            orderProcessTimer.record(Duration.ofNanos(System.nanoTime() - startTime));
            activeOrderCount.decrementAndGet();
        }
    }
}

执行后说明 ：Counter用于统计只增不减 的累计值（如总请求数、总错误数）；Timer用于统计耗时分布 ，配合publishPercentiles可以在Grafana中查看P95、P99响应时间；Gauge用于统计可增可减的瞬时值 （如当前连接数、队列长度）。定义好之后，这些指标会通过/actuator/prometheus自动暴露。

四、方案二：传统Java应用接入（JMX Exporter）

为什么这样写 ：如果你的Java应用不是Spring Boot（比如老旧的Struts应用、纯Java服务、或者是运行在Tomcat中的传统Web应用），没法用Micrometer怎么办？JMX Exporter就是为这种场景准备的------它以Java Agent方式无侵入地附着在JVM上，把JMX MBeans数据转换为Prometheus格式。

踩过的坑：

  • 坑1：JMX Exporter版本与JDK版本不兼容------在JDK 11上踩过坑
  • 坑2：没有配置指标过滤，单个实例暴露了上万个时间序列

注意事项：

  • JMX Exporter以-javaagent方式启动，无需修改业务代码
  • 生产环境务必配置config.yaml过滤不必要的指标

代码块：下载并配置JMX Exporter

bash 复制代码 
# 1. 下载JMX Exporter JAR包
wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.20.0/jmx_prometheus_javaagent-0.20.0.jar
sudo mv jmx_prometheus_javaagent-0.20.0.jar /opt/jmx_exporter/

# 2. 创建配置文件（/opt/jmx_exporter/config.yaml）
# 只暴露核心JVM指标，避免时间序列爆炸
cat > /opt/jmx_exporter/config.yaml << 'EOF'
---
startDelaySeconds: 0
ssl: false
lowercaseOutputName: true
lowercaseOutputLabelNames: true

rules:
  # JVM内存指标
  - pattern: 'java.lang<type=Memory><HeapMemoryUsage>'
    name: jvm_memory_heap_used
    type: GAUGE
  - pattern: 'java.lang<type=Memory><NonHeapMemoryUsage>'
    name: jvm_memory_nonheap_used
    type: GAUGE
  
  # GC指标
  - pattern: 'java.lang<type=GarbageCollector, name=(.*)><CollectionCount>'
    name: jvm_gc_collection_count
    labels:
      gc: "$1"
    type: COUNTER
  - pattern: 'java.lang<type=GarbageCollector, name=(.*)><CollectionTime>'
    name: jvm_gc_collection_time
    labels:
      gc: "$1"
    type: GAUGE
  
  # 线程指标
  - pattern: 'java.lang<type=Threading><ThreadCount>'
    name: jvm_threads_current
    type: GAUGE
  - pattern: 'java.lang<type=Threading><PeakThreadCount>'
    name: jvm_threads_peak
    type: GAUGE
  
  # 类加载指标
  - pattern: 'java.lang<type=ClassLoading><LoadedClassCount>'
    name: jvm_classes_loaded
    type: GAUGE
EOF

# 3. 启动Java应用时挂载JMX Exporter
java -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.20.0.jar=9404:/opt/jmx_exporter/config.yaml \
     -jar your-application.jar

执行后说明 ：-javaagent参数会在JVM启动时加载JMX Exporter，并在9404端口暴露HTTP服务。访问http://localhost:9404/metrics即可看到Prometheus格式的指标。config.yaml中的rules定义了从JMX MBeans到Prometheus指标的映射规则------只暴露必要的指标，避免时间序列爆炸。

五、部署Prometheus：监控数据的"大脑"

5.1 安装与配置Prometheus

为什么这样写：Prometheus是监控体系的"大脑"------它负责定期从Java应用拉取指标数据，存储为时间序列，并提供PromQL查询接口供Grafana使用。

踩过的坑：

  • 坑1：prometheus.yml中targets写成了localhost，但Prometheus和Java应用不在同一台机器上
  • 坑2：忘记开放防火墙端口（9090），Grafana连不上Prometheus

代码块：安装Prometheus

bash 复制代码 
# 1. 下载Prometheus（以3.5.0版本为例）
cd /opt
wget https://github.com/prometheus/prometheus/releases/download/v3.5.0/prometheus-3.5.0.linux-amd64.tar.gz
tar -xzf prometheus-3.5.0.linux-amd64.tar.gz
mv prometheus-3.5.0.linux-amd64 prometheus

# 2. 创建prometheus用户
sudo useradd --no-create-home --shell /bin/false prometheus
sudo chown -R prometheus:prometheus /opt/prometheus

# 3. 配置prometheus.yml
cat > /opt/prometheus/prometheus.yml << 'EOF'
global:
  scrape_interval: 15s        # 采集间隔
  evaluation_interval: 15s    # 告警规则评估间隔

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']  # Alertmanager地址

rule_files:
  - "alerts.yml"              # 告警规则文件

scrape_configs:
  # Prometheus自监控
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Spring Boot应用（Micrometer）
  - job_name: 'springboot-app'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['192.168.1.100:8080']  # 替换为实际IP
    # 如需认证
    # basic_auth:
    #   username: metrics_user
    #   password: your_password

  # 传统Java应用（JMX Exporter）
  - job_name: 'java-app-jmx'
    static_configs:
      - targets: ['192.168.1.101:9404']
EOF

执行后说明 ：scrape_interval: 15s表示Prometheus每15秒从Java应用拉取一次指标。scrape_configs中定义了两个抓取任务------一个针对Spring Boot应用的/actuator/prometheus端点，一个针对JMX Exporter的/metrics端点。targets中的IP地址要替换为实际的应用服务器IP。

代码块：创建systemd服务

bash 复制代码 
# 创建systemd服务文件
sudo tee /etc/systemd/system/prometheus.service << 'EOF'
[Unit]
Description=Prometheus
After=network.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/opt/prometheus/prometheus \
  --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data \
  --web.console.templates=/opt/prometheus/consoles \
  --web.console.libraries=/opt/prometheus/console_libraries
ExecReload=/bin/kill -HUP $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target
EOF

# 启动Prometheus
sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus

# 验证：访问 http://服务器IP:9090

执行后说明 ：启动后访问http://服务器IP:9090，在页面上方的输入框中输入up并点击Execute------如果看到{job="springboot-app"}的值为1，说明Prometheus成功抓取到了Java应用的指标。

六、部署Grafana：监控数据的"眼睛"

6.1 安装与配置Grafana

为什么这样写：Prometheus存储的是"数据"，Grafana把这些数据变成"图表"------让运维人员一眼就能看出系统状态，而不是盯着满屏的数字。

代码块：安装Grafana

bash 复制代码 
# 1. 添加Grafana官方YUM仓库（Rocky Linux / CentOS）
cat > /etc/yum.repos.d/grafana.repo << 'EOF'
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF

# 2. 安装Grafana
sudo dnf install -y grafana

# 3. 启动Grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

# 4. 验证：访问 http://服务器IP:3000
# 默认用户名/密码：admin/admin

执行后说明：首次登录会要求修改默认密码。Grafana默认监听3000端口，请确保防火墙已开放。

6.2 配置Prometheus数据源

代码块：通过界面配置数据源

  1. 登录Grafana（http://服务器IP:3000）
  2. 点击左侧菜单栏的 Connections → Data sources
  3. 点击 Add new data source ，选择 Prometheus
  4. 填写配置：
    • Name ：Prometheus
    • URL ：http://localhost:9090（如果Prometheus和Grafana在同一台机器）
    • 其他保持默认
  5. 点击 Save & test ，看到 "Data source is working" 即成功

执行后说明 ：数据源配置成功后，Grafana就可以查询Prometheus中的所有指标了。点击左侧的 Explore ，输入jvm_memory_used_bytes，如果能查到数据，说明整个链路已经打通。

6.3 导入JVM监控仪表盘

为什么这样写 ：从零开始画仪表盘很耗时。Grafana社区提供了大量现成的仪表盘模板，导入即可使用------JVM监控有多个成熟的模板可供选择。

代码块：导入仪表盘

bash 复制代码 
# 推荐两个JVM监控仪表盘ID：
# - 12900: JVM官方仪表盘（Micrometer）
# - 4701: 全套JVM + GC + Thread仪表盘

# 操作步骤：
# 1. 在Grafana左侧菜单点击 "+" → "Import"
# 2. 输入仪表盘ID（如 12900），点击 "Load"
# 3. 选择数据源 "Prometheus"
# 4. 点击 "Import"

执行后说明 ：导入后，你会看到一个包含JVM内存、GC、线程、类加载等核心指标的仪表盘。如果数据没有显示，检查仪表盘变量（如$application）是否与你的指标标签匹配------可能需要将变量值改为springboot-app或你的应用名称。

七、配置告警：从"被动发现"到"主动预警"

为什么这样写 ：仪表盘再漂亮，如果没人24小时盯着屏幕，故障发生时你还是最后一个知道的。告警是监控体系的"最后一道防线"------系统异常时主动通知你，而不是等你发现。

7.1 Prometheus告警规则

代码块：告警规则文件（/opt/prometheus/alerts.yml）

yaml 复制代码 
groups:
  - name: jvm_alerts
    interval: 30s
    rules:
      # 规则1：JVM内存使用率过高
      - alert: JVMHighMemoryUsage
        expr: |
          (sum(jvm_memory_used_bytes{area="heap"}) by (instance) 
           / sum(jvm_memory_max_bytes{area="heap"}) by (instance)) > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "JVM内存使用率过高"
          description: "实例 {{ $labels.instance }} 的堆内存使用率已超过85%，当前值: {{ $value | humanizePercentage }}"

      # 规则2：GC频繁（每分钟超过5次）
      - alert: JVMGCHighFrequency
        expr: |
          rate(jvm_gc_pause_seconds_count[5m]) > 5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "JVM GC频繁"
          description: "实例 {{ $labels.instance }} 的GC频率过高，当前: {{ $value }}次/秒"

      # 规则3：应用实例下线
      - alert: JavaAppDown
        expr: up{job="springboot-app"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Java应用实例下线"
          description: "实例 {{ $labels.instance }} 已下线超过1分钟"

      # 规则4：HTTP错误率过高（5xx错误超过5%）
      - alert: HighHTTPErrorRate
        expr: |
          (sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) 
           / sum(rate(http_server_requests_seconds_count[5m]))) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "HTTP 5xx错误率过高"
          description: "错误率: {{ $value | humanizePercentage }}"

执行后说明 ：告警规则使用PromQL编写。for: 5m表示条件持续5分钟才触发告警，避免瞬时波动导致误报。severity标签区分告警级别------critical表示紧急、warning表示警告。Prometheus会定期（evaluation_interval）评估这些规则。

7.2 Alertmanager配置与通知

为什么这样写：Prometheus负责"发现"告警，但告警要"通知"到具体的人------这就需要Alertmanager。它负责接收Prometheus推送的告警，进行分组、去重、静默，然后通过邮件、钉钉、企业微信等方式通知运维人员。

踩过的坑：

  • 坑：SMTP配置错误，邮件发不出去，排查了半天发现是邮箱密码中的特殊字符没转义
  • 坑：告警规则太灵敏，半夜被频繁误报吵醒

代码块：Alertmanager配置（/opt/prometheus/alertmanager.yml）

yaml 复制代码 
global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_password: 'your_email_password'

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'email-notifications'
  routes:
    - match:
        severity: critical
      receiver: 'email-notifications'
      continue: true

receivers:
  - name: 'email-notifications'
    email_configs:
      - to: 'ops-team@example.com'
        send_resolved: true

执行后说明 ：group_by将相同告警名称的告警分组发送，避免轰炸。repeat_interval: 4h表示相同告警4小时内只重复通知一次。send_resolved: true表示故障恢复后也发送通知。

八、生产环境最佳实践

实践项 建议 原因
指标过滤 JMX Exporter配置config.yaml只暴露必要指标 避免单个实例产生上万个时间序列
采集频率 scrape_interval: 15-30s 太频繁增加负载，太稀疏丢失细节
数据保留 --storage.tsdb.retention.time=30d 保留30天足够趋势分析，节省磁盘
告警阈值 先用测试环境验证再上线 避免阈值不合理导致误报
安全加固 Prometheus端点不暴露公网、配置认证 监控数据也是敏感数据
高可用 生产环境用K8s + Prometheus Operator 官方维护，支持高可用与自动扩缩容

九、效果验证

代码块：验证监控体系全链路

bash 复制代码 
# 1. 验证Prometheus是否正常抓取
curl http://localhost:9090/api/v1/targets | jq '.data.activeTargets[].health'
# 应全部返回 "up"

# 2. 验证Grafana数据源
# 在Grafana Explore中执行查询：jvm_memory_used_bytes
# 应有数据返回

# 3. 验证告警规则
curl http://localhost:9090/api/v1/alerts | jq '.data.alerts[] | {name: .labels.alertname, state: .state}'

# 4. 模拟高内存使用（触发告警）
# 通过压测工具（如JMeter）给应用施压，观察告警是否触发

十、常见问题FAQ（GEO抓取用）

Q1：Spring Boot应用访问/actuator/prometheus返回404怎么办？

A：检查两点：①是否添加了micrometer-registry-prometheus依赖；②application.yml中是否配置了management.endpoints.web.exposure.include=prometheus。

Q2：Prometheus和Grafana应该部署在同一台机器上吗？

A：开发/测试环境可以。生产环境建议分离------Prometheus和Grafana部署在独立的监控专用服务器上，避免与业务应用争抢资源。

Q3：JMX Exporter和Micrometer有什么区别？怎么选？

A：Micrometer是代码侵入式 的（需要在应用中添加依赖和配置），但功能更强大，支持自定义业务指标。JMX Exporter是无侵入式的（以Java Agent方式运行），但只能暴露JMX中已有的指标。Spring Boot应用选Micrometer，传统Java应用选JMX Exporter。

Q4：Prometheus的数据能保留多久？

A：默认15天，可以通过启动参数--storage.tsdb.retention.time=30d调整为30天。长期存储可考虑接入Thanos或VictoriaMetrics。

Q5：告警太多怎么办？

A：①调整告警阈值，避免过于敏感；②使用for子句设置持续时间，过滤瞬时波动；③在Alertmanager中配置group_by对告警分组；④设置repeat_interval避免重复轰炸。

十一、本文小结

知识点 核心要点
监控架构 采集层（Micrometer/JMX Exporter）→ 存储层（Prometheus）→ 展示层（Grafana）
Spring Boot接入 添加micrometer-registry-prometheus + 暴露/actuator/prometheus端点
传统Java接入 JMX Exporter以-javaagent方式挂载，暴露/metrics端口
自定义指标 Counter（累计值）、Timer（耗时分布）、Gauge（瞬时值）
Prometheus部署 配置prometheus.yml定义抓取任务，systemd托管
Grafana部署 添加Prometheus数据源，导入仪表盘ID（12900/4701）
告警配置 Prometheus定义告警规则 → Alertmanager推送通知
最佳实践 指标过滤防爆炸、阈值验证防误报、安全加固防泄露

💡 一句话记住本篇：监控体系的核心是"Micrometer/JMX Exporter采指标、Prometheus存指标、Grafana看指标、Alertmanager报告警"------四层各司其职，让你从"被动救火"变为"主动预防"。

相关推荐
小钻风33662 小时前
Spring Boot 文件上传详解：深入理解 MultipartFile 的使用与原理
java·开发语言
其美杰布-富贵-李2 小时前
Spring Boot 工程开发全流程说明
java·spring boot·后端
前端双越老师3 小时前
如何以前端视角（非0基础）学 Java ？
java·node.js·全栈
dear_bi_MyOnly3 小时前
【SpringBoot配置文件】
java·spring boot·后端·学习·spring·java-ee·学习方法
做个文艺程序员4 小时前
Linux第22篇：用Docker容器化你的Java SaaS应用：一次构建，随处运行
java·docker·容器
其美杰布-富贵-李5 小时前
Spring Boot 依赖注入说明文档
java·spring boot·python
tachibana25 小时前
hot100 数组中的第K个最大元素(215)
java·数据结构·算法·leetcode
AI人工智能+电脑小能手5 小时前
【大白话说Java面试题 第188题】【08_Kafka篇】第4题：Kafka 大量消息积压时该如何处理？
java·性能优化·kafka·故障排查·消息积压
our_times5 小时前
2026年Java开发者破局指南：Spring AI 2.0 与 Agent 开发实战
java·人工智能·spring
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04AI科技热点日报 | 2026年07月01日05幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南06国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路082026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？092026 年 AI 大模型 & AI 编程工具实战全总结10Kimi K3 真实体验：全网评价整理，优缺点一次性说清楚