Utiliser Query Insights pour améliorer les performances des requêtes

MySQL | PostgreSQL | SQL Server

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 MySQL. 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 :

1. Affichez la charge de la base de données pour les requêtes populaires
2. Identifiez une requête ou un tag potentiellement problématique
3. Examinez la requête ou le tag pour identifier les problèmes
4. 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.

Les insights sur les requêtes sont disponibles pour MySQL 5.7 et versions ultérieures.

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.

Note: By default, Query Insights displays data only from completed queries, unless you are monitoring active queries as part of Gemini in Databases. Pour surveiller toutes les requêtes exécutées en temps réel, consultez Surveiller les requêtes actives. Gemini dans les bases de données est en version Preview.

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.

Vous pouvez créer un compte pour évaluer les performances de Cloud SQL en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits à dépenser sur Cloud SQL pour exécuter, tester et déployer des charges de travail. Des frais ne vous seront facturés que si vous choisissez de passer à une version payante.

Inscrivez-vous pour essayer Cloud SQL gratuitement.

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 :

1. Dans Google Cloud Console, accédez à API et services :

   Accéder aux API et aux services

2. Cliquez sur Activer les API et les services.
3. Dans la barre de recherche, saisissez Trace API.
4. 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.

Remarque : Lorsque vous activez Insights sur les requêtes, toutes les autres opérations sont momentanément suspendues. Ces opérations incluent les vérifications de l'état, la journalisation, la surveillance et d'autres opérations sur les instances. Cependant, l'instance elle-même ne redémarre pas et vous disposez toujours d'un accès ininterrompu à votre base de données.

Console

Remarque : Si Insights sur les requêtes n'est pas activé sur l'une de vos instances, vous pouvez l'activer en cliquant sur Activer ou Activer pour plusieurs instances dans le tableau de bord d'Insights sur les requêtes.

Activer Insights sur les requêtes pour une instance

1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

   Accéder à la page Instances Cloud SQL

2. Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
3. Dans la tuile Configuration, cliquez sur Modifier la configuration.
4. Dans la section Options de configuration, développez Insights sur les requêtes.
5. Cochez la case Activer Insights sur les requêtes.
6. Facultatif : sélectionnez une ou plusieurs des options suivantes de l'outil Insights sur les requêtes :

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.

7. Cliquez sur Enregistrer.

Activer Insights sur les requêtes pour plusieurs instances

1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

   Accéder à la page Instances Cloud SQL

2. Cliquez sur le menu Autres actions de n'importe quelle ligne.
3. Sélectionnez Activer Insights sur les requêtes.
4. Dans la boîte de dialogue, cochez la case Activer Insights sur les requêtes pour plusieurs instances .
5. Cliquez sur Activer.
6. Dans la boîte de dialogue suivante, sélectionnez les instances pour lesquelles vous souhaitez activer Insights sur les requêtes.
7. Cliquez sur Activer Insights sur les requêtes.
   Remarque : Cette étape active les insights sur les requêtes sur vos instances sur la base de la configuration par défaut.

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 :

curl (Linux, macOS ou Cloud Shell)

Remarque : La commande suivante suppose que vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login, ou en utilisant Cloud Shell, qui vous connecte automatiquement à la CLI gcloud. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Remarque : La commande suivante suppose que vous vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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": "[e-mail]",
  "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.

Exemple :

resource "google_sql_database_instance" "INSTANCE_NAME" {
 name                = "INSTANCE_NAME"
 database_version    = "MYSQL_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

1. Lancez Cloud Shell.

2. 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).

1. 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 exemple main.tf. Dans ce tutoriel, le fichier est appelé main.tf.

   mkdir DIRECTORY && cd DIRECTORY && touch main.tf

2. 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.

3. Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
4. Enregistrez les modifications.
5. 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

1. 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.

2. 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).

3. 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.

Remarque : Les exemples Terraform partent généralement du principe que les API requises sont activées dans votre projet Google Cloud.

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 :

1. Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
2. 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.

Remarque : Si vous activez Gemini dans les bases de données, les règles de conservation des données pour les métriques des requêtes sont définies sur 30 jours. Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Vous pouvez traiter des données à caractère personnel dans le cadre de cette fonctionnalité, comme indiqué dans l'avenant relatif au traitement des données dans le cloud, sous réserve de respecter les obligations et restrictions décrites dans le contrat en vertu duquel vous accédez à Google Cloud.

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.

  Remarque : La charge du processeur tient compte à la fois de l'environnement d'exécution et du temps d'attente du programmeur Linux chargé de planifier le processus du serveur en cours d'exécution. Par conséquent, la charge du processeur peut dépasser la limite maximale de cœur.

• 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.

  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 :

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 commandes BEGIN, COMMIT et EXPLAIN, 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.

• Lignes analysées en moyenne : nombre moyen de lignes analysé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.

Insights sur les requêtes affiche les requêtes normalisées, ce qui signifie que la valeur constante littérale est remplacée par ?. 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" = ?

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.
• Lignes analysées en moyenne : nombre moyen de lignes analysé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 :

1. Pour trier la liste par ordre décroissant, cliquez sur l'en-tête Charge par temps total.
2. 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.

MySQL 5.7 fournit un plan de requête estimé avec la vue EXPLAIN, tandis que MySQL 8.0 et versions ultérieures fournissent un plan de requête exécuté avec la vue EXPLAIN ANALYZE. Un plan de requête estimé fournit le temps d'exécution estimé d'une requête, tandis qu'un plan de requête exécuté fournit des informations en temps réel de chaque étape d'exécution d'une requête donnée.

Les plans de requête dans MySQL 5.7 sont compatibles avec les requêtes suivantes compatibles avec l'instruction EXPLAIN :

• Pour des tables uniques : INSERT, SELECT, UPDATE et DELETE.

• Pour plusieurs tables : SELECT, UPDATE et DELETE.

Vous pouvez générer des plans de requête dans MySQL 8.0 et versions ultérieures pour toutes les requêtes compatibles avec EXPLAIN ANALYZE. Cet outil vous indique où MySQL passe du temps sur vos requêtes SELECT portant sur des tables uniques et plusieurs tables. Cloud SQL n'est pas compatible avec la génération de plans de requête LMD (langage de manipulation de données) multi-tables, car ces requêtes ne sont pas compatibles avec EXPLAIN ANALYZE.

L'exemple de plan de requête fournit une vue EXPLAIN ANALYZE pour les exemples de plans de requêtes liés à la requête normalisée. Il s'agit de plans de requête exécutés qui fournissent une répartition du temps d'activité de chaque opération du plan de 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 :

1. Quelles sont les ressources utilisées ?
2. Quel est le rapport avec les autres requêtes ?
3. 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 :

1. 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.
2. 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.
3. 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	Django psycopg2 Sqlalchemy Flask
Java	Hibernate Printemps
Ruby	Rails
Node.js	Knex.js Sequelize.js Express.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 :

1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

   Accéder à la page Instances Cloud SQL

2. Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
3. Dans la tuile Configuration, cliquez sur Modifier la configuration.
4. Dans la section Options de configuration, développez Insights sur les requêtes.
5. Décochez la case Activer Insights sur les requêtes.
6. 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 :

curl (Linux, macOS ou Cloud Shell)

Remarque : La commande suivante suppose que vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login, ou en utilisant Cloud Shell, qui vous connecte automatiquement à la CLI gcloud. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Remarque : La commande suivante suppose que vous vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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": "[e-mail]",
  "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 Google Cloud.

• 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