An Cloud Storage weitergeleitete Logs ansehen

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

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

Anweisungen zum Weiterleiten Ihrer Logs finden Sie unter Logs an unterstützte Ziele weiterleiten

Logs ansehen

So rufen Sie die an Cloud Storage weitergeleiteten Logs auf:

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

    Zu Buckets

    Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis mit der Zwischenüberschrift Cloud Storage:

  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. Das Protokoll -Typ, der in der Referenz LogEntry als [LOG_ID] bezeichnet wird, kann ein einfacher Name wie syslog oder ein zusammengesetzter Name wie appengine.googleapis.com/request_log Wenn diese Logs in einem Bucket gespeichert wurden mit dem Namen my-gcs-bucket, würden die Verzeichnisse wie im folgenden Beispiel benannt werden:

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 ein receiveTimestamp von 09:10:00 und wurde an 09:15:00 am 25. März 2021 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. Anzahl der Datei-Shards geschriebene Werte können sich je nach 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 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 aus den Systemmesswerten für den Export hervorgeht, Logeinträge an das Ziel weitergeleitet wurden, prüfen Sie den Filter, Prüfen Sie, ob Logeinträge, die Ihrem Filter entsprechen, in letzter Zeit angekommen sind Logging:

Rufen Sie in der Google Cloud Console die Seite Logrouter auf:

Zum Logrouter

Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring 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. 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 im Ziel der Senke fehlen oder Sie anderweitig vermuten ob die Senke Logs nicht ordnungsgemäß weiterleitet, Fehlerbehebung bei Routinglogs

Preise

In Cloud Logging fallen keine Kosten für das Weiterleiten von Logs an einen unterstütztes Ziel; Am Ziel fallen jedoch möglicherweise Gebühren an. Mit Ausnahme des Log-Buckets _Required Cloud Logging berechnet Gebühren für das Streamen von Logs in Log-Buckets und die länger als die standardmäßige Aufbewahrungsdauer des Log-Buckets ist.

Cloud Logging ist kostenlos für das Kopieren von Logs oder für Abfragen, die über die Log-Explorer oder über die Seite Loganalysen aufrufen.

Weitere Informationen finden Sie in folgenden Dokumenten: