我们有一个Azure设置,其中包括一个Azure事件网格主题和一个Azure函数服务,其订阅了通过不同前缀过滤器订阅主题的约15个函数。Azure函数服务被设置为消耗基础资源,并应该能够根据喜好进行扩展。
每个订阅都被设置为尝试在最长4小时内进行10次交付,然后将事件删除。到目前为止一切顺利,设置按预期工作 - 大多数时间。
在某些情况下,我们不知道情况的情况下,似乎事件网格主题无法将事件传递给不同的函数。我们所看到的是,我们的死信存储填充有未传递的事件。
现在来到我的问题
从日志中,我们可以看到各种事件未被传送的原因。原因通常是Outcome: Probation。我们找不到Microsoft提供的有关此实际含义的任何信息。
此外,网格会在超时策略(4小时)和交付尝试策略(10次重试)均未超过之前将事件添加到死信日志中。有时函数服务处于空闲状态,未收到来自网格的任何事件。
你们这些聪明的人有没有想法,可以帮助我们排除故障?当出现错误消息Probation时,Grid和Function App之间发生了什么?我们注意到网格从Function App到连接的数量相对较高,而传送的事件数量相对较少。除事件网格外,没有其他传入连接到Function App。
以下是死信消息的示例:
每个订阅都被设置为尝试在最长4小时内进行10次交付,然后将事件删除。到目前为止一切顺利,设置按预期工作 - 大多数时间。
在某些情况下,我们不知道情况的情况下,似乎事件网格主题无法将事件传递给不同的函数。我们所看到的是,我们的死信存储填充有未传递的事件。
现在来到我的问题
从日志中,我们可以看到各种事件未被传送的原因。原因通常是Outcome: Probation。我们找不到Microsoft提供的有关此实际含义的任何信息。
此外,网格会在超时策略(4小时)和交付尝试策略(10次重试)均未超过之前将事件添加到死信日志中。有时函数服务处于空闲状态,未收到来自网格的任何事件。
你们这些聪明的人有没有想法,可以帮助我们排除故障?当出现错误消息Probation时,Grid和Function App之间发生了什么?我们注意到网格从Function App到连接的数量相对较高,而传送的事件数量相对较少。除事件网格外,没有其他传入连接到Function App。
以下是死信消息的示例:
[{
"id":"a40a1f02-5ec8-46c3-a349-aea6aaff646f",
"eventTime":"2020-06-02T17:45:09.9710145Z",
"eventType":"mitbalAdded",
"dataVersion":"1",
"metadataVersion":"1",
"topic":"/subscriptions/XXXXXXX/resourceGroups/XXXX_STAGING/providers/Microsoft.EventGrid/topics/XXXXXstaging",
"subject":"odl/type/mitbal/v1",
"deadLetterReason":"TimeToLiveExceeded",
"deliveryAttempts":6,
"lastDeliveryOutcome":"Probation",
"publishTime":"2020-06-02T17:45:10.1869491Z",
"lastDeliveryAttemptTime":"2020-06-02T19:30:10.5756332Z",
"data":"<?xml version=\"1.0\" encoding=\"utf-8\"?><Stock><Action>ADD</Action><Id>123456</Id><Store>123</Store><Shelf>1</Shelf></Stock>"
}]
函数服务度量指标
- 蓝色 = 连接数 (计数)
- 红色 = 函数执行次数 (计数)
- 白色 = 请求次数 (计数)
azcommunity[at]microsoft[dot]com
并附上此线程的链接吗? - PramodValavala