Event Grid leverans av meddelanden och försök igen

Event Grid ger beständig leverans. Den försöker leverera varje meddelande minst en gång för varje matchande prenumeration omedelbart. Om en prenumerantslutpunkt inte bekräftar mottagandet av en händelse eller om det uppstår ett fel försöker Event Grid leverans baserat på ett fast schema för återförsök och återförsöksprincip. Som standard levererar Event Grid-modulen en händelse i taget till prenumeranten. Nyttolasten är dock en matris med en enda händelse.

Anteckning

Event Grid garanterar inte order för händelseleverans, så prenumeranter kan få dem i ordning.

Schema för återförsök

När EventGrid får ett fel för ett försök till händelseleverans avgör EventGrid om det ska försöka leverera igen, utan att ange något meddelande om händelsen eller ta bort händelsen baserat på typen av fel.

Om felet som returneras av den prenumererade slutpunkten är ett konfigurationsrelaterat fel som inte kan åtgärdas med återförsök (till exempel om slutpunkten tas bort) utför EventGrid antingen dead lettering på händelsen eller tar bort händelsen om den inte har konfigurerats.

I följande tabell beskrivs de typer av slutpunkter och fel som återförsök inte sker för:

Typ av slutpunkt Felkoder
Azure-resurser 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

Anteckning

Om Dead-Letter inte har konfigurerats för en slutpunkt ignoreras händelser när ovanstående fel inträffar. Överväg att Dead-Letter om du inte vill att den här typen av händelser ska tas bort.

Om felet som returnerades av den prenumererade slutpunkten inte finns i listan ovan utför EventGrid återförsöket med hjälp av principer som beskrivs nedan:

Event Grid väntar i 30 sekunder på ett svar när ett meddelande har levererats. Om slutpunkten inte har svarat efter 30 sekunder köas meddelandet för återförsök. Event Grid använder en exponentiell återförsöksprincip för händelseleverans. Event Grid försöker leverera på nytt enligt följande schema efter bästa försök:

  • 10 sekunder
  • 30 sekunder
  • 1 minut
  • 5 minuter
  • 10 minuter
  • 30 minuter
  • 1 timme
  • 3 timmar
  • 6 timmar
  • Var 12:e timme upp till 24 timmar

Om slutpunkten svarar inom 3 minuter försöker Event Grid att ta bort händelsen från återförsökskön efter bästa försök, men dubbletter kan fortfarande tas emot.

Event Grid lägger till en liten slumpmässighet i alla återförsökssteg och kan hoppa över vissa återförsök om en slutpunkt konsekvent är skadad, ligger nere under en längre period eller verkar vara överbelastad.

Återförsöksprincip

Du kan anpassa återförsöksprincipen när du skapar en händelseprenumeration med hjälp av följande två konfigurationer. En händelse tas bort om någon av gränserna för återförsöksprincipen uppnås.

  • Maximalt antal försök – Värdet måste vara ett heltal mellan 1 och 30. Standardvärdet är 30.
  • Time to live för händelser (TTL) – Värdet måste vara ett heltal mellan 1 och 1440. Standardvärdet är 1 440 minuter

Exempelkommandot CLI och PowerShell för att konfigurera de här inställningarna finns i Ange återförsöksprincip.

Batchbearbetning av utdata

Event Grid som standard att skicka varje händelse individuellt till prenumeranter. Prenumeranten tar emot en matris med en enda händelse. Du kan konfigurera Event Grid batchhändelser för leverans för bättre HTTP-prestanda i scenarier med högt dataflöde. Batchbearbetning är inaktiverat som standard och kan aktiveras per prenumeration.

Batchbearbetningsprincip

Batchleverans har två inställningar:

  • Maximalt antal händelser per batch – maximalt antal händelser Event Grid levereras per batch. Det här antalet överskrids aldrig, men färre händelser kan levereras om inga andra händelser är tillgängliga vid tidpunkten för publiceringen. Event Grid fördröjer inte händelser för att skapa en batch om färre händelser är tillgängliga. Måste vara mellan 1 och 5 000.
  • Önskad batchstorlek i kilobyte – Måltak för batchstorlek i kilobyte. Precis som maxhändelser kan batchstorleken vara mindre om fler händelser inte är tillgängliga vid tidpunkten för publiceringen. Det är möjligt att en batch är större än den önskade batchstorleken om en enskild händelse är större än den önskade storleken. Om den önskade storleken till exempel är 4 kB och en 10 KB-händelse skickas till Event Grid levereras 10 KB-händelsen fortfarande i sin egen batch i stället för att tas bort.

Batchad leverans i konfigureras per händelseprenumeration via portalen, CLI, PowerShell eller SDK:er.

Batchbearbetningsbeteende

  • Alla eller inga

    Event Grid fungerar med all-or-none-semantik. Det stöder inte partiell framgång för en batchleverans. Prenumeranter bör vara noga med att bara fråga efter så många händelser per batch som de rimligen kan hantera inom 60 sekunder.

  • Optimistisk batchbearbetning

    Inställningarna för batchbearbetningsprincipen är inte strikta gränser för batchbearbetningsbeteendet och respekteras efter bästa möjliga ansträngning. Vid låga händelsefrekvenser ser du ofta att batchstorleken är mindre än de begärda maximala händelserna per batch.

  • Standardvärdet är AV

    Som standard lägger Event Grid en händelse till varje leveransbegäran. Sättet att aktivera batchbearbetning är att ange någon av de inställningar som nämns tidigare i artikeln i händelseprenumerationens JSON.

  • Standardvärden

    Du behöver inte ange både inställningarna (Maximalt antal händelser per batch och Ungefärlig batchstorlek i kilobyte) när du skapar en händelseprenumeration. Om endast en inställning anges använder Event Grid (konfigurerbara) standardvärden. Se följande avsnitt för standardvärdena och hur du åsidosätter dem.

Azure Portal:

Batch delivery settings

Azure CLI

När du skapar en händelseprenumeration använder du följande parametrar:

  • max-events-per-batch – Maximalt antal händelser i en batch. Måste vara ett tal mellan 1 och 5 000.
  • preferred-batch-size-in-kilobytes – Önskad batchstorlek i kilobyte. Måste vara ett tal mellan 1 och 1024.
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

Mer information om hur du använder Azure CLI med Event Grid finns i Dirigera lagringshändelser till webbslutpunkter med Azure CLI.

Fördröjd leverans

När en slutpunkt får leveransfel börjar Event Grid fördröj leveransen och återförsöket av händelser till den slutpunkten. Om till exempel de första 10 händelserna som publiceras till en slutpunkt misslyckas antar Event Grid att slutpunkten har problem och fördröjer alla efterföljande återförsök och nya leveranser under en viss tid – i vissa fall upp till flera timmar.

Det funktionella syftet med fördröjd leverans är att skydda slutpunkter med feltillstånd och Event Grid system. Utan back-off och leveransfördröjning till felaktiga slutpunkter kan Event Grid återförsöksprincip och volymfunktioner enkelt överbelasta ett system.

Händelser med dead letter

När Event Grid inte kan leverera en händelse inom en viss tidsperiod eller efter att ha försökt leverera händelsen ett visst antal gånger kan den skicka händelsen som inte harupplevts till ett lagringskonto. Den här processen kallas för "dead-lettering". Event Grid en händelse när något av följande villkor är uppfyllt.

  • Händelsen levereras inte inom time to live-perioden.
  • Antalet försök att leverera händelsen har överskridit gränsen.

Om något av villkoren uppfylls tas händelsen bort eller blir inbokad. Som standard Event Grid inte aktivera dead-lettering. Om du vill aktivera det måste du ange ett lagringskonto som ska innehålla händelser som inte finns kvar när du skapar händelseprenumerationen. Du hämtar händelser från det här lagringskontot för att lösa leveranser.

Event Grid skickar en händelse till platsen för dead-letter när den har provat alla sina återförsök. Om Event Grid får svarskoden 400 (felaktig begäran) eller 413 (begärandeentiteten är för stor) schemalägger den omedelbart händelsen för dead-lettering. Dessa svarskoder anger att leveransen av händelsen aldrig lyckas.

Förfallotid till live kontrolleras ENDAST vid nästa schemalagda leveransförsök. Så även om time-to-live upphör att gälla innan nästa schemalagda leveransförsök, kontrolleras händelseförfallotid endast vid tidpunkten för nästa leverans och därefter utan bokstav.

Det finns en fördröjning på fem minuter mellan det senaste försöket att leverera en händelse och när den levereras till platsen för obokade bokstäver. Den här fördröjningen är avsedd att minska antalet Blob Storage-åtgärder. Om platsen för dead-letter inte är tillgänglig i fyra timmar ignoreras händelsen.

Du måste ha ett lagringskonto med en container innan du anger en plats med en bokstav. Du anger slutpunkten för den här containern när du skapar händelseprenumerationen. Slutpunkten har formatet: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Du kanske vill få ett meddelande när en händelse har skickats till platsen för oskickade meddelanden. Om du Event Grid att svara på händelser som inte harupplevts skapar du en händelseprenumeration för bloblagringen med obesvarade bokstäver. Varje gång din bloblagring med obemärkta bokstäver tar emot en händelse som inte har Event Grid meddelar hanteraren. Hanteraren svarar med åtgärder som du vill vidta för att stämma av händelser som inte finns. Ett exempel på hur du ställer in en plats för obokade bokstäver och återförsöksprinciper finns i Principer för oställlig bokstav och återförsök.

Leveranshändelseformat

Det här avsnittet innehåller exempel på händelser och händelser med obokad bokstav i olika leveransschemaformat (Event Grid-schema, CloudEvents 1.0-schema och anpassat schema). Mer information om dessa format finns i schemaartiklarna Event Grid ochCloud Events 1.0.

Event Grid-schema

Händelse

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

Händelse med dead letter

{
    "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

Händelse

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

Händelse med dead letter

{
    "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",
}

Anpassat schema

Händelse

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

Händelse med dead letter

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

Meddelandeleveransstatus

Event Grid använder HTTP-svarskoder för att bekräfta mottagandet av händelser.

Lyckade koder

Event Grid endast följande HTTP-svarskoder som lyckade leveranser. Alla andra statuskoder betraktas som misslyckade leveranser och kommer att göras ett åter försök eller ett deadletter efter behov. När du får en lyckad statuskod Event Grid leverans slutförd.

  • 200 OK
  • 201 Skapad
  • 202 Accepted
  • 203 Icke-auktoritativ information
  • 204 Inget innehåll

Felkoder

Alla andra koder som inte finns med i ovanstående uppsättning (200–204) betraktas som fel och kommer att göras ett nytt fel (om det behövs). Vissa har specifika återförsöksprinciper som är knutna till dem som beskrivs nedan. Alla andra följer standardmodellen för exponentiell back off. Det är viktigt att komma ihåg att återförsöksbeteendet är icke-deterministiskt på grund av den mycket parallelliserade Event Grid arkitekturen.

Statuskod Beteende för återförsök
400 – Felaktig begäran Inget åter försöker
401 – Ej behörig Försök igen efter 5 minuter eller mer för Azure-resursslutpunkter
403 – Förbjuden Inget åter försöker
404 – Hittades inte Försök igen efter 5 minuter eller mer för Azure-resursslutpunkter
408 Timeout för begäran Försök igen efter 2 minuter eller mer
413 Begärandeentiteten är för stor Inget åter försöker
503 Tjänsten är inte tillgänglig Försök igen efter 30 sekunder eller mer
Alla andra Försök igen efter 10 sekunder eller mer

Anpassade leveransegenskaper

Med händelseprenumerationer kan du konfigurera HTTP-huvuden som ingår i levererade händelser. Med den här funktionen kan du ange anpassade huvuden som krävs av ett mål. Du kan konfigurera upp till 10 huvuden när du skapar en händelseprenumeration. Varje rubrikvärde får inte vara större än 4 096 (4 000) byte. Du kan ange anpassade huvuden för de händelser som levereras till följande mål:

  • Webhooks
  • Azure Service Bus ämnen och köer
  • Azure Event Hubs
  • Relay-hybridanslutningar

Mer information finns i Anpassade leveransegenskaper.

Nästa steg