共用方式為

設定無效信件的位置和重試原則

  • 發行項

當建立事件訂用帳戶時，您可以自訂事件傳遞的設定。 本文說明如何設定無效信件位置及自訂重試設定。 如需這些功能的相關資訊，請參閱事件方格訊息傳遞和重試。

注意

若要了解訊息傳遞、重試和無效信件，請參閱概念性文章：事件方格訊息傳遞和重試。

設定無效信件位置

若要設定無效信件位置，您必須要有儲存體帳戶用以保存無法傳遞至端點的事件。 範例會取得現有儲存體帳戶的資源識別碼。 它們會建立事件訂閱，使用該儲存體帳戶中的容器作為無效信件端點。

注意

  • 在執行本文中的命令之前，請先在儲存體中建立儲存體帳戶和 Blob 容器。
  • 事件方格服務會在此容器中建立 Blob。 Blob 的名稱將具有事件方格訂用帳戶的名稱，此名稱為大寫的所有字母。 例如，如果訂閱的名稱為 My-Blob-Subscription，則無效信件 Blob 的名稱會有 MY-BLOB-SUBSCRIPTION (myblobcontainer/MY-BLOB-SUBSCRIPTION/2019/8/8/5/111111111-1111-1111-1111-111111111111.json)。 此行為是防止在 Azure 服務之間處理案例的差異。
  • 在上述範例中，.../2019/8/8/5/... 代表非零填補的日期和小時 (UTC)：.../YYYY/MM/DD/HH/...。
  • 建立的無效信件 Blob 會在陣列中包含一或多個事件，這是處理無效信件時要考慮的重要行為。

Azure 入口網站

建立事件訂閱時，您可以在 [其他功能] 索引標籤上啟用信件無效化，如下圖所示。 啟用此功能之後，請指定要保存無效信件事件的 Blob 容器，以及具有 Blob 儲存體的 Azure 訂閱。

您可以選擇性地啟用系統指派或使用者指派的受控識別，以進行信件無效化。 此受控識別必須是角色型存取控制 (RBAC) 角色的成員，以允許將事件寫入至儲存體。

此螢幕快照顯示事件訂用帳戶的寄不出的信件組態。

您也可以啟用信件無效化，並為現有事件訂閱進行設定。 在您事件訂閱的 [事件訂閱] 頁面上，切換至 [其他功能] 索引標籤以查看無效信件設定，如下圖所示。

此螢幕快照顯示現有事件訂用帳戶的寄不出的信件設定。

Azure CLI

containername=testcontainer

topicid=$(az eventgrid topic show --name demoTopic -g gridResourceGroup --query id --output tsv)
storageid=$(az storage account show --name demoStorage --resource-group gridResourceGroup --query id --output tsv)

az eventgrid event-subscription create \
  --source-resource-id $topicid \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --deadletter-endpoint $storageid/blobServices/default/containers/$containername

若要關閉無效信件處理，請重新執行命令以建立事件訂閱，但是不提供 deadletter-endpoint 的值。 您不需要刪除事件訂閱。

注意

如果您在本機電腦上使用 Azure CLI，請使用 Azure CLI 2.0.56 版或更新版本。 如需有關如何安裝最新版 Azure CLI 的指示，請參閱安裝 Azure CLI。

PowerShell

$containername = "testcontainer"

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id
$storageid = (Get-AzStorageAccount -ResourceGroupName gridResourceGroup -Name demostorage).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -DeadLetterEndpoint "$storageid/blobServices/default/containers/$containername"

若要關閉無效信件處理，請重新執行命令以建立事件訂閱，但是不提供 DeadLetterEndpoint 的值。 您不需要刪除事件訂閱。

注意

如果您在本機計算機上使用 Azure PowerShell，請使用 Azure PowerShell 1.1.0 版或更新版本。 從 Azure 下載中下載並安裝最新的 Azure PowerShell。

設定重試原則

當建立事件方格訂用帳戶時，您可以設定事件方格應該嘗試傳遞事件的時間長度。 依預設，事件方格會嘗試 24 小時 (1440 分鐘) 或 30 次。 您可以為事件方格訂閱設定上述任一值。 事件存留時間的值必須是介於 1 和 1440 的整數。 重試次數上限的值必須是介於 1 到 30 之間的整數。

您無法設定重試排程。

Azure 入口網站

建立事件訂閱時，您可以在 [其他功能] 索引標籤上設定重試原則設定。

顯示事件訂用帳戶重試原則設定的螢幕快照。

您也可以為現有事件訂閱進行重試原則設定。 在您事件訂閱的 [事件訂閱] 頁面上，切換至 [其他功能] 索引標籤以查看重試原則設定，如下圖所示。

顯示現有事件訂用帳戶重試原則設定的螢幕快照。

Azure CLI

若要將事件存留時間設定為 1440 分鐘以外的值，請使用：

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --event-ttl 720

若要將重試次數上限設定為 30 以外的值，請使用：

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --max-delivery-attempts 18

注意

如果您同時設定 event-ttl 和 max-deliver-attempts，事件方格就會使用前者作為到期條件，來判斷何時停止事件傳遞。 例如，如果您將 30 分鐘設定為存留時間 (TTL) 和 5 次傳遞嘗試上限。 當事件在 30 分鐘後未傳遞 (或) 在 5 次嘗試之後無法傳遞，無論是否為首次發生，事件均為無效信件。 如果您將最大傳遞嘗試設定為 10，相對於 指數重試排程，將會達到 30 分鐘 TTL 之前的最多 6 次傳遞嘗試次數，因此將嘗試次數上限設定為 10 將不會影響此案例，且事件會在 30 分鐘後寄不出。

PowerShell

若要將事件存留時間設定為 1440 分鐘以外的值，請使用：

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -EventTtl 720

若要將重試次數上限設定為 30 以外的值，請使用：

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -MaxDeliveryAttempt 18

注意

如果您同時設定 event-ttl 和 max-deliver-attempts，事件方格就會使用前者作為到期條件，來判斷何時停止事件傳遞。 例如，如果您將 30 分鐘設定為存留時間 (TTL) 和 5 次傳遞嘗試上限。 當事件在 30 分鐘後未傳遞 (或) 在 5 次嘗試之後無法傳遞，無論是否為首次發生，事件均為無效信件。 如果您將最大傳遞嘗試設定為 10，相對於 指數重試排程，將會達到 30 分鐘 TTL 之前的最多 6 次傳遞嘗試次數，因此將嘗試次數上限設定為 10 將不會影響此案例，且事件會在 30 分鐘後寄不出。

下一步