Outils de surveillance SQL Server : quoi suivre et comment choisir

Les outils de surveillance de SQL Server peuvent suivre tout, de l'activité CPU et disque de Windows aux blocages, statistiques d'attente, plans de requêtes et disponibilité de la base de données. Le bon outil dépend donc du niveau de SQL Server que vous devez réellement observer, plutôt que de la taille de sa liste de fonctionnalités.

Ce guide décompose ce que les équipes informatiques doivent surveiller, où la surveillance des serveurs Windows s'arrête et où la surveillance spécifique à SQL commence, quels outils Microsoft intégrés sont disponibles, et comment choisir une approche de surveillance appropriée.

Qu'est-ce qui rend la surveillance de SQL Server remarquable ?

Surveillance des serveurs, notions de base :

Microsoft SQL Server fonctionne sur une infrastructure serveur, donc la performance du système d'exploitation est importante Une utilisation élevée du CPU, une pression sur la mémoire ou un stockage lent peuvent affecter SQL Server même lorsque rien n'est intrinsèquement incorrect avec le moteur de base de données.

Besoins de surveillance spécifiques à la base de données pour les serveurs SQL :

Cependant, des métriques claires de Windows Server ne signifient pas nécessairement de bonnes performances de SQL Server. Les utilisateurs peuvent rencontrer des transactions lentes en raison de blocages, de mauvais plans d'exécution ou d'attentes de requêtes, tandis que la machine sous-jacente semble toujours en bonne santé.

Comment Microsoft divise cela :

Microsoft reflète cette distinction dans sa propre architecture de surveillance. Les outils Windows tels que le Moniteur de performance couvrent les ressources système, tandis que SQL Server fournit des fonctionnalités spécifiques aux bases de données, y compris le Query Store, les événements étendus, le Moniteur d'activité, les journaux d'erreurs et les capacités de surveillance Transact-SQL.

La surveillance de SQL Server devrait donc englober plusieurs couches complémentaires plutôt qu'un ensemble de métriques.

Que doivent suivre les outils de surveillance de SQL Server ?

Les métriques exactes nécessaires dépendent de la responsabilité principale des équipes informatiques, qu'il s'agisse de la disponibilité de l'infrastructure, de l'administration des bases de données ou de la performance des applications. Une stratégie de surveillance utile commence par une approche large et ajoute une visibilité plus approfondie sur SQL Server là où la charge de travail l'exige.

1. Santé du serveur et de l'infrastructure

Commencez par les ressources disponibles pour l'hôte SQL Server. Le CPU, la mémoire physique, la capacité du disque, l'activité de lecture et d'écriture du disque, l'utilisation du réseau et les processus en cours fournissent le contexte d'infrastructure pour la performance de la base de données.

Le point important est la corrélation. Des temps de réponse SQL élevés accompagnés d'une latence de stockage suggèrent une enquête différente par rapport aux requêtes lentes se produisant alors que l'hôte dispose d'une capacité CPU, mémoire et I/O suffisante.

Surveillance de l'hôte aide également à détecter des problèmes qui affectent plus que SQL Server. Un serveur physique ou virtuel peut héberger des applications, des services ou des utilisateurs distants dont l'activité concurrence les mêmes ressources.

2. Santé de l'instance et de la base de données SQL Server

La couche suivante examine l'intérieur du moteur de base de données lui-même.

Les domaines importants incluent généralement les attentes, les sessions actives, le blocage, les interblocages, la croissance des fichiers de base de données, l'utilisation des journaux de transactions et l'activité de TempDB. Les administrateurs peuvent également avoir besoin de surveiller l'état de la base de données, les connexions, le comportement de la mémoire et les services SQL Server.

Les statistiques d'attente sont particulièrement utiles car elles aident à identifier pour quelles tâches SQL Server attend plutôt que de montrer uniquement que le système est lent. Le blocage et les interblocages offrent une visibilité supplémentaire aidant à identifier si des transactions particulières se disputent des ressources.

Les plateformes de surveillance de bases de données dédiées vont donc beaucoup plus en profondeur que les moniteurs d'hôtes. Par exemple, IDERA SQL Diagnostic Manager documente la surveillance des attentes, des chaînes de blocage, des blocages, de la pression TempDB, de la latence I/O et de la croissance de la base de données.

3. Performance des requêtes et de la charge de travail

Une fois qu'un problème a été localisé dans la charge de travail de la base de données, les métriques agrégées du serveur sont souvent insuffisantes. Les administrateurs doivent déterminer quelles requêtes consomment des ressources excessives et si leur comportement a changé.

Des informations utiles au niveau des requêtes peuvent inclure la durée d'exécution, la consommation de CPU, les lectures logiques et physiques, la consommation de mémoire, la fréquence d'exécution, les attentes et les plans d'exécution.

Microsoft Query Store est un bon exemple de logiciel adapté à cela. Il conserve les requêtes, les plans et les statistiques d'exécution afin que les administrateurs puissent examiner les performances au fil du temps et identifier les régressions associées aux changements de plan de requête. SQL Server 2017 et versions ultérieures peuvent capturer les statistiques d'attente via Query Store.

Ce contexte historique est important car de nombreux problèmes de SQL Server sont intermittents. Savoir que le CPU a atteint 90 % hier après-midi est utile. Savoir quelles requêtes ont changé de comportement au même moment identifie des leviers d'action potentiels.

4. Disponibilité, Emplois et Santé Opérationnelle

La performance n'est qu'un aspect de la surveillance de SQL Server. Les pannes opérationnelles peuvent affecter la disponibilité et la récupérabilité même lorsque la performance de la charge de travail semble normale.

Selon l'environnement, les administrateurs peuvent avoir besoin de visibilité sur les travaux de SQL Server Agent, les sauvegardes, la disponibilité des bases de données et les groupes de disponibilité Always On. Des environnements plus grands ou critiques pour l'entreprise peuvent également nécessiter une surveillance de la réplication, un suivi de la configuration et des prévisions de capacité.

La profondeur requise doit suivre l'importance de la charge de travail. Une petite base de données interne ou un ensemble de serveurs SQL Server de production en cluster nécessitent des architectures de surveillance très différentes.

Quels outils de surveillance SQL Server intégrés pouvez-vous utiliser ?

Avant d'acheter une plateforme dédiée, il vaut la peine de comprendre ce que Microsoft SQL Server fournit déjà.

Un large éventail d'outils natifs :

• Le Moniteur d'activité prend en charge l'inspection ad hoc
• Le Query Store conserve des informations historiques sur les requêtes et les plans.
• Les événements étendus capturent des événements du moteur sélectionnés.
• Les vues de gestion dynamique exposent des données de performance internes
• Les journaux d'erreurs SQL Server aident à enquêter sur les événements du moteur de base de données.
• Le Moniteur de performance Windows ajoute des informations sur les ressources du système d'exploitation.

Diagnostics plus approfondies mais plus de complexité :

Ces outils peuvent fournir une profondeur de diagnostic substantielle, en particulier pour les administrateurs de bases de données expérimentés. Ils évitent également d'introduire un autre plateforme de surveillance lorsque le dépannage occasionnel est suffisant.

Leur limitation n'est souvent pas l'accès aux données mais la commodité opérationnelle. Une équipe informatique gérant plusieurs serveurs peut souhaiter des tableaux de bord centralisés, des historiques persistants, une alerte plus facile et une corrélation plus rapide au lieu de rassembler des informations provenant de plusieurs interfaces SQL Server et Windows.

C'est là que la surveillance par des tiers devient plus convaincante.

Comment choisir des outils de surveillance de SQL Server ?

Commencez par le problème que l'outil est censé résoudre. Cela devrait vous éviter de perdre de vue votre objectif dans une liste de contrôle du plus grand nombre de métriques prises en charge.

1. Profondeur de visibilité nécessaire

Une première question utile est de savoir si vous avez besoin de surveillance de l'infrastructure, de diagnostics du moteur de base de données ou d'analyse détaillée des requêtes.

Exigence	Approche de surveillance
CPU, mémoire, disponibilité du disque et du serveur	Surveillance des serveurs ou de l'infrastructure
Dépannage occasionnel de SQL Server	Outils Microsoft SQL Server intégrés
Blocage, attentes, interblocages et alertes de base de données	Surveillance dédiée de SQL Server
Plans de requêtes et régressions de performance	Store de requêtes ou surveillance SQL avancée
Grande infrastructure SQL multi-instance	Surveillance de base de données centralisée
SQL Server plus de dépendances d'application étendues	Infrastructure ou observabilité full-stack combinée avec une surveillance spécifique à SQL

Ces catégories peuvent se chevaucher. Dans de nombreux environnements, l'approche la plus pratique est une combinaison plutôt qu'un produit unique.

2. Correspondance des alertes et de l'historique avec les opérations

La surveillance devient la plus utile lorsqu'elle met en évidence un comportement anormal avant que les utilisateurs ne signalent un problème.

Regardez si un outil prend en charge les alertes de seuil, les tendances historiques et suffisamment de contexte pour enquêter sur l'événement par la suite. Les plateformes SQL spécialisées peuvent aller plus loin en attachant des chaînes de blocage, des graphiques de blocage ou des informations de requête directement à une alerte. Redgate Monitor, par exemple, documente les alertes spécifiques à SQL pour des événements tels que les blocages, les travaux échoués, les requêtes bloquées et les requêtes de longue durée.

Il est également important de définir des références. Une valeur qui est anormale pour une base de données peut être courante pour une autre, donc les alertes doivent refléter le comportement et l'importance commerciale des charges de travail individuelles.

3. Considérez l'échelle, le déploiement et l'administration

Un outil adapté à une instance SQL Server peut devenir encombrant sur des dizaines de serveurs.

Considérez combien d'hôtes, d'instances et de bases de données nécessitent une surveillance, comment les données de surveillance sont collectées et conservées, et à quel point il est facile pour les administrateurs de comparer les systèmes depuis une console centrale. La licence, l'effort de déploiement, la génération de rapports et l'administration des alertes doivent donc être évalués en même temps que la profondeur technique.

L'objectif n'est pas de collecter chaque métrique possible. Il s'agit de collecter les informations les plus pertinentes en quantité suffisante pour identifier un comportement anormal et raccourcir le chemin du symptôme à la cause afin que vos techniciens informatiques puissent résoudre un problème.

Où s'intègre TSplus Server Monitoring ?

TSplus Server Monitoring s'occupe de l'aspect infrastructure de ce modèle de surveillance. Il fournit visibilité en temps réel dans l'activité de lecture et d'écriture du CPU, de la mémoire, du disque, de la bande passante, des processus et des utilisateurs connectés, ainsi que des rapports historiques et des alertes configurables pour les métriques du serveur.

Pour un serveur Windows exécutant Microsoft SQL Server, cette visibilité aidera à déterminer si un problème de performance de base de données coïncide avec une pression sur le CPU, une consommation de mémoire, une activité disque ou une autre condition au niveau de l'hôte. Les rapports historiques fournissent également un contexte pour les problèmes d'infrastructure récurrents.

TSplus Server Monitoring n'est cependant pas un analyseur de performance de base de données SQL Server dédié. Les exigences spécifiques à SQL telles que l'analyse des plans d'exécution, l'investigation du Query Store, les chaînes de blocage, l'analyse des blocages ou les statistiques d'attente détaillées nécessitent les outils SQL Server de Microsoft ou un produit de surveillance de base de données spécialisé.

Pour de nombreuses équipes informatiques, ces couches se complètent mutuellement. Surveillance du serveur TSplus peut fournir une vue claire de la santé du serveur et de la consommation des ressources, tandis que les outils natifs de SQL Server fournissent une visibilité plus approfondie de la base de données et aident à identifier quand un incident indique un problème avec le moteur de base de données ou une charge de travail individuelle.

Conclusion

Choisir parmi les outils de surveillance de SQL Server commence par décider de ce qui nécessite une visibilité. Les ressources du serveur, la santé du moteur de base de données et la performance des requêtes représentent différentes couches du même système, et aucune métrique unique ne les explique toutes.

Commencez par la santé de l'infrastructure, puis ajoutez une surveillance spécifique à SQL chaque fois que la charge de travail nécessite un diagnostic plus approfondi. Cette approche en couches maintient la surveillance pratique tout en fournissant aux équipes informatiques un contexte suffisant pour distinguer un problème de serveur d'un problème de base de données ou de requête.

Quelques questions fréquemment posées

Qu'est-ce qu'un outil de surveillance de SQL Server ?

Un outil de surveillance SQL Server suit la santé, la performance ou la disponibilité des environnements Microsoft SQL Server. En fonction de son champ d'application, il peut surveiller les ressources hôtes, les bases de données, les attentes, les blocages, les requêtes, les travaux, les sauvegardes ou les configurations de disponibilité.

Quelles métriques SQL Server devrais-je surveiller ?

Les indicateurs clés dépendent de la charge de travail et incluent généralement le CPU, la mémoire et le stockage. Parallèlement, les marqueurs spécifiques à SQL indiquent des éléments tels que les attentes, le blocage, les interblocages, la croissance de la base de données, les journaux de transactions, l'activité de TempDB, la durée des requêtes et l'état des tâches.

La surveillance de Windows Server peut-elle détecter des problèmes de SQL Server ?

La surveillance de Windows Server peut identifier des problèmes d'infrastructure affectant SQL Server, y compris la pression sur le CPU, la mémoire et le disque. Elle ne peut pas à elle seule expliquer les problèmes du moteur de base de données tels que les régressions de plan de requête, les chaînes de blocage ou les attentes spécifiques à SQL.

SQL Server inclut-il ses propres outils de surveillance ?

Oui. Microsoft SQL Server comprend des outils et des fonctionnalités tels que Query Store, Extended Events, Activity Monitor, Dynamic Management Views, journaux d'erreurs et fonctions de performance Transact-SQL. Leur adéquation dépend de l'événement ou de la charge de travail en cours d'examen.

Ai-je besoin d'un logiciel de surveillance SQL Server dédié ?

Pas nécessairement. Les outils intégrés peuvent être suffisants pour de petits environnements ou des dépannages occasionnels. Associé à Surveillance du serveur TSplus Pour des besoins généraux, le moniteur intégré de SQL Server de Microsoft n'a que peu à envier aux produits de surveillance tiers. La surveillance dédiée devient plus utile lorsque les équipes ont besoin d'une visibilité centralisée, d'alertes continues, d'un historique à long terme ou d'un diagnostic plus rapide sur plusieurs instances de SQL Server.