À propos des vues analytiques

Aperçu

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres pré-DG" de la section "Conditions d'utilisation générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce document décrit les vues d'analyse et les cas dans lesquels vous pouvez être amené à les 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é), puis que vous enregistrez. 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 : définies par l'utilisateur et 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 des 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 des 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 située dans 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 illustre 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

Limites

Les limites suivantes s'appliquent aux vues d'analyse :

• Une vue d'analyse ne peut interroger que des vues de journal.
• La ressource parente d'une vue d'analyse doit être un Google Cloud projet.
• Vous ne pouvez interroger une vue d'analyse qu'à l'aide de la page Observability Analytics (Analyse de l'observabilité), et uniquement lorsque vous utilisez le moteur de requête Observability Analytics (default) (Analyse de l'observabilité (par défaut)).
• Toutes les vues interrogées par une vue d'analyse doivent se trouver au même emplacement.
• Vous devez utiliser la Google Cloud console pour créer ou gérer vos vues d'analyse.
• Vous pouvez créer au maximum 100 vues d'analyse par Google Cloud projet.
• Vous pouvez créer au maximum 50 vues d'analyse par région.
• Par Google Cloud projet, au maximum 10 régions peuvent contenir une vue d'analyse.

Étape suivante

• Créer, interroger et gérer des vues d'analyse
• Présentation de l'interrogation et de l'analyse des journaux
• Enregistrer et partager une requête SQL