1. IoT平台可观测性全景

IoT平台的可观测性，不是把服务器监控那一套原样搬过来。它面对的是一个从物理世界出发、跨越多种协议、经过多级异步处理、最终抵达应用消费的链路。链路上的每一段都有不同的时间尺度、不同的失败模式和不同的观测手段。如果只盯着某一层，比如只看Kubernetes的CPU使用率，或者只看MQTT Broker的连接数，就无法回答“为什么某个设备上报的数据在应用侧延迟了40秒”这类真正影响业务的问题。

要建立全景视角，先要看清数据在IoT平台中的实际路径。以一个典型的设备遥测场景为例：温度传感器通过MQTT over TLS连接到接入网关，网关完成认证、限流、协议解析后，把消息写入消息队列（如Kafka）；流处理作业从队列消费，做窗口聚合、异常检测和格式转换；结果写入时序数据库（如TDengine或InfluxDB）和对象存储；应用侧通过查询API或订阅推送获取数据，最终呈现在看板或触发告警。这条链路上，设备侧、网络侧、接入层、消息层、计算层、存储层、应用层各自都有独立的可观测性需求，但又必须能串起来看。

这张全景图揭示了一个关键事实：IoT可观测性的三大支柱——指标、日志、追踪——在IoT场景中都有不同于传统Web服务的特殊性。

指标的特殊性在于“规模”和“维度爆炸”。一个中型IoT平台可能同时管理数十万台设备，每台设备有几十个测点。如果为每个设备的每个测点都建立独立的时序指标，指标基数会迅速膨胀到千万级，直接压垮Prometheus这类基于拉取模型的监控系统。实际落地时，通常采用分层聚合策略：设备侧只上报原始测点值，接入层按产品维度聚合出“在线设备数”“消息速率”“认证失败率”等平台级指标，流计算层再按业务维度聚合出“区域平均温度”“异常设备占比”等业务指标。原始测点数据进入时序数据库供查询，而不进入指标系统。这样既保留了排障所需的细粒度，又控制了指标基数。

日志的特殊性在于“设备侧不可控”和“网络边界”。云端服务的日志可以统一采集、格式化、集中存储，但设备侧日志往往受限于存储空间、网络带宽和功耗，不可能全量上传。实际做法是分级处理：设备本地只保留最近若干条关键日志（如重启原因、连接失败码），云端通过MQTT下行通道按需拉取；接入层和计算层的日志则全量采集，但必须携带设备ID、产品ID、消息ID等关联字段，否则海量日志无法定位到具体设备。一个常见的坑是：设备日志时间戳不可信（设备可能没有RTC或时间未同步），需要在接入层打上服务端接收时间，并在日志中同时保留两个时间戳。

追踪的特殊性在于“异步跨越”和“上下文传播”。在HTTP微服务中，一次请求的Trace ID可以通过HTTP Header一路透传。但在IoT链路中，设备通过MQTT发布消息后连接可能立即断开，消息进入Kafka后被流处理作业异步消费，这中间没有天然的请求上下文。要实现全链路追踪，必须在消息体中注入Trace ID和Span ID，并在每个处理节点（接入网关、规则引擎、Flink算子、写入连接器）中正确提取和传递。对于不支持自定义消息体的老旧设备，只能在接入层生成Trace ID并绑定设备ID，后续链路用设备ID+时间窗口做关联，精度会下降但聊胜于无。

从工程实践角度，建议在平台建设初期就确定可观测性的三个基础约定。第一，统一关联ID：每条消息在接入层生成全局唯一的message_id，并尽可能携带device_id和trace_id，这三个字段贯穿日志、指标标签和追踪Span。第二，统一时间基准：所有服务端节点启用NTP同步，设备上报时间与服务端接收时间分开记录，避免时间跳变导致链路分析错乱。第三，分层采集策略：设备侧轻量采集、边缘侧聚合缓冲、云端全量处理，每一层都有明确的采集范围和上报频率。

以一个具体的排障场景收尾：应用侧反馈“某区域温度看板延迟约30秒”。按照全景视图逐层排查——先看应用层查询API的P99延迟（指标），发现正常；再看存储层写入延迟（指标），发现正常；接着用trace_id追踪一条具体消息，发现从Kafka消费到Flink输出的Span耗时异常，达到25秒；最后查Flink作业日志，发现该算子频繁反压（backpressure），原因是下游时序数据库写入连接池耗尽。整个定位过程依赖三支柱的协同：指标发现异常层，追踪缩小范围，日志确认根因。这正是全景视角的价值——不是三个独立工具，而是一条可观测性闭环。