El 11/03/2016 13:10, "Alba Ferri" <branvan2k@gmail.com> escribió:
>
> 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.
>
Saludos cordiales.
He seguido atento este hilo ya que estoy en algo parecido relacionado con monitoreo.
Hice hace un par de años un software para monitoreo de alarmas comunitarias con notificaciones vía sms, se llamaba usaga (micro sistema de monitoreo de alarmas).
Desde hace un año más o menos trabajo en una empresa donde hay varias sucursales (450) cada uno con un pc que hace de servidor.
Mi trabajo es ver que estos servidores estén operativos y principalmente sql server.
Cabe mensionar que no trabajo como desarrollador y para monitorear esos servidores no disponíamos de una herramienta para tal fin. Sólo nos dábamos cuenta algo no estaba bien cuando recibíamos las llamadas de las sucursales quejándose de que algo no funciona.
Así que me di a la tarea modificar el software que tenía de hace años para adaptarlo a lo que se va necesitando y ahora lo usamos para el monitoreo y nos ayuda a preveer posibles problemas.
Lo que monitoreo es: tiempo de encendido del servidor, estados de los jobs de sql server, espacio libre de los discos, y otras cosas más.
La base de datos que usa es postgres y tengo al momento más de 200 millones de registros de eventos.
Espero mejorarlo aún más y liberarlo como software libre en un par de meses y espero les sea útil.
Pueden ver la primera versión en youtuve como usaga alarmas comunitarias y también está en github como usaga en mi nic edwinspire.
Lamento la extension del mensaje pero era necesario el contexto.