📚 课程目录第4章 CoAP与LwM2M协议可观测性

4. CoAP与LwM2M协议可观测性

在物联网平台中，CoAP 与 LwM2M 常被用于低功耗、窄带宽、海量设备场景。与 HTTP/MQTT 相比，它们更强调报文紧凑、交互次数少、设备侧资源占用低。但这也意味着可观测性不能照搬“请求日志 + 指标 + 链路追踪”的常规做法：CoAP 基于 UDP，没有连接状态；LwM2M 在 CoAP 之上增加了对象/资源模型、注册、更新、Observe 和 Exec 等管理语义。要看清系统行为，必须把协议层、设备管理语义和平台侧处理链结合起来观察。

一、CoAP 可观测性的三个关键维度

CoAP 的可观测性首先落在报文层。每个 CoAP 报文包含 Version、Type、Token Length、Code、Message ID、Token、Options 和 Payload。其中 Type 分为 CON（需确认）、NON（不需确认）、ACK（确认）和 RST（复位）；Code 表示方法或响应码，如 0.01 GET、0.02 POST、2.05 Content、4.04 Not Found、5.03 Service Unavailable。Message ID 用于匹配 ACK/RST，Token 用于匹配请求与响应。平台侧采集时，应至少记录：设备标识、源/目的地址与端口、Type、Code、Message ID、Token、Uri-Path、Observe 选项、Block1/Block2 分块信息、报文大小、到达时间与处理耗时。

这些字段能直接回答几个排障问题：设备是否收到 ACK？响应是否与请求 Token 匹配？是否因分块传输导致超时？Observe 通知是否按预期到达？例如，某设备上报温度时使用 CON POST，平台在 2 秒内未回 ACK，设备会重传，若平台侧只记录业务日志，就会看到重复数据却找不到原因；而记录 Message ID 与重传次数后，可以判断是网络丢包还是平台处理阻塞。

二、LwM2M 管理操作的可追踪性

LwM2M 把设备能力抽象为 Object / Object Instance / Resource，例如 /3/0/0 表示 Device 对象的 Manufacturer Resource，/3303/0/5700 表示 Temperature 对象的 Sensor Value。平台对设备的操作包括 Register、Update、Deregister、Read、Write、Execute、Discover、Observe、Notify 等。可观测性要追踪的是“谁在什么时间对哪个资源做了什么操作，结果如何”。

以固件升级为例，平台先 Write 到 /5/0/1（Package URI），再 Execute /5/0/2（Update），设备随后通过 Notify 上报 /5/0/3（State）和 /5/0/5（Update Result）。如果只监控 HTTP 接口，会看到“升级任务已下发”，但无法判断设备是否真正开始下载、是否校验失败、是否回滚。因此，LwM2M 操作追踪应把 CoAP 报文与 LwM2M 资源路径关联起来，形成“管理操作—资源路径—CoAP 交互—设备状态”的链路。

三、资源消耗监控：轻量协议不等于零成本

CoAP/LwM2M 设备通常资源受限，可观测性本身也会消耗资源。需要监控的设备侧指标包括：CoAP 报文收发速率、重传次数、平均响应时延、DTLS 握手次数与失败率、Observe 通知频率、Block 分块传输次数、内存池使用量、任务栈水位、电池电压与休眠占比。平台侧则要关注：每设备会话数、注册更新频率、请求队列深度、CoAP 解析失败率、Token 冲突数、LwM2M 操作成功率与超时率。

一个常见误区是只监控“设备在线数”。假设 1 万台设备，每台每 30 秒发一次 Update，平台每秒要处理约 333 个 CoAP 报文；若其中 5% 因网络抖动重传，峰值会额外增加约 17 报文/秒。若平台侧队列深度超过 200 且处理时延从 20ms 升到 200ms，设备会因 ACK 超时继续重传，形成正反馈。此时应观察“重传率—队列深度—处理时延”三者的相关性，而不是单独看 CPU 使用率。

四、可观测性数据采集的实现要点

采集 CoAP/LwM2M 数据时，建议在接入网关中做无侵入埋点：在报文解码后、业务处理前记录原始字段；在响应发送后记录处理耗时与结果码；在 LwM2M 引擎中记录资源路径与操作类型。日志应采用结构化格式，便于按设备、Token、资源路径检索。例如：

{
  "ts": "2025-03-18T10:22:31.482Z",
  "device_id": "urn:dev:001",
  "coap": {
    "type": "CON",
    "code": "0.02",
    "mid": 41237,
    "token": "a1b2c3",
    "uri_path": "/3303/0/5700",
    "observe": 0,
    "payload_size": 18
  },
  "lwm2m": {
    "operation": "Notify",
    "path": "/3303/0/5700",
    "value": 23.6
  },
  "latency_ms": 34,
  "result": "success"
}

指标侧建议使用直方图记录 CoAP 处理时延，用计数器记录重传、超时、4.xx/5.xx 响应，用仪表记录在线设备数与队列深度。追踪侧可为每次 LwM2M 管理操作生成 trace_id，并把它写入 CoAP Token 或自定义 Option，使平台内部处理链与设备交互链可以串联。需要注意，Token 长度有限，不能直接塞入完整 trace_id，通常采用短随机标识并在网关侧做映射。

五、设备管理操作追踪的闭环判断

以“远程重启”为例，平台执行 Execute /3/0/4。可观测性应回答：请求是否发出、设备是否 ACK、Execute 是否返回 2.04 Changed、设备是否在预期时间内重新注册、注册时携带的 Lifetime 与 Binding 是否变化、重启后资源值是否恢复。若 30 秒内未收到重新注册，应检查 CoAP 重传次数、DTLS 会话是否重建、设备是否进入休眠。若收到 4.00 Bad Request，则说明资源路径或参数不匹配，应回到 LwM2M 对象定义核对。

排障时优先看三个信号：CoAP 层是否有 ACK/RST，LwM2M 层操作码是否成功，设备状态是否发生预期迁移。三者按“报文—操作—状态”顺序逐层收敛，比直接翻业务日志更快定位问题。

最后，CoAP/LwM2M 可观测性要避免两个极端：一是只采集业务指标，丢失协议层细节，导致重传、分块、Observe 异常无法解释；二是全量抓包长期存储，成本和隐私风险高。合理做法是常态保留聚合指标与结构化操作日志，异常时按设备或 Token 开启短期报文采样，并把 LwM2M 资源路径作为核心关联键，形成可查询、可告警、可回溯的轻量级观测体系。