1. 为什么需要JVM性能监控系统第一次线上服务崩溃的经历让我记忆犹新。那天凌晨三点报警电话把我从睡梦中惊醒线上订单服务完全瘫痪。排查了半天才发现是JVM老年代内存泄漏导致Full GC频繁触发最终拖垮了整个系统。如果当时有一套完善的JVM监控系统就能提前发现内存异常增长的趋势避免这次事故。这就是为什么我们需要搭建GrafanaPrometheusMicrometer这套黄金组合。它们分别扮演着Micrometer应用层的指标采集器相当于汽车的传感器Prometheus时序数据库和告警中枢相当于行车电脑Grafana数据可视化平台相当于仪表盘实测下来这套方案有三个突出优势全链路覆盖从JVM内部指标堆内存、线程数到系统资源CPU、磁盘都能监控实时性强默认15秒采集一次数据能捕捉到突发性性能波动零侵入性对业务代码几乎没有影响加个依赖改个配置就能用我经手过的电商、金融项目中90%的JVM问题内存泄漏、线程阻塞、GC异常都能通过这个方案提前预警。下面我会手把手带你搭建这套系统包含我踩过的所有坑和优化技巧。2. Spring Boot应用监控配置2.1 Actuator基础配置Spring Boot自带的Actuator模块是监控系统的起点。最近在给一家物流公司做监控升级时发现他们还在用1.x版本的配置方式导致很多关键指标缺失。这里分享正确的新版配置!-- pom.xml必须包含这两个依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency关键的application.yml配置这些参数都是我压测后优化的值management: endpoints: web: exposure: include: * # 暴露所有端点 base-path: /monitor # 自定义路径更安全 endpoint: health: show-details: always prometheus: enabled: true metrics: tags: application: ${spring.application.name} # 重要用于区分不同服务 export: prometheus: step: 15s # 采集间隔配置完成后访问http://localhost:8080/monitor/prometheus你会看到类似这样的输出jvm_memory_used_bytes{areaheap,idPS Survivor Space} 1.5672328E7 jvm_threads_live_threads 42 http_server_requests_seconds_count{methodGET,uri/api/orders,status200} 153避坑指南不要直接用/actuator作为路径容易被扫描工具攻击生产环境建议通过include精细控制暴露的端点如health,info,prometheus如果看到404检查是否漏了micrometer-registry-prometheus依赖2.2 Micrometer高级技巧Micrometer的强大之处在于它能自动收集数十种JVM指标但有些关键指标需要特别关注GC相关指标直接影响系统卡顿jvm_gc_pause_seconds_count{gcG1 Young Generation} jvm_gc_pause_seconds_sum{gcG1 Old Generation}线程状态监控死锁预警jvm_threads_states_threads{stateBLOCKED}HTTP接口性能定位慢请求http_server_requests_seconds_max{uri/api/payment}我常用的自定义指标配置示例Bean MeterRegistryCustomizerMeterRegistry metricsCommonTags() { return registry - registry.config() .commonTags(region, System.getenv(AWS_REGION)) // 区分部署区域 .commonTags(instance, hostname); // 标识实例 } // 自定义业务指标 Counter orderCounter Metrics.counter(order.count, type, vip); orderCounter.increment();3. Prometheus数据采集实战3.1 安装与基础配置Prometheus的安装其实很简单但配置中有很多经验性的参数需要调整。这是我优化过的prometheus.yml配置global: scrape_interval: 15s # 抓取频率 evaluation_interval: 15s # 规则评估频率 scrape_configs: - job_name: java-apps metrics_path: /monitor/prometheus scrape_interval: 10s # JVM监控需要更高频率 static_configs: - targets: [app1:8080, app2:8080] labels: env: prod tier: backend - job_name: node static_configs: - targets: [192.168.1.100:9100]启动命令建议用nohup生产环境建议用systemdnohup ./prometheus \ --config.fileprometheus.yml \ --web.listen-address0.0.0.0:9090 \ --storage.tsdb.retention.time30d \ prometheus.log 21 关键参数说明storage.tsdb.retention.time数据保留时间默认15天--web.enable-lifecycle支持热重载配置发POST到/-/reloadscrape_timeout建议设置为scrape_interval的2/33.2 告警规则配置在prometheus.yml同目录下创建alert.rules.ymlgroups: - name: jvm-alerts rules: - alert: HighHeapUsage expr: sum(jvm_memory_used_bytes{areaheap}) by (instance) / sum(jvm_memory_max_bytes{areaheap}) by (instance) 0.85 for: 5m labels: severity: warning annotations: summary: High heap usage on {{ $labels.instance }} description: Heap usage is {{ $value }}% - alert: GCTooFrequent expr: increase(jvm_gc_pause_seconds_count[1m]) 10 for: 10m labels: severity: critical加载规则文件需要在prometheus.yml中添加rule_files: - alert.rules.yml实用告警规则线程数突增jvm_threads_live_threads 500HTTP错误率sum(rate(http_server_requests_seconds_count{status~5..}[1m])) by (uri) / sum(rate(http_server_requests_seconds_count[1m])) by (uri) 0.01系统负载node_load5 / count(count(node_cpu_seconds_total{modesystem}) by (cpu)) 24. Grafana可视化搭建4.1 安装与数据源配置用Docker安装Grafana是最佳实践docker run -d \ -p 3000:3000 \ --namegrafana \ -v /data/grafana:/var/lib/grafana \ grafana/grafana:9.0.0配置Prometheus数据源时要注意URL填写http://prometheus:9090如果是容器需要配置网络开启Scrape interval覆盖设置为15s添加Custom HTTP Header进行鉴权如Authorization: Bearer xxx4.2 仪表盘配置技巧直接导入现成模板固然方便但定制化才能发挥最大价值。分享我的JVM监控面板配置要点核心图表配置内存池使用率sum(jvm_memory_used_bytes{area~heap|nonheap}) by (area) / sum(jvm_memory_max_bytes{area~heap|nonheap}) by (area)显示为Time seriesY轴格式设为0-100%添加阈值线85%警告95%危险GC暂停时间热力图histogram_quantile(0.95, sum(rate(jvm_gc_pause_seconds_bucket[1m])) by (le, gc))显示为Heatmap按GC类型分桶线程状态堆叠图sum(jvm_threads_states_threads) by (state)显示为Stacked bar重点关注BLOCKED状态布局优化技巧将关键指标放在顶部用Stat图表使用Row分割不同维度的监控添加Annotation标记部署事件设置Variables实现服务切换如${app}变量5. 生产环境优化方案5.1 性能调优参数在高负载场景下实测QPS5000需要调整这些参数Prometheus调优global: scrape_interval: 30s # 降低采集频率 storage: tsdb: wal_compression: true # 启用WAL压缩 max_block_chunk_segment_size: 512MBGrafana优化开启rendering_server使用外部渲染服务配置[dashboards] min_refresh_interval 30s使用GF_DATABASE_MAX_IDLE_CONN10减少数据库连接5.2 高可用方案对于关键业务系统建议部署多实例Prometheus联邦集群scrape_configs: - job_name: federate scrape_interval: 1m honor_labels: true metrics_path: /federate params: match[]: - {jobjava-apps} static_configs: - targets: - prometheus-01:9090 - prometheus-02:9090Grafana多数据源配置多个Prometheus实例为不同数据源使用--config参数指定不同环境的配置5.3 安全防护措施基础安全为Prometheus和Grafana启用HTTPS配置basic_auth或OAuth2.0认证限制/monitor端点的IP访问敏感数据过滤MeterFilter denyTags(String... tagKeys) { return MeterFilter.deny(id - { for (String tagKey : tagKeys) { if (id.getTag(tagKey) ! null) { return true; } } return false; }); }这套方案在多个千万级用户的产品中验证过稳定性。最近帮一个短视频平台优化后他们的GC问题排查时间从平均4小时缩短到15分钟。监控系统就像开发者的眼睛越早搭建收益越大。