Environnement de Supervision + Grafana#

Tip

Liens directs vers certaines sections de la doc :

Variables CLIENT, CLUSTER...
Déploiement du routage des alertes Canopsis via AlertingHub
Validation du déploiement

Objectifs#

créer une nouvelle zone contract ;
déployer l'environnement de supervision ;
déployer un Grafana connecté à cet environnement de supervision ;
déployer un repository client dans le GITLAB externe.

Points de vigilance#

La documentation ci-dessous est écrite pour les zones de Production.

Pour les zones de Staging, il faudra remplacer ou ajouter le suffixe -stg là où c'est nécessaire.

Préparatifs#

CLIENT=xxxx       # pour obs-pf : CLIENT=pf
ENVS_NG=xxx       # exemple : ENVS_NG=$HOME/git/caascad/terraform/envs-ng

Demande API key (Canopsis)#

Important

Cette étape est à suivre seulement dans le cas où alertmanager de la nouvelle zone doit router les notifications vers Canopsis.

Suivez la documentation de demande AlertingHub. L'API Key vous sera transmise par e-mail.

Création des habilitations#

Pour pouvoir déployer complètement Grafana, il faut créer les habilitations.

Suivre la documentation ici.

Note

Cette demande n'indique pas les noms des clients et c'est normal. L'équipe Support se chargera ultérieurement de la gestion des utilisateurs.

Silences#

Sur toute la zone#

Afin d'éviter d'alerter pendant la période de provisionning d'une nouvelle zone NGOT, il est important de poser un silence sur toute la zone.

Depuis cette URL :

xdg-open 'https://karma-infra.infra-prd.caascad.com/?m='$(echo '{"am":[{"label":"svc-monitoring-stack-corp-prd-1","value":["svc-monitoring-stack-corp-prd-1"]},{"label":"svc-monitoring-stack-corp-prd-2","value":["svc-monitoring-stack-corp-prd-2"]}],"m":[{"n":"obs_client","r":false,"e":true,"v":["CLIENT"]}],"d":10080,"c":"silence_cop '"$(date "+%d%m%Y" -d "8 day")"' Provisioning NGOT client CLIENT (silence to remove before client delivery)"}' | sed -e "s/CLIENT/${CLIENT}/g" | base64 -w0)

Ancienne méthode : depuis Karma mettez un silence :

il faut poser les silences sur les deux alertmanagers de Prod : svc-monitoring-stack-corp-prd-1 et svc-monitoring-stack-corp-prd-2 ;
filtre dans Karma le nom de la zone : obs_client=${CLIENT} ;
commentaire : Provisioning nouvelle zone NGOT ;
durée : 7 jours

Exemple :

À la fin du provisioning il sera nécessaire de supprimer les silences mis en place.

Sur l'alerte `PrometheusTSDBBlocksLoadedLow`#

L'alerte PrometheusTSDBBlocksLoadedLow peut se déclancher jusqu'à 24h après le déploiement de la zone. Aussi nous posons un silence dédié à cette alerte. Il ne sera retiré en fin de procédure que si l'alerte a disparu entre temps.

xdg-open 'https://karma-infra.infra-prd.caascad.com/?m='$(echo '{"am":[{"label":"svc-monitoring-stack-corp-prd-1","value":["svc-monitoring-stack-corp-prd-1"]},{"label":"svc-monitoring-stack-corp-prd-2","value":["svc-monitoring-stack-corp-prd-2"]}],"m":[{"n":"alertname","r":false,"e":true,"v":["PrometheusTSDBBlocksLoadedLow"]},{"n":"obs_client","r":false,"e":true,"v":["CLIENT"]}],"d":1440,"c":"silence_cop '"$(date "+%d%m%Y" -d "2 day")"' Provisionning NGOT client CLIENT (PrometheusTSDBBlocksLoadedLow)"}' | sed -e "s/CLIENT/${CLIENT}/g" | base64 -w0)

Configuration des zones#

Ajout des zones dans Envs-ng#

Créer un fichier zones/ngot_zones/client-${CLIENT}.cue pour ajouter les zones dans envs-ng.

Les zones à indiquer dans le fichier sont :

zone contract : obs-${CLIENT} ;
zone de service "monitoring-stack-client" : svc-monitoring-stack-client-${CLIENT} ;
zone de service "grafana-client" : svc-grafana-client-${CLIENT}.

Pour créer ce fichier, il est possible d'utiliser ce générateur.

cd /tmp
git clone git@git.corp.caascad.com:caascad/applications/monitoring_zones_generator.git /tmp/monitoring_zones_generator && cd /tmp/monitoring_zones_generator
nix-env -iA nixpkgs.gomplate # si gomplate n'est pas déjà installé
cp values.yaml zone.yaml

Éditer le fichier zone.yaml pour le paramétrer pour les zones à déployer, en particulier :

le nom du client: clientName ;
le nom du cluster cible: clusterName ;
activer le déploiment du stack monitoring: monitoring_stack_client:enable: true ;
activez le déploiment de Grafana :
```
grafana_client: {
    enable: true,
}
```

Puis générez le fichier de configuration :

cat template.cue | gomplate -d values=./zone.yaml | cue fmt - > client-${CLIENT}.cue
mv client-${CLIENT}.cue ${ENVS_NG}/zones/ngot_zones

Note

Afin de remplir le parent_zone_name de chaque zone de service dans le fichier client-${CLIENT}.cue ou le nom du cluster dans zone.yaml, il est nécessaire d'identifier les clusters disponibles. Normalement, un cluster vient d'être provisionné à cette fin et c'est celui qu'il faut utiliser.

En cas de doute, il est possible de vérifier la disponibilité des clusters avec la commande suivante. Il faut choisir un cluster avec aucune (0) zone cliente, ce qui doit être le cas du cluster nouvellement provisionné.

sd get zones | jq -r '.[] | select(.type =="cluster") | [.name, (.child_zone_names|length)] | @sh'

En version Comet et jusqu'à nouvel ordre, un cluster ne peut pas héberger des zones de services de contrats différents.

Configuration de la zone de service "monitoring-stack-client" dans Envs-ng#

Rétentions#

Warning

Cette section est à suivre seulement si les rétentions demandées par le client ne sont pas celles par défaut.

Rétention par défaut :

retention: {
    raw:             *"15d" | string
    downsampling_5m: *"30d" | string
    downsampling_1h: *"60d" | string
}

Pour modifier les rétentions, reprendre la nouvelle zone créée et ajouter la section thanos en remplaçant les <x> par les rétentions voulues :

"svc-monitoring-stack-client-<client>": {
    ...
    parameters: {
        ...
        "thanos": {
            retention: {
                raw:             "<x>d"
                downsampling_5m: "<x>d"
                downsampling_1h: "<x>d"
            }
        }
    }
}

Routage des alertes#

Warning

Cette section est à suivre seulement si le routage des alertes demandé par le client n'est pas vers Canopsis.

Dans le cas où le client souhaite définir des notifications sur ses alertes, il faut le définir dans le fichier zones/ngot_zones/client-<client>.cue.

Voici quelques exemples, réduits au strict nécessaire :

CanopsisXymonMailRocketchatMattermost

À cet endroit, il n'est pas encore possible de déployer la configuration Canopsis. Une étape dédiée à Canopsis détaille son déploiement plus loin dans la procédure.

On passe directement à la prochaine étape sans tenir compte de Canopsis.

À la suite du mail de M. DE SAINT QUENTIN Arnaud daté du 16/10/2025, nous ne procédons plus au déploiement des zones avec Xymon.

    "svc-monitoring-stack-client-<client>": {
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: {
                notifications_targets: [{
                    name: "xymon"
                }]
            }
        }
    }
}

Le secret (mail-pf dans l'exemple, cf la documentation) est à définir (manuellement) dans Vault.

    "svc-monitoring-stack-client-<client>": {
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: {
                notifications_targets: [{
                    name: "mail-pf"
                    receiver: {
                        to:          "maildest@example.com"
                        from:        "mailorigin@example.com"
                        smarthost:   "email-smtp.eu-west-1.amazonaws.com:587"
                    }
                }]
            }
        }
    }
}

Le secret (rocketchat-pf dans l'exemple, cf la documentation) est à définir (manuellement) dans Vault.

    "svc-monitoring-stack-client-pf": {
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: {
                notifications_targets: [{
                    name: "rocketchat-pf"
                }]
            }
        }
    }
}

Le secret (mattermost-pf dans l'exemple, cf la documentation) est à définir (manuellement) dans Vault.

    "svc-monitoring-stack-client-<client>": {
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: {
                notifications_targets: [{
                    name: "mattermost-pf"
                }]
            }
        }
    }
}

La documentation sur les notifications Alertmanager détaille les notifications et leur paramétrage. À part Canopsis, elle peut être suivie pour des configurations qui sont plus complexes que les exemples ci-dessus.

Créer une Merge Request envs-ng#

nix-shell et variables d'environnement#

cd ${ENVS_NG}
git switch master && git pull
nix-shell

Dans la suite de la procédure, nous utiliserons ces variables :

CLIENT=<client>
CLUSTER=<cluster où déployer les zones>

ZONE_CONTRACT=obs-${CLIENT}

Exemples :

automatiqueobs-pf

À partir du fichier /tmp/monitoring_zones_generator/zone.yaml défini ci-dessus :

CLIENT="$(cat /tmp/monitoring_zones_generator/zone.yaml  | yq -r '.clientName')"
CLUSTER="$(cat /tmp/monitoring_zones_generator/zone.yaml  | yq -r '.clusterName')"

ZONE_CONTRACT=obs-${CLIENT}

Exemple pour obs-pf :

CLIENT=pf
CLUSTER=kub-2

ZONE_CONTRACT=obs-${CLIENT}

Vérifier le contenu des variables :

printf "Vérification:\n  CLIENT:        '%s'\n  CLUSTER:       '%s'\n  ZONE_CONTRACT: '%s'\n" "${CLIENT}" "${CLUSTER}" "${ZONE_CONTRACT}"

Regénérer les fichiers de zones statiques#

generate-static-zones-files

Créer la MR#

cd ${ENVS_NG}
git switch -c new-client-${CLIENT}
git add zones/ngot_zones/client-${CLIENT}.cue
git add gen/
git status

git commit -m "zone: init obs-${CLIENT} contract and services"

git push origin new-client-${CLIENT}

Dans la MR, conformément à la documentation de déploiement des nouvelles zones contract, écrire un commentaire check zones pour lancer check_zones dans la CI. Observer le résultat.

Déploiement des zones#

Les commandes seront à exécuter dans le contexte ngot :

cd contexts/ngot

Assurez-vous d'être identifié au niveau de Vault :

ProductionStaging

export VAULT_ADDR=https://vault.infra-prd.caascad.com; vault token lookup || vault login -method oidc

export VAULT_ADDR=https://vault.infra-stg.caascad.com; vault token lookup || vault login -method oidc

Zone Contract#

Déployer la zone conformément à la documentation de déploiement des zones contract :

trackbone apply -z "obs-${CLIENT}" -t bootstrap=true --non-interactive --detailed-exitcode -n 8

Mise à jour des configurations existantes : partie 1#

Certaines configurations existantes doivent être mises à jour avec le nouveau client :

ProductionStaging

trackbone apply -z svc-signon-prd -c keycloak_k8s_openid_clients

trackbone apply -z svc-signon-stg -c keycloak_k8s_openid_clients

Warning

Ne pas supprimer de configuration sans savoir ce qu'on fait !

Il faut vérifier attentivement les différences avant de valider.

Zone "monitoring-stack-client"#

Warning

Excepté Xymon, les secrets pour les notifications_targets d'Alertmanager doivent avoir été créés avant de déployer la zone.

Si ce n'est pas le cas (en particulier pour AlertingHub/Canopsis), il vaut mieux temporairement désactiver les notifications_targets et déployer sans. On redéploiera Alertmanager plus tard lorsque les secrets sont créés.

Déployer la zone conformément à la documentation de déploiement des zones service :

trackbone apply -z "svc-monitoring-stack-client-${CLIENT}" -t bootstrap=true --non-interactive --detailed-exitcode -n 8 --add-services

Note

Vérifier INFO Trackbone Stats: Succeeded=x Skipped=x Failed=x Disabled=x Total=x.

Si la valeur Failed est plus grande que 0, identifier les configurations en échec et lancer trackbone apply avec ces configurations.

Zone "grafana-client"#

Warning

CAASINC-1962 : Le label config-sync.caascad.com/secret: "true" peut être manquant sur l'objet namespace grafana-client-obs-${CLIENT}. Merci de vérifier manuellement sa présence et de l'ajouter si besoin.

kubectl edit ns grafana-client-obs-${CLIENT}

Déployer la zone conformément à la documentation de déploiement des zones service :

trackbone apply -z "svc-grafana-client-${CLIENT}" -t bootstrap=true --non-interactive --detailed-exitcode -n 8 --add-services

Note

Vérifier INFO Trackbone Stats: Succeeded=x Skipped=x Failed=x Disabled=x Total=x.

Si la valeur Failed est plus grande que 0, identifier les configurations en échec et lancer trackbone apply avec ces configurations.

Lors d'une relance de déploiement, il est impératif de vérifier qu'aucun PVC ne soit en mode 'available'

kubectl get pv --no-headers=true |grep -v Bound |sed -e "s/^/$k : /g"

Vérifier les credentials Prometheus dans Vault#

Warning

À partir d'ici, aucune commande avec l'option --bootstrap=true ne doit être lancée. Sinon, un nouveau secret est déployé alors que l'objectif ici est d'en supprimer.

Les credentials se trouvent dans vault : secret/zones/fe/svc-monitoring-stack-client-xxxxx/prometheus-ingress/.

ProductionStaging

export VAULT_ADDR=https://vault.infra-prd.caascad.com; vault token lookup || vault login -method oidc

export VAULT_ADDR=https://vault.infra-stg.caascad.com; vault token lookup || vault login -method oidc

Executer :

vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/prometheus-ingress/

Vérifier ici qu'il n'y a qu'un seul secret prometheus-ingress-yyyymmdd-hhmmss comme dans cet exemple :

Keys
----
init-directory
prometheus-ingress-20231010-121900

S'il y en a plusieurs, il faut :

les supprimer et n'en garder qu'un seul ;

redéployer les composants utilisant ce secret :

ProductionStaging

trackbone apply -z "${CLUSTER}" -c kube-prometheus-stack --add-services
trackbone apply -z svc-monitoring-stack-client-"${CLIENT}" -c blackbox-exporter-probe-monitoring-stack-client-mon3 --add-services
trackbone apply -z svc-monitoring-stack-client-"${CLIENT}" -c blackbox-exporter-probe-monitoring-stack-client-mon4 --add-services
trackbone apply -z svc-monitoring-stack-corp-prd-1 -c kube-prometheus-stack --add-services
trackbone apply -z svc-monitoring-stack-corp-prd-2 -c kube-prometheus-stack --add-services

trackbone apply -z "${CLUSTER}" -c kube-prometheus-stack --add-services
trackbone apply -z svc-monitoring-stack-client-"${CLIENT}" -c blackbox-exporter-probe-monitoring-stack-client-mon3 --add-services
trackbone apply -z svc-monitoring-stack-client-"${CLIENT}" -c blackbox-exporter-probe-monitoring-stack-client-mon4 --add-services
trackbone apply -z svc-monitoring-stack-corp-stg-1 -c kube-prometheus-stack --add-services
trackbone apply -z svc-monitoring-stack-corp-stg-2 -c kube-prometheus-stack --add-services

Note

Cette section reprend la documentation de référence Generate new secret for Prometheus ingress.

La documentation de référence indique de déployer également ces configurations : -c prometheus-rules -c blackbox-exporter-core. Cependant, il est prévu de les redéployer plus loin dans la procédure. Il est inutile de le faire ici.

Création des pipelines Concourse#

Suivre la doc de gestion des drifts pour créer les pipelines Concourse.

Finalisation envs-ng (merger la MR)#

Dans la Merge Request, indiquer trackbone plan ngot en commentaire. Observer le résultat. Si la CI/CD ne fonctionne pas, vous pouvez passer cette commande en local trackbone plan -z svc-monitoring-stack-client-sbl --podman --add-services

Après les déploiements, il faut s'attendre à un "no-change" à l'exception des PrometheusRules (pas encore redéployées). Si tel est le cas, on peut :

faire valider la MR ;
merger la MR.

Warning

Il faut avoir "mergé" la MR pour pouvoir faire les parties suivantes, qui s'appuient sur ngot-zones de la branche master.

Une fois la MR mergée, il est possible de se connecter avec kswitch au cluster. Cela peut se faire soit sur la zone cluster (exemple : kub-x), soit sur la zone de service du client (exemples : svc-monitoring-stack-client-xxxx, svc-grafana-client-xxxx). Cela revient au même.

Mise à jour des configurations existantes : partie 2#

Certaines configurations existantes doivent être mises à jour avec le nouveau client.

Warning

Les commandes suivantes doivent être effectuées à partir de la branche master en ayant fait un git pull au préalable.

ProductionStaging

git switch master && git pull
trackbone apply -z svc-monitoring-stack-corp-prd-1 -c prometheus-rules -c blackbox-exporter-core -t blackbox_exporter_refresh_cache=true --non-interactive --add-services

Attendre que la commande ci-dessus ait terminé pour lancer les commandes ci-dessous.

trackbone apply -z svc-monitoring-stack-corp-prd-2 -c prometheus-rules -c blackbox-exporter-core --non-interactive --add-services
trackbone apply -z "${CLUSTER}" -c external_dns --non-interactive
trackbone apply -z "${CLUSTER}" -c fe_loadbalancer_v3 --non-interactive
trackbone apply -z "${CLUSTER}" -c ingress_nginx_public --non-interactive
trackbone apply -z "${CLUSTER}" -c prometheus-rules-dashboards-upstream --non-interactive

git switch master && git pull
trackbone apply -z svc-monitoring-stack-corp-stg-1 -c prometheus-rules -c blackbox-exporter-core -t blackbox_exporter_refresh_cache=true --non-interactive --add-services

Attendre que la commande ci-dessus ait terminé pour lancer les commandes ci-dessous.

trackbone apply -z svc-monitoring-stack-corp-stg-2 -c prometheus-rules -c blackbox-exporter-core --non-interactive --add-services
trackbone apply -z "${CLUSTER}" -c fe_loadbalancer_v3 --non-interactive
trackbone apply -z "${CLUSTER}" -c ingress_nginx_public --non-interactive
trackbone apply -z "${CLUSTER}" -c prometheus-rules-dashboards-upstream --non-interactive

Déploiement du routage des alertes Canopsis via AlertingHub#

Note

Cette partie n'est à réaliser que si le client a demandé un routage des alertes Canopsis via AlertingHub.

Plus d'informations dans la procédure Nginx Alertreceiver.

Important

Cette partie ne pourra être déroulée que seulement après avoir obtenu par mail l'API key demandée précédemment. Si vous ne l'avez pas encore reçue, vous pouvez ne pas réaliser cette étape. Vous devrez y revenir une fois que vous l'aurez reçue.

Vérification du dictionnaire#

Suivre la documentation de vérification.

Une capture d'écran peut être placée dans le ticket de réalisation. Dans ce cas, supprimer les DEUX références à l'API key de la capture d'écran

avec un outil de retouche d'image (gimp, draw...) ;
ou avec l'outil de développement web du navigateur : chercher l'API Key et la remplacer par <Redacted> ou par *************. La capture d'écran peut être prise ensuite.

Configuration de Nginx Alertreceiver#

Assurez-vous d'être identifié au niveau de Vault :

ProductionStaging

export VAULT_ADDR=https://vault.infra-prd.caascad.com; vault token lookup || vault login -method oidc

export VAULT_ADDR=https://vault.infra-stg.caascad.com; vault token lookup || vault login -method oidc

Ajouter le client interne dans Nginx Alertreceiver :

cd contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver -t bootstrap=true -t nginx_alertreceiver_zone_for_bootstrap=$CLIENT --add-services

Cette étape va :

générer une nouvelle clef externe, exemple : 6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT

modifier la configuration de l'ingress avec $CLIENT, exemple :

+ if ($request_uri = "/alertreceiver/test?apikey=6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT") {
+   set $code "OVERRIDE_ME";
+   set $cc_client "$CLIENT";
+   set $resp_body "";
+ }

créer un nouveau secret dans Vault : secret/applications/nginx-alertreceiver/$CLIENT.

Modifier manuellement le secret créé dans Vault pour le nouveau client (le champ "internal_apikey", qui est égal à OVERRIDE_ME, avec la clé API interne obtenue lors de la première étape) ;

ProductionStaging

xdg-open "https://vault.infra-prd.caascad.com/ui/vault/secrets/secret/list/applications/nginx-alertreceiver/${CLIENT}"

xdg-open "https://vault.infra-stg.caascad.com/ui/vault/secrets/secret/list/applications/nginx-alertreceiver/${CLIENT}"

Ajouter la zone dans contexts/pf/nginx-alertreceiver.cue:

#ZonesMonitoredByTruesight: ["lrdm", ..., "$new_client"]

Lancer la configuration nginx-alertreceiver. Cette étape va mettre à jour la configuration avec la nouvelle clé API interne :
```
cd contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver --add-services
```

Vérifier l'ingress de Nginx Alertreceiver :

kswitch prdcasa
kubectl get ingress -n nginx-alertreceiver -o yaml | grep -A5 "/alertreceiver/${CLIENT}"

Résultat attendu :

if ($request_uri = "/alertreceiver/$CLIENT?apikey=6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT") {
        set $code "xxxxxxxxxxxxx";
        set $cc_client "$CLIENT";
        set $resp_body "";
}

Où "xxxxxxxxxxxxx" doit être la clé API interne.

Configuration de l'Alertmanager du client#

Dans le fichier zones/ngot_zones/client-<client>.cue, ajouter une notifications_targets :

"svc-monitoring-stack-client-<client>": {
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: notifications_targets: [#MonitoringStackNotificationsTargetAlertinghub]
        }
    }
}

Regénérer les zones avec le nouveau paramétrage :
```
generate-static-zones-files
```

Créer une MR avec ces modifs :

git switch -c alertinghub-obs-${CLIENT}
git add zones/ngot_zones/client-${CLIENT}.cue
git add gen/

git add contexts/pf/nginx-alertreceiver.cue

git status

git commit -m "obs-${CLIENT}: connect to AlertingHub"

git push origin alertinghub-obs-${CLIENT}

Redéployer Alertmanager :

cd contexts/ngot
trackbone apply -z svc-monitoring-stack-client-$CLIENT -c alertmanager -t bootstrap=true --add-services

Écrire trackbone plan dans la MR : on doit obtenir un "no-change"
Faire valider la MR, puis la merger.

Déploiement Gitops Workflow#

Aller sur le repository qui contient les scripts pour le Gitops Workflow :

git clone git@git.corp.caascad.com:caascad/applications/gitops-tools.git /tmp/gitops-tools
cd /tmp/gitops-tools/ngot

Lancer les scripts suivants pour créer et initialiser le nouveau repository client :

Production (Comet)Staging (Comet)

./create_client_repo.py -c configs/comet-prd.yaml -C obs-${CLIENT}
./client_repo_set_credentials.py -a prometheus -c configs/comet-prd.yaml -C obs-${CLIENT}

./create_client_repo.py -c configs/comet-stg.yaml -C obs-${CLIENT}
./client_repo_set_credentials.py -a prometheus -c configs/comet-stg.yaml -C obs-${CLIENT}

Tip

En cas d'échec du script, voici des pistes d'investigation (les comptes, clients et URL sont indiquées pour la Prod) :

Voir si le repo existe déjà :
```
xdg-open "https://sourcehub.orange-business.com/cs-factory/cs-factory-environments/obs-${CLIENT}"
```
Si le repo existe, il faut voir s'il s'agit d'un repo archivé.
- si le repo est déjà archivé, on le supprime définitivement ;
- si le repo n'est pas archivé, il faut investiguer. Vient-il d'être créé (commande lancée deux fois, par exemple) ? A-t-il été créé il y a longtemps ? Dans ce cas, était-ce un oubli d'archivage ? Ou y a-t-il une vraie collision ?
Se connecter sur Sourcehub avec le compte applicatif et, dans les préférences voir si le token n'a pas expiré. Si tel est le cas, il faut regénérer un nouveau token et le renseigner dans Vault.

Aller dans templates-ci et faire un backup du contenu de la variable LIST_CLIENT sur votre poste (au cas où le script écrase cette variable).

Lancer le script suivant pour modifier les variables dans templates-ci :

Production (Comet)Staging (Comet)

./update-template-ci.py -c configs/comet-prd.yaml -C obs-${CLIENT}

./update-template-ci.py -c configs/comet-stg.yaml -C obs-${CLIENT}

Vérifications#

Grafana#

Se connecter à Grafana avec son compte Keycloak/Caascad (Sign-in with Keycloak > caascad).

xdg-open https://grafana.obs-${CLIENT}.cloudservicesfactory.com

Pour valider la connexion à Keycloak/Caascad, il faut constater :

que l'on peut se connecter ;
que l'on a les droits attendus.

Gitops Workflow#

Aller sur le repository qui contient les scripts pour le Gitops Workflow :

cd /tmp/gitops-tools/ngot

Lancer le script qui va permette de déployer les différentes ressources Kubernetes :

Production (Comet)Staging (Comet)

./validate-first-deploy-start.py -c configs/comet-prd.yaml -C obs-${CLIENT}

./validate-first-deploy-start.py -c configs/comet-stg.yaml -C obs-${CLIENT}

Les vérifications visuelles se font via Grafana.

On vérifie la présence :

de la métrique probe_success
du dashboard validate
de l'alerte TestAlert

Lancer le script qui va permettre de supprimer les différentes ressources Kubernetes :

Production (Comet)Staging (Comet)

./validate-first-deploy-uninstall.py -c configs/comet-prd.yaml -C obs-${CLIENT}

./validate-first-deploy-uninstall.py -c configs/comet-stg.yaml -C obs-${CLIENT}

Le script validate-first-deploy-uninstall.py peut avoir des échecs. Lancer les commandes suivantes sans se poser de questions :

kswitch svc-monitoring-stack-client-${CLIENT}
kubectl -n "grafana-dashboards-obs-${CLIENT}" delete cm validate

kswitch svc-grafana-client-${CLIENT}
kubectl -n "rules-obs-${CLIENT}" delete prometheusrules test.alert
kubectl -n "probes-obs-${CLIENT}" delete probe blackbox-exporter-http-2xx-probe

Vérifier dans Grafana que tout a été désinstallé :

absence de la métrique probe_success ;
absence du dashboard validate ;
absence de l'alerte TestAlert.

Tip

Il faut généralement attendre un minimum de 5 minutes pour constater que tout est désinstallé. À cet endroit, il est possible d'effectuer d'autres vérifications (tests de conformité, connexion à Prometheus...) avant de revenir à cette vérification.

Lorsqu'on a constaté que tout est désinstallé (mais pas avant) :

Production (Comet)Staging (Comet)

./validate-first-deploy-finish.py -c configs/comet-prd.yaml -C obs-${CLIENT}

./validate-first-deploy-finish.py -c configs/comet-stg.yaml -C obs-${CLIENT}

Note

La métrique probe_success persiste pendant 5 minutes une fois que la target n'est plus présente.

Il est possible d'observer timestamp(probe_success) à la place. Le plateau indique que la métrique va bientôt disparaître ; c'est lui qui dure 5 minutes.

Derniers contrôles visuels sur Gitlab :

xdg-open "https://sourcehub.orange-business.com/cs-factory/cs-factory-environments/obs-${CLIENT}"

Code/Branches : il ne doit y avoir que la branche main
Build/Pipelines : il ne doit y avoir qu'un seul pipeline (blocked - "First commit")
Build/Jobs : il ne doit y avoir que 5 jobs (1 "passed" et 4 "manual")

Lancer les tests de conformité#

Lancer les tests de conformité :

git clone git@git.corp.caascad.com:caascad/applications/poc_check_functional_tests_monitoring.git /tmp/poc_check_functional_tests_monitoring && cd /tmp/poc_check_functional_tests_monitoring/ngot
./func_tests_kub.sh "${CLUSTER}"  # example : ./func_tests_kub.sh kub-1
./func_tests_svc_grafana_client.sh "${CLIENT}" # example : ./func_tests_svc_grafana_client.sh pf
./func_tests_svc_monitoring_stack_client.sh "${CLIENT}" # example : ./func_tests_svc_monitoring_stack_client.sh pf

Gitops Workflow et creds Prometheus#

Vérifier la cohérence Login/Password de Vault/sourcehub et la connexion à Prometheus avec les credentials communiqués au client.

Pré-requis : il faut un token Gitlab(ext) avec au minimum les permissions api,write_repository : https://sourcehub.orange-business.com/-/profile/personal_access_tokens?scopes=api,write_repository.

ProductionStaging

export VAULT_ADDR=https://vault.infra-prd.caascad.com; vault token lookup || vault login -method oidc
export GITLAB_TOKEN=$(vault read -format json secret/zones/dtstore/cs-factory  | jq -r .data.api_token)

export VAULT_ADDR=https://vault.infra-stg.caascad.com; vault token lookup || vault login -method oidc
export GITLAB_TOKEN=$(vault read -format json secret/zones/dtstore/cs-factory-stg  | jq -r .data.api_token)

git clone git@git.corp.caascad.com:caascad/applications/check_ngot_credentials.git /tmp/check_ngot_credentials && cd /tmp/check_ngot_credentials
./check_prometheus_creds_in_vault_and_gitlab.sh "${CLIENT}" 2>/dev/null && echo OK

Alertmanager#

Lorsqu'une configuration spécifique d'alerting a été demandée (Canopsis, mail...), contrôler qu'elle est en place dans la configuration d'Alertmanager :

kswitch svc-monitoring-stack-client-"${CLIENT}"
kubectl -n "monitoring-stack-client-obs-${CLIENT}" get cm alertmanager -o yaml

PVs Released#

Vérifier l'absence de PV avec le status Released :

kubectl get pv | grep ${CLIENT} | grep Released

S'il y en a, supprimer les :

for pv in $(kubectl get pv | grep ${CLIENT} | grep Released | awk '$1 {print $1}'); do
  kubectl delete pv $ pv
done

Dernières étapes#

Karma#

ProductionStaging

xdg-open "https://karma-infra.infra-prd.caascad.com/?q=obs_client%3D${CLIENT}"

xdg-open "https://karma-infra.infra-stg.caascad.com/?q=obs_client%3D${CLIENT}"

Dans karma :

supprimez tous les silences mis en place pendant le provisioning de la zone ;
vérifiez qu'aucune alerte n'est active pour les nouvelles zones de service.

Support#

Prévenir sur Rocket.chat #support, la fin du déploiement.

Validation du déploiement#

Modèle pour Jira#

h1. Validation zone monitoring-stack

Tests fonctionnels
- (on) Tests fonctionnels zone monitoring-stack-client
- (on) Tests fonctionnels zone grafana-client
- (on) Test de connexion à Prometheus avec les creds du client (et vérification de la cohérence Vault/Gitlab)

Documentation
- (on) Contacts renseignés dans [Confluence|https://espace.agir.orange.com/display/BPF/Contacts+clients+NGOT]

Spécifications de la zone
- (on) Routage des alertes
- (on) Dashboards Grafana (pas de datasource inutile; datasource Loki uniquement si zone demandée)
- (on) Rétention Monitoring (correspond à la demande)

Résidus d'installation
- (on) Absence de PVs avec le status {{Released}}
- (on) Pas de creds inutiles ({{vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/prometheus-ingress/}})

Gitops Workflow
- (on) Vérification effectuée (présence ponctuelle d'une alerte dans Grafana/Explore)
- (on) Absence de résidus de tests dans Grafana
- (on) Absence de résidus de tests dans Gitlab(ext) : absence de branche de validation
- (on) Absence de résidus de tests dans Gitlab(ext) : absence de pipelines de test

Karma
- (on) Absence d'alertes
- (on) Aucun silence posé sur la zone (recherche sur {{obs_<client>}})

JIRA et Merge Requests
- (on) Présence du ticket CW (demande initiale) en lien du ticket JIRA
- (on) Présence de la MR "ngot-zones" en lien du ticket JIRA
- (on) Toutes les MR du ticket sont "merged"
- (on) Les acceptance criteria ont tous été contrôlés

Références#

Page Confluence : choisir la zone dans le menu à gauche ;
NGOT-Zones : zones/ngot_zones/client-<client>.cue ;
Rétentions par défaut (rechercher "retention" pour la zone "monitoring-stack-client").

Points de contrôles#

Les points à contrôler sont définis dans le modèle Jira. Voici quelques précisions :

Zones (monitoring-stack-client et grafana-client)
Routage des alertes (Canopsis/Xymon,etc): fichier conf
Dashboards Grafana (présence de Loki si demandé)
Stack logging (présence de la zone si elle a été demandée)
rétention Monitoring
Gitops Workflow
Si présence de screenshot avec les tests Gitops Workflow, vérifier la présence du dashboard
aller sur https://grafana.obs-<client>.cloudservicesfactory.com
- onglet "explore", métrique ALERTS : rechercher une alerte sur les 7 ou 30 derniers jours
- onglet "explore", métrique probe_success : rechercher la métrique sur les 7 ou 30 derniers jours
- note : on ne peut pas vérifier que le dashboard a été déployé
Vérifier l'absence de résidus de tests:
- absence de la branche validate-first deploy dans le repo du client: cs-factory-environments/obs-<client>
- absence de pipelines de tests (sur la branche validate-first)
- dans grafana, les métriques ALERTS et probe_success doivent être ponctuelles
Vérifier la présence de pipelines Concourse

Environnement de Supervision + Grafana#

Objectifs#

Points de vigilance#

Préparatifs#

Demande API key (Canopsis)#

Création des habilitations#

Silences#

Sur toute la zone#

Sur l'alerte PrometheusTSDBBlocksLoadedLow#

Configuration des zones#

Ajout des zones dans Envs-ng#

Configuration de la zone de service "monitoring-stack-client" dans Envs-ng#

Rétentions#

Routage des alertes#

Créer une Merge Request envs-ng#

nix-shell et variables d'environnement#

Regénérer les fichiers de zones statiques#

Créer la MR#

Déploiement des zones#

Zone Contract#

Mise à jour des configurations existantes : partie 1#

Zone "monitoring-stack-client"#

Zone "grafana-client"#

Vérifier les credentials Prometheus dans Vault#

Création des pipelines Concourse#

Finalisation envs-ng (merger la MR)#

Mise à jour des configurations existantes : partie 2#

Déploiement du routage des alertes Canopsis via AlertingHub#

Vérification du dictionnaire#

Configuration de Nginx Alertreceiver#

Configuration de l'Alertmanager du client#

Déploiement Gitops Workflow#

Vérifications#

Grafana#

Gitops Workflow#

Lancer les tests de conformité#

Gitops Workflow et creds Prometheus#

Alertmanager#

PVs Released#

Dernières étapes#

Karma#

Support#

Validation du déploiement#

Modèle pour Jira#

Références#

Points de contrôles#

Sur l'alerte `PrometheusTSDBBlocksLoadedLow`#