¿Qué es lo primero que verifica cuando un servidor Unix intacto comienza a volverse loco?

Por lo tanto, tiene este servidor Unix perfectamente configurado y es súper rápido y funciona bien y todo es excelente durante meses, y de repente comienzan a aparecer todo tipo de errores extraños para una variedad de servicios diferentes y ninguno de ellos tiene mucho sentido por sí mismos , mucho menos juntos.

¿Cuáles son las cosas baratas que debe verificar tan pronto como reciba su sesión ssh en la máquina?

Estoy especialmente interesado en historias de trauma que resaltan comandos no obvios y situaciones raras, pero supongo que lo que es obvio varía de persona a persona, por lo que podemos enumerarlos todos libremente.

Primer orden: ¿es receptivo?

Si no puede iniciar sesión, hay mayores problemas en marcha. Esto generalmente viene en dos sabores: falla de hardware y falla de software. Ambos son potencialmente catastróficos. Para evitar errores de DFA, primero verifique el estado general del hardware; una simple revisión generalmente será suficiente.

Segundo orden: ¿Las estructuras subyacentes del sistema gozan de buena salud y orden?

Verifique la "Tríada Dorada" de los sistemas:

• Suficiente tiempo de CPU es gratis para procesar
• Suficiente espacio en disco es libre para almacenamiento
• Suficiente memoria es gratuita para cargas de trabajo.

En las últimas décadas, la tríada se ha expandido a un "quad" que incluye comunicaciones (redes):

• La conectividad es funcional, receptiva y tiene capacidad

Tercer orden: ¿Cuál es la gravedad del problema?

¿Qué programas o servicios se ven afectados? En orden decreciente de gravedad, ¿es sistémico (en todo el sistema), agrupado (un grupo de programas) o aislado (un programa específico)? Los grupos de programas generalmente se están disparando porque un servicio subyacente específico ha fallado o no ha respondido. Los problemas sistémicos a veces están relacionados con esto (piense en los conflictos de DNS o IP), pero saber dónde buscar suele ser la clave.

Cuarto orden: ¿Las herramientas de diagnóstico proporcionan datos útiles relevantes para el problema? Ahora que tiene información sobre el estado del sistema (segundo orden) y qué partes del mismo están experimentando problemas (tercer orden), esto debería facilitar la determinación de dónde está el problema.

Los mensajes de error o los archivos de registro deben ser un punto de referencia común en este viaje.

Problemas de CPU:

• loadav
• parte superior
• strace

Espacio en disco / problemas de E / S:

• df
• du
• lsof
• iostat
• vmstat

Problemas de memoria:

• gratis

Problemas de conectividad:

• silbido
• ruta (y arp y rarp y amigos)
• iptables, ipchains, ipfw (para esas personas de BSD)
• traceroute o mtr
• hosts, nslookup o dig
• netstat

Queja más común (que escucho):

El correo electrónico no se entrega lo suficientemente rápido (más de un minuto desde el envío hasta la recepción del destinatario) o el correo electrónico rechaza mi intento de envío. Esto generalmente se reduce al limitador de velocidad en Postfix que se activa durante una tormenta de spam, lo que afecta la capacidad de aceptar la entrega interna.

Un ejemplo de la vida real:

Sin embargo, este no es siempre el caso. Una vez, el problema persistió independientemente del reinicio del servicio; así que después de 3 minutos era hora de empezar a mirar alrededor La CPU estaba ocupada pero por debajo del 100%, sin embargo, la carga se había disparado a 15 en una caja de solo 2 núcleos y amenazaba con aumentar. El comando superior reveló que el sistema de correo estaba en sobremarcha, junto con el escáner de correo, pero que no se veían procesos secundarios de amavis. Esa fue la pista: el comando de cola de correo (mailq) mostró más de 150 mensajes no entregados, de los cuales más del 80% eran spam, en los últimos 20 minutos. Un ajuste rápido para reducir el limitador de velocidad (que redujo la velocidad de entrada de la tormenta de spam) al tiempo que aumentaba el número de procesos secundarios del escáner de correo electrónico (para ayudar a procesar el retraso), seguido de un reinicio del servicio, resolvió el problema y el sistema pudo para completar entregas en poco tiempo.

La causa del problema fue que el proceso padre de amavis se había desplomado y los procesos hijos eventualmente habían seguido su curso (se terminaban automáticamente después de tantos escaneos para evitar pérdidas de memoria). Así que había procesos SMTP en postfix que intentaban contactar ... de la nada ... para hacer el escaneo de spam / virus que era necesario. La distribución que estaba usando tenía paquetes desactualizados que nunca serían actualizados; Como la instalación debía ser reemplazada en aproximadamente un año, "anulé" manualmente la instalación a la última versión, que incluía varias correcciones de errores. No he tenido el mismo problema desde entonces.

generalmente "quién" seguido de "último"

Un montón de problemas en las máquinas que he manejado a lo largo del tiempo se deben a una definición muy flexible de "intacto", a menudo alguien ha hecho algo :)

Bueno, yo comenzaré.

Este me mordió una vez, pasé horas probando miles de cosas diferentes, deshabilitando los servicios aquí y allá, reiniciando, etc. ¿Cuál era el problema? Totalmente sin espacio en disco.

Entonces, esto es lo primero que escribo cuando depuro un servidor que de repente tiene problemas:

df -h

Nunca lo olvido ahora. Simplemente me ahorró mucho esfuerzo desperdiciado. Pensé en compartir.

arriba (o alto)

Si puede, siempre trataría de cerrar todas las NIC, salvo la de administración.

Verificando dmesg para ver si hay algún error: generalmente comienzo con un dmesg | tail, porque es probable que las cosas sigan yendo mal y el servidor todavía esté tratando de hacer lo que sea que esté causando el error.

Lo primero que compruebo es "superior" (¿hay algún proceso extraño; los que acaparan la memoria o el tiempo de CPU).

Si no aparece nada allí, comprobaré "quién" para ver si hay alguien más en mi máquina por alguna razón.

Quizás se desmontó un sistema de archivos; verifique con una llamada a 'cat / etc / mtab' y luego 'fstab' para asegurarse de que todo saldrá bien en el arranque.

Verifique el tiempo de actividad para asegurarse de que el número de usuarios en la caja sea razonable (solo debe ser usted) y luego hojee var / log / auth.log para ver si hay algún problema allí.

Estos son los principales. Dependiendo de los errores que arroje su caja, es posible que deba examinar procesos específicos que están causando el problema.

top df -h y SIEMPRE verifique / var / log para asegurarse de que la partición no se haya llenado. Eso me ha causado un derretimiento total algunas veces.

df -ha

para verificar si los discos duros están llenos y alguien no ha recibido advertencias

htop o top

para verificar el uso de memoria y CPU no es anormalmente alto.

Alternativamente, si el cuadro no responde, entro en el cliente vm-ware y compruebo cpu / ram desde allí.

Ejecutando algo como (at) sar en el host es casi obligatorio. No se puede subestimar la utilidad de poder obtener instantáneas históricas de CPU, red, memoria y E / S de disco (entre otros).

Muchas veces pude diagnosticar una falla al examinar lo que estaba haciendo el anfitrión en las últimas 24 horas y ver cuándo las cosas comenzaron a salir mal.

En Linux, generalmente reviso dmesg y / var / log / messages o / var / log / syslog. dmesg indicará si se trata de una falla repentina de hardware; Aparecerán muchos otros problemas en los registros del sistema.

Supongo que lo primero que hago es verificar el espacio en disco (como han mencionado otros). Si las comprobaciones simples no revelan un problema "común", investigaré más a fondo.

Una cosa que me gusta hacer es capturar una instantánea del sistema. Puedo buscarlos más tarde para buscar cualquier cosa que me haya llamado la atención.

lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &

A partir de ahí, se trata de la resolución de problemas 101, pero me parece un poco más rápido manipular los registros guardados y, si la condición se borra mientras estoy conectado, tengo algo para continuar o buscar cambios.