Contexte
L'état des différents hôtes configurés dans Shinken Entreprise peut être visualisé dans l'interface de Visualisation. Il est possible de voir l'état instantané de l'hôte et de ses checks, ainsi que l'historique des états des éléments.
Shinken Entreprise calcule également le taux de disponibilité des éléments (SLA) et permet de l'afficher dans l'interface de Visualisation (voir Widget SLA).
Cependant, ce calcul de disponibilité dépend de l'organisation et des règles en place sur l'infrastructure du système supervisé.
Le calcul des SLA sont configurables dans Shinken Entreprise.
Cette configuration est globale à l'installation et n'est pas configurable de manière indépendante sur les hôtes.
| Panel | |
|---|---|
Sommaire
|
Paramètres du calcul
Les différents paramètres modifiables par l'administrateur de l'installation sont décrit dans la partie suivante. Pour choisir le comportement de Shinken Entreprise, les clés à utiliser et les fichiers de configuration sont décrits dans la partie
Prise en compte des états Warning
Les états Warning peuvent être interprétés de 2 manières différentes:
- Considéré comme un état OK, puisque le service est rendu, mais de manière potentiellement dégradée
- Considéré comme un état Critique, puisque le service n'est pas bien rendu
Prise en compte des états Unknown
De la même manière, l'état Unknown est ambigu pour calculer le taux de disponibilité. On peut:
- Le considérer comme un état Critique, puisqu'on ne peut pas affirmer que le service est rendu
- Ne pas le prendre en compte dans le calcul du SLA.
Pour une période Unknown de 2 heures, le calcul du SLA du jour sera en réalité effectué sur 22 heures.
Prise en compte des périodes d'inactivité de Shinken
Comme pour les Unknown, les périodes d'inactivité de Shinken ou les périodes peuvent ou pas être prises en compte dans le calcul.
Elles peuvent:
- Etre considérées comme un état Critique.
- Ne pas être prises en compte dans le calcul du SLA.
Gestion des périodes de Downtime
Les périodes de Downtime sont problématiques dans le calcul puisqu'elles peuvent être interprétées de 4 manières différentes:
Les périodes de maintenance peuvent:
- Etre ignorées du calcul de SLA.
Pour une période de Downtime sur un élément de 2 heures sur une journée, le calcul du SLA du jour sera en réalité effectué sur 22 heures. - Etre comptées dans le calcul du SLA.
Pendant les périodes de Downtime, le statut de l'élément sera utilisé pour le calcul du SLA. - Etre comptées en tant que statut OK.
Peu importe le statut de l'élément pendant la période de Downtime, un statut OK sera utilisé pour le calcul du SLA. - Etre comptées en tant que statut Critique.
Peut importe le statut de l'élément pendant la période de Downtime, un statut Critique sera utilisé pour le calcul du SLA.
Calcul du SLA du jour
Le SLA d'un élément est calculé de manière journalière. Ensuite, chaque journée de données utiles pour le calcul du SLA est archivée.
COMPORTEMENT ??? A voir avec les tests ce que fait exactement le parametre keep_daily_sla.
Configuration des paramètres de calcul du SLA
Le réglage de ces paramètres s'effectue au niveau du module SLA du Broker.
Le fichier de configuration concerné est /etc/shinken/modules/sla.cfg.
| Code Block | ||
|---|---|---|
| ||
warning_strict 1 ; Si 1, les Warning sont comptés comme OK, si 0 ils sont comptés comme Critique [par défaut 1]
exclude_unknown 0 ; Si 1, Les Unknown ne sont pas pris en compte dans le calcul du SLA, si 0, ils sont comptés comme Critique [par défaut 0]
exclude_no_data 1 ; Si 1, les périodes de données manquante ou Shinken inactif ne sont pas prises en compte dans le calcul du SLA. Si 0, ces périodes sont comptées comme Critique [par défaut 0]
# == downtime_period ==
# - include: Le statut est pris en compte sans tenir compte du contexte Downtime [par défaut]
# - exclude: Les statuts pendant les périodes de Downtime ne sont pas pris en compte pour le calcul
# - ok: Le statut pendant les périodes de Downtime est OK
# - critical: Le statut pendant les périodes de Downtime est Critique
downtime_period include |
Pour appliquer un changement de cette configuration, un redémarrage de l'Arbiter et du Broker sont nécessaires:
| Code Block |
|---|
service shinken-arbiter restart
service shinken-broker restart |