El servidor cayó – hora del postmortem

Antes de la muerte súbita, uno puede plantearse muchas cosas. A toro pasado, poco más que hacer un análisis forense…

Si tienes programadas alertas para posibles fallos, tu nagios (o equivalente) te habrá avisado con antelación para prevenir la catástrofe. Si además tienes montado algo más o menos altamente disponible, el impacto no suele ser tan grave (incluso aunque se caiga el servidor)

No obstante, en este artículo nos centraremos en la pregunta que se suelen hacer los usuarios en estos casos: “¿y por qué se ha caido?”. El administrador suele preguntarse algo más práctico: “¿cómo evitar que se repita?” (en ese servidor, y en el resto, por si acaso).

Si la consola permanece visible, los mensajes que aparecen pueden ser un buen punto de partida para el análisis forense.

Por defecto, los logs que suelen estar disponibles son kernel.log y auth.log. En ellos puede encontrarse alguna pista.

Si tienes instalado atop y/o snoopy, tendrás algo más de información.

Con kdump se puede obtener un volcado del núcleo de Linux. Para ello hace falta que el kernel en uso esté preparado (“After successfully loading the dump-capture kernel as previously described, the system will reboot into the dump-capture kernel if a system crash is triggered”)

La preparación de kdump no es trivial. En Debian, el paquete kdump-tools ayuda con el proceso. Con netdump, se puede hacer el volcado en otro ordenador (via ssh)

No se puede descartar la posibilidad de que el fallo se deba al hardware (la memoria, la placa base y todo lo que integra…), a un calentamiento (que sería delatado por los registros de temperatura), fallos en servicios privilegiados (o en controladores)…

Las tarjetas gráficas y las X pueden ser también causa de conflicto, pero normalmente en los servidores no se instalan.

Más información:

Determining the cause of a kernel panic

Common kernel problems (Fedora)

Tutorial sobre analisis de volcados de kernel, por Eugene Teo

Tutorial sobre LKCD, por Norman Patten (¿el primer tutorial oficial sobre la materia?)

Configure netdump (IBM)

“DevOps Troubleshooting: Linux Server Best Practices”, de Kyle Rankin.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *