Surveillance d'un serveur de bases (MySQL, MS SQL, ODBC)

Le programme surveille les bases MS SQL, MySQL et ODBC du réseau.

Les contrôles “MS SQL Server”, “MySQL” et “ODBC” suivent l'état du SGBD correspondant et alertent en cas de dysfonctionnement. Le contrôle tente périodiquement de se connecter avec les paramètres d'authentification indiqués. Si le SGBD accepte la connexion, le contrôle réussit.

Le programme peut aussi exécuter des requêtes SQL, lire le résultat et analyser les valeurs renvoyées.

La bibliothèque cliente libmySQL.dll est nécessaire au contrôle “MySQL”. Une version est fournie avec l'application. Elle peut se trouver dans le dossier Windows ou dans le dossier de l'application.

Le contrôle “MS SQL Server” exige la partie cliente de ce SGBD. L'application accepte l'authentification Windows et une authentification par identifiant et mot de passe.

 

Configurer la surveillance d'une base (exemple MySQL)

La surveillance de l'état de la base vise à maintenir ses performances et sa disponibilité. Elle contrôle des paramètres et des métriques du SGBD, et détecte les erreurs de fonctionnement.

Voici quelques métriques de base pour juger l'état de la base, avec 10-Strike Network Monitor et MySQL comme exemple.

1. Disponibilité et durée de fonctionnement

La disponibilité se vérifie par une connexion depuis des hôtes distants. Une erreur peut indiquer l'arrêt du service ou le blocage du port par un autre programme.

Le paramètre uptime révèle les redémarrages rapides, que le simple test de disponibilité peut manquer. Il mesure depuis combien de temps la base tourne sans incident. Vous pouvez par exemple alerter lorsque

uptime < 1800

où 1800 est la durée de fonctionnement en secondes depuis le dernier démarrage.

2. Erreurs de connexion

Les erreurs de connexion des nouveaux clients sont un problème courant. La métrique Nombre d'erreurs de connexion repère les périodes où elles deviennent trop fréquentes. Elle regroupe les variables d'état MySQL suivantes (counters):

• Connection_errors_accept
  Nombre d'erreurs lors des appels accept() sur le port d'écoute.
• Connection_errors_internal
  Nombre de connexions refusées à cause d'une erreur interne, par exemple l'échec de création d'un thread ou un manque de mémoire.
• Connection_errors_max_connections
  Nombre de connexions refusées parce que la limite max_connections du serveur est atteinte.
• Connection_errors_peer_address
  Nombre d'erreurs lors de la résolution de l'adresse IP du client qui se connecte.
• Connection_errors_select
  Nombre d'erreurs lors des appels select() ou poll() sur le port d'écoute (l'échec de cette opération ne signifie pas toujours que la connexion du client a été refusée).
• Connection_errors_tcpwrap
  Nombre de connexions refusées par libwrap.

Si max_connections est mal réglé, la base peut refuser un grand nombre de connexions simultanées et le compteur Connection_errors_max_connections augmente. Surveillez le rapport entre les connexions actuelles et le maximum, avec cette requête :

SELECT ROUND(100 - (100 * Variable_value / [max_connections]), 0) as tc FROM sys.metrics where Variable_name = 'threads_connected'

Remplacez [max_connections] par la valeur réelle du paramètre max_connections (100 par défaut). Vous l'obtenez dans la console MySQL :

show variables like "max_connections";

La commande renvoie un résultat de ce type :

La variable tc indique le pourcentage de connexions encore disponibles. Le seuil peut être fixé à 30 %.

 

3. Requêtes lentes

MySQL tient un journal des requêtes lentes. Le nombre d'entrées se lit avec la métrique slow_queries, par une requête SQL simple :

SELECT Variable_value FROM sys.metrics where Variable_name = 'slow_queries'

Le programme peut signaler les nouvelles entrées de ce journal, souvent le signe d'un problème de performance.

 

4. Requêtes de jointure

Les compteurs d'exécution des jointures signalent les opérations qui consomment trop de ressources.

• Select_full_join
  Nombre de jointures qui parcourent les tables faute d'index. Si la valeur n'est pas 0, vérifiez les index.
• Select_full_range_join
  Nombre de jointures qui ont utilisé une recherche par plage dans la table de recherche.
• Select_range_check
  Nombre de jointures sans clé qui vérifient l'usage d'une clé après chaque ligne. Si la valeur n'est pas 0, vérifiez les index.
• Select_scan
  Nombre de jointures qui ont parcouru entièrement la première table.
• Select_range
  Nombre de jointures qui ont utilisé des plages dans la première table. Ce n'est en général pas critique, même si la valeur est élevée.

 

5. Taux de succès du cache

MySQL utilise un cache en mémoire pour limiter les lectures et écritures disque. Un taux de succès faible dégrade les performances. Cette requête calcule le taux pour les tables ouvertes :

SELECT ROUND((open_cache_hits / (open_cache_hits + open_cache_misses)), 2) * 100 OpenTableFactor FROM (SELECT variable_value open_cache_misses FROM sys.metrics WHERE variable_name = 'table_open_cache_misses') miss, (SELECT variable_value open_cache_hits FROM sys.metrics WHERE variable_name = 'table_open_cache_hits') hits;

Fixez le seuil OpenTableFactor à 90 %. En dessous, le programme vous prévient.

 

6. Durée d'exécution d'une requête

La durée d'exécution d'une requête est un autre indicateur de dégradation. Écrivez une requête de test et mesurez-la en conditions normales. Cette valeur sert de seuil. Un dépassement durable indique une base très chargée, dont les utilisateurs attendent longtemps la réponse.

 

MySQL expose de nombreuses métriques pour évaluer l'état de la base. La plupart se trouvent dans les tables système INFORMATION_SCHEMA (sys), accessibles en lecture. Le programme exécute des requêtes arbitraires, ce qui permet une large gamme de contrôles de performance.

 

Voir aussi : Surveillance d'un serveur HTTP (web) et du contenu des pages, Surveillance d'un serveur FTP

 

Configuration requise : Windows XP/Vista/7/8.1/10/11, Server 2003/2008/2012/2016/2019/2022.