[PRD] Ajout/modification d'un receiver Type mail, dans la configuration d'Alertmanager#

Validation#

Ce Changement a été confirmé comme Changement Standard le 18/12/2024.

Contexte#

Un client nous a demandé d'ajouter ou de modifier un receiver dans la configuration Alertmanager

Critères d'éligibilité de Changement Standard#

Risque#

Ajouter un receiver qui ne fonctionne pas, cela n'a que très peu d'incidence car avant ce déploiement, il n'y a déjà pas eu d'envoi de ce même receiver.

Modifier un receiver qui ne fonctionne pas, cela n'a que très peu d'incidence, car c'est le client qui demande le changement et nous pouvons vite revenir en arrière Voir Procédure de rollback.

Impact#

L'impact est limité a l'Alertmanager client à déployer et à la zone NGOT qui l'accueille.

Changements précédents#

Procédure de rollback#

Redéployer le subtype alertmanager de la zone de service à partir de la zone master :

cd envs-ng
git switch master
git pull
nix-shell
cd contexts/ngot
trackbone apply -z <zone cloud> -c alertmanager

Merge Request Envs-ng#

La Merge Request Envs-ng est limitée au fichier zones/ngot_zones/client-XXX et aux fichiers générés du répertoire gen/. La modification consiste à ajouter un ou des bloc(s) comme ceci :

Configuration mail:

notifications_targets: [{
                        name:         "mail-XXX"
                        secret_creds: "mail-corp"
                        receiver: {
                            to:        "ues-genesys.interne@orange.com"
                            from:      "noreply@cloudservicesfactory.com"
                            smarthost: "email-smtp.eu-west-1.amazonaws.com:587"
                        }
                        route: {
                            matchers: ["alert_type= mail_alerte"]
                        }
                    }

CAASCHR#

Champs obligatoires#

Champ	Description
Titre	`[PRD][<CLIENT>] Alertmanager add/modify receiver`
Durée	1h00
Caascad Product	`Monitoring`
Customer Impact	`Workload <1m AND Caascad Services <5m (-)`
Responsable/Assignee	Indiquer la personne qui réalise le changement
Rapporteur/Reporter	Indiquer la personne qui rédige le ticket Jira

Liens Jira#

MR envs-ng
ticket jira CW (demande client)

Description#

Tip

Bien veiller à indiquer les bonnes valeurs là où sont placés des client.

Les valeurs à reporter dans la description sont fournie dans la demande client (en particulier matchers ).

h1. Changement Standard

Source : https://docs-internal.corp.caascad.com/Organisation/Gestion_du_changement/Changements_Standards/Templates/receiver_alertmanager_mail/

h2. Zones

svc-monitoring-stack-client-<client>

h2. Changement

On modifie la configuration du receivers pour <client>.
Il s'agit d'ajouter un receiver de type (mail/Webhook/etc).
*Note* : Pas de CAASCHR staging, car c'est un changement spécifique pour un client.

h2. Déploiement

Faire  :
{code}
trackbone plan -c alertmanager -z svc-monitoring-stack-client-<client>
{code}

Vérifier que le résultat est correct et attendu.

Faire un {{trackbone apply}} dans la MR envs-ng.

h2. Vérifications

h3. Configuration

{code}
kswitch svc-monitoring-stack-client-<client>
{code}

h3. Vérification

{code}
kubectl -n monitoring-stack-client-obs-<client> exec -it alertmanager-0 -- cat /tmp/alertmanager/alertmanager.yml | grep -A4 mail
{code}

*Résultat attendu*: on veut obtenir des lignes concernant la configuration mail avec les informations suivantes, bien vérifier l'adresse mail ainsi que les `matchers`

{code}
      receiver: mail-XXX
  - continue: true
    matchers:
    - app = cloudreporting
    - severity != info
{code}

h3. Logs

{code}
kubectl logs -n monitoring-stack-client-obs-<client> alertmanager-0
kubectl logs -n monitoring-stack-client-obs-<client> alertmanager-1
{code}

*Résultat attendu*: pas d'erreur dans les logs.

h2. Fin

Merger la MR envs-ng.

Se référer à la documentation indiquée au début du CAASCHR.