Méthodologie

Préambule

L’objectif du module Centreon Business Activity Monitoring (Centreon-BAM) est de définir un nouvel indicateur de supervision orienté “métier” à partir d’une agrégation d’indicateurs unitaires collectés par la supervision (KPI). Ce nouvel objet est appelé : une Business Activity (BA).

L’évolution de l’objet BA déterminera une qualité de service (Qos) correspondant à la qualité rendu par l’application aux utilisateurs de cette dernière. En s’appuyant sur cette mesure de Qos, on peut définir les niveaux de fonctionnement la BA et ainsi des indicateurs de niveau de service (SLA).

En cas de défaillance de la BA, il est possible d’analyser les dysfonctionnements qui ont conduit à la baisse de la Qos et par extension la diminution de la SLA.

Paramétrage initial

La construction d’une BA et de ses PKI associées doit être réalisée de manière simple et par étape. L’idéal est de commencer par intégrer les KPI les plus évidentes, celles directement liées au fonctionnement général de la BA puis d’ajouter au fur et à mesure celles qui ont un impact potentiel sur le fonctionnement global.

Toutes PKI ajoutée aux BA doit être initialement supervisée unitairement par le système de supervision pour connaître son état de fonctionnement. Elle pourra ensuite être intégrée aux BA et associée à un poids qui impactera l’état général de la BA. Les poids peuvent avoir un impact « bloquants », « majeurs », « mineurs », « null » sur la Qos de la BA.

Par exemple si le ping vers un serveur échoue, le poids associé est bloquant tandis qu’une partition pleine à 98% n’aura qu’un impacte « mineur ».

Grâce à cette logique de calcul, la qualité de service (Qos) produite sera beaucoup plus fidèle à une réalité de disponibilité / indisponibilité .

Si Qos > 0%, alors SLA = Disponible. A l’inverse, si Qos = 0%, alors SLA = Indisponible. Ainsi, les seuils d’alertes doivent être par défaut les suivants :

  • Seuil dégradé : 99,99% ;
  • Seuil critique : 0%.

Certains cas sont bien entendus différents et les seuils de Qos seront différents. Cependant de manière générale, lors de la création de première BA ceux-ci doivent être appliqués.

Méthode d’implémentation

Le premier point est de créer une liste des indicateurs qui entrent dans la composition de la BA et de les trier en plusieurs catégories :

  • Les indicateurs clés dont on sait qu’ils ont un impact bloquant
  • Les indicateurs clés dont on ne sait pas mesurer l’impact

Puis de répartir uniquement les états ” Opérationnel ” et ” Critique ” des KPI, avec des impacts ” Nuls ” ou ” Bloquants ”.

Note

L’utilisation des autres seuils intermédiaires ou de l’impact dégradé sera faite plus tard, quand l’utilisateur possédera une bonne vision du fonctionnement de la BA au travers de ses indicateurs clés.

Calibrage des KPI et calcul de la SLA

C’est ensuite lors de l’usage quotidien du produit qu’il sera possible de consulter l’évolution réelle de la Qos dans le temps et de visualiser le véritable seuil de Qos en dessous duquel l’usage de l’application n’est plus opérationnel .

Lors d’une situation d’une application très dégradée, voir indisponible, d’une mise à jour impactant fortement l’application, d’un accident de production; il sera alors temps d’ajouter de nouvelles KPI, ou de pondérer les KPI qui étaient jusqu’ici nuls , à la lumière des nouvelles informations mise en évidence.

Concernant l’ajustement des seuils dégradés et critiques de la BA, prenons pour exemple une courbe de Qos qui oscillerait entre 80%et 100% avec au final une disponibilité tout à fait bonne. Il est possible que certains composantes qui provoquent des chutes sans que celles ci soient réellement représentatives d’un dysfonctionnement. L’administrateur pourra alors réviser son seuil d’alerte dégradé de la BA en le passant de 99.99% à 80%.

Ainsi les écrans de supervision temps réel des BA en seront allégés. L’alerte dégradée prendra alors réellement tout son sens. De la même manière, il est possible constater par la suite que, sans passer en alerte critique , le fonctionnement n’est pas convenable. L’observation de la Qos peut indiquer que un état critique alors que celle-ci est inférieur à 10%, il sera alors temps de remonter le seuil critique de la BA de 0% à 10%.

Cette méthode de calcul permet d’affiner et de rendre de plus en plus pertinente la mesure de la disponibilité, en tirant partie de la valeur de sa Qos.

Warning

Il est important de ne pas associer les seuils dégradé et critique d’une BA aux valeurs de SLA.

La valeur finale de la SLA est liée au temps passé dans les états opérationnels, dégradés/critiques (indisponibilité/disponibilité), visible dans les écrans de “reporting”.

Exemples :

  • Paramètre de BA dégradé : 80% ;
  • Paramètre de BA critique : 10% ;
  • Supervision 24x7 des indicateurs ;
  • Sur une période de 1 jour :
    • Temps passé de la Qos >= dégradé = 23h30 (Opérationnel)
    • Temps passé de la Qos <= critique = 0h10 (Dégradé)
    • Temps passé de la Qos > critique = 0h20 (Critique)

Dans le cas présent, ma SLA n’est ni 80%, ni 10% mais :

  • Temps disponible >= dégradé = 97,916% (Opérationnel)
  • Temps disponible <= critique = 0,694% (Dégradé)
  • Temps disponible > critique = 1,388% (Critique)