Supervision de services

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, agent ou autres services) dont l’état de chacun affecte d’une certaine façon le fonctionnement général du service.

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).

Les supervisions Services sont réprésentés sous trois concepts : de manière imple, par ses poids d'importance et chaînes par événenments en cascade.

Dans ce mode il est seulement nécessaire d'indiquer quels éléments sont critiques et quels éléments 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.

Exemple :

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

Situation 1 :

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

Résultat : Le service serait alors en warning puisque l’imprimante n’est pas un élément critique, le routeur est en mode critical et cela répresente un 50 % du total des éléments critiques indiqués. Le serveur Apache n'est pas en état critique et n'apporte pas de la valeur à l'évaluation.

Situation 2 :

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

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

Situation 3 :

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

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

Le besoin de supervision de service en tant que quelque chose d'abtracte survient lors de donner une réponse à cette question :

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

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).

Une application web équilibrée à travers une serie d'éléments redondates doit être supervisée. L'infrastructure dans laquelle se fonde l'application est formé dans cet exemple par les éléments suivantes :

• Deux routeurs en Haute Disponibilité (HA).
• Deux commutateurs 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.

L'objectif est de savoir si l'application web fonctionne correctement, c'est à dire l'impression finale des clients es que l'application reçoit, traite et retourne les requêtes dans un délai péremptoire.

Si l'un des vingt serveurs Apache est hors ligne, à cause d'une telle quantité de rédondance, est-il prudent d'alerter tout le personnel ? Quelle est la règle d'alertage ?

De manière arriviste nous pouvons conclure que Pandora FMS seulement devrait avertir si un élément très critique échoue (par exemple un routeur) ou si quelques serveurs Apache sont hors ligne au même temps… mais combien d'eux ? Pour résoudre ça, attribuez des valeurs de poids à la liste de composants décris précédement :

Switches et routeurs

5 points à chacun lorsqu'ils sont en critical et 3 points s'ils sont en warning.

Serveurs Web

1,2 points à chacun en état critical, nous ne contemplons pas l'état warning.

Serveurs WebLogic

2 points à chacun en état critical.

Cluster MySQL

5 points chacun en état critical et 3 points en état warning.

Lors d'une situation normale, les poids additionnés est zéro, c'est pour ça que dans cet exemple, on établit que le seuil pour l'état warning doit être supérieur à 4 et pour l'état critical supérieur à 6 :

Exemples de défaillance :

• Un serveur Web Apache hors ligne (état critical) : si le reste est en état normal et apporte zéro, le totale serait 1,2 et puisque 1,2 < 4 (seuil warning), le Service est en état OK (état normal).

• Un serveur WEB et un WebLogic, tous les deux en état critical> le premier apporte 1,2 points et le deuxième 2,0 pour un total de 3,2 ; il est encore moins de 4 donc le service est encore en état OK, aucune alerte ou action est nécessaire.

• Maintenat ils sont deux serveurs WEB et un WebLogic hors ligne : 2 x 1,2 + 1 x 2 = 4,4; dans ce cas, le seuil d'avertissement a été dépassé, donc il entre l'état warning, il continue de focntionner et il se peut qu'il ne rêquise pas une actuation technique immédiate, mais il est évident qu'un problème s'est produit sur l'infrastructure.

• À la situation précédente, on ajoute un touteur en état critical et déclenche une nouvelle situation : il ajoute 5 points au poids et dépasse le seuil de criticité établi sur 6 ; le service est critique, le service n'est pas fourni et l'action technique immédiate est nécessaire.

Dans ce dernière situation, Pandora FMS alertera à l'équipe de travail correspondante (opérateurs, techniciens, etc.).

Un service racine est celui qui ne fait part d'autre service. Ce concept logique permet de simplifier la supervision, en réduisant les files d’attente.

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.

Il est nécessaire que le composant PredictionServer soit en exécution et la version Enterprise de Pandora FMS server soit installée.

Les services peuvent représenter :

• Modules.
• Agents complets.
• 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 Topology Maps > Services.

Une liste apparaîtra avec tous les services.

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

Nom

Il doit être un nom unique. qui permettra d'identifier le service.

Description

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 ACL.

Agent to store data

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 (voir les étapes suivantes).

Mode

Mode dans lequel le calcul de poids des éléments se réalisera.

• Smart : Les poids et éléments qui font partie du service seront calculés automatiquement selon des règles établies.
• Manuel : les poids se mettront manuellement dans le service et dans chaque élément avec des valeurs fixes. Avec le mode Smat, cette valeur sera un pourcentage.
• Critique : Seuil de poids pour déclarer le service comme critique. Avec le mode Smart, cette valeur sera un pourcentage.
• Avertissement : 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é.

Unknown elements as critical

Il permet d'indiquer que les éléments en état inconnu apportent leur poids de même que s'ils étaient un élément critique.

Favorite

Il crée un lien direct dans le menu latéral et les Services pourront être filtrés dans les vues en base à ce jugement.

Quiet

Il active le mode silencieux du service. LEs alertes et événements ne sont alors pas générés.

Cascade Protection enabled

Il 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.

Calculate continuous SLA for this service

Il active la création des modules de SLA et SLA value pour le service actuel. Il s’utilise dans le cas où le nombre de services nécessaires est si important qu’il peut affecter la performance.

SLA interval

Temps pour calculer le SLA effectif du service. 1 mois par défaut.

SLA limit

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.

Alerts

Dans cette section seléctionnez les modèles que le Service aura pour lancer l'alerte lorsque le service entre l'état avertissement, critique, unconnu ou lorsque le SLA du service n'est pas rempli.

Une fois le formulaire est correctement rempli in Service vide est régistré, ce qu'il faut remplir avec ses éléments. Dans le formulaire d'édition du Service, seléctionnez l'onglet “Configurer éléments”.

cliquez sur Add element et une fenêtre apparaitra avec un formulaire. Le formulaire sera légèrement différent si le service est en mode smart ou mode manuel.

Description

Texte facultatif utilisñe pour représenter l'élément dans la carte du service. S'il n'est pas indiquñe, le nom du module, agent ou service sera utilisé (seol l'élément ajouté).

Type

Choisissez un service, module ou agent ; s'il est en mode Smart, le type Dynamic appairetra aussi.

Agent

Chercheur d'agents (visible si el'élément à créer es Agent ou Module).

Module

Liste déployable avec les modules de l'agent choisi précédement dans le chercheur (seulement visible si un élément est edité ou créé pour le Service de type de module).

Service

Liste déployable dea services pour créer un élément (seulement visible si l'élément à créer ou éditer est un service).

Les champs suivants seulement seront disponibles pour les services en mode manuel :

• critical> Poids que l'élément additionnera au service lorsqu'il se trouve en état critique.
• warning> Poids que l'élément additionnera au service lorsqu'il se trouve en état d'avertissement.
• unknown> Poids que l'élément additionnera au service lorsqu'il se trouve en étac inconnu.
• normal> Poids que l'élément additionnera au service lorsqu'il se trouve en état normal.

Afin de calculer l'état d'un service, le poids de chacun de ses éléments sera additionné selon son état et s'il dépasse les seuils établis dans le service pour avertissement ou pour critique, l'état du service deviendra avertissement ou critique selon le cas.

Dans les services en mode Smaty, les poids ne sont définis non plus pour les éléments, donc son état est calculé comme suit :

• Les éléments critiques contribuent avec tout son pourcentage au poids du service. Cela signidiqe que si par exemple vous avez 4 éléments dans le service et seulement 1 d'entre eux est critique, cet élément additionnera de 25 % au poids du service. Si au lieu de 4 éléments, il sont 5, l'élément critique additionnerait de 20 % au poids du service.
• Les éléments en avertissement contribuent avec la moitié de sonpourcentage au poids du service. Cela signifie que si par exemple vous avez 4 éléments dans le service et seulement 1 d'entre eux en avertissement, cet élément additionnera 12,5 % au poids du service. Si en lieu de 4 éléments ils seraient 5, l'élément d'avertissement additionnerait 10 % au poids du service.

Mode Dynamic

Les champs suivants seraient seulement disponibles pour les éléments de type Dynamic (Services en mode Smart) :

Matching object types

Liste déployable pour choisir si les éléments pour lesquels les règles dynamique seront évaluées et qui feront part du service, ils seront des Agents ou Modules.

Filter by group

Règle pour indiquer le groupe auquel l'élément doint appartenir pour faire part du service.

Having agent name

Règle pour indiquer le nom de l'agent qui doit avoir l'élément pour faire part du service. Un texte qui devra faire part du nom de l'agent souhaité sera indiqué.

Having module name

Règle pour indiquer le nom du module que l'élément doit avoir pour faire partie du service. Un texte qui doit faire partie du module souhaité sera indiqué.

Utilisez regular expresions selector

Si vous activez cette option, le méchanisme de recherche sera utilisé par le biais d' Expressions Régulières (regex ou regexp) mais selon MySQL gère ce type d'expressions.

Having custom field name

Règle pour indiquer le nom du châmp personnalisé que l'élément doit avoir pour faire partie du service. Un texte qui doit faire partie du nom du champ personnalisé souhaité sera indiqué.

Having custom field value

Règle pour indiquer la valeur du champ personnalisé qui doit avir l'élément afin de faire part du service. Un texte qui doit être partie de la valeur du champ personnalisé shouhaitée doit être indiqué.

Exemple

Si vous choisissez de filtrer les agents du groupe Servers dont le nom de l'agent contient Firewall et le nom du module contient Network peut obtenir le résultat suivant.

Exemple

Si la configuration d'un élément synamique soyait la suivante.

Tous les modules qui incluent dans son nom “Host Alive” qui se trouvent dans un agent dont le nom inclut “SW”, dans le groupe “Servers”, avec un châmp personnalisé don le nom inclut “Department” et qui aie une valeur qui inclut “Systems” seraient utilisés en tant qu'éléments du 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)

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.

Cliquez Opération > Supervision et dedans, allez dans la section Services.

Chaque file représente un service :

Groupe

L’icône du groupe auquel appartient le service et que l’utilisateur peut voir.

Critical

La valeur plafond des sommes des poids pour marquer le service comme “critique”.

Warning

La valeur plafond des sommes des poids pour marquer le service en état “avertissement”.

Value

La valeur des sommes des poids des éléments qui contiennent le service.

Status

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é.

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

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 :

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 :

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.

Name

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.

Weight critical

La valeur du poids associée lorsque l’élément est en état critique. Les trois colonnes suivantes (Warning weight, Weight unknown et Weight OK) correspondent respectivement à avertissement, unconnu et normal.

Data

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.

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.

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.

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

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.

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.

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.

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 :

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.

Calcule de poids selon leur importance

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.

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.

Il est important de garder à l'esprit que ce système permet d'utiliser les alertes des éléments qui deviennent critiques chez le service, bien que son état général soit correcte.

La protection en cascade des services vous avertira avec fidélité des éléments racine qui ont échoué quelle que soit la profondité du service défini.

Dans l'exemple montré, on voit que nous disposons d'un des éléments du service en état critique. Bien que le service principal soit correce, il vous avertira de l'état des éléments incorrecter en déclenchant l'alerte liée à l'élement critique.

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]
[Application Web -> HW -> Apache server 4]
[Application Web -> HW -> Apache server 10]
[Application Web -> DB Instances -> MySQL_base_1]
[Application Web -> DB Instances -> MySQL_base_5]
[Application Web -> Balanceurs -> 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.

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.

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 avec ses poids d'importance respectifs.

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.

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.

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.

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 :

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.

Retour à l'index de documentation du Pandora FMS