|
Clé d'import : use
Les modèles de cluster qui sont attachés au cluster pour hériter de leurs propriétés et leurs données.
L'ordre des modèles est important.
Le premier modèle qui définit une propriété définit la valeur de la propriété pour le cluster.
Si une propriété est définie directement sur le cluster, la valeur définie sera utilisée et pas celle du modèle.
Pour un administrateur de SI, certains modèles ne sont pas "visible" et ne seront pas disponibles dans la liste des choix. |
au plus important ( 5 => $$$$$$ )
La valeur par défaut est 2 ( *** ). |
Cela peut être pratique si vous désirez faire une description écrite détaillée de l'hôte du cluster, une procédure de reprise sur panne, ou toute autre information qui sera visible pour les autres membres de l'équipe.
Les caractères < > " ' sont interdits. Une URL qui ne commence pas par http:// ou https:// provoquera un compteur erreur
Un caractère non autorisé provoquera un compteur d'erreur
Une URL externe peut contenir le mot clé ##USER## qui sera remplacé par le nom de l'utilisateur courant dans l'interface de Visualisation |
Dans cette propriété, des données ( macro ) de ce cluster peuvent être utilisées dans l'URL.
|
Cet onglet définit des données qui pourront être utilisées en tant que Variable, notamment à l'utilisation de la Commande des checks attachés à ce cluster. Consulter ces pages pour plus d'information.
Si vous donnez un nom de donnée protégée à l'une de vos données, vous ne pourrez plus modifier ce nom par la suite.
Cette modification est interdite afin d'éviter qu'une donnée protégée devienne visible, en changeant son nom. |
La valeur de la donnée pouvant être longue, il est possible d'agrandir le champ de la valeur afin d'améliorer la lisibilité du champ.
Pour agrandir le champ de la valeur, il faut maintenir le clic sur l'icône
située en bas à droite du champ et réajuster verticalement.
L'agrandissement manuel du champ n'est pas disponible pour le navigateur Internet Explorer. Mais les champs avec des valeurs longues sont automatiquement agrandis jusqu’à une certaine taille lorsque la valeur du champ dépasse une ligne. |
|
|
Il est possible pour chaque cluster de définir qui peut voir, éditer, ou encore recevoir les notifications. Le fonctionnement de ce mécanisme est expliqué dans la page Droits d'accès à un cluster. Ces propriétés gèrent l'Héritage additif (le +).
|
Cet onglet détaille la liste des checks qui seront appliqués au cluster, et leur provenance (venant de quel modèle de cluster, ou directement appliqué au cluster) :
Pour chaque check, vous pourrez essayer le check depuis sa configuration actuelle afin de vérifier son résultat.
Les boutons dans la colonne [Essayer ce check] permettent d'évaluer ou d'essayer directement l'exécution d'un check, avec la résolution de ses données.
Le second bouton (roue crantée + icône play) permet d'évaluer et de simuler son exécution depuis la plateforme de configuration ( Synchronizer ). Cette exécution n'utilisera pas vos pollers. Vous pouvez donc utiliser ce bouton pour tester votre commande sans affecter vos serveurs pollers en production.
Le tableau récapitulatif présente les données récupérées, et le résultat de la commande en prenant en compte les éventuelles modulations.
|
Le troisième bouton (icône play) permet d'évaluer et de simuler son exécution directement sur les Pollers, comme lors de l'exécution normale sur votre architecture Shinken. Vous pouvez donc utiliser ce bouton pour tester votre commande sur votre environnement de production.
Le tableau récapitulatif présente les données récupérées, et le résultat de la commande en prenant en compte les éventuelles modulations.
Si votre check utilise des tags de Poller, l'exécution ne peut avoir lieu que si l'un des Pollers définis dans votre architecture dispose d'un tag de Poller correspondant à celui du check que vous essayez. Veuillez consulter la page Le Poller pour plus d'informations sur les tags de poller. |
|
Afin de tester au mieux vos checks, si une erreur survient pendant l'essai du check, celle-ci vous sera affichée à la place des résultats. |
Les checks ayant une commande de supervision bp_rule ne pourront pas effectuer d’évaluation ou d'essai. |
Certains checks peuvent être affichés en grisé avec le libellé "Caché'".
Cette situation se produit lorsque deux checks ayant le même nom sont attachés sur deux modèles de cluster attachés ou bien directement attachés sur le cluster.
Dans l'ordre d'attachement, le premier check sera donc visible et les autres seront cachés ( visibles pour l'utilisateur, mais grisé pour qu'il comprenne que seul le premier sera pris en compte et visible dans l'interface de visualisation).
Inverser l'ordre d'héritage de ces modèles de cluster inversera également le statut (caché / actif) des checks.
|
|
Clé d'import : notification_period
Cette propriété permet de définir la période de temps durant laquelle les notifications sont autorisées.
En dehors de cette période, aucune notification ne sera envoyée.
Par défaut, il n'y a pas de période de temps, et donc les notifications ne seront jamais bloquées.
Clé d'import : first_notification_delay
Cette propriété permet de définir combien de minutes Shinken doit attendre avant d'envoyer la première notification.
Ce temps additionnel peut être utilisé pour limiter une avalanche de notifications ; en effet, les clusters n'ont pas de gestion HARD/SOFT et leur état est donc susceptible de changer plus fréquemment.
Ce temps additionnel peut être mis à profit par les utilisateurs pour prendre en compte le cluster depuis l'interface de visualisation avant que la notification ne soit envoyée.
Par défaut la valeur est 0, ceci signifie que la première notification sera envoyée sans attendre. La limite est fixée à 2630880 (soit 5 ans).
Une valeur non numérique provoquera un compteur erreur
Clé d'import : escalations
Cette propriété permet de lier ce cluster à une ou plusieurs définitions d'escalade.
Si, au bout d'un certain temps, le cluster n'est toujours pas revenu OK ou pas pris en compte (Contexte ACKNOWLEDGE ou DOWNTIME), la règle d'escalade sera appliquée.
Cette propriété gère l'Héritage additif (le +).
Détection du FLAPPING activée
Clé d'import : flap_detection_enabled
Cette propriété permet de définir si la détection du Contexte FLAPPING est active sur le cluster.
Peut être:
Options de la détection du FLAPPING
Clé d'import : flap_detection_options
Cette propriété permet de définir quel statut du cluster sont pris en compte pour le calcul du % de FLAPPING.
C'est une combinaison de l'un ou de plusieurs valeurs:
Sortie du Contexte FLAPPING
Clé d'import : low_flap_threshold
Sur les 21 derniers statuts, chaque fois qu'un statut est différent du précédent (de OK à Warning par exemple), le % de FLAPPING augmente. Donc 10 changements représenteront un % de flapping de 50% et 20 représenteront 100%.
Si ce % calculé est inférieur au % de sortie du Contexte FLAPPING, alors le Contexte de l'hôte ne sera plus FLAPPING.
Entrée du Contexte FLAPPING
Clé d'import : high_flap_threshold
Sur les 21 derniers statuts, chaque fois qu'un statut est différent du précédent (de OK a Warning par exemple), le % de FLAPPING augmente. Donc pour 10 changements, cela représentera un % de FLAPPING de 50% et pour 20, cela représentera 100%.
Si ce % calculé est supérieur au % d'entrée dans le Contexte FLAPPING, alors le Contexte de l'hôte deviendra FLAPPING.
Il sortira de ce Contexte quand ce pourcentage calculé sera inférieur au % de sortie du Contexte FLAPPING.
Modulations d'impact métier
Clé d'import : business_impact_modulations
Cette propriété permet de définir une ou plusieurs modulations d'impact métier. Les modulations ont une période temps durant laquelle elles sont actives.
Pendant cette période, la valeur d'impact métier de l'hôte sera changée par celle de la modulation.
Cette propriété gère l'Héritage additif (le +).
Modulations de données
Clé d'import : macromodulations
Cette propriété permet de définir une ou plusieurs modulations de données. Les modulations ont une période temps durant laquelle elles sont actives.
Pendant cette période, les données de l'hôte seront changées par celle de la modulation.
Cette propriété gère l'Héritage additif (le +).
Modulations de résultats
Clé d'import : resultmodulations
Cette propriété permet de définir une ou plusieurs modulations de résultats. (maximum 4)
Les modulations de résultats redéfinissent le statut de sortie du cluster, en fonction de son statut initial, d'une période de temps, ou de sa sortie.
Cette propriété gère l'Héritage additif (le +).
Gestionnaire d'événements activé
Clé d'import : event_handler_enabled
Cette propriété permet de définir si Shinken va lancer une commande (définie par le paramètre commande de gestionnaire d'évènements) à des étapes spécifiques du statut du cluster:
Tag de Reactionner
Clé d'import : reactionner_tag
Cette propriété permet de définir le reactionner_tag du cluster.
Toutes les notifications sur le cluster seront exécutées que par les Reactionners qui ont cette valeur dans leur paramètre reactionner_tags.
Par défaut, la valeur de Tag de Reactionner est non taggé, donc les Reactionners n'ayant aucun reactionner_tag prendront en compte les checks d'un cluster non taggé, car la valeur par défaut pour les Reactionners est aussi non taggé.
Commande lancée par le gestionnaire d'événements
Clé d'import : event_handler
Cette propriété permet de définir la commande que lancera le gestionnaire d'évènements pour cet cluster.