Choisir un outil de surveillance SQL Server adapté à vos besoins

Avant de commencer à examiner un outil de surveillance de serveur SQL, réfléchissez à votre environnement spécifique :

• Combien d'instances voulez-vous surveiller ?
• Sont-ils au même endroit ou dispersés ?
• Avez-vous besoin de surveiller le système d'exploitation et/ou l'hyperviseur ?
• De combien d'historique avez-vous besoin pour obtenir une image précise des limites de fonctionnement de votre instance ?
• Sont-ils tous sur site ou certains sont-ils dans le cloud ?
• Vos équipes sont-elles réparties ?
• Achetez-vous des logiciels dans le cadre d'un budget d'investissement ou de dépenses opérationnelles ?
• Pouvez-vous vous permettre d'investir une somme forfaitaire dans l'infrastructure et la licence ou préférez-vous répartir vos coûts dans le temps ?
• Disposez-vous d'une infrastructure et d'instances de base de données à dédier à un outil de surveillance ?
• Avez-vous le temps de créer une infrastructure de surveillance ?
• Disposez-vous d'une expertise constante au sein de votre équipe ?
• Utilisez-vous des ressources juniors pour le tri initial ou dépendez-vous de vos experts pour tout ?
• Disposez-vous de temps ou de ressources en interne pour gérer l'infrastructure de surveillance ?

Dois-je rouler moi-même ?

Je peux déclarer notre partialité ici. Quest Software développe des outils de suivi des performances depuis 20 ans. Il y a une excellente raison pour laquelle nous et beaucoup d'autres comme nous sommes restés dans ce segment pendant si longtemps et pourquoi nous avons une clientèle croissante. Le suivi des performances bien fait n'est pas facile !

Il existe en effet d'excellents moyens de collecter des métriques à partir de SQL Server à l'aide de PerfMon, de traces, de DMV et de XEvents, pour n'en citer que quelques-uns. Faire cela de manière ponctuelle pour un seul problème est une bonne chose, si vous avez le temps d'investir dans la recherche où et comment collecter les données pour ce problème. Une fois que les problèmes commencent à s'accumuler et que le nombre d'instances augmente, cela devient rapidement inévolutif.

Il existe plusieurs centaines de mesures disponibles qui méritent d'être suivies pour obtenir une image complète de la santé des performances de votre serveur SQL. En plus de cela, il y a le code SQL qui s'exécute et les plans de requête associés à chaque exécution de celui-ci. Certaines métriques doivent être collectées toutes les secondes, d'autres toutes les heures et d'autres en fonction du moment où le code s'exécute. Certaines méthodes de collecte peuvent avoir un impact sur l'instance surveillée et doivent être évitées.

Chaque métrique aura des seuils différents qui définiront son statut. Des instances particulières peuvent avoir des niveaux qui ne sont pas standard. Ensuite, vous devez stocker tout cela. Le volume de données s'accumule TRÈS rapidement. Vous devrez mettre en place une stratégie pour purger régulièrement les données détaillées, puis, si nécessaire pour les tendances, agréger ces données pour les rapports.

C'est BEAUCOUP de travail… et bien sûr, chaque fois qu'une nouvelle version de SQL Server sort, vous avez un mal de tête de régression à gérer. À moins que vous ne souhaitiez réellement vendre un outil de surveillance, je vous déconseille fortement de lancer le vôtre, à moins que le volume de problèmes ne soit faible et que les problèmes que vous devez résoudre soient très spécifiques.

Qu'en est-il des outils gratuits ?

Les outils gratuits valent souvent la peine d'être envisagés, en particulier pour les petites équipes avec des instances moins critiques. Considérez-le comme la prochaine étape dans l'échelle de l'évolutivité après "roulez le vôtre". De nombreux outils de surveillance de serveur SQL commerciaux d'entrée de gamme devraient avoir des considérations similaires. Considérez ce qui suit :

• L'outil couvre-t-il un éventail suffisant de métriques pour vous offrir une couverture adéquate pour tous les cas d'utilisation sur vos instances surveillées ? De nombreux outils gratuits offrent une sorte de « personnalisation » pour ajouter vos propres mesures. Lorsque la "personnalisation" est utilisée pour combler les lacunes des fonctionnalités, vous constaterez rapidement que votre équipe finit par "rouler la sienne" avec la distraction et les maux de tête nécessaires à la maintenance.
• L'outil prend-il en charge les alertes ? Est-il préconfiguré ? La configuration des alertes peut prendre beaucoup de temps. L'alerte prête à l'emploi est indispensable pour éviter de perdre de nombreuses heures de travail à configurer l'outil de quelqu'un d'autre. Cela devrait également faciliter la personnalisation des alertes pour les cas extrêmes qui ne sont pas conformes aux valeurs par défaut.
• Comment et où les données sont-elles stockées ? La plupart des outils gratuits vous laissent gérer le stockage des données de performance. Méfiez-vous de la surveillance « gratuite » des fournisseurs de cloud. Ils facturent le stockage, et cela peut vite devenir gros et coûteux !

Donc, par tous les moyens, exploitez les outils gratuits qui existent. Soyez simplement conscient de leurs limites et recherchez les anti-modèles classiques au sein de votre équipe, tels que :

• Plus de temps passé à réparer ou à entretenir l'outil qu'à l'utiliser pour résoudre les problèmes
• Plus d'argent dépensé pour l'infrastructure et le stockage
• Beaucoup de données, mais pas d'insights
•  Diagnostics pas assez approfondis pour résoudre les problèmes
• Pas assez évolutif pour répondre à vos besoins

Si vous remarquez l'un des éléments ci-dessus, cela devrait indiquer la nécessité de passer à une solution plus robuste.

Architecture type d'un système de surveillance SQL Server

Lorsque vous envisagez d'opter pour une solution traditionnelle sur site ou une solution hébergée de logiciel en tant que service (SaaS), il est utile de prendre en compte l'architecture de l'application de surveillance. Voici un résumé des principaux composants architecturaux.

Le principal écart entre SaaS et sur site concerne l'endroit où les données de performances sont stockées et qui gère ce référentiel. Pour une solution sur site, cela relève de la responsabilité de l'utilisateur final. Ces référentiels peuvent devenir volumineux rapidement, ils doivent donc être gérés avec soin. L'infrastructure doit être planifiée et budgétisée (voir ci-dessous).

Dans une solution SaaS de surveillance de serveur SQL, ces composants clés de l'infrastructure sont hébergés et gérés pour vous.

Pour plus de détails, consultez notre blog, Database Monitoring System Architecture.