Re: [OT] sobre monitoring
El día 11 de marzo de 2016, 16:22, Camaleón <noelamac@gmail.com> escribió:
> El Thu, 10 Mar 2016 14:48:25 +0100, Alba Ferri escribió:
>
>> Gracias por vuestras respuestas, suelo mirar ahí Camaleón :)
>
> Perfecto :-)
>
>> Actualmente estamos usando Icinga2 como plataforma de monitorización,
>> después de migrar desde nagios.
>> ¿Alguien más?
>
> Pues no, la verdad es que no uso ningún sistema de gestión/monitorización
> de registros pero sería interesante que comentaras el por qué del cambio
> de Nagios a Icinga2, seguro que a muchos listeros les puede interesar.
Pues la razón principal fue la escalabilidad.
En Nagios cada host+servicios están definidos en un servidor, mientras
que en Icinga2, se definen en un master (en nuestro caso) y manda
hacer los chequeos de forma distribuida a un pool de servidores
satelites.
Los chequeos de cada máquina no tienen que hacerse por el mismo
satelite, sino que igual 3/4 chequeos los hace uno, otros tantos otro
y así. Luego cada uno le manda la info al master, que lo unificada en
la DB y la interfaz gráfica (IcingaWeb2) lee de ahí para mostrar los
datos de la máquina en cuestión.
Así si empiezas a tener retardos a la hora de hacer chequeos porq
tiene más encolado de lo de que da abasto, tan solo añades otro
satelite más y listo.
En Nagios si añades un servidor más, tienes que dar de alta las
máquinas en el nuevo servidor y darlos de baja en el otro
(que si, que es sólo copiar archivos, pero ya tienes que controlar que
máquinas están en cada servidor Nagios).
>
>> Es verdad que hay mucha documentación sobre nagios y se pueden
>> "reutilizar" casi todos los scripts.
>>
>> Pero me preguntaba más bien por los típicos problemas de monitorización
>> de logs...cuando sale el msj una vez y en el siguiente chequeo ya no
>> sale y entonces lo das como OK? o qué se suele hacer?
>
> Mejor si especificas un poco más el problema, p. ej., qué tipo de evento
> estás monitorizando, la plantilla que utilizas, la configuración general
> de Icinga2... en cuanto a las estrategias de avisos pues cada uno tendrá
> la propia según le interese, es decir, si quieres asegurarte de que un
> evento importante sea atendido por el operador pues podrás configurarlo
> para que salten los avisos hasta que se realice alguna operación
> específica, etc...
>
Pongo un ejemplo:
Ahora mismo como hacemos para monitorizar el log de sistema (esto
viene del histórico), leemos en el /var/log/messages y buscamos los
patrones que nos indican los sysadmin (kernel error, etc). Si
encontramos el patrón, hace un exit 1 y echo "Se ha encontrado el
siguiente error blablabla".
Y guardamos cual fue la última linea del log.
Ahora bien, en el siguiente chequeo, empieza a leer desde la última
linea leida, con lo cual, si no machea con ningún patron, hace un exit
0 y pinta que está todo OK, pero no es cierto! Porq anteriormente
encontró un error (supongamos...).
Normalmente no hay un ACK del error, que nos indique que se ha solucionado..
No se si me he explicado bien...
Por ahora salta el CRITICAL en la consola de Icinga2 hasta que cambia
de estado...q es a los 5 minutos, cuando se produce el siguiente
chequeo...si el operador no se da cuenta y no crea la alerta...estamos
jodidos.
No es como en OVO, que salta la alarma y ahí se queda hasta que
alguien la trata...
>> Lo mismo con el llenado de FS, que a veces es mejor controlar los
>> llenados muy rápidos, más que se supere un threshold específico...
>>
>> Por charlar sobre estos aspectos...
>
> Me sigue pareciendo un asunto demasiado genérico para esta lista pero
> bueno, a ver si alguien te puede decir qué estrategias utiliza en su caso.
>
Totalmente!!! vaya rollo os he soltao y seguro que a mucha gente no le
interesa, por eso preguntaba por la lista de monitoring...sorry guys!
> Saludos,
>
> --
> Camaleón
>
Saludos, Alba.
Reply to: