Alertmanager-jira : intégration des alertes avec Jira

# Intégration d'Alertmanager avec Jira : Plugin Webhook Flexible sur Quarkus

Alertmanager-jira est un plugin webhook open-source pour Alertmanager (Prometheus, VictoriaMetrics) qui crée et gère des tickets dans Jira. Il prend en charge l'attribution aux assignees, les champs personnalisés, les modèles de description, et la détection de doublons via JQL. Construit sur Quarkus, il se déploie via Docker/Podman. Cet outil pallie les limites des alternatives comme jiralert, en offrant un contrôle total sur les tickets sans scripts personnalisés.

Problèmes des solutions existantes

Jiralert de prometheus-community crée des tickets basés sur group_key, utilise des templates Go, et prend en charge la résolution automatique. Cependant, en pratique, il présente ces limitations :

• Configuration minimale : templates YAML basiques, pas de support pour les champs personnalisés ou les requêtes JQL dynamiques.
• Les hachages group_key longs cassent l'UI de Jira.
• Développement lent : bugs ouverts depuis 2018, mises à jour rares.

Les autres options incluent des solutions enterprise comme PagerDuty ou des scripts personnalisés. Alertmanager-jira offre de la flexibilité : valeurs par défaut pour les projets/types de tickets, overrides dans les alertes, et commentaires sur les tickets existants.

Déploiement en conteneur

Le projet fournit des images Docker sur hub.docker.com. Exemple de lancement avec Podman (similaire à Docker) :

podman run -it --rm --name alertmanager-jira \
    --env JIRA_URL=https://your-jira.com \
    --env JIRA_USERNAME=service-account \
    --env JIRA_PASSWORD=your-token \
    -p 8080:8080 \
        hubbitus/alertmanager-jira:latest

Configuration d'Alertmanager

Ajoutez un receiver dans alertmanager.yml :

receivers:
  - name: 'jira'
    webhook_configs:
      - url: 'http://your-host:8080'
        send_resolved: true

Configuration des alertes dans Prometheus/VictoriaMetrics

Les champs Jira sont définis en utilisant le préfixe jira__ dans les labels/annotations des règles. Les templates Groovy SimpleTemplate sont pris en charge.

Exemple prometheus-rules.yml :

groups:
- name: example
  rules:
  - alert: HighCPU
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 1m
    labels:
      severity: critical
      jira__field__severity: High
    annotations:
      summary: "High CPU on {{ $labels.instance }}"
      description: "CPU usage above 80%."
      jira__project_key: OPS
      jira__issue_type_name: Incident
      jira__field__assignee: oncall-sre
      jira__field__labels: 'monitoring, cpu, alert'
      jira__field__component_s: 'DevOps+infrastructure, DQ-issues+alerts'
      jira__field__name__1: 'Custom Field'
      jira__field__value__1: 'Some dynamic value: ${context.alert.severity}'

Valeurs par défaut dans prometheus.yml via alert_relabel_configs :

alerting:
  alert_relabel_configs:
    - source_labels: [__alert_severity]
      target_label: jira__field__severity
      regex: critical;High
    - target_label: jira__project_key
      replacement: OPS

Les overrides dans les alertes spécifiques ont la priorité. Templates :

• ${context.alert.fingerprint} — hachage de l'alerte.
• ${context.jiraProject.name} — métadonnées du projet.
• JQL pour la recherche : labels = "alert[${context.alert.hashCode()}]") AND statusCategory != Done.

Implémentation technique

Construit sur Java + Groovy (Quarkus), Atlassian Jira SDK. Tests : tests unitaires pour l'analyse, tests d'intégration sur une instance Jira externe. La CI n'exécute pas les tests en raison des restrictions de licence Jira — nécessite des exécutions manuelles sur un serveur déployé.

Améliorations possibles : intégrer les tests dans la CI en utilisant des licences temporaires ou des serveurs mock.

Fonctionnalités clés

• Flexibilité des champs : n'importe quels champs personnalisés, labels, composants via le préfixe jira__ et les templates.
• Déduplication : recherche JQL pour les tickets existants avec option de commentaire.
• Automatisation : réduit le MTTR en DevOps/SRE/ITSM via des tickets auto.
• Prêt pour la production : 2 ans en production sur une plateforme de données.
• Open-source : Apache 2.0, GitHub pour les issues/PRs.

— Editorial Team