Ce document décrit les vues d'analyse et les cas où vous pouvez les créer. Il décrit également les différences entre les vues d'analyse et les concepts que vous connaissez peut-être, comme les vues de journaux et les requêtes enregistrées.
Pour savoir comment créer, interroger et gérer vos vues analytiques, consultez la section Créer et interroger des vues analytiques.
Présentation
Une vue d'analyse est une ressource sur laquelle vous pouvez lancer des requêtes. Cette ressource contient une requête SQL qui interroge une ou plusieurs vues de journaux.
Une vue de journaux sur un bucket de journaux contrôle les entrées de journal du bucket de journaux que vous pouvez voir. Vous pouvez interroger la vue des journaux à l'aide de l'explorateur de journaux et des pages Log Analytics. Dans les deux cas, le format des données interrogées est déterminé par la structure de données LogEntry
.
La requête SQL contenue dans une vue d'analyse vous permet de transformer les données de journal dans une ou plusieurs vues de journal en un format personnalisé. Autrement dit, vous pouvez filtrer les entrées de journal dans la vue des journaux qui contribuent au résultat de la requête, et vous pouvez définir les colonnes du résultat. Par exemple, vous pouvez supprimer des colonnes, déplacer des données d'un champ JSON imbriqué vers une colonne ou ajouter des colonnes.
Les vues Analytics 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 est équivalent à interroger les vues de journaux que la vue d'analyse interroge.
Une vue d'analyse et une requête enregistrée contiennent toutes deux une requête SQL. Toutefois, une vue d'analyse est une ressource sur laquelle vous pouvez lancer une requête. Vous pouvez réexécuter une requête enregistrée, mais vous ne pouvez pas interroger le résultat d'une requête enregistrée.
Types de vues Analytics
Il existe deux types de vues Analytics: les vues définies par l'utilisateur et les vues définies par le système:
Les vues analytiques définies par l'utilisateur sont toutes les vues analytiques que vous créez. Vous pouvez interroger, modifier et supprimer des vues analytiques définies par l'utilisateur.
Les vues d'analyse définies par le système sont des vues d'analyse créées par les servicesGoogle Cloud . Vous pouvez interroger des vues d'analyse définies par l'utilisateur. Vous ne pouvez toutefois pas les modifier ni les supprimer.
Pour savoir comment lister les vues d'analyse de votre projet Google Cloud, consultez Lister les vues d'analyse.
Emplacement des vues analytiques
L'emplacement d'une vue Analytics 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 console Google Cloud pour créer une vue d'analyse, l'emplacement est défini automatiquement.
Avantages des vues Analytics
L'avantage principal des vues d'analyse est que vous pouvez transformer vos données de journaux et créer un schéma cohérent pour d'autres requêtes. Toutefois, vous constaterez peut-être qu'en créant une vue d'analyse, vous pouvez réduire les efforts que vous consacrez à la rédaction de requêtes ou améliorer leur structure. Étant donné que les vues analytiques ne sont pas des vues matérialisées, leur utilisation ne réduit pas nécessairement le temps de requête.
Exemple: Transformation de données
Supposons que vous analysiez les performances du réseau à l'aide des journaux de flux VPC. Vous devez analyser les performances globales du réseau et être en mesure d'identifier des réseaux, des adresses IP ou des hôtes spécifiques.
Malheureusement, les informations dont vous avez besoin sont contenues dans des champs imbriqués dans le champ json_payload
d'une entrée de journal.
Pour extraire ces informations des entrées de journal, vous devez écrire la requête suivante, puis l'enregistrer en tant que vue d'analyse nommée network_details
:
SELECT
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 `TABLE_NAME_OF_LOG_VIEW`
WHERE
log_id = "compute.googleapis.com/vpc_flows"
AND SEARCH(json_payload.reporter, "SRC")
Lorsque vous souhaitez analyser les performances du réseau, vous pouvez désormais interroger votre vue Analytics. Par exemple, si vous ne vous intéressez qu'au 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
Exemple: Requête de base pour l'analyse de la latence de l'API
Supposons que vous deviez évaluer et résumer la latence des requêtes pour des intervalles d'une semaine. D'autres équipes utiliseront les données d'analyse des performances hebdomadaires comme base pour d'autres analyses.
La vue d'analyse que vous créez, qui peut être interrogée par d'autres équipes, indique la latence minimale, maximale et moyenne des requêtes terminées, telle qu'elle est enregistrée par les entrées de journal dans une vue de journal spécifique:
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 `TABLE_NAME_OF_LOG_VIEW`
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
Rôles et autorisations IAM requis
Étant donné que les vues d'analyse interrogent les vues de journaux, pour créer et interroger des vues d'analyse, vos rôles IAM doivent également vous permettre d'interroger les vues de journaux et d'utiliser Log Analytics. Cette section liste les rôles IAM requis pour créer des vues d'analyse, ainsi que ceux requis pour interroger les vues de journaux et utiliser Log Analytics:
-
Pour obtenir les autorisations nécessaires pour créer, gérer et utiliser des vues d'analyse, demandez à votre administrateur de vous accorder le rôle IAM Utilisateur d'analyse de l'observabilité (
roles/observability.analyticsUser
) sur votre projet.Ce rôle prédéfini contient les autorisations requises pour créer, gérer et utiliser des vues d'analyse. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :
Autorisations requises
Vous devez disposer des autorisations suivantes pour créer, gérer et utiliser des vues d'analyse:
-
observability.analyticsViews.get
-
observability.analyticsViews.list
-
observability.analyticsViews.create
-
observability.analyticsViews.update
-
observability.analyticsViews.delete
-
-
Pour obtenir les autorisations nécessaires pour interroger une vue des journaux et utiliser Log Analytics, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet:
-
Pour interroger les buckets de journaux
_Required
et_Default
: Lecteur 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 un principal à une vue de journaux spécifique en ajoutant une condition IAM à l'attribution du rôle "Accès aux vues de journaux" effectuée 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 la page Contrôler l'accès à une vue de journal.
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 la section Rôles Cloud Logging. -
Pour interroger les buckets de journaux
Limites
Les limites suivantes s'appliquent aux vues Analytics:
- Une vue d'analyse ne peut pas interroger une autre vue d'analyse.
- Une vue d'analyse peut interroger plusieurs vues de journaux. Toutefois, les buckets de journaux qui hébergent les vues de journaux interrogées doivent se trouver au même endroit. Par exemple, imaginons que vous disposiez de deux buckets de journaux, l'un dans
us-east1
et l'autre dansasia-east1
. Vous ne pouvez pas créer de vue d'analyse qui interroge les vues de journaux sur ces buckets de journaux. - La ressource parente d'une vue d'analyse doit être un projet Google Cloud. Vous ne pouvez pas créer de vue Analytics dans des dossiers ni des organisations.
- Les ensembles de données associés ne sont pas compatibles avec les vues Analytics. Par conséquent, vous ne pouvez interroger les vues d'analyse que sur la page Analyse de journaux. Vous devez également exécuter ces requêtes sur le service Cloud Logging par défaut.
- Les API ne permettent pas de créer ni de gérer des vues d'analyse.
Les limites suivantes s'appliquent aux vues Analytics:
- Nombre maximal de vues Analytics par projet Google Cloud : 100
- Nombre maximal de vues Analytics par région et par projet Google Cloud : 50
- Nombre maximal de régions pouvant stocker des vues d'analyse par projet Google Cloud : 10
Étape suivante
- Créer et interroger des vues Analytics
- Présentation de l'interrogation et de l'analyse des journaux
- Enregistrer et partager une requête SQL