Delen via


Berichtpushbezorging en opnieuw proberen met naamruimteonderwerpen

Event Grid-naamruimten push-levering biedt duurzame levering. Event Grid probeert elk bericht ten minste één keer te bezorgen voor elk overeenkomend abonnement. Als het eindpunt van een abonnee de ontvangst van een gebeurtenis niet bevestigt of als er een fout optreedt, probeert Event Grid de levering opnieuw op basis van een vast schema voor opnieuw proberen en beleid voor opnieuw proberen. Standaard levert Event Grid één gebeurtenis tegelijk aan de abonnee.

Notitie

Event Grid garandeert geen order voor levering van gebeurtenissen, zodat abonnees ze mogelijk niet in orde kunnen ontvangen.

Gebeurtenisabonnement

Een gebeurtenisabonnement is een configuratieresource die is gekoppeld aan één naamruimteonderwerp. U gebruikt onder andere een gebeurtenisabonnement om de criteria voor gebeurtenisselectie in te stellen om de gebeurtenisverzameling te definiëren die beschikbaar is voor een abonnee uit de totale set gebeurtenissen die beschikbaar zijn in een onderwerp. Met behulp van een gebeurtenisabonnement definieert u ook het doeleindpunt waarnaar de gebeurtenissen worden verzonden. Daarnaast kunt u met een gebeurtenisabonnement andere eigenschappen instellen, zoals het maximale aantal nieuwe pogingen en de time-to-live van de gebeurtenissen, waarmee het runtimegedrag van de levering van gebeurtenissen wordt gedefinieerd.

Schema voor opnieuw proberen

Wanneer Event Grid een fout ontvangt voor een poging tot bezorging van gebeurtenissen, bepaalt Event Grid of de levering opnieuw moet worden uitgevoerd 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 pogingen, verzendt Event Grid de gebeurtenis naar een geconfigureerde bestemming voor dode letters. Als er geen dode letter is geconfigureerd, wordt de gebeurtenis verwijderd. Een gebeurtenis is bijvoorbeeld niet-geschreven of verwijderd wanneer het eindpunt dat is geconfigureerd voor het gebeurtenisabonnement niet kan worden bereikt omdat deze is verwijderd. Het opnieuw proberen van bezorging vindt niet plaats voor de volgende voorwaarden en fouten:

Voorwaarden:

  • ArgumentException
  • TimeoutException
  • UnauthorizedAccessException
  • OperationCanceledException
  • SocketException |

Foutcodes

  • 404 - NotFound
  • 401 - Unauthorized
  • 403 - Forbidden
  • 400 -BadRequest
  • 414 RequestUriTooLong

Notitie

Als dode letter niet is geconfigureerd voor een eindpunt, worden gebeurtenissen verwijderd wanneer de bovenstaande fouten of voorwaarden optreden. Overweeg om een dode letter voor uw gebeurtenisabonnement te configureren als u niet wilt dat dit soort gebeurtenissen worden verwijderd. Dode gebeurtenissen worden verwijderd wanneer de bestemming van de dode letter niet wordt gevonden.

Als de voorwaarde of fout die wordt geretourneerd door het geabonneerde eindpunt zich niet in de bovenstaande lijsten bevindt, voert Event Grid nieuwe pogingen uit op basis van een basisinspanning met behulp van het volgende schema voor exponentieel uitstel:

  • 0 seconden (onmiddellijk opnieuw proberen)
  • 10 seconden
  • 30 seconden
  • 1 minuut
  • 5 minuten

Na 5 minuten blijft Event Grid elke 5 minuten opnieuw proberen totdat de gebeurtenis wordt afgeleverd of het maximale aantal nieuwe pogingen of de maximale time-to-live van de gebeurtenis is bereikt.

Beleid voor opnieuw proberen

U kunt het beleid voor opnieuw proberen aanpassen met behulp van de volgende twee eigenschappen van de configuratie van het gebeurtenisabonnement. Een gebeurtenis wordt verwijderd (geen dode letter geconfigureerd) of een dode letter als een van beide eigenschappen de geconfigureerde limiet bereikt.

  • Maximum aantal leveringen: de waarde moet een geheel getal tussen 1 en 10 zijn. De standaardwaarde is 10. Voor pushlevering definieert deze eigenschap de maximale leveringspogingen.
  • Retentie : deze eigenschap wordt ook wel bekend als event time to live. De waarde moet een ISO 8601-duurwaarde met minuutprecisie zijn. Vanaf het moment dat de gebeurtenis is gepubliceerd, definieert deze eigenschap de periode waarna het bericht verloopt. De toegestane minimumwaarde is 'PT1M' (1 minuut). De toegestane maximumwaarde is 7 dagen of de bewaartijd van het onderliggende onderwerp, afhankelijk van wat lager is. Azure Portal biedt een eenvoudige gebruikerservaring waarbij u de dagen, uren en minuten opgeeft als gehele getallen.

Notitie

Als u beide Retention instelt en Maximum delivery countEvent Grid deze gebruikt om te bepalen wanneer de levering van gebeurtenissen moet worden gestopt. Een van beide stopt de levering van gebeurtenissen. Als u bijvoorbeeld 20 minuten instelt als bewaarperiode en 10 maximale bezorgingspogingen, betekent dit dat wanneer een gebeurtenis na 20 minuten niet wordt bezorgd of niet wordt geleverd na tien pogingen, afhankelijk van wat zich het eerst voordoet, de gebeurtenis onbeletterd is. Vanwege het schema voor opnieuw proberen heeft het instellen van het maximum aantal bezorgingspogingen op 10 echter geen invloed, omdat gebeurtenissen na 20 minuten als onbestelbaar worden beschouwd. Dit is het gevolg van het feit op minuut 20, de leveringspoging #8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m) vindt plaats, maar op dat moment is de gebeurtenis onbeletterd.

Batchverwerking van uitvoer

Wanneer u Webhooks als doeleindpunttype gebruikt, wordt standaard elke gebeurtenis afzonderlijk naar abonnees verzonden. U kunt Event Grid configureren voor batchgebeurtenissen voor levering voor verbeterde HTTP-prestaties in scenario's met hoge doorvoer. Batchverwerking is standaard uitgeschakeld en kan per gebeurtenisabonnement worden ingeschakeld.

Wanneer u Event Hubs als doeleindpunttype gebruikt, worden gebeurtenissen in Event Grid altijd gebatched voor maximale efficiëntie en prestaties. Er is geen batchbeleidsconfiguratie beschikbaar, omdat Event Grid standaard het batchgedrag afhandelt bij het leveren aan Azure Event Hubs.

Batchverwerkingsbeleid

Batched delivery heeft twee instellingen:

  • Maximum aantal gebeurtenissen per batch : het maximum aantal gebeurtenissen dat Event Grid per batch levert. De waarde moet een geheel getal tussen 1 en 5.000 zijn. Dit aantal wordt nooit overschreden. Er kunnen echter minder gebeurtenissen worden geleverd als er op het moment van levering geen gebeurtenissen meer beschikbaar zijn. Event Grid vertraagt gebeurtenissen niet om een batch te maken als er minder gebeurtenissen beschikbaar zijn.
  • Voorkeursbatchgrootte in kilobytes - Doelmaximum voor batchgrootte in kilobytes. De waarde moet een getal tussen 1 en 1024 zijn. Net als bij maximumgebeurtenissen kan de batchgrootte kleiner zijn als er onvoldoende gebeurtenissen beschikbaar zijn op het moment van levering. Het is mogelijk dat een batch groter is dan de gewenste batchgrootte als één gebeurtenis groter is dan de voorkeursgrootte. Als de voorkeursgrootte bijvoorbeeld 4 kB is en een gebeurtenis van 10 kB naar Event Grid wordt gepusht, wordt de gebeurtenis 10Kb geleverd in plaats van te worden verwijderd.

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

Batchgedrag

  • Alles of geen

    Event Grid werkt met alles-of-geen-semantiek. Het biedt geen ondersteuning voor gedeeltelijk succes van een batchlevering. Abonnees moeten ervoor zorgen dat ze alleen om zoveel gebeurtenissen per batch vragen als ze binnen 30 seconden redelijk kunnen verwerken.

  • Optimistische batchverwerking

    De beleidsinstellingen voor batchverwerking zijn geen strikte grenzen voor het gedrag van batchverwerking en worden in acht genomen op basis van best effort. Bij lage gebeurtenissnelheden ziet u vaak dat de batchgrootte kleiner is dan de aangevraagde maximumgebeurtenissen per batch.

  • De standaardwaarde is ingesteld op UIT

    Standaard voegt Event Grid slechts één gebeurtenis toe aan elke leveringsaanvraag. De manier om batchverwerking in te schakelen, is door een van de instellingen in te stellen die worden vermeld in het Batching-beleid.

  • Standaardwaarden

    Het is niet nodig om beide instellingen (maximale gebeurtenissen per batch en geschatte batchgrootte in kilobytes) op te geven bij het maken van een gebeurtenisabonnement. Als er slechts één instelling is ingesteld, gebruikt Event Grid standaardwaarden. Zie de volgende secties voor de standaardwaarden en hoe u deze kunt overschrijven.

Azure Portal

U ziet deze instellingen op het tabblad Aanvullende functies van de pagina Gebeurtenisabonnement of zodra het gebeurtenisabonnement is gemaakt, in de menuoptie Configuratie bij het openen van het gebeurtenisabonnement.

Schermopname van het tabblad Extra functies van de pagina Gebeurtenisabonnement met Batching gemarkeerd.

Gebeurtenissen met dode letters

Wanneer Event Grid een gebeurtenis niet binnen een bepaalde periode kan leveren of nadat de gebeurtenis een bepaald aantal keren is uitgevoerd, wordt de gebeurtenis naar een opslagaccount verzonden. Dit proces staat bekend als dead-lettering. Event Grid kan een gebeurtenis als aan een van de volgende voorwaarden wordt voldaan.

  • De gebeurtenis wordt niet geleverd binnen de periode van time-to-live (retentie die is gedefinieerd in het gebeurtenisabonnement).
  • Het aantal pogingen om de gebeurtenis te leveren, heeft de limiet overschreden.

Als aan een van beide wordt voldaan, wordt de gebeurtenis verwijderd of is de gebeurtenis in een dode letter geplaatst. Event Grid schakelt standaard geen dode letters in. Als u dit wilt inschakelen, moet u een opslagaccount opgeven voor het opslaan van niet-bezorgde gebeurtenissen bij het maken van het gebeurtenisabonnement. U leest de gebeurtenissen uit dit opslagaccount om leveringen op te lossen.

Event Grid verzendt een gebeurtenis naar de locatie van de dode letter wanneer deze alle nieuwe pogingen heeft geprobeerd. Als Event Grid een antwoordcode van 400 (ongeldige aanvraag) of 413 (aanvraagentiteit te groot) ontvangt, wordt de gebeurtenis onmiddellijk gepland voor dode letters. Deze antwoordcodes geven aan dat de levering van de gebeurtenis nooit slaagt.

De time-to-live vervaldatum wordt ALLEEN gecontroleerd bij de volgende geplande leveringspoging. Dus zelfs als time-to-live verloopt voordat de volgende geplande leveringspoging verloopt, wordt het verlopen van gebeurtenissen alleen gecontroleerd op het moment van de volgende levering en vervolgens dode brieven.

Er is een vertraging van vijf minuten tussen de laatste poging om een gebeurtenis te leveren en wanneer deze wordt bezorgd bij de locatie van de dode letter. Deze vertraging is bedoeld om het aantal blobopslagbewerkingen te verminderen. Als de locatie van de dode letter vier uur niet beschikbaar is, wordt de gebeurtenis verwijderd.

Voordat u de locatie voor dode letters instelt, 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 dode letter. Als u Event Grid wilt gebruiken om te reageren op niet-bezorgde gebeurtenissen, maakt u een gebeurtenisabonnement voor de blobopslag met dode letters. Telkens wanneer uw blobopslag met dode letters een niet-bezorgde gebeurtenis ontvangt, meldt Event Grid uw handler. De handler reageert met acties die u wilt uitvoeren voor het afstemmen van niet-bezorgde gebeurtenissen.

Wanneer u dead-lettering configureert, moet u de beheerde identiteit toevoegen aan de juiste RBAC-rol (op rollen gebaseerd toegangsbeheer) in het Azure Storage-account waarin de niet-geschreven gebeurtenissen worden opgeslagen. Zie Ondersteunde bestemmingen en Azure-rollen voor meer informatie.

Indelingen voor bezorgingsevenementen

In deze sectie vindt u voorbeelden van gebeurtenissen en dode gebeurtenissen met behulp van het CloudEvents 1.0-schema, de indeling voor berichtmetagegevens die wordt ondersteund in naamruimteonderwerpen.

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
    }
}

Gebeurtenis voor onbestelbare letters

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Probation

Een gebeurtenisabonnement wordt enige tijd door Event Grid in probation geplaatst als de levering van gebeurtenissen aan de bestemming mislukt. De probatietijd verschilt voor verschillende fouten die door het doeleindpunt worden geretourneerd. Als een gebeurtenisabonnement in probatie is, kunnen gebeurtenissen onbesteld of verwijderd worden zonder zelfs de levering te proberen, afhankelijk van de foutcode waardoor het in probatie is.

Error Duur van proeftijd
Bezet 10 seconden
NotFound 5 minuten
SocketError 30 seconden
ResolutionError 5 minuten
Uitgeschakeld 5 minuten
Volledig 5 minuten
TimedOut 10 seconden
Niet geautoriseerd 5 minuten
Verboden 5 minuten
InvalidAzureFunctionDestination 10 minuten

Notitie

Event Grid maakt gebruik van probatieduur voor beter leveringsbeheer en de duur kan in de toekomst veranderen.

Status van berichtbezorging

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

Succescodes

Event Grid beschouwt alleen de volgende HTTP-antwoordcodes als geslaagde leveringen. Alle andere statuscodes worden beschouwd als mislukte leveringen en worden indien nodig opnieuw geprobeerd of onbestelbaar. Wanneer Event Grid een geslaagde statuscode ontvangt, wordt de levering voltooid beschouwd.

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

Foutcodes

Alle andere codes die niet in de bovenstaande set (200-204) staan, worden beschouwd als fouten en worden indien nodig opnieuw geprobeerd. Sommige hebben specifieke beleidsregels voor opnieuw proberen die zijn gekoppeld aan de beleidsregels die hieronder worden beschreven. Alle andere beleidsregels volgen het standaardschema voor opnieuw proberen. Houd er rekening mee dat vanwege de zeer parallelle aard van de architectuur van Event Grid het gedrag voor opnieuw proberen niet-deterministisch is.

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

Aangepaste leveringseigenschappen

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

  • Webhooks
  • Azure Event Hubs

Volgende stappen