Vectorjmx_metrics源设计解读基于 JMX 协议采集 JVM 指标RFC 3642【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector本文是对 Vector 官方设计文档 RFC 36422020-08-28采集 JVM 的 JMX 指标 的完整技术解读。该 RFC 为 Vector 规划了一个名为jmx_metrics的新指标源metrics source用于通过 JMXJava Management Extensions协议直接连接 JVM 进程并采集其运行指标。读完本文你将掌握该源的架构方案、完整的指标清单与命名约定、端到端的 TOML 配置方法以及它与 Prometheus JMX exporter、Telegraf Jolokia 等既有方案的设计取舍。需要说明的是本仓库当前快照中src/sources/尚未出现jmx_metrics的实现全仓库仅此 RFC 提及 jmx因此本文以该设计提案为主体并结合仓库中现有源组件的注册模式与配置惯例做对照解读。背景为什么需要为 Vector 增加 JMX 指标源JVM 是运行现代应用的主流平台之一同时也是 Kafka、Cassandra 等大量基础设施工具的运行时基础。用户的诉求很直接收集、转换并转发指标以便更好地观察基于 JVM 的应用程序的性能表现。而 JMX 正是 Java 平台暴露这些运行指标的标准通道通过 MBean 可以访问堆/非堆内存、GC、线程、类加载、文件描述符、操作系统与运行时信息等数据。RFC 的动机也契合 Vector 自身的定位——one tool一个工具即可完成可观测性数据的采集与转发尽可能多地接入各类数据源降低用户无法从自己使用的工具中摄取指标的概率。从仓库侧看src/sources/mod.rs 中每个源都以 feature flag如sources-prometheus_scrape、sources-host_metrics条件编译注册jmx_metrics若落地也会遵循同样的注册模式。RFC 的范围界定ScopeRFC 将本次变更的范围收敛得非常小仅包含一项内容新增一个用于采集基于 JVM 的指标的新源source通过 JMX 协议实现。其余增强如 MBean 的 accept/deny 过滤、规则化改写引擎均被明确列入未来工作而非本 RFC 范围这也符合 rfcs/README.md 中对 RFC Keep the scope small保持范围小的要求将未来改进显式列入 Scope 之外既让讨论聚焦也让实现更快交付。内部方案jmx_metrics源的总体设计技术选型Rust JMX 客户端直连 JVMRFC 建议构建一个名为jmx_metrics名称待最终确认的单一源推荐实现方式是使用 Rust 的 JMX 客户端按配置中指定的地址连接 JVM 服务器。这意味着用户需要在 JVM 实例上预先配置 JMX并让其绑定到 Vector 可以查询的外部端口。相应的端到端数据流为JVM开启 JMX 远程访问暴露端口 │ JMX/RMI 协议 ▼ jmx_metrics 源Rust JMX 客户端按 endpoint 连接并抓取 │ 解析查询结果转换为 Vector 指标事件 ▼ Vector 管道transform → sink运行模式独立抓取 vs Java AgentRFC 对比了两种主流做法并引用了 Prometheus JMX exporter 的官方说明This exporter is intended to be run as a Java Agent, exposing a HTTP server and serving metrics of the local JVM. It can be also run as an independent HTTP server and scrape remote JMX targets, but this has various disadvantages, such as being harder to configure and being unable to expose process metrics (e.g., memory and CPU usage). Running the exporter as a Java Agent is thus strongly encouraged.要点可归纳为Java Agent 模式agent 随 JVM 进程一起启动作为本地 HTTP server 暴露指标能拿到进程级指标内存、CPU但需要侵入 Java 应用启动参数独立抓取模式Vector 以独立进程身份远程 scrape JMX 目标配置更复杂且拿不到部分进程级指标但无需改动 Java 应用RFC 明确标注这可能需要在推进过程中做一些测试This may require some testing as we proceed并在文末的 Outstanding Questions 中保留了Java agent or not是否采用 Java agent 模式这一待决问题。从仓库现状看Vector 已有一个同类主动抓取型源——src/sources/prometheus/ 下的 Prometheus scrape 源mod.rs其按 endpoint 周期性抓取、解析后产出指标事件的模型与jmx_metrics的设计在架构上同构可作为实现时的参照。完整指标清单默认 JVM 指标全集RFC 给出了通过 JMX 可获取的默认 JVM 指标全集约 118 个并逐个标注了建议的指标类型与标签。这部分是 RFC 的核心资产下面按已明确类型与类型待定untyped两组完整保留。其中untyped的含义是类型尚不明确但很可能是 gauge需要更深入的研究来确定1是否保留这些指标2若保留其确切类型。已明确类型的指标36 个指标名类型标签jmx_up0/1 运行状态用作 uptime 指标—jmx_config_reload_success_totalcounter—jmx_config_reload_failure_totalcounter—jmx_process_cpu_seconds_totalcounter—jmx_process_start_time_secondsgauge—jmx_process_open_fdsgauge—jmx_process_max_fdsgauge—jmx_jvm_threads_currentgauge—jmx_jvm_threads_daemongauge—jmx_jvm_threads_peakgauge—jmx_jvm_threads_started_totalcounter—jmx_jvm_threads_deadlockedgauge—jmx_jvm_threads_deadlocked_monitorgauge—jmx_jvm_threads_stategaugestatejmx_jvm_buffer_pool_used_bytesgaugepooljmx_jvm_buffer_pool_capacity_bytesgaugepooljmx_jvm_buffer_pool_used_buffersgaugepooljmx_jvm_classes_loadedgauge—jmx_jvm_classes_loaded_totalcounter—jmx_jvm_classes_unloaded_totalcounter—jmx_jvm_gc_collection_secondssummarygcjmx_jvm_memory_bytes_usedgaugeareajmx_jvm_memory_bytes_committedgaugeareajmx_jvm_memory_bytes_maxgaugeareajmx_jvm_memory_bytes_initgaugeareajmx_jvm_memory_pool_bytes_usedgaugepooljmx_jvm_memory_pool_bytes_committedgaugepooljmx_jvm_memory_pool_bytes_maxgaugepooljmx_jvm_memory_pool_bytes_initgaugepooljmx_jvm_memory_pool_allocated_bytes_totalcounterpooljmx_jvm_infogaugeversion、vendor、runtimejmx_java_lang_MemoryPool_UsageThresholdSupportedgaugenamejmx_java_lang_Threading_ThreadContentionMonitoringEnabledgauge—jmx_java_lang_OperatingSystem_CommittedVirtualMemorySizegauge—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_usedcounter?name、keyjmx_java_lang_Threading_ThreadContentionMonitoringSupportedgauge—其中两个指标类型仍标注了 TBD待定jmx_java_lang_Memory_HeapMemoryUsage_committedmaybe gauge? TBDjmx_java_lang_OperatingSystem_TotalSwapSpaceSizemaybe gauge? TBD类型待定untyped的指标82 个下表完整保留 RFC 中所有untyped指标及其标签约定指标名标签jmx_java_lang_MemoryPool_CollectionUsage_maxnamejmx_java_lang_Runtime_StartTime—jmx_java_lang_GarbageCollector_LastGcInfo_endTimenamejmx_java_lang_Memory_HeapMemoryUsage_max—jmx_java_lang_MemoryPool_UsageThresholdnamejmx_java_lang_MemoryPool_CollectionUsageThresholdCountnamejmx_java_lang_Memory_NonHeapMemoryUsage_used—jmx_java_lang_Threading_PeakThreadCount—jmx_java_lang_MemoryPool_PeakUsage_usednamejmx_java_lang_ClassLoading_TotalLoadedClassCount—jmx_java_lang_OperatingSystem_MaxFileDescriptorCount—jmx_java_lang_ClassLoading_Verbose—jmx_java_lang_GarbageCollector_LastGcInfo_idnamejmx_java_lang_Threading_CurrentThreadUserTime—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_committedname、keyjmx_java_lang_Threading_ThreadCount—jmx_java_lang_MemoryPool_PeakUsage_committednamejmx_java_lang_Memory_ObjectPendingFinalizationCount—jmx_java_lang_MemoryPool_Usage_usednamejmx_java_lang_GarbageCollector_CollectionCountnamejmx_java_lang_Threading_SynchronizerUsageSupported—jmx_java_lang_Runtime_BootClassPathSupported—jmx_java_nio_BufferPool_Countnamejmx_java_lang_GarbageCollector_LastGcInfo_GcThreadCountnamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_committedname、keyjmx_java_lang_Threading_CurrentThreadCpuTimeSupported—jmx_java_lang_ClassLoading_LoadedClassCount—jmx_java_lang_MemoryPool_CollectionUsage_initnamejmx_java_lang_MemoryPool_PeakUsage_maxnamejmx_java_lang_MemoryPool_Usage_maxnamejmx_java_lang_GarbageCollector_Validnamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_usedname、keyjmx_java_lang_Threading_ThreadAllocatedMemoryEnabled—jmx_java_lang_MemoryManager_Validnamejmx_java_lang_MemoryPool_Usage_initnamejmx_java_lang_OperatingSystem_ProcessCpuLoad—jmx_java_lang_MemoryPool_CollectionUsage_committednamejmx_java_lang_OperatingSystem_TotalPhysicalMemorySize—jmx_java_lang_Memory_NonHeapMemoryUsage_committed—jmx_java_lang_Compilation_TotalCompilationTime—jmx_java_lang_Memory_Verbose—jmx_java_lang_MemoryPool_Validnamejmx_java_lang_OperatingSystem_FreeSwapSpaceSize—jmx_java_lang_MemoryPool_UsageThresholdExceedednamejmx_java_lang_Threading_CurrentThreadCpuTime—jmx_java_lang_MemoryPool_CollectionUsageThresholdnamejmx_java_lang_GarbageCollector_CollectionTimenamejmx_java_lang_Compilation_CompilationTimeMonitoringSupported—jmx_java_lang_MemoryPool_Usage_committednamejmx_java_lang_Memory_NonHeapMemoryUsage_init—jmx_java_lang_MemoryPool_PeakUsage_initnamejmx_java_lang_GarbageCollector_LastGcInfo_startTimenamejmx_java_lang_OperatingSystem_AvailableProcessors—jmx_java_lang_MemoryPool_CollectionUsageThresholdSupportednamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_maxname、keyjmx_java_lang_ClassLoading_UnloadedClassCount—jmx_java_nio_BufferPool_MemoryUsednamejmx_java_nio_BufferPool_TotalCapacitynamejmx_java_lang_Memory_HeapMemoryUsage_used—jmx_java_lang_MemoryPool_CollectionUsage_usednamejmx_java_lang_Memory_HeapMemoryUsage_init—jmx_java_lang_OperatingSystem_SystemCpuLoad—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_initname、keysjmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_initname、keyjmx_java_lang_Threading_ThreadAllocatedMemorySupported—jmx_java_lang_Memory_NonHeapMemoryUsage_max—jmx_java_lang_Threading_DaemonThreadCount—jmx_java_lang_Threading_ThreadCpuTimeSupported—jmx_java_lang_OperatingSystem_SystemLoadAverage—jmx_java_lang_Threading_TotalStartedThreadCount—jmx_java_lang_OperatingSystem_ProcessCpuTime—jmx_java_lang_OperatingSystem_FreePhysicalMemorySize—jmx_java_lang_Runtime_Uptime—jmx_java_lang_MemoryPool_CollectionUsageThresholdExceedednamejmx_java_lang_GarbageCollector_LastGcInfo_durationnamejmx_java_lang_Threading_ObjectMonitorUsageSupported—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_maxname、keyjmx_java_lang_MemoryPool_UsageThresholdCountnamejmx_java_lang_Threading_ThreadCpuTimeEnabled—jmx_java_lang_OperatingSystem_OpenFileDescriptorCount—指标命名与标签规范RFC 明确了三条命名与标签规则命名规则jmx_ 指标名jmx _ metric_name与 JMX 内部命名保持一致通用标签所有指标都会被打上endpoint和host两个标签用于区分采集来源维度标签凡是带多实例的 MBean如各 MemoryPool、各 GarbageCollector、各 BufferPool以pool、area、name、gc、state、key等标签区分维度例如jmx_jvm_memory_bytes_used{areaheap}与jmx_jvm_memory_pool_bytes_used{poolG1 Eden Space}。此外 RFC 特别指出上述清单只是默认 JVM 可通过 JMX 暴露的指标。具体应用Kafka、Cassandra、Tomcat 等会暴露各自专属的 MBean 和指标实现时可以像 Prometheus jmx_exporter 的 JmxScraper 那样逐个遍历 MBean 并解析其输出进而构造并返回指标。Prometheus exporter 中针对特定 MBean 对象的 accept/deny 模式以及用于匹配并构造特定指标的规则化改写引擎都被 RFC 视为合理但属后续的工作项——RFC 同时提出一个开放问题这类过滤与改写是否用 Vector 的 transform 来实现可能更有效配置示例Doc-level ProposalRFC 为jmx_metrics源规划了如下配置结构完整保留原文示例[sources.my_source_id] type jmx_metrics # required endpoint service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmi # required - address of the JMX webserver to scrape. username user # optional - username for any JMX authentication. password password # optional - password for any JMX authentication. scrape_interval_secs 15 # optional, default, seconds namespace jmx # optional, default is jmx, namespace to put metrics under各字段的含义与默认值归纳如下字段必填默认值说明type是—固定为jmx_metricsRFC 撰写时名称待最终确认endpoint是—要抓取的 JMX 服务地址典型形式为service:jmx:rmi:///jndi/rmi://host:port/jmxrmi即标准 JMX RMI 连接 URLusername否—JMX 认证用户名若 JVM 开启了 JMX 认证password否—JMX 认证密码与username配合使用scrape_interval_secs否15抓取间隔单位秒控制指标采集的周期namespace否jmx指标所属的命名空间namespace用于将指标归类放置RFC 还补充后续应增加一份带认证authentication的配置指南帮助用户在使用 JMX 用户名/密码认证的场景下完成端到端配置。关于namespace字段仓库中已有可对照的既有实现惯例例如 src/sources/static_metrics.rs 中的namespace配置同样带有默认值默认static并在构造指标事件时通过namespace: Some(self.namespace.clone())注入。可以推断jmx_metrics的namespace落地后会走相似的 serde 反序列化与默认值逻辑。设计权衡Rationale、Drawbacks 与 Alternatives为什么值得做RationaleJVM 是运行应用的流行平台也是 Kafka、Cassandra 等基础设施工具的运行时基础用户经常需要理解它的性能。同时作为 Vector 愿景one tool 摄取并转发可观测性数据的一部分尽可能多地增加数据源可以减少用户无法从自身工具摄取指标的概率。代价Drawbacks新增一个源带来的主要代价是额外的维护与集成测试负担——这也是每个新源组件都需要面对的成本。被否决的替代方案AlternativesRFC 认真评估了两条不新增源的替代路线借道 Prometheus jmx_exporter / Telegraf让用户自行运行 Telegraf 或 Prometheus 的 jmx_exporter再让 Vector 用现有的 Prometheus 源去抓取这些数据借道 jmxtrans使用 jmxtrans 之类的工具并为 Vector 编写一个 OutputWriter 插件。RFC 作者最终否决了这两条路线理由是它们与 Vector 的核心原则相冲突One Tool. All Data. - One simple tool gets your logs, metrics, and traces (coming soon) from A to B.即一个工具全部数据一个简单工具即可把日志、指标以及即将支持的追踪从 A 点送到 B 点。不过 RFC 也保留了灵活性如果用户已经在运行 Prometheus完全可以走 Prometheus 那条路径——这与仓库中现有的 src/sources/prometheus/ 源scrape / remote_write / pushgateway 三种模式见 mod.rs天然衔接。业界已有实践Prior ArtRFC 调研了当时业界的 JMX 指标采集方案作为设计参考此处仅列名称详见原 RFCPrometheus jmx_exporterJava Agent 或独立 HTTP server 形式自带维护的 agentTelegraf jolokia 与 jolokia2通过 Jolokia agent 进行采集collectd GenericJMX 插件collectd 生态的通用 JMX 采集方案panopticon-tuiScala 生态的相关实现replicante-io agents 中的 kafka agent面向 Kafka 的 agent 实现。其中 Prometheus 与 Telegraf 方案均依赖 Java 侧 agentPrometheus 使用自维护 agentTelegraf 使用 Jolokia agent这也呼应了前文Java agent or not这一待决问题。待决问题与实施计划Outstanding Questions待决问题RFC 明确遗留的唯一关键问题是否采用 Java agent 模式Java agent or not。该决定将直接影响用户侧的使用方式是给 JVM 加启动参数还是仅配置 Vector 的 endpoint 远程抓取以及进程级指标的可得性。Plan Of Attack攻击计划与 Future Work未来工作实施以增量步骤推进首要一步是提交包含初始源实现的 PRSubmit a PR with the initial source implementation计划中的未来工作包括accept/deny 列表针对 MBean 对象模式的过滤列表用于控制采集哪些 MBean规则化改写引擎用于匹配并构造特定指标的规则化引擎对标 Prometheus jmx_exporter 的配置化能力。结合仓库现状这类源在 Vector 中如何落地虽然jmx_metrics在本仓库快照中尚未实现但从仓库现有结构可以清晰推断其落地路径源注册模式src/sources/mod.rs 展示了所有源的注册方式——以#[cfg(feature sources-xxx)]特性开关声明模块jmx_metrics落地时会以sources-jmx_metrics之类的 feature 出现在其中并配套在根 Cargo.toml 中声明依赖抓取型源参照src/sources/prometheus/ 的 scrape 实现周期性按 endpoint 抓取、解析文本、产出带 namespace 的指标事件是jmx_metrics最接近的架构参照配置惯例参照src/sources/static_metrics.rs 中的namespace默认值与指标事件构造逻辑为 RFC 中namespace jmx的默认值设计提供了现成的实现范式流程背景本 RFC 位于仓库的 rfcs/ 目录遵循 rfcs/README.md 所描述的 Vector RFC 流程——先以文档形式达成共识再进入实施阶段这解释了为什么该设计文档先行于实现存在。对于希望在生产环境中采集 JVM 指标的读者在jmx_metrics落地之前最务实的路径正是 RFC 在 Alternatives 中给出的方案为 JVM 部署 Prometheus jmx_exporter或 Jolokia再通过 Vector 现有的 Prometheus scrape 源将指标纳入统一管道。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vector `jmx_metrics` 源设计解读：基于 JMX 协议采集 JVM 指标（RFC 3642）
Vectorjmx_metrics源设计解读基于 JMX 协议采集 JVM 指标RFC 3642【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector本文是对 Vector 官方设计文档 RFC 36422020-08-28采集 JVM 的 JMX 指标 的完整技术解读。该 RFC 为 Vector 规划了一个名为jmx_metrics的新指标源metrics source用于通过 JMXJava Management Extensions协议直接连接 JVM 进程并采集其运行指标。读完本文你将掌握该源的架构方案、完整的指标清单与命名约定、端到端的 TOML 配置方法以及它与 Prometheus JMX exporter、Telegraf Jolokia 等既有方案的设计取舍。需要说明的是本仓库当前快照中src/sources/尚未出现jmx_metrics的实现全仓库仅此 RFC 提及 jmx因此本文以该设计提案为主体并结合仓库中现有源组件的注册模式与配置惯例做对照解读。背景为什么需要为 Vector 增加 JMX 指标源JVM 是运行现代应用的主流平台之一同时也是 Kafka、Cassandra 等大量基础设施工具的运行时基础。用户的诉求很直接收集、转换并转发指标以便更好地观察基于 JVM 的应用程序的性能表现。而 JMX 正是 Java 平台暴露这些运行指标的标准通道通过 MBean 可以访问堆/非堆内存、GC、线程、类加载、文件描述符、操作系统与运行时信息等数据。RFC 的动机也契合 Vector 自身的定位——one tool一个工具即可完成可观测性数据的采集与转发尽可能多地接入各类数据源降低用户无法从自己使用的工具中摄取指标的概率。从仓库侧看src/sources/mod.rs 中每个源都以 feature flag如sources-prometheus_scrape、sources-host_metrics条件编译注册jmx_metrics若落地也会遵循同样的注册模式。RFC 的范围界定ScopeRFC 将本次变更的范围收敛得非常小仅包含一项内容新增一个用于采集基于 JVM 的指标的新源source通过 JMX 协议实现。其余增强如 MBean 的 accept/deny 过滤、规则化改写引擎均被明确列入未来工作而非本 RFC 范围这也符合 rfcs/README.md 中对 RFC Keep the scope small保持范围小的要求将未来改进显式列入 Scope 之外既让讨论聚焦也让实现更快交付。内部方案jmx_metrics源的总体设计技术选型Rust JMX 客户端直连 JVMRFC 建议构建一个名为jmx_metrics名称待最终确认的单一源推荐实现方式是使用 Rust 的 JMX 客户端按配置中指定的地址连接 JVM 服务器。这意味着用户需要在 JVM 实例上预先配置 JMX并让其绑定到 Vector 可以查询的外部端口。相应的端到端数据流为JVM开启 JMX 远程访问暴露端口 │ JMX/RMI 协议 ▼ jmx_metrics 源Rust JMX 客户端按 endpoint 连接并抓取 │ 解析查询结果转换为 Vector 指标事件 ▼ Vector 管道transform → sink运行模式独立抓取 vs Java AgentRFC 对比了两种主流做法并引用了 Prometheus JMX exporter 的官方说明This exporter is intended to be run as a Java Agent, exposing a HTTP server and serving metrics of the local JVM. It can be also run as an independent HTTP server and scrape remote JMX targets, but this has various disadvantages, such as being harder to configure and being unable to expose process metrics (e.g., memory and CPU usage). Running the exporter as a Java Agent is thus strongly encouraged.要点可归纳为Java Agent 模式agent 随 JVM 进程一起启动作为本地 HTTP server 暴露指标能拿到进程级指标内存、CPU但需要侵入 Java 应用启动参数独立抓取模式Vector 以独立进程身份远程 scrape JMX 目标配置更复杂且拿不到部分进程级指标但无需改动 Java 应用RFC 明确标注这可能需要在推进过程中做一些测试This may require some testing as we proceed并在文末的 Outstanding Questions 中保留了Java agent or not是否采用 Java agent 模式这一待决问题。从仓库现状看Vector 已有一个同类主动抓取型源——src/sources/prometheus/ 下的 Prometheus scrape 源mod.rs其按 endpoint 周期性抓取、解析后产出指标事件的模型与jmx_metrics的设计在架构上同构可作为实现时的参照。完整指标清单默认 JVM 指标全集RFC 给出了通过 JMX 可获取的默认 JVM 指标全集约 118 个并逐个标注了建议的指标类型与标签。这部分是 RFC 的核心资产下面按已明确类型与类型待定untyped两组完整保留。其中untyped的含义是类型尚不明确但很可能是 gauge需要更深入的研究来确定1是否保留这些指标2若保留其确切类型。已明确类型的指标36 个指标名类型标签jmx_up0/1 运行状态用作 uptime 指标—jmx_config_reload_success_totalcounter—jmx_config_reload_failure_totalcounter—jmx_process_cpu_seconds_totalcounter—jmx_process_start_time_secondsgauge—jmx_process_open_fdsgauge—jmx_process_max_fdsgauge—jmx_jvm_threads_currentgauge—jmx_jvm_threads_daemongauge—jmx_jvm_threads_peakgauge—jmx_jvm_threads_started_totalcounter—jmx_jvm_threads_deadlockedgauge—jmx_jvm_threads_deadlocked_monitorgauge—jmx_jvm_threads_stategaugestatejmx_jvm_buffer_pool_used_bytesgaugepooljmx_jvm_buffer_pool_capacity_bytesgaugepooljmx_jvm_buffer_pool_used_buffersgaugepooljmx_jvm_classes_loadedgauge—jmx_jvm_classes_loaded_totalcounter—jmx_jvm_classes_unloaded_totalcounter—jmx_jvm_gc_collection_secondssummarygcjmx_jvm_memory_bytes_usedgaugeareajmx_jvm_memory_bytes_committedgaugeareajmx_jvm_memory_bytes_maxgaugeareajmx_jvm_memory_bytes_initgaugeareajmx_jvm_memory_pool_bytes_usedgaugepooljmx_jvm_memory_pool_bytes_committedgaugepooljmx_jvm_memory_pool_bytes_maxgaugepooljmx_jvm_memory_pool_bytes_initgaugepooljmx_jvm_memory_pool_allocated_bytes_totalcounterpooljmx_jvm_infogaugeversion、vendor、runtimejmx_java_lang_MemoryPool_UsageThresholdSupportedgaugenamejmx_java_lang_Threading_ThreadContentionMonitoringEnabledgauge—jmx_java_lang_OperatingSystem_CommittedVirtualMemorySizegauge—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_usedcounter?name、keyjmx_java_lang_Threading_ThreadContentionMonitoringSupportedgauge—其中两个指标类型仍标注了 TBD待定jmx_java_lang_Memory_HeapMemoryUsage_committedmaybe gauge? TBDjmx_java_lang_OperatingSystem_TotalSwapSpaceSizemaybe gauge? TBD类型待定untyped的指标82 个下表完整保留 RFC 中所有untyped指标及其标签约定指标名标签jmx_java_lang_MemoryPool_CollectionUsage_maxnamejmx_java_lang_Runtime_StartTime—jmx_java_lang_GarbageCollector_LastGcInfo_endTimenamejmx_java_lang_Memory_HeapMemoryUsage_max—jmx_java_lang_MemoryPool_UsageThresholdnamejmx_java_lang_MemoryPool_CollectionUsageThresholdCountnamejmx_java_lang_Memory_NonHeapMemoryUsage_used—jmx_java_lang_Threading_PeakThreadCount—jmx_java_lang_MemoryPool_PeakUsage_usednamejmx_java_lang_ClassLoading_TotalLoadedClassCount—jmx_java_lang_OperatingSystem_MaxFileDescriptorCount—jmx_java_lang_ClassLoading_Verbose—jmx_java_lang_GarbageCollector_LastGcInfo_idnamejmx_java_lang_Threading_CurrentThreadUserTime—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_committedname、keyjmx_java_lang_Threading_ThreadCount—jmx_java_lang_MemoryPool_PeakUsage_committednamejmx_java_lang_Memory_ObjectPendingFinalizationCount—jmx_java_lang_MemoryPool_Usage_usednamejmx_java_lang_GarbageCollector_CollectionCountnamejmx_java_lang_Threading_SynchronizerUsageSupported—jmx_java_lang_Runtime_BootClassPathSupported—jmx_java_nio_BufferPool_Countnamejmx_java_lang_GarbageCollector_LastGcInfo_GcThreadCountnamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_committedname、keyjmx_java_lang_Threading_CurrentThreadCpuTimeSupported—jmx_java_lang_ClassLoading_LoadedClassCount—jmx_java_lang_MemoryPool_CollectionUsage_initnamejmx_java_lang_MemoryPool_PeakUsage_maxnamejmx_java_lang_MemoryPool_Usage_maxnamejmx_java_lang_GarbageCollector_Validnamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_usedname、keyjmx_java_lang_Threading_ThreadAllocatedMemoryEnabled—jmx_java_lang_MemoryManager_Validnamejmx_java_lang_MemoryPool_Usage_initnamejmx_java_lang_OperatingSystem_ProcessCpuLoad—jmx_java_lang_MemoryPool_CollectionUsage_committednamejmx_java_lang_OperatingSystem_TotalPhysicalMemorySize—jmx_java_lang_Memory_NonHeapMemoryUsage_committed—jmx_java_lang_Compilation_TotalCompilationTime—jmx_java_lang_Memory_Verbose—jmx_java_lang_MemoryPool_Validnamejmx_java_lang_OperatingSystem_FreeSwapSpaceSize—jmx_java_lang_MemoryPool_UsageThresholdExceedednamejmx_java_lang_Threading_CurrentThreadCpuTime—jmx_java_lang_MemoryPool_CollectionUsageThresholdnamejmx_java_lang_GarbageCollector_CollectionTimenamejmx_java_lang_Compilation_CompilationTimeMonitoringSupported—jmx_java_lang_MemoryPool_Usage_committednamejmx_java_lang_Memory_NonHeapMemoryUsage_init—jmx_java_lang_MemoryPool_PeakUsage_initnamejmx_java_lang_GarbageCollector_LastGcInfo_startTimenamejmx_java_lang_OperatingSystem_AvailableProcessors—jmx_java_lang_MemoryPool_CollectionUsageThresholdSupportednamejmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_maxname、keyjmx_java_lang_ClassLoading_UnloadedClassCount—jmx_java_nio_BufferPool_MemoryUsednamejmx_java_nio_BufferPool_TotalCapacitynamejmx_java_lang_Memory_HeapMemoryUsage_used—jmx_java_lang_MemoryPool_CollectionUsage_usednamejmx_java_lang_Memory_HeapMemoryUsage_init—jmx_java_lang_OperatingSystem_SystemCpuLoad—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_initname、keysjmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageBeforeGc_initname、keyjmx_java_lang_Threading_ThreadAllocatedMemorySupported—jmx_java_lang_Memory_NonHeapMemoryUsage_max—jmx_java_lang_Threading_DaemonThreadCount—jmx_java_lang_Threading_ThreadCpuTimeSupported—jmx_java_lang_OperatingSystem_SystemLoadAverage—jmx_java_lang_Threading_TotalStartedThreadCount—jmx_java_lang_OperatingSystem_ProcessCpuTime—jmx_java_lang_OperatingSystem_FreePhysicalMemorySize—jmx_java_lang_Runtime_Uptime—jmx_java_lang_MemoryPool_CollectionUsageThresholdExceedednamejmx_java_lang_GarbageCollector_LastGcInfo_durationnamejmx_java_lang_Threading_ObjectMonitorUsageSupported—jmx_java_lang_GarbageCollector_LastGcInfo_memoryUsageAfterGc_maxname、keyjmx_java_lang_MemoryPool_UsageThresholdCountnamejmx_java_lang_Threading_ThreadCpuTimeEnabled—jmx_java_lang_OperatingSystem_OpenFileDescriptorCount—指标命名与标签规范RFC 明确了三条命名与标签规则命名规则jmx_ 指标名jmx _ metric_name与 JMX 内部命名保持一致通用标签所有指标都会被打上endpoint和host两个标签用于区分采集来源维度标签凡是带多实例的 MBean如各 MemoryPool、各 GarbageCollector、各 BufferPool以pool、area、name、gc、state、key等标签区分维度例如jmx_jvm_memory_bytes_used{areaheap}与jmx_jvm_memory_pool_bytes_used{poolG1 Eden Space}。此外 RFC 特别指出上述清单只是默认 JVM 可通过 JMX 暴露的指标。具体应用Kafka、Cassandra、Tomcat 等会暴露各自专属的 MBean 和指标实现时可以像 Prometheus jmx_exporter 的 JmxScraper 那样逐个遍历 MBean 并解析其输出进而构造并返回指标。Prometheus exporter 中针对特定 MBean 对象的 accept/deny 模式以及用于匹配并构造特定指标的规则化改写引擎都被 RFC 视为合理但属后续的工作项——RFC 同时提出一个开放问题这类过滤与改写是否用 Vector 的 transform 来实现可能更有效配置示例Doc-level ProposalRFC 为jmx_metrics源规划了如下配置结构完整保留原文示例[sources.my_source_id] type jmx_metrics # required endpoint service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmi # required - address of the JMX webserver to scrape. username user # optional - username for any JMX authentication. password password # optional - password for any JMX authentication. scrape_interval_secs 15 # optional, default, seconds namespace jmx # optional, default is jmx, namespace to put metrics under各字段的含义与默认值归纳如下字段必填默认值说明type是—固定为jmx_metricsRFC 撰写时名称待最终确认endpoint是—要抓取的 JMX 服务地址典型形式为service:jmx:rmi:///jndi/rmi://host:port/jmxrmi即标准 JMX RMI 连接 URLusername否—JMX 认证用户名若 JVM 开启了 JMX 认证password否—JMX 认证密码与username配合使用scrape_interval_secs否15抓取间隔单位秒控制指标采集的周期namespace否jmx指标所属的命名空间namespace用于将指标归类放置RFC 还补充后续应增加一份带认证authentication的配置指南帮助用户在使用 JMX 用户名/密码认证的场景下完成端到端配置。关于namespace字段仓库中已有可对照的既有实现惯例例如 src/sources/static_metrics.rs 中的namespace配置同样带有默认值默认static并在构造指标事件时通过namespace: Some(self.namespace.clone())注入。可以推断jmx_metrics的namespace落地后会走相似的 serde 反序列化与默认值逻辑。设计权衡Rationale、Drawbacks 与 Alternatives为什么值得做RationaleJVM 是运行应用的流行平台也是 Kafka、Cassandra 等基础设施工具的运行时基础用户经常需要理解它的性能。同时作为 Vector 愿景one tool 摄取并转发可观测性数据的一部分尽可能多地增加数据源可以减少用户无法从自身工具摄取指标的概率。代价Drawbacks新增一个源带来的主要代价是额外的维护与集成测试负担——这也是每个新源组件都需要面对的成本。被否决的替代方案AlternativesRFC 认真评估了两条不新增源的替代路线借道 Prometheus jmx_exporter / Telegraf让用户自行运行 Telegraf 或 Prometheus 的 jmx_exporter再让 Vector 用现有的 Prometheus 源去抓取这些数据借道 jmxtrans使用 jmxtrans 之类的工具并为 Vector 编写一个 OutputWriter 插件。RFC 作者最终否决了这两条路线理由是它们与 Vector 的核心原则相冲突One Tool. All Data. - One simple tool gets your logs, metrics, and traces (coming soon) from A to B.即一个工具全部数据一个简单工具即可把日志、指标以及即将支持的追踪从 A 点送到 B 点。不过 RFC 也保留了灵活性如果用户已经在运行 Prometheus完全可以走 Prometheus 那条路径——这与仓库中现有的 src/sources/prometheus/ 源scrape / remote_write / pushgateway 三种模式见 mod.rs天然衔接。业界已有实践Prior ArtRFC 调研了当时业界的 JMX 指标采集方案作为设计参考此处仅列名称详见原 RFCPrometheus jmx_exporterJava Agent 或独立 HTTP server 形式自带维护的 agentTelegraf jolokia 与 jolokia2通过 Jolokia agent 进行采集collectd GenericJMX 插件collectd 生态的通用 JMX 采集方案panopticon-tuiScala 生态的相关实现replicante-io agents 中的 kafka agent面向 Kafka 的 agent 实现。其中 Prometheus 与 Telegraf 方案均依赖 Java 侧 agentPrometheus 使用自维护 agentTelegraf 使用 Jolokia agent这也呼应了前文Java agent or not这一待决问题。待决问题与实施计划Outstanding Questions待决问题RFC 明确遗留的唯一关键问题是否采用 Java agent 模式Java agent or not。该决定将直接影响用户侧的使用方式是给 JVM 加启动参数还是仅配置 Vector 的 endpoint 远程抓取以及进程级指标的可得性。Plan Of Attack攻击计划与 Future Work未来工作实施以增量步骤推进首要一步是提交包含初始源实现的 PRSubmit a PR with the initial source implementation计划中的未来工作包括accept/deny 列表针对 MBean 对象模式的过滤列表用于控制采集哪些 MBean规则化改写引擎用于匹配并构造特定指标的规则化引擎对标 Prometheus jmx_exporter 的配置化能力。结合仓库现状这类源在 Vector 中如何落地虽然jmx_metrics在本仓库快照中尚未实现但从仓库现有结构可以清晰推断其落地路径源注册模式src/sources/mod.rs 展示了所有源的注册方式——以#[cfg(feature sources-xxx)]特性开关声明模块jmx_metrics落地时会以sources-jmx_metrics之类的 feature 出现在其中并配套在根 Cargo.toml 中声明依赖抓取型源参照src/sources/prometheus/ 的 scrape 实现周期性按 endpoint 抓取、解析文本、产出带 namespace 的指标事件是jmx_metrics最接近的架构参照配置惯例参照src/sources/static_metrics.rs 中的namespace默认值与指标事件构造逻辑为 RFC 中namespace jmx的默认值设计提供了现成的实现范式流程背景本 RFC 位于仓库的 rfcs/ 目录遵循 rfcs/README.md 所描述的 Vector RFC 流程——先以文档形式达成共识再进入实施阶段这解释了为什么该设计文档先行于实现存在。对于希望在生产环境中采集 JVM 指标的读者在jmx_metrics落地之前最务实的路径正是 RFC 在 Alternatives 中给出的方案为 JVM 部署 Prometheus jmx_exporter或 Jolokia再通过 Vector 现有的 Prometheus scrape 源将指标纳入统一管道。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考