Démantèlement d'un environnement Grafana mutualisé#

Préparatifs#

Warning

Attention de les garder pour les avoir après le lancement de nix-shell.

CLIENT=xxxx       # pour obs-pf : CLIENT=pf
ENVS_NG=xxx       # exemple : ENVS_NG=$HOME/git/caascad/terraform/envs-ng
CLUSTER=xxx       # pour obs-pf : CLUSTER=kub-9
export VAULT_ADDR=https://vault.infra-prd.caascad.com/
export VAULT_FORMAT=json
vault token lookup > /dev/null 2>&1 || vault login -method oidc

Prévenir l'équipe Supervision sur le chan #Opérations et incidents.

Gestion des silences#

Afin d'éviter d'alerter pendant la période de démantèlement 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")"' Decom NGOT client CLIENT (silence to remove after decom)"}' | sed -e "s/CLIENT/${CLIENT}/g" | base64 -w0)

Ou poser un silence dans Karma (ancienne méthode):

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 : Decom NGOT client ${CLIENT} ;
durée : 7 jours

Exemple :

À la fin du démantèlement il sera nécessaire de supprimer les silences mis en place.

Zone grafana-client#

cd ${ENVS_NG}
nix-shell
cd contexts/ngot
trackbone destroy -t purge=true -z "svc-grafana-client-${CLIENT}" --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 destroy -t purge=true avec ces configurations.

for i in "$(vault list secret/zones/fe/svc-grafana-client-${CLIENT} | jq -r '.[]')"; do echo "vault delete secret/zones/fe/svc-grafana-client-${CLIENT}/${i}"; done
for i in "$(vault list secret/zones/fe/svc-grafana-client-${CLIENT} | jq -r '.[]')"; do echo "vault delete secret/zones/fe/svc-grafana-client-${CLIENT}/${i}"; done

Note

Il est possible que les secrets Vault aient déjà tous été supprimés.

Suppression du PV à faire seulement si la suppression a échouée avec la commande trackbone :

kswitch ${CLUSTER}
pv=$(kubectl get pv -o json | jq -r --arg client "${CLIENT}" '.items[] | select(.spec.claimRef.name == "grafana-obs-"+$client) | .metadata.name')
kubectl get pv "${pv}" -o json | jq '[.metadata.name, .status.phase,.spec.claimRef.name,.spec.persistentVolumeReclaimPolicy]'

Après le contrôle, supprimer le pv s'il existe.

kubectl delete pv "${pv}"

Suppression des backups#

Lister les backups

kubectl get backup -n velero -l velero.io/schedule-name=grafana-obs-${CLIENT}

Delete des backup

velero backup delete --selector=velero.io/schedule-name=grafana-obs-${CLIENT}

Vérification (aucune ligne doit sortir des cmds suivantes)

velero backup get -l velero.io/schedule-name=grafana-obs-${CLIENT}
kubectl get backup -n velero | grep grafana | grep $CLIENT

Restart de Velero et vérification que le pod running et ready

kubectl rollout restart -n velero deploy/velero
kubectl get pod -n velero

Cette étape s'applique seulement si un grafana mutualisé est connecté à la zone que vous êtes en train de decommissioner.

Pour vérifier :

cd ${ENVS_NG}/zones/ngot_zones
git grep ${CLIENT}

Il s'agit de supprimer :

la datasource alertmanager_${CLIENT} ;
la connexion Thanos-query ;
l'environnemment ${CLIENT}.

Note

Dans cette étape on va noter avec ${GRAFANA_CLIENT} le nom de la zone qui porte le Grafana mutualisé.

Exemples :

dev: GRAFANA_CLIENT = devteam01 ;
staging: GRAFANA_CLIENT = stgteam01 ;
production: GRAFANA_CLIENT = evp.

Supprimez la definition des connexions thanos-query et des datasources dans les fichiers des zones (${ENVS-NG}/zones/ngot_zones).

Example pour les zones test04 et test06 attachées à Grafana mutualisé devteam01:

zones/ngot_zones/client-devteam01.cue

_zones: {
    "svc-grafana-client-devteam01": {
        let connected_zones = "10000:1:test04,test06"
        parameters: {
            _mutualized_datasource_alertmanager: "test04": _
            _mutualized_datasource_alertmanager: "test06": _

            datasources: {
                _mutualized_datasource_alertmanager["test04"]
                _mutualized_datasource_alertmanager["test06"]
            }
        }
    }
}

Générez les fichiers des zones et puis mettez à jour les configurations suivantes pour la zone Grafana mutualisé :

cd ${ENVS_NG}
generate-static-zones-files
cd contexts/ngot
trackbone apply -z svc-grafana-client-${GRAFANA_CLIENT} -c grafana --add-services
trackbone apply -z svc-grafana-client-${GRAFANA_CLIENT} -c thanos-query -c thanos-certificates --add-services
trackbone apply -z svc-signon-prd -c keycloak_k8s_openid_clients
trackbone apply -z svc-monitoring-stack-corp-prd-1 -c prometheus-rules --add-services
trackbone apply -z svc-monitoring-stack-corp-prd-2 -c prometheus-rules --add-services

Vérifiez dans Grafana mutualisé l'absence de la datasource correspondante à la zone que l'on souhaite décommissioner :

la métrique alertmanager_alerts{obs_client="${CLIENT}"} dans le menu Explore ne devrait plus être présente ;
datasource alertmanager_${CLIENT} dans le menu Alerting > Silences ne devrait plus être présent.

Si la datasource alertmanager_${CLIENT} est toujours présente, c'est parce qu'elle est restée dans la database Grafana. dans ce cas vous pouvez forcer la suppression:

éditez la configmap grafana-obs-${GRAFANA_CLIENT} :

kswitch svc-grafana-client-${GRAFANA_CLIENT}
kubectl edit cm grafana-obs-${GRAFANA_CLIENT} -n grafana-client-obs-${GRAFANA_CLIENT}

ajoutez les lignes suivantes :

data:
  deleteDatasources:
    - name: alertmanager_${CLIENT}
      orgId: 1

redémarrez le pod Grafana ;
vérifiez que la datasource alertmanager_${CLIENT} n'existe plus dans Grafana mutualisé ;
rééditez la configmap et supprimez les lignes qui vous ont permis de supprimer la datasour ce ;
redémarrez Grafana ;
vérifiez que les datasources ne sont plus présentes dans Grafana.

Zone contract#

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

Post-démantèlement#

Créer une MR avec toutes les suppression.

cd ${ENVS_NG}
git switch -c decom-obs-${CLIENT}
git rm zones/ngot_zones/client-${CLIENT}.cue
git rm zones/ngot_zones/promitor-${CLIENT}.cue # échec si Promitor n'est pas déployé
generate-static-zones-files
git add gen/ zones/
git commit -m "Decom ${CLIENT}"
git push --set-upstream origin decom-obs-${CLIENT}

Faire valider la MR. Puis la merger.

Après le merge :

git switch master && git pull
cd contexts/ngot
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
trackbone apply -z svc-monitoring-stack-corp-prd-2 -c prometheus-rules -c blackbox-exporter-core --non-interactive --add-services
trackbone apply -z svc-signon-prd -c keycloak_k8s_openid_clients
trackbone apply -z "${CLUSTER}" -c ingress_controller_v2_public --non-interactive

Si le client avait une connexion à Alertinghub, il faut la supprimer :

cd ${ENVS_NG}/contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver --add-services

Vérifier qu'il n'y a pas d'alertes liées à la zone démantelée.
Supprimer les silences sur la zone démantelée.
Supprimer les namespaces :
```
kubectl get ns | grep "${CLIENT}"
```
Supprimer tous les namespaces ci-dessus.

Supprimer les PVs 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

Supprimer les pipelines Concourse:

Pour supprimer les pipelines liées à la zone, suivre la doc de gestion des drifts.

Habilitations#

Suppression des habilitations : suivre cette procédure.

Confluence#

Déréférencer le client dans Confluence.

Déplacer la page client dans la section Deleted (or to delete)
Supprimer les informations de contacts du client de la liste Contacts clients NGOT
Remplacer la référence client par NEXT dans la page Mutualisation des zones

Points de contrôle (démantèlement de zone sans suppression du cluster)#

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

(x) aucune référence aux zones
* (x) dans envs-ng
* (x) dans Vault
** (x) path : applications/nginx-alertreceiver
** (x) path : applications/alertmanager/receivers
** (x) path : zones/fe
* (x) dans la documentation

(x) Absence d'habilitations (demander au support)

(x) Absence de silences dans Karma

(x) Dans le cluster, absence de PV avec le status {{Released}}

Points de contrôle (démantèlement de zone avec suppression du cluster)#

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

(x) aucune référence aux zones et au cluster
* (x) dans envs-ng
* (x) dans Vault
** (x) path : applications/nginx-alertreceiver
** (x) path : applications/alertmanager/receivers
** (x) path : zones/fe
* (x) dans la documentation

(x) Absence d'habilitations (demander au support)

(x) Absence de silences dans Karma