Saludos,
Me gustaría pedirles a los colectivos opinión y opinión sobre los sistemas de monitoreo distribuido, ¿qué utilizan y qué saben que podría marcar mis casillas?
Los requisitos son bastante complejos;
No hay un solo punto de falla. De Verdad. ¡Estoy hablando en serio! Debe poder tolerar la falla de un nodo único / múltiple, tanto 'maestro' como 'trabajador' y puede suponer que ninguna ubicación de monitoreo ("sitio") tiene múltiples nodos en él, o están en la misma red. Por lo tanto, esto probablemente descarte las técnicas tradicionales de alta disponibilidad como DRBD o Keepalive.
Lógica distribuida, me gustaría implementar más de 5 nodos en múltiples redes, dentro de múltiples centros de datos y en múltiples continentes. Quiero la vista "Birds Eye" de mi red y aplicaciones desde la perspectiva de mis clientes, puntos de bonificación para que la lógica de monitoreo no se atasque cuando tienes más de 50 nodos, o incluso más de 500 nodos.
Debe ser capaz de manejar un número bastante razonable de controles de host / servicio, a la Nagios, para que las cifras aproximadas supongan 1500-2500 hosts y 30 servicios por host. Sería realmente bueno si agregar más nodos de monitoreo le permitiera escalar de forma relativamente lineal, ¡tal vez dentro de 5 años podría estar buscando monitorear 5000 hosts y 40 servicios por host! Agregando de mi nota anterior sobre 'lógica distribuida', sería bueno decir:
- En circunstancias normales, estas comprobaciones deben ejecutarse en $ n o n% de los nodos de supervisión.
- Si se detecta una falla, ejecute comprobaciones en otro $ n o n% de nodos, correlacione los resultados y luego utilícelos para decidir si se han cumplido los criterios para emitir una alerta.
Gráficos y características amigables de gestión. Necesitamos rastrear nuestros SLA y saber si nuestras aplicaciones 'altamente disponibles' están activas 24x7 es algo útil. Idealmente, su solución propuesta debería hacer informes "listos para usar" con un mínimo de fallas.
Debe tener una API sólida o un sistema de complementos para el desarrollo de cheques a medida.
Necesita ser sensible sobre las alertas. No quiero saber necesariamente (a través de SMS, a las 3 a.m.) que un nodo de monitoreo reconoce que mi enrutador central está caído. Yo no quiero saber si un determinado porcentaje de ellos están de acuerdo que algo enrrollado está sucediendo;) Básicamente lo que estoy hablando aquí es de "quórum" lógica, o la aplicación de la cordura a la locura distribuido!
Estoy dispuesto a considerar las opciones comerciales y de código abierto, aunque preferiría evitar el software que cuesta millones de libras :-) También estoy dispuesto a aceptar que puede que no haya nada que marque todas esas casillas, pero quería preguntarle al colectivo eso.
Cuando piense en monitorear nodos y su ubicación, tenga en cuenta que la mayoría de estos serán servidores dedicados en redes de ISP aleatorias y, por lo tanto, estarán fuera de mi control. Es probable que las soluciones que dependen de las fuentes de BGP y otras travesuras complejas de redes no sean adecuadas.
También debo señalar que en el pasado he evaluado, implementado o utilizado / personalizado en gran medida la mayoría de los sabores de código abierto, incluidos Nagios, Zabbix y sus amigos: en realidad no son malas herramientas, pero en general caen de plano " "distribuido", particularmente con respecto a la lógica discutida en mi pregunta y alertas 'inteligentes'.
Feliz de aclarar cualquier punto requerido. Saludos chicos y chicas :-)
fuente
Respuestas:
No es una respuesta realmente, pero algunos consejos:
definitivamente, eche un vistazo a la presentación sobre nagios @ goldman sachs . enfrentaron problemas que usted menciona: redundancia, escalabilidad: miles de hosts, también generación de configuración automatizada.
Tenía una configuración redundante de nagios pero a una escala mucho menor: 80 servidores, ~ 1k servicios en total. un servidor maestro dedicado, un servidor esclavo que extrae la configuración del maestro a intervalos regulares varias veces al día. ambos servidores cubrieron el monitoreo de las mismas máquinas, tenían una verificación cruzada de salud entre sí. Utilicé nagios principalmente como marco para invocar comprobaciones específicas de productos personalizados [grupo de trabajos cron que ejecutan scripts que hacen 'controles de flujo artificial', registros de resultados registrados en sql, nrpe plugins que comprueban ejecuciones exitosas / fallidas de aquellos en los últimos x minutos]. Todo funcionó muy bien.
su lógica de quórum suena bien, un poco similar a mis 'flujos artificiales', básicamente continúe, implemente su auto; -]. y haga que nrpe simplemente verifique algún tipo de indicador [o sql db con indicación de fecha y hora] cómo van las cosas.
probablemente querrá crear cierta jerarquía para escalar: tendrá algunos nodos que recopilarán una visión general de otros nodos, mire la presentación desde el primer punto. La bifurcación de Nagios predeterminada para cada verificación es excesiva en un mayor número de servicios monitoreados.
para responder algunas preguntas:
fuente
Lo que estás pidiendo se parece mucho a lo que Shinken ha hecho por Nagios.
Shinken es una reescritura de Nagios.
Esto debería ser motivo de reflexión.
Salud
fuente