Sie können Logeinträge, die von Cloud Logging an Cloud Storage-Buckets weitergeleitet wurden, aufrufen und abrufen, um Sicherheitsaudits, Compliance-Archivierung oder externe Analysen zu unterstützen. Logeinträge werden in stündlichen Batches in Cloud Storage-Buckets gespeichert und sind in der Regel innerhalb von 2 bis 3 Stunden nach dem Export sichtbar.
Logsenken können Logeinträge nicht an Cloud Storage-Buckets weiterleiten, die für Rapid Storage konfiguriert sind.
Hinweis
Eine konzeptionelle Erläuterung 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:
-
Rufen Sie in der Google Cloud Console die Seite Buckets auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Cloud Storage ist.
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 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, die jeweils die weitergeleiteten Logeinträge für einen im Dateinamen angegebenen Zeitraum enthalten. Die Dateien sind fragmentiert und ihre Namen enden mit einer Fragmentnummer, Sn oder An (n=0, 1, 2, ...). Hier sind beispielsweise zwei Dateien, die im Verzeichnis my-gcs-bucket/syslog/2015/01/13/ gespeichert sein könnten:
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 einen timestamp-Wert von 08:50:00 und einen receiveTimestamp-Wert von 09:10:00 hatte, würde die Addendum-Datei 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 Dateisplitter 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 von Logeinträgen.
Beachten Sie, dass die Sortierreihenfolge der Logeinträge in den Dateien weder einheitlich noch anderweitig garantiert ist.
Beschränkung
Das Feld „LogEntry.errorGroups“ ist für dieses Ziel nicht verfügbar.
Logsenken leiten die an Ihr Projekt gesendeten Logeinträge weiter, diese Logeinträge enthalten jedoch keine Fehlergruppen.
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 Export-Systemmesswerte darauf hinweisen, dass keine Logeinträge an das Ziel weitergeleitet wurden, prüfen Sie anhand Ihres [Filters][export-query], ob Logeinträge, die Ihrem Filter entsprechen, vor Kurzem in Logging eingegangen sind.
Rufen Sie in der Google Cloud Console die Seite Logs Router auf.
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis mit der Zwischenüberschrift Logging aus.
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 vom Typ google.appengine.logging.v1.RequestLog für die Anfrage, die die Logaktivität verursacht. Die Logzeilen haben jeweils eine „Anfrage-ID“, die den primären Eintrag identifiziert. Im Log-Explorer werden die Logzeilen mit dem Anfragelogeintrag angezeigt. Logging versucht, alle Logzeilen mit der ursprünglichen Anfrage in den Batch zu stellen, auch wenn sie aufgrund ihrer Zeitstempel im nächsten Batch platziert werden würden. Wenn das nicht möglich ist, fehlen im Anfrage-Logeintrag möglicherweise einige Logzeilen und im nächsten Batch sind möglicherweise „verwaiste“ Logzeilen ohne Anfrage vorhanden. 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 im Ziel Ihrer Senke zu fehlen scheinen oder Sie anderweitig vermuten, dass Ihre Senke Logs nicht ordnungsgemäß weiterleitet, lesen Sie den Abschnitt Fehlerbehebung bei der Weiterleitung von Logs.