Logeinträge weiterleiten

In diesem Dokument wird erläutert, wie Cloud Logging Logeinträge weiterleitet, die von Google Cloudempfangen werden. Es gibt verschiedene Arten von Routingzielen. Sie können Logeinträge beispielsweise an ein Ziel wie einen Log-Bucket weiterleiten, in dem Logeinträge gespeichert werden. Wenn Sie Ihre Protokolldaten an ein Drittanbieterziel exportieren möchten, können Sie Logeinträge an Pub/Sub weiterleiten. Ein Logeintrag kann auch an mehrere Ziele weitergeleitet werden.

Auf übergeordneter Ebene leitet Cloud Logging Logeinträge so weiter und speichert diese so:

Weiterleitung von Logeinträgen durch Cloud Logging

Log-Router

Jedes Google Cloud Projekt, jedes Rechnungskonto, jeder Ordner und jede Organisation hat einen Log-Router, der den Fluss von Logeinträgen über Senken auf Ressourcenebene verwaltet. Ein Log-Router verwaltet auch den Fluss eines Logeintrags durch Senken, die sich in der Ressourcenhierarchie des Eintrags befinden. Senken steuern, wie Logeinträge an Ziele weitergeleitet werden.

Ein Log-Router speichert einen Logeintrag temporär. Dadurch werden vorübergehende Unterbrechungen und Ausfälle vermieden, die auftreten können, wenn ein Logeintrag durch Senken fließt. Der temporäre Speicher bietet keinen Schutz vor Konfigurationsfehlern.

Der temporäre Speicher eines Log-Routers unterscheidet sich vom Langzeitspeicher, der von Logging-Buckets bereitgestellt wird.

Eingehende Logeinträge mit Zeitstempeln, die länger als die Aufbewahrungsdauer der Protokolle zurückliegen oder mehr als 24 Stunden in der Zukunft liegen, werden verworfen.

Logsenken

Wenn eine Log-Senke einen Logeintrag empfängt, wird ermittelt, ob der Logeintrag ignoriert oder weitergeleitet werden soll. Dazu wird der Logeintrag mit den Filtern in der Logsenke verglichen. Wenn der Logeintrag weitergeleitet wird, sendet die Logsenke den Logeintrag an das von der Logsenke angegebene Ziel. Das Ziel kann ein Projekt, ein Speicherort oder ein Dienst sein.

Logsenken gehören zu einer bestimmten Google Cloud Ressource: Google Cloud Projekten, Rechnungskonten, Ordnern und Organisationen. Diese Ressourcen enthalten auch mehrere Log-Speicherorte. Wenn eine Ressource einen Logeintrag empfängt, wird dieser von jeder Log-Senke in dieser Ressource unabhängig ausgewertet. Daher kann derselbe Logeintrag an mehrere Log-Ziele weitergeleitet werden.

Standardmäßig werden Protokolldaten im Projekt gespeichert, aus dem sie stammen. Es gibt jedoch mehrere Gründe, warum Sie diese Konfiguration ändern sollten:

  • Sie können den Speicher Ihrer Protokolldaten zentralisieren.
  • Logdaten mit anderen Geschäftsdaten zusammenführen
  • Zum Organisieren Ihrer Protokolldaten in einer für Sie nützlichen Weise.
  • Sie können Ihre Logs an andere Anwendungen, Repositories oder Dritte senden. Sie können Ihre Logs beispielsweise aus Google Cloud exportieren, um sie auf einer Drittanbieterplattform aufzurufen. Wenn Sie Ihre Logeinträge exportieren möchten, erstellen Sie eine Logsenke, die Ihre Logeinträge an Pub/Sub weiterleitet.

Bei einer falsch konfigurierten Logsenke werden keine Logeinträge weitergeleitet. Wenn eine Senke falsch konfiguriert ist, werden Protokolleinträge mit den Details zum Fehler geschrieben. Außerdem wird eine E-Mail an die wichtigen Kontakte für die Ressource gesendet. Weitere Informationen finden Sie unter Fehlerbehebung: Fehler bei der Ansicht.

Logsenken können Logeinträge nicht rückwirkend weiterleiten. Das bedeutet, dass eine Log-Senke keinen Logeintrag weiterleiten kann, der vor der Erstellung der Senke empfangen wurde. Wenn eine Senke falsch konfiguriert ist, werden nur Logeinträge weitergeleitet, die nach Behebung des Konfigurationsfehlers eingehen. Sie können jedoch rückwirkend Protokolldaten aus einem Protokoll-Bucket in Cloud Storage kopieren. Weitere Informationen finden Sie unter Protokolle kopieren.

Unterstützung für Organisationen und Ordner

So können Sie die Protokolldaten in einer Organisation oder einem Ordner verwalten:

  • Sie können aggregierte Senken erstellen, die Logeinträge für eine Organisation oder einen Ordner und deren untergeordnete Elemente an das von der Senke angegebene Ziel weiterleiten. Es gibt zwei Arten von aggregierten Abläufen:

    • Nicht abfangende aggregierte Senken
    • Aggregierte Senken abfangen

    Der Unterschied zwischen diesen beiden Senketypen besteht darin, dass das Abfangen von Senken auf einer Ebene in der Ressourcenhierarchie sich auf das Routing für Ressourcen in der Hierarchie auswirken kann. Nicht abfangsabhänige Senken haben keinen Einfluss auf das Routing für andere Ressourcen. Wenn eine abfangende Senke in einer Ressource mit einem Logeintrag übereinstimmt, wird der Logeintrag nicht an die Senken in untergeordneten Ressourcen gesendet. Eine Ausnahme besteht darin, dass der Logeintrag immer an die _Required-Log-Senke in der Ressource gesendet wird, aus der er stammt.

  • Sie können die Standardeinstellungen für Ressourcen konfigurieren, um die Konfiguration der vom System erstellten _Default-Senke für neue Ressourcen in einer Organisation oder einem Ordner anzugeben. Mit diesen Einstellungen können Sie beispielsweise den _Default-Sink deaktivieren oder die Filter in diesem Sink angeben.

Routing-Beispiele

In diesem Abschnitt wird veranschaulicht, wie ein Logeintrag, der in einem Projekt stammt, durch die Senken in der Ressourcenhierarchie fließen kann.

Beispiel: Es gibt keine aggregierten Senken

Wenn in der Ressourcenhierarchie des Logeintrags keine aggregierten Senken vorhanden sind, wird der Logeintrag an die Logsenken im Projekt gesendet, aus dem er stammt. Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber mit keinem der Ausschlussfilter der Senke.

Beispiel: Es gibt einen nicht abfangenden aggregierten Datenablauf

Angenommen, in der Ressourcenhierarchie für einen Logeintrag gibt es eine nicht abfangende aggregierte Senke. Nachdem der Log Router den Logeintrag an die nicht abfangende aggregierte Senke gesendet hat, geschieht Folgendes:

  1. Die nicht abfangende zusammengefasste Senke leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter, aber mit keinem Ausschlussfilter übereinstimmt.

  2. Der Log Router sendet den Logeintrag an die Logsenke im Projekt, aus dem er stammt.

    Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber mit keinem der Ausschlussfilter der Senke.

Beispiel: Es gibt eine abfangende aggregierte Senke.

Angenommen, in der Ressourcenhierarchie für einen Logeintrag gibt es eine abfangende aggregierte Senke. Nachdem der Log Router den Logeintrag an die abfangende aggregierte Senke gesendet hat, geschieht Folgendes:

  • Der Logeintrag stimmt mit dem Einschlussfilter überein, aber mit keinem Ausschlussfilter:

    1. Der Logeintrag wird an das Ziel der abfangenden aggregierten Senke weitergeleitet.
    2. Der Logeintrag wird an die _Required-Senke im Projekt gesendet, in dem er seinen Ursprung hat.

  • Der Logeintrag stimmt nicht mit dem Einschlussfilter überein oder mit mindestens einem Ausschlussfilter:

    1. Der Logeintrag wird nicht von der abfangenden aggregierten Senke weitergeleitet.

    2. Der Log Router sendet den Logeintrag an die Logsenke im Projekt, aus dem er stammt.

      Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber mit keinem der Ausschlussfilter der Senke.

Filter für Logsenke

Jede Logsenke enthält einen Einschlussfilter und kann mehrere Ausschlussfilter enthalten. Mit diesen Filtern wird festgelegt, ob die Logsenke einen Logeintrag an das Ziel der Senke weiterleitet. Wenn Sie keine Filter angeben, wird jeder Logeintrag an das Ziel der Senke weitergeleitet.

Ein Logeintrag wird von einem Log-Sink anhand dieser Regeln weitergeleitet:

  • Wenn der Logeintrag nicht mit dem Einschlussfilter übereinstimmt, wird er nicht weitergeleitet. Wenn für eine Senke kein Einschlussfilter angegeben ist, stimmt jeder Logeintrag mit diesem Filter überein.

  • Wenn der Logeintrag mit dem Einschlussfilter und mindestens einem Ausschlussfilter übereinstimmt, wird er nicht weitergeleitet.

  • Wenn der Logeintrag mit dem Einschlussfilter übereinstimmt und mit keinem Ausschlussfilter, wird er an das Ziel der Senke weitergeleitet.

Die Filter in einer Log-Senke werden mithilfe der Logging-Abfragesprache angegeben.

Sie können keine Ausschlussfilter verwenden, um den Verbrauch Ihres entries.write API-Kontingents oder die Anzahl der entries.write API-Aufrufe zu reduzieren. Ausschlussfilter werden angewendet, nachdem Logeinträge von der Logging API empfangen wurden.

Vom System erstellte Logsenken

Für jedes Google Cloud Projekt, jedes Rechnungskonto, jeden Ordner und jede Organisation erstellt Cloud Logging zwei Log-Senken, eine mit dem Namen _Required und die andere mit dem Namen _Default. Die Einschluss- und Ausschlussfilter für diese Senken sorgen dafür, dass jeder Logeintrag, der die Ressource erreicht, von einer dieser Senken weitergeleitet wird. Beide Sinks leiten Protokolldaten an einen Protokoll-Bucket weiter, der sich in derselben Ressource wie der Protokoll-Sink befindet.

Im Rest dieses Abschnitts finden Sie Informationen zu den Filtern und Zielen der vom System erstellten Protokoll-Speicherorte.

_Required Logsenke

Die _Required-Logsenke in einer Ressource leitet einen Teil der Audit-Logs an den _Required-Log-Bucket der Ressource weiter. Für diese Senke sind keine Ausschlussfilter angegeben. Der Einschlussfilter sieht so aus:

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

Die _Required-Logsenke entspricht nur Logeinträgen, die aus der Ressource stammen, in der die _Required-Logsenke definiert ist. Angenommen, eine Log-Senke leitet einen Eintrag aus dem Aktivitätsprotokoll von Projekt A an Projekt B weiter. Da der Logeintrag nicht aus dem Projekt B stammt, leitet der Log-Sink _Required im Projekt B diesen Logeintrag nicht an den Log-Bucket _Required weiter.

Sie können die _Required-Log-Senke nicht ändern oder löschen.

_Default Logsenke

Die _Default-Log-Senke in einer Ressource leitet alle Logeinträge mit Ausnahme derjenigen, die mit dem Filter der _Required-Log-Senke übereinstimmen, an den _Default-Log-Bucket der Ressource weiter. Da der Einschlussfilter für diese Senke leer ist, stimmt er mit allen Logeinträgen überein. Der Ausschlussfilter ist jedoch so konfiguriert:

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

Sie können die _Default-Log-Senke ändern und deaktivieren. Sie können beispielsweise den _Default-Log-Sink bearbeiten und das Ziel ändern. Sie können auch vorhandene Filter ändern und Ausschlussfilter hinzufügen.

Senkenziele

Das Ziel einer Senke kann sich in einer anderen Ressource als der Senke befinden. Sie können beispielsweise eine Log-Senke verwenden, um Logeinträge aus einem Projekt an einen Log-Bucket in einem anderen Projekt weiterzuleiten.

Folgende Ziele werden unterstützt:

Google Cloud -Projekt

Wählen Sie dieses Ziel aus, wenn die Log-Senke im Zielprojekt Ihre Logeinträge umleiten soll, oder wenn Sie eine abfangende aggregierte Senke erstellt haben. Die Log-Senke im Projekt, das das Senkenziel ist, kann die Logeinträge an jedes unterstützte Ziel weiterleiten, mit Ausnahme eines Projekts.

Log-Bucket

Wählen Sie dieses Ziel aus, wenn Sie Ihre Protokolldaten in von Cloud Logging verwalteten Ressourcen speichern möchten. In Log-Buckets gespeicherte Logdaten können mit Diensten wie dem Log-Explorer und Log Analytics aufgerufen und analysiert werden.

Wenn Sie Ihre Logdaten mit anderen Geschäftsdaten zusammenführen möchten, können Sie Ihre Logdaten in einem Log-Bucket speichern und ein verknüpftes BigQuery-Dataset erstellen. Ein verknüpftes Dataset ist ein schreibgeschütztes Dataset, das wie jedes andere BigQuery-Dataset abgefragt werden kann.

BigQuery-Dataset
Wählen Sie dieses Ziel aus, wenn Sie Ihre Protokolldaten mit anderen Geschäftsdaten zusammenführen möchten. Für das angegebene Dataset muss Schreibzugriff aktiviert sein. Als Ziel einer Senke darf kein verknüpftes BigQuery-Dataset festgelegt werden. Verknüpfte Datensätze sind schreibgeschützt.
Cloud Storage-Bucket
Wählen Sie dieses Ziel aus, wenn Sie Ihre Protokolldaten langfristig speichern möchten. Der Cloud Storage-Bucket kann sich im selben Projekt wie die Protokolleinträge oder in einem anderen Projekt befinden. Logeinträge werden als JSON-Dateien gespeichert.
Pub/Sub-Thema
Wählen Sie dieses Ziel aus, wenn Sie Ihre Protokolldaten ausGoogle Cloud exportieren und dann Drittanbieterintegrationen wie Splunk oder Datadog verwenden möchten. Logeinträge werden in JSON formatiert und dann an ein Pub/Sub-Thema weitergeleitet.

Einschränkungen für Ziele

In diesem Abschnitt werden zielspezifische Einschränkungen beschrieben:

  • Wenn Sie Logeinträge an einen Log-Bucket in einem anderen Google Cloud Projekt weiterleiten, werden diese Logeinträge nicht von Error Reporting analysiert. Weitere Informationen finden Sie unter Fehlerberichte – Übersicht.
  • Wenn Sie Logeinträge an ein BigQuery-Dataset weiterleiten, muss das BigQuery-Dataset für das Schreiben aktiviert sein. Sie können Logeinträge nicht an verknüpfte Datasets weiterleiten, die schreibgeschützt sind.
  • Bei neuen Senken, die Logdaten an Cloud Storage-Buckets weiterleiten, kann es mehrere Stunden dauern, bis das Routing von Logeinträgen beginnt. Diese Sinks werden stündlich verarbeitet.

  • Wenn das Ziel eines Log-Sinks ein Google Cloud -Projekt ist, gelten die folgenden Einschränkungen:

    • Es gilt ein Hop-Limit von einem.
    • Logeinträge, die mit dem Filter der _Required-Log-Senke übereinstimmen, werden nur an den _Required-Log-Bucket des Zielprojekts weitergeleitet, wenn sie aus dem Zielprojekt stammen.
    • Nur aggregierte Senken, die sich in der Ressourcenhierarchie eines Logeintrags befinden, verarbeiten den Logeintrag.

    Angenommen, das Ziel einer Protokollsenke in Projekt A ist Projekt B. Dann gilt Folgendes:

    • Aufgrund der Begrenzung auf einen Hop können die Log-Sinks in Projekt B keine Logeinträge an ein Google Cloud Projekt weiterleiten.
    • Im Log-Bucket _Required des Projekts B werden nur Logeinträge gespeichert, die aus dem Projekt B stammen. In diesem Log-Bucket werden keine Logeinträge gespeichert, die aus anderen Ressourcen stammen, einschließlich derjenigen aus Projekt A.
    • Wenn sich die Ressourcenhierarchie von Projekt A und Projekt B unterscheidet, wird ein Logeintrag, der von einem Log-Sink in Projekt A an Projekt B weitergeleitet wird, nicht an die aggregierten Sinks in der Ressourcenhierarchie von Projekt B gesendet.
    • Wenn Projekt A und Projekt B dieselbe Ressourcenhierarchie haben, werden Logeinträge an die aggregierten Senken in dieser Hierarchie gesendet. Wenn ein Logeintrag nicht von einer aggregierten Senke abgefangen wird, sendet der Log-Router den Logeintrag an die Senken im Projekt A.

Auswirkungen von Routing-Logeinträgen auf logbasierte Messwerte

Logbasierte Messwerte sind Cloud Monitoring-Messwerte, die aus dem Inhalt von Logeinträgen abgeleitet werden. Sie können beispielsweise einen logbasierten Messwert verwenden, um die Anzahl der Logeinträge zu zählen, die eine bestimmte Nachricht enthalten, oder um in Logeinträgen aufgezeichnete Latenzinformationen zu extrahieren. Sie können logbasierte Messwerte in Cloud Monitoring-Diagrammen anzeigen und diese Messwerte mit Benachrichtigungsrichtlinien überwachen.

Systemdefinierte logbasierte Messwerte gelten auf Projektebene. Benutzerdefinierte logbasierte Messwerte können auf Projektebene oder auf Ebene des Log-Buckets angewendet werden. Logbasierte Messwerte auf Bucket-Ebene sind nützlich, wenn Sie aggregierte Senken verwenden, um Logeinträge an einen Log-Bucket weiterzuleiten, und wenn Sie Logeinträge aus einem Projekt an einen Log-Bucket in einem anderen Projekt weiterleiten.

Systemdefinierte logbasierte Messwerte
Der Log-Router zählt einen Logeintrag, wenn alle der folgenden Bedingungen erfüllt sind:
  • Der Logeintrag wird durch die Log-Speicher des Projekts geleitet, in dem der logbasierte Messwert definiert ist.

  • Der Logeintrag wird in einem Log-Bucket gespeichert. Der Log-Bucket kann sich in einem beliebigen Projekt befinden.

    Angenommen, Projekt A hat eine Protokollsenke, deren Ziel Projekt B ist. Angenommen, die Log-Senken im Projekt B leiten die Logeinträge an einen Log-Bucket weiter. In diesem Szenario tragen die Logeinträge, die von Projekt A an Projekt B weitergeleitet werden, zu den systemdefinierten logbasierten Messwerten von Projekt A bei. Diese Logeinträge tragen auch zu den systemdefinierten logbasierten Messwerten des Projekts B bei.

Benutzerdefinierte logbasierte Messwerte
Der Log-Router zählt einen Logeintrag, wenn alle der folgenden Bedingungen erfüllt sind:
  • Die Abrechnung ist für das Projekt aktiviert, in dem der logbasierte Messwert definiert ist.
  • Bei Messwerten auf Bucket-Ebene wird der Logeintrag im Log-Bucket gespeichert, in dem der logbasierte Messwert definiert ist.
  • Bei Messwerten auf Projektebene wird der Logeintrag durch die Log-Speicher des Projekts geleitet, in dem der logbasierte Messwert definiert ist.

Weitere Informationen finden Sie unter Übersicht über logbasierte Messwerte.

Best Practices

Best Practices für die Verwendung von Routing für Data Governance oder für gängige Anwendungsfälle finden Sie in den folgenden Dokumenten:

Beispiele: Protokollspeicher zentralisieren

In diesem Abschnitt wird beschrieben, wie Sie einen zentralen Speicher konfigurieren. Zentraler Speicher bietet einen zentralen Ort, an dem nach Logdaten gesucht werden kann. Das vereinfacht Abfragen, wenn Sie nach Trends suchen oder Probleme untersuchen. Aus Sicherheitsperspektive haben Sie auch nur einen Speicherort, was die Aufgaben Ihrer Sicherheitsanalysten vereinfachen kann.

Logspeicher für Projekte in einem Ordner zentralisieren

Angenommen, Sie verwalten einen Ordner und möchten den Speicher Ihrer Logeinträge zentralisieren. Für diesen Anwendungsfall können Sie Folgendes tun:

  1. Sie erstellen in Ihrem Ordner ein Projekt mit dem Namen CentralStorage.
  2. Sie erstellen eine abfangende aggregierte Senke für Ihren Ordner und konfigurieren sie so, dass alle Logeinträge weitergeleitet werden. Sie legen das Projekt CentralStorage als Ziel der Senke fest.

Wenn ein Logeintrag eingeht, der aus dem Ordner oder einer seiner untergeordneten Ressourcen stammt, wird er an die von Ihnen erstellte Senkstelle für aggregierte Daten weitergeleitet. Diese Senke leitet Logeinträge an das Projekt mit dem Namen CentralStorage weiter. Die Logsenke in diesem Projekt verarbeitet die Logeinträge:

  • Die _Default-Logsenke leitet alle Logeinträge, die mit dem Filter der Senke übereinstimmen, an den _Default-Log-Bucket weiter. Dieser Log-Bucket ist Ihr zentraler Speicherort.

  • Die _Required-Log-Senke leitet die Logeinträge, die mit den Filtern der Senke übereinstimmen und aus dem Projekt CentralStorage stammen, an den _Required-Log-Bucket weiter. Dieser Log-Bucket ist kein zentraler Speicherort. Sie können jedoch alle Ihre Protokolldaten zentral speichern. Ein Beispiel finden Sie unter Audit-Logs an einem zentralen Speicherort speichern.

Nach Abschluss der Verarbeitung durch die aggregierte Senke wird der Logeintrag an die _Required-Log-Senke in der Ressource gesendet, aus der er stammt. Wenn der Logeintrag mit dem Filter in der _Required-Log-Senke übereinstimmt, wird er an den _Required-Log-Bucket der Ressource weitergeleitet. Daher speichert jedes Google Cloud Projekt in Ihrem Ordner Logeinträge in seinem _Required-Log-Bucket.

Protokollspeicher für eine Reihe von Projekten zentralisieren

Sie können Logeinträge auch an einem einzigen Ort speichern, wenn Sie keine Organisation oder keinen Ordner haben. Sie haben zum Beispiel folgende Möglichkeiten:

  1. Erstellen Sie ein Projekt mit dem Namen CentralStorage.
  2. Bearbeiten Sie für jedes Projekt außer CentralStorage den Log-Sink _Default und legen Sie das Projekt CentralStorage als Ziel fest.

Sie fragen sich vielleicht, warum im vorherigen Beispiel das Ziel der _Default-Log-Senke auf ein Projekt festgelegt ist und nicht auf den _Default-Log-Bucket in diesem Projekt. Die Hauptgründe sind Einfachheit und Einheitlichkeit. Wenn Sie Logeinträge an ein Projekt weiterleiten, steuern die Log-Sinks im Zielprojekt, welche Logeinträge gespeichert werden und wo sie gespeichert werden. Das bedeutet, dass Sie die Filter- und Zielfunktionen zentralisieren. Wenn Sie ändern möchten, welche Logeinträge gespeichert werden oder wo sie gespeichert werden, müssen Sie nur die Log-Speicherorte in einem Projekt ändern.

Protokollspeicher für Audit-Logs zentralisieren

Sie können Logeinträge, die der _Required-Log-Senke entsprechen, zentral speichern. Wenn Sie diese Logeinträge zentral speichern möchten, gehen Sie so vor:

  • Erstellen Sie Logsenken, die Logeinträge, die mit der _Required-Logsenke übereinstimmen, an einen zentralen Log-Bucket weiterleiten.

  • Konfigurieren Sie Logsenke wie in den beiden vorherigen Beispielen und fügen Sie dann im Zielprojekt eine Logsenke hinzu, die Logeinträge, die mit der _Required-Logsenke übereinstimmen, an einen Log-Bucket weiterleitet. Sie können die Filter auch im _Default-Log-Sink bearbeiten.

Lesen Sie sich die Preisrichtlinien durch, bevor Sie eine solche Strategie implementieren.

Preise

Informationen zu den Preisen für Cloud Logging finden Sie unter Preise für Google Cloud Observability.

Nächste Schritte

Informationen zum Weiterleiten und Speichern von Cloud Logging-Daten finden Sie in den folgenden Dokumenten: