📚 课程目录第4章工业设备软件指标采集与监控

4. 工业设备软件指标采集与监控

指标是工业设备软件可观测性的“体温计”。日志告诉你“发生了什么”，追踪告诉你“请求经过了哪里”，而指标告诉你“系统现在是否健康、趋势是否异常”。在工业网关这类长期无人值守的边缘设备上，指标采集往往是成本最低、收益最高的监控手段：它以固定频率采样少量数值，占用资源少，却能持续反映设备运行、软件性能和业务吞吐的真实状态。

四类指标：从硬件到业务的分层视角

工业网关的指标通常分为四层。第一层是设备运行指标，描述硬件与系统资源，例如 CPU 使用率、内存占用、磁盘剩余空间、网口收发速率、设备温度、供电电压、看门狗复位次数。第二层是软件性能指标，描述进程与服务的健康度，例如进程存活状态、线程数、GC 暂停时间、消息队列积压深度、Modbus/OPC UA 会话数、采集任务执行耗时。第三层是业务指标，直接对应生产价值，例如每秒采集点数、协议转换成功率、上云上报成功率、断线重连次数、数据缓存条数。第四层是链路与依赖指标，例如到 PLC 的往返时延、到云平台的连接状态、证书剩余有效期。

这四层不是并列关系，而是存在因果传导：设备资源紧张会拖慢软件性能，软件性能下降会导致业务指标恶化。因此监控设计要能沿这条链路定位根因，而不是只看单一层。

采集频率与精度：不是越快越好

采集频率决定监控的“时间分辨率”，精度决定数值的可信度。工业网关资源有限，频率过高会挤占采集与转发任务的 CPU 时间，反而制造问题。一个可参考的示例策略是：设备运行指标每 10 秒采集一次，软件性能指标每 5 秒一次，业务指标按事件累加后每 15 秒汇总一次，链路时延每 30 秒探测一次。这些数值属于示例，实际应根据设备算力、指标数量和告警时效要求调整。

精度方面要注意三点。其一，CPU 使用率应取采样窗口内的平均值而非瞬时值，避免毛刺误报；其二，计数器类指标（如累计采集点数、重连次数）应采集单调递增的原始值，由服务端做差分计算速率，而不是在设备端直接算速率，否则重启后计数归零会产生负跳变；其三，时间戳必须统一，建议设备端使用 NTP 同步，指标上报时携带采集时刻，避免因时钟漂移导致趋势错位。

指标与日志追踪的联动

指标擅长发现“异常存在”，但难以回答“为什么异常”。联动机制的核心是：当指标越过阈值时，自动触发一段高密度日志采集或追踪采样，把异常前后的上下文抓下来。例如，当“上云上报成功率”在 1 分钟内低于 95% 时，平台自动将该网关的日志级别从 INFO 临时提升到 DEBUG，持续 3 分钟，并记录该时段内的追踪 ID。运维人员随后可用这个追踪 ID 在日志系统中还原完整的采集—转换—上报链路，定位是 PLC 超时、证书过期还是网络抖动。

联动设计的关键是“指标做触发器，日志和追踪做证据链”。指标本身不必携带全部细节，但要能携带足够定位的标签，例如设备 ID、网关型号、固件版本、采集任务名。

实战任务：为工业网关设计指标采集方案

假设一台工业网关需要同时采集 3 台 Modbus PLC 的数据，并通过 MQTT 上报到云平台。下面给出一份可直接参考的采集方案配置示例，采用 YAML 描述采集任务与指标暴露方式。

gateway_metrics:
  device_id: GW-EDGE-001
  interval_default: 10s
  ntp_server: ntp.plant.local

  collectors:
    - name: system
      interval: 10s
      metrics: [cpu_usage_avg, mem_used_pct, disk_free_mb, temp_c, reset_count]
    - name: process
      interval: 5s
      metrics: [proc_alive, thread_count, gc_pause_ms, queue_depth]
    - name: business
      interval: 15s
      metrics: [points_collected_total, convert_ok_total, mqtt_pub_ok_total, reconnect_total]
    - name: link
      interval: 30s
      metrics: [plc_rtt_ms, cloud_conn_state, cert_days_left]

  alert_rules:
    - metric: mqtt_pub_ok_total
      expr: rate(5m) < 0.95
      action: raise_log_level(DEBUG, 3m) + tag_trace
    - metric: cpu_usage_avg
      expr: avg(1m) > 85
      action: notify + snapshot_top_threads

落地时按以下顺序推进：先确认每类指标的采集源（/proc、进程内埋点、协议栈回调、心跳探测），再确定频率与超时，然后定义指标命名与标签规范，最后配置告警规则与联动动作。验证方法是人为制造一次异常，例如断开 MQTT 连接 30 秒，观察 reconnect_total 是否递增、mqtt_pub_ok_total 速率是否下降、日志级别是否自动提升、追踪 ID 是否被标记。若这些现象按预期出现，说明指标采集与联动链路已经打通。

常见误区：把所有指标都设成 1 秒采集，导致网关 CPU 长期高于 70%，采集任务本身成为故障源；或者只采集业务指标而不采集资源指标，异常时无法判断是网络问题还是设备过载。频率与层级要匹配，才能既看得见又扛得住。

指标采集方案不是一次配置就结束的静态文档。随着设备固件升级、采集点位增加、云平台接口变化，指标清单和阈值都需要定期复核。建议每季度回顾一次告警误报率与漏报情况，据此调整频率、阈值和联动策略，让监控体系始终贴合现场真实运行状态。