如何利用Azure监控/日志定位Service Bus消息的读取者

嗨，针对你遇到的Service Bus消息莫名消失、怀疑是本地开发同学误消费的问题，我来分享几个用Azure监控和日志定位读取者的实用方法：

• 先确保Service Bus诊断日志已启用
  这是第一步，不然根本没数据可查。打开Azure门户找到你的Service Bus命名空间，进入「诊断设置」页面，添加新的诊断设置，勾选OperationalLogs和RequestLogs这两个日志类别，然后把日志输出到Log Analytics工作区——这是后续查询日志的核心载体。

• 用Log Analytics查询读取操作的详细日志
  进入对应的Log Analytics工作区，打开日志查询界面，用Kusto语言写查询语句筛选读取消息的操作，比如：

  AzureDiagnostics
  | where ResourceProvider == "MICROSOFT.SERVICEBUS"
  | where OperationName in ("ReceiveMessage", "PeekMessage")
  | project TimeGenerated, OperationName, MessageId, ClientIPAddress, ClientRequestId, Identity
  

  其中ReceiveMessage是实际消费（会删除消息）的操作，PeekMessage是只查看不删除的操作。通过查询结果里的字段，你能看到消息被读取的时间、发起请求的客户端IP、请求ID，还有调用者的身份信息（如果用了Azure AD认证的话）。

• 精准定位本地开发环境的读取者
  重点关注这几个字段：

  • ClientIPAddress：如果是开发者本地机器发起的请求，这里会显示他们的公网IP或者企业内网IP，结合你们团队的IP范围就能缩小范围；
  • Identity：如果用Azure AD认证的话，这里会显示开发者的用户ID或者服务主体ID，能直接定位到具体是谁；
  • ClientRequestId：如果你们的API在本地运行时会带上特定的请求ID标识，也可以通过这个字段快速筛选出本地环境的请求。

• 结合Service Bus指标辅助验证
  除了日志，还可以去Service Bus命名空间的「指标」页面，查看Active Connections（活跃连接数）和Messages Received（消息接收量）这两个指标。对比日志里出现异常读取的时间点，看看指标有没有对应的峰值，这样能更确认是不是本地环境在消费消息。

• 可选：给消息加自定义标识强化追踪
  如果现有日志信息还不够，你可以让发送消息的服务给每条消息加上自定义属性（比如SourceService标识发送方），之后在Log Analytics的查询里就能通过这个属性过滤出目标消息，再结合读取者的信息，快速区分预期和非预期的消费方。

备注：内容来源于stack exchange，提问作者WBuck