Exemples de requêtes SQL

Vous pouvez utiliser des exemples de requêtes SQL dans l'Analyse de l'observabilité pour analyser les entrées de journal, extraire les champs de charge utile et agréger les données de journal de vos services. Vous exécutez ces requêtes à partir de la page Analyse de l'observabilité de la console Google Cloud sur les buckets de journaux mis à niveau pour utiliser l'Analyse de l'observabilité. Pour obtenir d'autres exemples, consultez les dépôts GitHub logging-analytics-samples et security-analytics. Pour en savoir plus sur la syntaxe SQL ou sur l'acheminement et le stockage des entrées de journal, consultez la section Étapes suivantes.

Compatibilité avec le langage SQL

Les requêtes utilisées sur la page Analyse de l'observabilité sont compatibles avec les fonctions GoogleSQL, à quelques exceptions près.

Les commandes SQL suivantes ne sont pas compatibles avec les requêtes SQL émises à l'aide de la page Analyse de l'observabilité :

• Commandes LDD et LMD
• Fonctions JavaScript définies par l'utilisateur
• Fonctions BigQuery ML
• Variables SQL

Les éléments suivants ne sont compatibles que lorsque vous interrogez un ensemble de données BigQuery associé à l'aide des pages BigQuery Studio et Looker Studio, ou à l'aide de l'outil de ligne de commande bq :

• Fonctions JavaScript définies par l'utilisateur
• Fonctions BigQuery ML
• Variables SQL

Bonnes pratiques

Pour définir la période de votre requête, nous vous recommandons d'utiliser le sélecteur de période. Par exemple, pour afficher les données de la semaine passée, sélectionnez 7 derniers jours dans le sélecteur de période. Vous pouvez également utiliser le sélecteur de période pour spécifier une heure de début et de fin, spécifier une heure à afficher et modifier les fuseaux horaires.

Si vous incluez un champ timestamp dans la clause WHERE, le paramètre du sélecteur de période n'est pas utilisé. L'exemple suivant montre comment filtrer par code temporel :

-- Matches log entries whose timestamp is within the most recent 1 hour.
WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

Pour en savoir plus sur le filtrage par heure, consultez Fonctions d'heure et Fonctions de code temporel.

Avant de commencer

Cette section décrit les étapes à suivre avant de pouvoir utiliser l'analyse de l'observabilité.

Configurer des buckets de journaux

Assurez-vous que vos buckets de journaux ont été mis à niveau pour utiliser l'Analyse de l'observabilité :

1. Dans la console Google Cloud , accédez à la page Stockage des journaux :

   Accéder à la page Stockage des journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Pour chaque bucket de journaux contenant une vue de journaux que vous souhaitez interroger, assurez-vous que la colonne Analyse de l'observabilité disponible affiche Ouvrir. Si l'option Mettre à niveau s'affiche, cliquez dessus et suivez les instructions de la boîte de dialogue.

Configurer les rôles et les autorisations IAM

Cette section décrit les rôles ou les autorisations IAM requis pour utiliser l'analyse de l'observabilité :

• Pour obtenir les autorisations nécessaires pour utiliser l'analyse de l'observabilité et interroger les vues de journaux, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

  • Pour interroger les buckets de journaux _Required et _Default : Visionneuse de journaux (roles/logging.viewer)
  • Pour interroger toutes les vues de journaux d'un projet : Accesseur de vues de journaux (roles/logging.viewAccessor)

  Vous pouvez limiter l'accès d'un compte principal à une vue de journaux spécifique en ajoutant une condition IAM à l'attribution du rôle "Accesseur de vues de journaux" au niveau du projet, ou en ajoutant une liaison IAM au fichier de stratégie de la vue de journaux. Pour en savoir plus, consultez Contrôler l'accès à une vue de journal.

  Il s'agit des mêmes autorisations que celles dont vous avez besoin pour afficher les entrées de journal sur la page Explorateur de journaux. Pour en savoir plus sur les rôles supplémentaires dont vous avez besoin pour interroger des vues sur des buckets définis par l'utilisateur ou pour interroger la vue _AllLogs du bucket de journaux _Default, consultez Rôles Cloud Logging.

• Pour obtenir les autorisations nécessaires pour interroger des vues d'analyse, demandez à votre administrateur de vous accorder le rôle IAM Utilisateur de l'analyse de l'observabilité (roles/observability.analyticsUser) sur votre projet.

Utiliser les requêtes de cette page

1. Dans la console Google Cloud , accédez à la page Analyse de l'observabilité :

   Accéder à Analyse de l'observabilité

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Dans le volet Requête, cliquez sur  SQL, puis copiez et collez une requête dans le volet de requête SQL.

   Avant de copier une requête, dans la clause FROM, remplacez les champs suivants :

   • PROJECT_ID : identifiant du projet.
   • LOCATION : emplacement de la vue de journaux ou de la vue d'analyse.
   • BUCKET_ID : nom ou ID du bucket de journaux.
   • LOG_VIEW_ID : identifiant de la vue de journal, limité à 100 caractères et ne pouvant inclure que des lettres, des chiffres, des traits de soulignement et des traits d'union.

   Voici le format de la clause FROM pour une vue de journal :

   FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`

   Les exemples de journaux de cette page interrogent une vue de journal. Pour interroger une vue d'analyse, utilisez le format de chemin d'accès suivant : `analytics_view.PROJECT_ID.LOCATION.ANALYTICS_VIEW_ID`. Dans l'expression précédente, PROJECT_ID est l'ID de votre projet, et LOCATION et ANALYTICS_VIEW_ID sont l'emplacement et le nom de votre vue d'analyse.

   Remarque : Les délimiteurs du chemin d'accès sont des points ((.)). Si un élément de chemin d'accès tel que le projet Google Cloud contient un point, assurez-vous que chaque champ de chemin d'accès est entouré d'accents graves simples, (`).

Pour utiliser les requêtes présentées dans ce document sur la page BigQuery Studio ou pour utiliser l'outil de ligne de commande bq, modifiez la clause FROM et saisissez le chemin d'accès à l'ensemble de données BigQuery associé. Par exemple, pour interroger la vue _AllLogs sur l'ensemble de données BigQuery associé nommé mydataset qui se trouve dans le projet myproject, le chemin d'accès est myproject.mydataset._AllLogs.

Cas d'utilisation courants

Cette section répertorie plusieurs cas d'utilisation courants qui peuvent vous aider à créer vos requêtes personnalisées.

Afficher les entrées de journal dans le bucket de journaux par défaut

Pour interroger le bucket _Default, exécutez la requête suivante :

SELECT
  timestamp, severity, resource.type, log_name, text_payload, proto_payload, json_payload
FROM
  `PROJECT_ID.LOCATION._Default._AllLogs`
-- Limit to 1000 entries
LIMIT 1000

Extraire la valeur du champ par expression régulière

Pour extraire une valeur d'une chaîne à l'aide d'une expression régulière, utilisez la fonction REGEXP_EXTRACT :

SELECT
  -- Display the timestamp, and the part of the name that begins with test.
  timestamp, REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  -- Get the value of jobName, which is a subfield in a JSON structure.
  JSON_VALUE(json_payload.jobName) IS NOT NULL
ORDER BY timestamp DESC
LIMIT 20

Pour en savoir plus, reportez-vous à la documentation REGEXP_EXTRACT.

Pour les correspondances de sous-chaînes, comme la requête précédente, l'utilisation de la fonction CONTAINS_SUBSTR permet d'obtenir une requête plus efficace.

Filtrer les entrées de journal

Pour appliquer un filtre à votre requête, ajoutez une clause WHERE. La syntaxe que vous utilisez dans cette clause dépend du type de données du champ. Cette section fournit plusieurs exemples pour différents types de données.

Filtrer les entrées de journal par type de charge utile

Les entrées de journal peuvent avoir l'un des trois types de charge utile suivants. Pour filtrer les entrées de journal par type de charge utile, utilisez l'une des clauses suivantes :

• Charges utiles textuelles

  -- Matches log entries that have a text payload.
  WHERE text_payload IS NOT NULL
  

• Charges utiles JSON

  -- Matches log entries that have a JSON payload.
  WHERE json_payload IS NOT NULL
  

• Charges utiles proto

  -- Matches log entries that have a proto payload.
  -- Because proto_payload has a data type of RECORD, this statement tests
  -- whether a mandatory subfield exists.
  WHERE proto_payload.type IS NOT NULL
  

Dans les résultats de la requête, les champs json_payload et proto_payload sont affichés au format JSON, que vous pouvez parcourir.

Filtrer les données de journal par code temporel

Pour filtrer les entrées de journal en fonction de leur code temporel, nous vous recommandons d'utiliser le sélecteur de période. Toutefois, vous pouvez également spécifier timestamp dans la clause WHERE :

-- Matches log entries whose timestamp is within the most recent hour
WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

Pour en savoir plus sur le filtrage par heure, consultez Fonctions d'heure et Fonctions de code temporel.

Remarque : Si vous incluez un champ timestamp dans la clause WHERE, le paramètre du sélecteur de période n'est pas utilisé.

Filtrer par ressource

Pour filtrer vos données de journal par ressource, ajoutez une instruction resource.type à la clause WHERE :

-- Matches log entries whose resource type is gce_instance
WHERE resource.type = "gce_instance"

Filtrer par gravité

Pour filtrer les données de vos journaux par niveau de gravité, ajoutez une instruction severity à la clause WHERE :

-- Matches log entries whose severity is INFO or ERROR
WHERE severity IS NOT NULL AND severity IN ('INFO', 'ERROR')

Vous pouvez également filtrer vos entrées de journal par severity_number, qui est un entier. Par exemple, la clause suivante correspond à toutes les entrées de journal dont le niveau de gravité est au moins NOTICE :

-- Matches log entries whose severity level is at least NOTICE
WHERE severity_number IS NOT NULL AND severity_number > 200

Pour en savoir plus sur les valeurs énumérées, consultez LogSeverity.

Filtrer par nom de journal

Pour filtrer vos données de journal par nom de journal, ajoutez une instruction log_name ou log_id à la clause WHERE :

• Le nom du journal spécifie le chemin d'accès à la ressource :

  -- Matches log entries that have the following log ID.
  WHERE log_name="projects/cloud-logs-test-project/logs/cloudaudit.googleapis.com%2Factivity"
  

• L'ID de journal omet le chemin d'accès à la ressource :

  -- Matches log entries that have the following log id.
  WHERE log_id = "cloudaudit.googleapis.com/data_access"
  

Filtrer les entrées de journal par étiquette de ressource

Les libellés de ressources sont stockés sous forme de structure JSON. Pour filtrer les résultats selon la valeur d'un champ dans une structure JSON, utilisez la fonction JSON_VALUE :

SELECT
  timestamp, JSON_VALUE(resource.labels.zone) AS zone, json_payload, resource, labels
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  -- Matches log entries whose resource type is gce_instance and whose zone is
  -- us-central1-f. Because resource has data type JSON, you must use JSON_VALUE
  -- to get the value for subfields, like zone.
  resource.type = "gce_instance" AND
  JSON_VALUE(resource.labels.zone) = "us-central1-f"
ORDER BY timestamp ASC

La requête précédente repose sur le format des libellés de ressources, car ils sont stockés dans une entrée de journal. Voici un exemple de champ de ressource :

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

Pour en savoir plus sur toutes les fonctions permettant de récupérer et de transformer des données JSON, consultez Fonctions JSON.

Filtrer par requête HTTP

Pour n'interroger que les entrées de journal comportant un champ de requête HTTP, utilisez la clause suivante :

-- Matches log entries that have a HTTP request_method field.
-- Don't compare http_request to NULL. This field has a data type of RECORD.
WHERE http_request.request_method IS NOT NULL

Vous pouvez également utiliser l'instruction IN :

-- Matches log entries whose HTTP request_method is GET or POST.
WHERE http_request.request_method IN ('GET', 'POST')

Filtrer par état HTTP

Pour n'interroger que les entrées de journal qui ont un état HTTP, utilisez la clause suivante :

-- Matches log entries that have an http_request.status field.
WHERE http_request.status IS NOT NULL

Filtrer par champ dans un type de données JSON

Pour n'interroger les entrées de journal que lorsque le sous-champ d'un champ avec un type de données JSON a une valeur spécifique, extrayez la valeur à l'aide de la fonction JSON_VALUE :

-- Compare the value of the status field to NULL.
WHERE JSON_VALUE(json_payload.status) IS NOT NULL

La clause précédente est légèrement différente de la clause suivante :

-- Compare the status field to NULL.
WHERE json_payload.status IS NOT NULL

La première clause vérifie si la valeur du champ "status" est NULL. La deuxième clause vérifie si le champ d'état existe. Supposons qu'une vue de journal contienne deux entrées de journal. Pour une entrée de journal, le champ json_payload se présente comme suit :

{
    status: {
        measureTime: "1661517845"
    }
}

Pour l'autre entrée de journal, le champ json_payload a une structure différente :

{
    @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"
}

La clause WHERE json_payload.status IS NOT NULL correspond aux deux entrées de journal. Cependant, la clause WHERE JSON_VALUE(json_payload.status) IS NOT NULL ne correspond qu'à la deuxième entrée de journal.

Regrouper et agréger des entrées de journal

Cette section s'appuie sur les exemples précédents et illustre comment regrouper et agréger des entrées de journal. Si vous ne spécifiez pas de regroupement, mais que vous spécifiez une agrégation, un seul résultat est affiché, car SQL traite toutes les lignes qui répondent à la clause WHERE comme un seul groupe.

Chaque expression SELECT doit être incluse dans les champs de groupe ou être agrégée.

Regrouper les entrées de journal par code temporel

Pour regrouper les données par code temporel, utilisez la fonction TIMESTAMP_TRUNC, qui tronque un code temporel selon une précision spécifiée, par exemple HOUR :

SELECT
  -- Truncate the timestamp by hour.
  TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
  JSON_VALUE(json_payload.status) AS status,
  -- Count the number log entries in each group.
  COUNT(*) AS count
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  -- Matches log entries that have a status field whose value isn't NULL.
  json_payload IS NOT NULL AND JSON_VALUE(json_payload.status) IS NOT NULL
GROUP BY
  -- Group by hour and status
  hour,status
ORDER BY hour ASC

Pour en savoir plus, consultez la documentation sur TIMESTAMP_TRUNC et les fonctions de date et d'heure.

Regrouper les entrées de journal par ressource

La requête suivante montre comment regrouper les entrées de journal par type de ressource, puis compter le nombre d'entrées de journal dans chaque groupe :

SELECT
   -- Count the number of log entries for each resource type
   resource.type, COUNT(*) AS count
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
GROUP BY resource.type
LIMIT 100

Regrouper les entrées de journal par gravité

La requête suivante montre comment regrouper les entrées de journal par gravité, puis compter le nombre d'entrées de journal dans chaque groupe :

SELECT
  -- Count the number of log entries for each severity.
  severity, COUNT(*) AS count
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  severity IS NOT NULL
GROUP BY severity
ORDER BY severity
LIMIT 100

Regrouper les entrées de journal par log_id

La requête suivante montre comment regrouper les entrées de journal par ID de journal, puis compter le nombre d'entrées de journal dans chaque groupe :

SELECT
  -- Count the number of log entries for each log ID.
  log_id, COUNT(*) AS count
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
GROUP BY log_id
ORDER BY count DESC
LIMIT 100

Calculer la latence moyenne des requêtes HTTP par URL

La requête suivante montre comment regrouper les entrées de journal par URL et emplacement de la requête HTTP, puis compter le nombre d'entrées de journal dans chaque groupe :

SELECT
  -- Compute the average latency for each group. Because the labels field has a
  -- data type of JSON, use JSON_VALUE to get the value of checker_location.
  JSON_VALUE(labels.checker_location) AS location,
  AVG(http_request.latency.seconds) AS secs, http_request.request_url
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  -- Matches log entries when the request_method field is GET.
  http_request IS NOT NULL AND http_request.request_method IN ('GET')
GROUP BY
  -- Group by request URL and location
  http_request.request_url, location
ORDER BY location
LIMIT 100

Calculer le nombre moyen d'octets envoyés pour un test de sous-réseau

La requête suivante montre comment regrouper les entrées de journal par emplacement spécifié dans les étiquettes de ressource, puis calculer le nombre d'entrées de journal dans chaque groupe :

SELECT
  -- Compute the average number of bytes sent per location. Because labels has
  -- a data type of JSON, use JSON_VALUE to get the value of the location field.
  -- bytes_sent is a string. Must cast to a FLOAT64 before computing average.
  JSON_VALUE(resource.labels.location) AS location,
  AVG(CAST(JSON_VALUE(json_payload.bytes_sent) AS FLOAT64)) AS bytes
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  resource.type = "gce_subnetwork" AND json_payload IS NOT NULL
GROUP BY
  -- Group by location
  location
LIMIT 100

Pour en savoir plus, consultez Fonctions JSON et Fonctions de conversion.

Compter les entrées de journal dont un champ correspond à un modèle

Pour renvoyer la sous-chaîne correspondant à une expression régulière, utilisez la fonction REGEXP_EXTRACT :

SELECT
  -- Extract the value that begins with test.
  -- Count the number of log entries for each name.
  REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
  COUNT(*) AS count
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  json_payload.jobName IS NOT NULL
GROUP BY name
ORDER BY count
LIMIT 20

Pour obtenir d'autres exemples, consultez la documentation sur REGEXP_EXTRACT.

Recherche entre colonnes

Cette section décrit deux approches que vous pouvez utiliser pour rechercher plusieurs colonnes de la vue que vous interrogez :

• Recherches basées sur des jetons : vous spécifiez l'emplacement de recherche, une requête de recherche, puis vous utilisez la fonction SEARCH. Étant donné que la fonction SEARCH comporte des règles spécifiques sur la façon dont les données sont recherchées, nous vous recommandons de lire la documentation sur SEARCH.

• Recherches basées sur des sous-chaînes : vous fournissez l'emplacement de recherche, une chaîne littérale, puis vous utilisez la fonction CONTAINS_SUBSTR. Le système effectue un test non sensible à la casse pour déterminer si la chaîne littérale existe dans une expression. La fonction CONTAINS_SUBSTR renvoie TRUE lorsque la chaîne littérale existe, et FALSE dans le cas contraire. La valeur de recherche doit être un littéral STRING, mais pas le littéral NULL.

Recherche basée sur des jetons dans une vue de journaux

La requête suivante ne conserve que les lignes dont un champ correspond exactement à "35.193.12.15" :

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID` AS t
WHERE
  -- Search data access audit logs for the IP address that matches 35.193.12.15.
  -- The use of backticks prevents the string from being tokenized.
  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

Lorsque les accents graves sont omis dans la chaîne de requête, celle-ci est divisée en fonction des règles définies dans la documentation SEARCH. Par exemple, lorsque l'instruction suivante est exécutée, la chaîne de requête est divisée en quatre jetons : "35", "193", "12" et "15" :

  SEARCH(t,"35.193.12.15")

L'instruction SEARCH précédente correspond à une ligne lorsqu'un seul champ correspond aux quatre jetons. L'ordre des jetons n'a pas d'importance.

Vous pouvez inclure plusieurs instructions SEARCH dans une requête. Par exemple, dans la requête précédente, vous pouvez remplacer le filtre sur l'ID de journal par une instruction semblable à celle-ci :

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

L'instruction précédente recherche dans tous les champs des entrées de journal de la vue de journal, tandis que l'instruction d'origine ne recherche que le champ log_id des entrées de journal.

Pour effectuer plusieurs recherches sur plusieurs champs, séparez les différentes chaînes par un espace. Par exemple, l'instruction suivante correspond aux lignes où un champ contient "Hello World", "happy" et "days" :

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

Enfin, vous pouvez effectuer une recherche dans des champs spécifiques au lieu de rechercher dans une table entière. Par exemple, l'instruction suivante ne recherche que les colonnes nommées text_payload et json_payload :

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

Pour en savoir plus sur le traitement des paramètres de la fonction SEARCH, consultez la page de référence BigQuery Fonctions de recherche.

Recherche de sous-chaîne dans une vue de journal

Par exemple, la requête suivante extrait toutes les entrées de journal d'audit des accès aux données avec une adresse IP spécifique dont les codes temporels se situent dans une période spécifique. Enfin, la requête trie les résultats, puis affiche les 20 résultats les plus anciens :

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID` AS t
WHERE
  -- Search data access audit logs for the IP address that matches 35.193.12.15.
  -- CONTAINS_SUBSTR performs a contains-test.
  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

Interroger plusieurs vues

Les instructions de requête analysent une ou plusieurs tables ou expressions, et renvoient des lignes de calculs de résultats. Par exemple, vous pouvez utiliser des instructions de requête pour fusionner de différentes manières les résultats des instructions SELECT sur différentes tables ou ensembles de données, puis sélectionner les colonnes à partir des données combinées.

Les restrictions suivantes s'appliquent à la jointure de vues :

1. Les emplacements des vues répondent à l'une des conditions suivantes :

   • Toutes les vues ont le même emplacement.
   • Toutes les vues se trouvent dans l'emplacement global ou us.

2. Lorsque les ressources de stockage utilisent des clés de chiffrement gérées par le client (CMEK), l'une des conditions suivantes est remplie :

   • Les ressources de stockage qui utilisent des CMEK utilisent la même clé Cloud KMS.
   • Les ressources de stockage qui utilisent des CMEK ont un ancêtre commun, et cet ancêtre spécifie une clé Cloud KMS par défaut qui se trouve au même emplacement que les ressources de stockage.

   Lorsqu'une ou plusieurs ressources de stockage utilisent des CMEK, le système chiffre les données temporaires générées par la jointure avec la clé Cloud KMS commune ou la clé Cloud KMS par défaut de l'ancêtre.

Par exemple, supposons que vous disposiez de deux vues situées au même emplacement. Vous pouvez ensuite joindre ces vues si l'une des conditions suivantes est remplie :

• Les ressources de stockage n'utilisent pas de CMEK.
• Une ressource de stockage utilise des CMEK, mais pas l'autre.
• Les deux ressources de stockage utilisent des CMEK et la même clé Cloud KMS.

• Les deux ressources de stockage utilisent des CMEK, mais elles utilisent des clés différentes. Toutefois, les ressources partagent un ancêtre qui spécifie une clé Cloud KMS par défaut située au même emplacement que les ressources de stockage.

  Par exemple, supposons que la hiérarchie des ressources d'un bucket de journaux et d'un bucket d'observabilité inclut la même organisation. Vous pouvez joindre des vues sur ces buckets lorsque, pour cette organisation, vous avez configuré les paramètres de ressource par défaut pour Cloud Logging et pour les buckets d'observabilité avec la même clé Cloud KMS par défaut pour l'emplacement de stockage.

Joindre deux vues de journaux par l'ID de trace

Pour combiner les informations de deux tables, utilisez l'un des opérateurs de jointure :

SELECT
  -- Do an inner join on two tables by using the span ID and trace ID.
  -- Don't join only by span ID, as this field isn't globally unique.
  -- From the first view, show the timestamp, severity, and JSON payload.
  -- From the second view, show the JSON payload.
  a.timestamp, a.severity, a.json_payload, b.json_payload, a.span_id, a.trace
FROM  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1` a
JOIN  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_2` b
ON
  a.span_id = b.span_id AND
  a.trace = b.trace
LIMIT 100

Interroger deux vues de journaux avec une instruction UNION

Pour combiner les résultats d'au moins deux instructions SELECT et supprimer les lignes en double, utilisez l'opérateur UNION. Pour conserver les lignes en double, utilisez l'opérateur UNION ALL :

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
-- Create a union of two log views
FROM(
  SELECT * FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_1`
  UNION ALL
  SELECT * FROM `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_2`
)
-- Sort the union by timestamp.
ORDER BY timestamp ASC
LIMIT 100

Supprimer les entrées de journal en double

L'analyse de l'observabilité ne supprime pas les entrées de journal en double avant l'exécution d'une requête. Ce comportement est différent de celui que vous obtenez lorsque vous interrogez des entrées de journal à l'aide de l'explorateur de journaux, qui supprime les entrées en double en comparant les noms de journaux, les codes temporels et les champs d'ID d'insertion.

Vous pouvez utiliser la validation au niveau des lignes pour supprimer les entrées de journal en double.

Remarque : Les requêtes qui effectuent une validation au niveau des lignes sont plus lentes que celles qui n'en effectuent pas. Ne dédupliquez pas les entrées de journal, sauf si la requête est sensible aux entrées de journal en double ou si le résultat de la requête ne doit pas contenir d'entrées en double.

Pour en savoir plus, consultez Dépannage : il y a des entrées de journal en double dans mes résultats d'Analyse de l'observabilité.

Étapes suivantes

Pour en savoir plus sur l'acheminement et le stockage des entrées de journal, consultez les documents suivants :

• Créer un bucket de journaux
• Mettre à niveau un bucket pour utiliser Analyse de l'observabilité
• Associer un bucket de journaux à un ensemble de données BigQuery
• Configurer et gérer les récepteurs

Pour obtenir la documentation de référence sur SQL, consultez les documents suivants :

• Fonctions, opérateurs et expressions conditionnelles
• Fonctions de recherche
• Syntaxe des requêtes