Nachrichten-Push-Übermittlung und Wiederholungsversuche mit Namespace-Themen

Die Pushübermittlung von Event Grid-Namespaces stellt eine stabile Übermittlung bereit. Das Ereignisraster versucht, jede Nachricht mindestens einmal für jedes übereinstimmende Abonnement sofort zu übermitteln. Wenn der Endpunkt eines Abonnenten den Empfang eines Ereignisses nicht bestätigt oder wenn ein Fehler auftritt, wiederholt Event Grid die Übermittlung auf Grundlage eines festen Wiederholungszeitplans und einer festen Wiederholungsrichtlinie. Standardmäßig übermittelt Event Grid immer nur jeweils ein Ereignis an den Abonnenten.

Ereignisabonnement

Ein Ereignisabonnement ist eine Konfigurationsressource, die einem einzelnen Namespacethema zugeordnet ist. Unter anderem verwenden Sie ein Ereignisabonnement, um die Kriterien für die Ereignisauswahl festzulegen, um die für einen Abonnent verfügbare Ereignissammlung aus der Gesamtmenge der in einem Thema verfügbaren Ereignisse zu definieren. Mithilfe eines Ereignisabonnements definieren Sie auch den Zielendpunkt, an den die Ereignisse gesendet werden. Darüber hinaus können Sie mit einem Ereignisabonnement weitere Eigenschaften festlegen, wie z. B. die maximale Anzahl der Zustellversuche und die Lebensdauer der Ereignisse, die das Laufzeitverhalten der Ereignisübermittlung definieren.

Neuversuchszeitplan

Wenn Event Grid einen Fehler bei einem Zustellversuch empfängt, entscheidet Event Grid, ob basierend auf dem Fehlertyp die Zustellung erneut versucht werden soll.

Wenn der vom abonnierten Endpunkt zurückgegebene Fehler ein konfigurationsbezogener Fehler ist, der nicht mit Wiederholungsversuchen behoben werden kann, sendet Event Grid das Ereignis an ein konfiguriertes Dead-Letter-Ziel. Wenn kein Ziel für unzustellbare Nachrichten konfiguriert wurde, wird das Ereignis verworfen. Ein Ereignis ist beispielsweise inaktiv oder gelöscht, wenn der im Ereignisabonnement konfigurierte Endpunkt nicht erreicht werden kann, weil es gelöscht wurde. Die Übermittlungsversuche werden für die folgenden Bedingungen und Fehler nicht ausgeführt:

Bedingungen:

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

Fehlercodes

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

Wenn die vom abonnierten Endpunkt zurückgegebene Bedingung oder der zurückgegebene Fehler nicht in den obigen Listen enthalten ist, führt Event Grid Wiederholungen nach dem folgenden exponentiellen Backoff-Zeitplan durch:

• 0 Sekunden (sofortiger Wiederholungsversuch)
• 10 Sekunden
• 30 Sekunden
• 1 Minute
• 5 Minuten

Nach 5 Minuten wiederholt Event Grid den Vorgang alle 5 Minuten, bis das Ereignis übermittelt wurde oder die maximale Anzahl Wiederholungen oder die Gültigkeitsdauer des Ereignisses erreicht ist.

Wiederholungsrichtlinie

Sie können die Wiederholungsrichtlinie mithilfe der folgenden beiden Ereignisabonnementkonfigurationseigenschaften anpassen. Ein Ereignis wird verworfen (keine konfigurierte Warteschlange für unzustellbare Nachrichten) oder in die Warteschlange für unzustellbare Nachrichten gestellt, wenn eine der beiden Eigenschaften ihren konfigurierten Grenzwert erreicht.

• Maximale Zustellungsanzahl – Der Wert muss eine ganze Zahl zwischen 1 und 10 sein. Der Standardwert ist 10. Für die Pushübermittlung definiert diese Eigenschaft die maximalen Übermittlungsversuche.
• Aufbewahrung – Diese Eigenschaft ist auch bekannt als event time to live. Der Wert muss ein ISO 8601-Dauerwert mit Minutengenauigkeit sein. Ab dem Zeitpunkt der Veröffentlichung des Ereignisses definiert diese Eigenschaft die Zeitspanne, nach der die Nachricht abläuft. Der zulässige Mindestwert ist "PT1M" (1 Minute). Der maximal zulässige Wert beträgt 7 Tage oder die Aufbewahrungszeit des zugrunde liegenden Themas, je nachdem, welcher Wert niedriger ist. Das Azure-Portal bietet eine einfache Benutzererfahrung, in der Sie die Tage, Stunden und Minuten als ganze Zahlen angeben.

Ausgabebatches

Wenn Sie Webhooks als Zielendpunkttyp verwenden, sendet das Ereignisraster standardmäßig jedes Ereignis einzeln an Abonnenten. Sie können Event Grid so konfigurieren, dass Ereignisse gesammelt für die Übermittlung bereitgestellt werden, um die HTTP-Leistung in Szenarien mit hohem Durchsatz zu verbessern. Die Batchverarbeitung ist standardmäßig deaktiviert und kann pro Ereignisabonnement aktiviert werden.

Bei Verwendung von Event Hubs als Zielendpunkttyp stapelt Event Grid ereignisse immer für maximale Effizienz und Leistung. Es gibt keine Batchrichtlinienkonfiguration, da Event Grid das Batchverarbeitungsverhalten bei der Übermittlung an Azure Event Hubs standardmäßig steuert.

Batch-Richtlinie

Es gibt zwei Einstellungen für die Batchübermittlung:

• Maximale Anzahl von Ereignissen pro Batch: Maximale Anzahl der Ereignisse, die Event Grid pro Batch übermittelt. Der Wert muss eine ganze Zahl zwischen 1 und 5.000 sein. Diese Zahl wird nie überschritten. Es können jedoch weniger Ereignisse übermittelt werden, wenn zum Zeitpunkt der Übermittlung keine weiteren Ereignisse verfügbar sind. Event Grid verzögert Ereignisse nicht, um einen Batch zu erstellen, wenn weniger Ereignisse verfügbar sind.
• Bevorzugte Batchgröße in KB bezeichnet die Obergrenze für die Batchgröße in Kilobyte. Der Wert muss eine Zahl zwischen 1 und 1024 sein. Ähnlich wie bei maximalen Ereignissen ist die Batchgröße möglicherweise kleiner, wenn genügend Ereignisse zum Zeitpunkt der Übermittlung nicht verfügbar sind. Es ist möglich, dass ein Batch die bevorzugte Batchgröße überschreitet, wenn ein einzelnes Ereignis größer als die bevorzugte Batchgröße ist. Wenn z. B. die bevorzugte Größe 4 KB ist und ein 10 Kb-Ereignis an das Ereignisraster verschoben wird, wird das Ereignis 10 Kb bereitgestellt, anstatt verworfen zu werden.

Die Batchübermittlung wird pro Ereignisabonnement über das Portal, die CLI, PowerShell oder SDKs konfiguriert.

Verhalten der Batchverarbeitung

• Alle oder keine

  Event Grid arbeitet mit einer Alles-oder-Nichts-Semantik. Ein teilweiser Erfolg einer Übermittlung im Batch wird nicht unterstützt. Abonnent*innen sollten darauf achten, nur so viele Ereignisse pro Batch anzufordern, wie Sie nach sinnvollem Ermessen in 30 Sekunden tatsächlich verarbeiten können.

• Optimistische Batchverarbeitung

  Die Richtlinieneinstellungen für die Batchverarbeitung sind keine strengen Vorgaben für das Batchverarbeitungsverhalten, sie werden jeweils im Hinblick auf bestmögliche Leistung eingehalten. Bei niedrigen Ereignisraten beobachten Sie häufig, dass die Batchgröße kleiner als die angeforderten maximalen Ereignisse pro Batch ist.

• Standardwert ist AUS

  Standardmäßig fügt das Ereignisraster nur ein Ereignis zu jeder Übermittlungsanforderung hinzu. Die Möglichkeit zum Aktivieren der Batchverarbeitung besteht darin, eine der in der Batchverarbeitungsrichtlinie erwähnten Einstellungen festzulegen.

• Standardwerte

  Es ist nicht erforderlich, beim Erstellen eines Ereignisabonnements beide Einstellungen (maximale Ereignisse pro Batch und ungefähre Batchgröße in Kilobytes) anzugeben. Wenn nur eine Einstellung festgelegt ist, verwendet Das Ereignisraster Standardwerte. In den folgenden Abschnitten finden Sie die Standardwerte und wie Sie diese außer Kraft setzen.

Azure-Portal

Diese Einstellungen werden auf der Registerkarte "Zusätzliche Features " der Seite " Ereignisabonnement " oder nach erstellung des Ereignisabonnements in der Menüoption "Konfiguration" beim Zugriff auf das Ereignisabonnement angezeigt.

„Unzustellbare Nachrichten“-Ereignisse

Wenn das Ereignisraster ein Ereignis nicht innerhalb eines bestimmten Zeitraums oder nach einer bestimmten Anzahl von Versuchen liefern kann, sendet es das Ereignis an ein Speicherkonto. Dieser Prozess wird als Speicherung unzustellbarer Nachrichten bezeichnet. Von Event Grid werden unzustellbare Nachrichten gespeichert, wenn eine der folgenden Bedingungen erfüllt ist.

• Das Ereignis wird nicht innerhalb des Gültigkeitszeitraums (im Ereignisabonnement definierte Aufbewahrung) übermittelt.
• Die Anzahl der Versuche , das Ereignis zu übermitteln, hat den Grenzwert überschritten.

Wenn eine der beiden erfüllt ist, wird das Ereignis verworfen oder als unzustellbar gekennzeichnet. Die Speicherung unzustellbarer Nachrichten ist standardmäßig nicht aktiviert. Wenn Sie das Feature aktivieren möchten, müssen Sie bei der Erstellung des Ereignisabonnements ein Speicherkonto zum Speichern nicht übermittelter Ereignisse angeben. Sie lesen die Ereignisse aus diesem Speicherkonto, um Lieferungen abzuwickeln.

Event Grid sendet ein Ereignis an den Speicherort für unzustellbare Nachrichten, wenn alle Wiederholungsversuche ausgeführt wurden. Wenn Event Grid den Antwortcode 400 (Ungültige Anforderung) oder 413 (Anforderungsentität zu groß) empfängt, wird das Ereignis sofort für die Warteschlange für unzustellbare Nachrichten geplant. Diese Antwortcodes geben an, dass die Übermittlung des Ereignisses nie erfolgreich ist.

Der Ablauf der Gültigkeitsdauer wird ERST beim nächsten geplanten Übermittlungsversuch geprüft. Aus diesem Grund gilt Folgendes: Auch wenn die Gültigkeitsdauer vor dem nächsten geplanten Übermittlungsversuch abläuft, wird der Ablauf eines Ereignisses erst zum Zeitpunkt der nächsten Übermittlung überprüft. Anschließend wird das Ereignis als unzustellbar markiert.

Zwischen dem letzten Übermittlungsversuch eines Ereignisses und der Übermittlung an den Speicherort für unzustellbare Nachrichten gibt es eine fünfminütige Verzögerung. Diese Verzögerung dient dazu, die Anzahl der Blob Storage-Vorgänge zu reduzieren. Wenn der Speicherort für unzustellbare Nachrichten vier Stunden lang nicht verfügbar ist, wird das Ereignis gelöscht.

Wenn Sie den Speicherort für unzustellbare Nachrichten festlegen möchten, benötigen Sie ein Speicherkonto mit einem Container. Der Endpunkt für diesen Container wird bei der Erstellung des Ereignisabonnements angegeben. (Format des Endpunkts: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>)

Es wird empfohlen, sich benachrichtigen zu lassen, wenn ein Ereignis an den Speicherort für unzustellbare Nachrichten gesendet wurde. Wenn Event Grid auf nicht übermittelte Ereignisse reagieren soll, erstellen Sie ein Ereignisabonnement für den Blobspeicher für unzustellbare Nachrichten. Sobald bei Ihrem Blobspeicher für unzustellbare Nachrichten ein nicht übermitteltes Ereignis eingeht, informiert Event Grid Ihren Handler. Der Handler reagiert mit den gewünschten Aktionen zur Abstimmung nicht übermittelter Ereignisse.

Wenn Sie unzustellbare Nachrichten konfigurieren, müssen Sie die verwaltete Identität der zugehörigen RBAC-Rolle (rollenbasierten Zugriffssteuerung) für das Azure Storage-Konto hinzufügen, in dem die unzustellbaren Ereignisse gespeichert werden. Weitere Informationen finden Sie unter Unterstützte Ziele und Azure-Rollen.

Übermittlungsereignisformate

In diesem Abschnitt finden Sie Beispiele für Ereignisse und unzustellbare Ereignisse mit dem CloudEvents 1.0-Schema, dem Format für Nachrichtenmetadaten, das in Namespacethemen unterstützt wird.

CloudEvents 1.0-Schema

Ereignis

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

Ereignis für unzustellbare Nachrichten

[
  {
    "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: Probezeit

Event Grid legt für ein Ereignisabonnement eine Probezeit fest, wenn die Übermittlung von Ereignissen an das Ziel beginnen, Fehler auszulösen. Die Dauer der Probezeit unterscheidet sich je nach Fehler, der vom Zielendpunkt zurückgegeben wird. Bei Ereignisabonnements in der Probezeit können Ereignisse je nach Fehlercode, aufgrund dessen sie sich in der Probezeit befinden, als unzustellbar markiert oder gelöscht werden.

Nachrichtenübermittlungsstatus

Event Grid verwendet HTTP-Antwortcodes zum Bestätigen des Eingangs von Ereignissen.

Erfolgscodes

Event Grid berücksichtigt nur die folgenden HTTP-Antwortcodes als erfolgreiche Übermittlungen. Alle anderen Statuscodes gelten als fehlerhafte Übermittlungen und werden entsprechend wiederholt oder als unzustellbar gekennzeichnet. Wenn Event Grid einen erfolgreichen Statuscode empfängt, wird die Übermittlung als abgeschlossen angesehen.

• 200 – OK
• 201 – Erstellt
• 202 Akzeptiert
• 203 Nicht-Authoritative Information
• 204 Kein Inhalt

Fehlercodes

Alle anderen Codes, die sich nicht im obigen Satz (200-204) befinden, gelten als Fehler und werden bei Bedarf erneut überprüft. Einige haben spezifische Wiederholungsrichtlinien, die an sie gebunden sind, die unten beschrieben sind, alle anderen folgen dem Standard-Wiederholungszeitplan. Es ist wichtig zu beachten, dass aufgrund der stark parallelisierten Natur der Architektur von Event Grid das Wiederholungsverhalten nicht deterministisch ist.

Benutzerdefinierte Übermittlungseigenschaften

Mit Ereignisabonnements können Sie HTTP-Header einrichten, die in übermittelte Ereignisse eingeschlossen werden. Diese Funktion ermöglicht es Ihnen, benutzerdefinierte Header festzulegen, die für ein Ziel erforderlich sind. Beim Erstellen eines Ereignisabonnements können bis zu zehn Header festgelegt werden. Jeder Headerwert sollte nicht größer als 4.096 (4K)-Bytes sein. Sie können benutzerdefinierte Header für die Ereignisse festlegen, die an die folgenden Ziele übermittelt werden:

• Webhooks
• Azure Event Hubs

Nächste Schritte

• Bereitstellen von Ereignissen an Webhook-Endpunkte.