Nightingale 集成 Spring Boot基于 Actuator Micrometer 的 JVM 与 HTTP 指标采集、监控大盘与告警实战【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale导读本文讲解如何在 Nightingale 监控体系中纳管 Spring Boot 服务——应用侧通过 Spring Boot Actuator底层基于 Micrometer暴露 Prometheus 格式指标采集侧由 Categraf 的input.prometheus插件抓取/actuator/prometheus端点最终在 Nightingale 中落地 JVM 监控大盘与基于 PromQL 的告警规则。读完本文你将掌握 Spring Boot 3.x / 2.x 的指标暴露配置、Categraf 采集配置的写法与标签设计并能直接复用仓库自带的仪表盘和告警规则。Spring Boot 是 Java 生态中最主流的应用框架。要对它做监控常见的思路是引入 Micrometer 暴露 metrics但更省事的方式是直接使用 Spring Boot Actuator——Actuator 底层同样基于 Micrometer 实现只是把配置和使用进一步简化了。Nightingale 仓库在 integrations/SpringBoot 目录下提供了完整的接入资源接入文档中英双语、JVM 监控仪表盘、Prometheus 告警规则以及国际化文案可以直接导入使用。一、接入原理Actuator 如何把 JVM 指标变成 Prometheus 协议Spring Boot 项目的指标链路分三层MicrometerJava 生态的事实标准指标门面负责定义 Counter、Gauge、Timer、Summary 等指标类型Spring Boot Actuator在 Micrometer 之上提供开箱即用的指标暴露能力内置了大量绑定JVM 内存、GC、线程、HTTP 请求、Tomcat/Jetty 线程池、Logback 日志事件等无需手写埋点Micrometer Registry Prometheus把 Micrometer 指标序列化为 Prometheus 文本协议由/actuator/prometheus端点对外输出。因此在应用侧只需引入两个依赖spring-boot-starter-actuatormicrometer-registry-prometheus采集侧Categraf 的 Prometheus 插件即input.prometheus会以固定间隔抓取该端点并推送至 Nightingale 的时序库如 VictoriaMetrics / Prometheus随后即可在 Nightingale 中查询、展示与告警。二、应用配置按版本暴露 Prometheus 端点Spring Boot 3.x在application.properties中加入management.endpoints.web.exposure.includehealth,info,prometheus management.endpoint.prometheus.enabledtrue management.prometheus.metrics.export.enabledtrueSpring Boot 2.xmanagement.endpoints.web.exposure.includehealth,info,prometheus management.endpoint.prometheus.enabledtrue management.metrics.export.prometheus.enabledtrue两个版本的区别仅在 Prometheus 导出的开关路径3.x 是management.prometheus.metrics.export.enabled2.x 是management.metrics.export.prometheus.enabled其余一致。启动应用后访问http://localhost:8080/actuator/prometheus应能返回指标文本# HELP/# TYPE开头的 Prometheus 文本格式。如果返回 404优先检查依赖是否完整micrometer-registry-prometheus是否引入exposure.include是否包含prometheus端口是否为 8080 或已按实际端口调整。安全提醒除非确有需要不要把management.endpoints.web.exposure.include设置为*——这会暴露env、heapdump、shutdown等敏感或危险端点。按最小权限原则只暴露health,info,prometheus即可。三、采集配置Categraf 的 input.prometheus 插件在运行 Categraf 的机器上新建conf/input.prometheus/springboot.toml[[instances]] urls [http://127.0.0.1:8080/actuator/prometheus] url_label_key instance url_label_value {{.Host}} labels { job springboot, application order-service }逐项说明配置项作用取值建议urls要抓取的 Prometheus 端点按实际地址填写如http://127.0.0.1:8080/actuator/prometheusurl_label_key为每条时序附加的标签键通常用instance用于区分同一应用的不同实例url_label_value该标签的值支持模板{{.Host}}会自动替换为主机名/标识labels静态附加标签job标识采集任务application标识业务应用名配置完成后重启 Categraf指标即以jvm_*、http_server_requests_*、tomcat_*、logback_events_*等前缀进入 Nightingale。标签设计多实例部署的关键约定仓库接入文档明确给出两条约定多实例部署时保持application相同、instance唯一。application用于在模板中按应用聚合例如 JVM 内存使用率按应用维度查看instance用于区分同一应用的多个副本在 Nightingale 的仪表盘模板如 JVM(Actuator)withapplicationname.jsonwithapplicationname.json)中变量即按application和instance设计采集时标签不一致会导致变量下拉与面板过滤失效。面板数据的热身要求http_server_requests_seconds_*这类速率与延迟指标以及 GC 相关指标只有在产生真实 HTTP 请求、线程活动和 GC之后才会出现数据。因此验证面板前请先对应用发起实际请求压测或正常业务流量避免误判为采集失败。四、监控大盘仓库自带的 JVM 仪表盘仓库在 integrations/SpringBoot/dashboards 提供了两个可直接导入的仪表盘JVM.jsonJVM 仪表盘按ident标签过滤适用于采集侧以ident标识实例的场景JVM(Actuator)withapplicationname.jsonwithapplicationname.json)按applicationinstance双变量过滤与上文采集配置中的标签设计一一对应推荐优先使用。从仪表盘源码可以看到完整的监控面板分组以with application name版本为例Quick Facts启动时间、运行时长UptimeJVM 内存Heap / Non-Heap 使用率与使用量、JVM 总内存、Native MemoryRSS/PSS/Swap、内存池Heap/Non-Heap 可切换HTTP请求速率Rate、错误数Errors、延迟Duration均值与 P99 类最大值、Utilisation线程与容器Tomcat / Jetty 线程池 busy、current、config_max线程数、线程状态CPU 与文件系统/进程 CPU 使用率、打开文件描述符GC 与类加载GC 次数与停顿时长、Allocated/Promoted、类加载数量与 5 分钟增量用于发现类加载器泄漏Buffer PoolsDirect / Mapped 缓冲区的用量与容量日志事件Logback ERROR 等日志事件计数。对应到 PromQL面板底层依赖的典型指标包括均为 Actuator 暴露的标准 Micrometer 指标# 堆内存使用率 sum(jvm_memory_used_bytes{instance$instance, areaheap}) * 100 / sum(jvm_memory_max_bytes{instance$instance, areaheap}) # HTTP 请求速率 sum(rate(http_server_requests_seconds_count{instance$instance}[5m])) # HTTP 平均延迟非 5xx sum(rate(http_server_requests_seconds_sum{instance$instance, status!~5..}[1m])) / sum(rate(http_server_requests_seconds_count{instance$instance, status!~5..}[1m])) # GC 停顿时长 rate(jvm_gc_pause_seconds_sum{instance$instance}[5m]) / rate(jvm_gc_pause_seconds_count{instance$instance}[5m]) # 5 分钟内 ERROR 日志数量 increase(logback_events_total{instance$instance}[5m])需要注意兼容性细节jvm_memory_used_bytes、tomcat_threads_busy等指标名在部分 Spring Boot / Micrometer 版本中存在新旧命名差异例如jvm_threads_live与jvm_threads_live_threads面板中已用or做了新旧指标的兜底兼容例如tomcat_threads_busy{instance$instance} or tomcat_threads_busy_threads{instance$instance}若你的应用版本恰好命中旧命名面板同样能正常出图。五、告警规则仓库自带的 Spring Boot 告警模板仓库在 integrations/SpringBoot/alerts/alerts.json 提供了 5 条开箱即用的 Prometheus 告警规则均基于instance聚合可直接导入 Nightingale 告警规则管理告警名称PromQL 要点阈值springboot HEAP内存使用率大于85%sum by (instance) (jvm_memory_used_bytes{areaheap}) * 100 / sum by (instance) (jvm_memory_max_bytes{areaheap}) 8585%springboot 非堆内存使用率大于85%非堆 used / max 85%并保证 max 085%springboot HTTP请求延迟大于10smax by (instance, uri) (http_server_requests_seconds_max{status!~5..}) 1010 秒springboot HTTP错误数sum by (instance, uri) (rate(http_server_requests_seconds_count{status~5..}[5m])) 0出现即告警springboot 事件错误数sum by (instance) (increase(logback_events_total{levelerror}[5m])) 05 分钟内出现 ERROR 即告警从告警 JSON 结构看这些规则默认prom_eval_interval: 30每 30 秒评估一次、severity: 2、全天候生效并开启了恢复通知notify_recovered: 1。更重要的是每条规则都内置了annotations.action处置建议例如HEAP 内存告警先看jvm_gc_pause_seconds确认 Full GC 是否频繁用jmap -histo:live pid或 arthas 的 heapdump 抓堆、按对象数排序找异常增长的类区分是业务量增长调大-Xmx还是内存泄漏必须在代码里修复扩堆只是拖延应急可重启释放但要先抓好堆快照保留现场。HTTP 延迟告警从告警标签取uri定位接口用 arthastrace或 APM 链路追踪定位耗时段数据库慢查补索引下游慢则加熔断降级确认线程池是否被慢请求占满必要时隔离线程池。HTTP 错误告警取uri后到应用日志搜异常栈区分全量失败与部分失败若与发布时间吻合优先回滚。非堆内存告警用jcmd pid VM.native_memory summary需开启 NativeMemoryTracking或 arthasmemory看各区占用Metaspace 持续增长多为类加载器泄漏反复热部署、动态代理、脚本引擎应急调大-XX:MaxMetaspaceSize并重启。日志 ERROR 告警按instance定位实例按异常类型归类区分偶发下游抖动、超时重试与稳定复现代码 bug、配置错误ERROR 量突增且与发布时间吻合时优先回滚。这些中文处置建议在 i18n/en_US.json 中提供了英文对照便于国际化团队使用i18n 的 key 即告警文案本身说明仓库的告警文案已纳入多语言体系。六、完整落地路径小结把以上环节串起来一个 Spring Boot 服务接入 Nightingale 的完整流程是应用侧引入spring-boot-starter-actuator与micrometer-registry-prometheus按版本配置application.properties暴露prometheus端点验证http://localhost:8080/actuator/prometheus可返回指标采集侧在 Categraf 的conf/input.prometheus/下新建springboot.toml配置抓取 URL 与标签application相同、instance唯一重启 Categraf展示侧导入 JVM(Actuator)withapplicationname.jsonwithapplicationname.json)或 JVM.json仪表盘先产生真实流量再验证速率/延迟面板告警侧导入 alerts/alerts.json按需调整阈值与通知渠道参考内置 action 建议处置。这套方案完全复用 Spring Boot Actuator 的标准化指标与 Categraf 的 Prometheus 采集能力无需在业务代码中做任何埋点改动即可获得覆盖 JVM 内存、GC、线程、HTTP、容器线程池、日志事件的完整可观测视图。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nightingale 集成 Spring Boot：基于 Actuator + Micrometer 的 JVM 与 HTTP 指标采集、监控大盘与告警实战
Nightingale 集成 Spring Boot基于 Actuator Micrometer 的 JVM 与 HTTP 指标采集、监控大盘与告警实战【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale导读本文讲解如何在 Nightingale 监控体系中纳管 Spring Boot 服务——应用侧通过 Spring Boot Actuator底层基于 Micrometer暴露 Prometheus 格式指标采集侧由 Categraf 的input.prometheus插件抓取/actuator/prometheus端点最终在 Nightingale 中落地 JVM 监控大盘与基于 PromQL 的告警规则。读完本文你将掌握 Spring Boot 3.x / 2.x 的指标暴露配置、Categraf 采集配置的写法与标签设计并能直接复用仓库自带的仪表盘和告警规则。Spring Boot 是 Java 生态中最主流的应用框架。要对它做监控常见的思路是引入 Micrometer 暴露 metrics但更省事的方式是直接使用 Spring Boot Actuator——Actuator 底层同样基于 Micrometer 实现只是把配置和使用进一步简化了。Nightingale 仓库在 integrations/SpringBoot 目录下提供了完整的接入资源接入文档中英双语、JVM 监控仪表盘、Prometheus 告警规则以及国际化文案可以直接导入使用。一、接入原理Actuator 如何把 JVM 指标变成 Prometheus 协议Spring Boot 项目的指标链路分三层MicrometerJava 生态的事实标准指标门面负责定义 Counter、Gauge、Timer、Summary 等指标类型Spring Boot Actuator在 Micrometer 之上提供开箱即用的指标暴露能力内置了大量绑定JVM 内存、GC、线程、HTTP 请求、Tomcat/Jetty 线程池、Logback 日志事件等无需手写埋点Micrometer Registry Prometheus把 Micrometer 指标序列化为 Prometheus 文本协议由/actuator/prometheus端点对外输出。因此在应用侧只需引入两个依赖spring-boot-starter-actuatormicrometer-registry-prometheus采集侧Categraf 的 Prometheus 插件即input.prometheus会以固定间隔抓取该端点并推送至 Nightingale 的时序库如 VictoriaMetrics / Prometheus随后即可在 Nightingale 中查询、展示与告警。二、应用配置按版本暴露 Prometheus 端点Spring Boot 3.x在application.properties中加入management.endpoints.web.exposure.includehealth,info,prometheus management.endpoint.prometheus.enabledtrue management.prometheus.metrics.export.enabledtrueSpring Boot 2.xmanagement.endpoints.web.exposure.includehealth,info,prometheus management.endpoint.prometheus.enabledtrue management.metrics.export.prometheus.enabledtrue两个版本的区别仅在 Prometheus 导出的开关路径3.x 是management.prometheus.metrics.export.enabled2.x 是management.metrics.export.prometheus.enabled其余一致。启动应用后访问http://localhost:8080/actuator/prometheus应能返回指标文本# HELP/# TYPE开头的 Prometheus 文本格式。如果返回 404优先检查依赖是否完整micrometer-registry-prometheus是否引入exposure.include是否包含prometheus端口是否为 8080 或已按实际端口调整。安全提醒除非确有需要不要把management.endpoints.web.exposure.include设置为*——这会暴露env、heapdump、shutdown等敏感或危险端点。按最小权限原则只暴露health,info,prometheus即可。三、采集配置Categraf 的 input.prometheus 插件在运行 Categraf 的机器上新建conf/input.prometheus/springboot.toml[[instances]] urls [http://127.0.0.1:8080/actuator/prometheus] url_label_key instance url_label_value {{.Host}} labels { job springboot, application order-service }逐项说明配置项作用取值建议urls要抓取的 Prometheus 端点按实际地址填写如http://127.0.0.1:8080/actuator/prometheusurl_label_key为每条时序附加的标签键通常用instance用于区分同一应用的不同实例url_label_value该标签的值支持模板{{.Host}}会自动替换为主机名/标识labels静态附加标签job标识采集任务application标识业务应用名配置完成后重启 Categraf指标即以jvm_*、http_server_requests_*、tomcat_*、logback_events_*等前缀进入 Nightingale。标签设计多实例部署的关键约定仓库接入文档明确给出两条约定多实例部署时保持application相同、instance唯一。application用于在模板中按应用聚合例如 JVM 内存使用率按应用维度查看instance用于区分同一应用的多个副本在 Nightingale 的仪表盘模板如 JVM(Actuator)withapplicationname.jsonwithapplicationname.json)中变量即按application和instance设计采集时标签不一致会导致变量下拉与面板过滤失效。面板数据的热身要求http_server_requests_seconds_*这类速率与延迟指标以及 GC 相关指标只有在产生真实 HTTP 请求、线程活动和 GC之后才会出现数据。因此验证面板前请先对应用发起实际请求压测或正常业务流量避免误判为采集失败。四、监控大盘仓库自带的 JVM 仪表盘仓库在 integrations/SpringBoot/dashboards 提供了两个可直接导入的仪表盘JVM.jsonJVM 仪表盘按ident标签过滤适用于采集侧以ident标识实例的场景JVM(Actuator)withapplicationname.jsonwithapplicationname.json)按applicationinstance双变量过滤与上文采集配置中的标签设计一一对应推荐优先使用。从仪表盘源码可以看到完整的监控面板分组以with application name版本为例Quick Facts启动时间、运行时长UptimeJVM 内存Heap / Non-Heap 使用率与使用量、JVM 总内存、Native MemoryRSS/PSS/Swap、内存池Heap/Non-Heap 可切换HTTP请求速率Rate、错误数Errors、延迟Duration均值与 P99 类最大值、Utilisation线程与容器Tomcat / Jetty 线程池 busy、current、config_max线程数、线程状态CPU 与文件系统/进程 CPU 使用率、打开文件描述符GC 与类加载GC 次数与停顿时长、Allocated/Promoted、类加载数量与 5 分钟增量用于发现类加载器泄漏Buffer PoolsDirect / Mapped 缓冲区的用量与容量日志事件Logback ERROR 等日志事件计数。对应到 PromQL面板底层依赖的典型指标包括均为 Actuator 暴露的标准 Micrometer 指标# 堆内存使用率 sum(jvm_memory_used_bytes{instance$instance, areaheap}) * 100 / sum(jvm_memory_max_bytes{instance$instance, areaheap}) # HTTP 请求速率 sum(rate(http_server_requests_seconds_count{instance$instance}[5m])) # HTTP 平均延迟非 5xx sum(rate(http_server_requests_seconds_sum{instance$instance, status!~5..}[1m])) / sum(rate(http_server_requests_seconds_count{instance$instance, status!~5..}[1m])) # GC 停顿时长 rate(jvm_gc_pause_seconds_sum{instance$instance}[5m]) / rate(jvm_gc_pause_seconds_count{instance$instance}[5m]) # 5 分钟内 ERROR 日志数量 increase(logback_events_total{instance$instance}[5m])需要注意兼容性细节jvm_memory_used_bytes、tomcat_threads_busy等指标名在部分 Spring Boot / Micrometer 版本中存在新旧命名差异例如jvm_threads_live与jvm_threads_live_threads面板中已用or做了新旧指标的兜底兼容例如tomcat_threads_busy{instance$instance} or tomcat_threads_busy_threads{instance$instance}若你的应用版本恰好命中旧命名面板同样能正常出图。五、告警规则仓库自带的 Spring Boot 告警模板仓库在 integrations/SpringBoot/alerts/alerts.json 提供了 5 条开箱即用的 Prometheus 告警规则均基于instance聚合可直接导入 Nightingale 告警规则管理告警名称PromQL 要点阈值springboot HEAP内存使用率大于85%sum by (instance) (jvm_memory_used_bytes{areaheap}) * 100 / sum by (instance) (jvm_memory_max_bytes{areaheap}) 8585%springboot 非堆内存使用率大于85%非堆 used / max 85%并保证 max 085%springboot HTTP请求延迟大于10smax by (instance, uri) (http_server_requests_seconds_max{status!~5..}) 1010 秒springboot HTTP错误数sum by (instance, uri) (rate(http_server_requests_seconds_count{status~5..}[5m])) 0出现即告警springboot 事件错误数sum by (instance) (increase(logback_events_total{levelerror}[5m])) 05 分钟内出现 ERROR 即告警从告警 JSON 结构看这些规则默认prom_eval_interval: 30每 30 秒评估一次、severity: 2、全天候生效并开启了恢复通知notify_recovered: 1。更重要的是每条规则都内置了annotations.action处置建议例如HEAP 内存告警先看jvm_gc_pause_seconds确认 Full GC 是否频繁用jmap -histo:live pid或 arthas 的 heapdump 抓堆、按对象数排序找异常增长的类区分是业务量增长调大-Xmx还是内存泄漏必须在代码里修复扩堆只是拖延应急可重启释放但要先抓好堆快照保留现场。HTTP 延迟告警从告警标签取uri定位接口用 arthastrace或 APM 链路追踪定位耗时段数据库慢查补索引下游慢则加熔断降级确认线程池是否被慢请求占满必要时隔离线程池。HTTP 错误告警取uri后到应用日志搜异常栈区分全量失败与部分失败若与发布时间吻合优先回滚。非堆内存告警用jcmd pid VM.native_memory summary需开启 NativeMemoryTracking或 arthasmemory看各区占用Metaspace 持续增长多为类加载器泄漏反复热部署、动态代理、脚本引擎应急调大-XX:MaxMetaspaceSize并重启。日志 ERROR 告警按instance定位实例按异常类型归类区分偶发下游抖动、超时重试与稳定复现代码 bug、配置错误ERROR 量突增且与发布时间吻合时优先回滚。这些中文处置建议在 i18n/en_US.json 中提供了英文对照便于国际化团队使用i18n 的 key 即告警文案本身说明仓库的告警文案已纳入多语言体系。六、完整落地路径小结把以上环节串起来一个 Spring Boot 服务接入 Nightingale 的完整流程是应用侧引入spring-boot-starter-actuator与micrometer-registry-prometheus按版本配置application.properties暴露prometheus端点验证http://localhost:8080/actuator/prometheus可返回指标采集侧在 Categraf 的conf/input.prometheus/下新建springboot.toml配置抓取 URL 与标签application相同、instance唯一重启 Categraf展示侧导入 JVM(Actuator)withapplicationname.jsonwithapplicationname.json)或 JVM.json仪表盘先产生真实流量再验证速率/延迟面板告警侧导入 alerts/alerts.json按需调整阈值与通知渠道参考内置 action 建议处置。这套方案完全复用 Spring Boot Actuator 的标准化指标与 Categraf 的 Prometheus 采集能力无需在业务代码中做任何埋点改动即可获得覆盖 JVM 内存、GC、线程、HTTP、容器线程池、日志事件的完整可观测视图。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考