Aller au contenu

Gestion des silences#

Introduction#

Les alertes sont générées par des Prometheus et gérées par des Alertmanagers. Voici les architectures et la nomenclature des labels utilisés pour les alertes et donc pour les silences :

La pose de silences s'effectue en connaissance de ces architectures.

Dans le contexte de supervision de l'infrastructure NGOT/Caascad et afin de visualiser ces alertes, il a été choisi d'utiliser :

  • Karma comme interface graphique utilisateur ;
  • Amtool comme interface en ligne de commande.

Ces mêmes outils servent également à la gestion des silences.

Logiciels#

Karma#

Karma est un outil de visualisation des alertes venant d’Alertmanager, permettant de donner un état de sévérité, ainsi qu’une description sur les alertes récupérées.

Karma est accessible depuis les URL suivants :

La gestion des silences avec l'outil Karma est documenté ici.

Amtool#

Amtool est l'interface en ligne de commande d'Alertmanager.

La gestion des silences avec l'outil Amtool est documenté ici.

Types de silences#

Silence de type Downtime#

Ce type de silence a une date de début et de fin indiquées lors de sa création. Toute alerte se manifestant pendant la durée du silence ne sera pas visible. En dehors de cette période, toute alerte sera levée et correspondra à un incident.

Ce type de silence est bien adapté aux interventions prévisibles à l'avance.

Il ne convient pas aux incidents en cours de résolution car la date de fin n'est pas connue.

Cependant, lorsqu'une alerte bagotte, il n'est pas possible d'utiliser un silence de type Acknowledgement. Il faut donc se rabattre sur un silence de type Downtime qu'on prolongera manuellement si nécessaire, et qu'on supprimera également manuellement si la résolution intervient avant la fin du silence.

Silence de type Acknowledgement#

Ce type de silence s'utilise en cas d'incident lorsque l'alerte est déjà levée et que la date de résolution de l'incident n'est pas connue. Il se pose immédiatement et ne prend fin que lorsque l'alerte disparaît.

Ce type de silence est bien adapté aux cas d'incidents qui durent dans le temps.

Cependant, il n'est pas utilisable lorsque l'alerte bagotte.

Note

Alertmanager ne gère pas ce type de silences. Nous utilisons un outil tiers, Kthxbye, qui sera en charge de prolonger (de 15 minutes) tout silence dont :

  • le commentaire est préfixé de ACK! ;
  • l'alerte est toujours présente.

Format du commentaire des silences#

Les silences sont analysés régulièrement par l'outil Silence Cop. Cet outil a pour objectifs :

  • de vérifier la pertinence des silences (en particulier de montrer ceux faisant référence à des tickets Jira "finis") ;
  • de fiabiliser cette vérification avec des outils.

Il existe 3 types de silences considerés valides :

  • Type 1 : référence à un ticket JIRA ;
  • Type 2 : silences courts (< 4h) ;
  • Type 3 : exceptions.

Type 1 : référénce à un ticket Jira#

Règles :

  • le commentaire doit contenir une référence à au moins un ticket JIRA :
    • le ticket JIRA doit être de type PF, CAASINC ou CAASCHR ;
    • le ticket JIRA ne doit pas être en état “fini”.
  • le commentaire peut contenir quelques mots d’explication complémentaires ;
  • le commentaire peut avoir le préfixe ACK!.

Type 2 : silences courts (<4h)#

Ce type de silence est posé dans le contexte des opérations en cours (downtime).

Règles :

  • la durée du silence doit être inférieure à 4h ;
  • le commentaire ne doit pas avoir le préfixe ACK! ;
  • aucune contrainte sur le commentaire.

Ce silence sera toujours considéré comme valide (y compris s’il fait une référence à un ticket Jira, en cours ou même fini).

Type 3 : exceptions#

Ce type de silence s'applique dans le contexte des alertes “connues” qui ne sont pas liées à des incidents/travaux et où il n’est pas prévu de corriger le problème (car trop rare ou avec un bénéfice travail/résultat trop faible).

Règles :

  • le commentaire DOIT être au format silence_cop <date> <explication> :

    • silence_cop est un mot-clé servant à identifier ces exceptions,
    • date doit être inferieure à un mois (30 jours) et avoir un format accepté (DD/MM/YYYY, DDMMYYYY, …).

  • le commentaire doit avoir une explication de 4 mots minimum ;

  • le commentaire peut avoir le préfixe ACK!.

Ce silence sera considéré comme valide jusqu’à la date indiquée en commentaire (qui peut être différente de la date de fin du silence).

Poser un silence#

La pose d'un silence est décrite dans les documentations respectives de Karma et Amtool.

Les champs se renseignent ainsi :

  • Alertmanager (seulement pour l'outil Amtool en utilisant l'option --alertmanager.url) : Alertmanager sur lequel poser le silence.

    Warning

    Il faut bien spécifier l'Alertmanager voulu afin d’éviter toutes fuite d'information (un client n'a pas besoin de voir les silence d'un autre client). Se référer à l'architecture indiquée en début de cette documentation.

  • Labels : il s'agit des labels permettant de caractériser toute alerte à mettre sous silence.

  • Durée :
    • pour un Downtime, il est nécessaire d'indiquer la durée de l'intervention.
    • pour un Acknowledgement, la durée doit être supérieure à quelques minutes. Elle sera automatiquement prolongée par tranches de 15 minutes par Kthxbye.
    • il est possible de mixer les deux notions de Downtime et d'Acknowledgement en indiquant une durée plus longue qui, pour un Acknowledgement, sera la durée minimum garantie du silence.
    • il est également possible de spécifier non pas une durée mais une date de début et une date de fin.
  • Author : NGOT Team ou NGOT
  • Comment :
    • pour un Acknowledgement, il commence par ACK! ;
    • à chaque fois que possible, il faut indiquer un numéro de ticket Jira (qui n'est pas en état "fini") afin d'indentifier la raison de ce silence ;
    • un descriptif du silence de minimum 3 mots est recommandé ;
    • pour plus de détails sur le format des commentaires des silence c'est ici.

Statistiques sur les silences#

Volumétrie des alertes organisées par état et par alertmanager pour les zones infra :

Historique des silences#

Afin de visualiser l'historique des alertes, le dashboard Alert History est déployé pour les clusters Caascad :

  • zones infra :

  • zones cloud et client :

    • cloud - format URL : https://grafana-infra.ocb-<${CLIENT}>.caascad.com/d/obs-p6ml03vGz/obs-alerts-history?orgId=1 ;
    • client - format URL : https://grafana.ocb-<${CLIENT}>.caascad.com/d/obs-p6ml03vGz/obs-alerts-history?orgId=1.

Note

10/10/2023 L'équipe monitoring envisage d'industrialiser le déployment des dashboards custom pour les clusters NGOT (PF-1576), mais à date ce n'est pas encore le cas.

Il est également possible d'obtenir la liste d'alertes dans le menu Explore. Cette information est fournie par la métrique ALERTS. La recherche peut être affinée à l'aide de nombreux labels (alertname, alertstate, obs_client, namespace, container, pod, severity, etc). Exemples : 

ALERTS{obs_client="infra-prd", namespace="vault", severity="critical", alertstate="firing"}
ALERTS{alertname="BlackboxMetricsMissing"}
ALERTS{alertname="BlackboxMetricsMissing",alertstate="firing"}