Exportierte Logs verwenden

Auf dieser Seite wird erläutert, wie Sie exportierte Logeinträge in Cloud Storage, BigQuery, Pub/Sub und Cloud Logging finden und nutzen können.

Eine konzeptionelle Übersicht über das Exportieren von Logs mit Cloud Logging erhalten Sie unter Logexporte.

Cloud Logging

Eine Anleitung zum Exportieren Ihrer Logs mit Cloud Logging findet sich auf folgenden Seiten:

Cloud Storage

So rufen Sie Ihre exportierten Logs in Cloud Storage auf:

  1. Öffnen Sie in der Cloud Console den Cloud Storage Browser:

    Zum Cloud Storage Browser

  2. Wählen Sie den Ziel-Bucket für Ihren Logexport aus.

Ausführliche Informationen zur Organisation von Logs im Bucket finden Sie auf dieser Seite unter Cloud Storage-Organisation.

Verfügbarkeit von exportierten Logs

Wenn keine exportierten Logs vorhanden sind, rufen Sie die Systemmesswerte für den Export auf. Die Systemmesswerte für den Export geben darüber Aufschluss, wie viele Logeinträge exportiert und wie viele Logeinträge aufgrund von Fehlern gelöscht wurden. Wenn die Systemmesswerte für den Export anzeigen, dass keine Logeinträge exportiert wurden, prüfen Sie anhand der Exportabfrage, ob Logeinträge, die Ihrer Abfrage entsprechen, kürzlich in Logging eingegangen sind:

Zu den Logexporten

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

Organisation exportierter Logs

Wenn Sie Logs in einen Cloud Storage-Bucket exportieren, schreibt Logging eine Gruppe von Dateien in den Bucket. Die Dateien sind nach Logtyp 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 Bucket kann Logs von mehreren Ressourcentypen enthalten.

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 exportierten 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 einer Stunde ab 08:00 Uhr UTC. Die Zeitstempel der Logeinträge werden in UTC (koordinierte Weltzeit) ausgedrückt.

Um alle Logeinträ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 Log-Einträ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 auf dieser Seite unter LogEntry-Typ.

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

Abfragen

Beispiele für Abfragen zum Exportieren von Logs in Cloud Storage finden Sie unter Beispielabfragen.

BigQuery

So rufen Sie Ihre exportierten Logs in BigQuery auf:

  1. Rufen Sie in der Cloud Console die Seite „BigQuery” 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.

Unter Tabellenorganisation lesen Sie, wie die Tabellen organisiert sind, und unter Logexport und das BigQuery-Schema wie die Felder der exportierten Logeinträge benannt sind.

Verfügbarkeit von exportierten Logs

Wenn keine exportierten Logs vorhanden sind, rufen Sie die Systemmesswerte für den Export auf. Die Systemmesswerte für den Export geben darüber Aufschluss, wie viele Logeinträge exportiert und wie viele Logeinträge aufgrund von Fehlern gelöscht wurden. Wenn die Systemmesswerte für den Export anzeigen, dass keine Logeinträge exportiert wurden, prüfen Sie anhand der Exportabfrage, ob Logeinträge, die Ihrer Abfrage entsprechen, kürzlich in Logging eingegangen sind:

Zu den Logexporten

Wenn eine neue Tabelle erstellt wird, während Logging die Logeinträge in BigQuery exportiert, 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. Weitere Informationen finden Sie nachstehend unter Tabellenorganisation.

Tabellenorganisation

Wenn Sie die Logs in ein BigQuery-Dataset exportieren, werden in Stackdriver Logging für die exportierten 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 exportierte 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-Web-UI eine Tabelle mit exportierten Logeinträgen auswählen.

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

Abfragen

Beispiele für Abfragen zum Exportieren von Logs nach BigQuery finden Sie unter Beispielabfragen.

Weitere Informationen zur BigQuery-Abfragesyntax finden Sie in der Abfragereferenz. Besonders nützlich sind Platzhalterfunktionen in Tabellen, die Abfragen über mehrere Tabellen hinweg ermöglichen, sowie der Flatten-Operator, mit dem Sie Daten aus wiederkehrenden Feldern anzeigen lassen können.

Beispiel einer Compute Engine-Logabfrage

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 "-" "-"

Beispiel einer App Engine-Logabfrage

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.

In Pub/Sub exportierte 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 exportierte Logs anzeigen lassen, während sie über Pub/Sub gestreamt werden:

  1. Rufen Sie in der Cloud Console die Seite "Pub/Sub" auf.

    Zu Pub/Sub

  2. Suchen oder erstellen Sie ein Abo für das Thema des Logexports 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 der Logs finden Sie auf dieser Seite unter Organisation exportierter Logs.

Verfügbarkeit von exportierten Logs

Wenn keine exportierten Logs vorhanden sind, rufen Sie die Systemmesswerte für den Export auf. Die Systemmesswerte für den Export geben darüber Aufschluss, wie viele Logeinträge exportiert und wie viele Logeinträge aufgrund von Fehlern gelöscht wurden. Wenn die Systemmesswerte für den Export anzeigen, dass keine Logeinträge exportiert wurden, prüfen Sie anhand der Exportabfrage, ob Logeinträge, die Ihrer Abfrage entsprechen, kürzlich in Logging eingegangen sind:

Zu den Logexporten

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

Organisation exportierter Logs

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 dekodieren und formatieren, erhalten Sie das folgende LogEntry-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 das Einbinden von Drittanbietern. Eine aktuelle Liste der Einbindungen für die Operations Suite von Google Cloud finden Sie unter Partner.

Sie exportieren Ihre Logs über ein Pub/Sub-Thema und der Drittanbieter empfängt Ihre Logs, indem er das gleiche Thema abonniert.

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. In Ihrem Projekt mit den Logs

  3. Aktivieren Sie die Pub/Sub API.

    Aktivieren Sie die API

  4. Erstellen Sie ein Pub/Sub-Thema. Sie können dies während der Konfiguration einer Logsenke tun oder mithilfe der folgenden Schritten:

    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 exportiert.

      Jede Nachricht, die an das Thema gesendet wird, enthält den Zeitstempel des exportierten 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 zu exportieren. Anleitungen dazu finden Sie unter Berechtigungen für Pub/Sub festlegen.

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

    1. Bleiben Sie in der Cloud 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 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 Export starten.

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

    1. Klicken Sie in Ihrem Projekt, das die zu exportierenden Logs enthält, über dem Suchfeld auf Export erstellen. Dadurch wird das Fenster Edit Export (Export bearbeiten) geöffnet:

      Fenster

    2. Geben Sie einen Sink Name (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 Create Sink (Senke erstellen) aus, um mit dem Export zu beginnen.

    6. Ein Dialogfeld Senke erstellt wird eingeblendet. Dies zeigt an, dass Ihre Exportsenke 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.

Log-Eintragsobjekte

Stackdriver Logging-Logeinträge sind Objekte vom Typ LogEntry.

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

syslog von Compute Engine ist ein vom Logging-Agent erstellter benutzerdefinierter Logtyp google-fluentd, der 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"
 }
}

Spät ankommende Logeinträge

Exportierte Logeinträ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. Exportierte Logdatei-Shards mit dem Suffix An ("Append") enthalten Logeinträge, die verspätet angekommen sind.

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

Außerdem kombiniert App Engine 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 Log-Zeilen haben jeweils eine "Anfrage-ID" zur Identifizierung des primären Eintrags. Im 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.

Preise

Für exportierte Logs fallen keine Cloud Logging-Gebühren an. Es können aber Gebühren am Ziel erhoben werden. Weitere Informationen finden Sie auf der Preisseite des jeweiligen Produkts:

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.