Aller au contenu

Environnement Loki#

Objectifs#

  • déployer l'environnement Loki ;

Note

Une zone de contrat existe déjà, il faut utiliser la même que l'environnement de supervision associé.

Dans la suite de la documentation, nous utiliserons ces variables :

CLIENT=<client>

Exemple pour obs-pf :

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

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.

Silences#

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

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"]},{"n":"ngot_service","r":false,"e":true,"v":["svc-loki-client-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 : dans 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 du client : obs_client=xxxx ;
    • le nom de la zone : ngot_service="svc-loki-client-$CLIENT" ;
  • commentaire : Provisioning nouvelle zone NGOT ;
  • durée : 7 jours

Exemple : Silences dans karma

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

Initialisation du repo des rules Loki#

Créer un dossier vide dans loki-client-rules avec le nom du contrat.

mkdir obs-${CLIENT}

Créer une configmap vide : 

kswitch svc-monitoring-stack-client-${CLIENT}
kubectl create ns loki-client-obs-${CLIENT}
kubectl create configmap -n loki-client-obs-${CLIENT} loki-rules --from-file obs-${CLIENT}/ -o yaml --dry-run=client | kubectl apply -f -

Pousser le nouveau dossier vide dans git.

touch obs-${CLIENT}/.gitignore
git add obs-${CLIENT}/
git commit -m "add obs-${CLIENT}"
git push

Note

Explication sur le kswitch : la zone de service svc-monitoring-stack-client-${CLIENT} et la zone de service qui n'est pas encore créée svc-loki-client-${CLIENT} vont être sur le même cluster k8s.

Configuration des zones#

Ajout de la zone Loki dans Envs-ng#

Le fichier concerné est zones/ngot_zones/client-$CLIENT.cue.

La zone à ajouter est :

  • zone de service "loki-client" : svc-loki-client-$CLIENT.

Pour ajouter cette zone on peut copier la zone svc-loki-client-pf qui est dans le fichier zones/ngot_zones/client-pf.cue

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

Warning

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

Rétention par défaut : 

retention: *"15d" | string

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

"svc-loki-client-pf": {
        ...
    parameters: {
        loki: {
            retention: "<x>d"
        }
    }
}

Configuration de la datasource Loki dans la zone grafana associée#

Il faut ajouter une datasource Loki pour Grafana. Ajouter les lignes _datasource_loki au fichier zones/ngot_zones/client-$CLIENT.cue (il s'agit d'un exemple pour pf sur NGOT) :

"svc-grafana-client-pf": {
        let shortname = "pf"
        ...
        parameters: {
            _thanos_query_connected_services_default: "\(shortname)": _
            thanos_query_connected_services: _thanos_query_connected_services_default[shortname]

            _datasource_thanos: "\(shortname)":       _
            _datasource_alertmanager: "\(shortname)": _
            _datasource_loki: "\(shortname)":         _
            datasources: {
                _datasource_thanos[shortname]
                _datasource_alertmanager[shortname]
                _datasource_loki[shortname]
            }
        }
    }

Regénération des zones#

Lorsque la zones est copiée et que la datasource est ajoutée, il faut regénérer les zones générées : 

generate-static-zones-files

Créer une Merge Request envs-ng#

Note

Cette étape est nécessaire seulement quand vous exécutez le déploiement de Loki dans une étape à part (par exemple quand un client a dejà une zone et il souhaite ajouter le service de logging à sa zone).

Créer une MR avec ces modifs :

  • ajout de la zone de service loki ;
  • ajout de la datasource Loki dans Grafana.
cd ${ENVS_NG}
git add zones/ngot_zones/values.cue
git add gen/
git commit -m "zone: init obs-${CLIENT} loki service"

Déploiement des zones#

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

nix-shell
cd contexts/ngot

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

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

Zone "loki-client"#

Warning

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

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

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

Warning

Le déploiement de certains composants Loki (compactor, ingester, distributor) peut avoir des problèmes. En parallèle du déploiement, on peut regarder le status des pods Loki : 

kubectl get pod -n loki-client-obs-${CLIENT} -w
Si certains pods sont en CrashLoopBackOff avec cette erreur dans les logs : 
failed services
github.com/grafana/loki/pkg/loki.(*Loki).Run
   /src/loki/pkg/loki/loki.go:508
main.main
   /src/loki/cmd/loki/main.go:105
runtime.main
   /usr/local/go/src/runtime/proc.go:250
runtime.goexit
   /usr/local/go/src/runtime/asm_amd64.s:1598
Vous pouvez les supprimer, et l'erreur ne devrait pas se reproduire.

trackbone apply -z "svc-loki-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.

Datasource Loki#

trackbone apply -z "svc-grafana-client-${CLIENT}" -c grafana --add-services

Credentials Loki dans le repo du client#

Les credentials se trouvent dans vault : secret/zones/fe/svc-loki-client-xxxxx/loki-write/.

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

Le script suivant configure les credentials Loki dans les variables CI/CD du repository client : 

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

Finalisation envs-ng (merger la MR)#

Dans la Merge Request, indiquer trackbone plan ngot en commentaire. Observer le résultat.

Après les déploiements, il faut s'attendre à un "no-change".

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 (exemple : svc-loki-client-xxxx). Cela revient au même.

Mise à jour des configurations existantes#

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

Warning

Il faut avoir "mergé" la MR ci-dessus pour mettre à jour les configurations existantes, qui s'appuient sur ngot-zones de la branche master.

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

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
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 ingress_nginx_public --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
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 ingress_nginx_public --non-interactive

Vérifications#

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 && cd poc_check_functional_tests_monitoring/ngot
./func_tests_svc_grafana_client.sh "${CLIENT}" # example : ./func_tests_svc_grafana_client.sh pf
./func_tests_svc_loki_client.sh "${CLIENT}" # example : ./func_tests_svc_loki_client.sh pf

Gitops Workflow et creds Loki#

Vérifier la cohérence Login/Password de Vault/sourcehub et la connexion à Loki 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.

export GITLAB_TOKEN=xxxxx
git clone git@git.corp.caascad.com:caascad/applications/check_ngot_credentials.git && cd check_ngot_credentials
./check_loki_creds_in_vault_and_gitlab.sh "${CLIENT}" 2>/dev/null && echo OK

Grafana#

Se connecter à Grafana (https://grafana.obs-<client>.cloudservicesfactory.com).

Il faut constater dans Explore qu'il n'y a pas d'erreur quand la datasource loki est choisie.

Dernières étapes#

Karma#

Dans Karma infra-prd :

  • 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 loki-client

Tests fonctionnels
- (x) Tests fonctionnels zone loki-client
- (x) Tests fonctionnels zone grafana-client
- (x) Test de connexion à Loki avec les creds du client (et vérification de la cohérence Vault/Gitlab)

Spécifications de la zone
- (x) Datasource Loki dans Grafana
- (x) Rétention Logging (correspond à la demande)

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

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

Références#