Comment solutionner les pertes de monitoring?

Résumé

Le monitoring des capteurs de la station est géré par plusieurs applications Java, en relation avec les Bases De Données (BDD) des Services de la station Euler.

Le processus de mise à jour de la BDD consiste à extraire les informations récentes de l'ensemble des fichiers Services (format ASCII, RDB) et les enregistrer dans les tables des BBDs Euler (format PostgreSQL) avec l'utilitaire Meulup.

Il y a une BDD à La Silla et une à Genève. Celle de Genève lit la version synchronisée des fichiers de Services.

Celle de La Silla est utilisée par Meul qui affiche le monitoring des senseurs sur un écran dédié et celle de Genève est utilisée par Meulreport afin de générer un rapport journalier qui est envoyé par email aux personnes intéressées.

Les 2 bases permettent le tracé des données en local avec l'utilitaire Meulplot.

En résumé il y 2 jeux identiques de fichiers de Services et 2 BDDs PostgreSQL.

Les problèmes liés au monitoring sont multiples, mais la stratégie de debugging est unique.

Les problèmes courant sont les suivants:

Le mail journalier n'est pas reçu (Meulreport)
Le mail journalier contient beaucoup de Services avec des pertes de mesures sur les dernières heures (ou plus)
Affichage dans la station (Meul) avec plusieurs services grisé (values too old)

Ce document décrit les étapes pouvant conduire au solutionnement de ces problèmes

Investigation

Avant tout chose il faut avoir l'accès root sur les machines de La Silla (voir t4-support) et sur la machine de transfert de l'observatoire côté Genève (voir Nicolas Buchschacher, Luc Weber) si une action est à entreprendre.

La suite des opérations dans cette investigation relève de l'expérience dans ce genre de problème. Donc pas de conseil sinon celui de vérifier chaque point.

Il faut savoir qu'il y a de très fortes chances pour que le problème à La Silla et à Genève ait la même cause. Donc très certainement la solution nécessitera une seule correction et 2 resets.

Le processus de mise à jour des BDDs est lancé par des crons: sous weber sur glsmonitor, sous trmgr sur obstr01. Le processus se nomme Meulup.jar

Idéalement, il faut comprendre le problème sur obstr01, prendre les actions adéquates sur La Silla pour solutionner le problème et relancer/reseter la mise à jour des services sur glsmonitor et sur obstr01.

Mise à part les cas d'éléments en panne on peut diviser les problèmes en 2 groupes:

Les processus bloqués
Les fichiers corrompus

Verification des fichier de log

Le log du dernier et uniquement du dernier lancement de Meulup est sous

La Silla: /home/weber/Meulup.log

obstr01: /home/trmgr/MONEULER/Meulup.log

Ils sont certainement incompréhensibles, mais les dernières lignes orientent vers le problème. Le nom du dernier service traité est important. Si le processus est planté pour cause de manque de mémoire, alors on passe au point suivant, car cela signifie qu'il y a trop de processus bloqués et que le log n'a pas d'informations relevantes.

Test de processus bloqués

Des processus bloqués vont générer le problème.

Sur glsmonitor et sur obstr01, on peut tester les mise à jour bloquées, dans ce cas il faut lancer

ps -ef

Si on voit une succession de processus bloqués avec le nom Meulup.jar (et rsync sur obstr01), le problème vient de là, mais la source n'est pas connue.

Dans ce cas il faut taper (sur les 2 machines)

pkill -f Meulup.jar

Ceci tue les processus bloqués, mais ils vont à nouveau s'accumuler. Par contre cela à l'avantage de libérer de la mémoire afin de pouvoir les relancer.

S'il n'y a pas ce type de problème, alors le problèmes vient peut-être de glsserv. Il faut donc tester les processus sur cette machine

glsserv# ps -ef

S'il y a également des processus bloqués, il est important de savoir lequel et ainsi remonter à la source du problème.

Il est possible, en cas de situation catastrophique, de simplement rebooter glsserv!

Il est préférable de rebooter glsserv hors observation, dans le cas où le reboot se passe mal et bloque les observations. Avec l'accord de l'observateur les choses peuvent être faite avec plus de sérénité! On reboot glsserv avec la commande:

 T_reboot_lcu glsserv

Relancer Meulup.jar afin de voir s'il le problème vient de là

Meme s'il n'y avait pas processus bloqué, il est intéressant de relancer Meulup.jar pour s'assurer qu'il passe sans problème ou voir des messages de warning.

Attention, Meulup est lancé sur obstr01 toutes les 5,15,25, 35, 45, 55 minutes de l'heure, ainsi évitez de lancer la commande moins d'une minute avant ces moments.

Sur glsmonitor, toutes les 2 minutes avec le même conseil.

Donc avec ou sans blocage décoincé, on lance, sur obstr01:

java -Xmx1024m -jar /home/trmgr/MONEULER/Meulup.jar

Et à La Silla:

java -Xmx1024m -jar /home/weber/Meulup.jar

Dans le cas d'erreur, noter le nom du dernier service traité et si possible comprendre/noter l'erreur.

Test de l'integrité des fichier Service

Dans des cas exceptionnels, liés à des problèmes hardware, panne, perte de connexion reseau, etc... Les fichiers de service (RDB) peuvent être corrompus, cela se traduit la plupart du temps par un mauvais nombre de colonnes dans un fichier service.

Un fichier corrompu provoque l'arrêt de l'introduction des données dans la base de données, normalement pour un seul service, mais pas forcement. Donc un trou dans les données depuis un moment donné jusqu'à moment présent.

Il faut savoir que le directory $TDATA/services/CURRENT/ contient les links vers l'ensemble des fichiers de service en usage (généralement 1 par mois). Ainsi le test des fichiers se fait ici. Il est clair qu'au changement de mois la situation peut s'avérer plus compliquée, mais le principe est le même, il faut dans ce cas chercher les fichiers plus ancien dans le directory $TDATA/services/.

On utilise la commande check de rdb (StarBase) qui indique au moins une partie des problèmes. Séquence:

tcsh
cd $TDATA/services/CURRENT/
foreach i (*.rdb)
  echo $i
  check < $I
end

Les problèmes potentiels s'afficheront.

Correction des fichiers de services

Uniquement si l'étape précédente a montré des erreurs.

La correction se fait avec un simple éditeur, mais comme la plupart des mises à jour des fichiers Service RDB se fait toutes les minutes, voir toutes les 12 secondes pour Necam, il faut agir en conséquence pour ne pas être en train d'éditer lorsque le Service est mis à jour!

Si l'édition est rapide, on peut le faire sans autre, si non, il est de loin préfeerable de stopper le Service, éditer le fichier, relancer le Service. Il est absolument nécessaire de stopper/relancer le service Necam (car trop fréquent) selon la méthode décrite ici:.

Arrêt du service NECAM (pas nécessairement sous root) avec:

ssh glsserv
touch /tmp/INIB_SERVICE_NECAM

éditer le fichier de Service Necam et redémarrer le service avec:

rm /tmp/INIB_SERVICE_NECAM

Remarque: seul le service Necam a cette possibilité d'arrêt!

Pour les autres services:

Dans le cas d'un edition rapide: ma technique est la suivantes: utiliser nedit sous root. Nedit à l'avantage de d'afficher un popup lorsque le fichier est modifié (par le service) et permettre de le recharger, ce qu'il faut absolument faire quitte à perdre une correction faite trop lentement. Ainsi personnellement je clique sur le fichier jusqu'au moment où le popup s'affiche, à ce moment je choisi l'option de recharger le fichier qui est maintenant à jour et j'ai une minute pour faire la modification et surtout sauver le fichier avant la mise à jour suivante.

Si on ne peut pas rapidement faire l'edition: alors il faut stopper le service concerné. la plupart des services tournent sur glsserv. Pour arrêter un service il faut se loger sous root sur glsserv.

Exemple pour une édition du service c2_temp:

ssh glsserv
su
[root@glsserv]# crontab -l | grep services
0 12 * * *    /opt/t4/beta/scripts/services
...

[root@glsserv]# grep c2_temp /opt/t4/beta/scripts/services 
( /opt/t4/beta/scripts/service_c2_temp 60& )

[root@glsserv]# ps -ef | grep c2_temp
root     11285     1  0 May03 ?        00:00:00 /bin/csh -f /opt/t4/beta/scripts/service_c2_temp 60
...

[root@glsserv]# kill -9 11285

A ce moment on peut entreprendre l'édition du fichier de Service c2_temp.rdb (notre exemple) sur une autre machine (qui a X11) et sous root.

Il faut verifier à nouveau que les fichiers de Services ne sont plus corrompus en répétant les checks du point précédent. Inutile de continuer si les corrections ci-dessus n'ont pas solutionné le problème. En effet il peut arriver qu'il y avait plusieurs zones à éditer et qu'on en ait corrigé qu'une.

Une fois que les checks sont passés avec succès, on relance le service selon les informations obtenues ci-dessus (en background), exemple:

[root@glsserv weber]# /opt/t4/beta/scripts/service_c2_temp 60 &

Le service repart, on patiente le temps que le fichier de service se mette à jour. Attention du à NFS, la mise à jour se voit avec un décalage sur tout autre machine que glsserv. Ainsi 2 solutions selon la machine:

Sur un gls:

tail -f $TDATA/services/CURRENT/c2_temp.rdb

Sur glsserv:

tail -f /export/diskA/services/c2_temp/c2_temp_202005.rdb (mettre le mois courant!)

Verification du redémarrage des Services

Il est à ce moment possible de vérifier la dernière ligne de chaque fichier Service qui doit montrer un tunix d'actualité (à part temperature_telescope qui ne se rempli que durant l'observation) avec par exemple:

cd $TDATA/services/CURRENT/
tail -n 1 *.rdb

il faut savoir que le tunix est dans la 1ere colonne et que le tunix courant s'obtient avec la commande:

date +%s

Vérification de la mise à jour des BDDs

Une fois certain que tout est correct, il faut vérifier que les BDDs sont à jour.

Il faut reprendre les points en début de documents et s'assurer qu'il n'y a pas de processus bloqué.

Si on n'arrive pas à remettre les machine dans un état standard, c'est à dire où l'on voit avec un "ps -ef" que la liste des process semble correcte, c'est à dire sans commandes existant à plusieurs exemplaire avec un parent PID inconnu ("?"), il peut être plus simple de rebooter la machine incriminée.

glsmoniteur peut être rebooté n'importe quand avec la commande:

T_reboot_servers glsmonitor

Normallement on doit réussir à tuer tout les process bloqués sur obstr01, si toutefois un reboot est nécessaire, il faut s'adresser à Nicolas Buchschacher.

Une fois la situation nominale atteinte, il est nécessaire de vérifier que les données soit à jour.

Plusieurs solutions, mais il faut garder à l'esprit que les BDDs sont mise à jour toutes les 2 minutes sur glsmonitor et toutes les 10 minutes (avec offset 5 minutes) sur obstr01.

Les crons (sous weber sur glsmonitor, sous trmgr sur obstr01) montre les commandes permettant de faire une mise à jour (incluant la synchronisation sur Geneve) immédiate.

Moyens de tests:

lancer meulplot sur glslogin1 sous x2Go et vérification visuelle
lancer meul sur glslogin1 sous x2Go et vérification des dates
lancer meulreport sur obstr01 (sous trmgr) en mode "local" sans mail
lancer meulreport sur obstr01 (sous trmgr) avec lancement de mail

Le cron de trmgr@obstr01 montre comment lancer meulreport:

Avec mail:

java -Xmx512m -jar /home/trmgr/MONEULER/Meulreport.jar MONEULER

Sans mail:

java -Xmx512m -jar /home/trmgr/MONEULER/Meulreport.jar

Le mail de monitoring (lancé par Meulreport) est lancé tout les jours à 8h06.

Si la remise en marche des services par l'utilisation des moyens ci-dessus permet d'envoyer un mail corrigé plus à jour ou simplement le mail manquant, il faut le faire.

Points d'intérêts

Contrôleurs serie

Les contrôleurs de lignes series (Moxa Nport) peuvent présenter des problèmes, ainsi un rebboot de ceux-ci peut s'avérer nécessaire, les lignes/controlleurs sont listés dans ce fichier, un reboot d'un Moxa se fait avec un navigateur sur l'URL du contrôleur puis un click sur le bouton Submit de l'onglet Save/Restart.

A éviter lors des observations, et absolument vérifier que les services repartent.

Fichier RDB sans header

Le fichier de service se rempli, mais il n'a pas de header. C'est un bug, et ce cas nécessite un édition de fichier selon la technique exposée ci-dessus.

Il suffit de récupérer un header dans un des fichiers du même service d'un mois précédent, Surtout bien verifier après l'edition que le check de l'intégrité passe correctement.

Fichier RDB sans données

Meulup.jar n'accepte pas de fichier vide (ce problème est un bug à corriger!) .

Si tel est le cas, certainement le premier jour d'un mois, on a un header complet (2 lignes), mais pas de données.

Dans ce cas il faut ajouter une ligne de données, le plus simple est de copier la dernière ligne du fichier du même service du mois précédent en ajustant le tunix d'une seconde.

Erreur de duplication d'identificateur dans le log Meulup.jar

L'identificateur de record dans les BDD PostgreSQL est le tunix et on ne peut pas enregistrer des information différentes sous un même ID.

Un cas est arrivé (durant le confinement 2020) où le seeing monitor à envoyé durant plus d'un mois la même ligne de donnée. Visiblement Meulup réagit mal à cela, c'est à dire avoir 2 tunix identiques dans 2 fichier mensuels différents (bug à corriger).

La solution à consisté à supprimer les lignes avec tunix identiques (et des données stupides) dans les fichiers rdb, changer le tunix (d'une seconde) dans le dernier fichier mensuel et finalement commenter la ligne lançant le service seeing dans le fichier (root (ou weber) dans $THOME/scripts/services pour ne plus lancer cette commande durant la durée du mauvais fonctionnement du seeing monitor.

LW 04/05/2020