Cette page explique comment utiliser le tableau de bord de Query Insights pour détecter et analyser les problèmes de performances.
Vous pouvez bénéficier de l'assistance de Gemini dans les bases de données pour vous aider à observer et à résoudre les problèmes liés à vos ressources Cloud SQL pour PostgreSQL. Pour en savoir plus, consultez la page Observer et résoudre les problèmes avec l'aide de Gemini.Présentation
Insights sur les requêtes vous aide à détecter, à diagnostiquer et à empêcher les problèmes de performances des requêtes pour les bases de données Cloud SQL. Il offre un système de surveillance intuitif et fournit des informations de diagnostic qui vous aident à identifier la principale cause des problèmes de performances.
Avec Insights sur les requêtes, vous pouvez surveiller les performances au niveau de l'application et tracer la source d'une requête problématique sur la pile d'applications par modèle, vue, contrôleur, route, utilisateur et hôte. L'outil Insights sur les requêtes peut s'intégrer aux outils de surveillance d'application (APM) et aux services Google Cloud existants à l'aide de normes et d'API ouvertes. De cette façon, vous pouvez surveiller et résoudre les problèmes de requête à l'aide de votre outil préféré.
Insights sur les requêtes vous aide à améliorer les performances des requêtes Cloud SQL en suivant les étapes ci-dessous :
- Affichez la charge de la base de données pour les requêtes populaires
- Identifiez une requête ou un tag potentiellement problématique
- Examinez la requête ou le tag pour identifier les problèmes
- Tracez la source du problème.
Insights sur les requêtes est compatible avec tous les types de machines Cloud SQL et disponible dans toutes les régions Google Cloud.
Tarifs
Insights sur les requêtes n'entraîne aucun coût supplémentaire. Vous pouvez accéder à une semaine de données dans le tableau de bord de Insights sur les requêtes.
Insights sur les requêtes n'occupe pas d'espace de stockage dans votre espace de stockage d'instances Cloud SQL. Les métriques sont stockées dans Cloud Monitoring. Pour les requêtes API, consultez la page Tarifs de Cloud Monitoring. Cloud Monitoring dispose d'un niveau que vous pouvez utiliser sans frais supplémentaires.
Avant de commencer
Pour afficher un plan de requête ou effectuer un traçage de bout en bout, vous devez disposer d'autorisations IAM spécifiques. Créez un rôle personnalisé et ajoutez-y l'autorisation IAM cloudtrace.traces.get
. Ajoutez ensuite ce rôle à chaque compte utilisateur devant utiliser Query Insights.
Pour afficher les plans de requête et leurs vues de bout en bout, l'API Trace doit être activée pour votre projet Google Cloud. Ce paramètre permet à votre projet Google Cloud de recevoir des données de trace provenant de sources authentifiées, sans frais supplémentaires. Ces données peuvent vous aider à détecter et à diagnostiquer les problèmes de performances sur votre instance.
Pour vérifier que l'API Trace est activée, procédez comme suit :
- Dans Google Cloud Console, accédez à API et services :
- Cliquez sur Activer les API et les services.
- Dans la barre de recherche, saisissez
Trace API
. - Si l'option API activée est affichée, cette API est activée et vous n'avez rien à faire. Sinon, cliquez sur Activer.
Activer les insights sur les requêtes
Les métriques d'Insights sur les requêtes sont chiffrées au repos. Les utilisateurs qui ont accès au tableau de bord Cloud SQL peuvent accéder aux métriques de l'outil Insights sur les requêtes depuis le tableau de bord de ce dernier. Si vous disposez des autorisations nécessaires pour mettre à jour des instances, vous pouvez configurer Insights sur les requêtes. Pour obtenir la liste des autorisations requises pour les instances Cloud SQL, consultez la page Contrôle des accès aux projets Cloud SQL. Si vous ne disposez pas de ces autorisations et que vous souhaitez activer Insights sur les requêtes sur vos instances, contactez votre administrateur.
Console
Activer Insights sur les requêtes pour une instance
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
- Dans la tuile Configuration, cliquez sur Modifier la configuration.
- Dans la section Options de configuration, développez Insights sur les requêtes.
- Cochez la case Activer Insights sur les requêtes.
- Facultatif : sélectionnez une ou plusieurs des options suivantes de l'outil Insights sur les requêtes :
- Cliquez sur Enregistrer.
Stocker les adresses IP clientes
Valeur par défaut : false
Cette option vous permet de stocker les adresses IP clientes d'où proviennent les requêtes et de regrouper ces données pour en extraire des métriques. Les requêtes proviennent de plusieurs hôtes. L'examen des graphiques des requêtes à partir d'adresses IP clientes peut aider à identifier la source d'un problème.
Stocker les tags d'application
Valeur par défaut : false
Cette option permet de stocker les tags d'application qui vous aident à déterminer les API et les routes MVC (model-view-controller) qui envoient des requêtes, ainsi que de regrouper les données pour en extraire des métriques. Cette option nécessite l'ajout de commentaires sur les requêtes avec un ensemble spécifique de tags à l'aide de la bibliothèque d'instrumentation automatique Open Source sqlcommenter (mise en correspondance objet-relationnelle) de l'objet. Ces informations aident Insights sur les requêtes à identifier la source d'un problème et à comprendre de quelle route MVC provient le problème. Les chemins d'application facilitent la surveillance des applications.
Personnaliser la longueur des requêtes
Valeur par défaut : 1024
Définit la limite de longueur des requêtes sur une valeur spécifiée comprise entre 256 et 4 500 octets. Des longueurs de requête plus élevées sont plus utiles pour les requêtes analytiques, mais elles nécessitent également davantage de mémoire. Pour modifier la longueur de la requête, vous devez redémarrer l'instance. Vous pouvez toujours ajouter des tags aux requêtes qui dépassent la longueur maximale.
Définir le taux d'échantillonnage maximal
Valeur par défaut : 5
Définit le taux d'échantillonnage maximal. Le taux d'échantillonnage correspond au nombre d'échantillons de plan de requête exécutés capturés par minute sur l'ensemble des bases de données de l'instance. Pour modifier cette valeur, saisissez un nombre compris entre 0 (pour désactiver l'échantillonnage) et 20. Si vous augmentez le taux d'échantillonnage, vous obtiendrez peut-être plus de points de données, mais cela peut avoir un impact sur les performances et les coûts.
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Cliquez sur le menu Autres actions de n'importe quelle ligne.
- Sélectionnez Activer Insights sur les requêtes.
- Dans la boîte de dialogue, cochez la case Activer Insights sur les requêtes pour plusieurs instances .
- Cliquez sur Activer.
- Dans la boîte de dialogue suivante, sélectionnez les instances pour lesquelles vous souhaitez activer Insights sur les requêtes.
- Cliquez sur Activer Insights sur les requêtes.
gcloud
Afin d'activer Insights sur les requêtes pour une instance Cloud SQL à l'aide de gcloud
, exécutez gcloud sql instances patch
avec l'option --insights-config-query-insights-enabled
après avoir remplacé INSTANCE_ID par l'ID de l'instance.
gcloud sql instances patch INSTANCE_ID \ --insights-config-query-insights-enabled
De plus, utilisez une ou plusieurs des options facultatives suivantes :
--insights-config-record-client-address
Cette option vous permet de stocker les adresses IP clientes d'où proviennent les requêtes et de regrouper ces données pour en extraire des métriques. Les requêtes proviennent de plusieurs hôtes. L'examen des graphiques des requêtes à partir d'adresses IP clientes peut aider à identifier la source d'un problème.
--insights-config-record-application-tags
Cette option permet de stocker les tags d'application qui vous aident à déterminer les API et les routes MVC (model-view-controller) qui envoient des requêtes, ainsi que de regrouper les données pour en extraire des métriques. Cette option nécessite de commenter des requêtes avec un ensemble de tags spécifique. Pour ce faire, utilisez la bibliothèque d'instrumentation automatique ORM (mappage objet-relationnel) Open Source sqlcommenter. Ces informations aident Insights sur les requêtes à identifier la source d'un problème et à comprendre de quelle route MVC provient le problème. Les chemins d'application facilitent la surveillance des applications.
--insights-config-query-string-length
Définit la limite de longueur par défaut des requêtes de 256 à 4 500 octets. La longueur de requête par défaut est de 1 024 octets. Des longueurs de requête plus élevées sont plus utiles pour les requêtes analytiques, mais elles nécessitent également davantage de mémoire. Pour modifier la longueur de la requête, vous devez redémarrer l'instance. Vous pouvez toujours ajouter des tags aux requêtes qui dépassent la longueur maximale.
--query_plans_per_minute
Par défaut, 5 exemples de plan de requête exécutés sont capturés par minute dans toutes les bases de données de l'instance. Pour modifier cette valeur, saisissez un nombre compris entre 0 (pour désactiver l'échantillonnage) et 20. Si vous augmentez le taux d'échantillonnage, vous obtiendrez peut-être plus de points de données, mais cela peut avoir un impact sur les performances.
Remplacez les éléments suivants :
- INSIGHTS_CONFIG_QUERY_STRING_LENGTH : longueur de la chaîne de requête à stocker, en octets.
- API_TIER_STRING : configuration d'instance personnalisée à utiliser pour l'instance.
- REGION : région de l'instance
gcloud sql instances patch INSTANCE_ID \ --insights-config-query-insights-enabled \ --insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH \ --query_plans_per_minute=QUERY_PLANS_PER_MINUTE \ --insights-config-record-application-tags \ --insights-config-record-client-address \ --tier=API_TIER_STRING \ --region=REGION
REST v1
Afin d'activer Insights sur les requêtes pour une instance Cloud SQL à l'aide de l'API REST, appelez la méthode instances.patch
avec les paramètres insightsConfig
.
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- project-id : ID du projet
- instance-id : ID de l'instance.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Corps JSON de la requête :
{ "settings" : { "insightsConfig" : { "queryInsightsEnabled" : true } } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id", "status": "PENDING", "user": "user@example.com", "insertTime": "2021-01-28T22:43:40.009Z", "operationType": "UPDATE", "name": "operation-id", "targetId": "instance-id", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id", "targetProject": "project-id" }
Terraform
Afin d'activer Insights sur les requêtes pour une instance Cloud SQL à l'aide de Terraform, définissez l'option query_insights_enabled
sur true
.
Vous pouvez également utiliser une ou plusieurs des options facultatives suivantes :
query_string_length
: la valeur par défaut est 1024
, et vous pouvez la configurer sur une valeur comprise entre 256
et 4500
en octets.record_application_tags
: définissez la valeur sur true
si vous souhaitez enregistrer les tags d'application à partir de la requête.record_client_address
: définissez la valeur sur true
si vous souhaitez enregistrer l'adresse IP du client.query_plans_per_minute
: la valeur par défaut est 5
, et vous pouvez la configurer sur une valeur comprise entre 5
et 20
. resource "google_sql_database_instance" "INSTANCE_NAME" { name = "INSTANCE_NAME" database_version = "POSTGRESQL_VERSION" region = "REGION" root_password = "PASSWORD" deletion_protection = false # set to true to prevent destruction of the resource settings { tier = "DB_TIER" insights_config { query_insights_enabled = true query_string_length = 2048 # Optional record_application_tags = true # Optional record_client_address = true # Optional query_plans_per_minute = 10 # Optional } } }
Pour appliquer votre configuration Terraform dans un projet Google Cloud, suivez les procédures des sections suivantes.
Préparer Cloud Shell
- Lancez Cloud Shell.
-
Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.
Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.
Préparer le répertoire
Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).
-
Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension
.tf
, par exemplemain.tf
. Dans ce tutoriel, le fichier est appelémain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.
Copiez l'exemple de code dans le fichier
main.tf
que vous venez de créer.Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.
- Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
- Enregistrez les modifications.
-
Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire.
terraform init
Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option
-upgrade
:terraform init -upgrade
Appliquer les modifications
-
Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes :
terraform plan
Corrigez les modifications de la configuration si nécessaire.
-
Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant
yes
lorsque vous y êtes invité :terraform apply
Attendez que Terraform affiche le message "Apply completed!" (Application terminée).
- Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud, accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.
Les métriques sont généralement disponibles dans Insights sur les requêtes quelques minutes après la fin de la requête. Consultez les règles de conservation des données de Cloud Monitoring. Les traces d'Insights sur les requêtes sont stockées dans Cloud Trace. Consultez les règles de conservation des données de Cloud Trace.
Afficher le tableau de bord d'Insights sur les requêtes
Le tableau de bord d'Insights sur les requêtes affiche la charge de la requête en fonction des facteurs que vous sélectionnez. La charge de la requête correspond au calcul du travail total pour toutes les requêtes de l'instance au cours de la période sélectionnée. Le tableau de bord fournit une série de filtres qui vous aident à afficher la charge des requêtes.
Pour ouvrir le tableau de bord d'Insights sur les requêtes, procédez comme suit :
- Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
- Sélectionnez l'onglet Insights sur les requêtes dans le panneau de navigation de gauche ou cliquez sur le lien Consulter la page "Insights sur les requêtes" pour obtenir des informations plus détaillées sur les requêtes et les performances.
Le tableau de bord d'Insights sur les requêtes s'ouvre. Il affiche les informations suivantes concernant votre instance :
- Bases de données : permet de filtrer la charge des requêtes sur une base de données spécifique ou sur toutes les bases de données.
- Utilisateur : permet de filtrer la charge des requêtes à partir d'un compte utilisateur spécifique.
- Adresse client : permet de filtrer la charge des requêtes à partir d'une adresse IP spécifique.
- Période : permet de filtrer la charge des requêtes par période, par exemple par heure, par jour, par semaine ou selon une plage personnalisée.
- Graphique de la charge de la base de données : affiche le graphique de la charge des requêtes en fonction des données filtrées.
- Capacité du processeur, processeur et temps d'attente du processeur, attente E/S et temps de verrouillage : permet de filtrer en fonction des options que vous avez sélectionnées. Pour en savoir plus sur chacun de ces filtres, consultez la section Afficher la charge de la base de données pour les requêtes populaires.
- Requêtes et tags. Permet de filtrer la charge des requêtes en fonction d'une requête sélectionnée ou d'un tag de requête SQL sélectionné. Consultez la section Filtrer la charge de la base de données.
Afficher la charge de la base de données pour toutes les requêtes
La charge de la requête de la base de données est une mesure du travail (en secondes du processeur) ayant exécuté les requêtes de la base de données sélectionnée au fil du temps. Chaque requête en cours d'exécution utilise ou attend des ressources du processeur, des ressources d'E/S ou des ressources de verrouillage. La charge des requêtes de la base de données correspond au ratio du temps pris par toutes les requêtes effectuées sur une période donnée par rapport à la durée d'exécution.
Le tableau de bord de premier niveau d'Insights sur les requêtes affiche le graphique Charge de la base de données – toutes les principales requêtes. Les menus déroulants du tableau de bord vous permettent de filtrer le graphique pour une base de données, un utilisateur ou une adresse client spécifique.
Les lignes colorées dans le graphique indiquent la charge de la requête, divisée en quatre catégories :
- Capacité du processeur : nombre de processeurs disponibles sur l'instance
Processeur et temps d'attente du processeur : ratio entre le temps pris par les requêtes dans un état actif par rapport à la durée d'exécution. Les temps d'attente E/S et de verrouillage ne bloquent pas les requêtes dont l'état est actif. Cette métrique peut indiquer que la requête utilise le processeur ou qu'elle attend que le programmeur Linux planifie le processus du serveur exécutant la requête alors que d'autres processus utilisent le processeur.
Attente E/S : temps pris par les requêtes en attente d'E/S par rapport à la durée d'exécution. L'attente E/S comprend l'attente E/S en lecture et l'attente E/S en écriture.
Consultez la table des événements PostgreSQL.
Si vous souhaitez une répartition des informations sur les temps de verrouillage, vous pouvez les consulter dans Cloud Monitoring. Pour en savoir plus, consultez la page Métriques Cloud SQL.
Temps de verrouillage : temps pris par les requêtes en attente de verrous par rapport à la durée d'exécution. Cela inclut les temps d'attente associés aux valeurs Lock, LwLock et BufferPin. Pour afficher des informations détaillées concernant les temps de verrouillage, utilisez Cloud Monitoring. Pour en savoir plus, consultez la page Métriques Cloud SQL.
Examinez le graphique et utilisez les options de filtrage pour explorer les questions suivantes :
- La charge de la requête est-elle élevée ? Le graphique a-t-il connu un pic ou augmenté au fil du temps ? Si vous ne constatez pas de charge élevée, le problème ne concerne pas votre requête.
- Depuis combien de temps la charge est-elle élevée ? Est-elle élevée seulement actuellement ou a-t-elle été élevée depuis longtemps ? Utilisez le sélecteur de plage pour sélectionner différentes périodes afin de déterminer la durée du problème. Effectuez un zoom avant pour afficher une période pendant laquelle les pics de charge de requêtes sont observés. Effectuez un zoom arrière pour afficher jusqu'à une semaine de la chronologie.
- Qu'est-ce qui provoque la charge élevée ? Vous pouvez sélectionner des options pour examiner la capacité du processeur, le processeur et le temps d'attente du processeur, le temps de verrouillage ou l'attente E/S. Le graphique de chacune de ces options s'affiche dans une couleur différente, ce qui vous permet d'identifier facilement celle qui présente la charge la plus élevée. La ligne bleu foncé sur le graphique indique la capacité maximale du processeur du système. Il vous permet de comparer la charge de requête avec la capacité maximale de processeur du système. Cette comparaison vous permet de déterminer si une instance manque de ressources de processeur.
- Quelle base de données subit la charge ? Sélectionnez différentes bases de données dans le menu déroulant "Bases de données" pour trouver celles avec les charges les plus élevées.
- Des utilisateurs ou adresses IP spécifiques entraînent-ils des charges plus élevées ? Sélectionnez des utilisateurs et des adresses différents dans les menus déroulants pour identifier ceux qui entraînent des charges plus élevées.
Filtrer la charge de la base de données
Vous pouvez filtrer la charge de la base de données par requêtes ou par tags.
Filtrer par requêtes
Le tableau Requêtes fournit un aperçu des requêtes qui provoquent les charges de requête les plus élevées. Le tableau affiche toutes les requêtes normalisées pour la période et les options sélectionnées dans le tableau de bord d'Insights sur les requêtes. Il trie les requêtes par durée d'exécution totale au cours de la période sélectionnée.
Pour trier le tableau, sélectionnez un en-tête de colonne ou une propriété dans Filtrer les requêtes. Le tableau affiche les propriétés suivantes :
Requête : chaîne de requête normalisée. Par défaut, Insights sur les requêtes affiche uniquement 1 024 caractères dans la chaîne de requête.
Les requêtes libellées
UTILITY COMMAND
incluent généralement les commandesBEGIN
,COMMIT
etEXPLAIN
, ou les commandes de wrapper.Base de données : base de données sur laquelle la requête a été exécutée.
Charge par temps total/Charge par processeur/Charge par attente E/S/Charge par attente de verrouillage : options que vous pouvez utiliser pour filtrer des requêtes spécifiques en vue d'identifier la charge la plus élevée.
Temps d'exécution moyen (ms) : temps moyen d'exécution de la requête.
Heures d'appel : nombre de fois que l'application a appelé la requête.
Lignes renvoyées en moyenne : nombre moyen de lignes renvoyées pour la requête.
Insights sur les requêtes stocke et affiche uniquement les requêtes normalisées. Par défaut, Insights sur les requêtes ne collecte pas d'adresses IP ni d'informations sur les tags. Vous pouvez activer Insights sur les requêtes pour collecter ces informations et, si nécessaire, désactiver la collecte. Les traces du plan de requête ne collectent ni ne stockent aucune valeur constante et suppriment toutes les informations personnelles que la constante peut afficher.
Pour PostgreSQL 9.6 et 10, Query Insights affiche les requêtes normalisées, à savoir ?
remplace la valeur constante littérale. Dans l'exemple suivant, la constante de nom est supprimée et ?
la remplace.
UPDATE
"demo_customer"
SET
"customer_id" = ?::uuid,
"name" = ?,
"address" = ?,
"rating" = ?,
"balance" = ?,
"current_city" = ?,
"current_location" = ?
WHERE
"demo_customer"."id" = ?
Pour PostgreSQL 11 et versions ultérieures, $1
, $2
, etc., remplacent les valeurs constantes littérales.
UPDATE
"demo_customer"
SET
"customer_id" = $1::uuid,
"name" = $2,
"address" = $3,
"rating" = $4,
"balance" = $5,
"current_city" = $6,
"current_location" = $7
WHERE
"demo_customer"."id" = $8
Filtrer par tags de requête
Pour dépanner une application, vous devez d'abord ajouter des tags à vos requêtes SQL. Les tags de charge de requête fournissent la répartition de la charge des requêtes pour le tag sélectionné au fil du temps.
Query Insights offre également une surveillance centrée sur les applications afin de diagnostiquer les problèmes de performances des applications créées à l'aide d'ORM. Si vous êtes responsable de l'ensemble de la pile d'applications, Query Insights assure la surveillance des requêtes à partir d'une vue de l'application. L'ajout de tags aux requêtes vous aide à détecter les problèmes liés à des constructions de niveau supérieur, tels que la logique métier ou un microservice.
Vous pouvez ajouter des tags aux requêtes en fonction de la logique métier, par exemple à l'aide des tags de paiement, d'inventaire, d'analyse commerciale ou de livraison. Vous pouvez ensuite identifier la charge liées aux requêtes créée par les différentes logiques métier. Par exemple, vous pouvez observer des événements inattendus, tels que des pics pour une balise d'analyse commerciale à 13h ou une croissance anormale pour un service de paiement au cours de la semaine précédente.
Pour calculer la charge de base de données pour un tag, Insights sur les requêtes utilise le temps nécessaire à chaque requête utilisant le tag sélectionné. L'outil calcule la durée de finalisation à la limite de la minute à l'aide de la durée d'exécution.
Dans le tableau de bord d'Insights sur les requêtes, sélectionnez Tags pour afficher le tableau des tags. Le tableau trie les tags en fonction de leur charge totale par durée totale.
Vous pouvez trier la table en sélectionnant une propriété dans Filtrer les tags ou en cliquant sur un en-tête de colonne. Le tableau affiche les propriétés suivantes :
- Action, Contrôleur, Framework, Route, Application, Pilote de base de données : chaque propriété que vous avez ajoutée à vos requêtes est affichée sous forme de colonne. Vous devez ajouter au moins une de ces propriétés si vous souhaitez effectuer un filtrage par tags.
- Charge par temps total/Charge par processeur/Charge par attente E/S/Charge par attente de verrouillage : options que vous pouvez utiliser pour filtrer des requêtes spécifiques en vue d'identifier la charge la plus élevée pour chaque option.
- Temps d'exécution moyen (ms) : temps moyen d'exécution de la requête.
- Lignes renvoyées en moyenne : nombre moyen de lignes renvoyées pour la requête.
- Heures d'appel : nombre de fois que l'application a appelé la requête.
- Base de données : base de données sur laquelle la requête a été exécutée.
Examiner une requête ou un tag spécifique
Pour déterminer si une requête ou un tag est la cause principale du problème, procédez comme suit à partir de l'onglet Requêtes ou Tags :
- Pour trier la liste par ordre décroissant, cliquez sur l'en-tête Charge par temps total.
- En haut de la liste, cliquez sur la requête ou sur le tag qui a la charge la plus élevée et prend plus de temps que les autres.
Un tableau de bord s'ouvre et affiche les détails de la requête ou du tag sélectionné.
Examiner une charge de requête spécifique
Le tableau de bord d'une requête sélectionnée s'affiche comme suit :
Le graphique Charge de la base de données – requête spécifique montre le travail (en secondes de processeur) effectué au cours du temps par la requête normalisée dans la requête sélectionnée. Pour calculer la charge, elle utilise le temps pris par les requêtes normalisées à la limite de la minute par rapport à la durée d'exécution. En haut du tableau, les 1 024 premiers caractères de la requête normalisée s'affichent. Les littéraux sont supprimés à des fins d'agrégation et de respect des informations permettant d'identifier personnellement l'utilisateur.
Comme pour le graphique des requêtes totales, vous pouvez filtrer la charge d'une requête spécifique par base de données, utilisateur et adresse client. La charge de requête est divisée en capacité du processeur, processeur et temps d'attente du processeur, attente E/S et temps de verrouillage.
Examiner une charge de requête taguée spécifique
Le tableau de bord d'un tag sélectionné s'affiche comme suit. Par exemple, si toutes les requêtes d'un paiement de microservices sont identifiées en tant que payment
, vous pouvez voir la tendance de la quantité de charge de la requête en consultant le tag payment
.
Le graphique (Charge de la base de données – tags spécifiques) montre le travail (en secondes de processeur) effectué au cours du temps par les requêtes correspondant aux tags spécifiés, dans la base de données sélectionnée. Comme pour le graphique des requêtes totales, vous pouvez filtrer la charge d'un tag spécifique par base de données, utilisateur et adresse client.
Examiner les opérations dans un plan de requête échantillonné
Un plan de requête prend un échantillon de votre requête et le divise en opérations individuelles. Il décrit et analyse chaque opération dans la requête.
Le graphique des exemples de plan de requête affiche tous les plans de requête en cours d'exécution à des heures particulières et la durée d'exécution de chaque plan. Vous pouvez modifier la fréquence à laquelle les échantillons de plans de requêtes sont capturés par minute. Consultez la page Activer les insights sur les requêtes.
Par défaut, le panneau de droite affiche les détails de l'exemple de plan de requête le plus long, comme indiqué dans le graphique Exemples de plan de requête. Pour afficher les détails d'un autre exemple de plan de requête, cliquez sur le cercle approprié sur le graphique. Les détails développés montrent un modèle de toutes les opérations du plan de requête. Chaque opération indique la latence, les lignes renvoyées et le coût de l'opération. Lorsque vous sélectionnez une opération, vous pouvez afficher plus de détails, tels que les blocs d'appels partagés, le type de schéma, les boucles et les lignes de planification.
Essayez de préciser le problème en examinant les questions suivantes :
- Quelles sont les ressources utilisées ?
- Quel est le rapport avec les autres requêtes ?
- La consommation évolue-t-elle au fil du temps ?
Examiner la latence
La latence correspond au temps d'exécution de la requête normalisée en temps réel écoulé. Vous utilisez le graphique Latence pour examiner la latence de la requête ou du tag. Le tableau de bord de latence montre les latences des 50e, 95e et 99e centiles afin de détecter les comportements présentant des anomalies.
L'image suivante illustre le graphique de charge de la base de données au 50e centile pour une requête spécifique avec les filtres sélectionnés pour la capacité du processeur, le processeur et le temps d'attente du processeur, l'attente E/S et le temps de verrouillage.
La latence des requêtes parallèles est mesurée en temps réel écoulé, même si la charge de la base de données peut-être supérieure pour la requête en raison de l'utilisation de plusieurs cœurs pour exécuter une partie de la requête.
Essayez de préciser le problème en examinant les questions suivantes :
- Qu'est-ce qui provoque la charge élevée ? Sélectionnez des options pour examiner la capacité du processeur, le processeur et le temps d'attente du processeur, l'attente E/S ou le temps de verrouillage.
- Depuis combien de temps la charge est-elle élevée ? Est-elle élevée uniquement maintenant ? Ou est-elle élevée depuis longtemps ? Modifiez la période pour trouver la date et l'heure auxquelles la charge s'est mal exécutée.
- Y a-t-il eu des pics de latence ? Modifiez la période pour étudier l'historique de latence de la requête normalisée.
Tracer la source du problème
Une fois que vous avez trouvé les zones et les heures où la charge était la plus élevée, identifiez la source du problème à l'aide de la trace pour afficher plus de détails.
Pour vous aider à identifier la source spécifique du problème, telle qu'un modèle, une vue, un contrôleur, une route, un hôte ou un utilisateur, Insights sur les requêtes fournit une trace en contexte de l'application de bout en bout pour vous aider à comprendre ce qui se passe au niveau de la couche de base de données pour une requête spécifique et trouver la source d'une requête problématique par modèle, vue, contrôleurs et route.
Si vous activez OpenCensus ou OpenTelemetry, les informations sur les délais OpenCensus sont envoyées à la base de données avec les informations sur le tag dans les commentaires SQL. Toutes les traces de l'application vers Cloud Logging sont associées aux traces du plan de requête de la base de données pour vous aider à identifier la source du problème.
Cliquez sur l'onglet Bout en bout sur l'écran d'exemple de requête pour examiner la trace contextuelle.
Pour déterminer le client et l'utilisateur à l'origine du problème, utilisez les tableaux Adresses client les plus utilisées et Utilisateurs les plus actifs afin d'identifier les charges les plus élevées. Vous pouvez ajouter un utilisateur ou une adresse IP au filtre pour analyser plus précisément un utilisateur ou une adresse client spécifique. Les détails des tableaux incluent le pourcentage de la charge de requête, le temps d'exécution moyen en millisecondes et les heures d'appels.
Vous pouvez utiliser Cloud Trace pour afficher la trace de bout en bout pour chaque étape du plan de requête. Dans le tableau de bord d'Insights sur les requêtes, cliquez sur le bouton Afficher dans la trace pour ouvrir l'outil Cloud Trace. Le graphique de trace affiche toutes les traces qui ont été exécutées au cours de la période sélectionnée.
Pour en savoir plus, consultez la page Rechercher et afficher des traces.
Ajouter des tags aux requêtes SQL
L'ajout de tags aux requêtes SQL simplifie le dépannage des applications. Vous pouvez utiliser sqlcommenter pour ajouter des tags à vos requêtes SQL automatiquement ou manuellement.
Utiliser sqlcommenter avec ORM
Lorsque vous utilisez ORM au lieu d'écrire directement des requêtes SQL, vous risquez de ne pas trouver le code d'application qui engendre le problème de performances. Vous aurez peut-être également des difficultés à analyser l'impact du code de votre application sur les performances des requêtes. Pour résoudre ce problème, Insights sur les requêtes fournit une bibliothèque Open Source appelée sqlcommenter. Cette bibliothèque est utile pour les développeurs et les administrateurs utilisant des outils ORM pour détecter le code d'application qui engendre des problèmes de performances.
Si vous utilisez conjointement ORM et sqlcommenter, les tags sont automatiquement créés. Vous n'avez pas besoin d'ajouter ni de modifier du code dans votre application.
Vous pouvez installer sqlcommenter sur le serveur d'applications. La bibliothèque d'instrumentation permet de propager des informations liées à l'application en rapport avec votre framework MVC dans la base de données, ainsi que les requêtes en tant que commentaire SQL. La base de données récupère ces tags, puis commence à enregistrer et à agréger les statistiques en fonction de leurs tags, qui sont orthogonaux avec des statistiques agrégées par requêtes normalisées. Insights sur les requêtes affiche les tags pour vous permettre d'identifier l'application à l'origine de la charge de la requête et de trouver le code d'application qui engendre des problèmes de performances.
Lorsque vous examinez les résultats dans les journaux de la base de données SQL, ils se présentent comme suit :
SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/
Les tags acceptées incluent le nom du contrôleur, la route, le framework et l'action.
L'ensemble d'outils ORM dans sqlcommenter est compatible avec les langages de programmation suivants :
Python |
|
Java |
|
Ruby |
|
Node.js |
|
Pour plus d'informations sur sqlcommenter et sur son utilisation dans votre framework ORM, consultez la documentation de sqlcommenter.
Ajouter des tags à l'aide de sqlcommenter
Si vous n'utilisez pas ORM, vous devez ajouter manuellement des tags sqlcommenter ou des commentaires au format de commentaire SQL approprié à votre requête SQL. Vous devez également enrichir chaque instruction SQL avec un commentaire contenant une paire clé-valeur sérialisée. Utilisez au moins l'une des clés suivantes :
action=''
controller=''
framework=''
route=''
application=''
db driver=''
Insights sur les requêtes supprime toutes les autres clés.
Désactiver Insights sur les requêtes
Console
Si vous souhaitez désactiver Insights sur les requêtes pour une instance Cloud SQL à l'aide de Google Cloud Console, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
- Dans la tuile Configuration, cliquez sur Modifier la configuration.
- Dans la section Options de configuration, développez Insights sur les requêtes.
- Décochez la case Activer Insights sur les requêtes.
- Cliquez sur Enregistrer.
gcloud
Afin de désactiver Insights sur les requêtes pour une instance Cloud SQL à l'aide de gcloud
, exécutez gcloud sql instances patch
avec l'option --no-insights-config-query-insights-enabled
après avoir remplacé INSTANCE_ID par l'ID de l'instance.
gcloud sql instances patch INSTANCE_ID \ --no-insights-config-query-insights-enabled
REST
Afin de désactiver Insights sur les requêtes pour une instance Cloud SQL à l'aide de l'API REST, appelez la méthode instances.patch
avec queryInsightsEnabled
défini sur false
comme suit.
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- project-id : ID du projet
- instance-id : ID de l'instance.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Corps JSON de la requête :
{ "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id", "status": "PENDING", "user": "user@example.com", "insertTime": "2021-01-28T22:43:40.009Z", "operationType": "UPDATE", "name": "operation-id", "targetId": "instance-id", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id", "targetProject": "project-id" }
Étapes suivantes
- Blog sur le lancement : Observabilité de la base de données pour les développeurs : présentation de Cloud SQL Insights
- Consultez la page Métriques Cloud SQL. Les chaînes de type de métrique d'Insights sur les requêtes commencent par
database/postgresql/insights
.
- Blog : Boostez vos compétences en dépannage des performances à l'aide de Cloud SQL Insights
- Vidéo : Présentation de Cloud SQL Insights
- Podcast : Cloud SQL Insights
- Atelier de programmation Insights
- Blog : Présentation de Sqlcommenter : bibliothèque d'instrumentation automatique ORM Open Source
- Blog : Activez l'ajout de tags aux requêtes avec Sqlcommenter