SQL-Beispielabfragen

Dieses Dokument enthält Beispielabfragen für Logeinträge, die in Log-Buckets gespeichert sind, die auf Log Analytics umgestellt wurden. Sie können auf diesen Buckets SQL-Abfragen über die Seite Log Analytics in der Google Cloud Console ausführen. Weitere Beispiele finden Sie in den GitHub-Repositories logging-analytics-samples und security-analytics.

In diesem Dokument werden weder SQL noch die Weiterleitung und Speicherung von Logeinträgen beschrieben. Weitere Informationen zu diesen Themen finden Sie im Abschnitt Nächste Schritte.

Hinweise

In diesem Abschnitt werden die Schritte beschrieben, die Sie ausführen müssen, bevor Sie Log Analytics verwenden können.

Log-Buckets konfigurieren

Prüfen Sie, ob Ihre Log-Buckets für die Verwendung von Log Analytics aktualisiert wurden:

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

   Zum Log-Speicher

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Achten Sie für jeden Log-Bucket, der eine Logansicht enthält, die Sie abfragen möchten, darauf, dass in der Spalte Log Analytics verfügbar der Wert Offen angezeigt wird. Wenn Upgrade durchführen angezeigt wird, klicken Sie auf Upgrade durchführen und schließen Sie das Dialogfeld ab.

IAM-Rollen und -Berechtigungen konfigurieren

In diesem Abschnitt werden die IAM-Rollen oder -Berechtigungen beschrieben, die für die Verwendung von Log Analytics erforderlich sind:

• Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zur Verwendung von Log Analytics und zum Abfragen von Protokollansichten benötigen:

  • So rufen Sie die Log-Buckets _Required und _Default ab: Loganzeige (roles/logging.viewer)
  • So rufen Sie alle Logansichten in einem Projekt ab: Zugriffsberechtigter für Logbetrachtung (roles/logging.viewAccessor)

  Sie können ein Hauptkonto auf eine bestimmte Protokollansicht beschränken, indem Sie der Rolle „Zugriffsberechtigter für Protokollansicht“ auf Projektebene eine IAM-Bedingung hinzufügen oder der Richtliniendatei der Protokollansicht eine IAM-Bindung hinzufügen. Weitere Informationen finden Sie unter Zugriff auf eine Logansicht steuern.

  Dies sind dieselben Berechtigungen, die Sie zum Aufrufen von Logeinträgen auf der Seite Log-Explorer benötigen. Informationen zu zusätzlichen Rollen, die Sie benötigen, um Ansichten in benutzerdefinierten Buckets abzufragen oder die _AllLogs-Ansicht des _Default-Log-Buckets abzufragen, finden Sie unter Cloud Logging-Rollen.

Verwendung dieser Abfragen

Wenn Sie die in diesem Dokument auf der Seite Log Analytics gezeigten Abfragen verwenden möchten, ersetzen Sie TABLE_NAME_OF_LOG_VIEW durch den Tabellennamen der Logdatenansicht, die Sie abfragen möchten.

Wenn Sie eine Protokollansicht abfragen möchten, verwenden Sie in der FROM-Klausel das folgende Format:

FROM `PROJECT_ID.LOCATION.BUCKET_ID.VIEW_ID`

Im Folgenden wird die Bedeutung der Felder in den vorherigen Ausdrücken beschrieben:

• PROJECT_ID: Die Kennung des Projekts.
• LOCATION: Der Speicherort der Protokollansicht.
• BUCKET_ID: Der Name oder die ID des Log-Buckets.
• VIEW_ID: Die Kennung der Log-Ansicht.

Wenn Sie ein verknüpftes BigQuery-Dataset erstellt haben, können Sie es auf der Seite BigQuery Studio abfragen. Ersetzen Sie auf dieser Seite TABLE_NAME_OF_LOG_VIEW durch den Pfad zur Tabelle im verknüpften Dataset. Wenn Sie beispielsweise die Ansicht _AllLogs im verknüpften Dataset mydataset im Projekt myproject abfragen möchten, legen Sie dieses Feld auf myproject.mydataset._AllLogs fest.

Rufen Sie die Seite Log Analytics auf.

So öffnen Sie die Seite Log Analytics:

1. Rufen Sie in der Google Cloud Console die Seite Log Analytics auf.

   Zu Log Analytics

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Optional: Wenn Sie das Schema für die Log-Ansicht ermitteln möchten, suchen Sie in der Liste Log-Ansichten nach der Ansicht und wählen Sie den Namen der Ansicht aus.

   Das Schema wird angezeigt. Mit dem Feld Filter können Sie bestimmte Felder finden. Das Schema kann nicht geändert werden.

Informationen zum Zugriff auf die Standardabfrage für eine Protokollansicht finden Sie unter Logs mit Log Analytics abfragen und analysieren.

Logs filtern

Mit SQL-Abfragen wird festgelegt, welche Einträge in der Protokollansicht verarbeitet werden sollen. Anschließend werden diese Einträge gruppiert und Aggregatfunktionen ausgeführt. Wenn keine Gruppierungs- und Aggregationsvorgänge aufgeführt sind, enthält das Ergebnis der Abfrage die Zeilen, die durch den Filtervorgang ausgewählt wurden. Die Beispiele in diesem Abschnitt veranschaulichen die Filterung.

Nach Uhrzeit filtern

Wir empfehlen, die Zeitspanne für Ihre Abfrage über die Zeitraumauswahl festzulegen. Diese Auswahl wird automatisch verwendet, wenn in einer Abfrage in der WHERE-Klausel kein timestamp-Feld angegeben ist. Wenn Sie beispielsweise die Daten der letzten Woche aufrufen möchten, wählen Sie in der Auswahl für den Zeitraum Letzte 7 Tage aus. Mit der Auswahl für den Zeitraum können Sie auch einen Start- und Endzeitpunkt festlegen, einen Zeitraum für die Anzeige angeben und Zeitzonen ändern.

Wenn Sie in der WHERE-Klausel ein timestamp-Feld angeben, wird die Einstellung für die Auswahl des Zeitraums nicht verwendet. Im folgenden Beispiel werden die Daten mithilfe der Funktion TIMESTAMP_SUB gefiltert. Damit lässt sich ein Rückblickszeitraum ab der aktuellen Uhrzeit angeben:

WHERE
  timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

Weitere Informationen zum Filtern nach Zeit finden Sie unter Zeitfunktionen und Zeitstempelfunktionen.

Nach Ressource filtern

Wenn Sie nach Ressource filtern möchten, fügen Sie eine resource.type-Einschränkung hinzu.

Mit der folgenden Abfrage werden beispielsweise die Daten der letzten Stunde gelesen. Anschließend werden die Zeilen beibehalten, deren Ressourcentyp mit gce_instance übereinstimmt. Die Ergebnisse werden dann sortiert und bis zu 100 Einträge werden angezeigt:

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance"
ORDER BY timestamp ASC
LIMIT 100

Nach Schweregrad filtern

Sie können mit einer Einschränkung wie severity = 'ERROR' nach einem bestimmten Schweregrad filtern. Eine weitere Möglichkeit besteht darin, die Anweisung IN zu verwenden und eine Reihe gültiger Werte anzugeben.

Mit der folgenden Abfrage werden beispielsweise die Daten der letzten Stunde gelesen und dann nur die Zeilen beibehalten, die ein Feld severity mit dem Wert 'INFO' oder 'ERROR' enthalten:

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL AND
  severity IN ('INFO', 'ERROR')
ORDER BY timestamp ASC
LIMIT 100

Bei der vorherigen Abfrage wird nach dem Wert des Felds severity gefiltert. Sie können jedoch auch Abfragen schreiben, die nach dem numerischen Wert des Logschweregrads filtern. Wenn Sie beispielsweise die severity-Zeilen durch die folgenden Zeilen ersetzen, gibt die Abfrage alle Logeinträge zurück, deren Schweregrad mindestens NOTICE ist:

  severity_number IS NOT NULL AND
  severity_number > 200

Informationen zu den aufgezählten Werten finden Sie unter LogSeverity.

Nach Logname filtern

Wenn Sie nach einem Lognamen filtern möchten, können Sie eine Einschränkung für den Wert des Felds log_name oder log_id hinzufügen. Das Feld log_name enthält den Ressourcenpfad. Das Feld enthält also Werte wie projects/myproject/logs/mylog. Im Feld log_id wird nur der Logname gespeichert, z. B. mylog.

Die folgende Abfrage liest beispielsweise die Daten der letzten Stunde, behält die Zeilen bei, in denen der Wert im Feld log_id cloudaudit.googleapis.com/data_access ist, und sortiert und zeigt die Ergebnisse an:

SELECT
  timestamp, log_id, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  log_id = "cloudaudit.googleapis.com/data_access"
ORDER BY timestamp ASC
LIMIT 100

Nach Ressourcenlabel filtern

Die meisten Deskriptoren für überwachte Ressourcen definieren Labels, mit denen die jeweilige Ressource identifiziert wird. Der Descriptor für eine Compute Engine-Instanz enthält beispielsweise Labels für die Zone, die Projekt-ID und die Instanz-ID. Beim Schreiben des Logeintrags werden jedem Feld Werte zugewiesen. Hier ein Beispiel:

{
   type: "gce_instance"
   labels: {
      instance_id: "1234512345123451"
      project_id: "my-project"
      zone: "us-central1-f"
   }
}

Da der Datentyp des Felds labels JSON ist, führt die Aufnahme einer Einschränkung wie resource.labels.zone = "us-centra1-f" in eine Abfrage zu einem Syntaxfehler. Wenn Sie den Wert eines Felds mit dem Datentyp „JSON“ abrufen möchten, verwenden Sie die Funktion JSON_VALUE.

In der folgenden Abfrage werden beispielsweise die neuesten Daten gelesen und dann die Zeilen beibehalten, bei denen die Ressource eine Compute Engine-Instanz ist, die sich in der Zone us-central1-f befindet:

SELECT
  timestamp, log_name, severity, JSON_VALUE(resource.labels.zone) AS zone, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance" AND
  JSON_VALUE(resource.labels.zone) = "us-central1-f"
ORDER BY timestamp ASC
LIMIT 100

Informationen zu allen Funktionen, mit denen JSON-Daten abgerufen und transformiert werden können, finden Sie unter JSON-Funktionen.

Nach HTTP-Anfrage filtern

Wenn Sie die Logansicht so filtern möchten, dass nur Logeinträge enthalten sind, die einer HTTP-Anfrage oder ‑antwort entsprechen, fügen Sie eine http_request IS NOT NULL-Einschränkung hinzu:

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL
ORDER BY timestamp
LIMIT 100

Die folgende Abfrage enthält nur Zeilen, die GET- oder POST-Anfragen entsprechen:

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.request_method IN ('GET', 'POST')
ORDER BY timestamp ASC
LIMIT 100

Nach HTTP-Status filtern

Wenn Sie nach HTTP-Status filtern möchten, ändern Sie die WHERE-Klausel so, dass das Feld http_request.status definiert werden muss:

SELECT
  timestamp, log_name, http_request.status, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.status IS NOT NULL
ORDER BY timestamp ASC
LIMIT 100

Um den Datentyp zu ermitteln, der in einem Feld gespeichert ist, können Sie das Schema aufrufen oder das Feld anzeigen. Die Ergebnisse der vorherigen Abfrage zeigen, dass im Feld http_request.status Ganzzahlwerte gespeichert werden.

Nach einem Feld mit einem JSON-Typ filtern

Wenn Sie einen Wert aus einer Spalte mit dem Datentyp „JSON“ extrahieren möchten, verwenden Sie die Funktion JSON_VALUE.

Betrachten Sie die folgenden Abfragen:

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.status IS NOT NULL

und

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  JSON_VALUE(json_payload.status) IS NOT NULL

Bei den vorherigen Abfragen wird der Wert des Felds json_payload im Logeintrag getestet. Bei beiden Abfragen werden Logeinträge verworfen, die kein Feld mit der Bezeichnung json_payload enthalten. Der Unterschied zwischen diesen beiden Abfragen besteht in der letzten Zeile, in der definiert wird, was mit NULL verglichen wird. Betrachten wir nun eine Logansicht mit zwei Logeinträgen. Für einen Logeintrag hat das Feld json_payload das folgende Format:

{
    status: {
        measureTime: "1661517845"
    }
}

Beim anderen Logeintrag hat das Feld json_payload eine andere Struktur:

{
    @type: "type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished"
    jobName: "projects/my-project/locations/us-central1/jobs/test1"
    relativeUrl: "/food=cake"
    status: "NOT_FOUND"
    targetType: "APP_ENGINE_HTTP"
}

Beide vorherigen Logeinträge erfüllen die Einschränkung json_payload.status IS NOT NULL. Das Ergebnis der ersten Abfrage enthält also beide Logeinträge. Wenn die Einschränkung jedoch JSON_VALUE(json_payload.status) IS NOT NULL ist, wird nur der zweite Logeintrag in das Abfrageergebnis aufgenommen.

Nach regulären Ausdrücken filtern

Wenn Sie den Teilstring zurückgeben möchten, der mit einem regulären Ausdruck übereinstimmt, verwenden Sie die Funktion REGEXP_EXTRACT. Der Rückgabetyp dieser Funktion ist entweder STRING oder BYTES.

Die folgende Abfrage zeigt die neuesten empfangenen Logeinträge an, behält die Einträge mit einem json_payload.jobName-Feld bei und zeigt dann den Teil des Namens an, der mit test beginnt:

SELECT
  timestamp, REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
ORDER BY timestamp DESC
LIMIT 20

Weitere Beispiele finden Sie in der Dokumentation zu REGEXP_EXTRACT. Beispiele für andere reguläre Ausdrücke, die Sie verwenden können, finden Sie unter Funktionen, Operatoren und Bedingungen.

Die in diesem Beispiel gezeigte Abfrage ist nicht effizient. Verwenden Sie für eine Teilstringübereinstimmung wie die hier gezeigte die Funktion CONTAINS_SUBSTR.

Logeinträge gruppieren und zusammenfassen

In diesem Abschnitt bauen wir auf den vorherigen Beispielen auf und zeigen, wie Sie Logeinträge gruppieren und zusammenfassen können. Wenn Sie keine Gruppierung, aber eine Aggregation angeben, wird ein einzelnes Ergebnis ausgegeben, da SQL alle Zeilen, die der WHERE-Klausel entsprechen, als eine einzige Gruppe behandelt.

Jeder SELECT-Ausdruck muss in den Gruppenfeldern enthalten sein oder aggregiert werden.

Nach Zeit gruppieren

Wenn Sie Daten nach Zeit gruppieren möchten, verwenden Sie die Funktion TIMESTAMP_TRUNC. Damit wird ein Zeitstempel auf eine bestimmte Granularität wie MINUTE gekürzt. Beispiel: Ein Zeitstempel von 15:30:11, der als hours:minutes:seconds formatiert ist, wird zu 15:30:00, wenn die Granularität auf MINUTE festgelegt ist.

In der folgenden Abfrage werden die Daten gelesen, die im durch die Auswahl für den Zeitraum angegebenen Intervall empfangen wurden. Anschließend werden nur die Zeilen beibehalten, bei denen der Wert des Felds json_payload.status nicht NULL ist. In der Abfrage wird der Zeitstempel in jeder Zeile auf die Stunde gerundet und die Zeilen dann nach dem gerundeten Zeitstempel und dem Status gruppiert:

SELECT
  TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
  JSON_VALUE(json_payload.status) AS status,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload IS NOT NULL AND
  JSON_VALUE(json_payload.status) IS NOT NULL
GROUP BY hour,status
ORDER BY hour ASC

Weitere Beispiele finden Sie in der Dokumentation zu TIMESTAMP_TRUNC. Informationen zu anderen zeitbezogenen Funktionen finden Sie unter Datums- und Uhrzeitfunktionen.

Nach Ressource gruppieren

Die folgende Abfrage liest die Daten der letzten Stunde und gruppiert die Protokolleinträge dann nach dem Ressourcentyp. Anschließend wird die Anzahl der Zeilen für jeden Ressourcentyp gezählt und eine Tabelle mit zwei Spalten zurückgegeben. Die erste Spalte enthält den Ressourcentyp und die zweite Spalte die Anzahl der Zeilen für diesen Ressourcentyp:

SELECT
   resource.type, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY resource.type
LIMIT 100

Nach Schweregrad gruppieren

Die folgende Abfrage liest die Daten der letzten Stunde und behält dann Zeilen mit einem Schweregradfeld bei. Die Abfrage gruppiert dann die Zeilen nach Schweregrad und zählt die Anzahl der Zeilen für jede Gruppe:

SELECT
  severity, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL
GROUP BY severity
ORDER BY severity
LIMIT 100

Nach log_id gruppieren

Das Ergebnis der folgenden Abfrage ist eine Tabelle mit zwei Spalten. In der ersten Spalte sind die Lognamen und in der zweiten die Anzahl der Logeinträge aufgeführt, die in das Protokoll geschrieben wurden. Die Abfrage sortiert die Ergebnisse nach der Anzahl der Einträge:

SELECT
  log_id, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY log_id
ORDER BY count DESC
LIMIT 100

Durchschnittliche Latenz für HTTP-Anfrage berechnen

In der folgenden Abfrage wird die Gruppierung nach mehreren Spalten und die Berechnung eines Durchschnittswerts veranschaulicht. Die Abfrage gruppiert Zeilen nach der URL in der HTTP-Anfrage und nach dem Wert des Felds labels.checker_location. Nach der Gruppierung der Zeilen berechnet die Abfrage die durchschnittliche Latenz für jede Gruppe:

SELECT
  JSON_VALUE(labels.checker_location) AS location,
  AVG(http_request.latency.seconds) AS secs, http_request.request_url
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.request_method IN ('GET')
GROUP BY http_request.request_url, location
ORDER BY location
LIMIT 100

Im vorherigen Ausdruck ist JSON_VALUE erforderlich, um den Wert des Felds labels.checker_location zu extrahieren, da der Datentyp für labels JSON ist. Sie verwenden diese Funktion jedoch nicht, um den Wert aus dem Feld http_request.latency.seconds zu extrahieren. Das letzte Feld hat den Datentyp „integer“.

Durchschnittliche gesendeten Byte für einen Subnetzwerktest berechnen

Die folgende Abfrage veranschaulicht, wie Sie die durchschnittliche Anzahl der gesendeten Byte nach Standort anzeigen können.

Die Abfrage liest die Daten der letzten Stunde und behält nur die Zeilen bei, deren Spalte „Ressourcentyp“ gce_subnetwork ist und deren Spalte json_payload nicht NULL ist. Als Nächstes werden die Zeilen in der Abfrage nach dem Standort der Ressource gruppiert. Im Gegensatz zum vorherigen Beispiel, in dem die Daten als numerischer Wert gespeichert werden, ist der Wert des Felds bytes_sent ein String. Sie müssen ihn daher in einen FLOAT64 konvertieren, bevor Sie den Durchschnitt berechnen:

SELECT JSON_VALUE(resource.labels.location) AS location,
   AVG(CAST(JSON_VALUE(json_payload.bytes_sent) AS FLOAT64)) AS bytes
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_subnetwork" AND
  json_payload IS NOT NULL
GROUP BY location
LIMIT 100

Das Ergebnis der vorherigen Abfrage ist eine Tabelle, in der jede Zeile einen Standort und die durchschnittlich gesendeten Bytes für diesen Standort enthält.

Informationen zu allen Funktionen, mit denen JSON-Daten abgerufen und transformiert werden können, finden Sie unter JSON-Funktionen.

Weitere Informationen zu CAST und anderen Konversionsfunktionen finden Sie unter Konversionsfunktionen.

Anzahl der Logeinträge mit einem Feld zählen, das einem Muster entspricht

Wenn Sie den Teilstring zurückgeben möchten, der mit einem regulären Ausdruck übereinstimmt, verwenden Sie die Funktion REGEXP_EXTRACT. Der Rückgabetyp dieser Funktion ist entweder STRING oder BYTES.

Mit der folgenden Abfrage werden die Logeinträge beibehalten, für die der Wert des Felds json_payload.jobName nicht NULL ist. Anschließend werden die Einträge nach dem Namenssuffix gruppiert, das mit test beginnt. Abschließend wird in der Abfrage die Anzahl der Einträge in jeder Gruppe gezählt:

SELECT
  REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
GROUP BY name
ORDER BY count
LIMIT 20

Weitere Beispiele finden Sie in der Dokumentation zu REGEXP_EXTRACT. Beispiele für andere reguläre Ausdrücke, die Sie verwenden können, finden Sie unter Funktionen, Operatoren und Bedingungen.

Spaltenübergreifende Suche

In diesem Abschnitt werden zwei verschiedene Ansätze beschrieben, mit denen Sie in mehreren Spalten einer Tabelle suchen können.

Tokenbasierte Suche

Wenn Sie in einer Log-Ansicht nach Einträgen suchen möchten, die mit einer Reihe von Suchbegriffen übereinstimmen, verwenden Sie die Funktion SEARCH. Für diese Funktion sind zwei Parameter erforderlich: der Ort, an dem gesucht werden soll, und die Suchanfrage. Da für die Funktion SEARCH bestimmte Regeln für die Suche nach Daten gelten, empfehlen wir Ihnen, die SEARCH-Dokumentation zu lesen.

Bei der folgenden Abfrage werden nur die Zeilen beibehalten, die ein Feld mit der genauen Übereinstimmung „35.193.12.15“ haben:

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` AS t
WHERE
  proto_payload IS NOT NULL AND
  log_id = "cloudaudit.googleapis.com/data_access" AND
  SEARCH(t,"`35.193.12.15`")
ORDER BY timestamp ASC
LIMIT 20

In der vorherigen Abfrage wird der Wert, nach dem gesucht werden soll, in Backticks gesetzt. So wird sichergestellt, dass die Funktion SEARCH nach einer genauen Übereinstimmung zwischen einem Feldwert und dem Wert zwischen den Backticks sucht.

Wenn Anführungszeichen im Abfragestring weggelassen werden, wird der Abfragestring gemäß den in der SEARCH-Dokumentation definierten Regeln aufgeteilt. Wenn beispielsweise die folgende Anweisung ausgeführt wird, wird der Abfragestring in vier Tokens aufgeteilt: „35“, „193“, „12“ und „15“:

  SEARCH(t,"35.193.12.15")

Die vorherige SEARCH-Anweisung entspricht einer Zeile, wenn ein einzelnes Feld mit allen vier Tokens übereinstimmt. Die Reihenfolge der Tokens spielt keine Rolle.

Eine Abfrage kann mehrere SEARCH-Anweisungen enthalten. In der vorherigen Abfrage könnten Sie den Filter für die Log-ID beispielsweise durch eine Anweisung wie die folgende ersetzen:

  SEARCH(t,"`cloudaudit.googleapis.com/data_access`")

Mit der vorherigen Anweisung wird in jedem Feld der Logeinträge in der Loganzeige gesucht, während mit der ursprünglichen Anweisung nur das Feld log_id der Logeinträge durchsucht wird.

Wenn Sie mehrere Suchanfragen in mehreren Feldern ausführen möchten, trennen Sie die einzelnen Strings durch ein Leerzeichen. Mit der folgenden Anweisung werden beispielsweise Zeilen gefunden, in denen ein Feld „Hello World“, „glücklich“ und „Tage“ enthält:

  SEARCH(t,"`Hello World` happy days")

Außerdem können Sie bestimmte Felder durchsuchen, anstatt die gesamte Tabelle. Mit der folgenden Anweisung wird beispielsweise nur in den Spalten text_payload und json_payload gesucht:

   SEARCH((text_payload, json_payload) ,"`35.222.132.245`")

Informationen zur Verarbeitung der Parameter der Funktion SEARCH finden Sie auf der BigQuery-Referenzseite Suchfunktionen.

Nach Teilstrings suchen

Wenn Sie prüfen möchten, ob ein Wert in einem Ausdruck vorhanden ist, ohne die Groß-/Kleinschreibung zu berücksichtigen, verwenden Sie die Funktion CONTAINS_SUBSTR. Diese Funktion gibt TRUE zurück, wenn der Wert vorhanden ist, andernfalls FALSE. Der Suchwert muss ein STRING-Literal sein, aber nicht das Literal NULL.

Mit der folgenden Abfrage werden beispielsweise alle Audit-Logeinträge zum Datenzugriff mit einer bestimmten IP-Adresse abgerufen, deren Zeitstempel in einem bestimmten Zeitraum liegen. Abschließend werden die Ergebnisse sortiert und die 20 ältesten Ergebnisse angezeigt:

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` AS t
WHERE
  proto_payload IS NOT NULL AND
  log_id = "cloudaudit.googleapis.com/data_access" AND
  CONTAINS_SUBSTR(t,"35.193.12.15")
ORDER BY timestamp ASC
LIMIT 20

In der vorherigen Abfrage wird ein Teilstringtest durchgeführt. Daher entspricht eine Zeile mit „35.193.12.152“ der CONTAINS_SUBSTR-Anweisung.

Daten aus mehreren Quellen kombinieren

Abfrageanweisungen durchsuchen eine oder mehrere Tabellen oder Ausdrücke und geben die berechneten Ergebniszeilen zurück. Mit Abfrageanweisungen können Sie beispielsweise die Ergebnisse von SELECT-Anweisungen für verschiedene Tabellen oder Datensätze auf unterschiedliche Weise zusammenführen und dann die Spalten aus den kombinierten Daten auswählen.

Daten aus zwei Tabellen mit Joins kombinieren

Wenn Sie Informationen aus zwei Tabellen kombinieren möchten, verwenden Sie einen der Join-Operatoren. Die Art des Joins und die verwendete bedingte Klausel bestimmen, wie Zeilen kombiniert und verworfen werden.

Mit der folgenden Abfrage werden die json_payload-Felder aus Zeilen in zwei verschiedenen Tabellen zurückgegeben, die von derselben Trace-Spanne geschrieben wurden. Die Abfrage führt einen inneren JOIN über zwei Tabellen für Zeilen aus, bei denen die Werte der Spalten span_id und trace in beiden Tabellen übereinstimmen. Aus diesem Ergebnis werden dann die Felder timestamp, severity und json_payload aus TABLE_NAME_OF_LOG_VIEW_1, das Feld json_payload aus TABLE_NAME_OF_LOG_VIEW_2 und die Werte der Felder span_id und trace ausgewählt, anhand derer die beiden Tabellen zusammengeführt wurden. Es werden bis zu 100 Zeilen zurückgegeben:

SELECT
  a.timestamp, a.severity, a.json_payload, b.json_payload, a.span_id, a.trace
FROM `TABLE_NAME_OF_LOG_VIEW_1` a
JOIN `TABLE_NAME_OF_LOG_VIEW_2` b
ON
  a.span_id = b.span_id AND
  a.trace = b.trace
LIMIT 100

Mehrere Auswahlen mit Unions kombinieren

Wenn Sie die Ergebnisse von zwei oder mehreren SELECT-Anweisungen kombinieren und doppelte Zeilen verwerfen möchten, verwenden Sie den Operator UNION. Wenn Sie doppelte Zeilen beibehalten möchten, verwenden Sie den Operator UNION ALL.

In der folgenden Abfrage werden die Daten der letzten Stunde aus TABLE_NAME_OF_LOG_VIEW_1 gelesen, das Ergebnis mit den Daten der letzten Stunde aus TABLE_NAME_OF_LOG_VIEW_2 zusammengeführt, die zusammengeführten Daten nach steigendem Zeitstempel sortiert und dann die 100 ältesten Einträge angezeigt:

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM(
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_1`
  UNION ALL
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_2`
)
ORDER BY timestamp ASC
LIMIT 100

Doppelte Logeinträge entfernen

In Log Analytics werden keine doppelten Logeinträge entfernt, bevor eine Abfrage ausgeführt wird. Das Verhalten unterscheidet sich von dem, wenn Sie Logeinträge mit dem Log-Explorer abfragen. Dort werden doppelte Einträge entfernt, indem die Lognamen, Zeitstempel und Felder für die Einfüge-ID verglichen werden.

Mit der Validierung auf Zeilenebene können Sie doppelte Logeinträge entfernen.

Weitere Informationen finden Sie unter Fehlerbehebung: In meinen Log Analytics-Ergebnissen sind doppelte Logeinträge enthalten.

Beschränkungen

Abfragen, die auf der Seite Log Analytics verwendet werden, unterstützen mit einigen Ausnahmen GoogleSQL-Funktionen.

Die folgenden SQL-Befehle werden für SQL-Abfragen nicht unterstützt, die über die Seite Log Analytics ausgeführt werden:

• DDL- und DML-Befehle
• Benutzerdefinierte JavaScript-Funktionen
• BigQuery ML-Funktionen
• SQL-Variablen

Die folgenden Funktionen werden nur unterstützt, wenn Sie ein verknüpftes Dataset über die Seiten BigQuery Studio und Looker Studio und das bq-Befehlszeilentool abfragen:

• Benutzerdefinierte JavaScript-Funktionen
• BigQuery ML-Funktionen
• SQL-Variablen

Nächste Schritte

Informationen zum Weiterleiten und Speichern von Logeinträgen finden Sie in den folgenden Dokumenten:

• Log-Bucket erstellen
• Bucket für die Verwendung von Log Analytics upgraden
• Log-Bucket mit einem BigQuery-Dataset verknüpfen
• Senken konfigurieren und verwalten

Die SQL-Referenzdokumentation finden Sie in den folgenden Dokumenten:

• Funktionen, Operatoren und Bedingungen
• Suchfunktionen
• Abfragesyntax