Aller au contenu

Environnement Grafana mutualisé#

Objectifs#

  • déployer la zone contract.
  • déployer la zone Grafana mutualisé ;

Note

Avant de commencer le déploiement, il faut s'assurer que les zones de services monitoring-stack-client à connecter au Grafana mutualisé existent. Les informations de ces zones sont nécessaires pour le déploiement de la zone service Grafana mutualisé.

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#

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"]},{"n":"ngot_service","r":false,"e":true,"v":["svc-grafana-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 :

  • 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-grafana-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 mis en place.

Configuration des zones#

Ajout de la zone Grafana mutualisé dans Envs-ng#

Créer un fichier zones/ngot_zones/client-<client>.cue pour ajouter les zones dans envs-ng.

Pour créer ce fichier, on peut s'inspirer du fichier zones/ngot_zones/client-evp.cue.

Note

En date du 26/01/2024, les seules zones de service Grafana mutualisé qui existent sont celles du projet Evolve : svc-grafana-client-evp, svc-grafana-client-evpcns et svc-grafana-client-evpcco.

Lorsque les zones de service Grafana mutualisé seront plus démocratisées, nous pourrons retirer cette note.

Les zones copiées sont :

  • zone contract : obs-evp ;
  • zone de service "grafana-client" : svc-grafana-client-evp.

Note

Afin de remplir le parent_zone_name de chaque zone de service, il faut identifier les clusters hébergeant les zones de subtype grafana-client connectées au Grafana mutualisé. Il est forcement conseillé d'utiliser un de ces clusters.

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

Il faut copier la configuration de svc-grafana-client-evp et adapter les parties suivantes (il s'agit d'un exemple pour evp sur NGOT) :

Note

En date du 26/01/2024, les seules zones de service Grafana mutualisé qui existent sont celles du projet Evolve : svc-grafana-client-evp, svc-grafana-client-evpcns et svc-grafana-client-evpcco.

Lorsque les zones de service Grafana mutualisé seront plus démocratisées, nous pourrons retirer cette note.

  • connected_zones en mettant le nom du client des zones de services monitoring-stack-client connectés ;
  • parent_zone_name en mettant le cluster dans lequel sera déployé le Grafana mutualisé ;
  • _mutualized_datasource_alertmanager (à deux endroits) en mettant le nom du client des zones de services monitoring-stack-client connectés.

Note

La définition d'une zone de service Grafana mutualisé a la forme ci-dessous.

Préférer la copie d'une zone existante plutôt que de recopier la documentation ci-dessous, moins à jour que le code des zones. Exemple:

"svc-grafana-client-<CLIENT>": {
        let shortname = "<CLIENT>"
        let connected_zones = "<BASEPORT>:<BASENUM>:<DATASOURCE_1>,<DATASOURCE_2>,<DATASOURCE_3>"
        type:               "service"
        subtype:            "grafana-client"
        parent_zone_name:   "<CLUSTER>"
        contract_zone_name: "obs-\(shortname)"
        parameters: {
            _thanos_query_connected_services_mutualized: "\(connected_zones)": _
            thanos_query_connected_services: _thanos_query_connected_services_mutualized[connected_zones]

            _datasource_thanos: "\(shortname)":            _
            _mutualized_datasource_alertmanager: "<DATASOURCE_1>": _
            _mutualized_datasource_alertmanager: "<DATASOURCE_2>": _
            _mutualized_datasource_alertmanager: "<DATASOURCE_3>": _

            datasources: {
                _datasource_thanos[shortname]
                _mutualized_datasource_alertmanager["<DATASOURCE_1>"]
                _mutualized_datasource_alertmanager["<DATASOURCE_2>"]
                _mutualized_datasource_alertmanager["<DATASOURCE_3>"]
            }
        }
    }

Explications :

  • <BASEPORT> : Indiquer 10000 sauf si on sait ce qu'on fait.
  • <BASENUM> : Indiquer 1 sauf si on sait ce qu'on fait.
  • <DATASOURCE_x> : représente le nom de la zone connectée à cette nouvelle instance de Grafana mutualisé (une ou plusieurs).
  • <CLUSTER> : pour choisir le cluster sur lequel déployer le nouveau Grafana mutualisé. Il est préférable qu’il soit sur le même cluster que la zone qui lui sera connectée. S’il y a plusieurs zones connectées à ce Grafana mutualisé, il suffit de choisir un cluster sur lequel l’une de ces zones est déployée.

Si la demande veut que thanos-query soit exposé sur LB public, il faudra l'ajouter dans la définition de la zone : 

"svc-grafana-client-<CLIENT>": {
        ...
        parameters: {
            ...
            expose_thanos_query: true
        }
    }

Regénération des zones#

Lorsque les zones sont copiées, il faut regénérer les zones générées : 

generate-static-zones-files

Déploiement des zones#

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

nix-shell
cd contexts/ngot

Dans les commandes suivantes, nous utiliserons ces variables : 

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

Exemple pour obs-evp :

CLIENT=evp
CLUSTER=kub-21

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 --add-services

Mise à jour des configurations existantes#

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

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

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

Zone "grafana-client"#

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

kswitch $CLUSTER
kubectl create ns grafana-client-obs-${CLIENT}
kubectl edit ns grafana-client-obs-${CLIENT}

Exemple: 

apiVersion: v1
kind: Namespace
metadata:
  labels:
    config-sync.caascad.com/secret: "true"

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.

Redéploiement des ingress controller#

trackbone apply -z "${CLUSTER}" -c ingress_controller_v2_public

Modification de l'objet NetworkPolicy#

trackbone apply -z svc-monitoring-stack-client-<connected_client> -c kube-prometheus-stack
Le parametre <connected_client_x> est le nom des zones clientes connectées à Grafana mutualisé.

Exemple pour evp, le parametre connected_client_x prends la valeur evpo, mais ça peut prendre des valeurs multiples (dans ce cas, executez la commande pour chacune de ces valeurs).

Mise à jour external_dns#

S'il agit d'une nouvelle zone (et non d'une zone qui existait déja et à laquelle on a ajouté des nouvelles zones connectées), mettre à jour la config external_dns:

trackbone apply -z "${CLUSTER}" -c external_dns --non-interactive

Vérifications#

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". Si tel est le cas, on peut :

Créer, faire valider et merger 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}

Lancer les tests de conformité#

Tip

Pour chaque test, il faut s'assurer au préalable :

  • d'avoir lancé kswitch svc-xxx sur la zone du test
  • d'avoir lancé la commande nix-shell dans le répertoire xxx/tests du test (ce n'est pas forcément la même version de la toolbox selon les répertoires de tests)

Lancer les tests de conformité indiqués ici :

Grafana#

Se connecter à Grafana (https://grafana.obs-<client>.cloudservicesfactory.com) avec son compte Keycloak/Caascad (Sign-in with Keycloak > caascad).

Keycloak

Pour valider la configuration du Grafana mutualisé, il faut constater :

  • que l'on peut se connecter ;
  • que l'on a les droits attendus ;
  • que les datasources alertmanager des zones de services monitoring-stack-client connectées au Grafana mutualisé fonctionnent et sans erreur ;
  • que l'on retrouve des métriques venant des zones de services monitoring-stack-client connectées au Grafana mutualisé. (exemple: alertmanager_alerts en s'assurant que les noms des clients remontent dans le label obs_client).

Warning

La vérification des métriques doit se faire sur toutes les datasources.

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.

Ticket Jira#

Le ticket Jira pourra être rempli avec ces commentaires

h1. Grafana

[sum(alertmanager_alerts) by (ngot_contract)|https://grafana.obs-XXXXXX.cloudservicesfactory.com/explore?orgId=1&left=%7B%22datasource%22:%22thanos%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22sum%28alertmanager_alerts%29%20by%20%28ngot_contract%29%22,%22range%22:true,%22instant%22:true,%22datasource%22:%7B%22type%22:%22prometheus%22,%22uid%22:%22thanos%22%7D,%22editorMode%22:%22code%22%7D%5D,%22range%22:%7B%22from%22:%22now-1h%22,%22to%22:%22now%22%7D%7D]

Remplacer les XXXXXX par le nom de la zone (exemple : XXXXXX devient evp)

S'il a été demandé que Thanos-query soit exposé sur LB public, ajouter également ce commentaire :

h1. Thanos-query

https://metrics-query.obs-XXXXXX.cloudservicesfactory.com/
https://vault.infra-prd.caascad.com/ui/vault/secrets/secret/show/zones/fe/svc-grafana-client-XXXXXX/thanos-query-auth

Remplacer les XXXXXX par le nom de la zone (exemple : XXXXXX devient evp)

Enfin, un commentaire pour Karma sera apprécié :

h1. Karma

Pas d'alertes : [Karma prd|https://karma-infra.infra-prd.caascad.com/?q=obs_client%3DXXXXXX]

Remplacer les XXXXXX par le nom de la zone (exemple : XXXXXX devient evp)