Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

À propos des vues analytiques

Ce document décrit les vues d'analyse et les cas dans lesquels vous pouvez être amené à en créer. Il décrit également les différences entre les vues d'analyse et les requêtes enregistrées.

Présentation

Une vue d'analyse est une ressource que vous pouvez interroger. Autrement dit, une fois que vous avez défini une vue d'analyse, vous pouvez écrire des requêtes dans lesquelles vous spécifiez votre vue d'analyse dans la clause FROM.

L'avantage principal de l'utilisation des vues d'analyse est que vous n'êtes pas limité à l'interrogation des données au format défini par une API ou un système. Une vue d'analyse vous permet de définir un schéma, ce qui vous permet de simplifier vos requêtes ou de réduire le temps que vous passez à les écrire. La requête dans une vue d'analyse peut, par exemple, ne conserver que des champs spécifiques, renommer des champs, déplacer des champs imbriqués vers une colonne de premier niveau, et effectuer des regroupements et des agrégations.

Les vues d'analyse ne sont pas des vues matérialisées. Une vue d'analyse n'est pas une vue précalculée qui met régulièrement en cache les résultats des requêtes. Par conséquent, interroger une vue d'analyse revient à interroger les vues listées dans la requête de la vue d'analyse.

Les vues d'analyse sont plus puissantes que les requêtes enregistrées, qui sont des requêtes que vous exécutez sur la page Observability Analytics (Analyse de l'observabilité) et que vous enregistrez ensuite. Vous pouvez réexécuter une requête enregistrée, mais vous ne pouvez pas interroger ses résultats.

Types de vues d'analyse

Il existe deux types de vues d'analyse : celles définies par l'utilisateur et celles définies par le système :

Les vues d'analyse définies par l'utilisateur sont toutes les vues d'analyse que vous créez. Vous pouvez interroger, modifier et supprimer les vues d'analyse définies par l'utilisateur.
Les vues d'analyse définies par le système sont des vues d'analyse créées par Google Cloud des services. Vous pouvez interroger les vues d'analyse définies par le système. Toutefois, vous ne pouvez pas les modifier ni les supprimer.

Pour savoir comment lister les vues d'analyse de votre Google Cloud projet, consultez la page Lister les vues d'analyse.

Emplacement des vues d'analyse

L'emplacement d'une vue d'analyse est déterminé par l'emplacement des ressources qu'elle interroge. Par exemple, si une vue d'analyse interroge une vue de journal ou une vue d'observabilité qui se trouve à l'emplacement global, l'emplacement de la vue d'analyse doit également être global. Lorsque vous utilisez la Google Cloud console pour créer une vue d'analyse, l'emplacement est défini automatiquement.

Exemples de cas d'utilisation

L'avantage principal d'une vue d'analyse est que vous n'êtes pas limité à l'interrogation des données au format défini par le système. Une vue d'analyse vous permet de définir un schéma, ce qui vous permet de simplifier vos requêtes ou de réduire le temps que vous passez à les écrire.

Interroger les détails du réseau

Vous souhaitez analyser les performances du réseau à l'aide des journaux de flux VPC. Vous devez analyser les performances globales du réseau, ainsi qu'identifier des réseaux, des adresses IP et des hôtes spécifiques. Ces informations sont stockées dans des champs imbriqués du champ json_payload d'une entrée de journal.

Pour simplifier vos requêtes d'analyse, créez la vue d'analyse suivante et nommez-la network_details :

SELECT
  -- Create a column for each network field.
  JSON_VALUE(resource.labels.subnetwork_name) subnetwork_name,
  JSON_VALUE(json_payload.src_instance.vm_name) vm_name,
  JSON_VALUE(json_payload.connection.src_ip) as src_ip,
  JSON_VALUE(json_payload.connection.src_port) as src_port,
  JSON_VALUE(json_payload.connection.dest_ip) as dest_ip,
  JSON_VALUE(json_payload.connection.dest_port) as dest_port,
  CAST(JSON_VALUE(json_payload.bytes_sent) as INT64) as bytes_sent,
  CAST(JSON_VALUE(json_payload.packets_sent) as INT64) as packets_sent
FROM
  -- Query one log view.
  `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
WHERE
  -- Only query the VPC Flow Logs log.
  log_id = "compute.googleapis.com/vpc_flows"
  AND SEARCH(json_payload.reporter, "SRC")

Avant d'utiliser la requête, définissez les valeurs des variables suivantes :

PROJECT_ID : identifiant du projet.
LOCATION : emplacement de la vue de journal.
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.

Lorsque vous souhaitez analyser les performances du réseau, interrogez votre vue d'analyse. Par exemple, si vous n'êtes intéressé que par le nom de l'instance et la quantité de données envoyées, vous pouvez écrire la requête suivante :

SELECT vm_name, bytes_sent, packets_sent,
FROM `analytics_view.my_project.global.network_details`
ORDER BY bytes_sent DESC
LIMIT 100

Requête de base pour l'analyse de la latence de l'API

Plusieurs équipes ont besoin de données de performances hebdomadaires pour effectuer leur analyse. Au lieu que chaque équipe génère les données hebdomadaires, vous créez une vue d'analyse qui extrait ces données. Les autres équipes peuvent interroger la vue d'analyse, puis effectuer leur analyse.

La requête suivante montre comment utiliser SQL pour calculer la latence minimale, maximale et moyenne des requêtes :

SELECT week, MIN(took_ms) as min, MAX(took_ms) AS max, AVG(took_ms) AS avg
FROM (
  SELECT TIMESTAMP_TRUNC(timestamp, WEEK) AS week,
  CAST( JSON_VALUE(json_payload, '$."http.resp.took_ms"') AS INT64) as took_ms
  FROM
    -- Query one log view.
    `PROJECT_ID.LOCATION.BUCKET_ID.LOG_VIEW_ID`
  WHERE json_payload IS NOT NULL
    AND SEARCH(labels,"frontend")
    AND JSON_VALUE(json_payload.message) = "request complete"
  ORDER BY took_ms DESC, timestamp ASC
)
GROUP BY week ORDER BY week

Extraire le nom du service de trace

Supposons que vous souhaitiez écrire des requêtes qui analysent vos données de trace et que vous souhaitiez afficher ou regrouper les données par nom de service synthétisé. La requête de votre vue d'analyse détermine le nom du service pour un segment à l'aide de la fonction COALESCE, qui évalue une liste d'expressions, dans l'ordre, et renvoie la valeur de la première expression qui n'est pas évaluée sur NULL :

SELECT
  start_time,
  -- Set the value of service name based on the first non-null value in the list.
  COALESCE(
    JSON_VALUE(resource.attributes, '$."service.name"'),
    JSON_VALUE(attributes, '$."service.name"'),
    JSON_VALUE(attributes, '$."g.co/gae/app/module"')) AS service_name,
  name AS span_name,
  duration_nano,
  status.code AS status,
  trace_id,
  span_id
FROM
  `PROJECT_ID.us._Trace.Spans._AllSpans`
LIMIT 10

Avant d'utiliser la requête, remplacez PROJECT_ID par l'ID de votre Google Cloud projet.

Joindre les données de trace et de journal à l'aide de l'ID de trace

Lorsque vous analysez une application, vous pouvez corréler vos données de journal et de trace. Vous pouvez par exemple créer une vue d'analyse qui effectue la jointure et génère des rapports sur les champs sélectionnés.

La requête suivante joint les données de journal et de trace à l'aide des ID d'étendue et de trace :

SELECT
  T.trace_id,
  T.span_id,
  T.name,
  T.start_time,
  T.duration_nano,
  L.log_name,
  L.severity,
  L.json_payload,
  L.text_payload,
  L.proto_payload,
  L.insert_id
FROM
  `PROJECT_ID.us._Trace.Spans._AllSpans` AS T
JOIN
  `PROJECT_ID.us.BUCKET_ID.LOG_VIEW_ID` AS L
ON
  -- Join log and trace data by both the span ID and trace ID.
  -- Don't join only on span ID, this field isn't globally unique.
  T.span_id = L.span_id
  -- A regular expression is required because the storage format of the trace ID
  -- differs between a log view and a trace view.
  AND T.trace_id = REGEXP_EXTRACT(L.trace, r'/([^/]+)$')