Aller au contenu

Alerting rules NGOT#

Le but de cette procédure est de comprendre quelques points importants pour les alerting rules NGOT :

  • où est définie une alerting rule NGOT à partir de son nom ;
  • pour quel type/subtype de zone de service elle devrait être déployée.

Prérequis#

Identification de la prometheusrule dans Gitlab

Les prometheusrules NGOT sont définies dans deux repositories en fonction de leur type, custom où upstream.

Pour cela il suffit de chercher le nom de l'alerte dans chacun des deux repos :

  • soit dans Gitlab :

  • soit en CLI dans le clone du repository :

    cd $HOME/git/caascad/applications/caascad-prometheus-rules-dashboards-upstream/
git pull
cd helm
grep -r <alertname> *.yaml

    cd $HOME/git/caascad/applications/caascad-prometheus-rules/
git pull
cd rules/rules
grep -r <alertname> *.cue

En cas de problème, il existe deux cas de figure :

  • la rule est définie dans Gitlab, mais elle n'est pas déployée sur le cluster où elle devrait y être ;
  • la rule est déployée sur le cluster, mais elle ne devrait pas l'être.

Pour identifier le cas de figure qui correspond à votre problème, suivez la suite de la procédure.

Identification des nom/type/subtype de zone#

Les étapes suivantes servent à identifier si une prometheusrule aurait dû être déployée mais ne l'est pas (où le contraire).

Identification du type de zone#

Cas des rules upstream#

Toutes les alertes upstream sont déployées sur les zones de type cluster.

Cette information se trouve dans le fichier prometheus-rules-dashboards-upstream.cue du répertoire envs-ng/contexts/ngot.

Cas des rules custom#

Le type de zone est indiqué par la valeur de RulesetName dans la définition de la prometheusrule.

Sur NGOT, elle peut prendre deux valeurs :

  • service-ngot
  • cluster-ngot

Example alerte custom

Pour l'alerte PrivxServicesStates :

cd $HOME/git/caascad/applications/caascad-prometheus-rules/
grep -B 5 PrivxServicesStates rules/rules/*.cue | grep RulesetName
Le résultat indique une zone de type service : 
[RulesetName= "service-ngot"]: apps: "privx": groups: {

Remarque : à cette étape on peut également obtenir la valeur du nom de l'application : privx.

Identification du subtype pour les zones de type service#

Si la zone est de type service, il est nécessaire d'identifier le subtype.

Pour cela dans envs-ng/contexts/ngot/envs.cue il faut chercher une multi-ligne qui contient  :

  • prometheus-rules : mot clé
  • _rule_apps avec la valeur identifiée à l'étape précédente (apps).

Cette multi-ligne se trouve dans une définition #NgotServiceZones. Le subtype est la clé de cette définition.

Example

Pour l'alerte PrivxServicesStates, le résultat de la recherche indique que le subtype de la zone est bastion :

#NgotServiceZones: "bastion": {
...
configurations: close({
    ...
    "prometheus-rules":       _ & {_rule_apps: ["privx"]}
})
}

Identification du nom des zones#

  • pour les zones de type cluster, le nom de la zone est indiqué dans l'alerte (label cluster).

    Les zones de type cluster peuvent être listés avec la commande suivante :

    sd get zones | jq -r '.|map(select(.type == "cluster") | .name)'

  • pour les zones de type service, il est nécessaire d'utiliser le subtype identifié à l'étape précédente dans la recherche :

    sd get zones | jq -r '.|map(select(.type == "service" and .subtype == "<subtype>") | .name)'

Example

Pour l'alerte PrivxServicesStates (où le subtype de la zone est bastion) : 

sd get zones | jq -r '.|map(select(.type == "service" and .subtype == "bastion") | .name)'

Vérifications#

Une fois que les informations suivantes sont obtenues, les différentes vérifications peuvent être effectuées :

  • nom des zone
  • type des zone
  • subtype des zone de service (le cas échéant).

Vérification du contenu de la prometheusrule#

Si le problème provient de la définition de la prometheusrule, il suffit de se connecter à la zone et de vérifier sa définition : 

kswitch <zone_cluster|zone_service>
kubectl -n prometheusrules get prometheusrules -o yaml | grep <pattern>
Où le pattern peut prendre ces valeurs :

  • le nom de l'alerte (label alertname)
  • le nom de l'application (example : privx)
  • le nom du contrat (label ngot_contract)
  • etc.

Vérification que le déploiement est conforme#

Pour une vérification complète, il est nécessaire de vérifier que l'alerte est déployée sur toutes les zones où elle devrait y être.

Zones de type cluster#

Vérifier que la prometheusrule est présente sur TOUTES les zones de type cluster :

export ZONES=($(sd get zones | jq -r '.|map(select(.type == "cluster") | .name) | .[]'))

for zone in "${ZONES[@]}"; do
  kswitch ${zone}
  kubectl -n prometheusrules get prometheusrules -o yaml | grep <alertname>
done

Zones de type service#

Vérifier que la prometheusrule est présente sur TOUTES les zones de type service :

export ZONES=($(sd get zones | jq -r '.|map(select(.type == "service" and .subtype == "<subtype>") | .name) | .[]'))

for zone in "${ZONES[@]}"; do
  kswitch ${zone}
  kubectl -n prometheusrules get prometheusrules -o yaml | grep <alertname>
done

Example

Pour l'alerte PrivxServicesStates (où le subtype de la zone est bastion) : 

export ZONES=($(sd get zones | jq -r '.|map(select(.type == "service" and .subtype == "bastion") | .name) | .[]'))

for zone in "${ZONES[@]}"; do
  kswitch ${zone}
  kubectl -n prometheusrules get prometheusrules -o yaml | grep PrivxServicesStates
done