Aggregierte Senken – Übersicht

Mit aggregierten Senken können Sie Logeinträge aus allen Ressourcen in einem Ordner oder einer Organisation zusammenfassen und an ein unterstütztes Ziel weiterleiten. Sie können aggregierte Senken verwenden, um Ihre Logdaten an einem zentralen Ort zu speichern und zu steuern, ob untergeordnete Ressourcen doppelte Kopien speichern.

Aggregierte Senken

Eine aggregierte Senke ist eine Senke auf Ordner- oder Organisationsebene sink, die Logeinträge sowohl von der Ressource , in der die Senke definiert ist, als auch von allen untergeordneten Ressourcen weiterleitet. Wie eine Senke auf Projektebene hat eine aggregierte Senke ein Ziel und einen Filter, der bestimmt, welche Logeinträge weitergeleitet werden sollen. Eine Senke auf Projektebene leitet Logeinträge jedoch nur aus einem einzelnen Projekt weiter.

Arten von aggregierten Senken

Sie können zwei Arten von aggregierten Senken erstellen: abfangende und nicht abfangende. Dies hängt davon ab, ob untergeordnete Ressourcen die Logeinträge auch weiterleiten sollen. Wenn aggregierte Senken in der Ressourcenhierarchie eines Logeintrags vorhanden sind, sendet der Log-Router den Logeintrag zuerst an diese Senken. Der Senkentyp bestimmt, was als Nächstes geschieht:

Abfangende aggregierte Senke

Eine abfangende aggregierte Senke verhindert, dass Logeinträge an Senken in untergeordneten Ressourcen weitergeleitet werden. Ausgenommen sind die _Required-Senken in den Ressourcen, aus denen die Logeinträge stammen. Eine abfangende aggregierte Senke kann nützlich sein, um zu verhindern, dass doppelte Kopien von Logeinträgen an mehreren Orten gespeichert werden.

Angenommen, Sie müssen aus Auditgründen Audit-Logs zum Datenzugriff aktivieren. Um die Analyse zu vereinfachen, möchten Sie diese Logs an einem zentralen Ort speichern. Aus Sicherheits- und Kostengründen möchten Sie jedoch auch verhindern, dass diese Logs auf Projektebene gespeichert werden. In diesem Szenario können Sie eine abfangende aggregierte Senke erstellen.

Nicht abfangende aggregierte Senke

Eine nicht abfangende aggregierte Senke hat keine Auswirkungen darauf, wie Logeinträge an andere Senken weitergeleitet werden. Das heißt, auch wenn ein Logeintrag mit dem Filter einer nicht abfangenden aggregierten Senke übereinstimmt, wird er an andere Senken in der Ressourcenhierarchie des Logeintrags weitergeleitet. Mit einer nicht abfangenden aggregierten Senke können Sie die Sichtbarkeit von Logeinträgen in den Ressourcen beibehalten, in denen sie generiert wurden.

Sie können beispielsweise eine nicht abfangende aggregierte Senke erstellen, die alle Logeinträge, die aus den in einer Organisation enthaltenen Ordnern generiert wurden, an einen zentralen Log-Bucket weiterleitet. Die Logeinträge werden im zentralen Log-Bucket gespeichert. Da die Senke jedoch nicht abfangend ist, sendet der Log-Router Logeinträge auch an die Logsenken in der Ressource, in der sie generiert wurden.

Routing-Beispiele

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

Beispiel: 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, in dem er erstellt wurde. Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem „Einschließen“-Filter der Senke übereinstimmt, aber mit keinem der „Ausschließen“-Filter der Senke.

Beispiel: Eine nicht abfangende aggregierte Senke ist vorhanden

Angenommen, in der Ressourcenhierarchie eines Logeintrags ist 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 aggregierte Senke leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem „Einschließen“-Filter übereinstimmt, aber mit keinem „Ausschließen“-Filter.

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

    Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem „Einschließen“-Filter der Senke übereinstimmt, aber mit keinem der „Ausschließen“-Filter der Senke.

Beispiel: Eine abfangende aggregierte Senke ist vorhanden

Angenommen, in der Ressourcenhierarchie eines Logeintrags ist eine abfangende aggregierte Senke vorhanden. Nachdem der Log-Router den Logeintrag an die abfangende aggregierte Senke gesendet hat, geschieht eines der folgenden Dinge:

  • Der Logeintrag stimmt mit dem „Einschließen“-Filter überein, aber mit keinem „Ausschließen“-Filter:

    1. Der Logeintrag wird an das Ziel der abfangenden aggregierten Senke weitergeleitet.
    2. Der Logeintrag wird an die _Required-Senke in dem Projekt gesendet, in dem er erstellt wurde.

  • Der Logeintrag stimmt nicht mit dem „Einschließen“-Filter überein oder stimmt mit mindestens einem „Ausschließen“-Filter überein:

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

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

      Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem „Einschließen“-Filter der Senke übereinstimmt, aber mit keinem der „Ausschließen“-Filter der Senke.

Unterstützte Ziele für aggregierte Senken

In diesem Abschnitt sind die Ziele aufgeführt, die für aggregierte Senken unterstützt werden.

Abfangende Senken

Das Ziel einer abfangenden aggregierten Senke muss ein Google Cloud Projekt sein.

Die Logsenken im Zielprojekt leiten die Logeinträge an ihre Ziele weiter. Alle Ziele außer Projekten werden unterstützt. Die Logsenken im Zielprojekt können Logeinträge beispielsweise an einen Log-Bucket weiterleiten.

Nicht abfangende Senken

In diesem Abschnitt werden die unterstützten Ziele für nicht abfangende aggregierte Senken beschrieben.

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 weiterleiten sollen oder wenn Sie eine abfangende aggregierte Senke erstellt haben. Die Logsenken im Zielprojekt können die Logeinträge an jedes unterstützte Ziel außer einem Projekt weiterleiten.

Die vom System erstellten Logsenken im Zielprojekt schließen Logeinträge aus, die an den _Required-Log-Bucket im Quellprojekt weitergeleitet werden. Wenn Sie beispielsweise Administratoraktivitätslogs an ein anderes Projekt weiterleiten, schließen sowohl die _Required- als auch die _Default-Logsenken im Zielprojekt diese Logeinträge aus. 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 Ressourcen speichern möchten, die von Cloud Logging verwaltet werden. In Log-Buckets gespeicherte Logdaten 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 verknüpfen möchten. Das von Ihnen angegebene Dataset muss schreibgeschützt sein. Legen Sie kein verknüpftes BigQuery-Dataset als Ziel einer Senke fest. Verknüpfte BigQuery-Datasets haben Lesezugriff.
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, in dem die Logeinträge erstellt wurden, oder in einem anderen Projekt. Logeinträge werden als JSON-Dateien gespeichert.
Pub/Sub-Thema
Wählen Sie dieses Ziel aus, wenn Sie Ihre Logdaten aus Google Cloud exportieren und dann Integrationen von Drittanbietern wie Splunk oder Datadog verwenden möchten. Logeinträge werden als JSON formatiert und dann an ein Pub/Sub-Thema weitergeleitet.

Best Practices

Wir empfehlen, dass das Ziel einer aggregierten Senke ein Google Cloud Projekt ist. Bei diesem Ziel leiten die Logsenken im Ziel Google Cloud projekt die Logeinträge weiter. Die _Required-Senke leitet nur Logeinträge weiter, die mit ihrem Filter übereinstimmen und aus der Ressource stammen, in der die Senke definiert ist. Wenn Sie zusätzliche Kopien von Logeinträgen speichern möchten, die mit dem Filter der _Required-Senke übereinstimmen, müssen Sie daher eine benutzerdefinierte Logsenke erstellen oder den Filter der _Default-Logsenke ändern.

Wenn Sie eine abfangende Senke erstellen, empfehlen wir Folgendes:

  • Überlegen Sie, ob untergeordnete Ressourcen eine unabhängige Steuerung der Weiterleitung ihrer Logeinträge benötigen. Wenn eine untergeordnete Ressource eine unabhängige Steuerung bestimmter Logeinträge benötigt, prüfen Sie, ob Ihre abfangende Senke diese Logeinträge nicht weiterleitet.

  • Fügen Sie der Beschreibung einer abfangenden Senke Kontaktdaten hinzu. Dies kann hilfreich sein, wenn sich die Personen, die die abfangende Senke verwalten, von den Personen unterscheiden, die die Projekte verwalten, deren Logeinträge abgefangen werden.

  • Testen Sie Ihre Senkenkonfiguration, indem Sie zuerst eine nicht abfangende aggregierte Senke erstellen, um zu prüfen, ob die richtigen Logeinträge weitergeleitet werden.

Abfangende aggregierte Senken und logbasierte Messwerte

Logbasierte Messwerte sind Cloud Monitoring-Messwerte , die aus dem Inhalt von Logeinträgen abgeleitet werden. Die Art und Weise, wie ein Logeintrag weitergeleitet wird, bestimmt, zu welchen logbasierten Messwerten dieser Logeintrag beitragen kann. Da sich eine abfangende aggregierte Senke auf die Weiterleitung von Logeinträgen auswirkt, kann das Erstellen dieser Art von Senke zu Änderungen der Werte vorhandener logbasierter Messwerte führen.

Weitere Informationen finden Sie unter Auswirkungen der Weiterleitung von Logeinträgen auf logbasierte Messwerte.

Aggregierte Senken und VPC Service Controls

Wenn Sie aggregierte Senken und VPC Service Controls verwenden, gelten die folgenden Einschränkungen und Konfigurationsanforderungen:

  • Zugriff auf Projektlogs innerhalb eines Perimeters: Aggregierte Senken können auf Logdaten aus Projekten innerhalb eines Dienstperimeters zugreifen. Wenn Sie verhindern möchten, dass aggregierte Senken auf Daten innerhalb eines Perimeters zugreifen, verwenden Sie Identity and Access Management, um Cloud Logging-Berechtigungen zu verwalten.

  • Logdaten auf Ordner- und Organisationsebene: Ein VPC Service Controls-Dienst perimeter schützt keine Logdaten auf Ordner- oder Organisationsebene, einschließlich aggregierter Logdaten. Sie können zwar einen Ordner zu einem regulären Dienstperimeter hinzufügen, dadurch werden aber nur die Projekte innerhalb der Ordnerhierarchie geschützt, nicht Ressourcen oder Logs auf Ordnerebene. Sie können eine Organisation nicht als geschützte Ressource in einem Dienstperimeter hinzufügen.

    Verwenden Sie IAM, um Logging-Berechtigungen auf Ordner- oder Organisationsebene zu verwalten.

  • Regeln für eingehenden Traffic für durch Perimeter geschützte Ziele: Wenn Sie Logs mithilfe einer Senke auf Ordner- oder Organisationsebene an eine Ressource weiterleiten, die durch einen Dienstperimeter geschützt wird, müssen Sie dem Zieldienstperimeter eine Regel für eingehenden Traffic hinzufügen. Die Regel für eingehenden Traffic muss den Zugriff auf die Ressource über das Dienstkonto (Schreiberidentität) zulassen, das von der aggregierten Senke verwendet wird. Weitere Informationen finden Sie auf den folgenden Seiten:

  • Einschränkungen für Identitätstypen in Regeln für ein- und ausgehenden Traffic: Wenn eine aggregierte Logsenke Logs an eine Cloud Storage Ressource weiterleitet, die sich in einem VPC Service Controls-Perimeter befindet, kann in der Regel für ein- oder ausgehenden Traffic nicht ANY_SERVICE_ACCOUNT oder ANY_USER_ACCOUNT als Identitätstyp verwendet werden. Verwenden Sie stattdessen ANY_IDENTITY als Identitätstyp.

    Sie müssen keine Regel für eingehenden Traffic für nicht aggregierte Senken konfigurieren.

Nächste Schritte