SQL-Beispielabfragen

Dieses Dokument enthält Beispielabfragen für Logeinträge, die in Log-Buckets gespeichert sind, für die ein Upgrade zur Verwendung von Loganalysen durchgeführt wurde. Für diese Buckets können Sie SQL-Abfragen auf der Seite Loganalysen in der Google Cloud Console ausführen. Weitere Beispiele finden Sie in den GitHub-Repositories logging-analytics-samples und security-analytics.

In diesem Dokument wird nicht beschrieben, wie Sie SQL verwenden oder Logeinträge weiterleiten und speichern. Informationen zu diesen Themen finden Sie im Abschnitt Weitere Informationen.

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. Prüfen Sie für jeden Log-Bucket, der eine Logansicht enthält, die Sie abfragen möchten, ob in der Spalte Log Analytics verfügbar die Option Öffnen angezeigt wird. Wenn Upgrade durchführen angezeigt wird, klicken Sie darauf 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 Log-Ansichten benötigen:

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

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

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

• Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Observability Analytics User (roles/observability.analyticsUser) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Abfragen von Analyseansichten benötigen.

So verwenden Sie diese Abfragen

Wenn Sie die in diesem Dokument gezeigten Abfragen auf der Seite Loganalyse verwenden möchten, ersetzen Sie TABLE_NAME_OF_LOG_VIEW durch den Tabellennamen für die Logansicht oder Analyseansicht, die Sie abfragen möchten.

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

  FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
  

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

  FROM `analytics_view.PROJECT_ID.LOCATION.ANALYTICS_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 Logansicht oder der Analyseansicht.
• BUCKET_ID: Der Name oder die ID des Log-Buckets.
• LOG_VIEW_ID: Die Kennung der Logansicht. Sie ist auf 100 Zeichen begrenzt und darf nur Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten.
• ANALYTICS_VIEW_ID: Die ID der Analyseansicht, die auf 100 Zeichen begrenzt ist und nur Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten darf.

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 für das verknüpfte 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. Die Log- und Analyseansichten finden Sie im Bereich Ansichten.

   Log-Ansichten werden im Abschnitt segment Logs und Analytics-Ansichten im Abschnitt data_table Analytics Views aufgeführt.

3. Optional: Wenn Sie das Schema für eine Logansicht oder eine Analyseansicht ermitteln möchten, wählen Sie die Logansicht oder die Analyseansicht aus.

   Das Schema wird angezeigt. Mit dem Feld Filter können Sie nach bestimmten Feldern suchen. Das Schema kann nicht geändert werden.

Informationen zum Zugriff auf die Standardabfrage für ein Element, das im Bereich Ansichten aufgeführt ist, finden Sie unter Logs mit Loganalysen abfragen und analysieren.

Logs filtern

SQL-Abfragen legen fest, welche Einträge in der Logansicht verarbeitet werden sollen. Anschließend werden diese Einträge gruppiert und es werden Aggregatvorgänge 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, den Zeitraum für Ihre Abfrage über die Zeitraumauswahl festzulegen. Dieser Selektor wird automatisch verwendet, wenn in einer Abfrage kein timestamp-Feld in der WHERE-Klausel angegeben ist. Wenn Sie beispielsweise die Daten der letzten Woche aufrufen möchten, wählen Sie in der Zeitbereichsauswahl Letzte 7 Tage aus. Sie können auch die Zeitraumauswahl verwenden, um eine Start- und Endzeit festzulegen, einen Zeitpunkt anzugeben, um den herum die Ansicht zentriert werden soll, und die Zeitzone zu ändern.

Wenn Sie ein timestamp-Feld in die WHERE-Klausel einfügen, wird die Einstellung für die Zeitbereichsauswahl nicht verwendet. Im folgenden Beispiel werden die Daten mit der Funktion TIMESTAMP_SUB gefiltert. Damit können Sie ein Rückblickintervall ab dem aktuellen Zeitpunkt 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, dann werden die Zeilen beibehalten, deren Ressourcentyp mit gce_instance übereinstimmt, und schließlich werden bis zu 100 Einträge sortiert und 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 nach einem bestimmten Schweregrad filtern, indem Sie eine Einschränkung wie severity = 'ERROR' verwenden. Eine weitere Möglichkeit ist die Verwendung der IN-Anweisung, mit der Sie eine Reihe gültiger Werte angeben können.

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

In der vorherigen Abfrage wird nach dem Wert des Felds severity gefiltert. Sie können jedoch auch Abfragen schreiben, die nach dem numerischen Wert des Log-Schweregrads 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 Log-Namen 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. Dieses 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 dann 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 Deskriptor für eine Compute Engine-Instanz enthält beispielsweise Labels für die Zone, die Projekt-ID und die Instanz-ID. Wenn der Logeintrag geschrieben wird, 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 eine Einschränkung wie resource.labels.zone = "us-centra1-f" in einer Abfrage zu einem Syntaxfehler. Wenn Sie den Wert eines Felds mit dem Datentyp „JSON“ abrufen möchten, verwenden Sie die Funktion JSON_VALUE.

Mit der folgenden Abfrage werden beispielsweise die neuesten Daten gelesen und dann die Zeilen beibehalten, in 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 angezeigt werden, die einem HTTP-Request oder einer HTTP-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 sein 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

Wenn Sie den Typ der in einem Feld gespeicherten Daten ermitteln möchten, sehen Sie sich das Schema an oder lassen Sie das Feld anzeigen. Die Ergebnisse der vorherigen Abfrage zeigen, dass im Feld http_request.status Ganzzahlwerte gespeichert sind.

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

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

{
    status: {
        measureTime: "1661517845"
    }
}

Für den 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 lautet, wird nur der zweite Logeintrag in das Abfrageergebnis aufgenommen.

Nach regulärem Ausdruck 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 zuletzt empfangenen Logeinträge an, behält die Einträge mit dem Feld json_payload.jobName 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. Für einen Teilstring-Abgleich wie den oben gezeigten verwenden Sie die Funktion CONTAINS_SUBSTR.

Logeinträge gruppieren und zusammenfassen

In diesem Abschnitt wird auf den vorherigen Beispielen aufgebaut und veranschaulicht, wie Sie Logeinträge gruppieren und aggregieren können. Wenn Sie keine Gruppierung, aber eine Aggregation angeben, wird ein einzelnes Ergebnis ausgegeben, da in SQL alle Zeilen, die die WHERE-Klausel erfüllen, als eine einzelne Gruppe behandelt werden.

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

Nach Zeit gruppieren

Wenn Sie Daten nach Zeit gruppieren möchten, verwenden Sie die Funktion TIMESTAMP_TRUNC, mit der ein Zeitstempel auf eine bestimmte Granularität wie MINUTE gekürzt wird. 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.

Bei der folgenden Abfrage werden die Daten gelesen, die im vom Zeitraum-Picker angegebenen Intervall empfangen wurden. Anschließend werden die Zeilen beibehalten, in denen der Wert des Felds json_payload.status nicht NULL ist. In der Abfrage wird der Zeitstempel in jeder Zeile auf die Stunde gekürzt und die Zeilen werden dann nach dem gekürzten 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 zeitbasierten Funktionen finden Sie unter Datums- und Uhrzeitfunktionen.

Nach Ressource gruppieren

Mit der folgenden Abfrage werden die Daten der letzten Stunde gelesen und die Logeinträge dann nach Ressourcentyp gruppiert. Anschließend wird die Anzahl der Zeilen für jeden Ressourcentyp gezählt und eine Tabelle mit zwei Spalten zurückgegeben. In der ersten Spalte wird der Ressourcentyp aufgeführt, in der zweiten 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

Mit der folgenden Abfrage werden die Daten der letzten Stunde gelesen und dann Zeilen mit einem Feld „severity“ beibehalten. Die Abfrage gruppiert die Zeilen dann 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 Log-Namen und in der zweiten Spalte die Anzahl der Log-Einträge aufgeführt, die in das Log geschrieben wurden. Bei der Abfrage werden die Ergebnisse nach der Anzahl der Einträge sortiert:

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

Die folgende Abfrage veranschaulicht die Gruppierung nach mehreren Spalten und die Berechnung eines Durchschnittswerts. In der Abfrage werden Zeilen nach der URL im HTTP-Request und nach dem Wert des Felds labels.checker_location gruppiert. Nachdem die Zeilen gruppiert wurden, wird mit der Abfrage die durchschnittliche Latenz für jede Gruppe berechnet:

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 zweite Feld hat den Datentyp „Ganzzahl“.

Durchschnittliche Anzahl der gesendeten Byte für einen Subnetzwerktest berechnen

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

Bei der Abfrage werden die Daten der letzten Stunde gelesen und dann nur die Zeilen beibehalten, deren Spalte „resource type“ (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. Daher müssen Sie den Wert 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 in jeder Zeile ein Standort und die durchschnittliche Anzahl der für diesen Standort gesendeten Bytes aufgeführt sind.

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

Informationen zu CAST und anderen Konversionsfunktionen finden Sie unter Konversionsfunktionen.

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. Schließlich wird mit 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 Logansicht nach Einträgen suchen möchten, die einer Reihe von Suchbegriffen entsprechen, 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 in den Daten gelten, empfehlen wir Ihnen, die SEARCH-Dokumentation zu lesen.

In der folgenden Abfrage werden nur die Zeilen beibehalten, die ein Feld enthalten, das genau mit „35.193.12.15“ übereinstimmt:

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 werden die Backticks um den Wert gesetzt, nach dem gesucht werden soll. So wird sichergestellt, dass die Funktion SEARCH nach einer genauen Übereinstimmung zwischen einem Feldwert und dem Wert zwischen den Graviszeichen sucht.

Wenn im Abfragestring keine Backticks verwendet werden, wird er anhand der 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 stimmt mit einer Zeile überein, 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 beispielsweise den Filter für die Log-ID durch eine Anweisung wie die folgende ersetzen:

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

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

Wenn Sie mehrere Suchvorgänge für mehrere Felder ausführen möchten, trennen Sie die einzelnen Strings durch ein Leerzeichen. Die folgende Anweisung entspricht beispielsweise Zeilen, in denen ein Feld „Hello World“, „happy“ und „days“ enthält:

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

Schließlich können Sie auch in bestimmten Feldern suchen, anstatt eine ganze Tabelle zu durchsuchen. Mit der folgenden Anweisung werden beispielsweise nur die Spalten mit den Namen text_payload und json_payload durchsucht:

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

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

Nach Teilstrings suchen

Wenn Sie einen Test ohne Berücksichtigung der Groß-/Kleinschreibung durchführen möchten, um festzustellen, ob ein Wert in einem Ausdruck vorhanden ist, 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. Schließlich 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

Mit der vorherigen Abfrage wird ein Teilstring-Test durchgeführt. Eine Zeile, die „35.193.12.152“ enthält, entspricht also 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. Sie können beispielsweise Abfrageanweisungen verwenden, um die Ergebnisse von SELECT-Anweisungen für verschiedene Tabellen oder Datasets auf unterschiedliche Weise zusammenzuführen und dann die Spalten aus den kombinierten Daten auszuwählen.

Daten aus zwei Tabellen mit Joins kombinieren

Um Informationen aus zwei Tabellen zu kombinieren, verwenden Sie einen der Join-Operatoren. Der Typ des Joins und die verwendete Bedingungsklausel bestimmen, wie Zeilen kombiniert und verworfen werden.

Die folgende Abfrage gibt die Felder json_payload aus Zeilen in zwei verschiedenen Tabellen zurück, die vom selben Trace-Span geschrieben wurden. Die Abfrage führt einen inneren JOIN für zwei Tabellen für Zeilen aus, in denen die Werte der Spalten span_id und trace in beiden Tabellen übereinstimmen. Aus diesem Ergebnis wählt die Abfrage dann die Felder timestamp, severity und json_payload aus, die aus TABLE_NAME_OF_LOG_VIEW_1 stammen, das Feld json_payload aus TABLE_NAME_OF_LOG_VIEW_2 sowie die Werte der Felder span_id und trace aus, für die 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 mehr 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.

Mit 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 aufsteigendem 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 doppelte Logeinträge nicht entfernt, bevor eine Abfrage ausgeführt wird. Dieses Verhalten unterscheidet sich von dem, wenn Sie Logeinträge mit dem Log-Explorer abfragen. Dort werden doppelte Einträge entfernt, indem die Felder für Lognamen, Zeitstempel und 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 vorhanden.

Beschränkungen

Für Abfragen auf der Seite Log Analytics werden GoogleSQL-Funktionen mit einigen Ausnahmen unterstützt.

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

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

Die folgenden Elemente werden nur unterstützt, wenn Sie ein verknüpftes Dataset über die Seiten BigQuery Studio und Looker Studio sowie 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

SQL-Referenzdokumentation finden Sie in den folgenden Dokumenten:

• Funktionen, Operatoren und Bedingungen
• Suchfunktionen
• Abfragesyntax