[Outils] MONITORING de Base de données SQL Server vs KANKURU

Arnaud Lepicier - 31/07/2019 à 17:51:120 commentaire


Pourquoi faire du monitoring de base ?


Après les serveurs WEB, les serveurs de base de données sont probablement la seconde partie la plus importante de votre système et c’est pourquoi il est critique de les monitorer pour qu’ils soient disponibles en permanence (ou presque).

C’est de la responsabilité du DBA d’assurer : la qualité de service, la disponibilité de service, la performance, l’intégrité ainsi que la sécurité des bases de données dont il a la responsabilité.

Le DBA mène des actions correctives en cas de problème mais doit aussi avoir une bonne vision générale sur des points clés afin d’anticiper ces problèmes.

Côté SQL server, Microsoft fourni une panoplie d’outils afin d’aider le DBA dans son monitoring quotidien.

Dans cet article nous allons traiter 4 points clés à monitorer et comment KANKURU, un outil de monitoring, peut aider dans ces cas-là.

J’ai pris en exemple un environnement complexe, avec un pool d’application large afin qu’on se rende mieux compte de l’impact d’un outil de monitoring.

Par soucis de confidentialité, les noms des serveurs, base de données et répertoires ont été effacés sur les captures d’écrans



Pourquoi KANKURU?


Pourquoi prendre en exemple cet outil en particulier pour parler du monitoring ?

KANKURU est une application qui facilite le monitoring de BDD, sur une vision macro. Vous n’allez donc pas jeter vos outils SQL server habituels, il faut le voir comme un complément. De plus son interface vous permet, d’un seul coup d’œil, d’avoir une vision sur votre système de base de données dans son ensemble. On pourrait donc très bien imaginer qu’il soit utilisé par une personne n’étant pas DBA, afin d’avoir une vision globale sur la santé de la base de données.

L’application permet de suivre sur un même Dashboard plusieurs instances réparties sur plusieurs serveurs.

L’application est en WPF (on reste dans le domaine Microsoft), gratuite et a été développée par un DBA.



Présentation de l’interface KANKURU


KANKURU est une application graphique,utilisée pour un monitoring macro.



Menu Home :



Menu Monitoring :



Menu Instances :



Menu Tools :



Menu Audit :



Comme vous pouvez le voir, il y a une multitude de menus. Nous allons surtout nous intéresser aux menus Monitoring et Instances qui seront les plus utilisés quotidiennement.

Sur KANKURU, la santé des différentes parties est représentée sous forme de pastille de couleur : vert, jaune et rouge. D’un rapide coup d’œil vous pourrez voir les problèmes critiques (rouge) et les problèmes à venir ou non critiques (jaune).



Job agent SQL Server


Sur une base de données, les jobs servent à automatiser les tâches que ce soit pour la gestion des données (INSERT, DELETE, UPDATE) ou même les taches de maintenance (comme la réorganisation des index).

Ils sont souvent indispensables pour la maintenance de votre base de données et la mise à jour de vos données.



Outils SQL server 

Nativement, SQL server nous donne plusieurs outils pour monitorer ces jobs :

- alerte de messagerie : vous pouvez configurer un envoi de mail à un opérateur en particulier et utiliser ce mail pour le rattacher à un évènement en particulier (ici on s’intéressera surtout à un envoi de mail pour prévenir d’un éventuel échec d’un job)

- historique des jobs : sur SSMS (SQL Server Management Studio) on a accès à un historique des derniers jobs afin de vérifier les exécutions ainsi que les messages d’erreurs sur les exécutions qui ont ratées.

- observateur d’évènements : il log les évènements (SQL entre autres). Lors du fonctionnement du serveur, des erreurs, des messages ou des événements générés par SQL server sont inscrits dans l’observateur d’événement de Windows.



Kankuru 


Kankuru de son côté possède un Dashboard qui contient l’historique de l’exécution des jobs SQL et vous indique si vous devez regarder l’exécution des jobs d’un peux plus prêt (pastille jaune et rouge) ainsi que d’autres informations sur la santé de votre instance :


Vous pouvez également regarder l’exécution de vos jobs sous forme de diagramme de GANTT :



C’est donc un aperçu plus graphique de vos jobs SQL et qui permet une première analyse (les erreurs sont aussi visibles).



Lenteurs applicatives


Les lenteurs applicatives sont malheureusement un problème récurrent rencontré par les DBA (sinon ils n’auraient pas raison d’être).

Une base de données évolue avec le temps et vos requêtes qui ne rencontraient pas de problèmes hier peuvent d’un coup ralentir la base et donc votre application.




Outils SQL server


- performance monitor et activity monitor : outils pour capturer la santé de votre système. Dans notre cas on pourra voir si SQL Server est bien la cause d’un ralentissement ou si c’est un problème externe.

- SQL profiler : outil de trace qui capture les requêtes qui passent sur une base de données. Très utile dans le cas où on a déjà identifié que le problème venait bien de SQL Server. Il nous fournira des métriques sur les exécutions. Attention cependant à la consommation de ressource du profiler. Il est souvent malvenu de lancer une trace SQL profiler sans filtres sur une base de données (surtout en production).

- Index manquants : il existe des requêtes disponibles pour identifier les index manquants sur une base. Attention cependant au sur-indexage. Avant de créer un index il faut toujours mesurer les gains par rapport aux pertes (nombre de fois ou l’index va être utilisé par exemple). Un index pour une requête non critique qui passe une fois par mois par exemple ne sera pas le plus prioritaire à mettre.

- Query store (magasin de requête pour les allergiques à l’anglais) : introduit dans SQL Server 2016 il permet de capturer des données sur l’exécutions des requêtes (historique, métriques, plans d’exécution). Cette fonctionnalité doit être activée sur la base (désactivée par défaut).

- DATABASE ENGINE TUNING ADVISOR. Outil intégré à SSMS, il permet de faire une analyse sur les index requis, les statistiques, le partitionnement et le modèle physique.   

- Data collector. Outil de collecte des données, il est customisable et schedulable (voir annexe pour le lien).



Kankuru


Sur KANKURU l’instance Dashboard nous donne une vision globale et rapide des points critiques de notre instance :




Nous ne rentrerons pas dans le détail mais les indicateurs clés de performance sont affichées.

Le DBA fera tout particulièrement attention aux indices suivant : Page life Expectancy,Batch Request per second, transaction, lock wait per second et les indices IO. En tout cas dans un premier temps.

Deux écrans seront aussi très souvent utilisés (surtout si le problème est en cours) : WHO et Live session.

Ces deux écrans donnent les détails des sessions en cours avec leur plan d’exécution.



Avec les différentes métriques (mémoire, IO, CPU) on peut identifier les requêtes qui prennent trop de ressources.

A l’image du Query Store, on retrouve un top 50 des requêtes les plus consommatrices en ressources sur l’écran : Top 50 SP



Les Wait ont aussi leur écran :


Les chartes donnent la répartition des attentes par rapport au type, nombre etc…


A ces écrans on peut ajouter :

IO profiler



CPU usage 





Espace disque 


L’espace disque sur les serveurs SQL devient très vite une priorité, surtout sur les applications qui tournent depuis longtemps ou qui ont une augmentation soudaine de trafic.

LE DBA doit connaitre à tout instant l’espace disque restant pour ses instances ainsi que leur historique d’augmentation afin de pouvoir anticiper un problème d’espace disque qui est souvent synonyme de plantage.



Outils SQL server 


Sur SQL server nous avons 2 outils principaux pour monitorer l’espace disque :

- data collector. Cet outil que nous avons déjà vu plus haut permet de voir l’augmentation de taille des disques s’il est configuré dans ce but (voir annexe)

- Scripts PowerShell / requête. Un script PowerShell peut récupérer l’espace disque de différents serveurs et ainsi donner un instantané de l’espace disque restant. Une requête SQL peut renvoyer l’espace disque restant pour les fichiers de base de données (voir annexe).




KANKURU


Kankuru donne un récapitulatif de la taille des fichiers de données et de logs :


On peut configurer un seuil de pourcentage d’espace disque restant en-deçà duquel on affiche les fichiers (pour n’afficher que les fichiers qui sont devenus trop volumineux par exemple)

Les fichiers sont aussi visibles en « treemap ». Cette vue, plus graphique, vous permet d’avoir plus d’informations (notamment au niveau de la criticité) :



Fichiers de données : rouge

Fichiers logs : bleu

Plus la couleur est vive, moins il y a d’espace disponible. Plus le rectangle est grand, plus le fichier est volumineux. Sur cet exemple on voit bien pour quels fichiers il faudra mener des actions.

Une deuxième vue sera utilisée, la vue d’évolution des espaces. Cette vue permet de suivre la tendance sur le stockage de notre serveur SQL. Sur cette vue on fera une analyse de courbe simple, si la courbe devient exponentielle pour un fichier par exemple on prendra des mesures correctives sur celui-ci en priorité.



Livraison des scripts 


Dans un projet, la livraison des scripts rencontre souvent des problèmes, surtout pour les déploiements sur serveurs SQL. Souvent les processus de déploiement sont trop lourds ou inexistants et il y a toujours un risque de déployer des scripts qui vont planter.

On peut prendre l’exemple simple d’un DEV qui change la structure d’une table pour un besoin sans mesurer les impacts sur les procédures/ vues existantes.

Il faut donc pouvoir monitorer les modifications du modèle de donnée.



Outils SQL server 


Sur SQL server nous avons 2 outils principaux pour la modification du modèle de donnée :

-       La dépendance d’objets : sur SSMS, pour une table/ procédure / vue etc… vous pouvez inspecter ses dépendances vis-à-vis des autres objets de la base.

-       Database Compare : l’outil principal pour vérifier si on livre bien tout. En comparant 2 environnements ou 1 projet BDD sur Visual Studio et un environnement cible on va pouvoir générer un script des différences et déployer notre version.



KANKURU


Kankuru possède un comparateur de BDD mais il fonctionne sur le même principe que celui de Visual Studio par exemple :

Le réel plus de Kankuru va être sur le database compilator. C’est un outil qui génère les plans d’exécutions pour les objets et  génère des erreurs pour chaque procédure / vue qui ont des problèmes d’exécution du à des changements de modèle.

Grâce à cet outil, après déploiement de votre version, vous n’aurez plus d’erreurs techniques sur un objet.





Cette présentation du monitoring sur Kankuru est terminée.

Comme on a pu le voir, Kankuru reste un complément, un outil du DBA pour faciliter certaines prises de décisions grâce à une interface plus visuelle.

Je vous invite à regarder le WIKI Kankuru pour plus d’informations sur les différents écrans qui composent l’application.



ANNEXE


Script Index manquants :

https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/


Data collector pour monitoring espace disque:

https://docs.microsoft.com/en-us/sql/relational-databases/data-collection/system-data-collection-set-reports?view=sql-server-2017

 

Powershell pour monitoring espace disque:

https://www.mssqltips.com/sqlservertip/5839/sql-server-disk-space-monitoring-for-all-instances-with-powershell-script/

 

Script SQL monitoring espace disque :

https://blog.sqlauthority.com/2013/08/02/sql-server-disk-space-monitoring-detecting-low-disk-space-on-server/


WIKI officiel KANKURU :

http://kankuru.com/wiki/




Commentaires :

Aucun commentaires pour le moment


Laissez un commentaire :

Réalisé par
Expaceo