An Cloud Storage weitergeleitete Logs ansehen

In diesem Dokument wird erläutert, wie Sie Logeinträge finden, die Sie von Cloud Logging an Cloud Storage-Buckets weitergeleitet haben.

Log-Einträge werden stündlich in Batches in Cloud Storage-Buckets gespeichert. Es kann zwei bis drei Stunden dauern, bis die ersten Einträge angezeigt werden.

Hinweise

Eine konzeptionelle Diskussion der Senken finden Sie unter Routing- und Speichermodelle – Übersicht: Senken.

Eine Anleitung zum Weiterleiten von Logs finden Sie unter Logs an unterstützte Ziele weiterleiten.

Logs ansehen

So rufen Sie Ihre an Cloud Storage weitergeleiteten Logs auf:

  1. Rufen Sie in der Google Cloud Console die Seite Buckets auf.

    Gehen Sie zu Buckets.

    Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Cloud Storage lautet.

  2. Wählen Sie den Cloud Storage-Bucket aus, den Sie als Routingziel verwenden.

Logs organisieren

Wenn Sie Logs in einen Cloud Storage-Bucket weiterleiten, schreibt Logging eine Gruppe von Dateien in den Bucket.

Die Dateien sind nach Log-Typ und -Datum in Verzeichnishierarchien organisiert. Der Logtyp, der in der LogEntry-Referenz als [LOG_ID] bezeichnet wird, kann ein einfacher Name wie syslog oder ein zusammengesetzter Name wie appengine.googleapis.com/request_log sein. Würden diese Logs in einem Bucket mit dem Namen my-gcs-bucket gespeichert, hätten die Verzeichnisse den Namen wie im folgenden Beispiel:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Ein einzelner Cloud Storage-Bucket kann Logs von mehreren Ressourcentypen enthalten. Die maximale Dateigröße beträgt 3,5 GiB.

Logging garantiert nicht die Deduplizierung von Logeinträgen aus Senken, die identische oder sich überschneidende Suchanfragen enthalten. Logeinträge aus diesen Senken werden möglicherweise mehrfach in einen Cloud Storage-Bucket geschrieben.

Die Blattverzeichnisse (DD/) enthalten mehrere Dateien, von denen jede die weitergeleiteten Logeinträge für einen im Dateinamen angegebenen Zeitraum enthält. Die Dateien sind fragmentiert und ihre Namen enden mit einer Shard-Nummer, Sn oder An (n= 0, 1, 2, …). Ein Beispiel sind diese beiden Dateien, die im Verzeichnis my-gcs-bucket/syslog/2015/01/13/ gespeichert sein können:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Diese beiden Dateien enthalten zusammen die syslog-Logeinträge für alle Instanzen innerhalb der Stunde ab 08:00:00 Uhr UTC und bis zu 08:59:59 UTC. Die Zeitstempel der Log-Einträge werden in UTC (koordinierte Weltzeit) ausgedrückt.

Logeinträge, die mit einer receiveTimestamp innerhalb des 60 Minuten Ausrichtungs-Fensters ihrer timestamp ankommen, werden in Haupt-Shard-Dateien geschrieben. Beispielsweise wird ein Logeintrag mit einem timestamp von 08:00:00 und einem receiveTimestamp von 08:10:00 in der Haupt-Shard-datei gespeichert.

Diese Dateien enthalten einen nummerierten Haupt-Shard im Suffix: _Sn.json.

Logeinträge, die mit einem timestamp in einem anderen 60 Minuten Ausrichtungs-Fenster als ihr receiveTimestamp ankommen, werden in Addendum-Shard-Dateien geschrieben. Beispiel: Ein Logeintrag mit einem timestamp von 08:00:00 und einem receiveTimestamp von 09:10:00 wird in einer Addendum-Shard-Datei gespeichert.

Diese Dateien enthalten einen nummerierten Addendum-Shard mit dem Suffix: _An:Unix_timestamp.json.

Beispiel: Ein Logeintrag mit einer timestamp zwischen 08:00:00 und 08:59:59, aber eine receiveTimestamp innerhalb eines anderen 60 Minuten Ausrichtungs-Fensters wird in eine Datei mit dem Suffix _An:Unix_timestamp.json geschrieben, wobei der Unix-Zeitstempel die Zeit angibt, zu der die Datei an Cloud Storage weitergeleitet wurde. Wenn ein Logeintrag einen timestamp von 08:50:00 und einen receiveTimestamp von 09:10:00 hat und am 25. März 2021 um 09:15:00 Uhr weitergeleitet wurde, würde die Addendum-Datei so geschrieben:

08:00:00_08:59:59_A0:1616681700.json

Um alle Log-Einträge abzurufen, müssen alle Fragmente eines Zeitraums gelesen werden – in diesem Fall die Dateifragmente 0 und 1. Die Anzahl der geschriebenen Dateifragmente kann je nach Zeitraum variieren.

Innerhalb der einzelnen fragmentierten Dateien werden Logeinträge als Liste von LogEntry-Objekten gespeichert. Ein Beispiel für einen syslog-Eintrag finden Sie unter Organisation von Logeinträgen.

Beachten Sie, dass die Sortierreihenfolge der Logeinträge in den Dateien weder einheitlich noch anderweitig garantiert ist.

Spät ankommende Logeinträge

Weitergeleitete Log-Einträge werden stündlich in Batches in Cloud Storage-Buckets gespeichert. Es kann zwei bis drei Stunden dauern, bis die ersten Einträge angezeigt werden. Weitergeleitete Logdatei-Shards mit dem Suffix An ("Append") enthalten Logeinträge, die verspätet angekommen sind.

Wenn am ziel ein Ausfall auftritt, puffert Cloud Logging die Daten, bis der Ausfall vorüber ist.

Wenn im Ziel der Senke keine Logs enthalten sind, rufen Sie die Systemmesswerte für den Export auf. Die Systemmesswerte für den Export geben an, wie viele Logeinträge weitergeleitet und wie viele Logeinträge aufgrund von Fehlern gelöscht wurden. Wenn die Systemmesswerte für den Export anzeigen, dass keine Logeinträge an das Ziel weitergeleitet wurden, prüfen Sie [filter][export-query], um zu ermitteln, ob Logeinträge, die Ihrem Filter entsprechen, kürzlich in Logging angekommen sind.

Rufen Sie in der Google Cloud Console die Seite Log Router auf.

Zum Logrouter

Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

App Engine-Logeinträge

App Engine kombiniert mehrere Untereinträge vom Typ google.appengine.logging.v1.LogLine (auch AppLog oder AppLogLine genannt) unter einem primären Logeintrag des Typs google.appengine.logging.v1.RequestLog für die Anfrage, die die Logaktivität ausgelöst hat. Die Logzeilen haben jeweils eine „Anfrage-ID“ zur Identifizierung des primären Eintrags. Im Log-Explorer werden die Log-Zeilen mit dem Anfrage-Log-Eintrag angezeigt. Beim Logging wird versucht, alle Logzeilen in den Batch der ursprünglichen Anfrage aufzunehmen, auch wenn sie laut Zeitstempel dem nächsten Batch zugeordnet werden müssten. Ist dies nicht möglich, fehlen im Logeintrag der Anfrage möglicherweise einige Logzeilen und im nächsten Batch finden sich „verwaiste“ Protokollzeilen ohne Anfrage. Wenn dies für Sie von Bedeutung ist, planen Sie bei der Verarbeitung der Logs gegebenenfalls ein, die Teile der Anfrage wieder zu verbinden.

Fehlerbehebung

Wenn im Ziel der Senke Logs fehlen oder Sie vermuten, dass die Senke Logs nicht ordnungsgemäß weiterleitet, lesen Sie den Hilfeartikel Fehlerbehebung bei der Weiterleitung von Logs.

Preise

Für das Weiterleiten von Logs an ein unterstütztes Ziel fallen in Cloud Logging keine Gebühren an. Es können jedoch Gebühren am Ziel erhoben werden. Mit Ausnahme des _Required-Log-Buckets fallen in Cloud Logging Kosten für das Streamen von Logs in Log-Buckets und für die Speicherung über die standardmäßige Aufbewahrungsdauer des Log-Buckets hinaus an.

Für das Kopieren von Logs, das Definieren von Log-Bereichen oder das Ausführen von Abfragen über die Seiten Log-Explorer oder Log Analytics fallen in Cloud Logging keine Gebühren an.

Weitere Informationen finden Sie in folgenden Dokumenten: