可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载SkyWalking 借助 Prometheus windows_exporter 采集 Windows 主机指标再经 OpenTelemetry Collector 中转将指标通过 OpenTelemetry gRPC 协议送入 OAP 的 OpenTelemetry receiver最终由 Meter 系统MAL完成过滤、计算与聚合。本文以 backend-win-monitoring.md 为骨架结合仓库内的 windows.yaml 规则文件与 win e2e 用例 源码完整讲解 Windows 监控的部署步骤、数据流、每条监控面板对应的指标表达式以及如何自定义自己的指标与仪表盘。监控模型与数据流在 SkyWalking 中每一台被监控的 Windows 主机被建模为 OAP 中的一个Service其Layer为OS_WINDOWS。这意味着 Windows 主机与普通业务服务并列出现在拓扑与服务列表中可以直接复用 OAP 已有的服务检索、指标查询与告警能力。针对 OpenTelemetry receiver 的完整数据流如下Prometheus windows_exporter在 Windows 虚拟机/物理机上暴露指标端点持续采集 CPU、内存、虚拟内存、磁盘、网络等操作系统指标OpenTelemetry Collector通过内置的 Prometheus Receiver 定期抓取 windows_exporter 指标再通过 OpenTelemetry gRPC exporter 推送到 SkyWalking OAP Server默认端口11800OAP 的 OpenTelemetry receiver接收 OTLP 指标后按 MALMeter Analysis Language 规则文件中的表达式对样本进行过滤、计算、聚合最终写入存储层供 UI 查询展示。从源码角度看该链路对应的规则入口位于 otel-rules/windows.yaml接收端配置说明见 opentelemetry-receiver.md。这条链路与 Linux 主机监控vm.yaml 对应的 node_exporter 方案完全同构仅数据源与规则文件不同。部署前置组件1. 安装 Prometheus windows_exporter在每台需要监控的 Windows 主机上部署 prometheus-community/windows_exporter默认监听端口为9182。windows_exporter 会暴露windows_cpu_time_total、windows_cs_physical_memory_bytes、windows_os_physical_memory_free_bytes、windows_os_virtual_memory_bytes、windows_logical_disk_*_bytes_total、windows_net_bytes_*_total等原始指标这些指标名正是 MAL 规则中表达式的基础数据源。2. 部署 OpenTelemetry CollectorOpenTelemetry Collector 负责把 Prometheus 格式的指标转换为 OTLP 格式并转发给 OAP。仓库的 e2e 用例中提供了一个可直接参考的完整配置otel-collector-config.yaml其核心内容如下receivers: prometheus: config: scrape_configs: - job_name: windows-monitoring # 该 job 名用于 windows.yaml 规则中的过滤 scrape_interval: 10s static_configs: - targets: [win-service:9182] processors: batch: exporters: otlp: endpoint: oap:11800 # OAP Server 的 gRPC 地址 tls: insecure: true logging: logLevel: debug service: pipelines: metrics: receivers: [prometheus] processors: [batch] exporters: [otlp, logging]配置要点job_name必须与规则过滤条件一致MAL 规则文件顶部通过filter: { tags - tags.job_name windows-monitoring }只接收 job 名为windows-monitoring的样本因此此处 job 名不可随意修改targets指向 windows_exporter 的地址与端口示例中win-service:9182为 e2e 容器网络内的主机名实际部署时应替换为 Windows 主机的 IP 与 exporter 端口endpoint指向 OAP 的 gRPC 端口11800tls.insecure: true用于明文传输注意此写法适用于较新的 OTel Collector 版本旧版本如 0.29.0 需使用insecure: true的顶层写法配置文件中已有对应注释说明batchprocessor 对样本做批量发送优化loggingexporter 便于在调试阶段直接观察导出内容。3. 配置 SkyWalking OpenTelemetry receiverOAP 侧的 OpenTelemetry receiver 默认未激活需要通过环境变量或配置文件启用设置系统环境变量SW_OTEL_RECEIVERdefault或在application.yml中配置receiver-otel/selector${SW_OTEL_RECEIVER:default}启用 OTLP metrics handler 并加载 windows 规则参照 opentelemetry-receiver.md 中给出的通用写法将enabledOtelMetricsRules加入windows规则即可例如receiver-otel: selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:otlp-metrics} enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:windows}规则文件存放在$CLASSPATH/otel-rules下仓库源码位置为 oap-server/server-starter/src/main/resources/otel-rules/windows.yamlOAP 启动时加载。注意若规则文件格式不合法OAP 可能启动失败。支持的监控指标以下是 Windows 监控默认支持的面板指标。指标名带有meter_win前缀正是规则文件中metricPrefix: meter_win的产物。监控面板单位指标名Metric Name说明CPU Usage%meter_win_cpu_total_percentageCPU 总使用率百分比若有 2 个核心最大值为 200%CPU Average Used%meter_win_cpu_average_used各模式mode下 CPU 核心的平均使用百分比Memory RAM UsageMBmeter_win_memory_used物理内存总使用量Memory RAMMBmeter_win_memory_total、meter_win_memory_available、meter_win_memory_used物理内存统计Total / Available / UsedVirtual-Memory Usage%meter_win_memory_virtual_memory_percentage虚拟内存使用百分比Virtual-MemoryMBmeter_win_memory_virtual_memory_free、meter_win_memory_virtual_memory_total虚拟内存统计Free / TotalDisk R/WKB/smeter_win_disk_read、meter_win_disk_written磁盘读取与写入速率Network Bandwidth UsageKB/smeter_win_network_receive、meter_win_network_transmit网络接收与发送速率数据源均为 Prometheus windows_exporter。e2e 用例 metrics-has-value.yml 与 win-cases.yaml 中通过swctl metrics exec --expressionmeter_win_memory_virtual_memory_total实际验证了虚拟内存总容量指标能被正常查询到非空值。MAL 规则文件源码解析otel-rules/windows.yaml 是整个 Windows 监控的核心它定义了过滤条件、实体归属与全部指标表达式。先看文件头部的三个关键声明filter: { tags - tags.job_name windows-monitoring } # OpenTelemetry job 名 expSuffix: service([node_identifier_host_name], Layer.OS_WINDOWS) metricPrefix: meter_winfilter只处理 job 名为windows-monitoring的样本与 OpenTelemetry Collector 中scrape_configs.job_name一一对应expSuffix所有指标表达式统一附加的后缀将node_identifier_host_name标签值作为服务名并把服务归属到Layer.OS_WINDOWS层——这正是Windows 主机 一个 OS_WINDOWS 层 Service模型的实现来源。node_identifier_host_name标签由 OpenTelemetry receiver 自动打上其值取自 OTLP 资源属性net.host.name部分 OTLP 版本为host.name相关机制详见 opentelemetry-receiver.mdmetricPrefix生成的指标统一加meter_win前缀。CPU 指标metricsRules: # windows 不直接暴露 cpu load 指标 - name: cpu_total_percentage exp: (windows_cpu_time_total * 100).tagNotEqual(mode , idle).sum([node_identifier_host_name]).rate(PT1M) - name: cpu_average_used exp: (windows_cpu_time_total * 100).sum([node_identifier_host_name , mode]).rate(PT1M)windows_cpu_time_total是按 CPU modeidle / user / system 等拆分的累计计数器。cpu_total_percentage先过滤掉idle模式、按主机聚合后求 1 分钟速率再乘 100得到总使用率——这就是2 核时最大 200%的原因多个核心的时间计数被直接相加。cpu_average_used则保留mode维度聚合反映每个模式的占比。内存指标#memory - name: memory_total exp: windows_cs_physical_memory_bytes - name: memory_available exp: windows_os_physical_memory_free_bytes - name: memory_used exp: windows_cs_physical_memory_bytes - windows_os_physical_memory_free_bytes - name: memory_virtual_memory_free exp: windows_os_virtual_memory_free_bytes - name: memory_virtual_memory_total exp: windows_os_virtual_memory_bytes - name: memory_virtual_memory_percentage exp: 100 - ((windows_os_virtual_memory_free_bytes * 100) / windows_os_virtual_memory_bytes)物理内存的 Total / Available / Used 分别来自windows_cs_physical_memory_bytes与windows_os_physical_memory_free_bytes其中 Used 是两者的差值表达式虚拟内存的 Free / Total 来自windows_os_virtual_memory_free_bytes与windows_os_virtual_memory_bytes使用率则通过100 - (free * 100 / total)换算为百分比。磁盘指标#disk - name: disk_read exp: windows_logical_disk_read_bytes_total.sum([node_identifier_host_name]).rate(PT1M) - name: disk_written exp: windows_logical_disk_write_bytes_total.sum([node_identifier_host_name]).rate(PT1M)windows_logical_disk_read_bytes_total/windows_logical_disk_write_bytes_total是累计字节计数器先按主机聚合再取 1 分钟速率得到每秒读写字节数面板以 KB/s 展示。网络指标#network - name: network_receive exp: windows_net_bytes_received_total.sum([node_identifier_host_name]).irate() - name: network_transmit exp: windows_net_bytes_sent_total.sum([node_identifier_host_name]).irate()网络收发同样先按主机聚合再使用irate()瞬时速率计算每秒字节数。对比可见磁盘与网络这类按主机聚合后求速率的表达式结构完全一致区别仅在于磁盘用rate(PT1M)、网络用irate()。端到端验证e2e 用例仓库提供了完整的 Windows 监控 e2e 验证用例目录为 test/e2e-v2/cases/win包含docker-compose.yml拉起 OAP、BanyanDB 与 e2e-mock-sender 服务e2e.yaml定义触发动作——定时向 mock sender 发送otel-metrics请求使其把预置的 OTLP 指标数据推送给 OAPwin-cases.yaml两条验证断言swctl service ls能查询到服务名为10.211.55.3、layers含OS_WINDOWS的服务对应 service.yml 期望文件swctl metrics exec --expressionmeter_win_memory_virtual_memory_total --service-name10.211.55.3能查询到该指标的非空时序值对应 metrics-has-value.yml 期望文件mock-data/otel-mock-metrics.json预置的 OTLP 指标样本模拟 windows_exporter 采集结果。这套用例直接印证了两点一是 Windows 主机会以OS_WINDOWS层服务的形式出现在 OAP 中二是 MAL 规则生成的meter_win_*指标可以被标准指标查询协议正常检索可作为自建监控环境时的验证参考。自定义指标与仪表盘/config/otel-rules/windows.yaml仓库内对应 oap-server/server-starter/src/main/resources/otel-rules/windows.yaml定义了指标的表达式规则你可以按需修改新增指标在metricsRules中追加- name: 指标名与exp: MAL 表达式表达式基于 windows_exporter 暴露的原始指标如windows_*系列编写并注意expSuffix会自动附加service([node_identifier_host_name], Layer.OS_WINDOWS)因此聚合维度通常写[node_identifier_host_name]即可修改聚合方式例如将rate(PT1M)换成irate()、调整聚合标签组都会直接影响面板数值口径仪表盘面板面板 JSON 由 SkyWalking Horizon UI 前端包apache/skywalking-horizon-ui提供OAP 后端不再托管 UI 仪表盘 JSON修改面板需在前端侧进行。需要注意任何对规则文件的改动都要求 OAP 启动时能正确加载格式错误会导致启动失败规则语法细节可参考 MAL 设计文档。总结Windows 监控是 SkyWalking 通过 OpenTelemetry 生态实现零 SDK 接入主机可观测性的典型场景windows_exporter 负责采集OpenTelemetry Collector 负责协议转换与转发OAP 侧由 MAL 规则完成建模与聚合最终以OS_WINDOWS层服务的形态进入服务目录。理解了 windows.yaml 中 filter / expSuffix / metricPrefix / metricsRules 四段式结构以及每条面板指标背后的 MAL 表达式你就能按同样套路扩展出自定义的 Windows 监控指标。赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐SkyWalking Pulsar 监控接入实战OpenTelemetry Collector 采集链路、MAL 规则与指标面板详解SkyWalking Pulsar 监控接入实战OpenTelemetry Collector 采集链路、MAL 规则与指标面板详解 SkyWalking 通可观测性后端微服务云原生SkyWalking Pulsar 监控实战从 OpenTelemetry Collector 到 MAL 指标规则的全链路解析SkyWalking Pulsar 监控实战从 OpenTelemetry Collector 到 MAL 指标规则的全链路解析 本篇基于 SkyWalkin可观测性APM链路追踪指标监控日志分析微服务SkyWalking Elasticsearch 监控接入指南基于 elasticsearch-exporter、OpenTelemetry Collector 与 MAL 的全链路指标监控SkyWalking Elasticsearch 监控接入指南基于 elasticsearch exporter、OpenTelemetry Collecto可观测性APM链路追踪指标监控日志分析微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SkyWalking Windows 监控接入指南：windows_exporter + OpenTelemetry Collector 数据链路与 MAL 指标规则解析
可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载SkyWalking 借助 Prometheus windows_exporter 采集 Windows 主机指标再经 OpenTelemetry Collector 中转将指标通过 OpenTelemetry gRPC 协议送入 OAP 的 OpenTelemetry receiver最终由 Meter 系统MAL完成过滤、计算与聚合。本文以 backend-win-monitoring.md 为骨架结合仓库内的 windows.yaml 规则文件与 win e2e 用例 源码完整讲解 Windows 监控的部署步骤、数据流、每条监控面板对应的指标表达式以及如何自定义自己的指标与仪表盘。监控模型与数据流在 SkyWalking 中每一台被监控的 Windows 主机被建模为 OAP 中的一个Service其Layer为OS_WINDOWS。这意味着 Windows 主机与普通业务服务并列出现在拓扑与服务列表中可以直接复用 OAP 已有的服务检索、指标查询与告警能力。针对 OpenTelemetry receiver 的完整数据流如下Prometheus windows_exporter在 Windows 虚拟机/物理机上暴露指标端点持续采集 CPU、内存、虚拟内存、磁盘、网络等操作系统指标OpenTelemetry Collector通过内置的 Prometheus Receiver 定期抓取 windows_exporter 指标再通过 OpenTelemetry gRPC exporter 推送到 SkyWalking OAP Server默认端口11800OAP 的 OpenTelemetry receiver接收 OTLP 指标后按 MALMeter Analysis Language 规则文件中的表达式对样本进行过滤、计算、聚合最终写入存储层供 UI 查询展示。从源码角度看该链路对应的规则入口位于 otel-rules/windows.yaml接收端配置说明见 opentelemetry-receiver.md。这条链路与 Linux 主机监控vm.yaml 对应的 node_exporter 方案完全同构仅数据源与规则文件不同。部署前置组件1. 安装 Prometheus windows_exporter在每台需要监控的 Windows 主机上部署 prometheus-community/windows_exporter默认监听端口为9182。windows_exporter 会暴露windows_cpu_time_total、windows_cs_physical_memory_bytes、windows_os_physical_memory_free_bytes、windows_os_virtual_memory_bytes、windows_logical_disk_*_bytes_total、windows_net_bytes_*_total等原始指标这些指标名正是 MAL 规则中表达式的基础数据源。2. 部署 OpenTelemetry CollectorOpenTelemetry Collector 负责把 Prometheus 格式的指标转换为 OTLP 格式并转发给 OAP。仓库的 e2e 用例中提供了一个可直接参考的完整配置otel-collector-config.yaml其核心内容如下receivers: prometheus: config: scrape_configs: - job_name: windows-monitoring # 该 job 名用于 windows.yaml 规则中的过滤 scrape_interval: 10s static_configs: - targets: [win-service:9182] processors: batch: exporters: otlp: endpoint: oap:11800 # OAP Server 的 gRPC 地址 tls: insecure: true logging: logLevel: debug service: pipelines: metrics: receivers: [prometheus] processors: [batch] exporters: [otlp, logging]配置要点job_name必须与规则过滤条件一致MAL 规则文件顶部通过filter: { tags - tags.job_name windows-monitoring }只接收 job 名为windows-monitoring的样本因此此处 job 名不可随意修改targets指向 windows_exporter 的地址与端口示例中win-service:9182为 e2e 容器网络内的主机名实际部署时应替换为 Windows 主机的 IP 与 exporter 端口endpoint指向 OAP 的 gRPC 端口11800tls.insecure: true用于明文传输注意此写法适用于较新的 OTel Collector 版本旧版本如 0.29.0 需使用insecure: true的顶层写法配置文件中已有对应注释说明batchprocessor 对样本做批量发送优化loggingexporter 便于在调试阶段直接观察导出内容。3. 配置 SkyWalking OpenTelemetry receiverOAP 侧的 OpenTelemetry receiver 默认未激活需要通过环境变量或配置文件启用设置系统环境变量SW_OTEL_RECEIVERdefault或在application.yml中配置receiver-otel/selector${SW_OTEL_RECEIVER:default}启用 OTLP metrics handler 并加载 windows 规则参照 opentelemetry-receiver.md 中给出的通用写法将enabledOtelMetricsRules加入windows规则即可例如receiver-otel: selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:otlp-metrics} enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:windows}规则文件存放在$CLASSPATH/otel-rules下仓库源码位置为 oap-server/server-starter/src/main/resources/otel-rules/windows.yamlOAP 启动时加载。注意若规则文件格式不合法OAP 可能启动失败。支持的监控指标以下是 Windows 监控默认支持的面板指标。指标名带有meter_win前缀正是规则文件中metricPrefix: meter_win的产物。监控面板单位指标名Metric Name说明CPU Usage%meter_win_cpu_total_percentageCPU 总使用率百分比若有 2 个核心最大值为 200%CPU Average Used%meter_win_cpu_average_used各模式mode下 CPU 核心的平均使用百分比Memory RAM UsageMBmeter_win_memory_used物理内存总使用量Memory RAMMBmeter_win_memory_total、meter_win_memory_available、meter_win_memory_used物理内存统计Total / Available / UsedVirtual-Memory Usage%meter_win_memory_virtual_memory_percentage虚拟内存使用百分比Virtual-MemoryMBmeter_win_memory_virtual_memory_free、meter_win_memory_virtual_memory_total虚拟内存统计Free / TotalDisk R/WKB/smeter_win_disk_read、meter_win_disk_written磁盘读取与写入速率Network Bandwidth UsageKB/smeter_win_network_receive、meter_win_network_transmit网络接收与发送速率数据源均为 Prometheus windows_exporter。e2e 用例 metrics-has-value.yml 与 win-cases.yaml 中通过swctl metrics exec --expressionmeter_win_memory_virtual_memory_total实际验证了虚拟内存总容量指标能被正常查询到非空值。MAL 规则文件源码解析otel-rules/windows.yaml 是整个 Windows 监控的核心它定义了过滤条件、实体归属与全部指标表达式。先看文件头部的三个关键声明filter: { tags - tags.job_name windows-monitoring } # OpenTelemetry job 名 expSuffix: service([node_identifier_host_name], Layer.OS_WINDOWS) metricPrefix: meter_winfilter只处理 job 名为windows-monitoring的样本与 OpenTelemetry Collector 中scrape_configs.job_name一一对应expSuffix所有指标表达式统一附加的后缀将node_identifier_host_name标签值作为服务名并把服务归属到Layer.OS_WINDOWS层——这正是Windows 主机 一个 OS_WINDOWS 层 Service模型的实现来源。node_identifier_host_name标签由 OpenTelemetry receiver 自动打上其值取自 OTLP 资源属性net.host.name部分 OTLP 版本为host.name相关机制详见 opentelemetry-receiver.mdmetricPrefix生成的指标统一加meter_win前缀。CPU 指标metricsRules: # windows 不直接暴露 cpu load 指标 - name: cpu_total_percentage exp: (windows_cpu_time_total * 100).tagNotEqual(mode , idle).sum([node_identifier_host_name]).rate(PT1M) - name: cpu_average_used exp: (windows_cpu_time_total * 100).sum([node_identifier_host_name , mode]).rate(PT1M)windows_cpu_time_total是按 CPU modeidle / user / system 等拆分的累计计数器。cpu_total_percentage先过滤掉idle模式、按主机聚合后求 1 分钟速率再乘 100得到总使用率——这就是2 核时最大 200%的原因多个核心的时间计数被直接相加。cpu_average_used则保留mode维度聚合反映每个模式的占比。内存指标#memory - name: memory_total exp: windows_cs_physical_memory_bytes - name: memory_available exp: windows_os_physical_memory_free_bytes - name: memory_used exp: windows_cs_physical_memory_bytes - windows_os_physical_memory_free_bytes - name: memory_virtual_memory_free exp: windows_os_virtual_memory_free_bytes - name: memory_virtual_memory_total exp: windows_os_virtual_memory_bytes - name: memory_virtual_memory_percentage exp: 100 - ((windows_os_virtual_memory_free_bytes * 100) / windows_os_virtual_memory_bytes)物理内存的 Total / Available / Used 分别来自windows_cs_physical_memory_bytes与windows_os_physical_memory_free_bytes其中 Used 是两者的差值表达式虚拟内存的 Free / Total 来自windows_os_virtual_memory_free_bytes与windows_os_virtual_memory_bytes使用率则通过100 - (free * 100 / total)换算为百分比。磁盘指标#disk - name: disk_read exp: windows_logical_disk_read_bytes_total.sum([node_identifier_host_name]).rate(PT1M) - name: disk_written exp: windows_logical_disk_write_bytes_total.sum([node_identifier_host_name]).rate(PT1M)windows_logical_disk_read_bytes_total/windows_logical_disk_write_bytes_total是累计字节计数器先按主机聚合再取 1 分钟速率得到每秒读写字节数面板以 KB/s 展示。网络指标#network - name: network_receive exp: windows_net_bytes_received_total.sum([node_identifier_host_name]).irate() - name: network_transmit exp: windows_net_bytes_sent_total.sum([node_identifier_host_name]).irate()网络收发同样先按主机聚合再使用irate()瞬时速率计算每秒字节数。对比可见磁盘与网络这类按主机聚合后求速率的表达式结构完全一致区别仅在于磁盘用rate(PT1M)、网络用irate()。端到端验证e2e 用例仓库提供了完整的 Windows 监控 e2e 验证用例目录为 test/e2e-v2/cases/win包含docker-compose.yml拉起 OAP、BanyanDB 与 e2e-mock-sender 服务e2e.yaml定义触发动作——定时向 mock sender 发送otel-metrics请求使其把预置的 OTLP 指标数据推送给 OAPwin-cases.yaml两条验证断言swctl service ls能查询到服务名为10.211.55.3、layers含OS_WINDOWS的服务对应 service.yml 期望文件swctl metrics exec --expressionmeter_win_memory_virtual_memory_total --service-name10.211.55.3能查询到该指标的非空时序值对应 metrics-has-value.yml 期望文件mock-data/otel-mock-metrics.json预置的 OTLP 指标样本模拟 windows_exporter 采集结果。这套用例直接印证了两点一是 Windows 主机会以OS_WINDOWS层服务的形式出现在 OAP 中二是 MAL 规则生成的meter_win_*指标可以被标准指标查询协议正常检索可作为自建监控环境时的验证参考。自定义指标与仪表盘/config/otel-rules/windows.yaml仓库内对应 oap-server/server-starter/src/main/resources/otel-rules/windows.yaml定义了指标的表达式规则你可以按需修改新增指标在metricsRules中追加- name: 指标名与exp: MAL 表达式表达式基于 windows_exporter 暴露的原始指标如windows_*系列编写并注意expSuffix会自动附加service([node_identifier_host_name], Layer.OS_WINDOWS)因此聚合维度通常写[node_identifier_host_name]即可修改聚合方式例如将rate(PT1M)换成irate()、调整聚合标签组都会直接影响面板数值口径仪表盘面板面板 JSON 由 SkyWalking Horizon UI 前端包apache/skywalking-horizon-ui提供OAP 后端不再托管 UI 仪表盘 JSON修改面板需在前端侧进行。需要注意任何对规则文件的改动都要求 OAP 启动时能正确加载格式错误会导致启动失败规则语法细节可参考 MAL 设计文档。总结Windows 监控是 SkyWalking 通过 OpenTelemetry 生态实现零 SDK 接入主机可观测性的典型场景windows_exporter 负责采集OpenTelemetry Collector 负责协议转换与转发OAP 侧由 MAL 规则完成建模与聚合最终以OS_WINDOWS层服务的形态进入服务目录。理解了 windows.yaml 中 filter / expSuffix / metricPrefix / metricsRules 四段式结构以及每条面板指标背后的 MAL 表达式你就能按同样套路扩展出自定义的 Windows 监控指标。赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐SkyWalking Pulsar 监控接入实战OpenTelemetry Collector 采集链路、MAL 规则与指标面板详解SkyWalking Pulsar 监控接入实战OpenTelemetry Collector 采集链路、MAL 规则与指标面板详解 SkyWalking 通可观测性后端微服务云原生SkyWalking Pulsar 监控实战从 OpenTelemetry Collector 到 MAL 指标规则的全链路解析SkyWalking Pulsar 监控实战从 OpenTelemetry Collector 到 MAL 指标规则的全链路解析 本篇基于 SkyWalkin可观测性APM链路追踪指标监控日志分析微服务SkyWalking Elasticsearch 监控接入指南基于 elasticsearch-exporter、OpenTelemetry Collector 与 MAL 的全链路指标监控SkyWalking Elasticsearch 监控接入指南基于 elasticsearch exporter、OpenTelemetry Collecto可观测性APM链路追踪指标监控日志分析微服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考