Dans cet article


Offres d'emploi

Tags

Supervision des processus Planiware sous UNIX

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 »

<p>
  <div id="attachment_585" >
    <a href="http://blog.axopen.com/wp-content/uploads/2012/02/dispatch.jpg"><img aria-describedby="caption-attachment-585" class="size-full wp-image-585" title="Processus liés au Dispatch" src="http://blog.axopen.com/wp-content/uploads/2012/02/dispatch.jpg" alt="" width="229" height="322" srcset="/2012/02/dispatch.jpg 286w, /2012/02/dispatch-213x300.jpg 213w" sizes="(max-width: 229px) 100vw, 229px" /></a>

    <p id="caption-attachment-585" class="wp-caption-text">
      Processus liés au Dispatch
    </p>
  </div>
</p>

<p >
  </blockquote> 

  <ul>
    <li>
      <em><strong>Planisware Server</strong></em>
    </li>
  </ul>

  <p >
    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 :
  </p>

  <blockquote>
    <ul>
      <li>
        Nombre d’IS
      </li>
      <li>
        Mode Master/Slave ou standard
      </li>
    </ul>
  </blockquote>

  <p >
    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 :
  </p>

  <p>
    <div id="attachment_586" >
      <a href="http://blog.axopen.com/wp-content/uploads/2012/02/intranet.jpg"><img aria-describedby="caption-attachment-586" class="size-full wp-image-586" title="Processus liés aux Intranet Server" src="http://blog.axopen.com/wp-content/uploads/2012/02/intranet.jpg" alt="" width="540" height="508" srcset="/2012/02/intranet.jpg 600w, /2012/02/intranet-300x282.jpg 300w" sizes="(max-width: 540px) 100vw, 540px" /></a>

      <p id="caption-attachment-586" class="wp-caption-text">
        Processus liés aux Intranet Server
      </p>
    </div>
  </p>

  <p >
    <p >
      Tous les processus UNIX du Planisware Server dépendent du processus Watchdog Intranet.
    </p>

    <p >
      Pour résumer on observe :
    </p>

    <blockquote>
      <ul>
        <li>
          1 processus père Watchdog
        </li>
        <li>
          1 processus fils Watchdog lié au premier.
        </li>
      </ul>
    </blockquote>

    <p >
      Puis dans le cas d’un fonctionnement en Master/Slave avec n slaves :
    </p>

    <blockquote>
      <ul>
        <li>
          1 processus Intranet Server Master (lié au processus Watchdog fils)
        </li>
        <li>
          n processus Intranet Server Slave (liés au processus IS Master, ces processus sont générés par image du processus IS Master)
        </li>
      </ul>
    </blockquote>

    <p >
      Ou dans le cas d’un fonctionnement standard :
    </p>

    <blockquote>
      <ul>
        <li>
          n processus Intranet Server Slave (liés au processus Watchdog fils mais indépendants entre eux)
        </li>
      </ul>
    </blockquote>

    <ul>
      <li>
        <em><strong>Planisware Timecard</strong></em>
      </li>
    </ul>

    <p >
      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 :
    </p>

    <blockquote>
      <ul>
        <li>
          Nombre d’IS
        </li>
        <li>
          Mode Master/Slave ou standard
        </li>
      </ul>
    </blockquote>

    <p >
      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 :
    </p>

    <p>
      <div id="attachment_590" >
        <a href="http://blog.axopen.com/wp-content/uploads/2012/02/timecard.jpg"><img aria-describedby="caption-attachment-590" class="size-full wp-image-590" title="Processus liés au Timecard" src="http://blog.axopen.com/wp-content/uploads/2012/02/timecard.jpg" alt="" width="540" height="536" srcset="/2012/02/timecard.jpg 600w, /2012/02/timecard-150x150.jpg 150w, /2012/02/timecard-300x298.jpg 300w, /2012/02/timecard-36x36.jpg 36w, /2012/02/timecard-115x115.jpg 115w" sizes="(max-width: 540px) 100vw, 540px" /></a>

        <p id="caption-attachment-590" class="wp-caption-text">
          Processus liés au Timecard
        </p>
      </div>
    </p>

    <p >
      <p >
        Tous les processus UNIX du Planisware Timecard dépendent du processus Watchdog Timecard.
      </p>

      <p >
        Pour résumer on observe :
      </p>

      <blockquote>
        <ul>
          <li>
            1 processus père Watchdog
          </li>
          <li>
            1 processus fils Watchdog lié au premier.
          </li>
        </ul>
      </blockquote>

      <p >
        Puis dans le cas d’un fonctionnement en Master/Slave avec n slaves :
      </p>

      <blockquote>
        <ul>
          <li>
            1 processus Timecard Master (lié au processus Watchdog fils)
          </li>
          <li>
            n processus Intranet Timecard Slave (liés au processus TC Master, ces processus sont générés par image du processus TC Master)
          </li>
        </ul>
      </blockquote>

      <p >
        Ou dans le cas d’un fonctionnement standard :
      </p>

      <blockquote>
        <ul>
          <li>
            n processus Timecard Master (liés au processus Watchdog fils mais indépendants entre eux)
          </li>
        </ul>
      </blockquote>

      <p>
        &nbsp;
      </p>

      <p>
        <span ><strong>Stratégies de supervision :</strong></span>
      </p>

      <p>
        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.
      </p>

      <ul>
        <li>
          Monitoring de la présence des processus :
        </li>
      </ul>

      <p >
        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.
      </p>

      <p >
        Ce qui donne par exemple pour les processus intranet :
      </p>

      
ps -ef | grep <
NOM_INSTANCE_PLW>/OPX2Modules/bin/*/opx2-intranet.exe
<ul> <li> Monitoring du nombre de processus : </li> </ul> <p > Le second niveau de supervision consiste à compte 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. </p> <p > Ce qui donne par exemple pour 2 processus IS en Master / Slave : </p>
ps -ef | grep <
NOM_INSTANCE_PLW>/OPX2Modules/bin/*/opx2-intranet.exe |wc -l
<p > 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. </p> <p > 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é. </p> <p > 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. </p> <p > Enfin la supervision présentée ici est purement technique et ne remplace pas une supervision applicative « fonctionnelle » qui permet de s&rsquo;assurer que l&rsquo;application est effectivement disponible. Pour cette dernière on pourra mettre en place une surveillance <span >via un ping applicatif</span></a></span>. </p>

L'équipe AXOPEN

Voir aussi les articles suivants

Description  Lorsque l’on utilise l’outil standard d’export Excel dans une application sous P5 SP1 en client léger on peut observer un comportement anormal. Le fichier xls est bien généré sur par le serveur Planisware mais au lieu d’afficher le fichier dans Excel sur le poste client une popup s’ouvre et se referme instantanément sans rien afficher. Ce comportement est constaté uniquement sur les navigateurs Internet Explorer 7 (voire plus anciens).
Lire l'article

Description  Afin d’automatiser l’arrêt-relance du progiciel P5 on peut utiliser OPX Services Scheduler qui fonctionne sur toutes les plateformes. Sur les serveurs UNIX, on peut être amené à utiliser la fonctionnalité CRONTAB pour gérer les arrêt-relances de l’application (en particulier sur des environnements de test ou de recette). Si l’on programme l’arrêt-relance de P5 dans la crontab de l’utilisateur « root » en exécutant les scripts d’arrêt-relance standard P5 « stop-opx2 » et « start_opx2 » on ne rencontrera pas de problème particulier.
Lire l'article

Les fichiers de log P5

Les fichiers de log P5

Le 28/07/2011 par Thibault Gonin

Il peut être utile de connaitre le rôle des différents fichiers traçant l’activité des différents composants de P5 (Intranet Server, Dispatch, Connect…). La bonne connaissance de ces fichiers de log, de leur localisation et de la manière dont ils sont générés va permettre un meilleure exploitation et maintenance du progiciel P5. Localisation En standard, les logs P5 sont accessibles sous le répertoire « …\OPX2HttpRoot\admin\log » de la machine qui héberge l’application.
Lire l'article