Aller au contenu

Nginx Alertreceiver / TrueSight: add internal client#

Contexte#

Il s'agit d'ajouter un client interne (la source des alertes provient de nos Alertmanagers) dans Nginx Alertreceiver.

CAASCHR#

Champ Description
Titre [PRD] Ajout d'un client interne dans Nginx Alertreceiver
Durée En général, il faut 1h

Dans la description, bien revoir ces points :

  • les objectifs
  • la procédure de vérification
  • la variable new_client (exemple NGOT : pour obs-pf, indiquer pf; exemple Caascad : pour ocb-corp, indiquer ocb-corp)
  • les différences Caascad/Ngot

Description#

h2. Zones

Si NGOT :
{code}
svc-monitoring-stack-client-$new_client prdcasa
{code}

Si Caascad :
{code}
$new_client prdcasa
{code}

h2. Préparatifs

{code}
new_client=($new_client)
{code}

h2. Contexte

Ce changement ne peux pas être validé en stg car c'est un changement spécifique sur PRDCASA.

h2. Changements

* Ajout d'un client interne dans Nginx Alertreceiver

h2. Déploiement

h3. Lancer la configuration `nginx-alertreceiver` avec le mode bootstrap

{code}
cd contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver -t bootstrap=true -t nginx_alertreceiver_zone_for_bootstrap=$new_client
{code}

Cette étape va :

- générer une nouvelle clef externe, exemple : `6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT`
- modifier la configuration de l'ingress avec $new_client, exemple :
  {code}
   + if ($request_uri = "/alertreceiver/test?apikey=6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT") {
   +   set $code "OVERRIDE_ME";
   +   set $cc_client "$new_client";
   +   set $resp_body "";
   + }
  {code}
- créer un nouveau secret dans Vault : {{secret/applications/nginx-alertreceiver/$new_client}}.

h3. Modifier le nouveau secret créé dans Vault

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

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

h3. Lancer la configuration `nginx-alertreceiver`

{code}
cd contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver
{code}

Cette étape va modifier la configuration avec la nouvelle clé API interne.

h3. Redéployer Alertmanager

Si NGOT :
{code}
cd contexts/ngot
trackbone apply -z svc-monitoring-stack-client-$new_client -c alertmanager
{code}

Si Caascad :
{code}
cd contexts/caascad
trackbone apply -z $new_client -c alertmanager-cloud-app
{code}

h2. Vérifications

h3. Vérification ingress Nginx Alertreceiver

{code}
kswitch prdcasa
kubectl get ingress -n nginx-alertreceiver -o yaml
{code}

*Résultat attendu* :
{code}
  if ($request_uri = "/alertreceiver/$new_client?apikey=6Wo1uIb4mWk8I8GSkfBYTSf8y8ILENTT") {
     set $code "xxxxxxxxxxxxx";
          set $cc_client "$new_client";
          set $resp_body "";
  }

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

h3. Vérification Alertmanager

Si NGOT :
{code}
kswitch svc-monitoring-stack-client-${new_client}
kubectl get cm -n monitoring-stack-client-obs-${new_client} -o yaml alertmanager | grep url
{code}

*Résultat attendu*: https://alertreceiver.prdcasa.caascad.com/alertreceiver/$new_client?apikey=CHANGEME_alertinghub

Si Caascad :
A ce jour, 02/11/2023, aucun Alertmanager Caascad n'a été connecté à Nginx Alertreceiver. Quand ce sera le cas il faudra ajouter une vérification.

h2. Merge

Merger la MR envs-ng si tout s'est bien passé.