Alertmanager-jira: integración de alertas con Jira

# Integración de Alertmanager con Jira: Plugin de webhook flexible en Quarkus

Alertmanager-jira es un plugin de webhook de código abierto para Alertmanager (Prometheus, VictoriaMetrics) que crea y gestiona incidencias en Jira. Soporta la asignación de responsables, campos personalizados, plantillas de descripción y detección de duplicados mediante JQL. Construido sobre Quarkus, se despliega mediante Docker/Podman. Esta herramienta resuelve las limitaciones de alternativas como jiralert, ofreciendo control total sobre los tickets sin necesidad de scripts personalizados.

Problemas con las soluciones existentes

Jiralert del prometheus-community crea incidencias basadas en group_key, utiliza plantillas Go y soporta resolución automática. Sin embargo, en la práctica, presenta estas limitaciones:

• Configuración mínima: plantillas YAML básicas, sin soporte para campos personalizados o consultas JQL dinámicas.
• Los hashes largos de group_key rompen la interfaz de usuario de Jira.
• Desarrollo lento: errores abiertos desde 2018, actualizaciones poco frecuentes.

Otras opciones incluyen soluciones empresariales como PagerDuty o scripts personalizados. Alertmanager-jira ofrece flexibilidad: valores predeterminados para proyectos/tipos de incidencia, sobrescrituras en las alertas y comentarios en tickets existentes.

Despliegue en un contenedor

El proyecto incluye imágenes Docker en hub.docker.com. Ejemplo de lanzamiento con Podman (similar a 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

Configuración de Alertmanager

Añade un receptor en alertmanager.yml:

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

Configuración de alertas en Prometheus/VictoriaMetrics

Los campos de Jira se configuran usando el prefijo jira__ en etiquetas/anotaciones de las reglas. Se admiten plantillas Groovy SimpleTemplate.

Ejemplo de 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}'

Valores predeterminados en prometheus.yml mediante 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

Las sobrescrituras en alertas específicas tienen prioridad. Plantillas:

• ${context.alert.fingerprint} — hash de la alerta.
• ${context.jiraProject.name} — metadatos del proyecto.
• JQL para búsquedas: labels = "alert[${context.alert.hashCode()}]") AND statusCategory != Done.

Implementación técnica

Construido con Java + Groovy (Quarkus), Atlassian Jira SDK. Pruebas: pruebas unitarias para el análisis, pruebas de integración en una instancia Jira externa. CI no ejecuta pruebas debido a restricciones de licencia de Jira; requiere ejecuciones manuales en un servidor desplegado.

Mejoras posibles: integrar pruebas en CI utilizando licencias temporales o servidores simulados.

Características clave

• Flexibilidad de campos: cualquier campo personalizado, etiquetas, componentes mediante el prefijo jira__ y plantillas.
• Desduplicación: búsqueda JQL de incidencias existentes con opción de comentario.
• Automatización: reduce el MTTR en DevOps/SRE/ITSM mediante tickets automáticos.
• Listo para producción: 2 años en producción en una plataforma de datos.
• Código abierto: Apache 2.0, GitHub para issues/PRs.

— Editorial Team