Necesito reemplazar munin con algo más escalable [cerrado]

He usado munin en varios servidores durante muchos años con gran éxito, sin embargo, con más de 100 nodos munin y cuando hay una carga en los clientes, el procesamiento se agota.

He realizado algunos cambios de escala en el trabajo cron y la cantidad de procesos del cliente, y he reducido la cantidad de complementos que se ejecutan, etc., pero he decidido buscar una alternativa que tenga una arquitectura más escalable.

Cualquier sugerencia o experiencia sería bienvenida. Básicamente, estoy interesado en las métricas del servidor que se pueden utilizar para la planificación de la capacidad y el diagnóstico del uso de los recursos. (tenemos nagios para alertar)

Parece que puedes tener dos problemas

1. En su servidor de monitoreo, registrar las métricas para muchos servidores requiere más E / S aleatorias de las que puede proporcionar su almacenamiento. Incluso si todas sus métricas se escriben en el disco, el servidor puede estar demasiado sobrecargado para generar gráficos a partir de ellas.
2. En los clientes que se supervisan, los complementos que recopilan las métricas son demasiado intensivos en CPU y memoria y no terminan de recopilar datos a tiempo cuando los clientes experimentan una gran carga.

He usado Munin en el pasado, pero actualmente estoy usando collectd . Los autores de collectd han puesto mucho pensamiento y esfuerzo en resolver este problema. Tienen un sistema bien diseñado para escribir los datos en archivos RRD que garantiza que no pierda datos y pueda generar gráficos actualizados. También hay soporte para RRDCacheD. El demonio y los complementos oficiales están escritos en C, por lo que utilizan poca memoria o tiempo de CPU. En mis sistemas cliente, usa menos de 2 MB de RAM y aproximadamente un cuarto de segundo de tiempo de CPU por minuto. En mi servidor de monitoreo, usa 20 MB de RAM y dos tercios de segundo de tiempo de CPU por minuto. Tenga en cuenta que todas mis métricas se recopilan y envían a mi servidor de monitoreo cada diez segundos, en lugar de a intervalos de minutos como munin.

Aunque son excelentes herramientas, Munin y otras interfaces de RRDTool (como Cacti o Ganglia) han conocido problemas de E / S y son difíciles de escalar cuando monitorea cientos de nodos.

Sin embargo, existen algunas técnicas para lidiar con este cuello de botella de E / S. Una de estas técnicas es distribuir las escrituras en una gran cantidad de discos para reducir la E / S en cada disco. Por otro lado, muchos administradores de sistemas usan los sistemas de archivos tmpfs para tratar este problema. RRDCached también es una opción reciente y buena para lidiar con esto y le recomiendo que eche un vistazo a estas diapositivas .

No estoy tan familiarizado con Munin, pero Cacti tiene un complemento Boost . Este complemento almacena en caché los datos en la memoria y realiza actualizaciones masivas y bajo demanda en el disco, en lugar de escrituras individuales, lo que reduce la E / S. Estoy bastante seguro de que Munin también tiene algo como esto.

Si puede pagarlos, los discos SSD también son buenas opciones.

Por último, pero no menos importante, también puedes echar un vistazo a Reconnoiter . Recconoiter es una nueva herramienta de detección de fallas y gráficos / tendencias. A diferencia de la mayoría de las herramientas de tendencias, Reconnoiter no está basado en RRDTool e intenta resolver este problema específico. No estoy usando Reconnoiter en la producción, pero he realizado algunas pruebas y, a pesar de ser un poco "verde", parece muy prometedor, especialmente con respecto a su escalabilidad.

¡Espero que esto ayude!

Echa un vistazo a Zabbix . Es una de las mejores herramientas de monitoreo de rendimiento de código abierto que existen. Se escala bien y se ha utilizado en entornos con miles de computadoras.

Marco Ramos da algunos consejos sólidos. Sin embargo, quiero agregar algunas aclaraciones: el gran problema con munin es su horario fijo de recolección de 5 minutos. Si todos los nodos no devuelven resultados dentro de la ventana de 5 minutos, comienza a tener abandonos. Este es el mayor problema con munin.

Otras herramientas basadas en rrdtool como Ganglia no están bloqueadas en esta misma ventana de actualización de 5 minutos porque no sondean todas las fuentes de datos de la misma manera secuencial que lo hace Munin.

Recomiendo que mire Ganglia porque generalmente parece escalar bien (aunque necesita desactivar la recopilación de datos de multidifusión para una instalación de ganglios grandes). Sospecho que puedes llegar muy lejos con los ganglios antes de que tengas que preocuparte de que rrdtool sea el punto de estrangulamiento. En ese momento, puede hacer todo tipo de cosas que sugiere Marco, como usar unidades SSD.

Estoy reemplazando a Munin con Ganglia, Munin mata mi servidor, así que intentaré a Ganglia y veré cómo se escala.