SkyWalking Linux 虚拟机监控接入指南node-exporter OpenTelemetry 与 Telegraf 双通路详解【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking本篇指南以 SkyWalking OAP 的 Linux 虚拟机VM监控能力为核心讲解如何借助 Prometheus node-exporter 与 OpenTelemetry Collector或 InfluxDB Telegraf把 VM 的 CPU、内存、磁盘、网络等系统指标送入 SkyWalking 的 Meter 系统并以OS_LINUX层的 Service 实体进行观测。读完本文你将掌握两条数据通路的完整部署步骤、MAL 指标规则的含义、内置指标清单以及如何自定义指标与仪表盘模板。监控架构总览SkyWalking 对 Linux 虚拟机的基础设施监控本质上是将机器建模为一个位于Layer: OS_LINUX的 Service指标数据统一汇入 Meter 系统再由 OAP 通过 MALMetrics Analysis Language 表达式完成过滤、计算与聚合后落库。官方文档提供了两条完全独立的数据通路OpenTelemetry 通路Prometheus node-exporter → OpenTelemetry CollectorPrometheus Receiver OTLP gRPC Exporter→ OAP 的 OpenTelemetry Receiver → Meter SystemTelegraf 通路InfluxDB Telegraf 各输入插件 → HTTP/JSON 上报 → OAP 的 Telegraf Receiver → Meter System。无论走哪条通路最终在 OAP 中形成的指标实体与可视化方式是一致的两条通路甚至可以并行使用、互为备份。数据流详解OpenTelemetry Receiver 通路采集在每台目标 VM 上部署 Prometheus node-exporter由它暴露/metrics端点产出node_cpu_seconds_total、node_memory_MemTotal_bytes等原始指标转送OpenTelemetry Collector 通过内置的 Prometheus Receiver 抓取 node-exporter 指标再经 OTLP gRPC Exporter 推送给 SkyWalking OAP Server解析入库OAP 的 OpenTelemetry Receiver 按otel-rules/vm.yaml中定义的 MAL 表达式对指标做过滤、计算与聚合最终写入存储。这条链路下OAP 会为采集到的数据样本自动附加一个键为node_identifier_host_name的标签其值取自 OpenTelemetry proto 资源属性中的net.host.name部分 OTLP 版本为host.name正是它被用作 Service 实体的标识也就是vm.yaml规则中service([node_identifier_host_name], Layer.OS_LINUX)的来源。需要留意的是资源作用域中属性键名里的点号.会被转换为下划线_而指标作用域中不做转换。Telegraf Receiver 通路采集在目标 VM 上运行 InfluxDB Telegraf通过其 input plugins 采集各类系统指标其中cpu、mem、system、disk、diskio 输入插件必须在telegraf.conf中显式启用net、netstat 插件按需启用上报Telegraf 通过[[outputs.http]]以HTTP JSON 格式将指标发送到 Telegraf Receiver转换入库Telegraf Receiver 插件接收、处理并转换为 Meter 系统指标送入 OAP 的 Meter 系统由 MAL 表达式完成过滤/计算/聚合后存储对于 Telegraf 通路meter_vm_cpu_average_used表示每个 CPU 核在各模式下的平均使用率。环境搭建与配置通路一node-exporter OpenTelemetry Collector第 1 步部署 node-exporter。在每台目标 VM 上安装并启动 node-exporter默认监听9100端口参见 Prometheus 官方 node-exporter 使用指南。第 2 步配置 OpenTelemetry Collector。仓库在端到端测试用例中提供了一份可直接参考的 Collector 配置otel-collector-config.yaml。核心要点如下receivers: prometheus: config: scrape_configs: - job_name: vm-monitoring # 必须与 vm.yaml 规则中的 filter 保持一致 scrape_interval: 10s static_configs: - targets: [vm-service:9100] processors: batch: exporters: otlp: endpoint: oap:11800 # OAP Server 地址 tls: insecure: true logging: loglevel: debug service: pipelines: metrics: receivers: [prometheus] processors: [batch] exporters: [otlp, logging]其中两点对后续是否有数据至关重要job_name必须命名为vm-monitoring因为 otel-rules/vm.yaml 的过滤器正是filter: { tags - tags.job_name vm-monitoring }只放行该 job 采集到的指标exporters.otlp.endpoint指向 OAP 的 gRPC 端口默认11800。若使用 OTEL 0.34.0 之前的版本需把tls.insecure替换为顶层insecure: true写法配置中已用注释标明。第 3 步启用 OAP 的 OpenTelemetry Receiver。在application.yml源码位于 application.yml中激活receiver-otel模块并加载vm规则receiver-otel: selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:otlp-metrics} enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:istio-controlplane}将enabledOtelMetricsRules修改为包含vm与otel-rules/vm.yaml同名即可等价于通过环境变量启动SW_OTEL_RECEIVERdefault SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULESvm ./bin/oapServer.sh仓库的 e2e 测试 docker-compose.yml 正是这样组合的SW_OTEL_RECEIVER: defaultSW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES: vm并同时拉起vm-servicenode-exporter 容器与otel-collector三个服务。通路二InfluxDB Telegraf第 1 步编写telegraf.conf。依据 Telegraf 官方文档 配置。仓库测试用例提供了完整示例telegraf.conf其关键片段[agent] interval 10s hostname vm-service # 将被用作 Service 标识host 标签 omit_hostname false # 输出必须使用 HTTP 输出插件且 data_format 必须为 json [[outputs.http]] url http://oap:12800/telegraf # OAP 的 Telegraf Receiver HTTP 端点 timeout 10s method POST data_format json # 必选输入插件cpu / mem / system / disk / diskio [[inputs.cpu]] percpu true totalcpu true report_active true [[inputs.mem]] [[inputs.system]] [[inputs.disk]] [[inputs.diskio]] [[inputs.net]] [[inputs.netstat]]第 2 步遵守 Telegraf Receiver 的硬性约束。从 Telegraf Receiver 文档 可以确认以下三点限制缺一不可输出方式模块通过HTTP接收指标telegraf.conf中必须配置[[outputs.http]]数据格式模块只处理 Telegraf 的JSON指标格式因此必须设置data_format json时间戳单位JSON 输出默认时间戳单位为秒模块只处理秒级时间戳若需显式配置json_timestamp_units 1s是唯一可行取值。第 3 步启用 OAP 的 Telegraf Receiver。默认的receiver-telegraf配置片段如下默认加载vm规则receiver-telegraf: selector: ${SW_RECEIVER_TELEGRAF:default} default: activeFiles: ${SW_RECEIVER_TELEGRAF_ACTIVE_FILES:vm}通过环境变量SW_RECEIVER_TELEGRAFdefault与SW_RECEIVER_TELEGRAF_ACTIVE_FILESvm即可激活。OAP 在启动时加载$CLASSPATH/telegraf-rules下的规则文件若配置格式不合法OAP 可能无法启动。支持的监控指标一览两条通路最终产出的指标带meter_vm前缀完全一致官方文档给出的完整清单如下监控面板单位指标名称说明数据来源CPU Usage%meter_vm_cpu_total_percentageCPU 核心总使用率百分比若机器有 2 个核心最大值为 200%node-exporter / Telegraf input pluginMemory RAM UsageMBmeter_vm_memory_used内存总使用量node-exporter / Telegraf input pluginMemory Swap Usage%meter_vm_memory_swap_percentage交换内存使用率百分比node-exporter / Telegraf input pluginCPU Average Used%meter_vm_cpu_average_used每个 CPU 核在各模式下的平均使用率node-exporter / Telegraf input pluginCPU Load—meter_vm_cpu_load1/meter_vm_cpu_load5/meter_vm_cpu_load15CPU 1 分钟 / 5 分钟 / 15 分钟平均负载node-exporter / Telegraf input pluginMemory RAMMBmeter_vm_memory_total/meter_vm_memory_available/meter_vm_memory_used/meter_vm_memory_buff_cacheRAM 统计Total / Available / Used / Buff-Cachenode-exporter / Telegraf input pluginMemory SwapMBmeter_vm_memory_swap_free/meter_vm_memory_swap_totalSwap 统计Free / Totalnode-exporter / Telegraf input pluginFile System Mountpoint Usage%meter_vm_filesystem_percentage各挂载点文件系统使用率百分比node-exporter / Telegraf input pluginDisk R/WKB/smeter_vm_disk_read/meter_vm_disk_written磁盘读取与写入速率node-exporter / Telegraf input pluginNetwork Bandwidth UsageKB/smeter_vm_network_receive/meter_vm_network_transmit网络接收与发送速率node-exporter / Telegraf input pluginNetwork Status—meter_vm_tcp_curr_estab/meter_vm_tcp_tw/meter_vm_tcp_alloc/meter_vm_sockets_used/meter_vm_udp_inuseTCP 已建立数 / TCP Time Wait 数 / TCP 分配数 / 使用中的 socket 数 / UDP 使用数node-exporter / Telegraf input pluginFilefd Allocated—meter_vm_filefd_allocated已分配的文件描述符数量node-exporter注meter_vm_filefd_allocated仅由 node-exporter 通路提供Telegraf 默认输入插件不采集该指标meter_vm_cpu_average_used在 Telegraf 通路中的语义已在上文说明。MAL 规则源码级解析otel-rules/vm.yamlnode-exporter 通路规则文件位于 otel-rules/vm.yaml头部定义如下filter: { tags - tags.job_name vm-monitoring } # OpenTelemetry job 名称 expSuffix: service([node_identifier_host_name], Layer.OS_LINUX) metricPrefix: meter_vm metricsRules:filter只放行job_name vm-monitoring的指标与 Collector 配置中的job_name严格对应expSuffix按node_identifier_host_name标签聚合为 Service并声明 Layer 为OS_LINUXmetricPrefix统一加上meter_vm前缀因此规则名cpu_total_percentage实际产出meter_vm_cpu_total_percentage。规则主体的几个代表性表达式# CPU剔除 idle 模式后求 1 分钟速率再乘以 100 得百分比 - name: cpu_total_percentage exp: (node_cpu_seconds_total * 100).tagNotEqual(mode, idle).sum([node_identifier_host_name]).rate(PT1M) # 内存MemTotal 减去 MemAvailable 即已用内存 - name: memory_used exp: node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes # 文件系统按 host 与 mountpoint 维度求使用率 - name: filesystem_percentage exp: 100 - ((node_filesystem_avail_bytes * 100).sum([node_identifier_host_name, mountpoint]) / node_filesystem_size_bytes.sum([node_identifier_host_name, mountpoint])) # 网络irate 计算瞬时速率 - name: network_receive exp: node_network_receive_bytes_total.sum([node_identifier_host_name]).irate()可见磁盘、网络等速率型指标分别使用.rate(PT1M)1 分钟平均速率与.irate()瞬时速率两种计算方式内存类直接映射 node-exporter 原始指标负载类则把node_load1/5/15乘以 100 以放大展示。完整规则还覆盖了memory_buff_cache、memory_swap_*、tcp_*、sockets_used、udp_inuse、filefd_allocated等全部上表指标。telegraf-rules/vm.yamlTelegraf 通路规则文件位于 telegraf-rules/vm.yaml头部与字段映射有所不同expSuffix: service([host], Layer.OS_LINUX) metricPrefix: meter_vm metricsRules: - name: cpu_total_percentage exp: cpu_usage_active.tagEqual(cpu, cpu-total) - name: cpu_average_used exp: cpu_usage_active.tagNotEqual(cpu, cpu-total).avg([host, cpu]) - name: memory_used exp: mem_used - name: filesystem_percentage exp: disk_used_percent.avg([host, device]) - name: disk_read exp: diskio_read_bytes.rate(PT1M) - name: network_receive exp: net_bytes_recv.irate() - name: tcp_curr_estab exp: netstat_tcp_established与 OTLP 通路相比Telegraf 通路直接消费cpu_usage_active、mem_*、disk_used_percent、diskio_*、net_*、netstat_*等 Telegraf 插件字段聚合维度标签为host文件系统按host device维度求平均。两份vm.yaml的规则名完全对齐因此两条通路产出的meter_vm_*指标体系天然一致UI 面板可以无缝共用。内置仪表盘模板与自定义OAP 启动时会通过 UI 模板初始化机制加载$CLASSPATH/ui-initialized-templates下的面板模板Linux 监控面板位于 os_linux 目录包含linux-root.json虚拟机监控总览面板linux-service.json单台 VMService 视角的详细面板。以 linux-service.json 为例它由多个 Widget 构成例如Filefd Allocated面板直接查询meter_vm_filefd_allocatedNetwork Status面板把meter_vm_tcp_curr_estab、meter_vm_tcp_tw、meter_vm_tcp_alloc、meter_vm_sockets_used、meter_vm_udp_inuse五条指标画在同一条折线图上Network Bandwidth Usage (KB/s)与Disk R/W面板使用表达式meter_vm_network_receive/1024、meter_vm_disk_read/1024等把原始字节数值转换为 KB/s 展示。如需自定义指标、表达式或面板可按以下路径进行指标与表达式修改 otel-rules/vm.yaml 或 telegraf-rules/vm.yaml按 MAL 语法 增加metricsRules条目产出新的meter_vm_*指标面板在 os_linux 目录 中调整 Widget 的expressions与metricConfig即可让 UI 展示自定义指标。注意这些目录otel-rules/、telegraf-rules/、ui-initialized-templates/在打包时被排除在 jar 之外以保留在config/目录供用户直接编辑参见 server-starter/pom.xml。端到端验证仓库在 test/e2e-v2/cases/vm 下提供了完整的验证用例包含prometheus-node-exporter/、telegraf/、zabbix/三个子场景。以 node-exporter 场景为例docker-compose.yml 同时拉起 OAP、node-exporter 容器与otel/opentelemetry-collector并注入SW_OTEL_RECEIVERdefault、SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULESvm。随后 vm-cases.yaml 通过 swctl 工具对 OAP GraphQL 接口发起查询断言例如swctl --display yaml --base-urlhttp://${oap_host}:${oap_12800}/graphql \ metrics exec --expressionmeter_vm_memory_used --service-namevm-service其预期结果定义在 metrics-has-value.yml 中——要求返回TIME_SERIES_VALUES类型的时序值且value非空。这些用例同时印证了两点其一Service 名称来自 node-exporter 所在主机的标识示例中为vm-service其二meter_vm_*指标可按metrics exec --expression直接查询。部署完成后你可以用同样的方式在 UI 中看到以OS_LINUX为 Layer 的虚拟机 Service并在Linux面板下查看全部指标曲线。相关文档OpenTelemetry ReceiverOTLP 处理器与全部otel-rules规则清单Telegraf ReceiverHTTP/JSON 上报格式与receiver-telegraf配置Meter 系统指标模型与查询体系MAL 指标分析语言vm.yaml规则使用的表达式语法【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
