12 votos

Distribuidos geográficamente, tolerante a fallos y que "inteligente" application/host de sistemas de monitoreo

Saludos,

Me gustaría pedir a los colectivos de opinión y ver en la diversificación de los sistemas de monitoreo, lo usas y lo que es usted consciente de que podría garrapata de mis casillas?

Los requisitos son bastante complejas;

  • Ningún punto único de fallo. Realmente. Estoy hablando muy en serio! Debe ser capaz de tolerar la única/múltiple nodo falla, tanto de "maestro" y "trabajador" y se puede suponer que no hay ubicación de supervisión ("sitio") tiene varios nodos en ella, o están en la misma red. Por lo tanto, esta probablemente reglas tradicionales de HECTÁREAS de técnicas tales como DRBD o Keepalive.

  • Distribuido de la lógica, me gustaría ser la implementación de 5+ nodos a través de múltiples redes, dentro de los múltiples centros de datos y en varios continentes. Quiero que el "pájaro" a la vista de mi red y aplicaciones desde la perspectiva de mis clientes, puntos de bonificación para el seguimiento de la lógica de no estancarse cuando usted tiene más de 50 nodos, o incluso más de 500 nodos.

  • Debe ser capaz de manejar bastante razonable número de host/comprobaciones de servicio, a la Nagios, para cifras aproximadas asumir 1500-2500 hosts y 30 servicios por host. Sería muy bueno si la adición de más vigilancia en los nodos permite a escala relativamente lineal, tal vez en 5 años que podría estar buscando para monitor de 5000 hosts y 40 servicios por host! La adición de mi nota anterior sobre 'distribuido lógica" sería bueno que decir:

    • En circunstancias normales, estas comprobaciones se deben ejecutar en $n o% n de monitoreo de los nodos.
    • Si se detecta un fallo, ejecutar los controles en otro $n o% n de los nodos, se correlacionan los resultados y, a continuación, utilizar para decidir si los criterios se ha reunido para emitir una alerta.
  • Los gráficos y la gestión de características amigables. Necesitamos hacer un seguimiento de nuestro Sla y saber si nuestro 'alta disponibilidad de las aplicaciones están 24x7 es algo útil. Idealmente, tu solución propuesta debe hacer informes "fuera de la caja" con un mínimo de faff.

  • Debe tener una sólida API o sistema de plugins para el desarrollo de la medida de cheques.

  • Debe ser sensible acerca de las alertas. No quiero necesariamente saber (a través de SMS, a las 3 de la mañana!) que un nodo de supervisión reconoce mi router principal es hacia abajo. Puedo hacer quiero saber si un porcentaje definido de ellos de acuerdo en que algo diferente está pasando ;) Básicamente lo que estoy hablando aquí es de "quórum" de la lógica, o la aplicación de la cordura, distribuidos de la locura!

Estoy dispuesto a considerar tanto comerciales como de código abierto opciones, aunque yo preferiría que alejarse de software con un costo de millones de libras :-) yo también estoy dispuesto a aceptar que no hay nada por ahí que las garrapatas todas esas cajas, pero quería preguntar el colectivo que.

Cuando el pensamiento acerca de la supervisión de los nodos y su colocación, tenga en cuenta que la mayoría de estos servidores dedicados en aleatorio ISPs redes y por lo tanto en gran parte fuera de mi esfera de control. Las soluciones que se basan en BGP alimenta y otras complejas redes travesuras probable es que no traje.

También debo señalar que he cualquiera de los evaluados, despliega o utiliza mucho/personalizar la mayoría de la fuente abierta de sabores en el pasado, incluyendo Nagios, Zabbix y amigos-que realmente no son malas pero las herramientas que caiga en el conjunto de la "distribución" de aspecto, en particular con respecto a la lógica del objeto de mi pregunta y 'inteligente' alertas.

Feliz de aclarar todos los puntos requeridos. Saludos chicos y chicas :-)

4voto

Steve Mould Puntos 141

no es una respuesta de verdad, pero algunos consejos:

  • definitivly echar un vistazo a la presentación sobre nagios @ goldman sachs. se enfrentaban a los problemas que usted menciona de redundancia, escalabilidad: miles de hosts, también automática de configuración de generación.

  • yo había redundante de configuración de nagios, pero en mucho menor escala - 80 servidores, ~1k servicios en total. uno dedicado servidor maestro, un servidor esclavo tirando de configuración de maestro a intervalos regulares par de veces al día. ambos servidores cubiertos seguimiento de las mismas máquinas, que había de salud de la verificación cruzada entre uno y otro. he utilizado nagios en su mayoría como marco para invocar a un producto personalizado comprobaciones específicas [ montón de trabajos cron ejecución de secuencias de comandos haciendo artificial de flujo de los controles, los resultados de la vajilla de sesión de sql, nrpe plugins ware comprobación de éxito / error de ejecuciones de aquellos que en los últimos x minutos ]. todo funcionó muy bien.

  • su quórum lógica suena bien - un poco similar a mi artificial de los flujos' - básicamente ir, ipmplement su auto ;-]. y han nrpe acaba de comprobar algún tipo de bandera [ o sql db con la marca de tiempo de estado ] cómo las cosas se están haciendo.

  • usted probablemente querrá construir una jerarquía a escala - tendrás algunos nodos que se reúnen visión general de otros nodos, se ven en la presentación del primer punto. por defecto nagios que se bifurcan para cada cheque es un exceso en el mayor número de servicios monitoreados.

para responder a algunas preguntas:

  • en mi caso el entorno supervisado era típico maestro-esclavo setup [ principal de sql o de la aplicación de servidor + hot standby ], ningún maestro-maestro.
  • mi configuración humanos de filtrado factor' - resolución de grupo, que era un 'copia de seguridad', para la notificación por sms. ya había pagado grupo de técnicos que, por otras razones, había 24/5 turnos, que tiene que pasar nagios mails' como tarea adicional no poner demasiada carga sobre ellas. y la vajilla en el cargo de asegurarse de que db-administradores / -ops / app-administradores de la vajilla en realidad levantarse y solucionar problemas ;-]
  • he oído hablar mucho de las cosas buenas acerca de zabbix - para las alertas y el trazado de las tendencias, pero nunca la usó. para mí munin hace el truco, me han hackeado simple nagios plugin comprobando si existe la 'roja' [ crítica ] el color en munin lista de los servidores - sólo una comprobación adicional. así usted puede leer valores de munin rrd-archivos para disminuir el número de consultas que usted envíe a monitoreados de la máquina.

1voto

xkilian Puntos 71

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

Shinken es un Nagios a escribir.

  • Idioma moderno (Python)
  • Moderno distribuido marco de programación (Pyro)
  • Monitoreo de los Reinos(multi-tenancy), HA, repuestos
  • Livestatus API
  • Nagios plugin compatible
  • Nativo de NRPE ejecución
  • Criticidad del negocio de objetos
  • Reglas de negocio pueden ser aplicados para el estado de los objetos (administración de clúster de la piscina o de la disponibilidad)
  • Gráfica puede utilizar Grafito o de RRDtool base de PNP4nagios
  • Estable y está siendo implementado en entornos de gran tamaño
  • Grandes despliegues pueden considerar la posibilidad de combinar con Splunk para la presentación de informes o buscar en Grafito donde RRDtool no es un buen ajuste.

Esta debe ser la comida para el pensamiento.

Saludos

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X