Pandora: Documentation fr: Supervision procedures commerciales

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’Indice de Documentation Pandora FMS

1 Supervision de procédures commerciales

1.1 Introduction

Pandora FMS intègre depuis sa version 7, la possibilité de surveiller des procédures commerciales.

Le composant du serveur transactionnel implémenté dans cette version permet d’exécuter des tâches dépendantes les unes des autres en suivant un modèle défini par l’utilisateur. Cela signifie qu’il est possible de coordonner différentes exécutions pour vérifier un objectif en un temps déterminé.

Prenons par exemple un cas pratique. Il pourrait consister à réaliser le suivi d’une commande qui passera par différentes phases, en pouvant contrôler le temps pour chacune des étapes, dans chaque service :

Trans sq.png


Il nous définira un graphique de 4 étapes. Pandora FMS utilisera ce graphique avec une série de script de contrôle pour surveiller le processus précédent indiqué, en montrant visuellement l’état dans lequel se trouve, à tout instant, chacune des parties qui constituent notre procédure commerciale.

Ci-après, nous verrons comment surveiller entièrement un processus transactionnel.

1.2 Fonctionnement

Nous définirons une transaction << comme un ensemble d’étapes qui constituent une tâche plus complexe. Nous appellerons ces étapes des “phases”.

L’ensemble des phases et leur flux de travail (relations de dépendances) définiront un “graphique transactionnel”.

Pandora FMS, en se basant sur le graphique transactionnel, lancera un ordre d’exécution de scripts de contrôle dans chacun des phases précédentes définies. Ces scripts de contrôle réaliseront les tâches de surveillance de cette phase.

Les points les plus courants à vérifier dans les scripts de contrôle qui peuvent nous fournir des informations sur l’état de notre transaction sont :

  • Entrées dans les fichiers de log.
  • Présence d’archives temporaires.
  • Consultations directes aux bases de données.
  • Existence de courriers dans les boîte de réception.

Le système transactionnel est distribué, en pouvant déployer autant “d’agents transactionnels” que nous le souhaitons. Le serveur de Pandora FMS se chargera de communiquer avec ces agents en leur indiquant les étapes à suivre et quand ils doivent exécuter un script de contrôle.

1.3 Configurer une transaction

Pour configurer et réaliser correctement un processus de surveillance transactionnel, il faudra :

  • Une analyse préalable de la procédure commerciale à surveiller :
    • Flux de travail.
    • Points impliqués.
    • Scripts de contrôle.
  • Déployer des agents transactionnels dans les équipements concernés, afin de contrôler le flux d’informations.
    • Le développement et le déploiement des scripts de contrôle dans les agents transactionnels nécessaires.
    • Configuration des agents transactionnels.
  • A partir de la console de Pandora FMS, créer la transaction en y inscrivant les données dans les formulaires.

1.3.1 Analyse préalable

Nous allons réaliser une analyse courante :

Notre transaction débute lorsque l’on reçoit une commande dans la machine “Portail”. Nous devrons donc déployer un agent transactionnel dans “Portail” ou bien dans une machine capable de réaliser des consultations à distance. Lors de cette première phase, un script critique sera exécuté, c’est le “déclencheur de transaction”.

Dans l’étape suivante de notre transaction, un processus de traitement de la commande se lance dans la machine “EMI01”, qui emploie divers code identificateurs de la commande réalisée lors de l’étape précédente. Il nous faudra d’autres agents transactionnels dans cette machine ou une autre mais qui soit capable d’y accéder à distance. LE script de contrôle de cette phase devra vérifier que le processus a été correctement effectué. Pour cela, il cherchera des entrées dans les archives de registre, des événements ou archives temporaires.

La troisième étape de la transaction sera de stocker la commande traitée dans une base de données Oracle, dans la machine “ORAMON”. Il est courant que ces machines soient sécurisée et qu’il ne soit donc pas possible d’y installer d’autres softwares. C’est pourquoi, nous déploierons l’agent transactionnel dans une machine à distance avec autorisations de lancer des consultations envers la base de données.

La dernière étape consiste à confirmer l’existence d’un courrier dans la boîte de réception du service Logistique dans le serveur de courrier “public”. Dans le cas où nous ne pouvons pas déployer un agent dans cette machine, nous réaliserons les consultations depuis une autre qui pourra accéder à cette dernière. Nous pouvons utiliser les plugins classiques de Pandora FMS, avec des petites variations, pour réaliser la vérification de l’arrivée du courrier électronique.

1.3.2 Déploiement et développement

Dans notre exemple, nous identifions 4 phases et nous aurons besoin de 4 scripts :

  • 1. Déclencheur de transaction : laisser une commande factice dans la machine “Portal” pour pouvoir la tracer.
  • 2. Script de contrôle : chercher une chaîne dans une archive de log.
  • 3. Script de contrôle : réaliser une consultation sur la base de données.
  • 4. Script de contrôle : confirmer l’existence d’un courrier dans la boîte de réception de Logistique.

Dans notre exemple, le déclencheur de transaction laissera une copie d’un fichier d’une commande dans un point déterminé (par exemple, grâce à FTP).

Tous les scripts de contrôle doivent avoir une structure basique comme celle de l’exemple suivant :

Script1.JPG


#!/bin/bash
########################
# Check Control Set 
######################## 
function check_flag() { 
   # Conditions du script de contrôle. 
   if [ "a" == "a" ]; then 
      return 1; 
   fi 
   return 0; 
} 
max_tries=100 
wait=3 
try=0 
while [ $try -le $max_tries ]; do 
   if [ check_flag == 1 ]; then 
      echo 1 
      exit 0 
   fi 
   sleep 
   $wait 
   try=`expr $try + 1` 
done 
echo 0 
exit 1

Une fois que nous aurons tous les scripts en fonctionnement, nous déploierons des agents transactionnels dans les machines concernées.

tar xvzf pandorafms_transactional.tar.gz
cd pandora_transactional 
./pandora_transactional_installer --install

Nous devrons uniquement modifier le fichier de configuration de l’agent (par défaut /etc/pandora/pandora_transactional.conf) pour indiquer au serveur Pandora FMS qu’il se chargera du processus de la transaction. Enfin, nous débuterons le service de l’agent :

/etc/init.d/transactional_daemon start

1.3.3 Création de transaction

Nous le ferons grâce à la console web de Pandora FMS.

Nous accédons au menu Maps -> Transactional map.


Trans1.JPG


Trans2.JPG


Nous créons la nouvelle transaction et nous remplissons les champs exigés.


Trans3.JPG


  • Nom.
  • Description.
  • 'Agent ': agent de Pandora FMS dans lequel les modules générés par le système seront sauvegardés (historique).
  • Groupe : pour contrôler la visibilité et les accès.
  • Intervalle bouclé : temps d’attente avant de lancer à nouveau la transaction.

1.3.4 Création de l’arbre d’étapes

Une fois la transaction créée, l’arbre d’étapes pourra prendre forme en accédant au formulaire correspondant :


Trans111.png


Dans le formulaire, nous devons préciser les données pour chaque phase :


Trans222.png


  • Indice : identifiant unique de la phase lors de la transaction actuelle.
  • Nom.
  • Agent : depuis lequel le script de contrôle correspondant s’exécutera.
  • Dépendances : phases précédentes doivent être terminées avec succès avant de débuter la phase en question. Les indices des phases correspondantes seront indiqués, séparés par des virgules.
  • Les ayants-droit : descendants, phases qui s’activera quand la phase en cours seront achevée. Les indices seront indiqués, séparés par des virgules.
  • Actions : sauvegarder les changements.

Nous avons une phase initiale par défaut, START. Cette phase s’utilise uniquement pour définir quelles phases seront les premières à être exécutées.

Dans la capture suivante, nous voyons comment s'insère l’indice de la première phase à exécuter, (1) Réception de la commande :


Trans6.JPG


En sauvegardant le changement, nous voyons que la phase est automatiquement marquée en état d’erreur. Ceci est dû au fait que dans notre définition, il n’existe aucune phase avec l’indice 1. Nous cliquons sur “Ajouter” pour la créer :


Trans7.JPG


Une fois les changements sauvegardés, nous créons la phase, mettons à jour la prévisualisation du graphique de transaction et et corrigeons l’avertissement précédent :

Trans8.JPG


Nous pouvons observer que dans le champs des dépendances de la phase 1, ‘0’ est apparu pour indiquer que cette phase débutera lorsque la phase START sera achevée avec succès.

En suivant le même processus, nous créerons toutes les phases :


Trans9.JPG


La dernière étape n’activera rien ce qui signifiera que la transaction est terminée.

Dans la capture, nous observons également un avertissement jaune, nous indiquant une attente de configuration. Ce sont les scripts de contrôle.

1.3.5 Configuration des scripts de contrôle

Nous devrons configurer les scripts de contrôle associés à chaque phase. Ces derniers doivent avoir été définis au préalable pour réaliser les vérifications souhaitées et maintenir une structure basique déterminée. La sortie standard du script déterminera la valeur centrale montrée lors de l’étape, tandis que l’état (correct ou incorrect) sera déterminé por “le résultat de l’exécution” du script lui-même. ATTENTION, ne pas confondre le “résultat de l’exécution” (aussi appelé “errorlevel”, “nivel de error”, ou “code d’exécution”) avec la sortie standard du script (la valeur que renvoyée sur l’écran en l’exécutant).

Le résultat de l’exécution ou errorlevel peut se vérifier en exécutant echo $? sur des systèmes Linux et echo %ERRORLEVEL% sur des systèmes Windows.

En tenant compte de cela, nous accédons au formulaire grâce à l’icône d’édition :

Trans10.JPG


Dans le formulaire de configuration des scripts de contrôle, nous pourrons ajuster la commande à exécuter, le nombre de nouvelles tentatives et le temps maximum d’exécution permis pour le script indiqué :


Trans11.JPG


  • Lancer script : emplacement ou chemin d’accès complet du script de contrôle, appel, commande, etc. Nous pourrons utiliser la macro _name_ pour indiquer comme argument à notre script le nom de la transaction en cours.
  • Nouvelles tentatives : nombre maximum de nouvelles tentatives d’exécution jusqu’à obtenir une réponse positive.
  • Temps maximum d’attente' : valeur maximum, en secondes, du temps pendant lequel le script de contrôle sera en cours d’exécution (caractéristique non disponible pour l’agent transactionnel de Windows).

Dans notre exemple, nous utiliserons un script personnalisé (echo1.sh) pour simuler les actions du déclencheur de transaction et des scripts de contrôle de chaque phase :


Trans12.JPG


Une fois que nous avons notre environnement correctement configuré, nous pouvons commencer la transaction.


Trans13.JPG


Template warning.png

Tout changement apporté à la configuration d’une transaction ne sera effectif que si elle est redémarrée.

 


1.3.6 Contrôle d’une transaction

1.3.6.1 Commencer une transaction

Nous naviguerons jusqu’à la liste des transactions et nous cliquerons sur l’icône de départ :


Trans14.JPG


Une fois la transaction débutée, le bouton “arrêter transaction” apparaîtra.


Trans15.JPG


Nous pouvons visualiser l’état de la transaction à partir de la visionneuse, en cliquant sur le nom de la transaction :


Trans16.JPG


1.3.6.2 Arrêter une transaction

Pour arrêter la transaction, nous n’aurons qu’à cliquer sur le bouton correspondant. Après quelques secondes, nous pourrons la relancer grâce au bouton de lancement.


Trans17.JPG


1.3.6.3 Visualiser une transaction

Nous accèderons à la vue en appuyant sur le nom de la transaction, dans la liste des transactions.

Vue d’exécution en cours (début de la transaction) :


Trans18.JPG


Vue d’exécution en cours (phase intermédiaire) :


Trans19.JPG


Vue de la transaction complète :


Trans20.JPG


1.4 Configuration

1.4.1 Serveur transactionnel

Les paramètres de configuration du serveur transactionnel sont les suivants :

transactionalserver 1

transactional_threads 1

transactional_threshold 4

# Work directory
# By default in icomingdir/trans
transactional_pool trans
  • transactionalserver : pour démarrer le composant du serveur transactionnel en démarrant le service pandora_server.
  • transactional_threads : le champs est ajouté par convention/accord?. En interne, un seul thread est requis pour gérer les transactions actives à partir du serveur. C’est l’agent qui possède le sous-système de threads dynamique pour la gestion des exécutions des transactions configurées.
  • transactional_threshold : temps d’attente entre les changements d’état. Ce champs nous décrit le temps (en secondes) pendant lequel le système patientera entre les changements d’état des éléments qui composent une transaction (recommandé 4) tiempo de espera entre cambios de estado. Este campo nos define el tiempo (en segundos) que el sistema esperará entre los cambios de estado de los elementos que componen una transacción (recomendado 4).
  • transactional_pool : répertoire dans lequel se conserveront les archives “.lock” qui, en interne, utilise le système pour réaliser les communications entre les différents composants logiques (par défaut dans /var/spool/pandora/data_in/trans).

Pour que le système soit entièrement opératif, nous devons avoir activés aussi bien le serveur de données (“dataserver”) que le serveur transactionnel (“transactionnalserver”). Nous pourrons le vérifier dans la vue tactique des serveurs :


Trans21.JPG


1.4.2 Agent transactionnel

L’agent transactionnel a un fichier de configuration dans son répertoire de travail (par défaut /etc/pandora/pandora_transactional.conf) avec le contenu suivant :

############################################################
#  Base config file for Pandora FMS transactional agent 
#  Version 2.0                                      
#  Copyright (c) 2003-2016 Artica Soluciones Tecnologicas  
#  http://www.pandorafms.com                          
#############################################################

server_ip=localhost
server_port=41121

# Temporal directory
temporal=/tmp
#temporal=C:\Program Files\pandora_transactional\tmp

# Log directory
log=/var/log/pandora/pandora_transactional.log

# Tentacle binary
tentacle_bin=/usr/bin/tentacle_client

###############################
# Set the name of the agent
###############################
#agent_name=transactional_agent
agent_interval=300

# Performance (in seconds) internal clock
pause=5

# Show all log messages (0 - show none, 1 - show script execution messages, 2 - show all)
verbose=2
  • server_ip : adresse IP ou nom du serveur transactionnel de Pandora FMS.
  • server_port : port dans lequel le serveur de Tentacle est écouté.
  • temporal : répertoire auxiliaire pour fichiers de travail temporaires.
  • log : chemin d’accès de l’archive de log.
  • tentacle_bin : chemin d’accès binaire du client Tentacle.
  • agent_name : utiliser un nom personnalisé pour identifier l’agent (facultatif). PAr défaut, il utilise le nom de la machine.
  • pause : temps par défaut, en secondes, entre les étapes. Il s’ajustera selon la configuration reçue par le serveur pour maintenir la synchrone.
  • verbose : contrôle de la quantité d’informations montrée dans les archives de log. Par défaut, toute sortie dans “STDERR” que générent nos scripts de contrôle sont renvoyés dans le fichier :
    • 0 : ne montrer que les messages d’erreur critique.
    • 1 : montrer les exécutions des scripts de contrôle.
    • 2 : montrer tous les messages.

Toute la configuration de transactions sera publiée dans le serveur de Pandora FMS. C’est l’agent qui sera chargé de tracer ces fichiers et de démarrer les structures de données nécessaires pour lancer les transactions concernées.

Face à une mise à jour au cours d’une transaction active, l’agent arrêtera cette transaction, en démarrant un nouveau processus pour en établir une nouvelle. Toute la progression précédente sera abandonnée.

Le système transactionnel exécute la transaction finie. C’est-à-dire, s’il échoue lors de l’exécution d’un script, il continuera d’exécuter la transaction, en marquant la phase durant laquelle une erreur a été détectée comme erronée. Par conséquent, nous interpréterons une transaction comme un échec total quand, d’une phase à la dernière, toutes apparaissent comme erronées.

Vous pouvez trouver l’agent transactionnel dans la libraire de modules de Pandora FMS [1]


Revenir à l’Index de Documentation Pandora FMS