尧图网站建设 
Nightingale 集成指南Java/JVM 监控仪表盘JMX Exporter 与 OpenTelemetry 双采集链路【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleNightingale 的integrations/Java目录为 Java 应用提供了一组可直接导入的 Prometheus 数据源 JVM 仪表盘覆盖堆内存、内存池、GC、线程、类加载、进程与物理内存等核心指标。本指南以该目录下的 README 为核心完整讲解「Prometheus JMX Exporter」与「OpenTelemetry Java Agent」两条采集链路的部署步骤、Categraf 抓取配置、指标验证方法并结合仓库内的仪表盘 JSON 与国际化文件说明每张仪表盘依赖的指标族与标签约束。读完本文你可以独立完成 Java 进程的指标采集、验证与仪表盘导入。两类仪表盘两套指标族不能混用目录 integrations/Java/dashboards 下共存放三张仪表盘按采集方式分为两类指标命名完全不同仪表盘文件采集方式关键指标jmx_by_exporter.jsonJMXPrometheus JMX Exporterjmx_exporter_build_info、jvm_memory_*、jvm_gc_collection_seconds_*jmx_by_kubernetes.jsonJMX - KubernetesPrometheus JMX ExporterK8s 标签体系同上但使用namespace/container/pod标签jvm_by_opentelementry.jsonJVM by OpenTelemetryOpenTelemetry Java Agent → OTel Collectorjvm_cpu_count、jvm_memory_used_bytes、jvm_gc_duration_seconds_*等 OTel 命名由于两种链路产出的指标名与标签结构不同混用会导致面板查询无数据。选择仪表盘之前必须先确认线上 Java 进程实际使用的是哪条采集链路。链路一Prometheus JMX ExporterJMX Exporter 是 Prometheus 官方维护的 Java Agent通过 JMXJava Management Extensions读取 JVM 运行时数据并以/metrics暴露。1. 为 Java 进程加载 Agent 并监听端口以 9404 端口为例启动命令大致为java -javaagent:/opt/jmx_prometheus_javaagent.jar9404:/opt/config.yaml -jar app.jar参数含义-javaagent指定 agent 包路径9404:config.yaml表示监听 9404 端口并使用指定的 JMX 抓取规则配置文件。Agent 启动后http://127.0.0.1:9404/metrics即为 Prometheus 格式的指标端点。2. 新建 Categraf 抓取配置在 Categraf 的conf/input.prometheus/目录下新建java-jmx.toml内容如下# conf/input.prometheus/java-jmx.toml [[instances]] urls [http://127.0.0.1:9404/metrics] url_label_key instance url_label_value {{.Host}} labels { job order-service }各字段作用urlsJMX Exporter 暴露的指标地址抓取后会为每条时序自动附加instance标签url_label_key/url_label_value指定标签名与取值{{.Host}}会替换为目标主机名labels附加的静态标签这里用job order-service标识业务服务。3. 先验证再导入仪表盘配置完成后先确认指标确实存在curl -fsS http://127.0.0.1:9404/metrics \ | grep -E jmx_exporter_build_info|jvm_memory_pool_bytes_used \ | head出现jmx_exporter_build_info与jvm_memory_pool_bytes_used说明 Agent 正常、指标名与仪表盘预期一致此时再导入JMX仪表盘。4. 为什么必须保留 job 和 instance 标签打开 jmx_by_exporter.json 的var段可以看到两张 JMX 仪表盘的变量定义{ name: job, definition: label_values(jmx_exporter_build_info,job) }, { name: instance, definition: label_values(jmx_exporter_build_info{job\$job\},instance) }仪表盘的所有面板如up{job$job, instance$instance}、jvm_memory_used_bytes{areaheap,job$job,instance$instance}都通过job、instance两个标签筛选数据因此 Categraf 配置中的job静态标签与instance标签必须保留否则下拉框取不到值、面板全部为空。5. JMX 仪表盘包含哪些面板从 JSON 的panels结构看JMX仪表盘按行分组覆盖以下监控面Basic InfoStatusup的 UP/DOWN 映射、Uptimetime() - process_start_time_seconds、Available CPUsos_available_processors、Open file descriptorsos_open_file_descriptor_countJVM Memoryheap 与 nonheap 的jvm_memory_used_bytes、jvm_memory_bytes_maxMemory Pool按 pool 分组展示jvm_memory_pool_bytes_used/committed/max覆盖CodeHeap non-nmethods、CodeHeap profiled nmethods、CodeHeap non-profiled nmethods、Eden、Compressed Class Space、Survivor、Old Gen正则匹配PS Old Gen|G1 Old Gen|Tenured Gen、Metaspace兼容 G1、Parallel 等常见垃圾回收器GC过去一分钟 GC 耗时increase(jvm_gc_collection_seconds_sum[1m])、GC 次数increase(jvm_gc_collection_seconds_count[1m])、每次 GC 平均耗时两者相除Threads and Class loadingjvm_threads_current/daemon/deadlocked、jvm_classes_loaded_totalPhysical memoryos_total_physical_memory_bytes、os_committed_virtual_memory_bytes、os_free_physical_memory_bytes。6. Kubernetes 场景JMX - Kubernetes 仪表盘如果 Java 服务运行在 Kubernetes 中应使用 jmx_by_kubernetes.json。从该文件var段可以看到它的变量体系不同{ name: namespace, definition: label_values(jmx_exporter_build_info, namespace) }, { name: service, definition: label_values(jmx_exporter_build_info{namespace\$namespace\},container) }, { name: pod, definition: label_values(jmx_exporter_build_info{namespace\$namespace\, container\$service\},pod) }面板查询相应改为up{namespace$namespace, container$service, pod$pod}、jvm_memory_used_bytes{namespace$namespace, container$service, pod$pod}等并额外引入container_spec_cpu_quota、container_file_descriptors这类容器维度指标。这意味着采集端如 Kubelet / cadvisor 或带namespace/container/pod标签的抓取方式必须补齐这三类标签仪表盘才能工作。链路二OpenTelemetry Java AgentOpenTelemetry Java Agent 通过字节码注入自动采集 JVM 运行时指标并按照 OTel 语义约定命名与 JMX Exporter 的命名风格jvm_memory_pool_bytes_used等完全不同。文档记录的实机验证环境为OpenTelemetry Java Agent 2.28.1、OTLP gRPC 协议、OTel Collector 中转。1. 通过环境变量启动 Java 进程export JAVA_TOOL_OPTIONS-javaagent:/opt/opentelemetry-javaagent.jar export OTEL_SERVICE_NAMEorder-service export OTEL_EXPORTER_OTLP_ENDPOINThttp://otel-collector:4317 export OTEL_EXPORTER_OTLP_PROTOCOLgrpc export OTEL_METRICS_EXPORTERotlp java -jar app.jar环境变量说明JAVA_TOOL_OPTIONSJVM 启动时自动附加 agent-javaagent路径需替换为你实际存放 jar 的位置OTEL_SERVICE_NAME服务名会作为service.name资源属性上报OTEL_EXPORTER_OTLP_ENDPOINTOTLP 上报地址此处指向 OTel Collector 的 gRPC 端口4317OTEL_EXPORTER_OTLP_PROTOCOL传输协议固定为grpcOTEL_METRICS_EXPORTER只启用otlp指标导出如同时需要 trace可追加逗号分隔的其他 exporter。2. OTel Collector 最小配置把 OTLP 转成 Prometheus新建otel-collector.yamlreceivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 processors: batch: {} exporters: prometheus: endpoint: 0.0.0.0:9464 service: pipelines: metrics: receivers: [otlp] processors: [batch] exporters: [prometheus]链路为Java Agent → OTLP gRPC4317→ Collectorbatch处理器 → Prometheus exporter9464。Collector 的 Prometheus exporter 会把 OTel 指标转写为 Prometheus 文本格式供 Categraf 抓取。3. Categraf 抓取 Collector# conf/input.prometheus/java-otel.toml [[instances]] urls [http://otel-collector:9464/metrics] url_label_key instance url_label_value {{.Host}} labels { job java-otel }注意此处urls指向的是OTel Collector 的 9464 端口而不是 Java 进程本身。4. 验证 OTel 指标后再导入仪表盘抓取前先确认目标指标存在curl -fsS http://otel-collector:9464/metrics \ | grep -E jvm_memory_used_bytes|jvm_gc_duration_seconds \ | headJVM by OpenTelemetry仪表盘jvm_by_opentelementry.json依赖的指标与 JMX 版本有明显差异从面板查询可以归纳出CPUjvm_cpu_count、jvm_cpu_recent_utilization_ratio瞬时使用率乘 100 归一化为百分比、jvm_cpu_time_seconds_total增量计算的平均使用率内存jvm_memory_used_bytes、jvm_memory_committed_bytes、jvm_memory_limit_bytes、jvm_memory_used_after_last_gc_bytes且用jvm_memory_typeheap|non_heap区分堆内外用{{jvm_memory_pool_name}}做 legend 区分内存池GCjvm_gc_duration_seconds_sum/count的 1 分钟增量以及histogram_quantile(0.95, ...)计算的单次 GC 耗时 P95legend 使用{{jvm_gc_action}}、{{jvm_gc_name}}线程与类加载jvm_thread_count按jvm_thread_daemon、jvm_thread_state分组、jvm_class_count、jvm_class_loaded_total、jvm_class_unloaded_total。该仪表盘的变量定义同样基于指标反查job来自label_values(jvm_class_count, job)instance来自label_values(jvm_class_count{job$job}, instance)。因此 OTel 链路的 Categraf 配置同样必须保留job与instance标签。目录下的 i18n/en_US.json 还说明这些面板文案如上次 GC 后 Heap 使用率过去 1 分钟单次 GC 耗时 95 分位值均按 OpenTelemetry JVM 语义约定命名与仪表盘指标一一对应。指标命名差异与选型建议文档末尾特别强调Micrometer、JMX Exporter 和 OTel Java Agent 的指标命名不同应选择与采集链路对应的模板。三者典型差异如下采集方式内存示例GC 示例适用模板Prometheus JMX Exporterjvm_memory_pool_bytes_usedjvm_gc_collection_seconds_*JMX/JMX - KubernetesOpenTelemetry Java Agentjvm_memory_used_bytes{jvm_memory_typeheap}jvm_gc_duration_seconds_*JVM by OpenTelemetryMicrometerSpring Boot Actuator 等jvm_memory.used等 Micrometer 命名jvm_gc.pause等需另找对应模板不可直接套用因此落地时的推荐流程是确认 Java 进程实际使用的采集组件JMX Exporter / OTel Java Agent / Micrometer三种并存时尤其要区分清楚按对应链路完成 Agent 或 Collector 部署并配置 Categrafinput.prometheus抓取用curl验证关键指标名与job、instanceK8s 场景为namespace、container、pod标签齐全最后再导入与指标族匹配的仪表盘 JSON导入后通过变量下拉框确认能列出目标 job/instance面板即可出数。仓库中三张仪表盘 jmx_by_exporter.json、jmx_by_kubernetes.json、jvm_by_opentelementry.json 均以 Prometheus 为数据源面板中datasourceCate为prometheus通过${prom}变量引用导入时选择对应的 Prometheus 数据源即可直接使用无需修改面板表达式。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nightingale 集成指南：Java/JVM 监控仪表盘（JMX Exporter 与 OpenTelemetry 双采集链路）
Nightingale 集成指南Java/JVM 监控仪表盘JMX Exporter 与 OpenTelemetry 双采集链路【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleNightingale 的integrations/Java目录为 Java 应用提供了一组可直接导入的 Prometheus 数据源 JVM 仪表盘覆盖堆内存、内存池、GC、线程、类加载、进程与物理内存等核心指标。本指南以该目录下的 README 为核心完整讲解「Prometheus JMX Exporter」与「OpenTelemetry Java Agent」两条采集链路的部署步骤、Categraf 抓取配置、指标验证方法并结合仓库内的仪表盘 JSON 与国际化文件说明每张仪表盘依赖的指标族与标签约束。读完本文你可以独立完成 Java 进程的指标采集、验证与仪表盘导入。两类仪表盘两套指标族不能混用目录 integrations/Java/dashboards 下共存放三张仪表盘按采集方式分为两类指标命名完全不同仪表盘文件采集方式关键指标jmx_by_exporter.jsonJMXPrometheus JMX Exporterjmx_exporter_build_info、jvm_memory_*、jvm_gc_collection_seconds_*jmx_by_kubernetes.jsonJMX - KubernetesPrometheus JMX ExporterK8s 标签体系同上但使用namespace/container/pod标签jvm_by_opentelementry.jsonJVM by OpenTelemetryOpenTelemetry Java Agent → OTel Collectorjvm_cpu_count、jvm_memory_used_bytes、jvm_gc_duration_seconds_*等 OTel 命名由于两种链路产出的指标名与标签结构不同混用会导致面板查询无数据。选择仪表盘之前必须先确认线上 Java 进程实际使用的是哪条采集链路。链路一Prometheus JMX ExporterJMX Exporter 是 Prometheus 官方维护的 Java Agent通过 JMXJava Management Extensions读取 JVM 运行时数据并以/metrics暴露。1. 为 Java 进程加载 Agent 并监听端口以 9404 端口为例启动命令大致为java -javaagent:/opt/jmx_prometheus_javaagent.jar9404:/opt/config.yaml -jar app.jar参数含义-javaagent指定 agent 包路径9404:config.yaml表示监听 9404 端口并使用指定的 JMX 抓取规则配置文件。Agent 启动后http://127.0.0.1:9404/metrics即为 Prometheus 格式的指标端点。2. 新建 Categraf 抓取配置在 Categraf 的conf/input.prometheus/目录下新建java-jmx.toml内容如下# conf/input.prometheus/java-jmx.toml [[instances]] urls [http://127.0.0.1:9404/metrics] url_label_key instance url_label_value {{.Host}} labels { job order-service }各字段作用urlsJMX Exporter 暴露的指标地址抓取后会为每条时序自动附加instance标签url_label_key/url_label_value指定标签名与取值{{.Host}}会替换为目标主机名labels附加的静态标签这里用job order-service标识业务服务。3. 先验证再导入仪表盘配置完成后先确认指标确实存在curl -fsS http://127.0.0.1:9404/metrics \ | grep -E jmx_exporter_build_info|jvm_memory_pool_bytes_used \ | head出现jmx_exporter_build_info与jvm_memory_pool_bytes_used说明 Agent 正常、指标名与仪表盘预期一致此时再导入JMX仪表盘。4. 为什么必须保留 job 和 instance 标签打开 jmx_by_exporter.json 的var段可以看到两张 JMX 仪表盘的变量定义{ name: job, definition: label_values(jmx_exporter_build_info,job) }, { name: instance, definition: label_values(jmx_exporter_build_info{job\$job\},instance) }仪表盘的所有面板如up{job$job, instance$instance}、jvm_memory_used_bytes{areaheap,job$job,instance$instance}都通过job、instance两个标签筛选数据因此 Categraf 配置中的job静态标签与instance标签必须保留否则下拉框取不到值、面板全部为空。5. JMX 仪表盘包含哪些面板从 JSON 的panels结构看JMX仪表盘按行分组覆盖以下监控面Basic InfoStatusup的 UP/DOWN 映射、Uptimetime() - process_start_time_seconds、Available CPUsos_available_processors、Open file descriptorsos_open_file_descriptor_countJVM Memoryheap 与 nonheap 的jvm_memory_used_bytes、jvm_memory_bytes_maxMemory Pool按 pool 分组展示jvm_memory_pool_bytes_used/committed/max覆盖CodeHeap non-nmethods、CodeHeap profiled nmethods、CodeHeap non-profiled nmethods、Eden、Compressed Class Space、Survivor、Old Gen正则匹配PS Old Gen|G1 Old Gen|Tenured Gen、Metaspace兼容 G1、Parallel 等常见垃圾回收器GC过去一分钟 GC 耗时increase(jvm_gc_collection_seconds_sum[1m])、GC 次数increase(jvm_gc_collection_seconds_count[1m])、每次 GC 平均耗时两者相除Threads and Class loadingjvm_threads_current/daemon/deadlocked、jvm_classes_loaded_totalPhysical memoryos_total_physical_memory_bytes、os_committed_virtual_memory_bytes、os_free_physical_memory_bytes。6. Kubernetes 场景JMX - Kubernetes 仪表盘如果 Java 服务运行在 Kubernetes 中应使用 jmx_by_kubernetes.json。从该文件var段可以看到它的变量体系不同{ name: namespace, definition: label_values(jmx_exporter_build_info, namespace) }, { name: service, definition: label_values(jmx_exporter_build_info{namespace\$namespace\},container) }, { name: pod, definition: label_values(jmx_exporter_build_info{namespace\$namespace\, container\$service\},pod) }面板查询相应改为up{namespace$namespace, container$service, pod$pod}、jvm_memory_used_bytes{namespace$namespace, container$service, pod$pod}等并额外引入container_spec_cpu_quota、container_file_descriptors这类容器维度指标。这意味着采集端如 Kubelet / cadvisor 或带namespace/container/pod标签的抓取方式必须补齐这三类标签仪表盘才能工作。链路二OpenTelemetry Java AgentOpenTelemetry Java Agent 通过字节码注入自动采集 JVM 运行时指标并按照 OTel 语义约定命名与 JMX Exporter 的命名风格jvm_memory_pool_bytes_used等完全不同。文档记录的实机验证环境为OpenTelemetry Java Agent 2.28.1、OTLP gRPC 协议、OTel Collector 中转。1. 通过环境变量启动 Java 进程export JAVA_TOOL_OPTIONS-javaagent:/opt/opentelemetry-javaagent.jar export OTEL_SERVICE_NAMEorder-service export OTEL_EXPORTER_OTLP_ENDPOINThttp://otel-collector:4317 export OTEL_EXPORTER_OTLP_PROTOCOLgrpc export OTEL_METRICS_EXPORTERotlp java -jar app.jar环境变量说明JAVA_TOOL_OPTIONSJVM 启动时自动附加 agent-javaagent路径需替换为你实际存放 jar 的位置OTEL_SERVICE_NAME服务名会作为service.name资源属性上报OTEL_EXPORTER_OTLP_ENDPOINTOTLP 上报地址此处指向 OTel Collector 的 gRPC 端口4317OTEL_EXPORTER_OTLP_PROTOCOL传输协议固定为grpcOTEL_METRICS_EXPORTER只启用otlp指标导出如同时需要 trace可追加逗号分隔的其他 exporter。2. OTel Collector 最小配置把 OTLP 转成 Prometheus新建otel-collector.yamlreceivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 processors: batch: {} exporters: prometheus: endpoint: 0.0.0.0:9464 service: pipelines: metrics: receivers: [otlp] processors: [batch] exporters: [prometheus]链路为Java Agent → OTLP gRPC4317→ Collectorbatch处理器 → Prometheus exporter9464。Collector 的 Prometheus exporter 会把 OTel 指标转写为 Prometheus 文本格式供 Categraf 抓取。3. Categraf 抓取 Collector# conf/input.prometheus/java-otel.toml [[instances]] urls [http://otel-collector:9464/metrics] url_label_key instance url_label_value {{.Host}} labels { job java-otel }注意此处urls指向的是OTel Collector 的 9464 端口而不是 Java 进程本身。4. 验证 OTel 指标后再导入仪表盘抓取前先确认目标指标存在curl -fsS http://otel-collector:9464/metrics \ | grep -E jvm_memory_used_bytes|jvm_gc_duration_seconds \ | headJVM by OpenTelemetry仪表盘jvm_by_opentelementry.json依赖的指标与 JMX 版本有明显差异从面板查询可以归纳出CPUjvm_cpu_count、jvm_cpu_recent_utilization_ratio瞬时使用率乘 100 归一化为百分比、jvm_cpu_time_seconds_total增量计算的平均使用率内存jvm_memory_used_bytes、jvm_memory_committed_bytes、jvm_memory_limit_bytes、jvm_memory_used_after_last_gc_bytes且用jvm_memory_typeheap|non_heap区分堆内外用{{jvm_memory_pool_name}}做 legend 区分内存池GCjvm_gc_duration_seconds_sum/count的 1 分钟增量以及histogram_quantile(0.95, ...)计算的单次 GC 耗时 P95legend 使用{{jvm_gc_action}}、{{jvm_gc_name}}线程与类加载jvm_thread_count按jvm_thread_daemon、jvm_thread_state分组、jvm_class_count、jvm_class_loaded_total、jvm_class_unloaded_total。该仪表盘的变量定义同样基于指标反查job来自label_values(jvm_class_count, job)instance来自label_values(jvm_class_count{job$job}, instance)。因此 OTel 链路的 Categraf 配置同样必须保留job与instance标签。目录下的 i18n/en_US.json 还说明这些面板文案如上次 GC 后 Heap 使用率过去 1 分钟单次 GC 耗时 95 分位值均按 OpenTelemetry JVM 语义约定命名与仪表盘指标一一对应。指标命名差异与选型建议文档末尾特别强调Micrometer、JMX Exporter 和 OTel Java Agent 的指标命名不同应选择与采集链路对应的模板。三者典型差异如下采集方式内存示例GC 示例适用模板Prometheus JMX Exporterjvm_memory_pool_bytes_usedjvm_gc_collection_seconds_*JMX/JMX - KubernetesOpenTelemetry Java Agentjvm_memory_used_bytes{jvm_memory_typeheap}jvm_gc_duration_seconds_*JVM by OpenTelemetryMicrometerSpring Boot Actuator 等jvm_memory.used等 Micrometer 命名jvm_gc.pause等需另找对应模板不可直接套用因此落地时的推荐流程是确认 Java 进程实际使用的采集组件JMX Exporter / OTel Java Agent / Micrometer三种并存时尤其要区分清楚按对应链路完成 Agent 或 Collector 部署并配置 Categrafinput.prometheus抓取用curl验证关键指标名与job、instanceK8s 场景为namespace、container、pod标签齐全最后再导入与指标族匹配的仪表盘 JSON导入后通过变量下拉框确认能列出目标 job/instance面板即可出数。仓库中三张仪表盘 jmx_by_exporter.json、jmx_by_kubernetes.json、jvm_by_opentelementry.json 均以 Prometheus 为数据源面板中datasourceCate为prometheus通过${prom}变量引用导入时选择对应的 Prometheus 数据源即可直接使用无需修改面板表达式。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考