Informatique décisionnelle (BI)

Avant de vous lancer étape par étape dans la mise en œuvre pratique de la BI, vous devez d'abord connaître quelques termes :

Chaque application formalisée avec BI est appelée une agrégation, car un état global est agrégé à partir de nombreux états individuels.

Une agrégation est construite sous la forme d’un « arbre » d’objets. Ces objets sont appelés nœuds. Les nœuds finaux — les feuilles de l’arbre — sont les ordinateurs hôtes et les services de vos instances Checkmk. Les nœuds restants sont des objets BI créés artificiellement.

Chaque nœud est créé par une règle. Cela s’applique également aux racines de l’arbre — le nœud de niveau supérieur. Ces règles déterminent quels nœuds sont en connexion avec un autre nœud, et comment l’état des nœuds supérieurs doit être déterminé à partir de leurs états.

Le nœud supérieur d’une agrégation — la racine de l’arborescence — est également généré par une règle. De cette manière, une règle peut générer plusieurs agrégations.

La manière la plus simple de comprendre cela est d’utiliser un exemple concret. Nous avons créé l’application Mystery spécialement pour illustrer cet article. Supposons qu’il s’agisse d’une application importante au sein d’une organisation non spécifiée. Entre autres, cinq serveurs et deux commutateurs réseau jouent un rôle important. Afin que vous puissiez mieux comprendre notre exemple, nous utiliserons des noms simples tels que srv-mys-1 ou switch-1. Le diagramme suivant donne un aperçu simple de la structure :

Si vous souhaitez suivre les étapes suivantes une par une, il vous suffit de reproduire les objets de supervision comme indiqué dans notre exemple. Pour un test, il suffit de cloner plusieurs fois un ordinateur hôte existant et de nommer les clones en conséquence. Plus tard, quelques services viendront s’ajouter au jeu, pour lesquels vous aurez alors le temps d’ajouter les ordinateurs hôtes correspondants à la supervision. Même là, vous pouvez encore tricher : grâce à de simples checks locaux, vous obtiendrez rapidement des services correspondants avec lesquels jouer.

Les ordinateurs hôtes apparaîtront alors comme suit dans la supervision :

Commencez par quelque chose de simple — avec l’agrégation significative la plus simple possible — une agrégation ne comportant que deux nœuds. Vous souhaitez ensuite résumer les états des ordinateurs hôtes switch-1 et switch-2. L’agrégation doit s’appeler Network et doit être OK lorsque les deux commutateurs sont disponibles. En cas de défaillance partielle, l’état doit passer à WARN, et si les deux commutateurs sont hors tension, à CRIT.

Pour commencer : configurez BI via Setup > Business Intelligence > Business Intelligence. La configuration des règles et des agrégations s’effectue au sein des packages de configuration — les packs BI. Ces packages sont non seulement pratiques car ils vous permettent de mieux gérer des configurations plus complexes — vous pouvez également appliquer des autorisations à un package et attribuer certains groupes de contacts — mais ils permettent même aux utilisateurs ne disposant pas de droits d’administrateur d’éditer certaines parties de la configuration. Mais nous y reviendrons plus tard…​

La première fois que vous appelez le module BI, cela devrait ressembler à ceci :

Un paquet intitulé « Default Pack » est déjà présent. Celui-ci contient une démonstration d’une agrégation qui résume les données d’un ordinateur hôte.

Pour cet exemple, il est préférable de créer un nouveau paquet — à l’aide du bouton « Add BI Pack » — que vous nommerez « Mystery ». Comme toujours dans Checkmk, spécifiez un identifiant interne (mystery) qui ne pourra pas être modifié ultérieurement, ainsi qu’un titre descriptif. L’option « Public » est nécessaire pour les autres utilisateurs s’il existe dans ce paquet des règles qu’ils souhaitent utiliser pour leurs propres règles ou agrégations. Comme vous souhaitez probablement mener vos expériences seul et en toute tranquillité, laissez cette option désactivée :

Une fois la création terminée, vous trouverez bien sûr deux paquets dans la liste principale :

Chaque entrée est accompagnée d’une icône () permettant d’éditer les propriétés, et d’une icône permettant d’ouvrir le contenu réel du paquet (), où vous souhaitez vous rendre maintenant. Une fois sur place, créez immédiatement votre première règle via Add rule.

Comme toujours dans Checkmk, cette règle doit également disposer d’un identifiant unique et d’un titre. Le titre de la règle a non seulement une fonction de documentation, mais il sera également visible ultérieurement en tant que nom du nœud qui sera créé par cette règle :

La case suivante s’intitule « Child Node Generation » et est la plus importante. C’est ici que vous spécifiez quels objets de ce nœud doivent être regroupés. Il peut s’agir soit d’autres nœuds BI — pour lesquels vous choisiriez une règle BI différente — soit d’objets sous supervision, c’est-à-dire des ordinateurs hôtes ou des services.

Pour le premier exemple, sélectionnez la deuxième variante (State of a host) et créez deux objets en tant qu’enfants, à savoir les deux hôtes switch-1 et switch-2. Pour ce faire, utilisez le bouton « Add child node generator ». Ici, vous choisissez naturellement « State of a host » et saisissez un nom pour chaque hôte :

Dans la troisième et dernière case, Aggregation Function, vous spécifiez comment le statut de la supervision du nœud doit être calculé. La base pour cela est toujours la liste des états des sous-nœuds. Diverses relations logiques sont possibles.

L'option Best — take the best of all node states est présélectionnée. Cela signifierait que le nœud devient CRIT lorsque tous les sous-nœuds sont CRIT ou DOWN. Comme mentionné ci-dessus, cela ne devrait pas être le cas ici. Choisissez plutôt Count the number of nodes in state OK pour prendre comme référence le nombre de sous-nœuds ayant l'état OK. Ici, les chiffres 2 et 1 sont suggérés pour les valeurs seuils. C'est parfait, car c'est exactement ce dont vous avez besoin :

Voici à quoi ressemblera le formulaire une fois rempli :

En cliquant sur « Create », vous obtiendrez votre première règle :

Remarque — il est important de comprendre qu’une règle n’est pas encore une agrégation. Checkmk ne peut pas encore savoir s’il s’agit de l’ensemble ou seulement d’une partie d’une arborescence plus grande. Les véritables objets BI ne seront créés et ne deviendront visibles dans l’interface de suivi d'état que lorsque vous créerez une agrégation. Pour ce faire, passez à la liste des agrégations « ».

Le bouton « » vous amène à un formulaire permettant de créer une nouvelle agrégation. Il y a peu de champs à remplir ici. Dans le champ « Aggregation groups », vous pouvez saisir le nom de votre choix. Ces noms apparaissent ensuite dans l’interface de suivi d'état sous forme de groupes, sous lesquels toutes les agrégations partageant ce nom de groupe deviennent visibles. Il s’agit en fait du même concept que pour les hashtags ou les mots-clés. Vous pouvez également attribuer librement l’Aggregation ID, comme d’habitude, mais vous ne pourrez pas la modifier par la suite.

Vous définissez le contenu de l'agrégation via Add new element. Sélectionnez le paramètre Call a rule et, dans Rule:, la règle que vous venez de créer (et avant le paquet de règles dans lequel elle se trouve).

Si vous enregistrez maintenant l'agrégation via , vous avez terminé ! Votre première agrégation devrait désormais apparaître dans l'interface de suivi d'état — à condition que vous disposiez effectivement d'au moins un des ordinateurs hôtes, switch-1 ou switch-2.

Si vous avez tout fait correctement, vous devriez désormais pouvoir voir votre première agrégation dans l'interface de suivi d'état. Le moyen le plus simple d'y parvenir est d'utiliser Monitor > Business Intelligence > All Aggregations :

Examinez de plus près l'apparence de l'arborescence BI. L'exemple suivant montre votre mini-agrégation dans une situation où l'un des deux commutateurs est DOWN et l'autre UP. Comme souhaité, l'agrégation passe à l'état WARN :

Vous pouvez également constater que, afin de normaliser les ordinateurs hôtes et les services, l’ordinateur hôte DOWN est traité presque comme un service CRIT. De même, UP devient OK.

Les feuilles de l'arborescence indiquent les états des ordinateurs hôtes et des services. Le nom de domaine — et, pour les services, également le nom du service — est cliquable et vous redirige vers l'état actuel de l'objet correspondant. De plus, vous pouvez également voir la dernière sortie du plugin de supervision.

À gauche de chaque agrégation, vous trouverez deux icônes : et . La première icône — — vous amène à une page qui affiche uniquement cette agrégation. Cela s’avère naturellement très utile si vous avez créé plusieurs agrégations. Cette fonction est, par exemple, particulièrement adaptée pour créer un signet. vous amène au calcul de la disponibilité. Nous y reviendrons plus tard.

À gauche du nom de domaine, vous trouverez une icône intéressante : . Elle permet d’effectuer une analyse « et si ? ». Le principe est simple : en cliquant sur l’icône, l’objet passe à un autre état à titre de test — mais uniquement pour l’interface BI — pas dans la réalité ! Plusieurs clics vous feront passer de (OK) à (WARN), puis à (CRIT) et (UNKNOWN), avant de revenir à .

BI construit ensuite l'arborescence complète en fonction de l'état supposé. Le graphique suivant illustre l'agrégation minimale en partant de l'hypothèse que, outre switch-1 qui est effectivement en panne, switch-2 serait également DOWN :

L'état global de l'agrégation passe ainsi de WARN à CRIT. Dans le même temps, la couleur de l'état est accompagnée d'un motif en check. Ce motif vous indique que l'état réel est en fait différent. Ce n'est pas toujours le cas, car certaines modifications apportées à un ordinateur hôte ou à un service ne sont plus pertinentes pour la condition globale — par exemple, si celui en question est déjà CRIT.

Vous pouvez utiliser cette analyse « et si ? » de plusieurs façons, par exemple :

Dans ce dernier cas, à titre de test, vous définissez l’état de l’appareil à entretenir ou de ses services sur « ». Si l’agrégation dans son ensemble reste alors « OK », cela signifie que la défaillance peut actuellement être compensée par la redondance.

Il existe une autre façon de tester les agrégations BI : en modifiant directement l'état réel d'un objet. Ceci est particulièrement pratique dans un système de test.

À cette fin, les instructions disposent d’une instruction hôte/service nommée Fake check results. Par défaut, celle-ci n’est disponible que pour le rôle Administrateur. Cette méthode a été utilisée, par exemple, pour la création des captures d’écran utilisées dans cet article, où switch-1 a été défini sur DOWN. C’est de là que provient le texte révélateur « Manually set to Down by cmkadmin ».

Voici une petite astuce utile : Si vous utilisez cette méthode, il est préférable de désactiver les vérifications actives pour les ordinateurs hôtes et services concernés, sinon, lors du prochain intervalle de vérification, ils reviendront immédiatement à leur état réel. Si vous êtes paresseux, effectuez simplement cette opération de manière globale via le snap-in « Master Control ». Mais n’oubliez surtout pas de la réactiver par la suite !

Lors de la création de l'agrégation, nous avons brièvement abordé les possibilités disponibles pour le champ « Aggregation Groups ». Dans l'exemple, vous avez simplement confirmé l'Main suggérée ici. Vous êtes bien sûr entièrement libre dans l'attribution des noms, et vous pouvez également affecter une agrégation à plusieurs groupes.

Les groupes prennent toute leur importance lorsque le nombre d’agrégations dépasse ce que vous souhaitez afficher à l’écran. Pour accéder à un groupe, cliquez sur l’un des noms de groupe affichés sur la page « All aggregations » — dans notre exemple ci-dessus, il s’agit simplement de l’en-tête « Main ». Bien sûr, si vous ne disposez pour l’instant que de cette seule agrégation, cela ne changera pas grand-chose. Cependant, si vous y regardez de plus près, vous remarquerez que :

Si vous souhaitez consulter cette vue plus souvent, il vous suffit de l'ajouter à vos favoris — de préférence avec l'élément « Bookmarks » dans la barre latérale.

Une fois que vous avez configuré les agrégations BI, vous trouverez une nouvelle icône « » dans le menu contextuel de vos ordinateurs hôtes et services :

Cette icône vous permet d'accéder à la liste de toutes les agrégations dans lesquelles l'ordinateur hôte ou le service concerné est inclus.

Maintenant que vous disposez d’une arborescence un peu plus intéressante, vous pouvez vous familiariser davantage avec les différentes options d’affichage proposées par Checkmk. Le point de départ pour celles-ci est l’option « Modify display options », accessible via le menu « Display ». Cela ouvre une case contenant diverses options. Le contenu de cette case correspond toujours aux éléments affichés sur la page. Dans le cas de la BI, vous disposez actuellement de quatre options :

Enfin, vous pouvez définir une Refresh interval de 30, 60 ou 90 secondes et spécifier le nombre de colonnes via Entries per row.

Outre les représentations tabulaires, Checkmk maîtrise également la visualisation des agrégations BI. Vous pouvez ainsi visualiser les agrégations sous un angle nouveau, et parfois plus clair. Vous trouverez l’BI Visualization via dans la vue des agrégations standard.

Vous pouvez déplacer librement l’arborescence en cliquant sur l’arrière-plan et zoomer sur l’ensemble de l’affichage à l’aide de la molette de la souris. Dès que le pointeur de la souris survole un nœud individuel, vous obtenez les informations d’état associées à ce nœud via une fenêtre contextuelle. Utilisez la molette de la souris pour zoomer sur la longueur des branches de l’arborescence.

Cliquer sur les nœuds feuilles vous amène directement aux vues détaillées de l’ordinateur hôte ou du service. Un clic droit sur les autres nœuds — selon le type de nœud — donne accès aux options d’affichage et, par exemple, à la règle responsable elle-même — Edit rule dans l’image ci-dessous.

Poursuivons la configuration. Il est maintenant temps de passer aux choses sérieuses. Jusqu’à présent, l’exemple était si simple qu’il était possible de créer une liste individuelle de tous les objets de l’agrégation BI sans difficulté. Mais que se passe-t-il si les choses se compliquent ? Que faire si vous souhaitez définir de nombreuses dépendances récurrentes qui sont identiques ou similaires ? Que faire si une application comprend non pas un seul, mais plusieurs instances ? Que faire si vous souhaitez fusionner des centaines de services individuels d’une base de données en un seul nœud BI ?

Pour répondre à de telles exigences, vous aurez besoin de méthodes de configuration plus puissantes. Et c’est précisément ce qui distingue Checkmk BI des autres outils — et malheureusement, la courbe d’apprentissage est ici un peu plus raide. C’est également la raison pour laquelle Checkmk BI ne se prête pas à une configuration par « glisser-déposer ». Cependant, une fois que vous aurez découvert toutes ces possibilités, vous ne voudrez certainement plus vous en passer.

Commençons par les paramètres. Prenons la situation suivante : vous souhaitez non seulement savoir si les deux commutateurs sont UP, mais également connaître l’état des deux ports responsables de la liaison montante. D’une manière générale, cela dépend des quatre services suivants :

Le nœud Switch 1 & 2 doit désormais être étendu pour remplacer les deux états d’hôte des commutateurs 1 et 2, de sorte que chacun dispose d’un sous-nœud indiquant l’état d’hôte et les deux interfaces de liaison montante. Ces deux sous-nœuds devraient être Switch 1 ou Switch 2.

En fait, vous aurez désormais besoin de deux nouvelles règles — une pour chaque commutateur. Il est préférable de procéder en créant une nouvelle règle d’switch, et de la doter d’un paramètre. Ce paramètre est une variable que vous appelez lorsque vous appelez la règle depuis le nœud parent — qui, ici, peut être fournie par l’ancienne règle Switch 1 & 2. Dans cet exemple, vous pouvez simplement passer soit un 1, soit un 2. Le paramètre reçoit un nom que vous pouvez choisir librement. Prenons ici, par exemple, le nom NUMBER. L’orthographe en majuscules ici est purement arbitraire, et si vous trouvez les minuscules plus esthétiques, vous êtes également libre de les utiliser.

L'en-tête de la règle ressemblera alors à ceci :

Vous pouvez choisir switch comme ID pour la nouvelle règle. Dans le champ « Parameters », saisissez simplement le nom de la variable : NUMBER. Il est également important que la variable soit utilisée dans l’Rule Title de la règle afin que les deux nœuds ne s’appellent pas simplement switch et aient ainsi le même nom. Lors de l’utilisation de la variable, un signe dollar est ajouté au début et à la fin — comme c’est souvent le cas dans Checkmk. En conséquence, les deux nœuds s’appelleront alors Switch 1 et Switch 2.

Le sujet des expressions régulières mérite à nouveau qu’on s’y attarde. Lors de la correspondance du nom du service, nous avons tacitement sous-entendu au début qu’il ne s’agissait en principe que d’expressions régulières. Comme nous venons de le mentionner, il existe une correspondance de préfixe.

Ainsi, dans un nœud BI, si, par exemple, vous spécifiez disk sous « nom du service », tous les services de l’ordinateur hôte en question commençant par Disk seront capturés.

Les principes suivants s'appliquent généralement :

Cela vous semble peut-être un peu audacieux au premier abord, car n’est-il pas risqué d’omettre simplement, sans commentaire, des éléments qui devraient être présents ?

Eh bien, avec le temps, vous remarquerez à quel point ce concept est pratique, car cela vous permettra d'écrire des règles « intelligentes » capables de réagir à des situations très différentes. Existe-t-il un service qui n'est pas présent sur toutes les instances d'une application ? Pas de problème : il ne sera pris en compte que s'il est présent. Ou bien des ordinateurs hôtes ou des services peuvent-ils être temporairement retirés de la supervision ? Ils disparaissent alors simplement de BI sans entraîner d'erreurs ou autres. BI n’est pas là pour vérifier si votre configuration de supervision est complète !

Soit dit en passant, ce principe s’applique également aux services explicitement définis, puisque ceux-ci n’existent pas réellement, les noms des services étant toujours considérés comme des expressions régulières, même s’ils ne contiennent pas de caractères spéciaux tels que .*. Il s’agit toujours automatiquement d’un modèle de recherche.

Mais vous pouvez encore automatiser davantage et, surtout, réagir avec souplesse aux changements. Reprenons l’exemple des deux serveurs d’applications srv-mys-1 et srv-mys-2 de l’exemple précédent. Votre arborescence devrait continuer à s’étendre. Le nœud Infrastructure devrait passer au niveau 2. Et en tant que racine définitive, il devrait y avoir une règle intitulée The Mystery Application sous laquelle tout sera regroupé. À côté de Infrastructure, il devrait y avoir un nœud nommé Mystery Servers. Les deux serveurs « mystères » (pour l’instant) sont censés être regroupés sous ce nœud. Dans chacun d’eux, quelques services génériques sont intégrés à l’agrégation. Le résultat devrait ressembler à ceci :

Tout comme pour la recherche d'ordinateur hôte, il existe également un type de générateur de nœuds enfants appelé Create nodes based on a service search. Voici un exemple :

Vous pouvez utiliser () ici – en encadrant des expressions partielles – à la fois au niveau de l'ordinateur hôte et au niveau du service, où :

Et n'oubliez jamais que vous pouvez toujours utiliser pour obtenir de l'aide en ligne.

Au cours de vos essais, vous êtes peut-être tombé sur le générateur de nœuds enfants State of remaining services. Celui-ci génère un nœud pour chacun des services de votre hôte qui n’ont pas encore été classés dans votre agrégation BI. Cela s’avère utile si vous utilisez BI pour regrouper les états de tous les services d’un hôte en groupes clairement organisés, comme c’est le cas dans notre exemple fourni.

Revenons aux ensembles de règles. Pour toutes les actions d'édition dans BI, vous devez généralement disposer du rôle d'administrateur. Plus précisément, pour BI, il existe deux autorisations, qui se trouvent sous Setup > Users > Roles & permissions:

Dans le rôle d’utilisateur de supervision standard, seule la première de ces deux autorisations est active par défaut. Les utilisateurs de supervision standard ne peuvent donc travailler que sur les ensembles de règles pour lesquels ils ont été définis comme contact. Cette configuration s’effectue dans les détails de l’ensemble de règles sous .

Dans l’exemple suivant d’Permitted Contact Groups, le groupe de contact « The Mystery Admins » a été autorisé — ainsi, tous les membres de ce groupe peuvent désormais éditer les règles de ce paquet :

Par ailleurs, grâce à l’Public > Allow all users to refer to rules contained in this pack, vous pouvez autoriser d’autres utilisateurs à au moins utiliser les règles contenues ici — c’est-à-dire à définir (ailleurs) leurs propres règles — qui peuvent ensuite invoquer ces règles en tant que sous-nœuds.

Qu'en est-il de la visibilité effective des agrégations dans l'interface de suivi d'état ? Quels contacts sont autorisés à voir quoi ?

Eh bien, vous ne pouvez attribuer aucune autorisation dans les agrégations BI elles-mêmes. Cela s’effectue indirectement via la visibilité des ordinateurs hôtes et des services, et est régi par l’option « See all hosts and services » sous « Setup > Roles & Permissions: »

Dans le rôle «User», cette autorisation est désactivée par défaut. Les utilisateurs normaux ne peuvent voir que les hôtes et services partagés, et dans BI, cela se traduit par le fait qu’ils peuvent voir exactement toutes les agrégations BI qui contiennent au moins un hôte ou un service partagé. Ces agrégations ne contiennent toutefois que ces objets autorisés, et elles peuvent donc être quelque peu «allégées». Cela signifie en retour qu’elles peuvent présenter des états différents selon les utilisateurs.

Que cela soit une bonne ou une mauvaise chose dépend de ce que vous souhaitez. En cas de doute, vous pouvez activer ou désactiver cette autorisation et, en passant par BI, permettre à certains ou à tous les utilisateurs de voir les ordinateurs hôtes et les services pour lesquels ils ne sont pas des contacts — et ainsi vous assurer que l'état d'une agrégation BI est toujours le même pour tout le monde.

Bien sûr, toute cette question n’a d’importance que s’il existe effectivement des agrégations si hétéroclites que seuls certains utilisateurs sont contacts pour des parties spécifiques de celles-ci.

Comment BI gère-t-elle concrètement les périodes de maintenance planifiées pour ? Nous avons longuement réfléchi à cette question et en avons discuté avec de nombreux utilisateurs ; voici le résultat :

Pour comprendre selon quelle règle BI calcule l’état « en période de maintenance », il est utile de rappeler la véritable idée qui sous-tend les périodes de maintenance planifiées : l’objet en question fait actuellement l’objet de travaux. Des défaillances sont à prévoir. Même si l’objet est actuellement en état « OK », vous ne devez pas vous y fier. Il peut passer à l’état « CRIT » à tout moment. Ce phénomène est connu et documenté — il ne devrait donc pas déclencher de notification.

Ce principe peut être transposé tel quel dans BI : Dans l'agrégation, il peut y avoir quelques ordinateurs hôtes et services qui sont actuellement en période de maintenance. Que ceux-ci soient simplement « OK » ou « CRIT » n’a aucune importance, car c’est en réalité une coïncidence si, pendant la période de maintenance, les objets s’éteignent et se rallument parfois, ou non. Le simple fait qu’il y ait un objet en panne dans l’agrégation ne signifie pas immédiatement que l’application qui effectue l’affectation de l’agrégation est elle-même « menacée » et doit également être marquée comme « en période de maintenance ». L’application peut également disposer d’une redondance intégrée qui compense la défaillance des objets en période de maintenance. Ce n’est que si une telle défaillance conduisait effectivement à un état d’CRITe pour l’agrégation — c’est-à-dire s’il n’y a pas suffisamment de redondance et que l’agrégation est réellement menacée — que Checkmk la marquera comme « en période de maintenance ». Ici aussi, l’état actuel des objets n’a généralement aucune importance.

Pour être plus précis, la règle exacte est la suivante :

Si un état d’CRITion d’un ordinateur hôte/service entraînerait un état d’CRITion de l’agrégation, un état « en période de maintenance » de cet ordinateur hôte/service entraîne un état « en période de maintenance » pour l’agrégation.

Important : l’état réel actuel des ordinateurs hôtes/services ne joue aucun rôle dans le calcul — ce qui est en période de maintenance est considéré comme « in CRIT » dans la logique BI. Pourquoi ? Parce qu’un état « UP » ou « OK » pendant une période de maintenance planifiée est une pure coïncidence, par exemple si un ordinateur hôte signale « UP » pendant quelques secondes entre plusieurs redémarrages.

Et voici un autre exemple. Pour gagner de la place, voici une variante avec un seul serveur mystérieux au lieu de deux :

Tout d’abord, l’ordinateur hôte switch-1 est en période de maintenance. Pour le nœud Infrastructure, cela n’a aucun effet, car switch-2 n’est pas en période de maintenance, et donc Infrastructure n’est pas non plus en période de maintenance. Il n’y a donc pas d’icône pour les périodes de maintenance dérivées.

Cependant, le service Memory sur srv-mys-1 est également en période de maintenance. Celui-ci n'est pas redondant. La période de maintenance est donc héritée par le nœud parent Mystery Server 1, puis se propage jusqu'à Mystery Servers, et enfin jusqu'au nœud supérieur The Mystery Application. Ce nœud supérieur sera donc également en période de maintenance.

Nous avons indiqué plus haut qu’il n’était pas possible de mettre manuellement une agrégation BI en période de maintenance planifiée ? Ce n’est qu’à moitié vrai, car il existe en réalité une instruction permettant de définir des périodes de maintenance planifiées dans les agrégations BI. Mais cela ne fait rien de plus que d’enregistrer une entrée de période de maintenance pour chaque ordinateur hôte et service de l’agrégation. Cela conduit bien sûr généralement à ce que l’agrégation elle-même soit signalée comme étant en période de maintenance, mais il ne s’agit là que d’une procédure indirecte.

Vous avez vu plus haut que le calcul des périodes de maintenance planifiées repose sur un état d'CRIT supposé. Dans les propriétés d'une agrégation, vous pouvez personnaliser l'algorithme de manière à ce qu'un nœud qui prend l'état d'WARN soit marqué comme étant en période de maintenance. L'option correspondante s'appelle « Escalate downtimes based on aggregated WARN state » :

L'hypothèse de base reste que les objets en période de maintenance sont en état « CRIT ». La seule différence réside dans le fait que, selon la fonction d'agrégation, un état « CRIT » peut devenir un état « WARN » — comme ce fut le cas dans notre tout premier exemple avec Count the number of nodes in state OK. Ici, une période de maintenance planifiée aurait déjà été acceptée si un seul des deux commutateurs avait été en période de maintenance.

Tout comme pour le processus des périodes de maintenance planifiées, si un problème a été reconnu, l’information sera également calculée automatiquement par BI. Dans ce cas, l’état des objets joue certainement un rôle.

L'idée ici est de transposer le concept suivant dans BI : Un objet présente un problème (WARN, CRIT), mais celui-ci est connu et quelqu'un y travaille ().

Vous pouvez calculer cela pour une agrégation comme suit :

Toutefois, si l'agrégation devait rester en état « WARN » ou « CRIT », elle ne serait pas considérée comme ayant reçu la confirmation, car il y aurait alors au moins un problème important qui n'aurait pas reçu la confirmation, et l'état « OK » serait donc supprimé de l'agrégation.

À ce propos, l' vous proposera une instruction permettant à l'agrégation BI de valider ses problèmes, mais cela signifie uniquement que tous les ordinateurs hôtes et services détectés dans l'agrégation seront validés (uniquement ceux qui présentent actuellement des problèmes).

L'utilisation de la fonction de gel est très simple : Activez l'option « New aggregations are frozen » dans « Aggregation Properties ».

Cela gèlera l'agrégation lors de son enregistrement — et le fera chaque fois que la case sera cochée ; même si l'agrégation existait déjà auparavant (malgré la référence à « New aggregations …​ »). Pour débloquer le statut gelé, ne cochez pas la case en conséquence.

Dans la supervision, vous verrez désormais une nouvelle icône en forme de flocon de neige « » à côté de l’agrégation. Cela vous mènera à la vue de la table affichant les différences : à gauche, l’arborescence gelée ; à droite, l’arborescence actuelle avec les modifications mises en évidence (ici, la suppression du service backup3) :

Si vous souhaitez à nouveau geler l'état actuel, vous pouvez le faire via Commands > Freeze aggregations. Mais attention : il n'y a toujours qu'un seul état actuel gelé et aucun historique, y compris les états antérieurs.