Qu'est ce qu'un cluster ?
Son rôle principal est de permettre d'avoir dans un seul indicateur l'état agrégé d'autres états. Cet indicateur propose une vue unique pour des utilisateurs jouant différents rôles.
Rôles typiques:
- Service delivery Management
- Business Management
- Engineering
- IT support
Prenons l'exemple d'un rôle de service delivery pour une application ERP . Il est principalement constitué de:
- 2 databases, en haute disponibilité, donc avec une seule base active, le service est considéré comme rendu
- 2 web servers, en partage de charge, donc avec un web server actif, le service est considéré comme rendu
- 2 load balancers, encore en haute disponibilité
Ces composants (Hôtes dans cet exemple) seront la base de ce service ERP .
Avec des règles métier, vous pouvez avoir une vue agrégée de l'indicateur représentant l'état du service ERP !
Shinken Enterprise vérifie chaque composant un par un pour l'analyse de problème source.
Accéder à la configuration du Cluster
L'accès à la configuration des Clusters se fait par le menu "Elements", disponible dans la barre de navigation.
Ce lien donne accès à la liste des Clusters, permettant d'en créer de nouveaux ainsi que de les modifier.
|
Logique de notification
Un Cluster a la même logique de notification que les hôtes.
Lors de la création/édition d'un Cluster, les notifications peuvent être configurées via l'onglet Notifications de la même manière que pour un hôte.
TODO: Lien vers une page de Doc qui explique comment configurer les notifications (si elle existe).
Définition minimaliste d'un Cluster
TODO: Expliquer les regles de bases (selection host, et services, sans regex ni rien)
Un Cluster va voir son état dépendre de ceux de ces éléments. Ces éléments peuvent être des Hôtes, des Checks, ou un mélange des deux. La définition des éléments du Cluster se fait par l'intermédiaire de la bp_rule.
La manière la plus simple de définir un Cluster est de lister un à un les Hôtes/Checks et de spécifier avec des opérateurs de logique booléenne le comportement du Cluster.
Deux opérateurs de bases sont disponibles pour définir l'agrégation des états: & et |
L'opérateur & semblable au ET classique renvoie le pire état des 2 éléments.
Par exemple, si un hôte hote_a est OK et qu'un hôte hote_b est Critique,
hote_a & hote_b |
renverra Critique.
L'opérateur | semblable au OU classique renvoie le meilleur état des 2 éléments.
Par exemple, si un hôte hote_a est OK et qu'un hôte hote_b est Critique,
hote_a | hote_b |
renverra OK.
Dans un cluster, on peut séléctionner 2 types d'éléments: des hôtes et des services.
L'état d'un hôte se récupère avec seulement le nom de l'hôte, et l'état d'un service se récupère avec le nom de l'hôte, puis le nom du service, séparé par un virgule.
Par exemple
hote_a,service_a |
Aussi, il est possible de configurer la priorité des opérateurs booléens avec des parenthèses.
Exemple de configuration d'une règle pour un cluster ERP
(srv-oracle-1 | srv-oracle-2) & (srv-http-1 | srv-http-2) & (srv-loadbalancer-1 | srv-loadbalancer-2) |
|
Utiliser les négations
On peut également vouloir vérifier qu'un hôte ou un service renvoie un statut Critique. Cela peut être utile dans le cas de configuration avec des éléments actifs et passifs par exemple.
Le caractère ! permet de prendre l'inverse de l'état de l'élément. Ainsi, on peut définir des règles comme la suivante:
(srv-oracle-1 & !srv-oracle-2) |
Le cluster sera donc en statut OK si l'hôte srv-oracle-1 est OK et l'hôte src-oracle-2 est Critical.
Groupement d'expressions
Parfois, on ne souhaite/peut pas spécifier précisément les hôtes contenus dans une règle. On peut dans les bp_rule grouper les éléments selon différents critères. On peut par exemple récupérer tous les hôtes appartenant à un certain groupe d'hôte, ayant un certain modèle d'hôte accrochés, ou encore récupérer les hôtes dont le nom remplit certains critères. Ces groupements sont disponibles également pour le checks.
Pour cela, il est possible d'utiliser des expressions groupées suivant cette syntaxe :
flag:expression |
Le flag est un simple caractère qualifiant le type d'expansion.
Les types supportés sont décrits dans les tables ci-dessous.
Flags pour les hôtes
| Flag | Signification | Exemple | Equivalence |
|---|---|---|---|
| g | Hôtes appartenant au groupe d'hôtes | g:web | web-srv1 & web-srv2 & ... |
| r | Hôtes dont le nom matche la regex | r:^web | web-srv1 & web-srv2 & ... |
| t | Hôtes ayant le modèle d'hôte | t:http | web-srv1 & web-srv2 & ... |
| tr | Hôtes ayant le modèle d'hôte qui matche la regex | tr:^http | web-srv1 & web-srv2 & ... |
Flags pour les checks
| Flag | Signification | Exemple | Equivalence |
|---|---|---|---|
| r | Checks dont le nom match la regex | r:^HTTPS? | web-srv1,HTTP & db-srv2, HTTPS & ... |
| t | Checks ayant le modèle de check | t:http | web-srv1,HTTP & db-srv2, HTTPS & ... |
| tr | Checks ayant le modèle de check qui marche la regex | tr:^http | web-srv1,HTTP & db-srv2, HTTPS & ... |
Exemple d'expressions combinées
Si vous souhaitez créer une règle incluant tous les web servers composant l'application frontend.
t:http,r:HTTPS? |
qui est équivalent à:
web-srv1,HTTP & web-srv3,HTTPS |
Vous devriez donc combiner l'expansion d'expression avec :
t:http,t:HTTPS? & db-srv1,MySQL |
qui est équivalent à:
(web-srv1,HTTP & web-srv3,HTTPS) & db-srv1,MySQL |
Ensembles d'éléments
On voudrait également pouvoir sélectionner les éléments qui remplissent plusieurs critères différents. C'est possible en définissant des ensembles.
Les ensembles sont définis en enveloppant une expression de crochets. Dans les ensembles, les opérations booléennes & et | utilisées n'ont pas le même sens, et sont équivalentes à des opérations sur des ensembles. Le tableau ci-dessous récapitule les significations des différents opérateurs dans les ensembles.
| Opérateur | Sens de l'opération |
|---|---|
| | | Union |
| & | Intersection |
| &! | Exclusion (privé de) |
Les ensembles peuvent être imbriqués pour permettre des définir des priorités d'évaluation.
Les opérateurs sont évalués dans l'ordre des sous parties, puis de gauche à droite.
Ainsi, l'expression
[ t:linux | tr:windows.* &! [t:linux & tr:windows.* ]] |
regroupe les hôtes ayant le modèle linux, ou un modèle commençant par windows, mais pas les deux.
TODO:
- Est ce que la syntaxe des opérateurs & et | est changée par && et || ?
La règle Xof
Dans certains cas, un cluster de N éléments nécessite d'avoir au moins X d'entre eux en état OK pour être considéré comme OK.
Pour spécifier ce type de comportement, il suffit d'utiliser l'opérateur "X of:".
La syntaxe de cet opérateur est la suivante:
Xof: expression |
L'expression X of: peut être configurée avec différentes valeurs en fonction du besoin. Les valeurs supportées pour X sont les suivantes:
- Un nombre entier positif, soit "au moins X hôtes doivent être up"
- Un pourcentage positif, soit "au moins X% d'hôtes doivent être up".
On peut combiner des expression groupées telles que "95% de mes web front ends doivent être up".. - Un nombre entier négatif, soit "au plus X hôtes doivent être down"
- Un pourcentage négatif, soit "au plus X% d'hôtes doivent être down".
On peut combiner des expression groupées telles que "5% de mes web front ends doivent être down"
(srv-oracle-1 | srv-oracle-2) & (srv-loadbalancer-1 | srv-loadbalancer-2) & 95% of: g:frontend
Xof: expression |
L'expression passée à l'opérateur Xof peut également être un ensemble. On peut par exemple avoir une règle du type:
Xof: expression |
Voici un exemple avec 3 http web servers, et au moins 2 d'entre eux en état OK :
(srv-oracle-1 | srv-oracle-2) & (2 of: srv-http-1 & srv-http-2 & srv-http-3) & (srv-loadbalancer-1 | srv-loadbalancer-2)
Xof: expression |
Gérer un état dégradé
La règle X,Y,Zof
TODO: Rediger avec des vraies phrases en francais
X,Y,Zof:
Ordre d'évaluation:
- Critique
- Warning + Critique
- OK
- Par defaut met en OK pour un cluster de services, met en ? pour un cluster d'hotes
La règle Xof configurable
TODO: Expliquer comment marche le Xof configurable