Pandora: Documentation fr: Supervision services

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’index de Documentation Pandora FMS

1 Surveillance des Services

1.1 Introduction

Un service est un regroupement de ressources IT se basant sur leurs fonctionnalités.

Un service peut être, par exemple, un site web officiel, votre GRC, votre application de support, ou même toutes vos imprimantes. Les services sont des regroupements logiques qui incluent des hosts, routers, switches, firewalls, CRM, ERP, webs et bien d’autres services.

Sur Pandora FMS, nous représentons les services comme un regroupement d’éléments surveillés (modules, agent ou autres services) dont l’état de chacun affecte d’une certaine façon le fonctionnement général du service.

1.2 Service sur Pandora FMS

1.2.1 Comment fonctionnent les services sur Pandora FMS ?

La surveillance de base sur Pandora FMS consiste à rassembler des métriques de diverses origines, en les représentant commes des moniteurs (modules).

La surveillances dans des services nous permet de regrouper ces modules, de telle sorte qu’en jouant avec certaines marges basées sur l’accumulation d’erreurs, nous pourrons surveiller des groupes d’éléments de différentes natures ainsi que leur relation dans un plus grand service général.

En définitive, la surveillance de services nous permet de vérifier l’état d’un service global. Nous pourrons savoir si notre service fourni est réalisé normalement (vert), s’il est défaillant (jaune) ou bien s’il y a absence de service (rouge).

Pour mieux comprendre en quoi consiste la surveillance de services, nous allons illustrer ses propos avec un exemple.


Supposons que nous souhaitons surveiller notre application web que nous avons équilibrée grâce à une série d’éléments superflus. L’infrastructure sur laquelle se base notre application pourrait être composée des éléments suivants :

  • Deux routers en HA.
  • Deux switches en HA.
  • Vingt serveurs WEB Apache.
  • Quatre serveurs d’Applications Weblogic
  • Un cluster MySQL de deux noeuds de stockage et deux noeuds de traitement SQL.

Etant donné que notre objectif est de savoir si notre application web fonctionne correctement, c’est-à-dire que l’appréciation finale de nos clients est que l’application fonctionne bien, la nécessité de surveiller des services avec quelque “d’abstrait” survient lorsque se pose la question suivante :

Que se passe-t-il avec mon application lorsqu’un élément, en principe non critique, devient défaillant ?

Comme par exemple, si l’un des vingt serveurs Apache est défaillant. En principe, nous pourrions ne pas en être averti, du fait de l’abondance des situations problématiques couvertes qui se produisent. Mais alors, sur lequel faut-il configurer des alertes ? Tous ? Certains ? Quelle est la règle pour lancer l’alerte ?

Nous pourrions penser que Pandora FMS ne devrait nous avertir que lorsqu’un un élément plus critique cesse de fonctionner (comme un router) ou lorsque )plusieurs serveurs Apache sont défaillants.

Pour lever les doutes, la fonctionnalité de surveillance grâce aux services sur Pandora FMS apparaît.


Les services sur Pandora FMS nous aident à :

  • Limiter la quantité d’avertissements reçus. Nous recevrons des alertes sur des situations qui compromettent la fiabilité des services que nous fournissons.
  • Faire un suivi du niveau de conformité..
  • Simplifier la visualisation de la surveillance de notre infrastructure.


Pour réussir cela, chaque élément qui puisse affecter négativement notre application devra être surveillé.

Au moyen de la console de Pandora FMS, nous devrons définir un arbre de services dans lequel nous indiquerons aussi bien les éléments qui touchent notre application que le niveau d’affectation.

Tous les éléments que nous ajouterons aux arbres de service correspondront à une information qui est déjà surveillée, que ce soit comme modules, agents concrets ou d’autre services.

Pour préciser le niveau d’affectation des états de chaque élément par rapport à l’état global, on utilisera un système de somme des poids, de sorte que les plus importants (poids plus élevés) seront plus aptes pour ajuster l’état général du service complet à un état incorrect avant les éléments moins importants (poids plus faibles).

Voyons toutes les idées grâce à un exemple pratique :

  • Switches et routers : 5 points à chacun d’entre eux quand ils seront en “critical” et 3 points en “warning”.
  • Servidores WEB : 1.2 points à chacun en état “critical”. Pour l’état “warning”, nous ne prévoyons rien.
  • Servidores WebLogic : 2 points à chacun lors d’un état “critical”.
  • Cluster MySQL : 5 points à chaque noeud en “critical” et 3 points en “warning”.


Type d’élément Assignation de poids
Normal Warning Critical Unknown
Router0355
Switch0355
Web server001.21.2
Weblogic server0022
MySQL server0355


Nous établissons un seuil de warning pour le service de 4 et un seuil de “critical” de 6. De cette façon et en supposant que tout va bien, le service serait “OK” si tous les éléments surveillés sont “OK” ou bien que ceux qui ne le sont pas soient suffisamment peu importants pour ne pas engendrer des carences dans la prestation de notre service.

Configuration du service
Normal Warning Critical
0 >=4 >=6


Supposons maintenant qu’un (1) serveur Web cesse de fonctionner correctement :

  • 1 x Serveur Apache en CRITICAL x 1.2 pts = 1.2 étant donné que 1.2 < 4 (Warning), le serveur reste en état OK.

La contribution de poids sera :

2 x 0 (routers en OK)
+ 2 x 0 (switches en OK)
+ 19 x 0 (apache OK)
+ 1 x 1.2 (apache CRIT)
+ 4 x 0 (weblogic OK)
+ 1 x 0 (mysql OK)
Total : 1.2 → Notre service sera NORMAL 


Voyons maintenant ce qui se produit si un serveur WEB et Weblogic sont défaillants :

  • 1 x Serveur Apache en CRITICAL x 1.2 pts = 1.2
  • 1 x Serveur Weblogic en CRITICAL x 2 = 2

Total, 3,2 fonctionnent < 4 donc le service reste en état OK, il continue de fonctionner. Une réparation technique n’est alors pas nécessaire dans l’immédiat.

La contribution de poids sera :

2 x 0 (routers en OK)
+ 2 x 0 (switches en OK)
+ 19 x 0 (apache OK)
+ 1 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 3.2 --> Notre service sera NORMAL.


Voyons ce qui se passe si deux serveurs WEB et Weblogic cessent de fonctionner :

  • 2 x Serveur Apache en CRITICAL x 1.2 pts = 2.4
  • 1 x Serveur Weblogic en CRITICAL x 2 = 2

Total, 4,4 > 4, le serveur passe donc en état WARNING et notre service entre en état dégradé. Il continue de fonctionner et peut ne pas avoir besoin d’une assistance technique immédiate mais il est certain qu’un problème s’est produit dans notre infrastructure.

2 x 0 (routers en OK)
+ 2 x 0 (switches en OK)
+ 18 x 0 (apache OK)
+ 2 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 4.4 → Notre service sera en WARNING


Supposons qu’en plus, un router cesse tout fonctionnement :

  • 2 x Serveur Apache en CRITICAL x 1.2 pts= 2.4
  • 1 x Serveur Weblogic en CRITICAL x 2 = 2
  • 1 x Router en CRITICAL x 5 = 5

Nous avons 9,4, ce qui est déjà supérieur au seuil de 6 de l’état CRITICAL. Le service est donc critique, le service n’est plus assuré et une assistance technique immédiate est impérative.

1 x 0 (routers en OK)
+ 1 x 5 (router en CRIT)
+ 2 x 0 (switches en OK)
+ 18 x 0 (apache OK)
+ 2 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 9.4 --> Notre service sera en CRITIQUE

Pandora FMS alertera l’équipe de travail correspondante (opérateurs, techniciens, etc).


La surveillance de services est une caractéristique propre à la version Enterprise de Pandora FMS.

1.2.1.1 Comment fonctionne le mode simple ?

Il est possible que le système de poids soit trop complexe si les besoins de surveillance sont plus basiques.

Pour cela, le mode simple est disponible dans la configuration des services.

Dans ce mode, il ne faut qu’indiquer quels sont les éléments critiques et ceux qui ne le sont pas.

Seuls les éléments marqués comme critiques seront tenus en compte pour la réalisation des calculs et seul l’état “critical” des éléments aura une valeur.

  • Quand entre 0 et 50% des éléments critiques se trouvent en état “critical”, le service passera en “warning”.
  • Quand plus de 50% des éléments critiques sont en état “critical”, le service entrera en état “critical”.


Prenons un exemple de service simple :

  • Router comme élément critique.
  • Imprimante comme élément non critique.
  • Serveur Apache comme critique.


A un moment précis, les moniteurs se trouvent dans la situation suivante :

  • Router en critical.
  • Imprimante en critical.
  • Serveur Apache en warning.

L’état du service serait alors en “warning”, puisque l’imprimante n’est pas un élément critique et son état n’est pas pris en compte, tout comme le serveur Apache qui a le poids d’un élément critique, ne sera pris en compte qu’en état “critical”.

Par conséquent, il n’existe qu’un élément en état “critical”, exactement 50% du total des éléments critiques indiqués.


Supposons que les moniteurs se trouvent dans la situation suivante :

  • Router en critical.
  • Imprimante en critical.
  • Serveur Apache en critical.

L’état du service serait critical, puisque plus de la moitié des éléments critiques sont en état critique.


Enfin, un autre jour, les éléments sont en état :

  • Router en normal.
  • Imprimante en critical.
  • Serveur Apache en normal.

L’état du service serait “normal” puisque moins de 50% du total des éléments critiques sont en état critique.

De fait, aucun élément clé n’est en état “critical”. Seul l’imprimante l’est, mais, comme nous l’avons mentionné précédemment, ne faisait pas partie des éléments critiques, elle n’est pas prise en compte dans les calculs.

1.2.1.2 Les services racines

A partir de la version 7.0 OUM726 de Pandora FMS, les services s’évaluent légèrement différemment.

A présent, les services qui ne font pas partie d’autres services seront évalués. C’est ce que l’on appelle “des services racines”. Logiquement, ce changement nous permet de simplifier la surveillance, en réduisant les files d’attente de tâches.

De même, et en partant de cette base, lorsqu’un service défini dans un noeud de Pandora FMS apparaît comme élément d’un service racine dans la Metaconsole, ce sera le serveur Metacolsole qui l’évaluera, en mettant à jour les valeurs stockées dans le noeud.

Ceci nous fournit une logique distribuée qui est plus efficace et nous permet d’appliquer un système de protection en cascade basé sur des services. Les possibilités des serveurs sur la Métaconsole se sont élargies, en permettant d’ajouter en tant qu’élément d’un service aussi bien d’autres services comme des modules ou des agents. Dans des versions préalables, seuls les services de noeuds étaient possibles.

1.2.2 Créer un nouveau service

1.2.2.1 Introduction

Template warning.png

Il faut posséder la version Enterprise et le composant PredictionServer doit être activé pour pouvoir utiliser les services.

 


Les services peuvent représenter :

  • des modules
  • des agents complets
  • d’autres services

Les valeurs d’un service se calculent grâce à un serveur de Prédiction avec la période par défaut des modules de prédiction.

Une fois que vous avez tous les dispositifs surveillés. Dans chacun des services, vous pouvez ajouter tous les modules, agents ou sous-services dont vous avez besoin pour surveiller le service. Par exemple, si vous souhaitez surveiller le service de la Boutique en ligne, il faut un module pour le contenu, un service qui surveille l’état des communications, etc. Grâce aux étapes suivantes, vous pouvez apprendre à créer un service avec Pandora FMS.

Pour créer un nouveau service, nous devrons aller sur Services dans le menu Topology Maps.


Menu services.png


Une liste apparaîtra avec tous les services. Sur l’image suivante, ladite liste apparaît vide.


Services empty v5.png


1.2.2.2 Configuration initiale

Pour créer un nouveau service, il suffit de cliquer sur le bouton Create et vous pouvez ensuite créer le service en remplissant le formulaire qui apparaît comme sur l’image ci-dessous :



Services creation v5.png


Les champs du formulaire et leur signification sont :

  • 'Nom : le nom du service.
  • Description : description du service, long texte obligatoire. La description en question sera celle qui apparaîtra sur la carte du service, dans la vue de la table du service et dans le widget des services (au lieu du nom).
  • Groupe : groupe auquel appartient le service, utile pour l’organiser et pour appliquer des restrictions SLA.
  • Mode : mode dans lequel le calcul de poids des éléments se réalisera.
    • Manuel : les poids se mettront manuellement dans le service et dans chaque élément. ** Automatique : la valeur du seuil critique du service est 1 et le seuil d’avertissement est de 0.5. A chaque fois qu’un élément est créé pour ce service, les poids 0 leur seront automatiquement attribués, pour l’état OK, 0.5 pour warning et 1 pour critical.
    • Simple : il ne faudra pas mettre les poids mais seulement indiquer pour chaque élément s’il est critique ou non.
  • Critical : seuil de poids pour déclarer le service comme critique. Ce champ est désactivé quand le mode automatique est sélectionné et a 1 comme valeur par défaut. Il est invisible quand le mode simple est sélectionné.
  • Warning : seuil de poids pour déclarer le service en état d’avertissement. Ce champs est désactivé lorsque le mode automatique est activé et a 0.5 comme valeur par défaut. Il est invisible si le mode simple est activé.
  • Agent pour sauvegarder les données : le service sauvegarde les données dans des modules spéciaux de données (concrètement, les modules de prédiction) et il faut nommer un agent qui contiendra ces modules ainsi que les alarmes qui seront configurées au préalable dans ce même formulaire. Note : Tenez compte que l’intervalle dans lequel tous les calculs des modules du service se réaliseront dépendra de l’intervalle de l’agent configuré comme conteneur de modules.
  • Quiet : active le mode silencieux du service. LEs alertes et événements ne sont alors pas générés.
  • Cascade Protection : active la protection en cascade sur les éléments du service. Ils ne génèrent pas d’alerte ni d’événement s’ils appartiennent à un service (ou sous-service) en état critique.
  • Favori : token pour mettre le nouveau service dans les favoris. Un lien direct dans le menu latéral se créera alors.
  • Calculate continuous SLA for this service : active la création des modules de SLA et SLA value pour le service actuel. S’il est désactivé, il ne disposera pas de l’information SLA calculée de façon dynamique. Les alertes d’exécution SLA de ce service ne fonctionneront pas non plus. Il s’utilise dans le cas où le nombre de services nécessaires est si important qu’il peut affecter la performance. Si l’option se désactive, une fois le service créé, l’historique de données de ce module s’effacera et les informations seront perdues.
  • Intervalle de S.L.A. : temps pour calculer le SLA effectif du service. 1 mois par défaut.
  • Limite de S.L.A. : seuil de l’état OK du service pour qu’un SLA soit considéré comme positif pendant le temps de configuration du champs précédent.
  • Alerte du service en état Warning : écran d’alerte qu’aura le service pour lancer l’alerte quand le service passera en état d’avertissement.
  • Alerte du service en état Critical : écran d’alerte qu’aura le service pour lancer l’alerte quand le service passera en état critique.
  • Alerte du SLA en état Critical : écran d’alerte qu’aura le service pour lancer l’alerte quand le SLA du service ne s’exécutera pas.

1.2.2.3 Configuration des éléments

Une fois le formulaire rempli correctement, vous aurez un service vide à remplir avec des éléments ou items de services comme nous le verrons plus tard. Dans le formulaire d’édition du service, il faut sélectionner l’onglet ‘Config Elements’.


Services tab setup v5.png


Vous verrez alors une page comme la capture d’écran suivante, sur laquelle on peut gérer les éléments des services (les modifier, ajouter des nouveau ou les effacer).


Services elements empty v5.png


Avec la capture précédente, nous allons décrire le formulaire d’édition et la création des éléments du service :

  • Type : liste déployable qui peut présenter des services, des modules ou agents.
  • Agent : chercheur intelligent d’agents. Uniquement visible si l’élément à créer ou éditer est de type agent ou module.
  • Module : liste déployable avec les modules de l’agent choisi au préalable dans le chercheur intelligent. Ce contrôle ne peut se voir que si l’on édite ou crée un élément pour le service de type module.
  • Service : liste déployable des services pour créer un élément. Uniquement visible si l’élément à créer ou éditer est de type service. De plus, il faut bien prendre en compte que les services qui apparaîtront dans la liste déployable sont ceux qui ne sont pas issus du service. Cela est nécessaire pour montrer une arborescence correcte de la structure entre les services.
  • Critical : l’élément sera critique s’il est sélectionné. Il n’est visible que si le service est en mode simple.
  • Poids en Critical : poids de l’élément s’il est en état critique est de 1 par défaut et est désactivé si le service est en mode “auto calcul”. Il est invisible si le service est en mode simple.
  • Poids en Unknown : poids de l’élément s’il est en état inconnu. Par défaut, c’est 0 et il est désactivé si le service est en mode “auto calcul”. Il est invisible si le service est en mode simple.
  • Poids en Warning : poids de l’élément s’il est en état warning. Il est de 0.5 par défaut et est désactivé si le service est en mode “auto calcul”. Il est invisible si le service est en mode simple.
  • Poids en OK : poids de l’élément s’il est en état correct. Par défaut, c’est 0 et il est désactivé si le service est en mode “auto calcul”. Il est invisible si le service est en mode simple.

Dans cette capture, vous disposez d’icônes dans la dernière colonne de droite intitulée “Actions” pour :

  • Éditer : c’est l’icône représenté avec une clé anglaise au manche jaune. Vous éditerez l’élément de la file qui correspond à cet icône.
  • Effacer : c’est l’icône représenté avec une croix rouge. En cliquant dessus, une fenêtre modal s’activera pour confirmer son élimination et la suppression de la base de données de l’élément du service.

1.2.2.4 Modules créés en configurant un service :

  • SLA Value Service : c’est la valeur en pourcentage de la correcte exécution de SLA. (async_data)
  • Service_SLA_Service : nous indique si la SLA s’exécute ou non. (async_proc)
  • Service_Service : dans ce module, on y trouve la somme des poids du service. (async_data)



1.2.3 Visualización de los Servicios

1.2.3.1 Liste simple de tous les services

C’est la liste d’opération qui montre tous les services créés. Bien évidemment, elle ne montre que ceux des groupes auquel l’utilisateur a accès en utilisant la console de Pandora FMS.

Pour accéder à cette vue, il faut aller dans le menu Opération, ouvrir l’entrée Surveillance et dedans, allez dans la section Services.



Services list services admin v5.png


Chaque file représente un service et les colonnes présentées sont :

  • Nom : c’est le nom du service
  • Description : courte description du service
  • Groupe : l’icône du groupe auquel appartient le service et que l’utilisateur peut voir.
  • Critique : la valeur plafond des sommes des poids pour marquer le service comme “critique”.
  • Avertissement : la valeur plafond des sommes des poids pour marquer le service en état “avertissement”.
  • Valeur : la valeur des sommes des poids des éléments qui contiennent le service.
  • Etat : un icône qui représente l’état du service. Il y a les trois états suivants représentés normalement avec les couleurs suivantes :
    • Rouge : le service est entré en état critique car la somme des poids des modules est supérieure ou égale au seuil critique.
    • Jaune : le service est entré en état d’avertissement car la somme des poids des modules est supérieure ou égale au seuil d’avertissement.
    • Vert : le service se maintient en état normal ou correcte car la somme des poids des modules n’est pas arrivé jusqu’au seuil d’avertissement.
    • Gris : le service se maintient en état inconnu. Cela se produit généralement quand le service a récemment été créé et ne contient pas d’élément ou bien quand il le SErveur de Prédiction de Pandora FMS de défaillant.
  • SLA : la valeur de SLA du service, la SLA recevra l’une des valeurs suivantes :
    • OK : le SLA s’exécute pendant la période défini pour le SLA du service.
    • INCORRECT : le SLA ne s’exécute pas pendant la période défini pour le SLA du service.
    • N/A : le SLA est en état inconnu soit car il n’a pas encore collecté,suffisamment de données pour faire le calcul soit parce que le SLA est désactivé.



1.2.3.1.1 Table de tous les services

Table de visualisation rapide de tous les services visibles et leur état actuel.

Servs.JPG


1.2.3.1.2 Liste simple d’un service et tous les éléments qu’il contient

Cette vue est accessible en cliquant sur le nom d’un service dans la liste de tous les services ou via l’onglet avec l’icône loupe dans l’en-tête du titre du service.

Pandora FMS affichera une page semblable à la capture d’écran suivante :



Services list elements operation v5.png


Dans la capture, on peut distinguer deux zones, le service avec les mêmes colonnes que dans la vue précédente dans la partie au-dessus. Dans la partie inférieure, on y trouve la liste des éléments qui composent ce service.

La liste des éléments apparaît en format table, où les lignes correspondent à chaque élément et les colonnes représentent : lista de los elementos aparece en formato de tabla, donde las filas corresponden a cada elemento y las columnas representan:

  • Type : icône qui représente le type d’élément soit c’est un bloc de construction pour les modules ou des blocs empilés pour l’agent ou encore l’icône d’un diagramme de réseau pour les services.
  • Nom : texte qui a le nom de l’agent, ou le nom de l’agent et du module ou le nom du service. Tous contiennent un lien dans la vue de l’opération correspondante.
  • Description : court texte qui décrit l’élément
  • Poids pour critique : la valeur du poids associée lorsque l’élément est en état critique.
  • Poids pour avertissement : la valeur du poids associé lorsque l’élément est en état d’avertissement.
  • Poids pour normal : la valeur du poids associé lorsque l’élément est en état normal.
  • Donnée : la valeur de l’élément qui, selon le type, peut être :
    • Modules valeur du module.
    • Agents texte qui indiquera l’état de l’agent.
    • Services somme des poids des éléments du service qui a été choisi comme élément pour le service père.
  • Etat icône qui représente l’état de l’élément par une couleur.

Template warning.png

Il faut prendre en compte que le calcul des services est réalisé par le serveur de prédiction, c’est pourquoi les données ne sont pas en temps réel. Cela peut amener à des situations dans lesquelles vous ajoutez un agent ou un module et le poids ne se met pas à jour jusqu’à ce que le serveur recalcule ce service.

 


1.2.3.1.3 Vue de la carte de service

Cette vue affichera le service de manière arborescente comme vous pouvez le voir sur la capture d'écran suivante. De cette manière, vous pouvez rapidement voir comment les modules, les agents ou les sous-services influencent la surveillance du service. Même dans les sous-services, vous pouvez voir ce qui les influence lors du calcul de l’état par la somme des poids.



Services servicemap v5.png


Les noeuds possibles qui existent sont :

  • Noeuds du module représenté par l’icône du graphique des battements de coeur. Ce noeud est toujours un noeud final ou un noeud feuille auquel d’autres noeuds ne sont pas bloqués (raccrochés ?).
  • Noeud d’agent représenté avec l’icône de la boîte CPU. Celui-ci est aussi un noeud final auquel aucun autre ne sera suspendu.
  • Noeud de service représenté avec l’icône du marteau et la clé fixe croisés.Ce service doit contenir des éléments qui seront représentés comme des branches qui en sortent par en bas.

La couleur des noeuds et la flèche qui en sort et monte vers le service père dépend de l’état du noeud. Comme toujours, vert pour OK, rouge pour critique, jaune pour avertissement ou gris en état inconnu.

Dans le noeud, il y aura :

  • Titre qui est le nom du service, le nom de l’agent ou le nom du module accompagné de l’agent.
  • Liste des valeurs
    • Critique : sera le poids qui s’ajoute quand il est dans un état critique, sauf si le service est le service racine de l’arbre qui sera alors le seuil pour se mettre en état critique.
    • Avertissement : sera le poids qui s’ajoute quand il est dans un état d’avertissement, sauf si le service est le service racine de l’arbre qui sera alors le seuil pour se mettre en état d’avertissement..
    • Normal : sera le poids qui s’ajoute quand il est dans un état OK ou normal, sauf si le service est le service racine de l’arbre, qui n’apparaîtra pas dans la liste des valeurs. sera alors le seuil pour se mettre en état critique.
    • Inconnu : sera le poids qui s’ajoute quand il est dans un état OK ou normal, sauf si le service est le service racine de l’arbre, qui n’apparaîtra pas dans la liste des valeurs.

De plus, il est possible de cliquer sur chaque élément de l’arbre et redirige vers la vue de l’opération de chacun d’entre eux.

Info.png

Lorsque le service sera en mode “simple”, un point d’exclamation rouge apparaîtra à côté de chaque élément.

 


1.2.3.1.4 Services dans la Console visuelle

A partir de cette version, dans la console visuelle, vous pouvez ajouter des services comme davantage d’items à montrer sur la carte.



Servicios1.JPG


Pour créer un item service sur une carte, le processus est le même que pour le reste des items des cartes visuelles mais la palette d’options sera comme celle de la capture d’écran.



Servicios2.JPG


Vous pourrez contrôler :

  • Etiquette : titre que recevra le service sur la carte visuelle.
  • Service : liste déployable qui montre les services pour les utilisateurs autorisés à faire des ajouts sur la carte.

Il faut prendre en compte qu’un item du service, contrairement à d’autres items de la carte visuelle, ne peut être lié avec d’autres cartes visuelles. Le lien de la console virtuelle redirige vers la vue de la carte des services arborescence décrite précédemment.

1.2.3.2 Vue de l’arbre des services

Cette vue permet la visualisation des services sous forme d’arbre.

Chaque niveau indique le nombre d’éléments contenus dans chaque service ou agent.

  • Services : il indique le nombre total de services, d’agents et modules qui appartiennent à ce service.
  • Agent : indique le nombre de modules en état critical (rouge), warning (jaune) unknown (gris), non démarrés (bleu) et état normal (vert).

Dans le premier niveau, les services qui n’appartiennent pas à d’autres seront toujours affichés. Dans le cas d’un service fils, il sera imbriqué dans le service de son père.

Services treeview.png

Template warning.png

La restriction des autorisations ACLs qui ne s’applique qu’au premier niveau

 




1.2.4 Comment interpréter les données d’un service

Les arrêts planifiés recalculent la valeur des SLA en tenant compte du fait que le recalcul «à remonter le temps» est autorisé, et que les arrêts planifiés sont à ajouter a posteriori (cette option doit être activée au niveau général dans la configuration générale). Lorsqu'il s'agit d'un rapport SLA de service, s'il existe un arrêt planifié affectant un ou plusieurs éléments du service, on considère que l'arrêt planifié affecte l'ensemble du service, sans pouvoir définir l'impact que l'arrêt a sur l’ensemble du service

Il est important de noter qu'il s'agit du niveau de rapport, des arbres de services et les informations qu'ils présentent dans la console visuelle ne sont pas modifiées par rapport aux arrêts planifiés créés après leur exécution supposée. Ces valeurs de conformité de service sont calculées en temps réel sur les données historiques du même service, il ne s'agit pas d'un rapport pouvant être «préparé».


D’autre part, il est important de savoir comment se calcule le pourcentage de conformité d’un service :

Supposons que nous ayons un service, défini sur 95% de conformité dans un intervalle d’1h. Supposons une table de valeurs, où t est le temps, x le pourcentage de conformité du service (SLA) et s signifie que le service s’exécute ou non (1 il s’exécute, 0 il ne s’exécute pas). En 1 heure, nous aurions exactement 12 échantillons (en supposant un intervalle de 5 minutes).

Prenons le cas d’un service qui s’exécute bien pendant les 11 premiers échantillons (premières 55 minutes) et lors de la soixantième, il échoue. Nous aurions alors ces valeurs :

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          1      100
7          1      100
8          1      100
9          1      100
10         1      100
11         1      100
12         0      91,6

Ce cas est facile à calculer. Le pourcentage se calcule en fonction du nombre d’échantillons. En t3 par exemple, ce sont trois échantillons totaux avec trois échantillons qui exécutent le service à 100% tandis qu’en t12, nous avons 12 échantillons et 11 valides : 11/12.

Supposons que c’est au milieu de l’échantillon et qu’il se remet lentement.

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          0      83,3
7          1      85,7
8          1      87,5
9          1      88,8
10         1      90 
11         1      90,9
12         1      91,6

Jusque là, tout semble similaire au point précédent, mais regardons ce qui se passe si nous avançons dans le temps :

   t    |   s   |    x  
--------+-------+--------
13        1      91,6
14        1      91,6
15        1      91,6
16        1      91,6
17        1      91,6
18        1      100
19        1      100
....

Nous voyons ici un comportement peu intuitif puisque le volume d’échantillons valides reste à 11 pour une fenêtre temporelle, jusqu’à atteindre t18. L’unique valeur invalide est mise à l’écart, de sorte qu’en t18, la conformité soit de 100%.

Cet écart entre 91,6 et 100 s’explique par la taille de la fenêtre. Plus la fenêtre est grande (en général le calcul de SLA est quotidien, hebdomadaire ou mensuel), moins l’écart sera conséquent.

Calcul du poids en mode simple

Les poids sont abordés différemment en mode simple car seul le poid critique existe et a la possibilité de passer dans deux états autre que normal. Chaque élément reçoit le poids 1 en critical et 0 pour les autres états. Chaque fois qu’un changement sur les éléments du service est opéré, les poids du service sont recalculés. Le poids warning du service est dépréciable. Il prend toujours 0.5 pour valeur car s’il reste à 0, le service en warning sera toujours minimal, mais le poids en warning ne s’utilise pas en mode simple. Le poids critical se calcule de façon à être égal à la moitié de la somme des poids critiques des éléments, qui est de 1. Si avec 3 éléments, le poids critical du service est de 1.5 et donc c’est le serveur qui se charge de regarder si le poids critical a été dépassé ou s’il est égal pour passer le service en état critical ou warning.


1.2.5 Protection en cascade des services

Depuis la mise à jour OUM725, il est possible de mettre en sourdine ces éléments d’un service de façon dynamique. Ceci nous permet d’éviter une avalanche d’alertes pour chaque élément qui appartient au service ou aux sous-services.

Lorsque la caractéristique ‘protection en cascade des services’ est activée, l’action associée à l’écran que nous avons configuré pour le service racine s’exécutera, en nous informant sur les éléments qui ont un état incorrect dans le service.


1.2.6 Analyse de la cause première

Dans un service, nous pouvons avoir un nombre illimité de sous-services (chemins). Dans des versions précédentes à OUM725, Pandora FMS alertait en indiquant l’état du service (normal, critique, avertissement, etc). A partir de OUM725, une nouvelle macro est disponible, qui nous indiquera la cause première de l’état du service.

Pour l’utiliser, nous ajouterons le texte suivant sur l’écran associé au service :


Corps de l’alerte : message d’exemple La chaîne des événements qui ont provoqué l’état du service est la suivante :

_rca_


Ceci ne renverra pas une sortie similaire à la suivante :

Corps d’une alerte : exemple de message La chaîne des événements qui ont provoqué l’état du service est la suivante :

[Aplicación Web -> HW -> Apache server 3]
[Aplicación Web -> HW -> Apache server 4]
[Aplicación Web -> HW -> Apache server 10]
[Aplicación Web -> DB Instances -> MySQL_base_1]
[Aplicación Web -> DB Instances -> MySQL_base_5]
[Aplicación Web -> Balanceadores -> 192.168.10.139]


En voyant cette sortie, on peut interpréter que :

  • Les serveurs Apache 3,4 et 10 sont en état critique.
  • Les bases de données MySQL_base 1 et 5 sont défaillant.
  • L’équilibreur 192.168.10.139 ne répond pas.


Une fois ces informations obtenues, cela nous permet de déboguer la raison de l’état du service, en réduisant les tâches d’investigation des causes d’une défaillance.

1.2.7 Rassemblements des services

Les services sont des regroupements logiques faisant partie de la structure d’entreprise d’une organisation. Ainsi, le groupement de services peut avoir du sens puisque dans certains cas, vous pouvez avoir des dépendances les uns entre les autres, formant par exemple un service général (l’entreprise), plusieurs services plus particuliers (site web d’entreprise, communications, etc). Pour regrouper des services, il faut que le service général ou supérieur soit créé, ainsi que les services inférieurs, qui s’y ajouteront pour créer la structure logique en forme d’arbre.

Ces groupements nous aideront par exemple à : créer des cartes visuelles, configurer des alertes, appliquer des politiques de surveillance, etc. De telle sorte que nous puissions créer des alertes qui préviennent lorsque l’entreprise est en état critique car les commerciaux ne peuvent réaliser leur travail ou lorsque la productivité de l’un des sièges se ralentit, en raison de problèmes techniques avec son service ERP.

Pour mieux comprendre ce que sont les regroupements de services, deux exemples seront présentés ci-dessous.

1.2.8 Exemples de surveillance de services

1.2.8.1 Service de Pandora FMS

Nous allons voir un cas dans lequel l’état du service de surveillance de Pandora FMS est surveillé, composé du service Apache, MySQL, Pandora Server et Tentacle. Chacun de ces éléments constitue à son tour un service avec différents composants, en format grâce au groupement des services, une structure en forme d’arbre.


Arbol.JPG


Dans cet exemple, le service général de Pandora FMS passera en état critique en atteignant le poids 2 et l’état warning avec le poids 1. Comme on peut le remarquer, les quatre composants ont différents poids sur le service de Pandora FMS :

  • MySQL : critique pour le service de Pandora FMS, poids individuel de 2 si MySQL est défaillant. Il obtiendra un poids de 1 s’il se trouve en état warning, en montrant un avertissement dans le service de Pandora FMS.
  • Pandora Server : critique pour le service de Pandora FMS, poids individuel de 2 si le Pandora Server se trouve défaillant. Poids individuel de 1 s’il se trouve en état warning. Par exemple, par une charge excessive de CPU, faisant alors remonter l’avertissement jusqu’au service général de Pandora FMS.
  • Apache : suppose une dégradation du service de Pandora FMS mais pas une interruption totale. C’est pourquoi, il obtient un poids individuel de 1 s’il est défaillant, en montrant en état warning le service de Pandora FMS.
  • Tentacle : suppose une dégradation et il existe des composants qui peuvent échouer mais il ne suppose pas l’interruption totale du fonctionnement de Pandora FMS. C’est pourquoi, le poids individuel en cas de défaillance est 1, en montrant un warning dans le service général.

Dans l‘image suivante, la configuration des différents poids des éléments pour l’état général du service de Pandora FMS est affichée :


Pesos.JPG

1.2.8.2 Service de stockage dans un cluster, groupement de services

Les services sont des regroupements logiques faisant partie de la structure d’entreprise d’une organisation. Ainsi, le groupement de services peut avoir du sens puisque puisque parfois les services seuls n’ont pas beaucoup de sens. Pour regrouper des services, il suffit de les ajouter comme élément à un service supérieur, en créant ainsi un nouveau regroupement logique.

Dans l’exemple suivant, nous avons un cluster de stockage en HA. Pour ce cas, un fichier de deux fileserver fonctionnant en parallèle a été utilisé. Chacun contrôle le pourcentage et l’état d’une série de disques desservant des départements spécifiques, en créant ainsi une structure en forme d’arbre des services regroupés.


Cluster.JPG


Selon cette structure, le seuil de criticité du service de stockage de l’entreprise sera atteint si les deux fileservers échouent puisque cela signifierait qu’ils rejetteraient complètement le service, alors que la défaillance de l’un des deux ne signifierait qu’un service dégradé.

Sur l’image suivante, vous pouvez observer la configuration des poids attribuée aux deux éléments principaux du service de stockage :


Pesoscluster.JPG


Sur l’image suivante, nous pouvons voir le contenu et la configuration des poids du service regroupé FS01. Ici, les éléments auront un poids particulier, en fonction de leur criticité :

  • FS01 ALIVE : critique pour le service de FS01 puisqu’il s’agit de l’IP virtuelle attribuée au premier cluster de disques. Poids individuel de 2 puisque s’il se trouve défaillant, le reste des éléments du service seront logiquement hors service. Dans notre cas, il n’y a pas de seuil warning, puisqu’il s’agit d’une donnée dépendante de l’état Oui/Non.
  • DHCPserver ping : critique pour le service de FS01. Nous lui attribuons le poids individuel de 2. Dans notre cas, il n’y a pas non plus de seuil warning.
  • Disques un poids individuel de 1 leur est attribué dans le cas où ils atteignent leur seuil critique, et 0.5 pour leur seuil warning. C’est pourquoi, le service FS01 ne sera touché de façon critique que s’il en existe au moins deux en état critique ou bien les quatres disques en état critique.


Pesosfs01.JPG

1.3 Pandora Server

Il faut que le composant PredictionServer fonctionne et que la version Enterprise de Pandora FMS soit installée pour pouvoir réaliser la surveillance de Services.


Revenir à l’index de Documentation Pandora FMS