[Jderobot-admin] Caída de zabbix_server este fin de semana

[Oscar Garcia]

El 04/12/2012 19:26, Borja Mon Serrano escribió:
> 1) Los logs generados por zabbix el sábado indican que la base de datos
> estaba caída mucho tiempo antes de que se terminase de caer la máquina.
> Aquí es la primera vez que aparece el síntoma:
>
>    1360:20121201:154253.366 [Z3001] Connection to database 'zabbix'
> failed: [1040] Too many connections
>    1360:20121201:154253.370 Watchdog: Database is down


Como dije en un mensaje anterior realmente no cayó el servicio MySQL, 
simplemente se llenó el pool de conexiones activas (100 por defecto) y 
eso hace que MySQL comience a rechazar nuevas conexiones.

En nuestro corpomysql tenemos en [mysqld] la siguiente línea:

max_connections        = 800

Pero hay que tener que son tres servidores mysql (percona para ser más 
exactos) en activo-activo, con lo que realmente el máximo número de 
conexiones serían (virtualmente) 2400. Teniendo la máquina que tenemos 
no creo que hubiera problema en subir el número de conexiones a un 
mínimo de 300.


> Casi dos horas antes de que se terminara la actividad en el servidor la
> base de datos ya estaba caída. ¿Hay alguna forma de que la máquina se
> reinicie en cuanto se sepa que la base de datos está caída? Con watchdog
> sé que se puede monitorizar el pid de cualquier proceso, incluida la
> base de datos, pero dijiste que esto no era buena práctica; ¿cómo se
> podría hacer esto?


A ver, la base de datos no estaba caída, simplemente el servidor 
rechazaba aceptar más conexiones a ella mientras las otras 100 
conexiones no terminaran su trabajo (cerraran su conexión). Con lo que 
el PID del MySQL seguía activo.

Con watchdog puedes monitorizar el PID, pero ya sabes que reiniciar el 
mysql o actualizarlo puede provocar el reinicio del servidor.

En zabbix ya viste que se pueden ejecutar scripts en la máquina cuando 
ocurre algún tipo de condición. Se podría crear un script para reiniciar 
el servidor MySQL, otro para reiniciar el servidor apache2, etc.


> Esos mensajes se vinieron repitiendo continuamente hasta la propia caída
> del servidor. Poco antes de morir soltó lo siguiente:
>
>    1401:20121201:172741.538 Executing housekeeper
>    1401:20121201:172741.539 [Z3001] Connection to database 'zabbix'
> failed: [1040] Too many connections
>    1360:20121201:172741.960 One child process died (PID:1401). Exiting ...
>    1360:20121201:172744.040 Syncing history data...
>    1360:20121201:172744.055 Syncing history data...done.
>    1360:20121201:172744.055 Syncing trends data...
>    1360:20121201:172745.655 Syncing trends data...done.
>    1360:20121201:172745.710 Zabbix Server stopped. Zabbix 1.8.2
> (revision 11211).


El primer mensaje es normal, el housekeeper simplemente elimina 
registros antiguos de la base de datos, el segundo mensaje es un error 
de conexión al servidor MySQL igual al que da la wiki.

El tercer mensaje es el que no tengo muy claro. No sé si al fallar la 
conexión a la base de datos zabbix_server decidió cerrarse o si fue otro 
motivo el que propició la caída del proceso.


> Supongo que el mensaje de que un proceso hijo murió se refiere a un
> proceso de la base de datos, ¿puede ser posible?


No exactamente, todos los procesos zabbix_server mantienen una conexión 
activa con el servidor MySQL completamente independiente, por lo que si 
estás usando la configuración por defecto:

# StartPollers=5
# StartIPMIPollers=0
# StartPollersUnreachable=1
# StartTrappers=5
# StartPingers=1
# StartDiscoverers=1
# StartHTTPPollers=1
# StartDBSyncers=4
# StartProxyPollers=1

Son unos 20 procesos zabbix_server con sus respectivas 20 conexiones 
persistentes a la base de datos.

Eso ya está quitando una quinta parte de la capacidad del servidor, 
recomiendo de nuevo aumentar el número de conexiones a 300 como mínimo.

Se puede ver el número de procesos y el número de sockets con los 
siguientes comandos:

root en zabbix:~# lsof -n | grep "mysqld.sock" | wc -l
94
root en zabbix:~# ps -efu zabbix | grep "zabbix_server$" | wc -l
98
root en zabbix:~# mysql -e "SHOW PROCESSLIST" -uroot -pTUCONTRASEÑA | cut -f 4 
| grep zabbix | wc -l
94

Como puede verse hay 4 conexiones menos a la base de datos que procesos 
zabbix_server, parece que no todos los procesos mantienen conexión con 
ella. El primer comando mide conexiones a través de unix socket al mysql 
y el tercero conexiones activas (aunque estén durmiendo) al servidor mysql.


> 1') Como apunte adicional, pero ya dejando de lado lo que es la caída
> del servidor en sí, tengo que cambiar la plantilla para que no saque
> mensajes que no sirven de nada, como por ejemplo:
>
>    1391:20121201:154337.476 Item [Zabbix Server:sensor[temp2]] error:
> Not supported by Zabbix Agent
>    1393:20121201:154339.919 Item [Zabbix Server:sensor[temp3]] error:
> Not supported by Zabbix Agent
>    1390:20121201:154341.740 Item [Zabbix Server:sensor[temp1]] error:
> Not supported by Zabbix Agent
> Es totalmente innecesario monitorizar algo que no está soportado, ¿no?


Realmente no se monitoriza, sólo se obtienen métricas. Se puede cambiar 
en algunos casos por esto:

En zabbix_agentd.conf:
UserParameter=sensores[*],lang=C sensors | grep "^$1" | sed 
's/^.*:\([^a-z]*\).C.*$/\1/'

En el item:
En vez de Zabbix Server:sensor[temp1] -> Zabbix Server:sensores[temp1]

Tienes que instalar lm-sensors para que funcione.

Vendría bien, si se pueden obtener bien las métricas de temperatura, 
agregar alertas por temperatura. Luego se puede crear un script en 
zabbix que ejecute un cpufreq-set por CPU para reducir su frecuencia de 
trabajo al mínimo o cambiar el governor:

Script para reducir la frecuencia de trabajo:
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo 
"powersave" > $i ; done

Para volver al modo por defecto:
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo 
"ondemand" > $i ; done

Puede ayudar en verano. Aquí en Madrid no habrá tanto problemas como en 
mi tierra, Linares, pero siempre viene bien conocer a qué temperatura 
trabajan las máquinas para evitar daños en el hardware (sobre todo en 
los discos duros, que son los más sensibles a la temperatura).


> Y en relación con el cambio de configuraciones en las plantillas:
>
>    1390:20121201:155106.180 Item [Zabbix
> Server:vfs.fs.inode[/var/www,pfree]] error: Type of received value
> [95.261516] is not suitable for value type [Numeric (integer 64bit)]
> Esto también se repite cada dos por tres.
>
> Este tipo de mensajes:
>
>    1396:20121201:152632.345 Sending list of active checks to [127.0.0.1]
> failed: host [localhost] not found


No pasa nada, por algún motivo el agente se identifica como "localhost":

root en zabbix:~# zabbix_get -s 127.0.0.1 -k system.hostname
zabbix

La respuesta correcta debería ser un nombre de host válido que esté dado 
de alta en zabbix. Creo recordar que en jderobot está dado de alta como 
"Zabbix Server", por lo que hay que agregar esto a zabbix_agentd.conf:

Hostname=Zabbix Server

Si no coincide el hostname de un servidor con el que está configurado 
dentro de zabbix no se puede enviar el listado de comprobaciones 
activas. De todas formas no hay configurado ninguna comprobación activa, 
por lo que tampoco pasa nada.


> Yo creo que también tienen relación a que no está bien hecha la
> plantilla. En lugar de localhost lo mismo hay que poner la IP de
> localhost como tal. O directamente monitorizar la IP que tiene el
> servidor (193.147.15.110), ¿no?


Yo haría un "zabbix_get -s 127.0.0.1 -k system.hostname" y con la 
respuesta que nos dé el agente configuraría el host de zabbix (que ahora 
es "Zabbix Server".


> 2) Supongo que lo que comentas de poder crear usuarios normales para
> poder meterse en la máquina se podrá hacer con la base de datos de
> usuarios del LDAP, es decir, configurar el servidor SSH de alguna manera
> para que consiga loguear a usuarios "normales". No sé lo que dirá José
> María al respecto, pero supongo que si se pudiese hacer esto lo lógico
> sería que estos usuarios no tuviesen ningún tipo de privilegio salvo el
> de poder acceder a su propio home. Aun así, creo recordar que me dijo
> José María un día que no lo tenía hecho así a propósito.


No todos los usuarios, sólo los que pertenezcan a un grupo dado. Si se 
permitiera el acceso a todos los usuarios podría entrar cualquiera al 
servidor y acceder (aunque sólo sea para leer) a ciertos sitios que 
quizá no interesen.

Otra cosa sería dar usuarios locales sólo a quienes lo necesiten o vayan 
a colaborar en ciertas tareas de administración.


> 3) En la configuración de watchdog está puesto:
> max-load-5              = 18
> Ese valor es el que viene por defecto, pero está claro que se lo ha
> saltado a la torera viendo los resultados... Quizá para la antigua
> máquina esto hubiera sido un valor muy bajo, pero a lo mejor ahora viene
> bien dejarlo activo así (o quizá un pelín más alto para no pillarnos los
> dedos, por ejemplo en 35 ó 40). El fichero /etc/default/watchdog está
> como sigue:
>
> # Start watchdog at boot time? 0 or 1
> run_watchdog=1
> # Load module before starting watchdog
> watchdog_module="none"
> # Specify additional watchdog options here (see manpage).


Habiendo sobrepasado en muchas ocasiones ese valor sin haber caído 
completamente la máquina debería haber dejado rastro en syslog. ¿Puedes 
mirar qué dejó en él?


> Supongo que en lo de las opciones se le podría indicar la opción de "-b"
> para que haga un softboot...


Primero a ver el motivo por el que no funcionó este fin de semana...

Voy a desayunar, a la vuelta continúo.