[Jderobot-admin] Zabbix

[Borja Mon Serrano]

Buenos días,

Al desinstalar el paquete zabbix-server-mysql creo que ni se borra el
> usuario zabbix de base de datos, ni sus permisos ni la base de datos. La
> verdad es que no lo he hecho nunca, ¿has comprobado que siguieran ahí?
> Podría estar dando problemas si ahora hay varios usuarios con el mismo
> nombre pero diferentes contraseñas o, peor aún, no se limpió la base de
> datos.
>

No he comprobado que la base de datos siguiera ahí, pero entiendo que purge
se encarga de eliminar todo lo relativo al programa que desinstalas (por
eso ni miré la base de datos).


> Un "DROP DATABASE zabbix;" debería arreglar el problema de mantener
> datos (una vez hecho el dpkg -P zabbix-server-mysql o el apt-get remove
> --purge zabbix-server-mysql).
>

En relación a lo anterior, he desinstalado zabbix-server-mysql y
zabbix-frontend-php, eliminando también el directorio /etc/zabbix y
cerciorándome de que ya no existía la base de datos zabbix (efectivamente,
purge la elimina) y al reinstalar ambos paquetes parece que ya funciona
bien :D Se puede acceder al recurso /zabbix sin problemas y se puede entrar
a la interfaz con el usuario y contraseña por defecto, de momento no lo he
cambiado. Lo que tendría que hacer ahora es instalar y configurar un agente
que se conectase a este servidor, ¿verdad? También me tengo que hacer a la
interfaz de zabbix y ver qué es lo que puedo empezar a hacer con él.


> Eso siempre lo dice cuando no puede conectarse a la base de datos (por
> estar caída, por no tener permisos, etc).
>

Sí, sí, si es algo lógico... Era simplemente por dar más información.

Precisamente hubiera sido un momento genial para iotop más que para top.
>

Lo tendré en cuenta en el futuro.


>  > 19072 www-data  20   0 96180  51m 3932 R   93  2.5   1:43.34 apache2
> > 19002 www-data  20   0 96272  50m 3728 R   88  2.5   1:25.10 apache2
> > 18028 www-data  20   0 66824  14m 3324 S    4  0.7   0:12.11 apache2
>
>
> Quizá el parámetro para regenerar los hijos de apache2 esté mal
> configurado ya que no debería tener tanto tiempo de ejecución sin
> regenerarse (marca 1 hora y 45 minutos uno de ellos). Nosotros tenemos
> configuradas 50 conexiones por hijo antes de que éste se regenere.
>

No soy muy amigo de top (poco a poco nos vamos conociendo), pero entiendo
que la información de cuánto tiempo lleva corriendo un proceso en la
máquina te lo da en minutos y no en horas, es decir, que ese 1:43.34 quiere
decir que lleva corriendo 1 minuto, 43 segundos y 34 centésimas. Creo que
es así porque alguna vez he visto que lo que va después del punto ha pasado
de 60, por lo que no podrían ser segundos (no tendría sentido) y, además,
en cuanto he reinstalado zabbix he visto que había un proceso zabbix_server
que llevaba corriendo 00:01.57...

Es lo normal de un servidor web en carga:
> top - 12:31:58 up 7 days,  5:26,  2 users,  load average: 0.73, 0.64, 0.52
> Tasks: 228 total,   2 running, 226 sleeping,   0 stopped,   0 zombie
> Cpu0  : 43.0%us,  5.6%sy,  0.0%ni, 49.3%id,  0.0%wa,  0.3%hi,  1.7%si,
> 0.0%st
> Cpu1  : 11.8%us,  5.2%sy,  0.0%ni, 83.0%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu2  :  6.9%us,  4.9%sy,  0.0%ni, 88.2%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu3  : 12.5%us,  3.6%sy,  0.0%ni, 83.9%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu4  :  3.7%us,  4.7%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu5  :  3.6%us,  4.0%sy,  0.0%ni, 92.4%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu6  :  2.3%us,  4.0%sy,  0.0%ni, 93.7%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Cpu7  :  1.7%us,  4.2%sy,  0.0%ni, 94.1%id,  0.0%wa,  0.0%hi,  0.0%si,
> 0.0%st
> Mem:   2060264k total,  1703880k used,   356384k free,    84288k buffers
> Swap:   499704k total,        0k used,   499704k free,  1157184k cached
>
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13903 www-data  20   0  225m  35m  12m S   20  1.8   0:01.32 apache2
> 13016 www-data  20   0  225m  34m  11m S   13  1.7   0:01.39 apache2
> 13238 www-data  20   0  219m  28m  12m S   11  1.4   0:01.22 apache2
> 15795 www-data  20   0  213m  20m 9.8m S    9  1.0   0:00.26 apache2
>   9421 www-data  20   0  219m  29m  13m S    8  1.5   0:03.10 apache2
>   9007 www-data  20   0  217m  28m  13m S    8  1.4   0:02.79 apache2
> 15794 www-data  20   0  216m  24m  10m S    7  1.2   0:00.31 apache2
>   9422 www-data  20   0  225m  36m  13m S    6  1.8   0:03.34 apache2
>   9004 www-data  20   0  217m  27m  13m R    4  1.4   0:02.35 apache2
>   8693 www-data  20   0  219m  28m  12m S    1  1.4   0:01.98 apache2
>
> Aunque el ejemplo no vale mucho debido a que el servidor está tras un
> acelerador web (un squid que balancea la carga entre varios servidores
> web) y que esta máquina tiene 8 núcleos "Intel(R) Xeon(R) CPU
> E7450  @ 2.40GHz" (sacado del /proc/cpuinfo), pero es normal que ante
> ciertas páginas se queden durante un par de segundos usando el 99% de
> cpu uno o varios procesos apache2 (he estado esperando un par de minutos
> a ver si pillaba alguno así y no ha habido suerte, pero ha habido
> ocasiones en los que he visto eso).
>
> Quizá deberíais probar a cambiar:
> MaxRequestsPerChild   50


> Lo único que hace es que los procesos "hijos" de apache2 que realmente
> sirven las peticiones "mueran" tras atender 50 peticiones, liberando
> memoria (para evitar agujeros o zonas muertas de memoria, etc) y
> posteriormente (si se necesita y está dentro del rango de procesos
> configurado) levantará un proceso fresco. De este modo será difícil que
> un proceso apache2 siga vivo con una hora y tres cuartos de tiempo de
> ejecución.
>

Estaba puesto a 0, ya está cambiado (y reiniciado el servidor). ¿Por qué 50
exactamente? Supongo que este número habría que cambiarlo dependiendo de la
carga que tuviera el servidor, ¿no?

El iotop, ha fallado el iotop aquí para descartar velocidad de acceso a
> disco (si los datos están en disco local).
>

Como ya he dicho antes, lo tendré en cuenta en futuras ocasiones.


> Por cierto, provecho para preguntar, ¿es un sistema de archivos local o
> es nfs?
>

Es un sistema de archivos local, todo está en una misma máquina. De hecho,
a principios de octubre se le instaló otro disco duro para albergar todo el
svn.

También te ha faltado un "uptime" para saber si el servidor ha sido
> reiniciado o no... por la poca memoria "cached" y la cantidad de memoria
> libre tiene toda la pinta de que llevaba poco tiempo levantado (vamos,
> que había sido reiniciado hacía poco, aunque fuera la madrugada anterior).
>
> Posiblemente saltó watchdog para salvar la situación desde el error de
> anoche. Si watchdog salta tras una congelación debida a paginación
> excesiva es normal que no deje rastro en el syslog (si watchdog falla
> con el reboot "suave" tira de un reset brusco).
>

Pero aunque tire de un reset brusco, ¿no escribe nada en el syslog?


> ¡Eso sí es un síntoma de paginación excesiva! Ese es el típico mensaje
> que sale cuando la máquina pagina con tantísima frecuencia que si una
> operación de entrada/salida se retrasa más de 120 segundos aparece un
> mensaje en el log advirtiendo sobre eso... y poco a poco lo hace con más
> frecuencia.
>
> Si en ese momento hiciéramos un top veríamos una carga de CPU muy
> elevada (por encima de 15), y un tiempo iowait también elevado (por
> encima del 75%) y un uso de swap elevado.
>
> Un consejo: un servidor debería tener menos del 50% de swap que de
> memoria RAM, así el equipo no perdería rendimiento por uso de memoria,
> si no que se dedicaría a matar procesos que considere que puedan ser
> eliminados.
>
> Yo prefiero una caída suave de los servicios que una caída completa del
> servidor.
>

Ahora mismo el servidor tiene aproximadamente un 75% de swap (en relación a
la RAM).

Es lo malo de los reinicios "bruscos", pero nada que no se pueda reparar
> con un "REPAIR TABLE ...". Los índices siempre se pueden reconstruir a
> partir de los datos (tenemos suerte en ese aspecto), si llega a ser un
> archivo de datos entonces recuperar a partir del log de transacciones es
> más complejo, no es tan fiable (nunca sabes si los datos que te faltan
> están recogidos en el reducido tamaño de log que tiene mysql) y encima
> no está soportado en bases de datos myisam, sólo en innodb (es como la
> diferencia entre ext2 y ext3).
>

El REPAIR TABLE fue una de las primeras cosas que hice ayer. Además de
hacer la reparación de esa tabla hice un chequeo con auto-reparación de
todas las bases de datos con "mysqlcheck --all-databases --auto-repair" y
todo pareció funcionar bien.

He hecho una búsqueda rápida en los bugs de debian y he encontrado esto:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535148#65
>
> ¿Podrías comprobar si somos víctimas de ese bug? En caso afirmativo,
> ¿podrías desinstalar el paquete php5-suhosin?
>
> Es un bug extremadamente viejo, pero sin poder ver las versiones
> instaladas no sé si estamos bajo su influjo. Por lo pronto desactivar o
> desinstalar ese paquete podría arrojar luz sobre el problema aunque
> también podría estar derivado de peticiones al servidor MySQL que han
> sido canceladas, postpuestas, etc por latencias altas de acceso a disco
> y que PHP no haya sabido cómo tratar ese evento.
>

Está instalada la última versión disponible, la 0.9.32.1-1, que es de 2010
según el changelog. En él no he visto referencia a que se arregle este
error, pero como tampoco sabemos por qué ha sido provocado lo mismo sí que
aparece como arreglado en alguna de las líneas del changelog.


> Podría tratarse de corrupción del sistema de archivos, ¿has hecho un
> fsck o lo has forzado para el próximo reinicio? No es normal que un
> archivo se quede "colgado" accediendo a él o que un registro de una
> tabla de la base de datos se quede "congelada" de esa manera, pero sí me
> ha pasado que tras periodos muy largos de paginación de una máquina en
> repetidas ocasiones, el calor que genera la actividad ha terminado por
> dañar los discos duros físicos de la máquina y han empezado a
> comportarse de manera extraña a partir de entonces.
>

No he hecho un fsck, pero lo dejaré ahora programado para el próximo
reinicio.


>
> Prueba antes de nada un RECOVER TABLE de todas las tablas. Como no la
> base de datos de la wiki no es muy grande no tardará mucho.
>
> Para asegurarte _haz antes_ un backup _completo_ con mysqldump (-p --opt
> --all-databases, etc) por si las moscas. Nunca se sabe, no me ha pasado
> nunca que se corrompan las bases de datos, pero siempre hay un primer
> día para que ocurra algo. Vuelca a local y, si puedes, a un USB o equipo
> externo en dos ejecuciones diferentes (no copies un archivo previamente
> generado), así evitamos propagar cualquier problema de disco.
>
> Si quieres, por velocidad, excluye del backup la base de datos zabbix (y
> si hacéis backups lógicos diarios más vale excluirla de ellos a no ser
> que sean backups binarios).
>

Lo haré ahora mismo, aunque de todas formas la base de datos zabbix ahora
mismo debe de ser bastante pequeña.

Después de todo esto, si sigue la congelación del equipo habrá que mirar
> dmesg por si hay errores de entrada/salida del tipo:
>
> [332888.147751] ata1.00: failed command: WRITE FPDMA QUEUED
> [332888.150324] ata1.00: cmd 61/08:50:48:9c:1e/00:00:06:00:00/40 tag 10
> ncq 4096 out
> [332888.150327]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x44 (timeout)
> [332888.155453] ata1.00: status: { DRDY }
> [332888.158000] ata1: hard resetting link
> [332888.500039] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [332888.566365] ata1.00: configured for UDMA/133
> [332888.566373] ata1.00: device reported invalid CHS sector 0
> [332888.566406] ata1.00: device reported invalid CHS sector 0
> [332888.566427] ata1: EH complete
> [333184.165140] ata1.00: exception Emask 0x50 SAct 0x1 SErr 0x280900
> action 0x6 frozen
> [333184.167747] ata1.00: irq_stat 0x08000000, interface fatal error
> [333184.170354] ata1: SError: { UnrecovData HostInt 10B8B BadCRC }
> [333184.172942] ata1.00: failed command: READ FPDMA QUEUED
> [333184.175506] ata1.00: cmd 60/a8:00:e0:00:b9/00:00:03:00:00/40 tag 0
> ncq 86016 in
> [333184.175508]          res 40/00:00:e0:00:b9/00:00:03:00:00/40 Emask
> 0x50 (ATA bus error)
> [333184.180671] ata1.00: status: { DRDY }
> [333184.183242] ata1: hard resetting link
> [333184.530054] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>
> Ve probando y vamos a ver si terminamos de poner a punto todo para que
> vuelva todo a la normalidad.
>

Eso espero :)

Un saludo,

Borja.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jderobot-admin/attachments/20121122/23c563e9/attachment-0001.htm