可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载本文以 SkyWalking 官方文档 micrometer-observations.md 为核心骨架系统讲解如何在 SkyWalking OAP 后端启用 MicroMeter Observation 指标采集从 Java Agent 侧集成 MicroMeter 1.10 Observation API到后端开启 meter receiver、激活spring-micrometer.yaml分析规则再到 Dashboard 展示与自定义指标扩展。读完本文你将掌握一条可复现的 Spring 应用指标 → SkyWalking Meter 系统 完整配置路径并能基于仓库源码理解每条 MAL 规则背后的换算逻辑。背景MicroMeter Observation 与 SkyWalking Meter 系统MicroMeter Observation 是 Micrometer 项目的一部分提供了一整套 Observation API观测 API用于统一描述 HTTP 请求、数据库连接、JVM 运行时等可观测数据。SkyWalking 集成了 MicroMeter 1.10 的 API使其上报的指标可以直接汇入 SkyWalking 后端的 Meter 系统。Meter 系统是 SkyWalking OAP 内部的指标流式处理系统专门负责处理与分析聚合后的指标数据来自 OpenTelemetry、Zabbix、Prometheus 以及 SkyWalking Meter API 等。它提供了一门函数式分析语言MALMeter Analysis Language用户可以用 MAL 表达式对原始 meter 数据进行过滤、聚合、重命名与下采样最终落库并供查询使用。spring-micrometer.yaml正是用 MAL 编写的、面向 Spring 应用指标的分析规则文件。需要注意的是接入分为 Agent 侧与后端 OAP 侧两个环节Agent 侧负责把 Spring 应用内 Micrometer Observation 产生的指标通过 Java Agent 上报出去后端侧负责接收、解析并存储这些指标。本文聚焦后端Agent 侧的详细配置请参阅 Java Agent 的 Observations 文档。第一步在后端启用 Meter Receiver在 SkyWalking 后端配置文件application.yml默认位于$SKYWALKING_BASE_DIR/config/application.yml中确保 meter receiver 模块处于启用状态receiver-meter: selector: ${SW_RECEIVER_METER:default} default:该配置段对应源码中的 MeterReceiverModule 与 MeterReceiverProvider。selector支持通过环境变量SW_RECEIVER_METER覆盖默认值为default即启用内置实现。Meter 协议接收器在 MeterServiceHandler 中处理 Agent 上报的指标数据并在收集到的数据样本上自动附加service与instance两个标签其值取自 SkyWalking Agent 中定义的 service / service instance 名称用于标识指标归属详见 backend-meter.md 的 Report Meter Telemetry Data 一节。如果指标通过 Kafka 中转还需要在application.yml中启用 Kafka Fetcherkafka-fetcher: selector: ${SW_KAFKA_FETCHER:default} default: bootstrapServers: ${SW_KAFKA_FETCHER_SERVERS:localhost:9092}第二步激活 spring-micrometer 分析规则SkyWalking 后端已经内置了 Spring Micrometer 的 meter 配置文件即 spring-micrometer.yaml。它位于 OAP 的$CLASSPATH/meter-analyzer-config目录下。重要新增的 meter-analyzer-config 文件默认不会生效必须通过agent-analyzer模块下的meterAnalyzerActiveFiles显式激活。在application.yml中加入agent-analyzer: selector: ${SW_AGENT_ANALYZER:default} default: meterAnalyzerActiveFiles: ${SW_METER_ANALYZER_ACTIVE_FILES:spring-micrometer}参数说明meterAnalyzerActiveFiles需要激活的规则文件名不带扩展名多个文件用英文逗号分隔例如spring-micrometer,datasource,threadpoolSW_METER_ANALYZER_ACTIVE_FILES对应的环境变量覆盖项默认值为spring-micrometer。这里有一个值得注意的约束meterAnalyzerActiveFiles中列出的每个条目都必须在$CLASSPATH/meter-analyzer-config下存在同名规则文件若某条目找不到匹配文件OAP 将启动失败在早期版本中这类条目会被静默忽略。另外配置文件在 OAP 启动时加载如果新配置格式不合法OAP 同样会启动失败。从版本演进看该规则文件的默认启用状态经历过调整在 8.7.0 中 Spring sleuth meter analyzer 曾被默认禁用见 changes-8.7.0.md9.0.0 起spring-sleuth重新被列入meterAnalyzerActiveFiles默认值见 changes-9.0.0.md9.4.0 中规则文件由spring-sleuth.yaml更名为spring-micrometer.yaml见 changes-9.4.0.md。因此使用当前仓库版本时默认配置即指向spring-micrometer。第三步理解内置规则文件 spring-micrometer.yaml当前仓库内置的 spring-micrometer.yaml 是理解整套 Micrometer 指标映射的关键。文件首部两行定义了全局行为expSuffix: instance([service], [instance], Layer.GENERAL) metricPrefix: meterexpSuffix附加到本文件所有 MAL 表达式末尾。这里调用了 MAL 的instance([svc_label1, svc_label2...], [ins_label1, ins_label2...], Layer)函数即从指标标签中提取service与instance两个标签分别作为服务级与实例级标签并声明该指标归属Layer.GENERAL通用服务实例层。这正是 backend-meter.md 中所说的接收器附加的service/instance标签在此被 MAL 提升为指标的服务、实例层级信息metricPrefix插入到指标名前的固定前缀最终存储的指标名为metricPrefix_raw_metric_name例如原始指标http_server_requests_count会以meter_http_server_requests_count落库并出现在 UI 中。metricsRules中共有 22 条规则将 Agent 上报的原始 Micrometer 指标名映射为经过处理后的 Meter 指标。完整对照关系如下规则 name落库名MAL 表达式语义http_server_requests_counthttp_server_requests_count.increase(PT1M)HTTP 请求计数按分钟窗口计算增量http_server_requests_durationhttp_server_requests_sum.increase(PT1M)HTTP 请求耗时求和按分钟窗口计算增量jdbc_connections_activejdbc_connections_activeJDBC 活跃连接数瞬时值jdbc_connections_idlejdbc_connections_idleJDBC 空闲连接数瞬时值jdbc_connections_maxjdbc_connections_maxJDBC 最大连接数瞬时值jvm_classes_loadedjvm_classes_loaded已加载类数量瞬时值jvm_classes_unloadedjvm_classes_unloaded.increase(PT1M)卸载类数量按分钟窗口计算增量jvm_gc_pause_countjvm_gc_pause_count.increase(PT1M)GC 暂停次数按分钟窗口计算增量jvm_gc_pause_durationjvm_gc_pause_sum.increase(PT1M)GC 暂停耗时求和按分钟窗口计算增量jvm_memory_committedjvm_memory_committedJVM 内存 committed 大小瞬时值jvm_memory_maxjvm_memory_maxJVM 内存 max 大小瞬时值jvm_memory_usedjvm_memory_usedJVM 内存 used 大小瞬时值jvm_threads_daemonjvm_threads_daemon守护线程数瞬时值jvm_threads_livejvm_threads_live存活线程数瞬时值jvm_threads_peakjvm_threads_peak峰值线程数瞬时值process_cpu_usageprocess_cpu_usage.multiply(100)进程 CPU 使用率 ×100转为百分比展示system_cpu_usagesystem_cpu_usage.multiply(100)系统 CPU 使用率 ×100转为百分比展示system_load_average_1msystem_load_average_1m系统 1 分钟平均负载瞬时值tomcat_sessions_active_currenttomcat_sessions_active_currentTomcat 当前活跃会话数瞬时值tomcat_sessions_active_maxtomcat_sessions_active_maxTomcat 历史最大活跃会话数瞬时值tomcat_sessions_rejectedtomcat_sessions_rejected.increase(PT1M)Tomcat 拒绝会话数按分钟窗口计算增量process_files_maxprocess_files_max进程可打开文件数上限瞬时值process_files_openprocess_files_open进程当前打开文件数瞬时值从这些表达式可以看出三个典型的 MAL 用法模式函数语义详见 mal.md 的 Function 一节瞬时量直通对 gauge 类指标连接数、内存、线程数、CPU 使用率等不做聚合原样透传增量计算对 counter 类指标请求数、请求耗时、GC 次数、会话拒绝数等使用increase(PT1M)按 ISO-8601 时长格式PT1M1 分钟计算窗口内的增量量纲换算对 CPU 使用率使用multiply(100)把 0~1 的小数换算为 0~100 的百分比数值便于 Dashboard 直接展示。仓库中 spring-micrometer.data.yaml 是这套规则的可执行测试用例它向 22 个原始指标输入value: 100.0的样本携带instance: test-instance标签并断言输出结果。例如meter_http_server_requests_count的期望值为50.0验证了increase(PT1M)的增量计算meter_process_cpu_usage的期望值为10000.0验证了multiply(100)的量纲换算所有结果实体的 scope 均为SERVICE_INSTANCE、layer 为GENERAL印证了expSuffix中instance(...)的层级声明。这组测试可以作为你验证自定义规则文件的模板。支持的指标类型Application / System / JVMMicrometer Observations 接入后支持三类信息这也是spring-micrometer.yaml中 22 条规则对应的数据来源Application应用层HTTP 请求计数与耗时http_server_requests_*、JDBC 最大/空闲/活跃连接数jdbc_connections_*、Tomcat 会话活跃/拒绝数tomcat_sessions_*System系统层系统/进程 CPU 使用率system_cpu_usage/process_cpu_usage、操作系统系统负载system_load_average_1m、操作系统进程文件数process_files_*JVM运行时层GC 暂停次数与耗时jvm_gc_pause_*、内存 max/used/committed 大小jvm_memory_*、线程峰值/存活/守护数量jvm_threads_*、类加载/卸载数量jvm_classes_*。这些指标由 Java Agent 侧的 Micrometer Observation toolkit 自动采集上报无需在应用代码中手工埋点覆盖了 Spring 应用日常巡检最核心的运行时维度。Dashboard 展示与自定义指标SkyWalking 默认在通用服务实例general service instance下提供了Spring Sleuth Dashboard其中包含 Spring Sleuth 默认提供的上述指标无需额外配置即可在 UI 中查看。如果你在应用中添加了自定义指标并在后端配置了对应的 meter 规则文件则需要按 自定义 Dashboard 文档 的说明将新指标手工加入 Dashboard。自定义 meter 的完整流程Agent 侧在应用中通过 Micrometer Observation API 定义并上报自定义指标Agent 侧的 API 用法请参见 Java Agent Micrometer 文档后端规则文件在meter-analyzer-config目录$CLASSPATH/meter-analyzer-config下新建或修改 YAML 规则文件。规则文件的顶层结构与字段如下括号表示可选参数# 过滤指标仅满足此闭包条件的指标才会进入下方 metricsRules filter: closure # 示例: { tags - tags.job_name vm-monitoring } # expPrefix 在指标执行其他函数之前执行 expPrefix: string # expSuffix 追加到本文件所有表达式的末尾 expSuffix: string # 将 metricPrefix 插入指标名: metricPrefix_raw_metric_name metricPrefix: string # 可选内联声明自定义 layer详见 mal.md layerDefinitions: - name: string ordinal: int normal: bool # 指标规则允许对查询进行重算 metricsRules: # 规则名称与前缀 metricPrefix_ 组合后作为存储中的 index/table 名 # 带前缀的名称也可在 UIDashboard/Template/Item/Metrics中引用 - name: string # MAL 表达式可直接使用自定义指标采集的原始名称 exp: string激活在application.yml的agent-analyzer.default.meterAnalyzerActiveFiles中加入自定义规则文件名不带扩展名多个用逗号分隔并确保$CLASSPATH/meter-analyzer-config下存在同名文件Dashboard按 自定义 Dashboard 文档 将落库后的指标形如meter_name加入 Dashboard 的 Metrics 项中。关于rate/irate/increase的使用建议MAL 后端虽然支持rate、irate、increase等函数但官方建议优先在客户端Agent 侧完成这类计算原因有二后端计算需要为这些函数建立缓存来推算数值一旦 Agent 重连到另一台 OAP 实例rate 计算的时间窗口会被打断导致结果不准确。因此自定义指标时应优先在 Micrometer 侧完成速率/增量计算后端只负责透传或做轻量变换。进阶规则的运行时热更新与调试Meter-analyzer-config 规则与otel-rules走同一条规则管线因此支持在OAP 运行期间动态新增、覆盖、停用规则或将规则恢复为内置内容全程无需重启 OAP。相关 API 的目录名统一为meter-analyzer-config运行时规则热更新见 Runtime Rule Hot-Update APIMAL DSL 调试规则还可以挂载到采样调试会话上查看 MAL 表达式每个阶段的中间结果见 DSL Debug API — MAL。这意味着spring-micrometer.yaml里的任意规则都可以在不停机的情况下临时调整例如修改increase窗口、追加multiply换算、变更落库名验证通过后再固化为正式配置。总结Micrometer Observations 接入的完整链路可以归纳为Agent 侧Micrometer 1.10 Observation API 采集 Spring 运行时指标→Meter 协议上报receiver-meter接收并附加service/instance标签→MAL 规则分析spring-micrometer.yaml由meterAnalyzerActiveFiles激活完成增量计算、量纲换算与层级声明→落库与展示meter_name指标在 Spring Sleuth Dashboard 中呈现。核心配置只需三处receiver-meter模块开启、meterAnalyzerActiveFiles激活spring-micrometer、Dashboard 引用指标。在此基础上你可以复用 spring-micrometer.yaml 的 22 条规则模式与 spring-micrometer.data.yaml 的测试范式快速扩展出自定义指标的采集与验证闭环。赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐SkyWalking OAP Zabbix Receiver 接入指南将 Zabbix Agent 指标纳入 Meter System 统一监控SkyWalking OAP Zabbix Receiver 接入指南将 Zabbix Agent 指标纳入 Meter System 统一监控 本文围绕 A可观测性后端微服务云原生SkyWalking OAP Meter Receiver 完整指南从 Meter 协议接入到 MAL 规则配置与运行时热更新SkyWalking OAP Meter Receiver 完整指南从 Meter 协议接入到 MAL 规则配置与运行时热更新 导读 Meter Receiv可观测性APM链路追踪指标监控日志分析微服务SkyWalking Meter API 详解原生指标上报协议、采集模式与 OAP 处理链路SkyWalking Meter API 详解原生指标上报协议、采集模式与 OAP 处理链路 本篇技术指南围绕 Apache SkyWalking 的 Met可观测性APM链路追踪指标监控日志分析微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
