- 可观测性
- APM
- 链路追踪
- 指标监控
- 日志分析
- 微服务
【免费下载链接】skywalking
APM, Application Performance Monitoring System
本文以 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 等）。它提供了一门函数式分析语言MAL（Meter 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 Fetcher：
kafka-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,threadpool；SW_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.md），9.0.0 起spring-sleuth重新被列入meterAnalyzerActiveFiles默认值（见 changes-9.0.0.md），9.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_count | http_server_requests_count.increase("PT1M") | HTTP 请求计数，按分钟窗口计算增量 |
http_server_requests_duration | http_server_requests_sum.increase("PT1M") | HTTP 请求耗时求和，按分钟窗口计算增量 |
jdbc_connections_active | jdbc_connections_active | JDBC 活跃连接数（瞬时值） |
jdbc_connections_idle | jdbc_connections_idle | JDBC 空闲连接数（瞬时值） |
jdbc_connections_max | jdbc_connections_max | JDBC 最大连接数（瞬时值） |
jvm_classes_loaded | jvm_classes_loaded | 已加载类数量（瞬时值） |
jvm_classes_unloaded | jvm_classes_unloaded.increase("PT1M") | 卸载类数量，按分钟窗口计算增量 |
jvm_gc_pause_count | jvm_gc_pause_count.increase("PT1M") | GC 暂停次数，按分钟窗口计算增量 |
jvm_gc_pause_duration | jvm_gc_pause_sum.increase("PT1M") | GC 暂停耗时求和，按分钟窗口计算增量 |
jvm_memory_committed | jvm_memory_committed | JVM 内存 committed 大小（瞬时值） |
jvm_memory_max | jvm_memory_max | JVM 内存 max 大小（瞬时值） |
jvm_memory_used | jvm_memory_used | JVM 内存 used 大小（瞬时值） |
jvm_threads_daemon | jvm_threads_daemon | 守护线程数（瞬时值） |
jvm_threads_live | jvm_threads_live | 存活线程数（瞬时值） |
jvm_threads_peak | jvm_threads_peak | 峰值线程数（瞬时值） |
process_cpu_usage | process_cpu_usage.multiply(100) | 进程 CPU 使用率 ×100（转为百分比展示） |
system_cpu_usage | system_cpu_usage.multiply(100) | 系统 CPU 使用率 ×100（转为百分比展示） |
system_load_average_1m | system_load_average_1m | 系统 1 分钟平均负载（瞬时值） |
tomcat_sessions_active_current | tomcat_sessions_active_current | Tomcat 当前活跃会话数（瞬时值） |
tomcat_sessions_active_max | tomcat_sessions_active_max | Tomcat 历史最大活跃会话数（瞬时值） |
tomcat_sessions_rejected | tomcat_sessions_rejected.increase("PT1M") | Tomcat 拒绝会话数，按分钟窗口计算增量 |
process_files_max | process_files_max | 进程可打开文件数上限（瞬时值） |
process_files_open | process_files_open | 进程当前打开文件数（瞬时值） |
从这些表达式可以看出三个典型的 MAL 用法模式（函数语义详见 mal.md 的 Function 一节）：
- 瞬时量直通：对 gauge 类指标（连接数、内存、线程数、CPU 使用率等）不做聚合，原样透传；
- 增量计算：对 counter 类指标（请求数、请求耗时、GC 次数、会话拒绝数等）使用
increase("PT1M")，按 ISO-8601 时长格式PT1M（1 分钟）计算窗口内的增量； - 量纲换算：对 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 / JVM
Micrometer 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 名 # 带前缀的名称也可在 UI（Dashboard/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 API；
- MAL 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
- 链路追踪
- 指标监控
- 日志分析
- 微服务
【免费下载链接】skywalking
APM, Application Performance Monitoring System
相关推荐
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），仅供参考
