配置托管标识的Azure Service Bus触发器函数未触发却持续向命名空间发送请求的问题排查

这种情况我之前碰到过好几次，核心是Service Bus Trigger的后台探测机制加上托管标识的身份验证流程在“悄悄干活”，给你拆解下原因和排查步骤：

你的Function用了ServiceBusTrigger且配置了托管标识，Function Runtime会在后台做两件事，这两件事都可能产生大量请求但不触发函数执行：

• 定期向Service Bus命名空间发送元数据探测请求（比如验证队列是否存在、获取队列状态）；
• 因为用了托管标识，每次请求SB前都要向Azure AD申请访问令牌，令牌过期前还会自动刷新，这个过程也会产生额外请求。

如果这些请求没触发函数执行，大概率是：Runtime能连上SB，但无法正确接收队列消息（或者队列本身是空的），但探测/令牌刷新的请求一直在持续。

1. 先查托管标识的权限配置 #

别光看“关联到了目标Service Bus命名空间”，得确认权限到底给到队列层面没：

• 托管标识需要至少Azure Service Bus Data Receiver权限（专门针对你的myQueue）；
• 如果只给了命名空间级别的Reader权限，Runtime能获取队列元数据，但没办法接收消息，就会一直反复重试探测，导致大量请求；
• 排查方式：在Azure Portal打开你的SB命名空间→Access control (IAM)→Role assignments，找到Function的托管标识，确认它的角色包含队列的消息接收权限。

2. 检查连接字符串的格式 #

用托管标识时，连接字符串的格式和传统密钥式不一样，必须是：

Endpoint=sb://<你的命名空间>.servicebus.windows.net/;Authentication=ManagedIdentity

如果你的ConnectionString配置还是传统的带密钥格式（哪怕没填密钥），Runtime会陷入错误的身份验证循环，不断发送请求尝试连接。

3. 调整Trigger的重试/轮询配置 #

Service Bus Trigger默认会根据队列负载动态调整轮询频率，但如果身份验证有问题，可能触发高频重试。你可以在host.json里手动限制：

{
  "extensions": {
    "serviceBus": {
      "clientRetryOptions": {
        "mode": "Exponential",
        "tryTimeout": "00:01:00",
        "delay": "00:00:00.800",
        "maxDelay": "00:01:00",
        "maxRetries": 3
      }
    }
  }
}

把maxRetries调低（比如设为3），重启Function后观察SB的请求量是否下降，以此确认是不是重试机制在搞鬼。

4. 挖Runtime的日志（Application Insights） #

哪怕没有函数执行记录，Function Runtime的后台日志还是会记录连接、身份验证的细节：

• 打开Application Insights→Logs，运行这个Kusto查询：

traces
| where message contains "ServiceBus" or message contains "ManagedIdentity"
| order by timestamp desc

看看有没有身份验证失败、连接超时、队列不存在之类的错误日志——这些都会导致Runtime不断重试请求。

• 临时给托管标识加上Azure Service Bus Data Owner权限（测试用，之后记得改回去），往队列发一条测试消息，看看函数能不能触发。如果能触发，说明之前的权限不够；如果还是不行，继续查连接字符串和日志。
• 把host.json里的maxRetries设为0，重启Function后看SB请求量是否骤降，就能确认是不是重试导致的请求了。

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