Aller au contenu

[PRD] Ajout/modification d'un receiver Type webhook, 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
  • Delete du secret mattermost dans Vault :

Dans Vault dans applications/alertmanager/receivers

Aller au niveau du nom du secret puis delete

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 WebHook:

{
                        name: "mattermost-<name>"
                        route: {
                            matchers: ["app = defectdojo-ext", "severity != info"]
                        }
                        receiver: {
                            mattermost_template
                        }

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_webhook/

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

h3. Création du secret mattermost dans Vault

Dans Vault dans [applications/alertmanager/receivers|https://vault.infra-prd.caascad.com/ui/vault/secrets/secret/list/applications/alertmanager/receivers/]

cliquer sur 'Create secret'

dans 'Path for this secret' = <le nom du secret> il doit etre identique au code présent dans le fichier `zones/ngot_zones/client-XXX`
Dans 'secret data' On met l'url mattermost comme demandé dans ce ticket CW-xxxx de type :
{code}
url=https://mattermost.tech.orange/xxxxx
{code}

h3. envs-ng

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}

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

*Résultat attendu*: on veut obtenir des lignes concernant la notification_target avec les informations suivantes, bien vérifier le nom du `secret` ainsi que l'url du webhook.

{code}
- name: <le nom du secret>
  slack_configs:
  - api_url: https://mattermost.tech.orange/XXXX
{code}

h3. Grafana

Vérifier dans [Grafana|https://grafana.obs-corp-prd.cloudservicesfactory.com] qu'il n'y a pas d'erreurs de notifications.
Requête :
{code}
alertmanager_notifications_failed_total{obs_client="<client>", integration="slack"}
{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.