Orion订阅通知丢失问题排查请求

以下是针对订阅通知偶尔丢失问题的具体排查步骤：

• 核对节流配置实际生效情况
  先通过GET /v2/subscriptions/<你的订阅ID>接口查看订阅的节流参数，重点确认throttlingInterval和throttlingLimit的数值。Orion默认节流规则是短时间内相同类型的更新会合并通知，如果你的实体更新频率超过节流阈值，多次更新会被合并为一次通知，可能造成“丢失”的错觉。可以临时关闭节流（将两个参数设为0）测试，看是否还会出现丢通知的情况。

• 验证订阅触发条件匹配度
  检查订阅的entities、attrs、expression字段是否与实体更新的内容完全匹配：

  • 确认订阅指定的实体ID、类型和更新的实体一致；
  • 如果订阅指定了监听属性列表attrs，要确保更新的属性在列表内；
  • 若使用了expression过滤条件，验证实体更新后是否满足该表达式的逻辑。

• 查看Orion内部日志与队列状态
  直接查看Orion的运行日志（容器部署可执行docker logs <orion容器ID>，物理机部署默认日志路径通常为/var/log/contextBroker/contextBroker.log），搜索notification关键词，重点关注：

  • 是否有通知发送失败的错误记录（如响应码非2xx、超时）；
  • 是否出现队列溢出（queue full）的提示，默认notificationQueueSize为1000，若更新量过大可调整该启动参数扩大队列；
  • 日志中是否有未触发通知的原因说明（如属性未变化、条件不匹配）。

• 确认实体更新的触发逻辑
  Orion默认notifyOnChange为true，即仅当实体属性值实际发生变化时才会发送通知。如果你的更新操作是重复设置相同的属性值，不会触发通知。可以临时将订阅的notifyOnChange改为false，测试是否能收到所有更新通知，以此验证是否是重复值导致的“丢失”。

• 排查Orion到通知端点的深层网络问题
  虽然tcpdump未捕获到请求，但仍需确认：

  • 在Orion所在服务器上执行curl <你的通知URL>，验证端点是否能正常响应（返回2xx状态码）；
  • 检查Orion服务器是否有防火墙、安全组规则拦截出站请求到通知端点的端口；
  • 确认通知URL的域名解析在Orion服务器上是否正常（执行nslookup <域名>测试）。

• 检查Orion版本是否存在已知bug
  部分旧版本的Orion存在订阅通知丢失的已知问题，比如0.28.x及更早版本的队列处理缺陷。通过GET /version接口查看当前版本，若版本较老，建议升级到最新的稳定版（如3.x系列），验证问题是否解决。

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