如何核验OPC Publisher与IoT Hub间日志并排查历史数据缺失问题

1. 拉取并分析OPC Publisher模块日志 #

登录部署IoT Edge的边缘设备，执行以下命令拉取过去10天的模块日志：
iotedge logs opc-publisher --since 240h
重点检索以下类型的日志条目：

• 包含IoTHub、connection、timeout、401、403、5xx关键字的记录：用于排查IoT Hub侧连接鉴权失败、服务不可用、链路超时类问题
• 包含Queue full、buffer overflow关键字的记录：确认是否边缘侧消息积压阈值设置过低，超出缓存的消息被直接丢弃
• 包含OPC UA、endpoint、disconnect关键字的记录：排除OPC UA服务器主动断连、OPC Publisher会话异常中断的情况

如果日志留存时长不足10天，执行iotedge inspect opc-publisher查看模块重启记录，确认中断时间段内是否存在模块反复崩溃、异常退出的情况。

2. 核验IoT Edge运行时状态 #

执行以下命令拉取IoT Edge运行时日志：
iotedge system logs --since 240h

• 检索edgeHub日志中对应opc-publisher模块的消息上报记录，确认是edgeHub未收到OPC Publisher的消息，还是edgeHub转发到IoT Hub失败
• 检索edgeAgent日志中的模块状态变更记录，确认中断时间段内OPC Publisher是否处于运行状态，是否存在CPU、内存资源占满导致模块被系统强制终止的情况

同时排查边缘设备系统日志（Linux下查看/var/log/syslog，Windows下查看事件查看器），确认中断时间段内是否存在网络断连、设备休眠、系统时间跳变的情况：设备系统时间大幅偏移会导致IoT Hub拒绝接收带有异常时间戳的消息，是此类间歇性中断的常见原因

3. 匹配IoT Hub侧诊断日志 #

进入对应IoT Hub的日志查询页，运行以下Kusto语句拉取中断时间段的操作记录：

AzureDiagnostics
| where ResourceType == "IOTHUBS"
| where OperationName in ("DeviceConnect", "SendDeviceTelemetry")
| where deviceId == "替换为你的边缘设备ID"
| where TimeGenerated between (datetime(中断开始时间) .. datetime(中断结束时间))
| project TimeGenerated, OperationName, ResultType, ResultDescription, deviceId

重点关注ResultType为非Success的条目：

• 401 Unauthorized：排查边缘设备的SAS令牌/证书是否过期，是否存在IoT Hub侧设备权限变更
• 429 Throttling：确认是否IoT Hub的消息配额被耗尽，触发限流导致消息被丢弃
• 503 ServiceUnavailable：对应IoT Hub侧服务故障，可匹配平台服务健康公告确认

4. 验证OPC Publisher配置合理性 #

检查OPC Publisher的启动参数或配置文件：

• 确认--mq（消息队列大小）、--rc（重试次数）、--ft（故障容忍时间）配置是否合理：队列大小设置过小、重试次数为0时，短时间网络波动就会直接丢弃消息，网络恢复后也不会补发历史数据
• 确认是否开启了离线持久化缓存：如果未开启持久化存储，模块重启或网络中断期间的所有消息都会被直接丢弃

内容的提问来源于stack exchange，提问作者Maryo David