Logs in Senkenzielen ansehen

In diesem Dokument wird erläutert, wie Sie Logeinträge finden, die Sie von Cloud Logging an unterstützte Ziele weitergeleitet haben:

Ziel Routing-Häufigkeit
Cloud Storage-Buckets Stündliche Batches
BigQuery-Tabellen Echtzeitnah
Pub/Sub-Themen Echtzeitnah
Cloud Logging-Buckets Echtzeitnah
Drittanbieterziele (Splunk) Echtzeitnah

Eine konzeptionelle Diskussion der Senken finden Sie unter Routing und Speicherübersicht: Senken.

Eine Anleitung zum Routing Ihrer Logs finden Sie unter Senken konfigurieren und verwalten.

Cloud Storage

So rufen Sie Ihre weitergeleiteten Logs in Cloud Storage auf:

  1. Rufen Sie in der Konsole den Cloud Storage-Browser auf:

    Zum Cloud Storage-Browser

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

Ausführliche Informationen zur Organisation von Logs im Cloud Storage-Bucket finden Sie in diesem Dokument unter Cloud Storage-Organisation.

Routing-Häufigkeit

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.

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. Jede Datei beträgt ungefähr 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 Umfang der Logeinträge pro 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 in diesem Dokument unter LogEntry-Typ.

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

Filter

Beispiele für Filter zum Weiterleiten von Logs an Cloud Storage finden Sie unter Beispielabfragen.

BigQuery

So rufen Sie Ihre weitergeleiteten Logs in BigQuery auf:

  1. Rufen Sie die BigQuery-Seite in der Konsole auf:

    BigQuery aufrufen

  2. Wählen Sie das als Ziel der Senke verwendete Dataset aus.

  3. Wählen Sie eine der Tabellen des Datasets aus. Die Logeinträge werden auf dem Tab Details angezeigt. Sie können auch die Tabelle nach den Daten abfragen.

Informationen zum Organisieren der Tabellen finden Sie unter Tabellenstrukturierung.

Informationen zum Benennen der weitergeleiteten Logeintragsfelder finden Sie unter BigQuery-Schema für Logs.

Routing-Häufigkeit

Wenn eine neue Tabelle erstellt wird, während Logging die Logeinträge in BigQuery weiterleitet, kann es einige Minuten dauern, bis die ersten Logeinträge in der neuen Tabelle angezeigt werden. Nachfolgende Logeinträge werden normalerweise innerhalb einer Minute angezeigt.

Tabellenorganisation

Wenn Sie die Logs in ein BigQuery-Dataset weiterleiten, werden in Logging für die weitergeleiteten Logeinträge datierte Tabellen erstellt. Die Namen der Tabellen, in die die Logeinträge geschrieben werden, basieren auf den Lognamen und Zeitstempeln1 der Einträge. In der folgenden Tabelle sehen Sie anhand von Beispielen, wie Lognamen und Zeitstempel Tabellennamen zugeordnet werden:

Logname Zeitstempel des Logeintrags1 BigQuery-Tabellenname
syslog 2017-05-23T18:19:22.135Z syslog_20170523
apache-access 2017-01-01T00:00:00.000Z apache_access_20170101
compute.googleapis.com/activity_log 2017-12-31T23:59:59.999Z compute_googleapis_com_activity_log_20171231

1: Die Zeitstempel der Logeinträge werden in UTC (koordinierte Weltzeit) ausgedrückt.

Schemas und Felder

BigQuery-Tabellenschemas für weitergeleitete Logs basieren auf der Struktur des LogEntry-Typs und den Inhalten der Log-Nutzlasten. Sie können das Tabellenschema aufrufen, indem Sie in der BigQuery-UI eine Tabelle mit weitergeleiteten Logeinträgen auswählen.

Das BigQuery-Tabellenschema, das zur Darstellung komplexer Nutzlasten von Logeinträgen verwendet wird, kann verwirrend sein. Für weitergeleitete Audit-Logs gelten außerdem einige spezielle Namensregeln. Weitere Informationen finden Sie unter BigQuery-Schema für Logs.

Abfragen

Beispiele für Abfragen zum Weiterleiten von Logs an BigQuery finden Sie unter Beispielabfragen.

Weitere Informationen zur BigQuery-Abfragesyntax finden Sie unter Abfragereferenz. Besonders nützlich sind Tabellenplatzhalterfunktionen, mit denen Sie mehrere Tabellen abfragen können, und der Flatten-Operator zum Anzeigen von Daten aus wiederkehrenden Feldern.

Compute Engine-Beispielabfrage

Mit der folgenden BigQuery-Abfrage werden Logeinträge von mehreren Tagen und Logtypen abgerufen:

  • Die Abfrage durchsucht die letzten drei Tage der Logs syslog und apache-access. Die Abfrage wurde am 23. Februar 2015 durchgeführt und deckt alle am 21. und 22. Februar empfangenen Logeinträge sowie die am 23. Februar bis zur Ausgabe der Abfrage erhaltenen Logeinträge ab.

  • Mit der Abfrage werden nur Ergebnisse für die Compute Engine-Instanz 1554300700000000000 abgerufen.

SELECT
  timestamp AS Time,
  logName as Log,
  textPayload AS Message
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.syslog_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())),
  (TABLE_DATE_RANGE(my_bq_dataset.apache_access_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP()))
WHERE
  resource.type == 'gce_instance'
  AND resource.labels.instance_id == '1554300700000000000'
ORDER BY time;

Hier ein paar Beispiele zu Ausgabezeilen:

Row | Time                    | Log                                         | Message
--- | ----------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------
 5  | 2015-02-21 03:40:14 UTC | projects/project-id/logs/syslog             | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269;
 6  | 2015-02-21 04:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 7  | 2015-02-21 04:49:58 UTC | projects/project-id/logs/apache-access      | 128.61.240.66 - - [21/Feb/2015:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"
 8  | 2015-02-21 05:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 9  | 2015-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2015:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"

App Engine-Beispielabfrage

Mit der folgenden BigQuery-Abfrage werden Logeinträge von fehlgeschlagenen App Engine-Anfragen des vergangenen Monats abgerufen:

SELECT
  timestamp AS Time,
  protoPayload.host AS Host,
  protoPayload.status AS Status,
  protoPayload.resource AS Path
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_,
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP()))
WHERE
  protoPayload.status != 200
ORDER BY time

Hier sind einige der Ergebnisse:

Row | Time                    | Host                                  | Status | Path
--- | ----------------------- | ------------------------------------- | ------ | ------
 6  | 2015-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo?thud=3
 7  | 2015-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo
 8  | 2015-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com         |    404 | /favicon.ico
 9  | 2015-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com         |    404 | /foo?thud=%22what???%22

Pub/Sub

Wir empfehlen die Verwendung von Pub/Sub, wenn Sie Cloud Logging-Logs in Software von Drittanbietern einbinden möchten.

An Pub/Sub weitergeleitete Logs sind im Allgemeinen innerhalb von Sekunden verfügbar, wobei 99 % der Logs in weniger als 60 Sekunden angezeigt werden können.

So können Sie weitergeleitete Logs anzeigen lassen, während sie über Pub/Sub gestreamt werden:

  1. Rufen Sie die Pub/Sub-Seite in der Konsole auf:

    Zu Pub/Sub

  2. Suchen oder erstellen Sie ein Abo für das Thema, das in der Logsenke verwendet wird, und rufen Sie einen Logeintrag daraus ab. Sie müssen möglicherweise warten, bis ein neuer Logeintrag veröffentlicht wird.

Ausführliche Informationen zur Organisation von Logs in Pub/Sub finden Sie in diesem Dokument unter Logorganisation.

Routing-Häufigkeit

Wenn Sie Logs in ein Pub/Sub-Thema weiterleiten, veröffentlicht Logging jeden Logeintrag sofort nach dem Empfang als Pub/Sub-Nachricht.

Logs organisieren

Das Feld data jeder Nachricht ist ein Base64-codiertes LogEntry-Objekt. Beispielsweise kann ein Pub/Sub-Abonnent das folgende Objekt aus einem Thema abrufen, das Logeinträge empfängt. Das angezeigte Objekt enthält eine einzelne Nachricht. Pub/Sub kann aber möglicherweise auch mehrere Nachrichten zurückgeben, wenn mehrere Logeinträge verfügbar sind. Der Wert data (ca. 600 Zeichen) und der Wert ackId (ca. 200 Zeichen) wurden gekürzt, um das Beispiel besser lesbar zu machen:

{
 "receivedMessages": [
  {
   "ackId": "dR1JHlAbEGEIBERNK0EPKVgUWQYyODM...QlVWBwY9HFELH3cOAjYYFlcGICIjIg",
   "message": {
    "data": "eyJtZXRhZGF0YSI6eyJzZXZ0eSI6Il...Dk0OTU2G9nIjoiaGVsbG93b3JsZC5sb2cifQ==",
    "attributes": {
     "compute.googleapis.com/resource_type": "instance",
     "compute.googleapis.com/resource_id": "123456"
    },
    "messageId": "43913662360"
   }
  }
 ]
}

Wenn Sie das Feld data decodieren und formatieren, erhalten Sie das folgende InfoType-Objekt:

{
  "log": "helloworld.log",
  "insertId": "2015-04-15|11:41:00.577447-07|10.52.166.198|-1694494956",
  "textPayload": "Wed Apr 15 20:40:51 CEST 2015 Hello, world!",
  "timestamp": "2015-04-15T18:40:56Z",
  "labels": {
    "compute.googleapis.com\/resource_type": "instance",
    "compute.googleapis.com\/resource_id": "123456"
  },
  "severity": "WARNING"
  }
}

Drittanbieter in Pub/Sub einbinden

Logging unterstützt die Logging-Integration von Drittanbietern wie z. B. Splunk. Eine aktuelle Liste der Einbindungen für die Operations Suite von Google Cloud finden Sie unter Partner.

Sie leiten Ihre Logs über ein Pub/Sub-Thema weiter und der Drittanbieter erhält dann Ihre Logs durch Abonnieren des gleichen Themas.

Für die Integration führen Sie in der Regel die folgenden Schritte aus:

  1. Lassen Sie sich von dem Drittanbieter einen Google Cloud-Dienstkontonamen geben, der über dessen Google Cloud-Projekt erstellt wurde. Beispiel: 12345-xyz@developer.gserviceaccount.com Erteilen Sie dem Drittanbieter anhand dieses Namens die Empfangsberechtigung für Ihre Logs.

  2. Aktivieren Sie in Ihrem Projekt mit den Logs die Pub/Sub API.

  3. Pub/Sub API aktivieren.

    Aktivieren Sie die API

  4. Erstellen Sie ein Pub/Sub-Thema. Sie können ein Thema erstellen, wenn Sie eine Logsenke konfigurieren oder diese Schritte ausführen:

    1. Rufen Sie die Pub/Sub-Themenliste auf.
    2. Wählen Sie Thema erstellen aus und geben Sie einen Themennamen ein. Beispiel: projects/my-project-id/topics/my-pubsub-topic Die Logs werden in dieses Thema weitergeleitet.

      Jede Nachricht, die an das Thema gesendet wird, enthält den Zeitstempel des weitergeleiteten Logeintrags in der Pub/Sub-Nachricht attributes; zum Beispiel:

      "attributes": {
        "logging.googleapis.com/timestamp": "2018-10-01T00:00:00Z"
      }
      
    3. Klicken Sie auf Erstellen.

    4. Autorisieren Sie Logging, Logs in das Thema weiterzuleiten. Eine Anleitung finden Sie unter Berechtigungen für Pub/Sub festlegen.

  5. Autorisieren Sie den Drittanbieter, das Thema zu abonnieren:

    1. Bleiben Sie in der Console in der Pub/Sub-Themenliste Ihres Projekts.
    2. Wählen Sie Ihr neues Thema aus.
    3. Wählen Sie Berechtigungen aus.
    4. Geben Sie den Namen für das Dienstkonto des Drittanbieters ein.
    5. Wählen Sie im Menü Rolle auswählen die Rolle Pub/Sub-Abonnent aus.
    6. Klicken Sie auf Add (Hinzufügen).
  6. Teilen Sie dem Drittanbieter den Namen Ihres Pub/Sub-Themas mit, zum Beispiel projects/my-project-number/topics/my-pubsub-topic. Dieser sollte das Thema abonnieren, bevor Sie den Weiterleitung starten.

  7. Beginnen Sie mit dem Weiterleiten der Logs, sobald Ihr Drittanbieter das Thema abonniert hat:

    1. Klicken Sie in Ihrem Projekt, das die weiterzuleitenden Logs enthält, über dem Suchfeld auf Export erstellen. Dadurch wird das Fenster Edit Export (Export bearbeiten) geöffnet:
    2. Geben Sie einen Namen für die Senke ein.
    3. Wählen Sie im Menü Sink Service (Senkendienst) die Option Cloud Pub/Sub aus.
    4. Wählen Sie im Menü Sink Destination (Ziel der Senke) das Pub/Sub-Thema aus, das der Drittanbieter abonniert hat.
    5. Wählen Sie Senke erstellen aus.
    6. Ein Dialogfeld mit der Meldung Senke erstellt wird angezeigt. Diese Nachricht zeigt an, dass Ihre Senke erfolgreich mit Berechtigungen erstellt wurde, um zukünftige übereinstimmende Logs an das von Ihnen ausgewählte Ziel zu schreiben.

Der Drittanbieter sollte sofort Logeinträge erhalten.

Unter Entwurfsmuster zum Routing nach Cloud Logging: Szenarien des Logging-Exports finden Sie Informationen zu gängigen Logrouting-Szenarien mit Pub/Sub.

Cloud Logging

Log-Buckets sind Cloud Logging-Speichercontainer in Ihren Google Cloud-Projekten, die Ihre Logdaten enthalten. Sie können Logsenken erstellen, um alle oder nur einen Teil Ihrer Logs an einen beliebigen Bucket in Cloud Logging weiterzuleiten. Dies bietet die Möglichkeit, festzulegen, in welchem Cloud-Projekt und mit welchen anderen Logs Ihre Logs gespeichert werden sollen.

Eine Anleitung zum Erstellen und Auflisten von Log-Buckets, die mit Ihrem Cloud-Projekt verknüpft sind, finden Sie unter Log-Buckets konfigurieren und verwalten.

Logeinträge organisieren

Logging-Log-Einträge sind LogEntry-Objekte.

Logeinträge desselben Logtyps, der in der LogEntry-Referenz mit [LOG_ID] bezeichnet ist, haben normalerweise dasselbe Format. Die folgende Tabelle enthält Beispiel-Logeinträge:

syslog

Die Compute Engine syslog ist ein benutzerdefinierter Logtyp, der vom Logging-Agent google-fluentd auf VM-Instanzen ausgeführt wird:

{
  logName: "projects/my-gcp-project-id/logs/syslog",
  timestamp: "2015-01-13T19:17:01Z",
  resource: {
    type: "gce_instance",
    labels: {
      instance_id: "12345",
      zone: "us-central1-a",
      project_id: "my-gcp-project-id"
    }
  },
  insertId: "abcde12345",
  textPayload: "Jan 13 19:17:01 my-gce-instance /USR/SBIN/CRON[29980]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)"
}

request_log

request_log von App Engine enthält Logeinträge mit protoPayload-Feldern, die Objekte vom Typ RequestLog enthalten:

{
  logName: "projects/my-gcp-project-id/logs/appengine.googleapis.com%2Frequest_log",
  timestamp: "2015-01-13T19:00:39.796169Z",
  resource: {
    type: "gae_app",
    labels: {
      module_id: "default",
      zone: "us6",
      project_id: "my-gcp-project-id",
      version_id: "20150925t173233"
    }
  }
  httpRequest: {
    status: 200
  }
  insertId: "abcde12345",
  operation: {
    id: "abc123",
    producer: "appengine.googleapis.com/request_id",
    first: true,
    last: true
  }
  protoPayload: {
    @type: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
    versionId: "20150925t173233",
    status: 200,
    startTime: "2017-01-13T19:00:39.796169Z",
    # ...
    appId: "s~my-gcp-project-id",
    appEngineRelease: "1.9.17",
  }
}

activity

activity ist ein Audit-Log einer Administratoraktivität. Seine Nutzlast ist eine JSON-Darstellung vom Typ AuditLog:

{
 logName: "projects/my-gcp-project-id/logs/cloudaudit.googleapis.com%2Factivity"
 timestamp: "2017-04-22T13:41:32.245Z"
 severity: "NOTICE"
 resource: {
  type: "gce_instance"
  labels: {
   instance_id: "2403273232180765234"
   zone: "us-central1-b"
   project_id: "my-gcp-project-id"
  }
 }
 insertId: "54DC1882F4B49.A4996C2.6A02F4C1"
 operation: {
  id: "operation-1492868454262-54dc185e9a4f0-249fe233-f73d472a"
  producer: "compute.googleapis.com"
  last: true
 }
 protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail: "649517127304@cloudservices.gserviceaccount.com"
  }
  requestMetadata: {…}
  serviceName: "compute.googleapis.com"
  methodName: "v1.compute.instances.delete"
  resourceName: "projects/my-gcp-project-id/zones/us-central1-b/instances/abc123"
 }
}

Splunk

Logging unterstützt die Integration mit Splunk. Dazu werden Logs über ein Pub/Sub-Thema weitergeleitet. Informationen zum Erstellen eines Pub/Sub-Themas und zum Autorisieren von Splunk zum Abonnieren dieses Themas finden Sie unter Drittanbieter-Integration mit Pub/Sub.

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 Ihren Filter, um zu ermitteln, ob Logeinträge, die Ihrem Filter entsprechen, kürzlich in Logging angekommen sind:

Zum "Log Router"

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.

Problembehebung

Wenn Logs aus dem Ziel der Senke fehlen oder Sie vermuten, dass die Senke nicht ordnungsgemäß weitergeleitet wird, lesen Sie den Abschnitt Fehler bei Routing und Logsenken beheben.

Preise

Beim Weiterleiten von Logs fallen für Cloud Logging keine Gebühren an. Es können aber Gebühren am Ziel erhoben werden. Weitere Informationen finden Sie in den Preisdetails des entsprechenden Dienstes:

Zusätzlich zu den Gebühren am Ziel fallen weitere Gebühren für das Generieren von VPC-Flusslogs an, wenn Sie Ihre Virtual Private Cloud-Flusslogs senden und dann von Cloud Logging ausschließen.