Sistemas de monitorización de aplicaciones / hosts distribuidos geográficamente, tolerantes a fallos e "inteligentes"


12

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 :-)


2
Eso es realmente extraño, estaba a punto de hacer una pregunta similar. Esta semana tuvimos algunas quejas de los clientes sobre interrupciones en el sitio, pero solo en ciertos lugares. Nuestros sistemas de alerta no detectaron estos problemas. Contactamos a nuestro proveedor y confirmaron que algunos tenían algunos problemas de red troncal. Entonces también estoy interesado en una solución. ¡Gracias!
splattne el

¿Y cuál fue la solución final?
ewwhite

Respuestas:


4

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:

  • en mi caso, el entorno monitoreado era la configuración típica maestro-esclavo [sql primario o servidor de aplicaciones + espera activa], no maestro-maestro.
  • mi configuración implicaba 'factor de filtrado humano': un grupo de resolución que era una 'copia de seguridad' para la notificación de sms. ya había un grupo remunerado de técnicos que, por otras razones, tenían turnos de 24/5, se les "comprobaban los correos de nagios" como una tarea adicional que no les imponía demasiada carga. y se encargan de asegurarse de que db-admins / it-ops / app-admins ware realmente se levante y solucione problemas; -]
  • He escuchado muchas cosas buenas sobre zabbix , para alertar y trazar tendencias, pero nunca lo usé. para mí, munin hace el truco, he pirateado el simple complemento de nagios para verificar si hay un color 'rojo' [crítico] en la lista de servidores de munin, solo una verificación adicional. también puede leer valores de archivos munrd rrd para disminuir el número de consultas que envía a la máquina monitoreada.

1
@astinus: bueno para alertas sensibles, utilicé un script de notificación personalizado. en lugar de depender de nagios notificar por correo / buscapersonas, almacené el mensaje a quince y tuve al consumidor que envió el mensaje basado en una lógica personalizada [basada en un horario de llamadas bastante flexible, etc.], además, hubo un límite de mensajes enviados por hora, así que uno no recibe 50 sms en poco tiempo. Veo enfoques similares en escalas más grandes: nagios es solo un esqueleto y las personas escriben alrededor de él y en realidad usan cada vez menos características.
pQd el

1
Con respecto a la jerarquía, lo que tengo en este momento es una configuración de Nagios completamente "modular" donde su directorio etc / contiene una configuración 'core' que es compartida (e idéntica) en todos los hosts y luego etc / modules / $ NAME (es decir : Correo, Web, Red, DNS) que es 100% portátil entre servidores. Incluir con cfg_dir =) Usted pone cualquier comando específico de módulo, complementos y todo en ese directorio. Fabricación> 1 servidor ejecutar estos controles es bastante fácil, ya que sólo tienes que copiar el módulo a la mayor cantidad de cajas de Nagios según sea necesario, sin embargo, una vez más, la lógica de alerta causa problemas :-)
nixgeek

1
@ astinus # 2. en mi caso, la replicación de configuración master-> slave ocurre cada 6h. si el maestro simplemente muere [corte de energía, etc.] - el esclavo alertará a todos acerca de que el maestro está muerto [verificación cruzada entre servidores]. uno puede imaginar otro escenario: cuando el maestro muere debido a una configuración incorrecta. si eso sucede hasta 5 minutos antes de la sincronización de configuración con el esclavo, habrá una notificación. si es justo antes de la sincronización de configuración, desafortunadamente terminamos sin tener un sistema de monitoreo. ¿Quién vigilará al vigilante? bueno tal vez otro nagios muy simple.
pQd el

1
@pQd: interesante, estoy de acuerdo en que implementar la lógica en los scripts de notificación personalizados es probablemente el camino a seguir. Sin embargo, es bastante difícil evitar las notificaciones duplicadas de más de 2 hosts, cuando se dice que hay 50 hosts de monitoreo, y todavía no he visto a nadie (en público) poner su lógica compartida en un sistema adecuado de transmisión de mensajes como Rabbit o Amazon SQS.
nixgeek el

1
@ astinus # 3 en mi caso era la solución 'Nivel 8' [del modelo iso osi]: nagios primarios enviaba sms'es a las personas en llamadas + correos a 24/5 'grupo resolutor', mientras que 2 nagios secundarios solo enviaban correos ' grupo de resolución ". dependía de ese grupo filtrar duplicados antes de escalar;
pQd el

1

Lo que estás pidiendo se parece mucho a lo que Shinken ha hecho por Nagios.

Shinken es una reescritura de Nagios.

  • Lenguaje moderno (Python)
  • Marco moderno de programación distribuida (Pyro)
  • Monitoreo de reinos (multicliente), HA, repuestos
  • API de Livestatus
  • Nagios plugin compatible
  • Ejecución NRPE nativa
  • Crítica empresarial de los objetos.
  • Las reglas de negocio se pueden aplicar al estado de los objetos (gestión de la disponibilidad del clúster o grupo)
  • Los gráficos pueden usar grafito o RRDtool basados ​​en PNP4nagios
  • Estable y desplegado en entornos grandes.
  • Las implementaciones grandes pueden considerar emparejarlo con Splunk para generar informes o examinar Graphite donde RRDtool no es una buena opción.

Esto debería ser motivo de reflexión.

Salud

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.