Utilisation de Prométheus Alertmanager pour la surveillance active Ci/cd

Pourquoi la surveillance proactive des pipelines CI/CD est-elle importante?

Les pipelines d'intégration et de déploiement continu (IC/CD) constituent l'épine dorsale de la livraison moderne des logiciels. Ils automatisent tout, de l'intégration de code à l'essai, à la construction et au déploiement en production. Lorsqu'un pipeline se brise, il peut bloquer toute l'équipe de développement, retarder les rejets et, s'il n'est pas remarqué, pousser le code défectueux à la production.

Prométhée est une boîte à outils de surveillance et d'alerte open-source de premier plan, conçue pour la fiabilité et l'évolutivité. Sa composante d'alerte, Alertmanager, gère le travail complexe de gestion des alertes – regroupement des notifications connexes, suppression des duplicata, et les acheminer vers les bonnes personnes ou les bons systèmes.

Comprendre Prométheus Alertmanager

Prométheus Alertmanager n'est pas un système autonome, il fonctionne en accord avec le serveur Prométheus. Le serveur recueille des paramètres et évalue les règles d'alerte définies dans la configuration. Lorsqu'une condition de règle est remplie, une alerte est déclenchée et envoyée à Alertmanager. Alertmanager prend alors le relais, appliquant le routage, le regroupement, l'inhibition et le silencieux avant d'envoyer des notifications par différents canaux : email, Slack, PagerDuty, OpsGenie, webhooks, etc.

Composantes essentielles de l'alerteur

• Ingestion alerte: reçoit des alertes de Prométhée via l'API HTTP. Les alertes comprennent des étiquettes (p. ex. , ) et des annotations (p. ex., résumé, description).
• Logique de groupe:[ Règles configurables qui consolident des alertes similaires en notifications uniques. Par exemple, groupez toutes les défaillances de construction par nom de pipeline et environnement.
• Arbre de coupure:[ Arbre de récepteurs qui décide où les alertes vont en fonction de la correspondance des étiquettes. Les alertes peuvent suivre plusieurs branches avec différentes configurations.
• Silençage et inhibition:[ Suppression temporaire des alertes pendant la maintenance ou lorsque des alertes prioritaires rendent celles qui sont moins prioritaires redondantes.
• Mutage basé sur le temps:[ Utilisez des minuteurs muets pour supprimer les alertes selon un calendrier (p. ex. déploiements courants ou emplois de nuit).

Comment les alertes passent par le système

1. Prométheus gratte les mesures des exportateurs ou des paramètres (p. ex., les mesures Jenkins, les mesures de l'IC GitLab, le statut de la pod Kubernetes).
2. Selon les règles d'alerte définies dans la configuration de Prométhée, les conditions déclenchent une alerte (p. ex., taux de défaillance de construction > 5 % en 10 minutes).
3. Le responsable de l'alerte reçoit l'alerte incendie, applique les réglages d'attente et d'intervalle de groupe, fait le lot d'alertes et les dirige.
4. Les notifications sont envoyées aux récepteurs configurés. Les réponses peuvent déclencher des actions automatisées (p. ex., webhook pour redémarrer un travail bloqué).

Comprendre ce flux est essentiel pour régler Alertmanager afin d'éviter la fatigue alerte tout en veillant à ce que les événements critiques ne soient jamais manqués.

Pourquoi utiliser le gestionnaire d'alerte spécifiquement pour la surveillance de l'IC/DC?

Sans alerte intelligente, les équipes se noient dans des notifications bruyantes – chaque test échoué, déploiement lent ou blip réseau intermittent déclenche un message. Alertmanager résout cela par :

• Réduction du bruit:[ Le regroupement fusionne les alertes provenant du même pipeline ou cause, de sorte qu'une notification couvre plusieurs défaillances connexes.
• Les problèmes critiques prioritaires:[ Le routage peut envoyer des alertes de haute gravité (p. ex., défaillance du déploiement) à PagerDuty alors que les alertes de faible gravité vont à un canal de journal Slack.
• Déduplication manuelle :[ Prévient les alertes répétées pour la même condition, ce qui est fréquent lorsque les mesures sont éliminées toutes les 15 secondes.
• Fenêtres de maintenance : Alertes de silence lors des déploiements prévus ou des mises à niveau de l'infrastructure pour éviter les fausses alarmes.

La surveillance proactive avec Alertmanager permet de détecter les tendances de dégradation des pipelines (p. ex., augmentation du temps de construction) avant qu'elles ne causent une défaillance totale.

Mise en place du Prométhée et du gestionnaire d'alerte pour votre pipeline CI/CD

La mise en place d'une base d'alerte solide nécessite la configuration à la fois de Prométhée et d'Alertmanager. Ci-dessous est un guide étape par étape avec des considérations du monde réel.

Étape 1: Déployer Prométhée et alerteur

Si vous n'avez pas déjà, installez Prométheus et Alertmanager. Les approches courantes comprennent l'utilisation de Docker, Kubernetes Helm graphes, ou des paquets natifs. Pour un environnement de test simple, vous pouvez utiliser docker-composer:

version: '3'
services:
 prometheus:
 image: prom/prometheus:latest
 volumes:
 - ./prometheus.yml:/etc/prometheus/prometheus.yml
 ports:
 - "9090:9090"

 alertmanager:
 image: prom/alertmanager:latest
 volumes:
 - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
 ports:
 - "9093:9093"

Voir le document officiel pour les configurations de niveau de production.

groups:
 - name: CI/CD Alerts
 rules:
 - alert: BuildFailureHigh
 expr: rate(jenkins_job_last_result{result="failure"}[5m]) > 0.1
 for: 2m
 labels:
 severity: critical
 annotations:
 summary: "High build failure rate in pipeline {{ $labels.job }}"
 description: "Build failure rate > 10% over 5 minutes for job {{ $labels.job }} in environment {{ $labels.env }}"

 - alert: DeploymentDurationAnomaly
 expr: histogram_quantile(0.95, rate(deployment_duration_seconds_bucket[10m])) > 300
 for: 5m
 labels:
 severity: warning
 annotations:
 summary: "Deployment duration anomaly for service {{ $labels.service }}"
 description: "95th percentile deployment duration exceeds 5 minutes"

route:
 group_by: ['alertname', 'job', 'env']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 4h
 receiver: 'default'
 routes:
 - match:
 severity: critical
 receiver: 'pagerduty-critical'
 continue: true
 - match:
 severity: warning
 receiver: 'slack-warnings'

receivers:
 - name: 'pagerduty-critical'
 pagerduty_configs:
 - service_key: <your-pagerduty-key>
 - name: 'slack-warnings'
 slack_configs:
 - api_url: https://hooks.slack.com/services/...
 channel: '#ci-cd-alerts'
 send_resolved: true

Pour un guide complet, voir la documentation de configuration Alertmanager.

Étape 5 : Intégrer l'automatisation des interventions en cas d'incident

La surveillance proactive n'est efficace que si les alertes mènent à l'action. Utilisez les webhooks dans Alertmanager pour déclencher des réponses automatiques :

• Envoyer un webhook à un outil comme Rundeck ou Ansible pour réessayer un déploiement raté.
• Revenez automatiquement à la dernière bonne construction connue lorsqu'une alerte de déploiement de haute gravité tire.
• Créer un ticket Jira ou un incident de PagerDuty à partir d'alertes critiques.

De nombreuses équipes utilisent également Grafana OnCall (ou similaire) pour gérer les escalades et les horaires de garde en plus de Alertmanager.

Fonctions de gestionnaire de alerte avancé pour la surveillance proactive des IC/CD

Une fois le routage de base configuré, utilisez des fonctionnalités avancées pour affiner votre surveillance.

Règles d'interdiction

Par exemple, si un noeud Kubernetes descend (alerte critique), vous n'avez pas besoin d'alertes sur chaque pipeline qui peut programmer des pods (alertes d'avertissement). Ajouter à :

inhibit_rules:
 - source_match:
 severity: 'critical'
 target_match:
 severity: 'warning'
 equal: ['namespace', 'cluster']

Cela réduit le bruit lors des pannes de cascade.

Silencing et minuteries Mute

Planifiez des fenêtres de maintenance de routine avec des minuteurs mutés. Par exemple, si vous déployez chaque mardi à 2h du matin, supprimez les alertes liées au déploiement pendant cette fenêtre :

mute_time_intervals:
 - name: tuesday_deploy
 weekdays: ['Tuesday']
 time_intervals:
 - times: ['02:00', '04:00']

Référencez le minuteur muet dans votre itinéraire : . Cela empêche la fatigue d'alerte des activités opérationnelles attendues.

Webhooks pour les actions personnalisées

Au-delà de Slack et PagerDuty, utilisez des webhooks pour s'intégrer à l'outillage interne. Par exemple, un récepteur webhook peut appeler une API pour redémarrer automatiquement un pipeline bloqué :

receivers:
 - name: 'webhook-auto-fix'
 webhook_configs:
 - url: 'https://internal-api.example.com/pipeline/restart'
 send_resolved: true

Mesures clés Chaque pipeline IC/CD devrait surveiller

Pour définir des règles d'alerte efficaces, vous devez savoir quelles sont les mesures importantes. Le cadre de recherche et d'évaluation de la DORA (DevOps Research and Assessment) identifie quatre mesures clés :

• Fréquence de déploiement:[ Combien de fois vous vous déployez à la production. Alertez sur les chutes en dessous d'un seuil.
• Temps de mise en attente pour les changements :[ Temps de mise en attente au déploiement.
• Délai de récupération (MTTR):[ Délai de récupération des défaillances.
• [ Pourcentage de déploiements causant des défaillances.

Prométhée peut suivre ces derniers par l'intermédiaire d'exportateurs personnalisés ou de pipelines de log-to-metrics.

 - alert: MTTRTooHigh
 expr: avg by (service) (deployment_recovery_time_seconds) > 3600
 for: 10m
 labels:
 severity: warning
 annotations:
 summary: "MTTR for {{ $labels.service }} exceeds 1 hour"

Pratiques exemplaires pour l'alerte sur les pipelines CI/CD

Le surchauffe est un piège commun. Suivez ces lignes directrices pour garder votre alerte efficace.

Définir des seuils significatifs

Analyser les incidents passés pour déterminer ce qui constitue une véritable alerte par rapport à une fluctuation normale. Utiliser des seuils dynamiques (par l'entremise de règles d'enregistrement) pour déterminer l'adaptabilité.

Utiliser des niveaux de gravité multiples

Cartographier les gravités des interventions :

• Critical: Le pipeline est complètement bloqué ou le déploiement de la production échoue.
• Avertissement :[ Dégradation de la performance, augmentation du taux de défaillance, utilisation des ressources proche de la limite.
• Info: Notifications courantes (p. ex., achèvement de la maintenance).

Règles d'alerte avec données réelles

Utilisez les outils de test intégrés Prométheus ou la commande pour vérifier les règles avant de déployer. Simuler les conditions d'alerte dans un environnement de mise en scène.

Configurations d'alerte de document

Maintenez un wiki ou un roundbook expliquant chaque but d'alerte, ce qu'il faut faire au moment du déclenchement et comment faire pour faire taire si nécessaire.

Examen et amélioration réguliers

Réglez une révision trimestrielle de toutes les règles d'alerte. Supprimez les règles d'impasse, ajustez les seuils et ajoutez de nouveaux pour les pipelines modifiés.

Intégration de la gestion des alertes aux plateformes populaires CI/CD

Jenkins

Installez le Prométheus métriques plugin[ pour exposer les nombres de constructions, les durées et les résultats. Alerte sur les tailles de file d'attente en croissance ou les travaux coincés dans l'état --en attente.

GitLab CI

GitLab expose un paramètre pour les coureurs. Surveillez la disponibilité des coureurs et les délais d'exécution des pipelines. Pour fusionner les pipelines de requête, utilisez des mesures personnalisées via la porte-poussoir.

Actions GitHub

Puisque GitHub Actions n'expose pas nativement les métriques Prométhée, poussez les métriques à partir des flux de travail en utilisant la passerelle. Alertez sur les échecs des flux de travail ou les taux de temps d'arrêt.

# In a workflow step
- name: push metrics
 run: |
 echo "pipeline_status{workflow=\"deploy\",result=\"${{ job.status }}\"} 1" | curl --data-binary @- http://pushgateway:9091/metrics/job/github_actions/instance/${{ github.run_id }}

Kubernetes Native Pipelines (Tekton, Argo Workflows)

Utilisez pour surveiller les gousses de pipeline et les définitions des ressources personnalisées (DCR).

Pièges courants et comment les éviter

Même avec une configuration forte, les équipes rencontrent des défis. Voici comment les naviguer:

• Alerte fatigue:[ Seuils trop sensibles ou trop d'alertes de faible gravité. Solution : relever les seuils, alertes agrégées avec regroupement et utiliser la mutation pendant les cycles connus.
• Missing critical alerts:[ Règles non définies pour certains modes de défaillance (p. ex., pannes de construction silencieuse dues à des tests flous). Solution : examiner périodiquement les rapports d'incident et ajouter les règles d'alerte correspondantes.
• Plomb de notification:[ Même alerte envoyée à plusieurs canaux. Solution : utiliser soigneusement le routage – faire suivre les alertes critiques vers PagerDuty, les alertes à relâcher et les informations aux archives de courriel.
• Dérivation de configuration:[ Alertmanager modifications de configuration sans examen. Solution: version contrôler votre et utiliser CI/CD pour déployer des modifications avec approbation.

Surveillance de l'EIG

Prométhée et Alertmanager peuvent se surveiller. Expose Prométhée possède des mesures et met en place des alertes pour les défaillances d'Alertmanager (par exemple, les notifications défaillantes, les silences venant à expiration).

 - alert: AlertmanagerNotificationFailing
 expr: rate(alertmanager_notifications_failed_total[10m]) > 0.01
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "Alertmanager notifications are failing"

Assurez-vous que votre boucle de surveillance est résistante pour éviter les taches aveugles.

Conclusion

En configurant des règles d'alerte bien adaptées, un regroupement intelligent et un routage robuste, vous obtenez la capacité de détecter les problèmes avant qu'ils ne s'aggravent, qu'il s'agisse d'une construction lente, d'une anomalie de déploiement ou d'une défaillance de l'infrastructure en cascade. Le système est suffisamment souple pour s'intégrer à toute plateforme CI/CD, et sa nature open-source vous permet de l'adapter à vos besoins exacts sans frais de licence.