可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载本篇技术指南以 SkyWalking 社区 SWIP-8SkyWalking Improvement Proposal 8Support ActiveMQ classic Monitoring为核心骨架讲解如何将 Apache ActiveMQ Classic 的 JMX 指标通过 jmx_prometheus_javaagent 与 OpenTelemetry Collector 接入 SkyWalking OAP 的 Meter System实现 Cluster / Broker / Destination 三个维度的多维监控。读完本文你将掌握完整的链路搭建步骤、三类监控面板对应的全部指标定义、底层 MAL 表达式规则文件的结构与工作原理以及如何基于仓库内已有的 e2e 测试配置快速复现整套监控环境。一、方案背景与动机Apache ActiveMQ Classic 是广受欢迎且功能强大的开源消息与集成模式服务器支持多种跨语言客户端与协议内置易用的企业集成模式Enterprise Integration Patterns与大量高级特性。但在 SkyWalking 的生态中它此前缺少原生的指标监控能力因此 SWIP-8 提出通过 OpenTelemetry Collector 抓取以 Java Agent 方式运行的 jmx_prometheus_exporter 暴露的指标将其送入 SkyWalking OAP Server从而为 ActiveMQ Classic 提供监控支持。该方案的核心设计意图是复用 SkyWalking 已有的 OpenTelemetry 接收能力与 Meter 系统不引入任何新的第三方依赖详见 SWIP-8 的 Imported Dependencies libs and their licenses 一节No new dependency.且不带来任何破坏性变更no breaking changes属于纯增量式的监控能力扩展。二、整体架构与数据流SWIP-8 指出本方案没有显著的架构级变化There is no significant architecture-level change.。其完整数据流在仓库的 backend-activemq-monitoring.md 中被拆分为四个步骤JMX 采集源头ActiveMQ Classic 对 JMX 有广泛支持通过 JMX MBeans 暴露 broker 的行为数据用于监控与控制。指标暴露jmx_prometheus_exporter 以 Java Agent推荐方式挂载到 ActiveMQ Classic 的 JVM 中在本机启动一个 HTTP Server将本地 JVM 与 broker 的 JMX 指标转换为 Prometheus 格式对外服务。指标传输OpenTelemetry Collector 通过 Prometheus Receiver 定时抓取 jmx_prometheus_exporter 的指标再经 OpenTelemetry gRPC exporter 推送到 SkyWalking OAP Server。指标加工入库OAP Server 使用 MALMeter Analysis Language 解析规则对原始指标进行过滤filter、计算calculate、聚合aggregate最终落库并提供查询。对应的配置示例存放在 e2e 测试目录 test/e2e-v2/cases/activemq 中包括 ActiveMQ 配置、jmx_exporter 配置与 Collector 配置三份关键文件。三、环境搭建四步接入 ActiveMQ Classic3.1 启用 ActiveMQ 的 JMX在 ActiveMQ 的activemq.xml中启用 JMX。仓库 e2e 用例提供了完整可用的示例activemq.xml其中与 JMX 直接相关的片段如下broker xmlnshttp://activemq.apache.org/schema/core brokerName${ACTIVEMQ_BROKER_NAME} dataDirectory${activemq.data} ... !-- The managementContext is used to configure how ActiveMQ is exposed in JMX -- managementContext managementContext createConnectorfalse/ /managementContext ... systemUsage systemUsage memoryUsage memoryUsage percentOfJvmHeap70 / /memoryUsage storeUsage storeUsage limit100 gb/ /storeUsage tempUsage tempUsage limit50 gb/ /tempUsage /systemUsage /systemUsage ... /brokerJMX 远程端口默认为1616可以通过环境变量ACTIVEMQ_SUNJMX_START修改。e2e 用例的 docker-compose.yml 展示了具体的启动参数amq: image: apache/activemq-classic:6.0.1 expose: - 1616 environment: ACTIVEMQ_SUNJMX_START: -Dcom.sun.management.jmxremote.port1616 -Dcom.sun.management.jmxremote.rmi.port1616 -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.authenticatefalse ACTIVEMQ_BROKER_NAME: activemq-broker3.2 部署 jmx_prometheus_exporterjmx_prometheus_exporter 推荐以Java Agent方式随 ActiveMQ Classic 的 JVM 一起启动在本地暴露一个 HTTP 端口提供 Prometheus 格式指标。若使用 Docker也可以像 e2e 用例那样部署独立的 exporter 服务基于bitnami/jmx-exporter镜像通过远程 JMX 端口抓取指标。其抓取规则配置文件示例见 config.yaml核心参数说明如下配置项示例值说明startDelaySeconds10启动后延迟多少秒再开始抓取等待 ActiveMQ 完全就绪hostPortamq:1616目标 ActiveMQ 的 JMX 地址host:portusername/passwordadmin/activemqJMX 认证凭据需与 ActiveMQ 侧一致sslfalse是否启用 JMX-RMI 的 SSLincludeObjectNames见下方列表白名单只暴露这些 ObjectName 对应的 MBean 指标excludeObjectNames[org.apache.activemq:typeColumnFamily,*]黑名单排除不需要的 MBeanrules- pattern: .*匹配全部指标名将 JMX 属性全部转换为 Prometheus 指标其中includeObjectNames决定了后续 MAL 规则能否取到对应数据e2e 用例的白名单覆盖了 ActiveMQ 业务 MBean 与 JVM 基础 MBeanincludeObjectNames: [org.apache.activemq:*,java.lang:typeOperatingSystem,java.lang:typeGarbageCollector,*,java.lang:typeThreading,java.lang:typeRuntime,java.lang:typeMemory,java.lang:name*]注意backend-activemq-monitoring.md 特别提示要关注includeObjectNames的配置——若 MBean 未被白名单包含对应指标将无法进入 SkyWalking 的监控体系。3.3 配置 OpenTelemetry CollectorOpenTelemetry Collector 在本链路中扮演指标搬运工用 Prometheus Receiver 抓取 jmx_exporter再用 OTLP exporter 推送给 OAP。仓库提供的完整示例为 otel-collector-config.yamlreceivers: prometheus: config: scrape_configs: - job_name: activemq-monitoring scrape_interval: 30s static_configs: - targets: [amqexporter:5556] labels: cluster: activemq-cluster exporters: otlp: endpoint: oap:11800 tls: insecure: true processors: batch: service: pipelines: metrics: receivers: - prometheus processors: - batch exporters: - otlp其中两个关键点直接决定了 OAP 侧规则的匹配job_name: activemq-monitoring与后续 MAL 规则文件顶部的filter条件一一对应见第四节labels.cluster: activemq-cluster为所有抓取到的样本打上cluster标签OAP 将依据该标签把数据归属到对应的 ActiveMQ 集群服务而service_instance_id标签则由 OpenTelemetry Receiver 根据资源属性自动附加见 3.4。e2e 的 docker-compose.yml 中还演示了通过otel/opentelemetry-collector:${OTEL_COLLECTOR_VERSION}镜像与--config/etc/otel-collector-config.yaml参数启动 Collector 的方式。3.4 配置 SkyWalking OpenTelemetry ReceiverOAP 侧需要激活receiver-otelOpenTelemetry 接收器。根据 opentelemetry-receiver.md通过系统环境变量SW_OTEL_RECEIVERdefault或在application.yml中设置receiver-otel/selector${SW_OTEL_RECEIVER:default}来激活接收器默认启用otlpgRPC handlerenabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:otlp-metrics}需要将 ActiveMQ 的规则文件加入启用列表例如enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:...activemq-cluster,activemq-broker,activemq-destination}该列表以逗号分隔可按需增删。规则文件位于$CLASSPATH/otel-rules目录下打包后即oap-server/server-starter/src/main/resources/otel-rulesOAP 在启动时加载若配置格式不合法OAP 可能启动失败因此修改规则后需仔细校验 YAML 语法。此外OpenTelemetry Receiver 会给采集到的样本附加node_identifier_host_name标签取自 OTLP 资源属性net.host.name或host.name用于标识数据来源同时注意资源作用域内属性名中的点.会被转换为下划线_而指标作用域内不做转换。四、监控模型Layer / Service / Instance / Endpoint 的映射按照 backend-activemq-monitoring.md 的说明ActiveMQ Classic 监控在 OAP 中被建模为Layer: ActiveMQ下的Service。在每个集群内部Broker被表示为Instance实例Destination队列/主题被表示为Endpoint端点。这一映射关系在三个 MAL 规则文件的expSuffix中直接可见集群维度activemq-cluster.yaml 中expSuffix: tag({tags - tags.cluster activemq:: tags.cluster}).service([cluster], Layer.ACTIVEMQ)——按cluster标签构建Service并统一加activemq::前缀避免与其他服务冲突Broker 维度activemq-broker.yaml 中expSuffix: tag(...).instance([cluster], [brokerName], Layer.ACTIVEMQ)——在集群下按brokerName构建InstanceDestination 维度activemq-destination.yaml 中expSuffix: tag(...).endpoint([cluster], [destinationName], Layer.ACTIVEMQ)——在集群下按destinationName构建Endpoint。三个规则文件都使用metricPrefixmeter_activemq_cluster/meter_activemq_broker/meter_activemq_destination为最终落库的指标名添加前缀这正是 SWIP-8 指标表中所有meter_activemq_*指标名的由来。五、指标清单Cluster / Broker / Destination 三类监控面板以下三张指标表完整继承自 SWIP-8 与 backend-activemq-monitoring.md数据源统一为JMX Prometheus Exporter。5.1 ActiveMQ Cluster集群级即 JVM 级指标监控面板单位指标名说明System Load AverageCountmeter_activemq_cluster_system_load_average系统平均负载范围 [0, 10000]Thread CountCountmeter_activemq_cluster_thread_countJVM 当前使用的线程数Init Heap Memory UsageBytesmeter_activemq_cluster_heap_memory_usage_initJVM 可用的初始堆内存大小Committed Heap Memory UsageBytesmeter_activemq_cluster_heap_memory_usage_committedJVM 保证可用的已提交堆内存大小Used Heap Memory UsageBytesmeter_activemq_cluster_heap_memory_usage_usedJVM 当前正在使用的堆内存大小Max Heap Memory UsageBytesmeter_activemq_cluster_heap_memory_usage_max堆内存可能达到的最大尺寸GC G1 Old Collection CountCountmeter_activemq_cluster_gc_g1_old_collection_countG1 Old 代 GC 次数JDK[9,17]GC G1 Young Collection CountCountmeter_activemq_cluster_gc_g1_young_collection_countG1 Young 代 GC 次数JDK[9,17]GC G1 Old Collection Timemsmeter_activemq_cluster_gc_g1_old_collection_timeG1 Old 代 GC 耗时毫秒JDK[9,17]GC G1 Young Collection Timemsmeter_activemq_cluster_gc_g1_young_collection_timeG1 Young 代 GC 耗时毫秒JDK[9,17]GC Parallel Old Collection CountCountmeter_activemq_cluster_gc_parallel_old_collection_countParallel Old 代 GC 次数JDK[6,8]GC Parallel Young Collection CountCountmeter_activemq_cluster_gc_parallel_young_collection_countParallel Young 代 GC 次数JDK[6,8]GC Parallel Old Collection Timemsmeter_activemq_cluster_gc_parallel_old_collection_timeParallel Old 代 GC 耗时毫秒JDK[6,8]GC Parallel Young Collection Timemsmeter_activemq_cluster_gc_parallel_young_collection_timeParallel Young 代 GC 耗时毫秒JDK[6,8]Enqueue RateCount/smeter_activemq_cluster_enqueue_rate每秒发送到集群的消息数JDK[6,8]Dequeue RateCount/smeter_activemq_cluster_dequeue_rate集群上每秒被确认或丢弃的消息数Dispatch RateCount/smeter_activemq_cluster_dispatch_rate每秒投递给消费者的消息数Expired RateCount/smeter_activemq_cluster_expired_rate每秒过期的消息数Average Enqueue Timemsmeter_activemq_cluster_average_enqueue_time消息在集群上停留的平均时长Max Enqueue Timemsmeter_activemq_cluster_max_enqueue_time消息在集群上停留的最大时长5.2 ActiveMQ Broker 指标监控面板单位指标名说明Uptimesecmeter_activemq_broker_uptimebroker 的运行时长天Statemeter_activemq_broker_state若为 slave broker 则为 1否则为 0Current ConnectionsCountmeter_activemq_broker_current_connections当前连接到 broker 的客户端数Current Producer CountCountmeter_activemq_broker_current_producer_count当前挂载在 broker 上的生产者数Current Consumer CountCountmeter_activemq_broker_current_consumer_count当前从 broker 消费消息的消费者数Producer CountCountmeter_activemq_broker_producer_count在目的地活跃的消息生产者数量Consumer CountCountmeter_activemq_broker_consumer_count订阅目的地的消息消费者数量Enqueue CountCountmeter_activemq_broker_enqueue_count发送到 broker 的消息总数Dequeue CountCountmeter_activemq_broker_dequeue_countbroker 已投递给消费者的消息总数Enqueue RateCount/secmeter_activemq_broker_enqueue_rate每秒发送到 broker 的消息总数Dequeue RateCount/secmeter_activemq_broker_dequeue_rate每秒 broker 投递给消费者的消息总数Memory Percent Usage%meter_activemq_broker_memory_percent_usagebroker 已用配置内存的百分比Memory UsageBytesmeter_activemq_broker_memory_percent_usage未投递消息所占用的内存字节Memory LimitBytesmeter_activemq_broker_memory_limit在分页到临时存储之前用于保存未投递消息的内存上限Store Percent Usage%meter_activemq_broker_store_percent_usage持久化消息存储所用可用磁盘空间的百分比Store LimitBytesmeter_activemq_broker_store_limit在阻塞生产者之前用于持久化消息的磁盘上限Temp Percent UsageBytesmeter_activemq_broker_temp_percent_usage非持久化消息存储所用可用磁盘空间的百分比Temp LimitBytesmeter_activemq_broker_temp_limit在阻塞生产者之前用于非持久化消息与临时数据的磁盘上限Average Message SizeBytesmeter_activemq_broker_average_message_sizebroker 上的平均消息大小Max Message SizeBytesmeter_activemq_broker_max_message_sizebroker 上的最大消息大小Queue SizeCountmeter_activemq_broker_queue_size已派发但未被确认的消息数量5.3 ActiveMQ Destination 指标监控面板单位指标名说明Producer CountCountmeter_activemq_destination_producer_count挂载到该目的地的生产者数Consumer CountCountmeter_activemq_destination_consumer_count订阅该目的地的消费者数Topic Consumer CountCountmeter_activemq_destination_topic_consumer_count订阅主题的消费者数Queue SizeCountmeter_activemq_destination_queue_size未被消费者确认的消息数Memory UsageBytesmeter_activemq_destination_memory_usage未投递消息占用的内存字节Memory Percent Usage%meter_activemq_destination_memory_percent_usage目的地已用配置内存的百分比Enqueue CountCountmeter_activemq_destination_enqueue_count发送到目的地的消息数Dequeue CountCountmeter_activemq_destination_dequeue_count目的地已投递给消费者的消息数Average Enqueue Timemsmeter_activemq_destination_average_enqueue_time消息在目的地上停留的平均时长Max Enqueue Timemsmeter_activemq_destination_max_enqueue_time消息在目的地上停留的最大时长Dispatch CountCountmeter_activemq_destination_dispatch_count已投递给消费者的消息数Expired CountCountmeter_activemq_destination_expired_count已过期的消息数Inflight CountCountmeter_activemq_destination_inflight_count已派发但未被消费者确认的消息数Average Message SizeBytesmeter_activemq_destination_average_message_size该目的地的平均消息大小Max Message SizeBytesmeter_activemq_destination_max_message_size该目的地的最大消息大小六、MAL 规则源码级解析指标是如何被加工出来的SWIP-8 的指标表只是结果真正决定指标语义的是 OAP 启动时加载的 MAL 规则文件。三个文件均位于 otel-rules/activemq以下逐一解读其关键表达式。6.1 通用结构每个规则文件都由四部分组成filter入口过滤条件。三个文件均为filter: { tags - tags.job_name activemq-monitoring }即只处理 OpenTelemetry Collector 中job_name为activemq-monitoring的样本——这与 otel-collector-config.yaml 中的job_name必须严格一致expSuffix维度映射后缀决定数据归属到 Service / Instance / Endpoint见第四节metricPrefix指标名前缀metricsRules每条规则的name指标后缀名与expMAL 表达式含原始 Prometheus 指标名与聚合算子。6.2 Cluster 规则的典型表达式Cluster 规则同时加工 JVM 指标与 ActiveMQ Broker 全局计数指标activemq-cluster.yaml# The average system load, range:[0,10000]. - name: system_load_average exp: java_lang_OperatingSystem_SystemLoadAverage.avg([cluster,service_instance_id])*10000 # Threads currently used by the JVM. - name: thread_count exp: java_lang_Threading_ThreadCount.sum([cluster,service_instance_id]) # The gc count of G1 Old Generation(JDK[9,17]). - name: gc_g1_old_collection_count exp: java_lang_G1_Old_Generation_CollectionCount.tagEqual(type,GarbageCollector).sum([cluster,service_instance_id]).increase(PT1M) # Number of messages that have been sent to the broker per second. - name: enqueue_rate exp: org_apache_activemq_Broker_TotalEnqueueCount.sum(([cluster])).rate(PT1M)可以观察到几个值得注意的实现细节JVM 原始指标名直接来自 jmx_exporter 的命名规则包名、类型名用下划线连接如java_lang_OperatingSystem_SystemLoadAverage、java_lang_Threading_ThreadCountGC 指标区分了 JDK 版本JDK[9,17] 使用 G1 专用指标名java_lang_G1_Old_Generation_CollectionCountJDK[6,8] 则退化为通用java_lang_GarbageCollector_CollectionCount并用tagEqual(name,PS MarkSweep)或PS Scavenge过滤——这解释了 SWIP-8 指标表中对两种 GC 系列的标注聚合粒度sum/avg/max算子后的维度数组决定了按什么标签维度聚合如[cluster,service_instance_id]表示在同一集群、同一 JVM 实例内聚合时间窗口算子.rate(PT1M)计算每分钟速率.increase(PT1M)计算每分钟增量PT1M为 ISO-8601 时长格式表示 1 分钟量纲换算系统负载原始值为 [0,1] 的小数规则中*10000放大为 [0,10000] 的整数与指标表中描述一致ActiveMQ 业务指标org_apache_activemq_Broker_TotalEnqueueCount等来自 ActiveMQ 的org.apache.activemqMBean与 config.yaml 中includeObjectNames: [org.apache.activemq:*, ...]的白名单严格对应。6.3 Broker 规则的典型表达式Broker 规则以brokerName为实例维度activemq-broker.yaml# Uptime of the broker in day. - name: uptime exp: org_apache_activemq_Broker_UptimeMillis.max([cluster,brokerName,service_instance_id]) # If slave broker 1 else 0. - name: state exp: org_apache_activemq_Broker_Slave.sum([cluster,brokerName,service_instance_id]) # The total number of messages sent to the broker. - name: enqueue_count exp: org_apache_activemq_Broker_TotalEnqueueCount.sum([cluster,brokerName,service_instance_id]).increase(PT1M) # Memory used by undelivered messages in bytes. - name: memory_usage exp: org_apache_activemq_Broker_MemoryUsageByteCount.sum([cluster,brokerName,service_instance_id]) # Number of messages on this broker that have been dispatched but not acknowledged. - name: queue_size exp: org_apache_activemq_Broker_QueueSize.sum([cluster,brokerName,destinationName])6.4 Destination 规则的典型表达式Destination 规则以destinationName、destinationType为端点维度并演示了标签过滤的用法activemq-destination.yaml# Number of consumers subscribed to the topics. - name: topic_consumer_count exp: org_apache_activemq_Broker_ConsumerCount.tagEqual(destinationType,Topic).sum([cluster,destinationName]) # The number of messages that have been dispatched to but not acknowledged by consumers. - name: inflight_count exp: org_apache_activemq_Broker_InFlightCount.sum([cluster,destinationName,destinationType])其中tagEqual(destinationType,Topic)只保留 Topic 类型的样本从而单独计算主题消费者数——这是 MAL 标签过滤算子在实际监控规则中的典型应用。七、UI 面板与自定义扩展7.1 内置监控面板仓库在 ui-initialized-templates/activemq 目录下提供了四份开箱即用的 UI 模板activemq-root.json入口面板activemq-cluster.json集群级JVM 与全局吞吐面板activemq-broker.jsonbroker 实例面板activemq-destination.jsondestination 端点面板。并在 menu.yaml 中注册了菜单项因此 OAP 启动后 SkyWalking UI 即可在菜单中看到 ActiveMQ 相关面板无需额外导入。7.2 自定义指标与面板根据 backend-activemq-monitoring.md 的 Customizations 一节你可以按需扩展指标定义与表达式规则修改或新增 otel-rules/activemq 下的activemq-cluster.yaml、activemq-broker.yaml、activemq-destination.yaml可自定义指标、过滤/计算/聚合表达式规则语法遵循 MALUI 面板自定义ui-initialized-templates/activemq目录下的 dashboard 面板配置。由于该链路完全走 OpenTelemetry 通用接收通道规则文件遵循 MAL 通用方案但需注意 opentelemetry-receiver.md 的说明receiver-otel由于是推模式push mode只支持group、defaultMetricLevel和metricsRules节点不支持拉模式相关的其他节点。八、端到端验证e2e 测试如何复现整套监控仓库在 test/e2e-v2/cases/activemq 下提供了完整的端到端验证用例是快速复现本文整套方案的最佳参考各文件职责如下activemq.xml启用了managementContext的 ActiveMQ 主配置并定义了systemUsage内存 70% JVM 堆、store 100GB、temp 50GB 上限对应memory_limit/store_limit/temp_limit等指标的量程与 openwire/amqp/stomp/mqtt/ws 多个 transportConnectorconfig.yamljmx_exporter 的抓取规则见 3.2otel-collector-config.yamlCollector 的 Prometheus Receiver OTLP exporter 管道见 3.3docker-compose.yml一键编排oap、amq、amqexporter、otel-collector四个核心服务以及amq-producer-mock、amq-consumer-mock两个压测容器——它们通过activemq producer/consumer命令行工具向queue://testQueue与topic://testTopic生产/消费消息为监控指标提供真实流量expected 目录断言文件service.yml、instance.yml、endpoint.yml、metrics-has-value*.yml验证 OAP 是否生成了预期的 Service / Instance / Endpoint 实体以及cluster、service_instance_id、destinationName、destinationType等标签是否携带了正确取值。其中metrics-has-value-label-destinationname.yml等文件直接证明了 Destination 级指标确实按destinationName标签打点是第五节指标表在真实运行环境中的行为验证。九、兼容性与影响面SWIP-8 明确了本方案的两个约束无新增依赖整条链路只复用 jmx_prometheus_exporter、OpenTelemetry Collector 与 SkyWalking 已有的 OpenTelemetry Receiver / Meter 能力SkyWalking 本身不引入新的第三方库无破坏性变更监控能力以增量规则otel-rules与新增 UI 模板ui-initialized-templates的形式落地不影响既有 trace / metric / log 链路。需要特别留意的前提条件JDK 版本差异GC 指标区分了 JDK[9,17] 的 G1 指标与 JDK[6,8] 的 Parallel 指标若使用其他 GC 组合如 JDK 8 上的 G1部分 GC 指标可能为空属预期行为JMX 端口与认证远程 JMX1616端口的 SSL/认证开关须在ACTIVEMQ_SUNJMX_START与 jmx_exporter 的hostPort/username/password/ssl配置之间保持一致规则文件一致性Collector 的job_name、jmx_exporter 的includeObjectNames白名单与 MAL 规则中的指标名必须相互匹配任何一环缺失都会导致对应指标无法展示。十、总结从 SWIP-8 提案到仓库中完整的落地实现SkyWalking 对 ActiveMQ Classic 的监控遵循了一条清晰的通用化路线JMX MBeans → jmx_prometheus_exporterJava Agent/独立服务→ OpenTelemetry CollectorPrometheus Receiver OTLP exporter→ OAP 的 OpenTelemetry Receiver → MAL 规则聚合 → UI 面板展示。它不引入新依赖、无破坏性变更并通过 Cluster / Broker / Destination 三层模型覆盖了从 JVM 资源、broker 吞吐与存储到每个队列/主题的生产消费细节。无论是直接复用仓库中的 e2e 配置快速搭建监控还是基于 MAL 规则与 UI 模板做深度自定义本文提供的指标清单、规则源码与配置文件都已覆盖到可直接动手实践的程度。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐SkyWalking 接入 ActiveMQ Classic 监控JMX jmx_prometheus_javaagent OpenTelemetry Collector 全链路配置指南SkyWalking 接入 ActiveMQ Classic 监控JMX jmx_prometheus_javaagent OpenTelemetry可观测性APM链路追踪指标监控日志分析微服务SkyWalking 集成 ActiveMQ Classic 监控JMX Prometheus OpenTelemetry 全链路实践指南SkyWalking 集成 ActiveMQ Classic 监控JMX Prometheus OpenTelemetry 全链路实践指南 本指南系统可观测性后端微服务云原生基于 Prometheus JMX Exporter 与 OpenTelemetry Collector 的 SkyWalking Kafka 监控实战指南基于 Prometheus JMX Exporter 与 OpenTelemetry Collector 的 SkyWalking Kafka 监控实战指南 本可观测性后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考