Tracer et suivre une activité

  • 11 minutes

Une grande partie de la gestion des bases de données réside dans le réglage des performances. Les fichiers journaux que vous utilisiez pour vérifier vos bases de données locales sont toujours disponibles dans Azure Database pour MySQL/PostgreSQL.

Une fois vos bases de données migrées vers Azure, vous devez continuer à consulter les fichiers journaux pour vous assurer que les performances des bases de données sont maintenues.

Dans cette leçon, vous verrez où les fichiers journaux pour PostgreSQL et MySQL sont stockés dans Azure, ainsi que le niveau de détail qu’ils contiennent.

Utiliser les journaux du serveur pour suivre l’activité de la base de données

Azure Database pour MySQL/PostgreSQL enregistre également des informations de diagnostic dans les journaux du serveur. Les journaux du serveur sont les fichiers journaux des messages natifs pour MySQL et PostgreSQL (et non les fichiers journaux des transactions, qui sont inaccessibles dans Azure Database pour MySQL/PostgreSQL). Ces fichiers contiennent des messages, l’état du serveur et d’autres informations sur les erreurs que vous utilisez pour déboguer les problèmes liés à vos bases de données. Les journaux du serveur sont conservés pendant jusqu’à sept jours (moins si la taille totale des fichiers journaux du serveur est supérieure à 7 Go).

Azure Database pour MySQL et Azure Database pour PostgreSQL enregistrent des détails différents dans les journaux du serveur. Les sections suivantes décrivent les journaux du serveur pour chaque service séparément.

Journaux du serveur dans Azure Database pour MySQL

Dans Azure Database pour MySQL, le journal du serveur fournit les informations normalement disponibles dans le journal des requêtes lentes et le journal d’audit sur un serveur MySQL.

Vous utilisez les informations du journal des requêtes lentes pour identifier les requêtes lentes. Par défaut, le journal des requêtes lentes est désactivé. Pour l’activer, activez le paramètre de serveur slow_query_log (ON). Vous configurez le journal des requêtes lentes pour déterminer ce qu’implique une requête lente à l’aide des paramètres de serveur suivants :

  • log_queries_not_using_indexes. Ce paramètre a la valeur ON ou OFF. Définissez-le sur ON pour enregistrer toutes les requêtes susceptibles d’effectuer une analyse de table complète plutôt qu’une recherche d’index.
  • log_throttle_queries_not_using_indexes. Spécifie le nombre maximal de requêtes lentes n’utilisant pas d’index qui peuvent être consignées par minute.
  • log_slow_admin_queries. Définissez ce paramètre sur ON pour inclure les requêtes administratives lentes dans le journal.
  • long_query_time. Seuil (en secondes) selon lequel une requête doit être considérée comme lente.

Une fois que vous avez activé le journal des requêtes lentes et le journal d’audit, les fichiers journaux commencent à apparaître sur la page Journaux du serveur pour le serveur. Un nouveau journal des requêtes lentes est créé chaque jour. Cliquez sur un fichier journal pour le télécharger :

Image of the Server logs page for Azure Database for MySQL.

Pour activer la journalisation d’audit, activez le paramètre de serveur audit_log_enabled (ON). Vous configurez la journalisation d’audit avec les paramètres suivants :

  • audit_log_events. Spécifiez les événements à auditer. Dans le portail Azure, ce paramètre fournit une liste déroulante d’événements, tels que CONNECTION, DDL, DML, ADMIN.
  • audit_log_exclude_users. Ce paramètre est une liste séparée par des virgules d’utilisateurs dont les activités ne seront pas incluses dans le journal d’audit.

Si vous devez conserver le journal des requêtes lentes et le journal d’audit pendant plus de sept jours, vous pouvez faire en sorte qu’ils soient transférés vers le stockage Azure. Utilisez la page Paramètres de diagnostic de votre serveur, puis sélectionnez + Ajouter un paramètre de diagnostic. Sur la page Paramètres de diagnostic, sélectionnez Archiver dans un compte de stockage, sélectionnez un compte de stockage dans lequel enregistrer les fichiers journaux (ce compte de stockage doit déjà exister), sélectionnez MySqlSlowLogs et MySqlAuditLogs, puis spécifiez une période de rétention allant jusqu’à 365 jours. Vous pouvez télécharger les fichiers journaux à partir du stockage Azure à tout moment pendant cette période. Sélectionnez Enregistrer :

Image of the Diagnostic settings page for Azure Database for MySQL.

Les données du journal des requêtes lentes sont écrites au format JSON dans des objets BLOB dans un conteneur nommé insights-logs-mysqlslowlogs. L’affichage des fichiers journaux dans le stockage Azure peut prendre jusqu’à 10 minutes. Les enregistrements d’audit sont stockés dans le conteneur d’objets BLOB insights-logs-mysqlslowlogs, là encore au format JSON.

Journaux d’activité de serveur dans Azure Database pour PostgreSQL

Dans Azure Database pour PostgreSQL, le journal du serveur contient le journal des erreurs et les fichiers journaux des requêtes. Utilisez les informations contenues dans ces fichiers pour localiser les sources des erreurs et des requêtes inefficaces.

Vous activez la journalisation en activant les différents paramètres de configuration du serveur log_ (ON). Ces paramètres sont les suivants :

  • log_checkpoints. Un point de contrôle se produit chaque fois qu’un fichier de données est mis à jour avec les informations les plus récentes du journal des transactions. En cas de défaillance d’un serveur, ce point marque l’heure à laquelle la récupération doit commencer en restaurant par progression à partir du journal des transactions.
  • log_connection et log_disconnections. Ces paramètres enregistrent chaque connexion réussie et la fin de chaque session.
  • log_duration. Ce paramètre entraîne l’enregistrement de la durée de chaque instruction SQL terminée.
  • log_lock_waits. Ce paramètre entraîne l’enregistrement des événements d’attente de verrouillage. Les attentes de verrouillage peuvent être dues à des transactions mal implémentées dans le code d’application.
  • log_statement_stats. Ce paramètre écrit des informations cumulatives sur les performances du serveur dans le journal.

Azure Database pour PostgreSQL fournit également des paramètres supplémentaires pour affiner les informations enregistrées :

  • log_error_verbosity. Ce paramètre spécifie le niveau de détail enregistré pour chaque message journalisé.
  • log_retention_days. Il s’agit du nombre de jours pendant lesquels le serveur conserve chaque fichier journal avant de le supprimer. La valeur par défaut est de trois jours, et vous pouvez la définir sur sept jours maximum.
  • log_min_messages et log_min_error_statement. Utilisez ces paramètres pour spécifier les niveaux d’avertissement et d’erreur pour l’enregistrement des instructions.

Comme avec Azure Database pour MySQL, les fichiers journaux générés par Azure Database pour PostgreSQL sont disponibles sur la page Journaux du serveur. Vous pouvez également utiliser la page Paramètres de diagnostic pour copier les journaux dans le stockage Azure.

Suivre les performances des requêtes

Magasin des requêtes est une fonctionnalité supplémentaire fournie par Azure pour vous aider à identifier et à suivre les requêtes qui s’exécutent mal. Vous l’utilisez avec Azure Database pour MySQL et Azure Database pour PostgreSQL.

Activation du suivi des performances des requêtes

Magasin des requêtes enregistre des informations dans le schéma mysql dans Azure Database pour MySQL et dans une base de données nommée azure_sys dans Azure Database pour PostgreSQL. Magasin des requêtes permet de capturer deux types d’informations : les données relatives à l’exécution des requêtes et les informations sur les statistiques d’attente. Magasin des requêtes est désactivé par défaut. Pour l’activer :

  • Si vous utilisez Azure Database pour MySQL, définissez les paramètres de serveur query_store_capture_mode et query_store_wait_sampling_capture_mode sur ALL.
  • Si vous utilisez Azure Database pour PostgreSQL, définissez le paramètre de serveur pg_qs.query_capture_mode sur ALL ou TOP, et définissez le paramètre pgms_wait_sampling.query_capture_mode sur ALL.

Analyse des données de performances des requêtes

Vous pouvez interroger directement les tables utilisées par Magasin des requêtes. Si vous exécutez Azure Database pour MySQL, connectez-vous à votre serveur et exécutez les requêtes suivantes :

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Si vous utilisez Azure Database pour PostgreSQL, exécutez les requêtes suivantes à la place :

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

Dans les deux cas, la première requête affichera le texte de chaque requête d’exécution récente et diverses statistiques sur la durée de compilation et d’exécution de la requête. La deuxième requête affiche des informations sur les événements d’attente. Un événement d’attente se produit lorsqu’une requête ne peut pas s’exécuter du fait qu’elle nécessite des ressources détenues par une autre.

Si vous examinez le Magasin des requêtes directement, vous pouvez générer vos propres rapports personnalisés et obtenir un aperçu détaillé du fonctionnement du système. Toutefois, la quantité de données disponible peut compliquer la compréhension de ce qui se passe. Azure Database pour MySQL/PostgreSQL fournit deux outils supplémentaires pour vous aider à naviguer dans ces données : Aperçu des performances de requête et Recommandations de requête.

Aperçu des performances de requête est un utilitaire graphique, disponible à partir de la page Aperçu des performances de requête de votre serveur. L’onglet Requêtes longues affiche les statistiques des requêtes les plus longues. Vous spécifiez la période de temps et faites un zoom sur quelques minutes. La légende affiche le texte de chaque requête, ainsi que la durée et le nombre d’exécutions de la requête. Le graphique fournit une vue comparative de la durée de chaque requête. Vous affichez les données selon le temps moyen de chaque requête, mais il est également intéressant d’afficher le temps total (durée * nombre d’exécutions) pour chaque requête. L’image ci-dessous montre un exemple :

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

L’onglet Statistiques d’attente affiche les informations d’événement d’attente pour chaque requête. Vous verrez le temps d’attente de diverses ressources passé par une requête.

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

Les événements d’attente sont généralement répartis dans trois catégories :

  • Attentes de verrouillage. Ces événements se produisent si une requête tente de lire ou de modifier des données qui sont verrouillées par une autre requête. Si vous rencontrez un grand nombre d’attentes de verrouillage, vérifiez les transactions longues ou les opérations qui utilisent un niveau d’isolation très restrictif.
  • Attentes d’E/S. Ce type d’attente se produit si une requête exécute une quantité importante d’E/S. Cela peut être dû à une requête mal conçue (vérifiez la clause WHERE), à une opération de jointure inefficace ou à une analyse de table complète en raison d’un index manquant.
  • Attentes de mémoire. Une attente de mémoire se produit si la mémoire disponible est insuffisante pour traiter une requête. Votre requête peut tenter de lire une grande quantité de données, ou elle peut être bloquée par d’autres requêtes qui s’accaparent la mémoire. Là encore, cela peut indiquer que des index sont manquants, conduisant ainsi les requêtes à lire des tables entières dans la mémoire.

Il est également très probable qu’une forme d’attente en déclenche une autre. Vous ne pouvez pas donc examiner ces problèmes de manière isolée. Par exemple, une transaction qui lit et met à jour des données dans des tables différentes peut être sujette à une attente de mémoire. Cette transaction peut, quant à elle, avoir verrouillé des données qui provoquent une attente de verrouillage sur une autre transaction.

La page Recommandations sur les performances du serveur prend les informations contenues dans Magasin des requêtes et les utilise pour formuler des recommandations de réglage de votre base de données pour les charges de travail qu’elle rencontre.