[Modularit-devel] Fwd: Monitorización

[Miguel Armas]

Sorry, this message is in spanish, but I thought it could be
interesting to many people in the list.
If you received it and don't understand spanish, tell me and I'll send
it in english.
Anyway, I will try to publish this in english in the project wiki
during the next week...

---------- Mensaje reenviado ----------
De: Miguel Armas <kuko at canarytek.com>
Fecha: 4 de noviembre de 2009 19:15
Asunto: Re: Monitorización
Para: Imobach González Sosa <imobachgs at banot.net>


El día 1 de noviembre de 2009 00:20, Imobach González Sosa
<imobachgs at banot.net> escribió:
> Hola Kuko,

Hola Imo, perdona el retraso, pero he estado bastante liado... :(

> En la GCDS hablamos algo acerca de la posibilidad de estudiar otro tipo de
> monitorización para ModularIT. Es algo a lo que probablemente podría dedicarle
> algo de esfuerzo. ¿Tienes alguna idea acerca de lo que quieres?

Pues depende de por donda quieras meterle mano. En temas de
monitorizacion tenemos tres frentes abiertos:

1. Monitorizacion dentro de la maquina: Ahora estamos usando el PIFIA,
que es una ñapa que hicimos cuando estaba en la ULPGC basado en Perl.
Esto lo queremos reescribir en Ruby y hacerlo mucho mas potente, y
posiblemente integrarlo con Puppet. A esta parte le llamamos
internamente RASCA (porque es el sustituto de PICA). La idea es ir
desarrollando baterias de test formadas por componentes, de forma que
por ejemplo definamos:
* Servicio: Apache
 * Proceso: httpd,
   * comprobar que esta activo y que no consuma mas de X CPU y X
Memoria (si no se cumple, reiniciar)
   * Depende del fichero httpd.conf (si este cambia, reiniciar)
 * Fichero: httpd.conf, gestionado por Puppet (augeas, plantilla, o lo que sea)
 * Puerto: Debe estar escuchando en los puertos X e Y

Y que podamos encadenar tantos test como queramos (de diferentes
tipos) y podamos definir las dependencias. Cada test debe poder tener
una planificacion diferente (p.ej el proceso cada 5 min y el fichero
cada 60 min)

Parte de lo que queremos hacer ya lo hacen Puppet y God, asi que igual
podemos extender God e integrarlo con Puppet.

Para integrar esto con puppet hay un requisito previo: los test
tenemos que poder planificarlos con bastante periodicidad (cada 10
minutos?), pero puppet tiene una limitacion con los schedulers porque
el getcatalog no se puede replanificar, se ejecuta siempre (al menos
en la 0.24.x), y si ponemos el puppet a ejecutarse cada 10 minutos en
las maquinas matariamos al servidor puppetmaster. Para que cualquier
entorno de tests decente se pueda integrar con Puppet necesitamos
poder cambiar la planificacion del getcatalog. Esto lo plantee en la
lista de Puppet y Luke Kanies me dijo que era un cambio interesante y
que se lo apuntaba, pero que yo sepa aun no esta. Para hacer esto
necesitamos alguien que se mire las tripas de Puppet

2. Monitorizacion externa (sustituto del Nagios): Esta claro que
Nagios no es lo que queremos, pero aqui tenemos diferentes opciones:
2.1 Usar algun otro programa de monitorizacion que soporte alertas
asincronas (PandoraFMS, Zabbix, etc). Las ventajas es que ya estara
hecho y probablemente tienen muchas funcionalidades utiles.
2.2 Hacer algo nosotros: como en realidad todo el tema de
monitorizacion lo haremos desde dentro de las maquinas (con RASCA), lo
que realmente necesitamos es simplemente un sistema de notificacion de
eventos desde la maquina a una consola. Para este tema igual es muy
sencillo un sistema de notificacion de eventos basado en XMPP, con la
ventaja añadida de que tendriamos control de presencia de las maquinas
y podriamos tener un JabberBOT en cada maquina a la que mandarles
comandos simples para el tratamiento de incidencias. Ademas tambien
podriamos usar este sistema para notificacion de eventos que no tengan
nada que ver con monitorizacion (Inventario, recepcion de fax, etc).
El inconveniente de esta opcion es que tambien necesitamos
monitorizacion activa para sites web, servicios externos, etc.
2.3 Solucion mixta: desarrollar el punto 2.2 para los eventos, y dar
la posibilidad de pasar los eventos recibidos a alguna herramienta de
monitorizacion "normal" (Zabbix, etc)

3. Monitorizacion de rendimiento: Queremos integrar los parametros de
rendimiento en el sistema de monitorizacion para tener un sistema
predictivo y detectar cuando las maquinas se nos estan empezando a
quedar cortas, o se ha producido un evento que hay que investigar
(p.ej. las colas de correo han crecido un 70% sobre la media de los
ultimos dias: posible ataque de spam?). El entorno de toma de datos
parece que tenemos claro que sea collectd, pero donde se analizan
estos datos aun no lo tenemos muy claro. Se pueden analizar en la
maquina o se podrian pasar a una maquina externa que analizara las
tendencias y si es necesario redefina los umbrales de alerta. En
realidad para llegar a este paso deberiamos tener definido el paso 1.

Pues eso, dime que opcion te parece mas interesante y si quieres
meterte empezamos a plantearlo en la lista.

Salu2!
--
Miguel Armas <kuko at canarytek.com>
CanaryTek Consultoria y Sistemas SL
ModularIT http://www.modularit.org/



-- 
Miguel Armas <kuko at canarytek.com>
CanaryTek Consultoria y Sistemas SL
ModularIT http://www.modularit.org/