Aller au contenu

Nouveau déploiement pour un client#

Note

Cette documentation ne s'applique qu'à NGOT.

Variables d'environnement#

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

# Nom pour différencier les différentes instances de Promitor pour un client, on commence par tenant1
export INSTANCE_NAME=tenantxxx  # exemple : export INSTANCE_NAME=tenant1

Informations requises#

Pour le déploiement de ce composant, l'équipe Support doit fournir à l'équipe Monitoring les informations fournies par le client de manière sécurisée :

  • les identifiants : id/clé de l'application.

    xdg-open "https://vault.infra-prd.caascad.com/ui/vault/secrets/secret/list/zones/fe/svc-monitoring-stack-client-${CLIENT}/promitor-client/"

  • les informations de collecte sous la forme de deux fichiers scraper.yaml et resource_discovery.yaml.

    xdg-open "https://sourcehub.orange-business.com/cs-factory/cs-factory-environments/obs-${CLIENT}/-/tree/main/promitor?ref_type=heads"

Ajout des informations de collecte dans Ngot-Zone#

Pour créer le fichier promitor-<client>.cue, il est possible d'utiliser ce générateur :

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

Préparer l'environnement : 

export GIT_NGOT_PATH=/tmp

rm -rf /tmp/obs-${CLIENT}
git clone git@sourcehub.orange-business.com:cs-factory/cs-factory-environments/obs-${CLIENT}.git /tmp/obs-${CLIENT}

for f in scraper.yaml resource_discovery.yaml; do
  test -f /tmp/obs-${CLIENT}/promitor/${INSTANCE_NAME}/${f} || printf "\nWARNING WARNING WARNING\nFile /tmp/obs-${CLIENT}/promitor/${INSTANCE_NAME}/${f} does not exists or is not named as expected\nWARNING WARNING WARNING\n\n"
done

Générer le fichier promitor-<client>.cue :

gomplate -f template.cue | cue fmt - > promitor-$CLIENT.cue
cp promitor-${CLIENT}.cue ${ENVS_NG}/zones/ngot_zones

Si le générateur échoue à générer le fichier de configuration, il est fort probable que le fichier scraper.yaml modifié par le client contient des erreurs. Exemple log d'erreur:

13:23:11 ERR  error="failed to render template template.cue: template: template.cue:8:16: executing \"template.cue\" at <ds \"scraper\">: error calling ds: yaml: line 1: did not find expected key"

Veuillez vérifier ce fichier, qu'il est bien nommé, et s'assurer qu'il n'y a pas des erreurs comme des problèmes d'indentation.

Warning

Si nous sommes en mesure d'effectuer les corrections, nous pouvons le faire.

Cependant, ATTENTION à ces trois points :

  • ne faites pas un commit sur votre poste. La commande git log montrerait alors votre nom !
  • les commits peuvent être réalisés avec l'interface clic clic de Gitlab(Ext), mais avec le compte générique. Rappel des credentials génériques Gitlab(Ext) ;
  • les commits dans Gitlab(Ext) ne doivent être effectués qu'après le déploiement réussi en prod (pour éviter de multiples commits suite à des corrections successives).

Test de la configuration client sur staging (obs-test04)#

Cette section permet de faire un test sur staging avant de faire le déploiement en production avec un CAASCHR.

Warning

Afin d'éviter les requêtes en double sur les comptes Azure des clients, le test doit durer le moins longtemps possible : 30 minutes au maximum.

Ajout du mot de passe dans Vault infra-stg#

On récupère les credentials dans Vault infra-prd :

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

if [ -z ${INSTANCE_NAME} ]; then echo "WARNING: set INSTANCE_NAME"; fi
application_id=$(vault read secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/promitor-client/${INSTANCE_NAME} | jq -r .data.application_id)
application_key=$(vault read secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/promitor-client/${INSTANCE_NAME} | jq -r .data.application_key)

On les met temporairement dans Vault infra-stg sur l'environnement obs-test04 qui servira pour les tests :

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

vault write "secret/zones/fe/svc-monitoring-stack-client-test04/promitor-client/${INSTANCE_NAME}" application_id=${application_id} application_key=${application_key}

Déploiement#

Déployer sur obs-test04 :

cd ${ENVS_NG}
git switch master && git pull
git switch -c new_${CLIENT}_promitor
cp ${ENVS_NG}/zones/ngot_zones/promitor-${CLIENT}.cue ${ENVS_NG}/zones/ngot_zones/promitor-test04.cue
sed -i -e "s/svc-monitoring-stack-client-${CLIENT}/svc-monitoring-stack-client-test04/g" ${ENVS_NG}/zones/ngot_zones/promitor-test04.cue
nix-shell
generate-static-zones-files
(cd contexts/ngot && trackbone apply -z "svc-monitoring-stack-client-test04" -c promitor-client)

Vérifications#

  • les pods tournent :

    • vérification :

      kswitch svc-monitoring-stack-client-test04
kubectl -n monitoring-stack-client-obs-test04 get pod | grep promitor

    • en cas d'erreur :

      kubectl -n monitoring-stack-client-obs-test04 logs promitor-scraper-tenant1-xxxxxxxxxx-xxxxx

      Les logs devraient expliquer l'origine du problème. Voir les cas connus dans la section suivante.

  • modifications prises en compte. Dans Grafana vérifier la présence de quelques métriques avec le préfixe azure_ ;

  • aucune erreur constatée. Dans Grafana faire les différentes requêtes PromQL :

    • on vérifie que le scraper fonctionne correctement :

      promitor_scrape_error == 1

      Cette requête doit retourner no data.

    • on vérifie que la resource discovery fonctionne correctement :

      increase(promitor_runtime_http_request_duration_seconds_count{job=~"promitor-resource-discovery-.*", status_code!="200"}[5m]) > 0

      Cette requête doit retourner no data.

En cas de problème : cas connus#

Métriques en double#

Il peut arriver que le pod promitor entre en état CrashLoopBackOff parce que le fichier scraper.yaml dans le repository du client contient des métriques en double.

Dans ce cas, nous pouvons supprimer la définition en trop et essayer de déployer à nouveau.

Si cela résoud le problème, il faut reporter la correction dans le Gitlab(Ext) du client avec le compte générique (rappel des credentials génériques Gitlab(Ext)).

xdg-open "https://sourcehub.orange-business.com/cs-factory/cs-factory-environments/obs-${CLIENT}/-/tree/main/promitor?ref_type=heads"

Warning

Ne faites pas un commit sur votre poste. La commande git log montrerait alors votre nom !

Les commits peuvent être réalisés avec l'interface clic clic de Gitlab(Ext), mais avec le compte générique. Attendre la fin du déploiement pour ne faire qu'un seul commit correctif.

Error 'Total(Sum)' is not a valid value for 'type'#

Il peut arriver que le pod promitor entre en état CrashLoopBackOff parce que le fichier scraper.yaml dans le repository du client contient des définintions erronées.

Exemple :

kubectl -n monitoring-stack-client-obs-test04 logs promitor-scraper-tenant1-xxxxxxxxxx-xxxxx
...
[16:19:24 ERR] The following problems were found with the metric configuration:
Error 85:13: 'Total(Sum)' is not a valid value for 'type'.
...

Remplacer Total(Sum) par Total dans le fichier scraper.yaml.

Puis re-tester.

Si cela résoud le problème, on effectue la correction pour le client.

Error 'xxx' is not a valid value for 'resourceType'#

Il peut arriver que le pod promitor entre en état CrashLoopBackOff parce que le fichier scraper.yaml dans le repository du client contient des définintions erronées.

Exemple :

kubectl -n monitoring-stack-client-obs-test04 logs promitor-scraper-tenant1-xxxxxxxxxx-xxxxx
...
[16:19:24 ERR] The following problems were found with the metric configuration:
Error 130:17: 'databases' is not a valid value for 'resourceType'.
...

La liste des resourceType supportés se trouve dans le menu à gauche de cette page.

  • rechercher le type correspondant dans Supported Providers ;

  • lire la première phrase, toujours la même :

    You can declare to scrape an Azure Database for PostgreSQL server via the XXXXXXXXX resource type.

  • le resourceType correspond au XXXXXXXXX ci-dessus. On le retrouve également dans l'exemple qui suit (rechercher resourceType dans la page).

Ici, deux cas se présentent :

  • soit la correction est triviale (erreur dans l'orthographe, ou type unique). Dans ce cas, on effectue la correction pour le client ;

  • soit la correction nécessite de connaître le besoin du client. Dans ce cas, il faut revenir vers lui avec un message de ce genre :

    Lors du déploiement de Promitor, nous rencontrons un problème dans la définition des métriques :
'xxx' is not a valid value for 'resourceType'.

À l'aide des 'Supported Providers' indiqués sur cette page (https://docs.promitor.io/v2.11/resource-discovery/overview/) pourriez-vous corriger les deux fichiers 'resource_discovery.yaml' et 'scraper.yaml' en indiquant le 'resourceType' que vous souhaitez ?

    Bien remplacer le xxx par le type (ou les types) réellements indiquées dans le message d'erreur.

Communiquer au client en cas de problème#

Lorsqu'une erreur de configuration nécessite une correction de la part du client, il faut en informer l'équipe Support en leur proposant un exemple de communication :

Bonjour,

<indiquer ici les problèmes rencontrés>

Lorsque les corrections auront été effectuées, merci de nous en informer, afin que nous puissions reprendre le déploiement de Promitor.

Cordialement

Cleanup test staging#

(cd contexts/ngot && trackbone destroy -z "svc-monitoring-stack-client-test04" -c promitor-client)
rm zones/ngot_zones/promitor-test04.cue
generate-static-zones-files

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

if [ -z ${INSTANCE_NAME} ]; then echo "WARNING: set INSTANCE_NAME"; fi
vault delete "secret/zones/fe/svc-monitoring-stack-client-test-04/promitor-client/${INSTANCE_NAME}"

Déploiement en production#

Une fois que le test en staging a réussi, le déploiement de promitor-client est possible.

Warning

Ne pas faire le déploiement en production tant que le test en staging n'a pas réussi.

À ce stade, nous sommes toujours dans le nix-shell. Vérifier que la variable $CLIENT est bien positionnée :

echo "CLIENT=${CLIENT}"

Vérifier le déploiement avec un plan puis créer la MR (nous sommes déjà dans une branche dédiée) :

(cd contexts/ngot && trackbone plan -z "svc-monitoring-stack-client-${CLIENT}" -c promitor-client)
(cd contexts/ngot && trackbone plan -z "svc-monitoring-stack-client-${CLIENT}" -c prometheus-rules --add-services)
git add zones/ngot_zones/promitor-$CLIENT.cue
git add gen/
git status
git commit -m "promitor-client: $CLIENT: add/update"
git push

Si tout est OK, vous pouvez demander la review de votre MR et préparer votre CAASCHR à l'aide du template suivant.

Fin d'opération et communication#

Lorsque l'opération (CAASCHR) a été réalisée, il faut prévenir l'équipe Support.

Si des corrections ont eu lieu, le client doit également en être informé. Il faut indiquer à l'équipe Support les commits que nous avons réalisés dans le repo du client.