¿Cómo investigar el apagado inesperado del servidor Linux?

En un nuevo servidor Xeon 55XX con 4xSSD en la incursión 10 con Debian 6, he experimentado 2 apagados aleatorios dentro de las dos semanas posteriores a la construcción del servidor. Mirar los registros de ancho de banda antes de apagar no indica nada inusual. La carga del servidor suele ser muy baja (aproximadamente 1) y está colocada muy lejos. Parece que no hay apagón mientras el servidor se apaga.

Sé que miro / var / log pero no estoy seguro de qué registros debo investigar y qué debo buscar. Así que aprecio tus pistas.

Primero, debo preguntar: ¿"paradas"? ¿Quiere decir que la máquina se reinicia o se detiene realmente? Si se detiene, está mal configurado (tal vez en BIOS) o algo está apagando activamente la máquina (es decir, init 0).

De lo contrario, su candidato principal sería / var / log / syslog y /var/log/kern.log ya que su problema suena como un pánico del kernel o una falla de hardware activada por software. Por supuesto, si el servidor ejecuta algún servicio (por ejemplo, apache) también puede darle una pista.

A menudo, en situaciones como esta, se generan entradas de registro, pero debido a que la máquina tiene dificultades, no logrará escribir las entradas en el disco. Si la caja está colocada, es probable que el socio colo la conecte a una consola en serie. Ahí es donde buscaría si no encontrara nada sospechoso en los registros anteriores.

Si la máquina no está conectada a una consola serie y no hay nada en el registro, puede considerar enviar syslog a una caja diferente a través de la red. Quizás la interfaz de red sobrevive un poco más y los mensajes de registro se pueden leer en el servidor syslog. Eche un vistazo a rsyslog o syslog-ng.

ACTUALIZAR:

Estoy de acuerdo con @Johann a continuación. La causa más probable de detención es la vigilancia de la temperatura del procesador. Intente verificar / graficar la temperatura en la caja a través de lmsensors o smartctl (generalmente la más fácil). Encuentro que collectd no tiene paralelo en el seguimiento de una gran cantidad de variables a lo largo del tiempo. Puede hacer tanto IPMI como sensores lm y hddtemp. Además, algunos BIOS: es la temperatura de registro para detener eventos.

Primero, quieres comprobarlo /var/log/syslog. Si no está seguro de qué buscar, puede comenzar mediante la búsqueda de las palabras error, panicy warning.

grep -i error /var/log/syslog

Si tiene gráficos del sistema disponibles (por ejemplo, Munin). Revísalos y busca patrones anormales. Si no tiene instalado munin, podría ser una idea instalarlo ( apt-get install munin munin-node)

También debe consultar el correo raíz en busca de mensajes interesantes que puedan estar relacionados con el bloqueo del sistema.

Otros archivos de registro que debe verificar son los registros de errores de la aplicación. Por ejemplo /var/log/apache2/error.logo similar. Pueden contener información que lo lleve al problema.

En mi experiencia, un "alto inesperado" casi siempre es causado por el sobrecalentamiento. Verifique sus temperaturas y velocidades de ventilador a través de lm_sensors y asegúrese de que sean buenas.

Recientemente tuvimos el mismo patrón: un servidor se detuvo aproximadamente una hora después de que el soporte lo iniciara manualmente. Después de estas horas, la temperatura de la CPU alcanzó el umbral configurado en el BIOS (iirc 60 o 70 ° C) y detuvo el sistema. Todos estos problemas fueron causados ​​por un ventilador de CPU roto. Después de reemplazar el ventilador, todo volvió a la normalidad.

Hay varios archivos de registro en el directorio / var / log (y sus subdirectorios), incluidos

/var/log/boot

y

/var/log/boot.log

Comience con los archivos de arriba.

Hay 2 formas de verificar qué provocó el apagado, primero revise la consola de administración fuera de banda para cualquier problema en el hardware, sugeriría configurar SNMP y recibir correos electrónicos o agregar las trampas en un software de monitoreo para cualquier alerta.

Luego, a través del sistema operativo, puede verificar /var/log/messages(distribuciones basadas en RedHat) o /var/log/syslog(distribuciones basadas en Debian).

El subsistema de disco es lo suficientemente complicado como para verse afectado cuando se produce un problema, ya que casi no obtendrá nada en sus archivos de registro.

Intente iniciar sesión en la consola serie. Esto necesita un poco de cableado y otro sistema para recoger las líneas, pero tiene más posibilidades de detectar el problema.

Por supuesto, si su nodo tiene un sistema de gestión incorporado similar a ALOM / ILOM de Oracle, también puede verificar posibles problemas y registrar archivos allí.

Puede encontrar si el sistema sabe sobre el hecho de que estaba fallando con los siguientes comandos

sudo last -1x reboot
sudo last -1x shutdown

Si no hay información => entonces podría ser una pérdida de poder o algo más externo

si tiene información => busque en registros alrededor del tiempo de reinicio / apagado