Definir a localização de mensagens mortas e a política de repetição

  • Artigo

Ao criar uma assinatura de evento, você pode personalizar as configurações para entrega de eventos. Este artigo mostra como configurar um local de mensagens mortas e personalizar as configurações de repetição. Para obter informações sobre esses recursos, consulte Entrega e repetição de mensagens da Grade de Eventos.

Observação

Para saber mais sobre entrega de mensagens, repetições e mensagens mortas, consulte o artigo conceitual: Entrega de mensagens da Grade de Eventos e repetição.

Defina o local de mensagens mortas

Para definir um local de mensagens mortas, é necessário ter uma conta de armazenamento para armazenar eventos que não podem ser entregues a um ponto de extremidade. Os exemplos obtêm a ID de recurso de uma conta de armazenamento existente. Eles criam uma assinatura de evento que usa um contêiner na conta de armazenamento para o ponto de extremidade de inatividade.

Observação

  • Crie uma conta de armazenamento e um contêiner de blobs no armazenamento antes de executar comandos neste artigo.
  • O serviço Grade de Eventos cria blobs nesse contêiner. Os nomes de blobs terão o nome da assinatura da Grade de Eventos com todas as letras maiúsculas. Por exemplo, se o nome da assinatura for My-Blob-Subscription, os nomes dos blobs de mensagens mortas terão MY-BLOB-SUBSCRIPTION (myblobcontainer/MY-BLOB-SUBSCRIPTION/2019/8/8/5/111111111-1111-1111-1111-111111111111.json). Esse comportamento serve para proteger contra diferenças no tratamento de casos entre os serviços do Azure.
  • No exemplo acima, .../2019/8/8/5/... representa a data e a hora (UTC) preenchidas com valores diferentes de zero: .../YYYY/MM/DD/HH/....`
  • Os blobs de mensagens mortas criados conterão um ou mais eventos em uma matriz, o que é um comportamento importante a ser considerado ao processar mensagens mortas.

Portal do Azure

Ao criar uma assinatura de evento, você pode habilitar mensagens mortas na guia Recursos adicionais, conforme mostrado na imagem a seguir. Depois de habilitar o recurso, especifique o contêiner de blob que conterá eventos com mensagens mortas e a assinatura do Azure que tem o armazenamento de blobs.

Opcionalmente, você pode habilitar uma identidade gerenciada atribuída pelo sistema ou atribuída pelo usuário para mensagens mortas. A identidade gerenciada deve ser membro de uma função RBAC (controle de acesso baseado em função) que permita gravar eventos no armazenamento.

Captura de tela mostrando a configuração de mensagem morta de uma assinatura de evento.

Você também pode habilitar mensagens mortas e definir as configurações de uma assinatura de evento existente. Na página Assinatura de Evento da sua assinatura do evento, alterne para a guia Recursos adicionais para ver as configurações de mensagens mortas, conforme mostrado na imagem a seguir.

Captura de tela mostrando a configuração de mensagem morta de uma assinatura de evento existente.

CLI do Azure

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

Para desativar a colocação em fila de mensagens mortas, execute novamente o comando para criar a assinatura de evento, mas não forneça um valor para deadletter-endpoint. Você não precisa excluir a assinatura do evento.

Observação

Se você estiver usando a CLI do Azure em seu computador local, use a CLI do Azure versão 2.0.56 ou superior. Para obter instruções sobre como instalar a versão mais recente da CLI do Azure, confira Instalar a CLI do Azure.

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"

Para desativar a colocação em fila de mensagens mortas, execute novamente o comando para criar a assinatura de evento, mas não forneça um valor para DeadLetterEndpoint. Você não precisa excluir a assinatura do evento.

Observação

Se você estiver usando o Azure PowerShell em seu computador local, use o Azure PowerShell versão 1.1.0 ou superior. Baixe e instale o Azure PowerShell mais recente de Downloads do Azure.

Definir a política de repetição

Ao criar uma assinatura de Grade de Eventos, você pode definir valores de por quanto tempo a Grade de Eventos deve tentar entregar o evento. Por padrão, a Grade de Eventos tenta por 24 horas (1440 minutos) ou 30 vezes. Você pode definir esses valores para a sua assinatura da Grade de Eventos. O valor de tempo de vida do evento deve ser um inteiro de 1 a 1440. O valor para máximo de tentativas deve ser um inteiro de 1 a 30.

Não é possível configurar um plano de tentativas.

Portal do Azure

Ao criar uma assinatura de evento, você pode definir as configurações de política de repetição na guia Recursos adicionais.

Captura de tela mostrando a configuração de política de repetição de uma assinatura de evento.

Você também pode definir as configurações de política de repetição para uma assinatura de evento existente. Na página Assinatura de Evento da sua assinatura do evento, alterne para a guia Recursos adicionais para ver as configurações de política de repetição, conforme mostrado na imagem a seguir.

Captura de tela mostrando a configuração de política de repetição de uma assinatura de evento existente.

CLI do Azure

Para definir o evento de vida útil para um valor diferente de 1440 minutos, use:

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

Para definir o máximo de tentativas com um valor diferente de 30, use:

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

Observação

Se você definir ambos event-ttl e max-deliver-attempts, a Grade de Eventos usa o primeiro para expirar, a fim de determinar quando parar a entrega de eventos. Por exemplo, se você definir 30 minutos como vida útil (TTL) e um máximo de 5 tentativas de entrega. Quando um evento não é entregue após 30 minutos (ou) não é entregue após 5 tentativas, o que ocorrer primeiro, o evento é considerado morto. Se você definir o máximo de tentativas de entrega como 10, em relação à agenda de repetição exponencial, o número máximo de 6 tentativas de entrega ocorrerá antes de 30 minutos, a TTL será atingida, portanto, definir o número máximo de tentativas como 10 não terá impacto nesse caso e os eventos inativados após 30 minutos.

PowerShell

Para definir o evento de vida útil para um valor diferente de 1440 minutos, use:

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

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

Para definir o máximo de tentativas com um valor diferente de 30, use:

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

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

Observação

Se você definir ambos event-ttl e max-deliver-attempts, a Grade de Eventos usa o primeiro para expirar, a fim de determinar quando parar a entrega de eventos. Por exemplo, se você definir 30 minutos como vida útil (TTL) e um máximo de 5 tentativas de entrega. Quando um evento não é entregue após 30 minutos (ou) não é entregue após 5 tentativas, o que ocorrer primeiro, o evento é considerado morto. Se você definir o máximo de tentativas de entrega como 10, em relação à agenda de repetição exponencial, o número máximo de 6 tentativas de entrega ocorrerá antes de 30 minutos, a TTL será atingida, portanto, definir o número máximo de tentativas como 10 não terá impacto nesse caso e os eventos inativados após 30 minutos.

Próximas etapas