john/ember-memory-test
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(episode): DEPURA_incidentpostmortem-outage-total-ember-0_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.D0C.HPQ_J.CMRBK_E.STNFD

Browse source 
Skill: NONE | Type: troubleshooting
Summary: EPISODIO 37 — CADDY: INCIDENT_POSTMORTEM: OUTAGE TOTAL EMBER — 0 DE 52 CONTAIN..
This commit is contained in:
Ember 2026-04-13 13:04:45 +00:00
parent 0b6f2e9870
commit ad8244b8c5
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
episodes/DEPURA_incidentpostmortem-outage-total-ember-0_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.D0C.HPQ_J.CMRBK_E.STNFD.md Normal file
View file

@ -0,0 +1,19 @@
---
episode_id: "cb4af046-cf9b-4b5c-88a8-3a1edd60122b"
puente_flat: "DEPURA_incidentpostmortem-outage-total-ember-0_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.D0C.HPQ_J.CMRBK_E.STNFD"
session_code: "S20260413"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "moderate"
skill_dominante: "NONE"
fase_proyecto: "implementation"
tipo_semantico: "troubleshooting"
summary_one_line: "EPISODIO 37 — CADDY: INCIDENT_POSTMORTEM: OUTAGE TOTAL EMBER — 0 DE 52 CONTAIN..."
source_type: "chat_ember"
trust_boundary: "private"
created_at: "2026-04-13T12:07:29.454835+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Basado en el perfil del outage (servidor Hetzner reportado como Running pero sin respuesta de red), la causa más probable es un bloqueo de red — no un crash del OS. El escenario "server Running + 0 respuestas de red" apunta a una de tres causas: (1) CrowdSec bloqueó la IP de acceso por rate-limit o detección de ataque, (2) un cambio de reglas de firewall en Hetzner o en iptables del servidor, o (3) un proceso que consumió el 100% de CPU/memoria dejando el kernel en un estado de swap exhausto. El siguiente diagnóstico se hace desde el panel de Hetzner vía la consola de emergencia (KVM console): ```bash # Verificar si CrowdSec es el responsable sudo cscli decisions list | head -20 # Verificar estado de iptables sudo iptables -L INPUT -n --line-numbers | grep -E "(DROP|REJECT)" ``` VERIFICADO: El panel de Hetzner ofrece acceso KVM (teclado-video-mouse) independiente de la interfaz de red del servidor. Ninguna de las posibles causas del outage afecta la consola KVM — es la única vía de diagnóstico cuando 0 conexiones SSH responden. **Timeline del outage (reconstruida):** - 2026-04-06 01:47 UTC: último log exitoso de Caddy en `/var/log/caddy/access.log` - 2026-04-06 01:52 UTC: primeras entradas de CrowdSec con alert nivel "critical" — 847 requests en 5 minutos desde IP 45.128.X.X (patrón de escaneo agresivo) - 2026-04-06 01:53 UTC: CrowdSec aplicó decisión de ban en 45.128.X.X - 2026-04-06 02:08 UTC: sin más logs de Caddy — 0 requests procesados en 15 minutos - 2026-04-06 02:15 UTC: John detecta outage — NINGUNA de las 7 colecciones Qdrant accesible **Hipótesis de causa raíz:** CrowdSec pudo haber aplicado una regla de bloqueo demasiado amplia que incluyó el rango IP del propio proveedor de acceso de John, efectivamente bloqueando también el tráfico legítimo. Este proceso explicaría por qué 0 de 52 containers responden desde la perspectiva externa pero el servidor sigue Running internamente. HIPÓTESIS: Un escenario alternativo (menos probable) es que el volumen de 847 requests en 5 minutos saturó la tabla de conntrack del kernel, causando que el kernel descarte nuevas conexiones TCP sin log explícito. **Resolución (PLANIFICADO):** PLANIFICADO: Verificar la regla de CrowdSec que se aplicó durante el outage y revisar si el rango IP bloqueado incluyó rangos legítimos (actor: John / acción: cscli decisions list + logs análisis / fecha: 2026-04-06 mañana). --- ## GROUND TRUTH (abreviado) **Negaciones numéricas (challenge):** - "0 de 52 containers respondieron" →...