applications:cemu:serveur:surveillance_serveur:zabbix_tableau_de_bord_ecampus

Tableau de bord Zabbix pour Ecampus

Les indicateurs ayant changé coté serveur, cette page serait à réactualiser.

Le tableau de bord a dorénavant plusieurs pages :

Pour plus de détails sur nos paramètres (pas leurs valeurs, mais leur origine), voir les explications dans la page zabbix
Pour apprécier les valeurs dans les graphiques quand elles ne sont pas très parlantes, il est possible de dézoomer l'échelle des temps pour connaitre les valeurs usuelles à d'autres périodes.

Cette page regroupe les graphique à caractère applicatif (haut niveau).

Cela permet d'avoir une vue sur les aspects suivant.

  • Nb connections Moodle : correspond au paramètre personnalisé moodle.connexions
  • Nb utilisateurs en ligne Moodle : correspond au paramètre personnalisé moodle.utilisateurs

Pour information, 300 connexions (par 5 minutes) correspondent en moyenne à une nouvelle connexion chaque seconde. C'est à peu près le niveau moyen en période de rentrée.

Un exemple classique :

Le nombre d'utilisateurs en ligne (qui ont fait au moins une action dans les 5 dernières minutes) est classiquement à peu près le double du nombre de connexions.

  • moodle response time : correspondent aux paramètres personnalisés
    • phpmoodledb.responsetime
    • moodle.responsetime

Cette information s'avère dans la pratique peu pertinente. Les chiffres oscillent classiquement autour de 200 à 500ms avec des pointes fréquentes au delà de la seconde. Les valeurs sont très instables.

Cette page essaie de rendre compte de la santé du service de base de données.

Ne pas oublier que le service de base de données est commun à toutes nos plateformes.

Les indicateurs les plus importants sont :

  • MySQL operations : en kqps (Kilo Queries Per Second) qui donne une vue du niveau d'activité du service. Pendant les périodes de confinement nous avons assez souvent atteint 50 à 60 kpqs, et exceptionnellement et très ponctuellement presque 100 kqps (100 000 requêtes par secondes).
  • Mysql Active Queries Count : il s'agit du nombre de requêtes qui s'exécutent simultanément. Il y en a généralement une poignée. La courbe doit être très accidentée. Si au contraire elle montre une hausse continue, c'est que l'une d'elle a bloqué les autres, qui ne peuvent alors pas se finir et s'accumulent. Il faut intervenir (depuis un client SQL, tuer la requête fautive en la repérant à son ancienneté plus grande)
  • MySQL slow queries per second : compte le nombre de requête qui ont mis un certain temps seuil pour s'exécuter. La valeur retournée est le pourcentage que ces longues requêtes représentent au regard des milliers de requêtes exécutées chaque seconde. Ce chiffre doit être très très faible et ne jamais s'approcher de son maximum à 1 (jamais détecté jusqu'à présent)

Un exemple avec des valeurs correctes :

Les indicateurs sont les indicateurs système standard, notamment :

  • Memory usage : ce paramètre est un des plus important pour mariadb. Ses performances dépendent beaucoup de la mémoire vive. Le serveur a été fortement doté (64Go de RAM actuellement). Mariadb en consomme la plus grosse partie (actuellement plus de 40 Go). Si la la partie available memory est trop faible (1 ou 2 Go ou moins par exemple), le service mariadb sera impacté.

Un exemple correct :

  • CPU utilization : charge du processeur, ne doit en théorie pas dépasser 100% (charge maximale)
  • Disk … utilisation : espace présent (Total space) et utilisé (Used space) sur différents espaces de stockage. Il doit rester quelques Go non utilisés sur / et beaucoup plus sur les autres montages qui accueillent de très gros fichiers de plusieurs dizaines de Go. Actuellement nous avons près d'1To sur le plus petit.

Cette partie explore tous les serveurs web du pool (répartition de charge oblige).

Il y a une ligne pour chaque serveur du pool.

De gauche à droite :

  • Apache thread scorebord : montre l'état des différentes connexions http sur le serveur web Apache. Il doit y avoir un maximum de connexions disponibles (état OpenSlotWithNoCurrentProcess), en pratique beaucoup de violet, sinon cela signifie qu'Apache est en train de se faire submerger par des demandes qu'il n'arrive pas à satisfaire (généralement parce que les éléments dont il dépend, php, mariadb, ne répondent pas comme il faut). Ci dessous un exemple de l'affichage attendu, la majorité des 500 connexions dispos sont dispos.

  • Php-fpm active processes : correspond au paramètre phpfpm.activeprocesses. Actuellement pour Ecampus, php-fpm peut utiliser jusqu'à 60 processus par serveur. Quand ce chiffre est atteint et qu'un plateau apparait sur la courbe, c'est que php ne parvient plus à réaliser l'ensemble des traitements qui lui sont demandé par Apache. Il sature.
  • Autres paramètres système, à apprécier comme dans la page BDD, mais ATTENTION, les ressources des conteneurs LXC qui hébergent nos serveurs sont partagées avec leur machine physique. Les ressources sont mutualisées avec l'ensemble des containers sur le même hôte. La sur-utilisation d'une ressource vient généralement d'un autre conteneur sur la machine physique. Ces informations sont donc peu pertinentes sauf à expliquer les difficulté d'un serveur du pool qui aurait la malchance de se trouver sur un hôte surchargé.
    • CPU utilization : ne doit pas dépasser 100%
    • disk / utilisation : quelques Go suffisent car les fichiers Moodle sont ailleurs dans des montages NFS partagés (faire df -h sur 1 serveur pour voir la liste des montages)
    • disk /media/vdata_ecampus utilisation : doit contenir de l'espace libre car c'est ici que sont justement stockés les fichiers Moodle. Le sous-dossier moodledata/ est très très gros 1) car il accueille tous les fichiers multimédia. Pour ne pas saturer vite, il doit disposer de plusieurs centaines de gigaoctets disponibles.

  • Apache voit une envolée des connexions en mode Sending Reply (en vert clair), signe que ces connexions ne parviennent pas à terminer l'envoi de leur réponse au visiteur, certainement parce que les connexions php ne retournent pas leurs réponse non plus
  • php-fpm a toutes ses connexions actives (les 60), ce qui ne devrait pas et l'empêche de répondre à toute nouvelle demande

… A documenter plus.

Le principal indicateur à regarder est Instantaneous operations per sec.. Il montre le nombre de requêtes auxquelles chaque serveurs du pool Redis répond.

Cela permet de

  • rapidement voir qu'elle est le serveur du pool qui est maître (celui qui fait le plus d'opérations) ;
  • vérifier que le service Redis est sollicité (ce n'est plus le cas s'il y a une erreur de configuration Moodle qui lui fait perdre son cache Redis par exemple)
Sans cache Redis opérationnel Moodle perd tellement en performance, qu'il devient inaccessible rapidement !

Un exemple concret le 18 aout (donc en période d'activité faible) qui montre que lecampus-redis3 est le maitre :

Voir https://www.datadoghq.com/blog/how-to-monitor-redis-performance-metrics/

Les 3 dernières lignes regroupent les indicateurs machine habituels, à raison d'une ligne par serveur.


1)
2.9 To le 18 aout 2022
  • applications/cemu/serveur/surveillance_serveur/zabbix_tableau_de_bord_ecampus.txt
  • Dernière modification: il y a 8 semaines
  • de dumontj01