Fase 5.3
Demo Grabada

Incident Simulation · La Demo

El momento mas importante del proyecto: forzar un crash de pod y ver el loop completo funcionando en tiempo real. Prometheus detecta, Alertmanager notifica, n8n procesa con LLM y Discord recibe el analisis. Esta secuencia grabada es lo que va en el README.

01

El Guion — Paso a Paso

Siete pasos desde que se fuerza el crash hasta que Discord recibe el analisis del LLM. El tiempo total es de aproximadamente 2 minutos y 20 segundos.

1
Forzar crash de un pod
Elimina un pod forzosamente. Kubernetes intenta recrearlo, pero durante unos segundos el servicio esta caido. Prometheus detecta que el target /metrics de Grafana no responde.
kubectl delete pod grafana-7d4f5b6d8-xk2p -n aiops --force --grace-period=0
2
Prometheus dispara la alerta ~2 min
La regla ServiceDown (up == 0) se activa despues de 2 minutos con el target caido. Prometheus evalua las reglas cada 15 segundos — la alerta pasa a estado 'firing'.
3
Alertmanager enruta a n8n +10s
Alertmanager recibe la alerta de Prometheus, la agrupa con otras alertas del mismo severity (10s group_wait) y envia un webhook POST a n8n con el payload JSON de la alerta.
4
n8n extrae el contexto +2s
El nodo Webhook recibe el POST. El nodo Set extrae: alertname=ServiceDown, severity=critical, job=grafana, description. Prepara las variables para el prompt del LLM.
5
LLM analiza la alerta +5s
El nodo HTTP Request envia el prompt a OpenCode Go API. El LLM responde con: causa probable (pod eliminado, crash, OOM), impacto (Grafana no disponible), comandos sugeridos (kubectl describe pod, kubectl logs), y acciones preventivas (aumentar replicas, HPA).
6
Discord recibe el analisis +1s
El nodo HTTP Request envia un embed a Discord con: titulo (nombre de la alerta + severity), descripcion (analisis del LLM en Markdown), color (rojo para firing), timestamp y campos adicionales.
7
Grafana muestra el timeline visible
El dashboard de Grafana muestra el spike de alertas en el panel de Service Status, el gap en las metricas del pod eliminado (2-3s hasta que k3s lo recrea), y el log del evento en el panel de Loki.
02

El Comando

Un solo comando dispara toda la secuencia. El flag --force --grace-period=0 hace que el pod se elimine inmediatamente sin waiting period.

incident simulation
# 1. Forzar el crash del pod de Grafana
$kubectl delete pod -l app=grafana -n aiops --force --grace-period=0
pod "grafana-7d4f5b6d8-xk2p" force deleted
# 2. Monitorear los pods mientras k3s recrea el eliminado
$kubectl get pods -n aiops -w
grafana-7d4f5b6d8-xk2p Terminating 0 5m
grafana-7d4f5b6d8-9mz3 ContainerCreating 0 1s
grafana-7d4f5b6d8-9mz3 Running 0 3s
# 3. Esperar ~2 min. Discord recibe el mensaje del LLM.
03

Estructura del Video

El video de la demo tiene una duracion objetivo de 4 minutos. Cada segmento muestra una parte del stack en accion.

00:00-00:30
Intro: arquitectura del stack en pantalla. Mencion de los componentes: Prometheus, Alertmanager, n8n, OpenCode Go, Discord, Grafana.
00:30-01:00
Terminal: kubectl delete pod --force. Mostrar el pod siendo eliminado y el nuevo pod en estado ContainerCreating.
01:00-01:30
Discord: el mensaje del LLM aparece en tiempo real. Leer el analisis en voz alta — causa probable, comandos sugeridos, prioridad.
01:30-02:00
Grafana: mostrar el dashboard con el spike de alertas. Panel de Service Status con Grafana en rojo. Timeline de Loki con el evento.
02:00-03:00
n8n UI: mostrar la ejecucion del workflow. Resaltar cada nodo mientras se explica su funcion. Mostrar el payload de entrada y el output del LLM.
03:00-03:30
Cuando la alerta se resuelve: mostrar el mensaje de Discord con status 'resolved' en verde. Cierre del incidente documentado.
03:30-04:00
Outro: recapitulacion del loop completo. Mencion de que esto corre en k3s sobre Rocky Linux con SELinux enforcing.
Consejo para el video: grabar la pantalla completa con OBS. Tener 4 ventanas abiertas: terminal, Discord, Grafana y n8n UI. Cambiar entre ellas en cada segmento. Voz en off explicando lo que se ve. Sin musica — solo la voz y los comandos.
04

Lo Que se Demuestra

La simulacion de incidente demuestra mas que skills tecnicos. Demuestra un sistema integrado donde multiples componentes trabajan juntos sin intervencion humana.

1
Automatizacion real, no un script que imprime logs. El loop usa protocolos estandar (webhooks, HTTP, PromQL) entre componentes heterogeneos.
2
Integracion con IA. No es un chatbot — es un LLM analizando datos operativos reales y generando recomendaciones accionables.
3
Observabilidad completa: metricas (Prometheus), logs (Loki), dashboards (Grafana) y alertas (Alertmanager) trabajando en conjunto.
4
Todo self-hosted en k3s sobre Rocky Linux. Nada de servicios cloud administrados — cada pieza se configuro desde cero.

Fase 5 Completada

Los workflows de n8n con LLM estan funcionando. La Fase 6 introduce Jenkins self-hosted en k3s con agentes dinamicos y pipeline CI/CD.

Fase 6