Surveiller Azure Database pour MySQL – Serveur flexible

Azure Monitor collecte et agrège les métriques et les journaux d’activité de votre système pour surveiller la disponibilité, les performances et la résilience, et vous avertir des problèmes affectant votre système. Vous pouvez utiliser le portail Azure, PowerShell, Azure CLI, l’API REST ou les bibliothèques clientes pour configurer et afficher les données de surveillance.

Différentes métriques et journaux sont disponibles pour différents types de ressources. Cet article décrit les types de données de surveillance que vous pouvez collecter pour ce service et les moyens d’analyser ces données.

La supervision est essentielle pour maintenir l’intégrité, les performances et la sécurité de vos instances Azure Database pour MySQL - Serveur flexible. Azure Monitor fournit une solution complète pour collecter, analyser et agir sur les données de télémétrie à partir de vos serveurs MySQL. Cet article décrit les principales fonctionnalités de supervision disponibles, notamment les métriques, les journaux, les alertes et les outils de visualisation, pour vous aider à gérer de manière proactive vos charges de travail de base de données.

Collecter des données avec Azure Monitor

Ce tableau décrit comment collecter des données pour surveiller votre service et ce que vous pouvez faire avec les données une fois collectées :

Pour obtenir la liste de toutes les données prises en charge par Azure Monitor, consultez :

• Métriques prises en charge par Azure Monitor
• Journaux des ressources pris en charge par Azure Monitor

Problèmes connus

Les métriques du serveur ne sont pas générées lorsque le paramètre du serveur character_set_server est défini sur UTF16. Cela se produit parce que la tâche de collecte de métriques s’appuie sur le connecteur C# MySQL, qui présente des problèmes de compatibilité avec UTF16. Nous recommandons aux clients d’utiliser un autre jeu de caractères et de redémarrer le serveur après la mise à jour de la configuration pour restaurer les fonctionnalités de métriques.

Supervision intégrée pour Azure Database pour MySQL - Serveur flexible

Azure Database pour MySQL - Serveur flexible offre des ressources intégrées pour la supervision.

Journaux du serveur

Dans Azure Database pour MySQL – Serveur flexible, les utilisateurs peuvent configurer et télécharger les journaux du serveur pour faciliter le travail de résolution des problèmes. Quand cette fonctionnalité est activée, une instance Azure Database pour MySQL – Serveur flexible commence à capturer les événements du type de journal sélectionné et les écrit dans un fichier. Vous pouvez ensuite utiliser le portail Azure et Azure CLI afin de télécharger les fichiers pour les utiliser.

La fonctionnalité des journaux du serveur est désactivée par défaut. Pour plus d’informations sur l’activation des journaux du serveur, consultez Activer et télécharger les journaux du serveur pour Azure Database pour MySQL – Serveur flexible

Les journaux du serveur prennent en charge l’activation et le téléchargement des journaux des requêtes lentes et des journaux d’erreurs. Pour effectuer une analyse historique de vos données, dans le portail Azure, dans le volet Paramètres de diagnostic de votre serveur, ajoutez un paramètre de diagnostic pour envoyer les journaux à l’espace de travail Log Analytics, à Stockage Azure ou à des hubs d’événements. Pour plus d’informations, consultez Configurer des diagnostics.

Quand la journalisation est activée pour une instance Azure Database pour MySQL – Serveur flexible, les journaux sont disponibles jusqu’à 7 jours à compter de leur création. Si la taille totale des journaux d’activité disponibles dépasse 7 Go, les fichiers les plus anciens sont supprimés jusqu’à ce que de l’espace soit disponible. La limite de stockage de 7 Go pour les journaux du serveur est disponible gratuitement et ne peut pas être augmentée.

Les fichiers journaux subissent une rotation toutes les 24 heures ou lorsqu’ils atteignent 500 Mo, selon la première éventualité.

Journaux des requêtes lentes dans Azure Database for MySQL

Dans Azure Database pour MySQL – Serveur flexible, le journal des requêtes lentes disponible peut être configuré et consulté par les utilisateurs. Les journaux des requêtes lentes sont désactivés par défaut et peuvent être activés pour faciliter l’identification de goulots d’étranglement des performances lors de la résolution des problèmes.

Pour plus d’informations sur le journal des requêtes lentes MySQL, consultez la section sur le journal des requêtes lentes dans la documentation du moteur MySQL.

Configurer la journalisation des requêtes lentes

Par défaut, le journal des requêtes lentes est désactivé. Pour activer les journaux, définissez le paramètre de serveur slow_query_log sur ACTIVÉ. Ce paramètre peut être configuré à l’aide du portail Azure ou d’Azure CLI.

Les autres paramètres que vous pouvez ajuster pour contrôler le comportement de la journalisation des requêtes lentes sont les suivants :

• long_query_time : consigner une requête si sa durée d’exécution est supérieure à long_query_time (en secondes). La valeur par défaut est de 10 secondes. Le paramètre de serveur long_query_time s’applique globalement à toutes les connexions nouvellement établies dans MySQL. Cependant, il n’affecte pas les threads déjà connectés. Nous vous recommandons de vous reconnecter à Azure Database for MySQL Flexible Server à partir de l’application ou de redémarrer le serveur pour effacer les threads avec des valeurs antérieures de long_query_time et appliquer la valeur de paramètre mise à jour.
• log_slow_admin_statements : détermine si les instructions d’administration (par exemple ALTER_TABLE, ANALYZE_TABLE) sont consignées.
• log_queries_not_using_indexes : détermine si les requêtes qui n’utilisent pas d’index sont consignées.
• log_throttle_queries_not_using_indexes : limite le nombre de requêtes non indexées qui peuvent être écrites dans le journal des requêtes lentes. Ce paramètre prend effet quand log_queries_not_using_indexes est défini sur ACTIVÉ.

Consultez la documentation MySQL consacrée au journal des requêtes lentes pour obtenir une description complète des paramètres du journal des requêtes lentes.

Accéder aux journaux des requêtes lentes

Les journaux des requêtes lentes sont intégrés aux paramètres de diagnostic d’Azure Monitor. Après avoir activé les journaux des requêtes lentes sur votre instance Azure Database pour MySQL – Serveur flexible, vous pouvez les diriger vers les journaux Azure Monitor, Event Hubs ou Stockage Azure. Pour plus d’informations sur les paramètres de diagnostic, consultez la documentation des journaux de diagnostic. Pour plus d’informations sur l’activation des paramètres de diagnostic dans le portail Azure, consultez l’article du portail sur le journal des requêtes lentes.

Le tableau suivant décrit la sortie du journal des requêtes lentes. En fonction de la méthode de sortie, les champs inclus et l’ordre dans lequel ils apparaissent peuvent varier.

Suivre l’activité de base de données avec les journaux d’audit

Azure Database pour MySQL – Serveur flexible offre aux utilisateurs la possibilité de configurer des journaux d’audit. Les journaux d’audit peuvent être utilisés pour suivre l’activité au niveau de la base de données, y compris les événements relatifs aux connexions, à l’administration, au DDL et DML. Ces types de journaux sont couramment utilisés à des fins de conformité.

Configurer la journalisation d’audit

Par défaut, les journaux d’audit sont désactivés. Pour les activer, définissez le paramètre de serveur audit_log_enabled sur ACTIVÉ. Activez les journaux d’audit à l’aide du portail Azure ou d’Azure CLI.

Les autres paramètres que vous pouvez ajuster pour contrôler le comportement de la journalisation d’audit sont les suivants :

• audit_log_events : contrôle les événements à consigner. Consultez le tableau suivant pour obtenir des événements d’audit spécifiques.
• audit_log_include_users : utilisateurs MySQL à inclure pour la journalisation. La valeur par défaut de ce paramètre est vide, ce qui inclut tous les utilisateurs pour la journalisation. Ce paramètre a une priorité plus élevée par rapport audit_log_exclude_usersà . La longueur maximale du paramètre est de 512 caractères. Par exemple, la valeur générique de dev* inclut tous les utilisateurs avec des entrées commençant par le mot clé dev tel que dev1,dev_user,dev_2. Un autre exemple d’entrée générique pour inclure l’utilisateur est *dev. Dans cet exemple, tous les utilisateurs se terminant par la valeur « dev » comme « stage_dev,prod_dev,user_dev » sont inclus dans les entrées du journal d’audit. En outre, l’utilisation d’un point d’interrogation (?) comme caractère générique est autorisée dans les modèles.
• audit_log_exclude_users : utilisateurs MySQL à exclure de la journalisation. La longueur maximale du paramètre est de 512 caractères. Les entrées génériques pour l’utilisateur sont également acceptées pour exclure des utilisateurs dans les journaux d’audit. Par exemple, la valeur générique stage* exclut tous les utilisateurs avec des entrées commençant par le mot-clé stage comme stage1,stage_user,stage_2. Un autre exemple d’entrée générique pour exclure un utilisateur est *com. Dans cet exemple, tous les utilisateurs se terminant par une valeur com sont exclus des entrées du journal d’audit. En outre, l’utilisation d’un point d’interrogation (?) comme caractère générique est autorisée dans les modèles.

Accéder aux journaux d’audit

Les journaux d’audit sont intégrés aux journaux de diagnostic Azure Monitor. Après avoir activé les journaux d’audit sur votre serveur flexible, vous pouvez les émettre vers les journaux Azure Monitor, Azure Event Hubs ou Stockage Azure. Pour plus d’informations sur les paramètres de diagnostic, consultez la documentation des journaux de diagnostic. Pour plus d’informations sur l’activation des paramètres de diagnostic dans le portail Azure, consultez l’article du portail des journaux d’audit.

En fonction de la méthode de sortie, les champs inclus et l’ordre dans lequel ils apparaissent peuvent varier.

Connexion:

Généralités:

Le schéma suivant s’applique aux types d’événements GENERAL, DML_SELECT, DML_NONSELECT, DML, DDL, DCL et ADMIN.

Accès aux tables de données :

Utilisez les classeurs d'Azure Monitor

Azure Database pour MySQL – Serveur flexible est maintenant intégré aux classeurs Azure Monitor. Les workbooks vous offrent un canevas flexible pour l’analyse des données et la création de rapports visuels enrichis au sein du portail Azure. Les classeurs vous permettent d’exploiter plusieurs sources de données au sein d’Azure et de les combiner dans des expériences interactives unifiées. Les modèles de classeur servent de rapports organisés que plusieurs utilisateurs et équipes conçoivent pour une réutilisation flexible.

Quand vous ouvrez un modèle, vous créez un classeur temporaire qui est rempli avec le contenu du modèle. Avec cette intégration, le serveur dispose d’un lien vers les workbooks et quelques exemples de modèles, ce qui peut vous aider à superviser le service à grande échelle. Vous pouvez modifier ces modèles, les personnaliser selon vos besoins et les épingler au tableau de bord pour créer une vue ciblée et organisée des ressources Azure.

Trois modèles sont disponibles pour Azure Database pour MySQL – Serveur flexible :

• Vue d’ensemble : affiche le récapitulatif d’une instance et les métriques principales pour vous aider à visualiser et à comprendre l’utilisation des ressources sur votre serveur. Ce modèle affiche les vues suivantes :

  • Résumé du serveur
  • Résumé de la base de données
  • Métriques de connexion
  • Mesures de performances
  • Métriques de stockage

• Audit : affiche un récapitulatif et des détails sur les événements d’audit collectés pour le serveur. Ce modèle affiche les vues suivantes :

  • Actions d’administration sur le service
  • Résumé de l’audit
  • Résumé de l’audit des événements de connexion
  • Audit des événements de connexion
  • Résumé de l’accès aux tables
  • Erreurs identifiées

• Query Performance Insight : affiche un récapitulatif et des détails de la charge de travail de requête sur l’instance, requête longue, analyse de requête lente et métriques de connexion. Ce modèle affiche les vues suivantes :

  • Chargement des requêtes
  • Nombre total de connexions actives
  • Tendance des requêtes lentes (durée des requêtes supérieure à 10 secondes)
  • Détails des requêtes lentes
  • Répertorier les cinq requêtes les plus longues
  • Résume les requêtes lentes selon la durée minimale, maximale, moyenne et l’écart type des requêtes

Vous pouvez aussi modifier et personnaliser ces modèles selon vos besoins. Pour plus d’informations, consultez Azure Workbooks.

Accéder aux modèles de classeur

Pour voir les modèles dans le portail Azure, accédez au volet Surveillance pour Azure Database pour MySQL – Serveur flexible et sélectionnez Classeurs.

Vous pouvez également afficher la liste des modèles en accédant au volet Modèles publics.

Utiliser les outils Azure Monitor pour analyser les données

Ces outils Azure Monitor sont disponibles dans le portail Azure pour vous aider à analyser les données de surveillance :

• Certains services Azure ont un tableau de bord de supervision intégré dans le portail Azure. Ces tableaux de bord sont appelés insights, et vous pouvez les trouver dans la section Insights d’Azure Monitor dans le portail Azure.

• Metrics Explorer vous permet d’afficher et d’analyser les métriques pour les ressources Azure. Pour plus d’informations, consultez Analyser les métriques avec l’Explorateur de métriques Azure Monitor.

• Log Analytics vous permet d’interroger et d’analyser les données de journalisation à l’aide du langage de requête Kusto (KQL) . Pour plus d’informations, voir Introduction aux requêtes de journal dans Azure Monitor.

• Le portail Azure dispose d’une interface utilisateur pour l’affichage et les recherches de base du journal d’activité . Pour effectuer une analyse plus approfondie, routez les données vers les journaux Azure Monitor et exécutez des requêtes plus complexes dans Log Analytics.

• Application Insights surveille la disponibilité, les performances et l’utilisation de vos applications web, afin de pouvoir identifier et diagnostiquer les erreurs sans attendre qu’un utilisateur les signale.
  Application Insights inclut des points de connexion à différents outils de développement et s’intègre à Visual Studio pour prendre en charge vos processus DevOps. Pour plus d’informations, consultez Surveillance des applications pour App Service.

Les outils qui permettent une visualisation plus complexe sont les suivants :

• Tableaux de bord qui vous permettent de combiner différents types de données dans un seul volet du portail Azure.
• Les workbooks, des rapports personnalisables que vous pouvez créer dans le portail Azure. Les workbooks peuvent inclure du texte, des métriques et des requêtes de journal.
• Grafana, un outil de plateforme ouvert, parfait pour les tableaux de bord opérationnels. Vous pouvez utiliser Grafana pour créer des tableaux de bord qui incluent des données provenant de plusieurs sources autres qu’Azure Monitor.
• Power BI, un service d’analyse métier qui fournit des visualisations interactives pour diverses sources de données. Vous pouvez configurer Power BI pour importer automatiquement des données de journal à partir d’Azure Monitor pour tirer parti de ces visualisations.

Exporter des données Azure Monitor

Vous pouvez exporter des données hors d’Azure Monitor dans d’autres outils à l’aide de :

• Métriques : utilisez l’API REST pour les métriques pour extraire les données de métriques de la base de données de métriques Azure Monitor. Pour plus d’informations, consultez Informations de référence sur l’API REST Azure Monitor.

• Journaux : utilisez l’API REST ou les bibliothèques de client associées.

• L’exportation de données de l’espace de travail Log Analytics.

Pour bien démarrer avec l’API REST Azure Monitor, consultez le guide de l’API REST Azure Monitor.

Utiliser des requêtes Kusto pour analyser les données de journal

Vous pouvez analyser les données du journal Azure Monitor à l’aide du langage de requête Kusto (KQL). Pour plus d’informations, consultez Requêtes de journal dans Azure Monitor.

Requêtes Kusto recommandées pour Azure Database pour MySQL - Serveur flexible

Vous pouvez utiliser les logs de requêtes lentes pour rechercher des candidats à l’optimisation. Une fois vos journaux des requêtes lentes dirigés vers des journaux Azure Monitor via des journaux de diagnostic, vous pouvez effectuer une analyse plus poussée de vos requêtes lentes. Ces exemples de requêtes peuvent vous aider à démarrer. Veillez à les mettre à jour avec le nom de votre serveur.

• Requêtes de plus de 10 secondes sur un serveur particulier

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | where query_time_d > 10
  

• Répertorier les cinq requêtes les plus longues sur un serveur particulier

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | order by query_time_d desc
  | take 5
  

• Résumer les requêtes lentes par durée minimale, maximale, moyenne et écart type sur un serveur particulier

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | summarize count(), min(query_time_d), max(query_time_d), avg(query_time_d), stdev(query_time_d), percentile(query_time_d, 95) by Resource
  

• Représenter sous forme de graphique la distribution des requêtes lentes sur un serveur particulier

  AzureDiagnostics
  | where Resource  == '<your server name>'
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | summarize count() by Resource , bin(TimeGenerated, 5m)
  | render timechart
  

• Afficher les requêtes d’une durée de plus de 10 secondes sur toutes les instances Azure Database pour MySQL – Serveur flexible avec les journaux de diagnostic activés

  AzureDiagnostics
  | where Category == 'MySqlSlowLogs'
  | project TimeGenerated, Resource , event_class_s, start_time_t , query_time_d, sql_text_s
  | where query_time_d > 10
  

Pour les journaux d’audit, une fois que vos journaux d’audit sont redirigés vers les journaux d’activité Azure Monitor via les journaux de diagnostic, vous pouvez effectuer une analyse plus approfondie de vos événements audités. Ces exemples de requêtes peuvent vous aider à démarrer. Veillez à les mettre à jour avec le nom de votre serveur.

• Lister les événements GENERAL sur un serveur spécifique

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_class_s == "general_log"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

• Lister les événements CONNECTION_V2 sur un serveur particulier ; la colonne status_d indique le code d’erreur de connexion cliente rencontré par l’application cliente lors de la connexion.

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_subclass_s == "CONNECT"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, user_s, ip_s, status_d
  | order by TimeGenerated asc nulls last
  

• Lister les événements CONNECTION sur un serveur spécifique

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs' and event_class_s == "connection_log"
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

• Récapituler les événements audités sur un serveur spécifique

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | summarize count() by event_class_s, event_subclass_s, user_s, ip_s
  

• Représenter sous forme de graphique la distribution des types d’événements d’audit sur un serveur spécifique

  AzureDiagnostics
  | where Resource  == '<your server name>' //Server name must be in Upper case
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | summarize count() by Resource, bin(TimeGenerated, 5m)
  | render timechart
  

• Lister les événements audités sur toutes les instances Azure Database pour MySQL – Serveur flexible avec les journaux de diagnostic activés pour les journaux d’audit

  AzureDiagnostics
  | where Category == 'MySqlAuditLogs'
  | project TimeGenerated, Resource, event_class_s, event_subclass_s, event_time_t, user_s , ip_s , sql_text_s
  | order by TimeGenerated asc nulls last
  

Utiliser des alertes Azure Monitor pour vous avertir des problèmes

alertes Azure Monitor vous permettent d’identifier et de résoudre les problèmes dans votre système, et de vous avertir de manière proactive lorsque des conditions spécifiques sont trouvées dans vos données de surveillance avant que vos clients ne les remarquent. Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor. Il existe différents types d’alertes Azure Monitor en fonction des services que vous surveillez et des données de surveillance que vous collectez. Consultez Choix du type approprié de règle d’alerte.

Règles d’alerte Azure Monitor recommandées pour Azure Database pour MySQL - Serveur flexible

Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal.

Implémentation d’alertes à grande échelle

Pour certains services, vous pouvez surveiller à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type qui existent dans la même région Azure. Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée pour l'implémentation à grande échelle d'alertes de métriques de plateforme importantes, de tableaux de bord et de recommandations.

Obtenir des recommandations personnalisées à l’aide d’Azure Advisor

Pour certains services, si des conditions critiques ou des changements imminents se produisent pendant des opérations de ressources, une alerte s’affiche dans la page Vue d’ensemble du service concerné dans le portail. Des informations supplémentaires et les correctifs recommandés pour l’alerte sont disponibles dans les Recommandations Advisor sous Surveillance dans le menu de gauche. Pendant les opérations normales, aucune recommandation de conseiller ne s’affiche.

Pour plus d’informations sur Azure Advisor, consultez Vue d’ensemble d’Azure Advisor.

Contenu connexe

• Informations de référence sur les données de surveillance d’Azure Database for MySQL – Serveur flexible
• Supervision de ressources Azure avec Azure Monitor