Event Grid bezorging van berichten en opnieuw proberen

Event Grid biedt duurzame levering. Er wordt geprobeerd elk bericht ten minste één keer voor elk overeenkomend abonnement onmiddellijk te leveren. Als het eindpunt van een abonnee de ontvangst van een gebeurtenis niet bevestigt of als er een fout is, Event Grid de levering opnieuw op basis van een vast schema voor opnieuw proberen en beleid voor opnieuw proberen. Standaard levert de Event Grid-module één gebeurtenis tegelijk aan de abonnee. De nettolading is echter een matrix met één gebeurtenis.

Notitie

Event Grid garandeert geen bestelling voor levering van gebeurtenissen, zodat abonnees deze mogelijk buiten de bestelling ontvangen.

Schema voor opnieuw proberen

Wanneer EventGrid een fout ontvangt voor een gebeurtenisleveringspoging, bepaalt EventGrid of de levering opnieuw moet worden geprobeerd, de gebeurtenis in een dead-letter moet worden bezorgd of dat de gebeurtenis moet worden neergeslagen op basis van het type fout.

Als de fout die wordt geretourneerd door het geabonneerde eindpunt een configuratiefout is die niet kan worden opgelost met nieuwe proberen (bijvoorbeeld als het eindpunt wordt verwijderd), voert EventGrid dead-lettering uit op de gebeurtenis of wordt de gebeurtenis verwijderd als er geen dead-letter is geconfigureerd.

In de volgende tabel worden de typen eindpunten en fouten beschreven waarvoor geen nieuwe poging wordt onderkend:

Eindpunttype Foutcodes
Azure-bronnen 400 Bad Request, 413 Request Entity Too Large, 403 Forbidden
Webhook 400 Bad Request, 413 Request Entity Too Large, 403 Forbidden, 404 Not Found, 401 Unauthorized

Notitie

Als Dead-Letter is geconfigureerd voor een eindpunt, worden gebeurtenissen wegvallen wanneer de bovenstaande fouten optreden. Overweeg het Dead-Letter als u niet wilt dat dit soort gebeurtenissen worden uitgevallen.

Als de fout die wordt geretourneerd door het geabonneerde eindpunt niet in de bovenstaande lijst staat, voert EventGrid de nieuwe poging uit met behulp van de beleidsregels die hieronder worden beschreven:

Event Grid wacht 30 seconden op een antwoord na het bezorgen van een bericht. Als het eindpunt na 30 seconden niet heeft gereageerd, wordt het bericht in de wachtrij geplaatst om het opnieuw te proberen. Event Grid maakt gebruik van een beleid voor exponentieel terugval voor het opnieuw proberen van gebeurtenissen. Event Grid op basis van de best effort een nieuwe levering volgens de volgende planning:

  • 10 seconden
  • 30 seconden
  • 1 minuut
  • 5 minuten
  • 10 minuten
  • 30 minuten
  • 1 uur
  • 3 uur
  • 6 uur
  • Elke 12 uur tot 24 uur

Als het eindpunt binnen drie minuten reageert, probeert Event Grid de gebeurtenis op basis van best effort te verwijderen uit de wachtrij voor opnieuw proberen, maar kunnen er nog steeds duplicaten worden ontvangen.

Event Grid voegt een kleine randomisatie toe aan alle stappen voor opnieuw proberen en kan bepaalde nieuwe poging opportunistisch overslaan als een eindpunt consistent niet in orde is, voor een lange periode niet in orde is of overbelast lijkt te zijn.

Beleid voor opnieuw proberen

U kunt het beleid voor opnieuw proberen aanpassen bij het maken van een gebeurtenisabonnement met behulp van de volgende twee configuraties. Een gebeurtenis wordt gesloten als een van de limieten van het beleid voor opnieuw proberen is bereikt.

  • Maximum aantal pogingen: de waarde moet een geheel getal tussen 1 en 30 zijn. De standaardwaarde is 30.
  • TTL (Event Time to Live) : de waarde moet een geheel getal tussen 1 en 1440 zijn. De standaardwaarde is 1440 minuten

Zie Set retry policy (Beleid voor opnieuw proberen instellen) voor een voorbeeld van een CLI- en PowerShell-opdracht om deze instellingen te configureren.

Batchverwerking van uitvoer

Event Grid standaard wordt elke gebeurtenis afzonderlijk naar abonnees verzonden. De abonnee ontvangt een matrix met één gebeurtenis. U kunt de Event Grid batchgebeurtenissen configureren voor levering voor verbeterde HTTP-prestaties in scenario's met hoge doorvoer. Batching is standaard uitgeschakeld en kan per abonnement worden ingeschakeld.

Batchbeleid

Batchgebatch geleverde levering heeft twee instellingen:

  • Maximaal aantal gebeurtenissen per batch: het maximum aantal gebeurtenissen Event Grid per batch wordt bezorgen. Dit aantal wordt nooit overschreden, maar er kunnen minder gebeurtenissen worden geleverd als er op het moment van publiceren geen andere gebeurtenissen beschikbaar zijn. Event Grid gebeurtenissen voor het maken van een batch niet uit als er minder gebeurtenissen beschikbaar zijn. Moet tussen 1 en 5000 zijn.
  • Voorkeursbatchgrootte in kilobytes: doel maximum voor batchgrootte in kilobytes. Net als bij het maximum aantal gebeurtenissen kan de batchgrootte kleiner zijn als er op het moment van publiceren niet meer gebeurtenissen beschikbaar zijn. Het is mogelijk dat een batch groter is dan de gewenste batchgrootte als één gebeurtenis groter is dan de gewenste grootte. Als de voorkeursgrootte bijvoorbeeld 4 kB is en een gebeurtenis van 10 kB naar Event Grid wordt pusht, wordt de gebeurtenis van 10 kB nog steeds geleverd in een eigen batch in plaats van dat deze wordt uitgevallen.

Batched delivery in geconfigureerd op basis van een abonnement per gebeurtenis via de portal, CLI, PowerShell of SDK's.

Batchgedrag

  • Alles of geen

    Event Grid werkt met all-or-none-semantiek. Het biedt geen ondersteuning voor gedeeltelijk succes van batchlevering. Abonnees moeten zorgvuldig om slechts zo veel gebeurtenissen per batch vragen als ze in 60 seconden redelijk kunnen verwerken.

  • Optimistische batching

    De instellingen van het batchbeleid zijn geen strikte grenzen voor het batchgedrag en worden op basis van best effort in acht genomen. Bij lage gebeurtenissnelheden zult u vaak zien dat de batchgrootte kleiner is dan de aangevraagde maximumgebeurtenissen per batch.

  • Standaard is ingesteld op UIT

    Standaard voegt Event Grid slechts één gebeurtenis toe aan elke bezorgingsaanvraag. De manier om batching in te stellen, is door een van de eerder in het artikel genoemde instellingen in te stellen in de JSON van het gebeurtenisabonnement.

  • Standaardwaarden

    Het is niet nodig om zowel de instellingen (Maximum aantal gebeurtenissen per batch als Geschatte batchgrootte in kilo bytes) op te geven bij het maken van een gebeurtenisabonnement. Als er slechts één instelling is ingesteld, Event Grid standaardwaarden (configureerbare) gebruikt. Zie de volgende secties voor de standaardwaarden en hoe u deze kunt overschrijven.

Azure Portal:

Batchleveringsinstellingen

Azure CLI

Gebruik de volgende parameters bij het maken van een gebeurtenisabonnement:

  • max-events-per-batch: maximum aantal gebeurtenissen in een batch. Moet een getal tussen 1 en 5000 zijn.
  • preferred-batch-size-in-kilobytes: voorkeursbatchgrootte in kilobytes. Moet een getal tussen 1 en 1024 zijn.
storageid=$(az storage account show --name <storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
endpoint=https://$sitename.azurewebsites.net/api/updates

az eventgrid event-subscription create \
  --resource-id $storageid \
  --name <event_subscription_name> \
  --endpoint $endpoint \
  --max-events-per-batch 1000 \
  --preferred-batch-size-in-kilobytes 512

Zie Opslaggebeurtenissen naar een web-eindpunt Event Grid Azure CLI voor meer informatie over het gebruik van Azure CLI metEvent Grid.

Vertraagde levering

Als een eindpunt leveringsfouten ervaart, Event Grid de levering en het opnieuw proberen van gebeurtenissen naar dat eindpunt vertragen. Als bijvoorbeeld de eerste 10 gebeurtenissen die naar een eindpunt worden gepubliceerd mislukken, gaan Event Grid ervan uit dat het eindpunt problemen ondervindt en worden alle volgende nieuwe en nieuwe leveringen enige tijd vertraagd , in sommige gevallen tot enkele uren.

Het functionele doel van vertraagde levering is om slechte eindpunten en het Event Grid beschermen. Zonder uitstel en vertraging van de levering aan slechte eindpunten, kunnen het beleid voor opnieuw proberen en de volumemogelijkheden van Event Grid een systeem eenvoudig overbelasten.

Dead-letter-gebeurtenissen

Wanneer Event Grid een gebeurtenis niet binnen een bepaalde periode kan leveren of nadat de gebeurtenis een bepaald aantal keren is geleverd, kan deze de niet-bezorgde gebeurtenis naar een opslagaccount verzenden. Dit proces wordt dead-lettering genoemd. Event Grid van een gebeurtenis wanneer aan een van de volgende voorwaarden wordt voldaan.

  • De gebeurtenis wordt niet geleverd binnen de time-to-live-periode.
  • Het aantal pogingen om de gebeurtenis te leveren, heeft de limiet overschreden.

Als aan een van de voorwaarden wordt voldaan, wordt de gebeurtenis uitgevallen of in een dead-letter geschreven. Standaard wordt Event Grid in de standaardinstelling niet ingeschakeld. Als u dit wilt inschakelen, moet u een opslagaccount opgeven voor het opslaan van niet-bezorgde gebeurtenissen bij het maken van het gebeurtenisabonnement. U haalt gebeurtenissen op uit dit opslagaccount om leveringen op te lossen.

Event Grid verzendt een gebeurtenis naar de locatie van de dead-letter wanneer deze alle nieuwe pogingen heeft geprobeerd. Als Event Grid antwoordcode 400 (Slechte aanvraag) of 413 (Aanvraagentiteit te groot) ontvangt, wordt de gebeurtenis onmiddellijk gepland voor het maken van dead-lettering. Deze responscodes geven aan dat de gebeurtenis nooit slaagt.

De time-to-live verlooptijd wordt ALLEEN gecontroleerd bij de volgende geplande leveringspoging. Dus zelfs als time-to-live verloopt vóór de volgende geplande leveringspoging, wordt de verlooptijd van gebeurtenissen alleen gecontroleerd op het moment van de volgende levering en vervolgens in een dead-letter voorzien.

Er is een vertraging van vijf minuten tussen de laatste poging om een gebeurtenis te leveren en het moment waarop deze wordt afgeleverd bij de locatie van de dead-letter. Deze vertraging is bedoeld om het aantal blobopslagbewerkingen te verminderen. Als de onbeschikbare locatie vier uur niet beschikbaar is, wordt de gebeurtenis weggevallen.

Voordat u de locatie van de dead-letter in te stellen, moet u een opslagaccount met een container hebben. U geeft het eindpunt voor deze container op bij het maken van het gebeurtenisabonnement. Het eindpunt heeft de volgende indeling: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Mogelijk wilt u een melding ontvangen wanneer een gebeurtenis is verzonden naar de locatie van de dead-letter. Als u Event Grid om te reageren op niet-bezorgde gebeurtenissen, maakt u een gebeurtenisabonnement voor de blobopslag met onbe bezorgde letters. Telkens als uw blob-opslag met onbeletterde letters een niet-bezorgde gebeurtenis ontvangt, Event Grid de handler op de Event Grid ontvangen. De handler reageert met acties die u wilt uitvoeren voor het afstemmen van niet-bezorgde gebeurtenissen. Zie Dead letter and retry policies(Beleid voor dead letter en beleid voor opnieuw proberen) voor een voorbeeld van het instellen van een dead-letter-locatie en beleid voor opnieuw proberen.

Indelingen voor leveringsgebeurtenissen

In deze sectie vindt u voorbeelden van gebeurtenissen en gebeurtenissen in dead-lettered in verschillende indelingen voor leveringsschema's (Event Grid-schema, CloudEvents 1.0-schema en aangepast schema). Zie de artikelen Schema en Cloud Events 1.0 schema voor meer Event Grid over deze indelingen.

Event Grid-schema

Gebeurtenis

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/000000000-0000-0000-0000-00000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    }
}

Dead-letter-gebeurtenis

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/0000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    },

    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T17:18:14.0265758Z",
    "lastDeliveryAttemptTime": "2020-08-13T17:18:14.0465788Z" 
}

CloudEvents 1.0-schema

Gebeurtenis

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Dead-letter-gebeurtenis

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    },

    "deadletterreason": "MaxDeliveryAttemptsExceeded",
    "deliveryattempts": 1,
    "lastdeliveryoutcome": "NotFound",
    "publishtime": "2020-08-13T21:21:36.4018726Z",
}

Aangepast schema

Gebeurtenis

{
    "prop1": "my property",
    "prop2": 5,
    "myEventType": "fooEventType"
}

Dead-letter-gebeurtenis

{
    "id": "8bc07e6f-0885-4729-90e4-7c3f052bd754",
    "eventTime": "2020-08-13T18:11:29.4121391Z",
    "eventType": "myEventType",
    "dataVersion": "1.0",
    "metadataVersion": "1",
    "topic": "/subscriptions/00000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.EventGrid/topics/myCustomSchemaTopic",
    "subject": "subjectDefault",
  
    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T18:11:29.4121391Z",
    "lastDeliveryAttemptTime": "2020-08-13T18:11:29.4277644Z",
  
    "data": {
        "prop1": "my property",
        "prop2": 5,
        "myEventType": "fooEventType"
    }
}

Status van berichtbezorging

Event Grid HTTP-responscodes gebruikt om ontvangst van gebeurtenissen te bevestigen.

Succescodes

Event Grid worden alleen de volgende HTTP-antwoordcodes als geslaagde leveringen gezien. Alle andere statuscodes worden beschouwd als mislukte leveringen en worden waar nodig opnieuw bevraagd of in een impasse geraakt. Na ontvangst van een geslaagde statuscode wordt Event Grid levering voltooid.

  • 200 OK
  • 201 Gemaakt
  • 202 Geaccepteerd
  • 203 Niet-gezaghebbende informatie
  • 204 Geen inhoud

Foutcodes

Alle andere codes die niet in de bovenstaande set staan (200-204) worden beschouwd als fouten en worden opnieuw proberen (indien nodig). Sommige beleidsregels voor opnieuw proberen zijn gekoppeld aan de beleidsregels die hieronder worden beschreven. Alle andere beleidsregels volgen het standaardmodel voor exponentieel afbouwen. Het is belangrijk om te weten dat het gedrag voor opnieuw proberen niet-deterministisch is vanwege de sterk ge parallelliseerde aard van de architectuur van Event Grid.

Statuscode Gedrag voor opnieuw proberen
400 Ongeldige aanvraag Niet opnieuw proberen
401 Onbevoegd Opnieuw proberen na 5 minuten of meer voor Azure-resources-eindpunten
403 Verboden Niet opnieuw proberen
404 Niet gevonden Opnieuw proberen na 5 minuten of meer voor Azure-resources-eindpunten
408 Time-out van aanvraag Opnieuw proberen na 2 minuten of meer
413 Aanvraagentiteit te groot Niet opnieuw proberen
503 Service niet beschikbaar Opnieuw proberen na 30 seconden of meer
Alle andere Opnieuw proberen na 10 seconden of meer

Aangepaste leveringseigenschappen

Met gebeurtenisabonnementen kunt u HTTP-headers instellen die zijn opgenomen in geleverde gebeurtenissen. Op deze manier kunt u aangepaste headers instellen die vereist zijn voor een doel. U kunt maximaal 10 headers instellen bij het maken van een gebeurtenisabonnement. Elke headerwaarde mag niet groter zijn dan 4096 bytes (4.000). U kunt aangepaste headers instellen voor de gebeurtenissen die aan de volgende bestemmingen worden geleverd:

  • Webhooks
  • Azure Service Bus en wachtrijen
  • Azure Event Hubs
  • Hybride verbindingen doorgeven

Zie Aangepaste leveringseigenschappen voor meer informatie.

Volgende stappen

  • Zie Monitor Event Grid message delivery (De levering van berichten controleren) Event Grid de status van leveringen van gebeurtenissen.
  • Zie Dead letter and retry policies(Beleid voor dead letter en opnieuw proberen) om opties voor het leveren van gebeurtenissen aan te passen.