Prometheus y Alertmanager · Metricas + Alertas

El corazon del observability stack. Prometheus recolecta metricas de cada componente y evalua reglas de alerta. Alertmanager recibe las alertas disparadas y las enruta a n8n para su procesamiento automatico con LLM.

Scrape Jobs

Prometheus recolecta metricas de 7 endpoints via HTTP. Cada 15 segundos, consulta /metrics en cada target y almacena las series temporales en su TSDB con 15 dias de retencion.

prometheuslocalhost:9090

Auto-monitoreo de Prometheus. Metricas sobre el propio proceso de recoleccion.

node-exporternode-exporter:9100

Metricas del sistema operativo: CPU, memoria, disco, red. Corre como DaemonSet.

kube-state-metricskube-state-metrics:8080

Metricas de objetos de Kubernetes: estado de pods, deployments, nodos. No metricas de uso, sino de estado.

n8nn8n:5678

Metricas de n8n: ejecuciones, workflows activos, uso de memoria.

alertmanageralertmanager:9093

Metricas de Alertmanager: alertas activas, silenciadas, tasa de notificaciones.

jenkinsjenkins:8080

Metricas de Jenkins: builds, jobs, agentes activos.

grafanagrafana:3000

Metricas de Grafana: usuarios activos, dashboards, uso de memoria.

Storage: Prometheus usa un PVC de 5Gi. Con 7 scrape jobs a 15s y 15 dias de retencion, el uso estimado es de ~2-3Gi — suficiente para el lab.

Reglas de Alerta

Siete reglas cubren los escenarios de fallo mas comunes. Cada regla tiene un severity (critical/warning) que Alertmanager usa para decidir la ruta.

PodCrashLoopingcriticalfor: 5m

kube_pod_container_status_waiting_reason == 'CrashLoopBackOff'

Un pod esta en CrashLoopBackOff. El contenedor arranca y muere repetidamente.

HighMemoryUsagewarningfor: 5m

node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 15

Menos del 15% de memoria disponible en el nodo. Riesgo de OOM kill.

DiskSpaceLowwarningfor: 5m

node_filesystem_avail_bytes / node_filesystem_size_bytes * 100 < 20

Menos del 20% de disco disponible. Loki y Prometheus consumen storage.

N8nDowncriticalfor: 2m

up{job='n8n'} == 0

n8n no responde. Los workflows de respuesta a incidentes no funcionan.

GrafanaSLOBreachwarningfor: 5m

avg_over_time(up{job='grafana'}[30d]) * 100 < 99.9

Disponibilidad de Grafana por debajo del SLO de 99.9%.

HighCPUwarningfor: 10m

100 - (avg(rate(node_cpu_seconds_total{mode='idle'}[5m])) * 100) > 80

CPU del nodo por encima del 80% durante 10 minutos.

ServiceDowncriticalfor: 2m

up == 0

Un servicio esta caido. La label job identifica cual.

De estas 7 reglas, 2 disparan el loop de respuesta a incidentes (PodCrashLooping y ServiceDown), 4 monitorean la salud del sistema (HighCPU, HighMemoryUsage, DiskSpaceLow, N8nDown), y 1 monitorea el SLO de Grafana.

Alertmanager: Enrutamiento a n8n

Alertmanager recibe las alertas de Prometheus y las enruta segun severity. Todas las alertas —criticas y warnings— terminan en el mismo webhook de n8n. La diferencia esta en la agrupacion.

severity: criticalgroup_wait: 10s

Agrupar en lotes de 10s. Si una alerta critica se dispara, todas las que lleguen en los proximos 10s se agrupan en una sola notificacion.

severity: warninggroup_wait: 30s

Agrupar en lotes de 30s. Las alertas de warning no requieren respuesta inmediata.

defaultgroup_wait: 30s

Agrupar en lotes de 30s y enviar a n8n via webhook. Incluye send_resolved para notificar cuando la alerta se resuelve.

receivers:
  - name: n8n-webhook
    webhook_configs:
      - url: http://n8n.aiops.svc.cluster.local:5678/webhook/alertmanager
        send_resolved: true

route:
  receiver: n8n-webhook
  routes:
    - match:
        severity: critical
      group_wait: 10s
      receiver: n8n-webhook

send_resolved: true es clave: cuando una alerta se resuelve, Alertmanager envia una segunda notificacion a n8n con status 'resolved'. El workflow de n8n puede usar esto para cerrar incidentes o notificar que el sistema se recupero.

Siguiente: Loki y Grafana Alloy

Las metricas cubren el QUE. Los logs cubren el POR QUE. Loki almacena los logs del cluster y Alloy los recolecta de cada pod.

Loki + Alloy