Supervision des processus Planiware sous UNIX
Sous UNIX lorsqu’une instance Planisware (PLW) est démarrée un certain nombre de processus système apparaissent. Chaque module Planisware (Connect, Application Server ou Intranet Server, Dispatch, Timecard etc.) possède un certain nombre de processus et sous-processus qui lui est propre.
En exploitation il peut être intéressant de superviser ces processus unix pour détecter une éventuelle défaillance de l’un d’eux. Cet article présente d’une part les processus Planisware présent sur un serveur UNIX et d’autre part les stratégies de surveillance que l’on peut mettre en place pour une supervision efficace.
Description des processus PLW
Chaque module PLW a ses propres processus qui sont lancés au démarrage des services PLW :
→ Planisware Connect
Lors du démarrage d’un Planisware Connect plusieurs processus sont lancés :
→ 2 processus « Connect Launcher »
→ n processus « Connect Driver »
Processus liés au Connect
→ Planisware Dispatch
Lors du démarrage d’un Planisware Dispatch plusieurs processus sont lancés :
→ 2 processus « Dispatch Watchdog »
→ 1 processus « Dispatch »
Processus liés au Dispatch
→ Planisware Server
Lors du démarrage d’un Planisware Server (ou Intranet Server) c’est en réalité un processus Watchdog Intranet qui est lancé avec un certain nombre de paramètres qui vont déterminer le nombre de processus lancés :
→ Nombre d’IS
→ Mode Master/Slave ou standard
Prenons le cas d’un démarrage de 2 IS en mode Master/Slave. Dans ce cas on aura la séquence de processus suivante :
Processus liés aux Intranet Server
Tous les processus UNIX du Planisware Server dépendent du processus Watchdog Intranet.
Pour résumer on observe :
→ 1 processus père Watchdog
→ 1 processus fils Watchdog lié au premier.
Puis dans le cas d’un fonctionnement en Master/Slave avec n slaves :
→ 1 processus Intranet Server Master (lié au processus Watchdog fils)
→ n processus Intranet Server Slave (liés au processus IS Master, ces processus sont générés par image du processus IS Master)
Ou dans le cas d’un fonctionnement standard :
→ n processus Intranet Server Slave (liés au processus Watchdog fils mais indépendants entre eux)
→ Planisware Timecard
Comme pour le Planisware Server, lors du démarrage d’un Planisware Timecard c’est en réalité un processus Watchdog Timecard qui est lancé avec un certain nombre de paramètres qui vont déterminer le nombre de processus lancés :
→ Nombre d’IS
→ Mode Master/Slave ou standard
Prenons le cas d’un démarrage de 2 Timecard en mode Master/Slave. Dans ce cas on aura la séquence de processus suivante :
Processus liés au Timecard
Tous les processus UNIX du Planisware Timecard dépendent du processus Watchdog Timecard.
Pour résumer on observe :
→ 1 processus père Watchdog
→ 1 processus fils Watchdog lié au premier.
Puis dans le cas d’un fonctionnement en Master/Slave avec n slaves :
→ 1 processus Timecard Master (lié au processus Watchdog fils)
→ n processus Intranet Timecard Slave (liés au processus TC Master, ces processus sont générés par image du processus TC Master)
Ou dans le cas d’un fonctionnement standard :
→ n processus Timecard Master (liés au processus Watchdog fils mais indépendants entre eux)>
Stratégies de supervision
Afin de superviser les processus système d’une instance PLW sous UNIX on pourra monitorer la présence des processus ainsi que leur nombre.
→ Monitoring de la présence des processus :
Un premier niveau de supervision consiste à vérifier régulièrement la présence de chacun des processus lancés. Manuellement cela se traduit par vérifier que la commande suivante renvoie des processus.
Ce qui donne par exemple pour les processus intranet :
ps -ef | grep <
NOM_INSTANCE_PLW>/OPX2Modules/bin/*/opx2-intranet.exe
→ Monitoring du nombre de processus :
Le second niveau de supervision consiste à compter le nombre de processus présents par type de processus. Ceci est utile quand plusieurs IS ou Timecard sont lancés. Il s’agit de comparer le nombre de processus lancés sur le server à la valeur nominale que l’on doit avoir.
Ce qui donne par exemple pour 2 processus IS en Master / Slave :
ps -ef | grep <
NOM_INSTANCE_PLW>/OPX2Modules/bin/*/opx2-intranet.exe |wc -l
On devra avoir un résultat de 3. Si ce nombre est inférieur à 3 cela signifiera qu’un ou plusieurs IS seront hors service.
A l’inverse si ce nombre est supérieur à 3 cela pourrait traduire que des processus fantômes tournent sur le serveur. Si ces processus mobilisent de la RAM ou CPU cela entrainera une dégradation des performances globales de l’application. Cependant ces processus peuvent aussi être des « fork » des processus « normaux » générés par Planisware pour éviter de surcharger une instance. Il n’est donc pas possible de différencier facilement un processus non utilisé d’un processus forké.
On se contentera donc de vérifier que le nombre de processus est bien supérieur ou égal au nombre de processus nominal. Cette vérification pourra être faite pour chaque type de processus et pour chaque instance Planisware présente sur le serveur.
Enfin la supervision présentée ici est purement technique et ne remplace pas une supervision applicative « fonctionnelle » qui permet de s’assurer que l’application est effectivement disponible. Pour cette dernière on pourra mettre en place une surveillance via un ping applicatif.