[Jderobot-admin] Caída del servidor del finde pasado

[Oscar Garcia]

El 08/11/12 20:00, Borja Mon Serrano escribió:
> Hola,
> Dado que los problemas con perl y las dependencias de libc se han 
> solucionado y ya se pueden hacer instalaciones desde el repositorio 
> oficial, estoy haciendo cambios para mejorar y monitorizar el servidor 
> tal y como ha dicho Óscar.


Me alegra saberlo. ¿Al final habéis tirado de paquetes oficiales? ¿Era 
perl el que impedía que se instalaran cosas?

Me interesa saber cómo se ha arreglado si no es molestia.


> De momento no he instalado zabbix, aunque me estoy mirando el manual 
> para entenderlo mejor. Por lo que veo, hay que tener instalado un 
> servidor y un agente, pero no se pueden (o *deben*) instalar en la 
> misma cuenta de usuario. Siendo así, ¿qué recomendarías, Óscar? 
> ¿Arrancar el servidor en root y el agente en otra cuenta o al revés? 
> La verdad es que estoy un poco perdidillo en este tema.


Es la primera noticia que tengo de eso y no creo que sea cierto. Tengo 
en producción cinco servidores zabbix (tres de ellos en monitorización 
distribuida) y todos ellos llevan agentes ejecutándose en la misma 
máquina con el mismo usuario (zabbix).

En debian la instalación es muy sencilla, sobre todo si se usa dbconfig, 
crea automáticamente un usuario en la base de datos para la 
monitorización, crea la base de datos, realiza la importación de la 
plantilla inicial, etc. Luego hay que instalar el frontal php. Todo está 
disponible en forma de paquetes en los repositorios oficiales.

Las plantillas que vienen en zabbix son muy genéricas y, como ocurre en 
casi todas las plataformas de monitorización, hay cosas que no sirve 
para nada monitorizar o saltarán alertas por no estar instalados 
servicios, pero nada que no se pueda arreglar desactivando el monitor o 
eliminándolo de la plantilla.

Por cierto, en mi empresa no usamos ninguna plantilla "por defecto", al 
final hemos tirado de plantillas propias. Con 10 o 20 máquinas no 
importa si monitorizas más de lo que necesitas, pero con casi 1000 
máquinas la base de datos es el mayor cuello de botella de la 
monitorización.

Ojito con eso si el servidor zabbix va a estar en una máquina donde haya 
más cosas funcionando y va a monitorizar muchos equipos, escribir 5 o 10 
registros por segundo no ralentiza nada, pero si se empiezan a meter 
máquinas a monitorizar, posiblemente escribir 100 o 200 registros por 
segundo empiece a comerle tiempo de I/O a otros procesos (servidor web, 
ftp o svn) si los discos no son rápidos.

Por último, MUY IMPORTANTE, activar innodb_file_per_table y reiniciar 
mysql ANTES de comenzar la instalación del servidor zabbix.

Si los espacios de tablas (tablespaces) se dejan en un archivo único, 
ibdata1, éste podrá crecer hasta ocupar varios gigas conforme pasen los 
meses (si no se modifican las plantillas para que en vez de guardar 
históricos detallados tres meses y tendencias durante un año) y luego no 
se podrá recuperar ese espacio ni borrando la base de datos (y no se 
podrá borrar el archivo sin perder los tablespaces del resto de tablas 
de las bases de datos existentes).

Por último (para rizar el rizo) se puede usar un servidor percona y 
particionar la base de datos para aumentar el rendimiento. Percona se 
puede instalar sobre los datos binarios de un mysql anterior y arranca y 
los usa sin problemas.


> Lo que comentaste de cambiar la línea del script de php5 no nos sirve, 
> ya que el problema viene del script de php4. Te recuerdo que me pusiste:
>
> 09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d
> /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1
> -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete
>
> ¿Valdría eso mismo poniendo php4 en lugar de php5 para nuestro caso? 
> En el syslog he visto que el script de php5 funciona bien.


Lo que no entiendo es qué hace aún un servidor en PHP4... desde debian 
etch viene por defecto PHP5 e incluso en sarge ya se podía elegir entre 
PHP4 o 5. ¿No habéis pensado en migrar a PHP5? Me da miedo preguntar qué 
versión de debian estáis usando :S :)

Supongo que valdrá, basta con que pruebes la siguiente línea de comandos...

find /var/lib/php4/ -depth -mindepth 1 -maxdepth 1 \
       -type f -cmin +$(/usr/lib/php4/maxlifetime)

... y veas si aparecen archivos de sesión de PHP. Si no funciona hay que 
localizar dónde se guarda el archivo maxlifetime, y dónde se guardan los 
archivos de sesión para adaptar la línea a las rutas correctas.


> Perdona que te conteste tan tarde, pero es que hay que digerir toda la 
> información que has puesto y necesitaba también empezar a trastear con 
> estas herramientas para ver cómo funcionan.


Es lógico, cada uno tiene sus cosas que hacer y tiempo limitado para 
hacerlas :)


------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jderobot-admin/attachments/20121108/34e530bd/attachment.htm