La caída nunca fue lo que estaba depurando
Una caída total del homelab a la 01:45. Primero culpé al reverse proxy, luego al IPS y después a la capa de SSO. La causa raíz fue un puerto de red caído en el switch; todo lo que sospeché era solo un síntoma.
Alrededor de la 01:45 el homelab se cayó — no fue solo un servicio, fueron todos. Este es el postmortem, incluyendo la parte donde mi primer intento de arreglo no funcionó y la razón por la que no lo hizo.
Lo que sospeché, en orden
Traefik. Todo pasa por ahí, así que que todo falle parece que el router falló. Estaba saludable.
CrowdSec. Un IPS al que recientemente le había puesto reglas más agresivas. Un baneo masivo se vería exactamente así. No había baneado nada relevante.
Authentik. Forward-auth está frente a la mayoría de los servicios internos, así que una caída de SSO también produce indisponibilidad total. También estaba saludable.
Tres causas plausibles, cada una de las cuales podría producir el síntoma observado, y las tres inocentes. Esa es la señal de que estás viendo la capa equivocada.
El workaround fallido
La resolución de nombres claramente estaba involucrada, así que intenté fijar DNS a un resolver conocido y funcional en vez de la IP virtual flotante. No funcionó.
La razón vale la pena documentarla: ejecuté el redirect sin root, así que el symlink del stub de systemd se mantuvo intacto y mi cambio fue silenciosamente un no-op. No marcó ningún error. El sistema simplemente siguió usando la ruta anterior. Pasé un buen rato re-verificando un arreglo que nunca se aplicó.
Segundo intento, ahora como root, fijó la resolución a la dirección real del host DNS primario y evitó por completo el VIP de keepalived. Eso restauró el servicio.
La causa raíz real
Un puerto de red se cayó a nivel de switch. No fue DNS, ni Traefik, ni CrowdSec, ni Authentik. El síntoma de DNS fue el más ruidoso porque la resolución de nombres falla rápido y todo lo demás falla detrás de eso.
Más tarde ese día confirmé que el VIP y el host DNS primario compartían la misma MAC, lo que probó que keepalived seguía siendo dueño de la dirección correctamente — la capa de HA había estado haciendo su trabajo todo el tiempo. No podía enrutar alrededor de un enlace físico muerto, que no es para lo que está hecho.
El seguimiento que dolió
Uno de los pendientes que me dejé fue: ¿el monitoreo alertó sobre esto en algún momento? Si no, agrega un check.
Tengo un dashboard, un monitor de uptime, un stack de métricas, un agregador de logs y un servicio de notificaciones push. Me enteré de una caída total intentando usar algo. Cubrir servicios no es cubrir la capa debajo de ellos.
Lo que me llevo de esto
- Lo que sospechas primero usualmente está aguas abajo de lo que realmente se rompió. Tres sospechosos saludables seguidos es información: deja de investigar y empieza a bajar de capa.
- Verifica que tu arreglo se haya aplicado antes de evaluar si funcionó. Un no-op silencioso cuesta más que un fallo ruidoso.
- El postmortem mantiene el intento fallido. Limpiar eso haría un documento más ordenado y uno menos útil.
Escrito por
Adrian Romo
Ingeniero Backend Senior que diseña APIs escalables en Python, arquitecturas sobre AWS Lambda, sistemas de voz e integraciones empresariales.
Relacionado
Sigue leyendo
La alerta que nombró algo y lo presentó como evidencia
Cinco alertas de alta severidad de mi propio monitoreo. Las cinco fueron por el mismo defecto: un registro que nombra algo se leía como una observación de una propiedad que nunca midió.
Un ciclo de escritura que nunca fusiona nada
Mi homelab detectó problemas y no hizo nada al respecto. Cerrar el ciclo implicaba cuatro revisiones humanas y un ejecutor cuya característica principal es que se detiene en un PR en borrador.
Enseñando a un sistema a decir “No sé
Lo más útil que hace mi cerebro de homelab es negarse a responder. Con base o bloqueado: cada afirmación cita el hecho que la originó, o nunca llega a mí.
Continúa
¿A dónde sigues?
Explora más textos técnicos, revisa los casos de estudio o escríbeme directo.