Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.




Contexte

L'interface de Visualisation fournie fournit une représentation de l'état d'un élément et de son taux de disponibilité. Le taux de disponibilité doit être configuré en fonction du statut d'un élément et de votre organisation. La configuration est globale à l'installation donc elle n'est pas configurable de manière indépendante sur les hôtes.

Cette page fournie fournit une description des options de configuration de ce calcul.

Les parties de l'interface de Visualisation impacté impactées par cette configuration sont les suivantes : 


Panel

Sommaire

Table of Contents


Description des paramètres de configuration

Configuration du calcul

Ici nous décrions les différents paramètre de la configuration du calcule du taux

du taux de disponibilité

On peut définit .Les paramètre ont 3 type d'impacte sur le taux de disponibilité

  • (tick) Le taux de disponibilité augmente
  • (error) Le taux de disponibilité baisse
  • (grey lightbulb) Le taux de disponibilité n'est pas impacté : La période est exclut du calcul du SLA
    Exemple : Pour une période de 2 heures, le calcul du SLA du jour sera en réalité effectué sur 22 heures.

Paramètre des états Warning : warning_counts_as_ok

L'état Warning peut être configuré de 2 manières différentes:

  • (tick) Le taux de disponibilité augmente : On considère que le service est toujours rendu même de manière potentiellement dégradée.
  • (error) Le taux de disponibilité baisse : On considère que le service n'est pas bien rendu.

Paramètre des états Unknown : unknown_period

L'état Unknown peut être configuré de 3 manières différentes:

  • (tick) Le taux de disponibilité augmente : On considère que le service à donnée un état donc le service est encore rendu même de manière potentiellement dégradée.
  • (error) Le taux de disponibilité baisse : On considère que si l'on ne peux savoir si le service est rendu c'est qu'il n'est pas rendu.
  • (grey lightbulb) Le taux de disponibilité n'est pas impacté : On considère l'état est trop imprécis pour modifier le taux de disponibilité.

Paramètre des états Missing dataShinken inactive : no_data_period

Les états Missing data & Shinken inactive ont été regroupés dans un paramètre. Ce paramètre correspond à la période durant 

L'état sans donné peut être configuré de 3 manières différentes:

  • (tick) Le taux de disponibilité augmente : On considère que même si la supervision ne la pas confirmer le service est rendu.
  • (error) Le taux de disponibilité baisse : On considère que si l'on ne peux savoir si le service est rendu c'est qu'il n'est pas rendu.
  • (grey lightbulb) Le taux de disponibilité n'est pas impacté : On considère que l'état de la supervision (de Shinken) n'impact pas le taux de disponibilité.

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.
  • dans Shinken Entreprise par le pourcentage de temps sur une période donnée pendant lequel l'élément est en statut OK. Tout statut différent de OK va donc faire baisser le taux de disponibilité.

    Il est possible de choisir si certains statuts sont interprétés comme OK dans le cadre du calcul de taux de disponibilité. Par exemple, un statut Warning peut être interprété comme un OK, car le service est rendu mais de manière dégradée, ou comme un Critique car le service n'est pas rendu de manière optimale. On veut donc pouvoir configurer, pour les différents statuts et contextes, comment ils vont être interprétés dans le calcul du taux de disponibilité. 


    La configuration du calcul du taux de disponibilité s'effectue directement par fichier de configuration. La modification des paramètres de calcul s'effectue dans le module sla, qui est chargé par le Broker.

    Le fichier de configuration correspondant est le suivant:

  • 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. Les SLA des jours précedents sont sauvegardés et ne sont par défaut pas recalculés.

    Après un changement dans les paramètres de calcul du SLA, on pourrait vouloir voir les anciens SLA calculés avec les paramètres nouvellement définis.

    Dans Shinken Entreprise, il est possible de dire au système de recalculer les anciens SLA avec l'option recompute_old_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.

    Les paramètres du fichier suivant correspondent dans l'ordre aux cas énumérés dans la partie précédente:

    Code Block
    title/etc/shinken/modules/sla.cfg
    warning_counts_as_ok     	0  ; Si 1, les Warning sont comptés comme OK, si 0 ils sont comptés comme Critique [par défaut 0]
    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    			0  ; 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]
    recompute_old_sla 			0  ; Si 1, les anciens SLA seront recalculés avec les paramètres de calcul actuels. Si 0, les anciens SLA ne seront pas recalculés [par défaut 0] 
     
    #  == Downtime periods ==
    #    - 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

    Contexte

    L'interface de Visualisation fournie une représentation de l'état d'un élément et de son taux de disponibilité. Le taux de disponibilité doit être configuré en fonction du statut d'un élément et de votre organisation. La configuration est globale à l'installation donc elle n'est pas configurable de manière indépendante sur les hôtes.

    Cette page fournie une description des options de configuration de ce calcul.

    Les parties de l'interface de Visualisation impacté par cette configuration sont les suivantes : 

    Panel

    Sommaire

    toc

    Dans ce fichier, un grand nombre de commentaires indiquent brièvement les différentes options disponibles. Ces options de configuration sont décrites de manière détaillée dans les section suivantes de ce document.

    Description des paramètres de configuration du calcul

    Ici nous décrions décrirons les différents paramètre paramètres de la configuration du calcule calcul du taux de disponibilité.

    Les paramètre ont 3 type d'impacte sur le taux de disponibilité : 

    • (tick) Le taux de disponibilité augmente
    • (error) Le taux de disponibilité baisse
    • (grey lightbulb) Le taux de disponibilité n'est pas impacté : La période est exclut du calcul du SLA
      Exemple : Pour une période de 2 heures, le calcul du SLA du jour sera en réalité effectué sur 22 heures.

    Chaque paramètre permet de modifier le comportement du calcul du taux de disponibilité en fonction du statut ou contexte rencontré. Aussi, chaque paramètre est indépendant.

    Paramétrage des états Warning

    L'état Warning peut avoir plusieurs significations, selon comment il est interprété.

    Paramètre des états Warning :
    Option du fichier cfgValeur de l'optionEffet sur le taux de disponibilitéExplication
    warning_counts_as_ok
    L'état Warning peut être configuré de 2 manières différentes:
    1

    (tick) Le taux de disponibilité

    augmente :

    augmente

    On considère que le service est toujours rendu même de manière potentiellement dégradée
    .
    warning_counts_as_ok0

    (error)

     Le

    Le taux de disponibilité

    baisse : On

    baisse 

    On considère que si le service n'est pas rendu de manière optimale, il n'est pas bien rendu et donc fait baisser le taux de disponibilité.


    Paramètre des

    Paramétrage des états Unknown

     : unknown_period

    L'état Unknown peut être configuré de 3 manières différentes:

    Option du fichier cfgValeur de l'optionEffet sur le taux de disponibilitéExplication
    unknown_periodok

    (tick) Le taux de disponibilité

    augmente :

    augmente

    On considère que le service
    à donnée
    a donné un état donc le service est encore rendu même de manière potentiellement dégradée
    .
    unknown_periodinclude

    (error) Le taux de disponibilité baisse 

    : On

    On considère que si l'on ne peux savoir si le service est rendu c'est qu'il n'est pas rendu.
    unknown_periodexclude

    (grey lightbulb) Le taux de disponibilité n'est pas

    impacté : On

    impacté 

    On considère l'état
    est
    trop imprécis pour modifier le taux de disponibilité.


    Paramètre des

    Paramétrage des états Missing dataShinken inactive

     : no_data_period

    Les états Missing data & Shinken inactive ont été regroupés dans un paramètre. Ce paramètre correspond à la période durant 

    laquelle

    durant laquelle Shinken n'a pas effectué les vérifications pour un check (plateforme Shinken éteinte, ou vérification du check désactivée grâce aux Périodes de temps). Le statut de ces checks est donc "Missing data" ou "Shinken inactive".

    L'état sans données peut L'état Unknown peut être configuré de 3 manières différentes:

    Option du fichier cfgValeur de l'optionEffet sur le taux de disponibilitéExplication
    no_data_periodok

    (tick)

     Le

    Le taux de disponibilité

    augmente :

    augmente

    On considère que même si la supervision ne l'a pas confirmé, le service
    à donnée un état donc le service est encore rendu même de manière potentiellement dégradée.
    est rendu
    no_data_periodinclude

    (error) Le taux de disponibilité baisse 

    : On

    On considère que si l'on ne peux pas savoir si le service est rendu, c'est qu'il n'est pas rendu
    .
    no_data_periodexclude

    (grey lightbulb) Le taux de disponibilité n'est pas

    impacté : On considère l'état est trop imprécis pour modifier le taux de disponibilité.

    Gestion des périodes de Downtime

    impacté 

    On considère que l'état de la supervision (de Shinken) n'impacte pas le taux de disponibilité


    Paramétrage du contexte Downtime

    Le context Downtime peut être configuré 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. Les SLA des jours précedents sont sauvegardés et ne sont par défaut pas recalculés.

    Après un changement dans les paramètres de calcul du SLA, on pourrait vouloir voir les anciens SLA calculés avec les paramètres nouvellement définis.

    Dans Shinken Entreprise, il est possible de dire au système de recalculer les anciens SLA avec l'option recompute_old_sla.

     

    Option du fichier cfgValeur de l'optionEffet sur le taux de disponibilitéExplication
    downtime_periodok

    (tick) Le taux de disponibilité augmente

    On considère que les périodes de maintenance planifiées font partie du service, donc le service est rendu

    downtime_periodcritical

    (error) Le taux de disponibilité baisse 

    On considère que lors d'une maintenance planifiée, le service n'est plus rendu

    downtime_periodexclude

    (grey lightbulb) Le taux de disponibilité n'est pas impacté 

    On considère que la maintenance est planifiée et donc que cette période n'impacte pas le service

    downtime_periodinclude

    (question) Le taux de disponibilité dépend de l'état de l'élément

    On considère que seul l'état du service compte pour le taux de disponibilité


    Paramétrage de recalcul des taux de disponibilité archivés

    Le taux de disponibilité des éléments est archivé quotidiennement.
    Par défaut un changement de paramétrage du calcul n'impactera pas les taux de disponibilité des jours précédant la modification.
    L'option recompute_old_sla permet de mettre à jour les taux de disponibilité archivés à jour à chaque changement de configuration. 

    Exemple d'un paramétrage du calcul du taux de disponibilité

    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.Les paramètres du fichier suivant correspondent dans l'ordre aux cas énumérés dans la partie précédente:


    Voici ci-dessous un exemple de configuration pour le calcul du taux de disponibilité. Dans cette configuration:

    • L'option de recalcul des anciennes données est commentée. La valeur par défaut sera donc prise, en l’occurrence, les taux de disponibilités déjà archivés ne seront pas recalculés.
    • Un statut "Warning" est compté positivement dans le calcul
    • Un statut "Unknown" est aussi compté positivement dans le calcul
    • Les statuts "Missing data" et "Shinken Inactive" sont exclus du calcul. Si on a une période de 2 heures avec un statut "Missing data" ou "Shinken Inactive", le taux de disponibilité de la journée ne sera calculé que sur 22 heures.
    • Les périodes de maintenances sont comptées négativement dans le calcul.


    Note

    Par défaut, les options sont commentées dans le fichier (précédées d'un dièse (#)). Pour qu'elles soient prises en compte, il faudra donc les dé-commenter.


    Code Block
    title/etc/shinken/modules/sla.cfg
    warning_counts_as_ok     	0  ; Si 1, les Warning sont comptés comme OK, si 0 ils sont comptés comme Critique [par défaut 0]
    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    			0  ; 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]
    recompute_old_sla 			0  ; Si 1, les anciens SLA seront recalculés avec les paramètres de calcul actuels. Si 0, les anciens SLA ne seront pas recalculés [par défaut 0] 
     # SLA are computed on a daily basis. SLA of the current day are always recomputed after a configuration change. SLA from days before are by default not recomputed.
    # If 1, old SLA will be recomputed with current settings.
    # If 0, old SLA will not be recalculated [default]
    # recompute_old_sla      0
    
    #======== SLA calculation ========
    # Some status can impact positively (counted as OK/UP), negatively (counted as CRITICAL/DOWN) or not impact the SLA
    # (is not counted, meaning the period of study is reduced by the period that is not counted).
    # This configuration aims at giving Shinken administrators a way to configure how the SLA are calculated.
    
    # If 1, Warning counts as UP
    # If 0, Warning counts as DOWN [default]
    warning_counts_as_ok   1
    
    #  == DowntimeUnknown periods ==
    #    - include:  LeOnly statutstatus estis prisconsidered. enUnknown comptestatus sansis tenircounted comptenegatively duin contextethe DowntimeSLA. [par défautdefault]
    #    - exclude:  LesUnknown statutsare pendantnot lescounted périodesfrom deSLA Downtime ne sont pas pris en compte pour le calculconsidered period
    #    - ok:       LeUnknown statutare pendantconsidered lesas périodes de Downtime est OK
    #    - critical: Le statut pendant les périodes de Downtime est Critique
    downtimeUP periods
    unknown_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

    Contexte

    L'interface de Visualisation fournie une représentation de l'état d'un élément et de son taux de disponibilité. Le taux de disponibilité doit être configuré en fonction du statut d'un élément et de votre organisation. La configuration est globale à l'installation donc elle n'est pas configurable de manière indépendante sur les hôtes.

    Cette page fournie une description des options de configuration de ce calcul.

    Les parties de l'interface de Visualisation impacté par cette configuration sont les suivantes : 

    Panel

    Sommaire

    Table of Contents

    Description des paramètres de configuration du calcul

    Ici nous décrions les différents paramètre de la configuration du calcule du taux de disponibilité.

    Paramètre :

    warning_counts_as_ok

     

    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. Les SLA des jours précedents sont sauvegardés et ne sont par défaut pas recalculés.

    Après un changement dans les paramètres de calcul du SLA, on pourrait vouloir voir les anciens SLA calculés avec les paramètres nouvellement définis.

    Dans Shinken Entreprise, il est possible de dire au système de recalculer les anciens SLA avec l'option recompute_old_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.

    Les paramètres du fichier suivant correspondent dans l'ordre aux cas énumérés dans la partie précédente:

    Code Block
    title/etc/shinken/modules/sla.cfg
    warning_counts_as_ok     	0  ; Si 1, les Warning sont comptés comme OK, si 0 ils sont comptés comme Critique [par défaut 0]
    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    			0  ; 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]
    recompute_old_sla 			0  ; Si 1, les anciens SLA seront recalculés avec les paramètres de calcul actuels. Si 0, les anciens SLA ne seront pas recalculés [par défaut 0] 
     ok
    
    #  == No_data periods ("Missing data" and "Shinken inactive" status) ==
    #    - include:  Only status is considered. "Missing data" and "Shinken inactive" status are counted negatively in the SLA. [default]
    #    - exclude:  No_data are not counted from SLA considered period
    #    - ok:       No_data are considered as UP periods
    no_data_period        exclude
    
    #  == Downtime periods ==
    #    - include:  LeOnly statutstatus est pris en compte sans tenir compte du contexte Downtime [par défautis considered. [default]
    #    - exclude:  LesDowntimes statutsare pendantnot lescounted périodesfrom deSLA Downtime ne sont pas pris en compte pour le calculconsidered period
    #    - ok:       LeDowntimes statutare pendantconsidered lesas périodes de Downtime est OKUP periods
    #    - critical: LeDowntimes statutare pendantconsidered lesas périodes de Downtime est CritiqueDOWN periods
    downtime_period    includecritical

     

    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