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

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.

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 :

  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.

Console

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

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

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 :

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

    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 :

    Affiche le tableau de bord Query Insights, avec des menus déroulants pour les bases de données, les utilisateurs et les adresses. À droite des menus déroulants, vous trouverez un filtre permettant de définir une période. En outre, un graphique indique la charge de la base de données pour les requêtes populaires. Au bas du graphique se trouvent des cases de sélection pour la capacité du processeur, le processeur et l'attente du processeur, l'attente d'E/S et l'attente de verrouillage, ainsi qu'un onglet pour les requêtes et les tags.
    • 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.

    Affiche le graphique de charge de base de données avec une charge en termes de capacité du processeur, de processeur et de temps d'attente du processeur, de temps d'attente d'E/S et de temps d'attente de verrouillage.

    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.

      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.

    Affiche le graphique de charge de la base de données avec une charge pour les requêtes, et les filtres sélectionnés pour la capacité du processeur, le processeur et le temps d'attente du processeur, le temps d'attente d'E/S et le temps d'attente de verrouillage.

    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.

    Affiche le tableau de bord d'Insights sur les requêtes, avec le chargement des tags et une liste de tags.

    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 :

    Illustre les graphiques de charge et de latence de la base de données pour une requête spécifique.

    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.

    Le graphique de charge de la base de données s'affiche avec une charge pour une requête spécifique, ainsi que 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.

    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.

    Illustre les graphiques de charge et de latence pour une requête spécifique.

    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.

    Un graphique pour des exemples de plans de requête, ainsi que l'heure à laquelle elles ont été exécutées au bas du graphique (axe X) et le nombre de secondes pendant lesquelles elles ont été exécutées sur la droite (axe Y).

    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.

    Le plan de requête indique la latence et le coût de chaque opération exécutée pour la requête. Elle commence par une agrégation, qui renvoie 48 lignes, avec une latence de 31,06 ms et un coût. de 296,34. L'opération suivante est une boucle imbriquée, qui est divisée en une autre boucle imbriquée et une matérialisation.
         La boucle imbriquée se divise en une autre boucle imbriquée et une analyse d'index. La matérialisation entraîne une analyse de séquence.

    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.

    Affiche le graphique de latence de la requête 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.

    Sélectionnez un tag de bout en bout pour afficher des informations spécifiques sur le tag. Le résumé affiche les RPC et la durée totale en ms pour chaque opération de ce tag.

    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.

    L'image montre que pour les adresses des principaux clients, la charge était de 100 %, le temps d'exécution moyen était de 19 568 secondes et le nombre d'exécution appelées 1 226. Pour les principaux utilisateurs, l'utilisateur postgres avait 100 % de la charge, un temps d'exécution moyen de 19 568 ms et avait été appelé 1 226 fois.

    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.

    Le graphique de trace affiche toutes les traces qui ont été exécutées pour la période sélectionnée, dans ce cas, une heure. La page contient également un tableau indiquant la latence, la méthode HTTP, l'URL, ainsi que l'heure à laquelle la trace a été exécutée (cd).

    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 :

    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