Logeinträge weiterleiten

Mit Cloud Logging können Sie Logeinträge aus Google Cloud Diensten, Ihren Anwendungen und anderen Cloud-Anbietern an Ziele für die Speicherung, Analyse und den Export an Drittanbieter weiterleiten.

Standardmäßig leitet Cloud Logging alle Logeinträge an Log-Buckets in dem Projekt, Ordner oder der Organisation weiter, aus dem sie stammen. Sie können jedoch Logs so konfigurieren, dass Logdaten an benutzerdefinierte Buckets, Cloud Storage, BigQuery oder Pub/Sub weitergeleitet werden. Dienste wie Cloud Storage und Pub/Sub unterstützen den Export Ihrer Logdaten in Drittanbietertools.

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

Abbildung dazu, wie Cloud Logging Logeinträge weiterleitet

Die Abbildung oben gilt für Log-Buckets in einem Projekt. Sie können keine benutzerdefinierten Log-Buckets in Ordnern oder Organisationen erstellen. Außerdem können Sie die Aufbewahrungsdauer von Log-Buckets in einem Ordner oder einer Organisation nicht verlängern.

Logeinträge weiterleiten und exportieren

Routing ist der Vorgang, bei dem Logeinträge, die von einem Google Cloud Projekt, -Ordner oder einer Organisation empfangen werden, an ein Ziel weitergeleitet werden. Ein Ziel ist ein Dienst, der empfangene Logeinträge verarbeitet und eine Aktion ausführt. Sie können beispielsweise Logeinträge an ein Log-Bucket weiterleiten. Bei diesem Ziel werden die Logeinträge nach Fehlerinformationen durchsucht und dann in den Speicher geschrieben.

Beim Exportieren werden Logeinträge aus Google Cloud an einen externen Speicherort verschoben. Sie können Logeinträge beispielsweise an Pub/Sub weiterleiten und dann in Tools von Drittanbietern exportieren.

Cloud Logging verwendet Logsenken, um Logeinträge an Ziele weiterzuleiten. Standardmäßig werden Ihre Logeinträge an einen von zwei Log-Buckets in IhremGoogle Cloud Projekt, Ordner oder Ihrer Organisation weitergeleitet. Sie können Logsenken erstellen, um Ihre Logdaten an andere Ziele weiterzuleiten. Sie können auch einen der vom System erstellten Logsinks ändern. In diesem Dokument werden diese Optionen beschrieben.

Mit dem Log-Explorer können Sie Logeinträge, die in Log-Buckets gespeichert sind, in den lokalen Speicher herunterladen. Die Downloadoption ist jedoch auf 10.000 Logeinträge beschränkt. Wenn Sie Ihre Logeinträge ausGoogle Cloudexportieren möchten, haben Sie folgende Möglichkeiten:

  • Konfigurieren Sie eine Logsenke, um eingehende Logeinträge an Pub/Sub weiterzuleiten, und exportieren Sie dann die Daten aus Google Cloud.

  • Kopieren Sie Logeinträge aus einem Log-Bucket in Cloud Storage und exportieren Sie die Daten dann aus Google Cloud. Informationen zum Kopieren von Logs finden Sie unter Logs im Batch verarbeiten und nachträglich weiterleiten.

Log-Router

Jedes Google Cloud Projekt, Rechnungskonto, jeder Ordner und jede Organisation hat einen Log-Router, der den Fluss von Logeinträgen durch 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 vorübergehend. Dieses Verhalten puffert vorübergehende Unterbrechungen und Ausfälle, die auftreten können, wenn ein Logeintrag durch Senken fließt. Temporärer Speicher schützt nicht vor Konfigurationsfehlern.

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

Eingehende Logeinträge mit Zeitstempeln, die mehr als die Aufbewahrungsdauer für Logs in der Vergangenheit liegen oder die mehr als 24 Stunden in der Zukunft liegen, werden verworfen.

Logsenken

Wenn eine Logs-Senke einen Logeintrag empfängt, wird entschieden, ob der Logeintrag ignoriert oder zum Ziel der Senke weitergeleitet werden soll. Die Logsenke vergleicht den Logeintrag mit ihren Filtern, um diese Entscheidung zu treffen. Das Ziel einer Senke kann ein Projekt, ein Speicherort oder ein Dienst wie Pub/Sub sein. Eine Senke kann beispielsweise Logeinträge an einen Log-Bucket weiterleiten.

Logsinks gehören zu einer bestimmten Google Cloud Ressource Google Cloud :Projekte, Rechnungskonten, Ordner und Organisationen. Diese Ressourcen enthalten auch mehrere Logsinks. Wenn eine Ressource einen Logeintrag empfängt, wird dieser von jeder Logs-Senke in dieser Ressource unabhängig ausgewertet. Daher können mehrere Logsinks denselben Logeintrag weiterleiten.

Standardmäßig werden Logdaten in dem Projekt gespeichert, aus dem die Daten stammen. Es gibt jedoch mehrere Gründe, warum Sie diese Konfiguration ändern sollten:

  • Um die Speicherung Ihrer Logdaten zu zentralisieren.
  • Logdaten mit anderen Geschäftsdaten zusammenführen
  • Sie können Ihre Logdaten so organisieren, dass sie für Sie nützlich sind.
  • Sie können Ihre Logs an andere Anwendungen, Repositories oder Dritte senden. Sie möchten Ihre Logs beispielsweise aus Google Cloud exportieren, um sie auf einer Drittanbieterplattform anzusehen. 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 Logeinträge nicht weitergeleitet. Wenn eine Senke falsch konfiguriert ist, werden Logeinträge geschrieben, in denen der Fehler detailliert beschrieben wird. Außerdem wird eine E‑Mail an die wichtigen Kontakte für die Ressource gesendet. Weitere Informationen finden Sie unter Fehlerbehebung: Fehler ansehen.

Mit Logsenken können Logeinträge nicht rückwirkend weitergeleitet werden. Eine Logsenke kann also keinen Logeintrag weiterleiten, der vor der Erstellung der Senke empfangen wurde. Wenn eine Senke falsch konfiguriert ist, werden nur Logeinträge weitergeleitet, die nach der Behebung des Konfigurationsfehlers eingehen. Sie können Logdaten jedoch nachträglich aus einem Log-Bucket in Cloud Storage kopieren. Weitere Informationen finden Sie unter Logs kopieren.

Unterstützung für Organisationen und Ordner

Um die Logdaten in einer Organisation oder einem Ordner zu verwalten, haben Sie folgende Möglichkeiten:

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

    • Nicht abfangende aggregierte Senken
    • Aggregierte Senken abfangen

    Abfangende Senken können das Routingverhalten für Ressourcen überschreiben, die in der Hierarchie niedriger angesiedelt sind. Nicht abfangende 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 jedoch: Der Logeintrag wird immer an die _Required-Logsenke in der Ressource gesendet, aus der der Logeintrag stammt.

  • Sie können Standardressourceneinstellungen für Cloud Logging konfigurieren, um die Konfiguration der vom System erstellten _Default-Senke für neue Ressourcen in einer Organisation oder einem Ordner anzugeben. Sie können diese Einstellungen beispielsweise verwenden, um den _Default-Sink zu deaktivieren oder die Filter in diesem Sink anzugeben.

Routing-Beispiele

In diesem Abschnitt wird veranschaulicht, wie ein Logeintrag, der in einem Projekt erstellt wurde, durch die Senken in der zugehörigen Ressourcenhierarchie fließen kann.

Beispiel: Es sind keine aggregierten Senken vorhanden.

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

Beispiel: Es ist ein nicht abfangender aggregierter Sink vorhanden.

Angenommen, in der Ressourcenhierarchie ist für einen Logeintrag eine nicht abfangende aggregierte Senke vorhanden. 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 übereinstimmt, aber nicht mit einem Ausschlussfilter.

  2. Der Log-Router sendet den Logeintrag an die Logsenken in dem Projekt, in dem der Logeintrag erstellt wurde.

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

Beispiel: Eine abfangende aggregierte Senke ist vorhanden

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

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

    1. Der Logeintrag wird an das Ziel der abfangenden aggregierten Senke weitergeleitet.
    2. Der Logeintrag wird an die Senke _Required in dem Projekt gesendet, aus dem der Logeintrag stammt.

  • Der Logeintrag entspricht nicht dem Einschlussfilter oder entspricht mindestens einem Ausschlussfilter:

    1. Der Logeintrag wird nicht über die abfangende aggregierte Senke weitergeleitet.

    2. Der Log-Router sendet den Logeintrag an die Logsenken in dem Projekt, in dem der Logeintrag erstellt wurde.

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

Filter für Logsenken

Jede Logs-Senke 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 der folgenden 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 Logsenke werden mit der Logging-Abfragesprache angegeben.

Sie können Ausschlussfilter nicht 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, Rechnungskonto, jeden Ordner und jede Organisation erstellt Cloud Logging zwei Logsinks: einen mit dem Namen _Required und einen mit dem Namen _Default. Die Ein- und Ausschlussfilter für diese Senken sorgen dafür, dass jeder Logeintrag, der von der Ressource stammt, über eine dieser Senken weitergeleitet wird. Beide Senken leiten Logdaten an einen Log-Bucket weiter, der sich in derselben Ressource wie die Logsenke befindet.

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

_Required Logsenke

Die Logsenke _Required in einer Ressource leitet eine Teilmenge von Audit-Logs an den _Required-Log-Bucket der Ressource weiter. Für diese Senke sind keine Ausschlussfilter angegeben und der Einschlussfilter ist wie folgt:

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 Logsenke _Required entspricht nur Logeinträgen, die von der Ressource stammen, in der die Logsenke _Required definiert ist. Angenommen, eine Logsenke leitet einen Aktivitätslogeintrag aus dem Projekt A an das Projekt B weiter. Da der Logeintrag nicht aus dem Projekt B stammt, wird er durch die _Required-Logsinks im Projekt B nicht an den _Required-Log-Bucket weitergeleitet.

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

_Default-Logsenke

Die _Default-Logsenke in einer Ressource leitet Logeinträge 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 Logs-Senke _Default ändern und deaktivieren. Sie können beispielsweise die Log-Senke _Default 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 die Senke befinden. Sie können beispielsweise eine Logsenke verwenden, um Logeinträge aus einem Projekt an einen Log-Bucket weiterzuleiten, der in einem anderen Projekt gespeichert ist.

Die folgenden Ziele werden unterstützt:

Google Cloud -Projekt

Wählen Sie dieses Ziel aus, wenn die Logsenken im Zielprojekt Ihre Logeinträge umleiten sollen oder wenn Sie eine abfangende aggregierte Senke erstellt haben. Die Logsinks im Zielprojekt können die Logeinträge an jedes unterstützte Ziel weiterleiten, mit Ausnahme eines Projekts.

Die vom System erstellten Logsenken im Zielprojekt schließen Logeinträge aus, die an den Log-Bucket _Required im Quellprojekt weitergeleitet werden. Wenn Sie beispielsweise Administratoraktivitätslogs an ein anderes Projekt weiterleiten, werden diese Logeinträge sowohl von den _Required- als auch von den _Default-Logsinks im Zielprojekt ausgeschlossen. Wenn Sie diese Logeinträge speichern möchten, aktualisieren Sie im Zielprojekt die _Default-Logsenke oder erstellen Sie eine benutzerdefinierte Logsenke.

Log-Bucket

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

Wenn Sie Ihre Logdaten mit anderen Geschäftsdaten verknüpfen möchten, können Sie Ihre Logdaten in einem Log-Bucket speichern und ein verknüpftes BigQuery-Dataset erstellen. Ein verknüpftes BigQuery-Dataset ist schreibgeschützt, Sie können es aber wie jedes andere BigQuery-Dataset abfragen.

BigQuery-Dataset
Wählen Sie dieses Ziel aus, wenn Sie Ihre Logdaten mit anderen Geschäftsdaten zusammenführen möchten. Das von Ihnen angegebene Dataset muss für Schreibvorgänge aktiviert sein. Legen Sie für das Ziel einer Senke kein verknüpftes BigQuery-Dataset fest. Verknüpfte BigQuery-Datasets sind schreibgeschützt.
Cloud Storage-Bucket
Wählen Sie dieses Ziel aus, wenn Sie Ihre Logdaten langfristig speichern möchten. Der Cloud Storage-Bucket kann sich in dem Projekt befinden, aus dem die Logeinträge stammen, oder in einem anderen Projekt. 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 als JSON formatiert und dann an ein Pub/Sub-Thema weitergeleitet.

Einschränkungen für Ziele

In diesem Abschnitt werden zielgruppenspezifische Einschränkungen beschrieben:

  • Wenn Sie ein Senkenziel konfigurieren, geben Sie den voll qualifizierten Pfad an und verwenden Sie den globalen Endpunkt des Dienstes. Regionale Dienstendpunkte (Regional Service Endpoints, REPs) wie pubsub.LOCATION.rep.googleapis.com werden nicht unterstützt.
  • 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 Error Reporting – Übersicht.

  • Wenn das Ziel eines Logsinks ein BigQuery-Dataset ist, gelten die folgenden Einschränkungen:

    • Das BigQuery-Dataset muss schreibgeschützt sein. Legen Sie das Ziel nicht auf ein verknüpftes BigQuery-Dataset fest. Verknüpfte Datasets sind schreibgeschützt.
    • Beim Logging wird für jeden Log-Namen eine Tabelle im Dataset erstellt. Sie können eine Tabelle nicht umbenennen, während ein Sink Daten in sie streamt.
  • Bei neuen Senken, mit denen Logeinträge an Cloud Storage-Buckets weitergeleitet werden, kann es mehrere Stunden dauern, bis die Weiterleitung von Logeinträgen beginnt. Diese Senken werden stündlich verarbeitet.

  • Das Weiterleiten von Logs an ein Pub/Sub-Thema, für das Einschränkungen für die Übertragung gelten, wird nicht unterstützt. Logging kann nicht garantieren, dass Veröffentlichungsanfragen aus einer zulässigen Region stammen. Dies führt zu topic_region_not_allowed-Konfigurationsfehlern und verworfenen Logs.

  • Die folgenden Einschränkungen gelten, wenn das Ziel einer Logs-Senke ein Google Cloud -Projekt ist:

    • Es gibt ein Hop-Limit von eins.
    • Die _Required-Logsenke im Zielprojekt leitet Logeinträge an den _Required-Log-Bucket des Projekts weiter, wenn die Logeinträge mit dem Filter der Senke übereinstimmen und aus dem Zielprojekt stammen.
    • Die _Default-Logsenke im Zielprojekt leitet Logeinträge weiter, die mit ihrem Einschlussfilter übereinstimmen und nicht mit einem Ausschlussfilter. Die Logsenke _Default schließt einige Logeinträge aus. Über diesen Senken werden beispielsweise keine Logeinträge zu Administratoraktivitäten und Systemereignissen weitergeleitet. Sie können diese Senke ändern.
    • Nur aggregierte Senken in der Ressourcenhierarchie eines Logeintrags verarbeiten den Eintrag.

    Angenommen, das Ziel einer Logs-Senke im Projekt A ist das Projekt B. In diesem Fall gelten die folgenden Regeln:

    • Aufgrund des One-Hop-Limits können die Logsenken im Projekt B Logeinträge nicht an ein anderes Projekt Google Cloud 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 einer anderen Ressource stammen, einschließlich der Einträge, die aus dem Projekt A stammen.
    • Wenn Projekt A und Projekt B unterschiedliche Ressourcenhierarchien haben, wird ein Logeintrag, den eine Logs-Senke in Projekt A an Projekt B weiterleitet, nicht an die aggregierten Senken 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 Eintrag an die Senken im Projekt A.

Auswirkungen des Routings von 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 darstellen und Benachrichtigungsrichtlinien können diese Messwerte überwachen.

Systemdefinierte logbasierte Messwerte gelten auf Projektebene. Benutzerdefinierte logbasierte Messwerte können auf Projekt- oder Log-Bucket-Ebene 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 über die Logsinks des Projekts weitergeleitet, 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, das Projekt A hat eine Logs-Senke, deren Ziel das Projekt B ist. Angenommen, die Logsenken im Projekt B leiten die Logeinträge an einen Log-Bucket weiter. In diesem Szenario tragen die Logeinträge, die von Projekt A zu Projekt B weitergeleitet werden, zu den systemdefinierten logbasierten Messwerten von Projekt A bei. Diese Logeinträge werden auch für die systemdefinierten logbasierten Messwerte des Projekts B berücksichtigt.

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

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

Best Practices

Verwalten Sie Ihre Log-Senken, wenn Sie Ihren Log-Speicher verwalten. Wenn Sie beispielsweise das Ziel einer Logsenke löschen, löschen Sie auch die entsprechende Logsenke.

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: Logspeicher zentralisieren

In diesem Abschnitt wird beschrieben, wie Sie zentralen Speicher konfigurieren können. Durch die zentrale Speicherung können Sie Logdaten an einem einzigen Ort abfragen. Das vereinfacht Ihre Abfragen, wenn Sie nach Trends suchen oder Probleme untersuchen. Aus Sicherheitssicht haben Sie auch einen Speicherort, was die Aufgaben Ihrer Sicherheitsanalysten vereinfachen kann.

Wenn Sie Ihre Logs zentral speichern, sollten Sie prüfen, ob Sie das Projekt, in dem Ihre Logdaten gespeichert werden, mit einem Pfandrecht belegen möchten. Eine Sperre kann das versehentliche Löschen eines Projekts verhindern. Weitere Informationen finden Sie unter Projekte mit Sperren schützen.

Zentrale Speicherung von Logs für Projekte in einem Ordner

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

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

Wenn ein Logeintrag, der im Ordner oder in einer seiner untergeordneten Ressourcen stammt, eingeht, wird er an die von Ihnen erstellte abfangende aggregierte Senke gesendet. Über diese Senke werden Logeinträge an das Projekt CentralStorage weitergeleitet. Die Logsenken in diesem Projekt verarbeiten die Logeinträge:

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

  • Die Logsenke _Required leitet Logeinträge, die den Filtern der Senke entsprechen und aus dem Projekt CentralStorage stammen, an den Log-Bucket _Required 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 Ort speichern.

Nachdem die Verarbeitung der aggregierten Senke abgeschlossen ist, wird der Logeintrag an die _Required-Logsenke in der Ressource gesendet, in der der Logeintrag erstellt wurde. Wenn der Logeintrag mit dem Filter in der _Required-Logsenke übereinstimmt, wird er an den _Required-Log-Bucket der Ressource weitergeleitet. Daher werden Logeinträge für jedes Google Cloud Projekt in Ihrem Ordner im zugehörigen _Required-Log-Bucket gespeichert.

Logspeicher 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. Zum Beispiel könnten Sie Folgendes tun:

  1. Erstellen Sie ein Projekt mit dem Namen CentralStorage.
  2. Für jedes Projekt außer CentralStorage bearbeiten Sie die Logsink _Default und legen als Ziel das Projekt CentralStorage fest.

Vielleicht fragen Sie sich, warum im vorherigen Beispiel das Ziel der _Default-Logsinks auf ein Projekt und nicht auf den _Default-Log-Bucket in diesem Projekt festgelegt wird. Die Hauptgründe dafür sind Einfachheit und Einheitlichkeit. Wenn Sie Logeinträge an ein Projekt weiterleiten, wird durch die Logsinks im Zielprojekt gesteuert, 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-Senken in einem Projekt ändern.

Zentrale Speicherung von Audit-Logs

Sie können Logeinträge, die der _Required-Logsenke entsprechen, zentral speichern. Um diese Logeinträge zentral zu speichern, haben Sie folgende Möglichkeiten:

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

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

Bevor Sie eine solche Strategie implementieren, sollten Sie sich die Preisrichtlinien ansehen.

Preise

Informationen zu den Preisen für Cloud Logging finden Sie auf der Seite Google Cloud Observability-Preise.

Nächste Schritte

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