Bekannte Probleme bei Eventarc Standard

Aktuelle Dienstbeschränkungen, Symptome und Problemumgehungen für Eventarc Standard helfen Ihnen, Betriebsprobleme zu erkennen und zu beheben.

Außerdem können Sie in der öffentlichen Problemverfolgung prüfen, ob Probleme vorhanden sind, und neue Probleme eröffnen.

Bereitstellung und Timing

  • Bereitstellungszeit für Trigger: Es kann bis zu zwei Minuten dauern, bis neu erstellte Trigger bereit sind.

  • Bereitstellung des Dienst-Agents: Wenn Sie zum ersten Mal einen Eventarc-Trigger in einem Google Cloud -Projekt erstellen, kann es zu einer Verzögerung bei der Bereitstellung des Eventarc-Dienst-Agents kommen. Dieses Problem lässt sich normalerweise durch erneutes Erstellen des Triggers beheben. Weitere Informationen finden Sie unter Fehler „Berechtigung verweigert“.

Triggerkonfiguration

  • Projektübergreifende Trigger: Projektübergreifende Trigger werden noch nicht unterstützt. Der Dienst, der die Ereignisse für den Trigger empfängt, muss sich im selbenGoogle Cloud -Projekt wie der Trigger befinden. Wenn Anfragen an Ihren Dienst durch Nachrichten ausgelöst werden, die in einem Pub/Sub-Thema veröffentlicht wurden, muss sich das Thema auch im selben Projekt wie der Trigger befinden. Ereignisse in Google Cloud -Projekten weiterleiten

  • Cloud-Audit-Log-Trigger für Compute Engine: Unabhängig davon, wo sich die VM-Instanz befindet, führen Cloud-Audit-Logs-Trigger für Compute Engine zu Ereignissen, die aus einer einzelnen Region stammen: us-central1. Achten Sie beim Erstellen des Triggers darauf, dass der Triggerstandort auf us-central1 oder global festgelegt ist.

  • Cloud Storage-Trigger an Standorten mit mehreren Regionen: Cloud Storage-Trigger können fehlschlagen, wenn ein Cloud Storage-Ereignis aus einer Region stammt, die von Ihrer Pub/Sub-Richtlinie für die Nachrichtenspeicherung nicht zugelassen ist, und wenn In-Transit-Vorgänge erzwungen werden ("enforceInTransit": true). Wenn Sie einen Cloud Storage-Trigger an einem Standort mit mehreren Regionen erstellen, muss Ihre Richtlinie für die Nachrichtenspeicherung alle Quellregionen innerhalb dieser Multi-Region zulassen. In dieser Richtlinie wird festgelegt, wo Nachrichten während der Zustellung gespeichert werden und wo Vorgänge während der Übertragung erzwungen werden. Weitere Informationen finden Sie unter Richtlinien für die Nachrichtenspeicherung konfigurieren.

  • Trigger aktualisieren: Wenn Sie einen Trigger aktualisieren, bevor das generierte Ereignis gesendet wird, wird das Ereignis entsprechend der vorherigen Filterung weitergeleitet und wird innerhalb von drei Tagen nach der Ereignisgenerierung an das ursprüngliche Ziel gesendet. Die neuen Filter werden auf Ereignisse angewendet, die nach der Aktualisierung generiert wurden.

Ereignisnutzlasten und ‑übermittlung

  • Doppelte Übertragung von Cloud-Audit-Logs: Es gibt eine bekannte doppelte Übertragung von Cloud-Audit-Logs aus einigen Google Cloud Ereignisquellen. Wenn doppelte Logs veröffentlicht werden, werden doppelte Ereignisse an Ziele gesendet. Um diese doppelten Ereignisse zu vermeiden, sollten Sie Trigger für Felder erstellen, die gewährleisten, dass das Ereignis eindeutig ist. Dies gilt für die folgenden Ereignistypen:

    • Cloud Storage (serviceName: storage.googleapis.com), methodName: storage.buckets.list
    • Compute Engine (serviceName: compute.googleapis.com), methodName: beta.compute.instances.insert
    • BigQuery (serviceName: bigquery.googleapis.com)

    Da Workflows die Deduplizierung von Ereignissen verarbeiten, müssen Sie nicht gewährleisten, dass das Ereignis eindeutig ist, wenn Sie einen Trigger für Workflows erstellen.

  • Fehler bei Nachrichten für direkte Pub/Sub-Ereignisse verarbeiten: Direkte Pub/Sub-Ereignisse enthalten kein Feld delivery_attempt, es sei denn, das Ereignisziel ist Cloud Run oder Cloud Run Functions. Dies kann sich auf die Behandlung von Nachrichtenfehlern auswirken.

  • Codierung der Ereignisnutzlast: Bei einigen Ereignisanbietern können Sie die Ereignisnutzlast als application/json oder application/protobuf codieren. Eine im JSON-Format formatierte Ereignisnutzlast ist jedoch größer als eine in Protobuf formatierte. Dies kann sich je nach Ereignisziel und seine Limits für die Ereignisgröße auf die Zuverlässigkeit auswirken. Wenn dieses Limit erreicht ist, wird das Ereignis gemäß den Wiederholungsmerkmalen der Transportebene von Eventarc, Pub/Sub, noch einmal versucht. Informationen zum Beheben von Pub/Sub-Nachrichtenausfällen, wenn die maximale Anzahl von Wiederholungsversuchen erreicht wurde.

Ziele und Limits

  • Größe von Workflow-Argumenten: Wenn Sie Workflows als Ziel für einen Eventarc-Trigger verwenden, lösen Ereignisse, die größer als die maximale Argumentgröße von Workflows sind, keine Workflow-Ausführungen aus. Weitere Informationen finden Sie unter Kontingente und Limits.

  • Verschachtelungstiefenlimit für Logeinträge: Das maximale Verschachtelungstiefenlimit für jeden strukturierten Logeintrag für Trigger, die Cloud-Audit-Logs verwenden, beträgt 64 Ebenen. Log-Ereignisse, die dieses Limit überschreiten, werden gelöscht und nicht von Eventarc zugestellt.