Je viens de rajouter dans Shinken deux options qui peuvent se révérer intéressantes : critical_is_warning et inverse_ok_critical.

Les deux options sont utiles pour remplacer des sur-chouches de checks comme negate ou nocritical.sh.

Le cas des serveurs de Qualifications

L'option critical_is_warning est utile pour les serveurs de Qualification. Il est en effet coutume d'avoir du rouge dans l'interface de supervision (et donc CRITICAL) si et seulement si c'est important et que cela demande une intervention immédiate. Mais que faire si le service remonte un état CRITICAL sur une machine de Qualification? Si deux erreurs arrivent sur l'interface, une sur un serveur de PROD, l'autre sur un serveur de Qualif, il va falloir regarder qui traiter en premier, et surtout connaître si les serveurs sont en Prod ou non. Pour les petits environnements point de problème, pour les plus gros, c'est plus difficile...

C'est pour cette raison qu'il peut être pratique de "déclasser" les résultats d'un service sur un serveur de Qualification de Critical en Warning. Un script comme nocritical.sh (si exit_code==2 -> exit_code=1) peut être utile.

Le problème est que l'on devait avoir des check_command dédiées pour cela. La moindre modification était double (version avec et sans nocritical.sh).

Avec critical_is_warning, l'administrateur va pouvoir tagguer une machine comme étant non critique. Ce paramètre sera hérité par les services (héritage implicite) si le service ne le défini pas déjà. Ainsi, il est possible d'avoir pour la plupart des services ce paramètre d'absent (et donc hérité de l'hôte, 0 par défaut) et certains services critiques partout (comme ceux concernant la sécurité) avec critical_is_warning à 0. Les hôte taggué critical_is_warning à 1 seront automatiquement, et avec les même services que les autres, limités au niveau Warning. sur une configuration comme la mienne, ceci divise tout simplement le nombre de service par deux, ce qui n'est pas négligeable :)

Les services clusters passifs

Une autre problématique classique concerne les services sur les services passifs de cluster. Ils ont besoin d'être l'inverse de l'actif. Ici il n'est pas possible d'imaginer un attribut sur l'hôte, car il est cluster pour un service, mais pas pour tous les autres de l'hôte (comme le CPU par exemple). Le paramètre inverse_ok_critical fait donc le même rôle que la célèbre sonde negate (code retours : 0->2, 2->0). Il s'applique sur un service. Il va permettre de ne plus avoir de duplication des check_command, mais ne règle pas le besoin de définition d'un nouveau service. Il n'est pas dit que ce paramètre soit la solution ultime à ce problème des clusters, mais c'est une première réponse à cette problématique.

Byebye negate, tu nous auras bien aidé.

Ordre d'application

Il peut y avoir un service taggué avec ces deux paramètres. Quid alors d'un résultat CRITICAL? Et bien c'est le critical_is_warning qui l'emporte. Mais il faut être un peu tordu pour mettre les deux à vrai dire...

NOTE 2021: et bah dans la vraie vie c'est beaucoup utilisé pour gérer des sondes où on a pas la main, ou alors qu'on a peur de modifier

Jean Gabès