Alertmanager-jira: integracja alertów z Jira

# Integracja Alertmanager z Jira: elastyczny plugin webhook na Quarkus

Alertmanager-jira — open-source'owy plugin webhook dla Alertmanager (Prometheus, VictoriaMetrics), który tworzy i zarządza zadaniami w Jira. Obsługuje przypisywanie wykonawców, niestandardowe pola, szablony opisów oraz wyszukiwanie duplikatów za pomocą JQL. Został opracowany na Quarkus, wdrażany w Docker/Podman. Narzędzie rozwiązuje problemy ograniczonych alternatyw, takich jak jiralert, zapewniając pełną kontrolę nad ticketami bez samodzielnie pisanych skryptów.

Problemy istniejących rozwiązań

Jiralert od prometheus-community tworzy zadania na podstawie group_key, wykorzystuje szablony Go, obsługuje automatyczne zamykanie. Jednak w praktyce ujawniono ograniczenia:

• Minimalne opcje konfiguracji: podstawowe szablony w YAML, brak wsparcia dla niestandardowych pól i dynamicznych zapytań JQL.
• Długie hashe group_key psują interfejs użytkownika Jira.
• Wolny rozwój: otwarte błędy od 2018 roku, rzadkie aktualizacje.

Inne warianty to rozwiązania enterprise, takie jak PagerDuty, lub samodzielny kod. Alertmanager-jira zapewnia elastyczność: domyślne wartości dla projektów/typów zadań, nadpisywanie w alertach, komentarze do istniejących ticketów.

Wdrażanie w kontenerze

Projekt jest dostarczany z obrazami Docker na hub.docker.com. Przykład uruchomienia z Podman (analogicznie do 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

Konfiguracja Alertmanager

W pliku alertmanager.yml dodaj receiver:

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

Konfiguracja alertów w Prometheus/VictoriaMetrics

Pola Jira są ustawiane za pomocą prefiksu jira__ w labels/annotations reguł. Obsługiwane są szablony Groovy SimpleTemplate.

Przykład pliku 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}'

Domyślne wartości w prometheus.yml za pomocą 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

Nadpisywanie w konkretnych alertach ma priorytet. Szablony:

• ${context.alert.fingerprint} — hash aleru.
• ${context.jiraProject.name} — metadane projektu.
• JQL do wyszukiwania: labels = "alert[${context.alert.hashCode()}]") AND statusCategory != Done.

Realizacja techniczna

Na bazie Java + Groovy (Quarkus), Atlassian Jira SDK. Testy: modułowe do parsowania, integracyjne na zewnętrznym instancie Jira. CI nie uruchamia testów z powodu ograniczeń licencyjnych Jira — wymagany ręczny start na wdrożonym serwerze.

Możliwe ulepszenia: integracja testów w CI za pomocą tymczasowych licencji lub mock-serwerów.

Co ważne

• Elastyczność pól: dowolne niestandardowe pola, labels, components za pomocą prefiksu jira__ i szablonów.
• Deduplikacja: wyszukiwanie JQL istniejących zadań z opcją komentarzy.
• Automatyzacja: skrócenie MTTR w DevOps/SRE/ITSM dzięki auto-ticketom.
• Gotowość do produkcji: 2 lata w eksploatacji na platformie danych.
• Open-source: Apache 2.0, GitHub dla issues/PR.

— Editorial Team