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 Beschreibung von Senken finden Sie unter Übersicht über Routing- und Speichermodelle: Senken.

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

Logs ansehen

So rufen Sie die an Cloud Storage weitergeleiteten Logs auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Cloud Storage aus und klicken Sie dann auf Buckets:

    Zu Buckets

  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. Wenn diese Logs in einem Bucket mit dem Namen my-gcs-bucket gespeichert würden, würden die Verzeichnisse wie im folgenden Beispiel benannt:

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 am 25. März 2021 um 09:15:00 Uhr weitergeleitet wurde und für timestamp 08:50:00 und für receiveTimestamp 09:10:00 festgelegt wurde, würde die Zusatzdatei so geschrieben werden:

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 Datei-Shards kann sich für jeden Zeitraum ändern.

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 der Logeinträge.

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

Spät ankommende Log-Einträ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 aus den Systemmesswerten für den Export hervorgeht, dass keine Logeinträge an das Ziel weitergeleitet wurden, prüfen Sie den Filter darauf, ob Logeinträge, die Ihrem Filter entsprechen, kürzlich in Logging angekommen sind.

Wählen Sie im Navigationsbereich der Google Cloud Console Logging und dann Log Router aus:

Zum Logrouter

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. In dem Log-Explorer werden die Log-Zeilen mit dem Anfrage-Log-Eintrag angezeigt. Logging 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 Logs am Ziel der Senke fehlen oder Sie aus anderen Gründen vermuten, dass die Senke Logs nicht ordnungsgemäß weiterleitet, lesen Sie die Informationen unter Fehlerbehebung beim Routing von Logs.

Preise

Das Weiterleiten von Logs an ein unterstütztes Ziel ist in Cloud Logging kostenlos. Für das Ziel können jedoch Gebühren anfallen. Mit Ausnahme des Log-Buckets _Required berechnet Cloud Logging Gebühren für das Streamen von Logs in Log-Buckets und für eine längere Speicherdauer als die standardmäßige Aufbewahrungsdauer des Log-Buckets.

Bei Cloud Logging fallen keine Kosten für das Kopieren von Logs oder für Abfragen an, die über die Seite Log-Explorer oder Loganalysen ausgeführt werden.

Weitere Informationen finden Sie in folgenden Dokumenten: