如何在不改代码的情况下监测Slack客户端与Azure Bot的单向延迟

刚好之前处理过类似的场景，给你几个不用改代码就能在Azure上实现Slack机器人单向延迟监测的方案，都是实际验证过可行的：

1. 利用Azure Application Gateway（推荐） #

如果你的机器人部署在App Service、VM或者容器后面，且已经用了Application Gateway做入口转发，这是最省心的方案：

• 先开启Gateway的访问日志（Access Logs），把日志发送到你的Log Analytics工作区。
• 登录Log Analytics，用Kusto查询分析AzureDiagnostics表：
  • 监测用户消息到机器人的延迟：过滤来自Slack的入站请求（可以通过host_s匹配Slack的回调域名），提取请求头里的Date字段（Slack发送请求的时间），和Gateway记录的requestStartTime_t（机器人接收到请求的时间）做时间差，就是这段单向延迟。
  • 监测机器人响应到用户的延迟：过滤机器人发往Slack API的出站请求（比如host_s匹配slack.com），用requestEndTime_t（Gateway发送完响应的时间）减去requestStartTime_t（机器人发起响应请求的时间），得到这段延迟。
• 优势：配置简单，日志自带时间戳，能直接计算精确的单向延迟，不用额外开发。

2. Azure Network Watcher + Log Analytics #

如果没有用Application Gateway，Network Watcher的连接监控和数据包捕获能帮你搞定：

• 使用Connection Monitor：添加两个监测端点，一个是你的机器人资源（比如App Service的出站IP、VM的私有IP），另一个是Slack的API端点（https://slack.com/api/）。开启后，它会定期测试双向延迟，你可以在Log Analytics的NetworkMonitoring表中提取单向的入站/出站延迟数据。
• 进阶用Packet Capture：针对机器人所在资源的NSG，开启数据包捕获，捕获所有和Slack相关的流量，把捕获文件存储到Blob存储后，导入Log Analytics。用Kusto查询匹配请求和响应数据包的时间戳，计算单向延迟。
• 注意：Connection Monitor适合长期监测，Packet Capture适合临时排查，前者更稳定。

3. Azure Functions Proxies（针对Functions机器人） #

如果你的机器人是用Azure Functions构建的，Functions Proxies可以做一层无代码的代理层：

• 在Functions里创建一个Proxy，把所有Slack的请求转发到你的机器人函数。
• 开启Proxies的日志，发送到Log Analytics。
• 在日志里提取Proxy接收到请求的时间（用户消息到达Azure的时间）和转发到函数的时间（机器人接收到请求的时间），差值就是用户到机器人的延迟；同理，函数响应到达Proxy的时间和Proxy发送到Slack的时间差值，就是机器人到用户的延迟。

为什么Application Insight直接用不了？ #

你之前研究的Application Insight，默认的自动遥测只能拿到整个请求的往返时间，而且因为无法修改代码，没法添加自定义时间戳来拆分单向延迟。但如果结合上面的方案，比如把Application Gateway的日志和Application Insight的遥测通过请求ID关联起来，也能更精准地拆分延迟，不过单独用Application Insight确实满足不了你的需求。

内容的提问来源于stack exchange，提问作者Planet-Zoom