azure - Azure 的事件网格的回复策略似乎不起作用

Question

在过去的一周里，我一直在尝试通过带有 webhook 的事件网格来实现事件传播，但我遇到了一个问题，即使订阅者返回了一个应该触发重试的错误代码（任何https://docs. microsoft.com/en-us/azure/event-grid/delivery-and-retry#failure-codes），但它只是没有发生。显示重试策略配置。服务器当前总是以 503 响应，理论上应该将事件标记为无法传递。有什么我想念的吗？

哦，我可能应该提到我正在记录所有事件，而这些事件只发生一次。

标签： azureazure-eventgrid

Answer 1

以下是使用死信选项测试重试策略的示例。所有功能都运行良好。

1. 我有一个用于触发事件的自定义主题（topicTester100）

    [
      {
        "topic":null,
        "id":"690bb0ec-7aad-4ed9-a7a1-3b6c8899c57c",
        "subject":"/myapp/vehicles/motorcycles",
        "eventType":"retrytest",
        "eventTime":"2020-12-03T14:15:46.660",
        "data":{
          "make":"Ducati",
          "model":"Monster"
        }
      }
    ]
   

2. 此主题有一个订阅(Tester--17158468)，具有以下属性：

   {
    "name":"Tester--17158468",
    "type":"Microsoft.EventGrid/eventSubscriptions",
    "id":"/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.EventGrid/topics/testerTopic100/providers/Microsoft.EventGrid/eventSubscriptions/Tester--17158468",
    "properties":{
      "topic":"/subscriptions/xxxx/resourceGroups/xxxx/providers/microsoft.eventgrid/topics/testertopic100",
      "provisioningState":"Succeeded",
      "destination":{
        "properties":{
          "endpointUrl":null,
          "endpointBaseUrl":"https://xxxx.azurewebsites.net/api/HttpEventGrid",
          "maxEventsPerBatch":1,
          "preferredBatchSizeInKilobytes":64
        },
        "endpointType":"WebHook"
      },
      "filter":{
        "subjectBeginsWith":"",
        "subjectEndsWith":""
      },
      "labels":[
        ""
      ],
      "eventDeliverySchema":"EventGridSchema",
      "retryPolicy":{
        "maxDeliveryAttempts":4,
        "eventTimeToLiveInMinutes":20
      },
      "deadLetterDestination":{
        "properties":{
          "resourceId":"/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Storage/storageAccounts/rk2018ebstg",
          "blobContainerName":"eventgrid"
        },
        "endpointType":"StorageBlob"
      }
    }
    }
   

   请注意，交付计数器 = 4和TTL = 20 分钟。

3. 订阅者实现为 HttpTrigger 函数，其中Notification消息的逻辑如下：

    else if(eventTypeHeader == "Notification") 
    {   
        log.LogInformation($"Notification message: [id = {jtoken["id"]}, eventType = {jtoken["eventType"]}]");
   
        return jtoken["eventType"].Value<string>() == "retrytest" ? (ActionResult)new StatusCodeResult(503) : (ActionResult)new OkResult();
    }
   

   如您所见，如果eventType的值为retryTest，则订阅者将返回状态码 = 503，否则返回码为200。

4. 以下屏幕片段显示了订阅者日志消息：

   

   从上面的Logs可以看到，事件消息（id=690bb0ec-7aad-4ed9-a7a1-3b6c8899c57c）已经投递了3次，第一次立即投递，第二次1分钟后投递，最后一次如10分钟后第三个。下一次投递被安排在 60 分钟后，但是这次投递超过了订阅中的特定时间 TTL，例如 20 分钟，因此可以丢弃消息，或者如果我们打开了死信选项，则在之后发送消息5 分钟（不可配置）到 blob 存储，请参阅以下屏幕片段：

   

   请注意，存储帐户上还有一个订阅(TESTER--169394031)订阅了与第一个相同的 weebhook 端点，这就是为什么我们可以在日志中看到基于在blob 存储。

5. 以下屏幕片段显示了一条死信消息：

   

   如您所见，有一条原始事件消息，其中详细说明了传递失败的原因。