Cacti vs Nagios vs Pandora FMS; una comparativa en profundidad
Cacti, Nagios y Pandora FMS son tres aplicaciones de monitorización con aproximaciones completamente diferentes: Cacti está enfocada en gráficas, Nagios en estados, y Pandora FMS abarca ambos aspectos, entre muchas otras funcionalidades. Si conoces RRDTool o MRTG, Cacti expande esa filosofía: si tengo una fuente de datos, puedo pintar los datos. Si tengo varias fuentes de datos, puedo combinarlos. Cacti se inició con esa filosofía y evolucionó siguiendo este paradigma: pintarlo todo en gráficas. Y hay que decir que lo hace realmente bien. Algunas de las gráficas de Cacti que utiliza por debajo RRDTool son realmente potentes y atractivas.
Tradicionalmente, en multitud de entornos, se usaba Cacti para crear gráficas y Nagios para gestionar estados y levantar alertas. Esto no significa que Cacti no tenga alertas, ni que Nagios no tenga gráficas, pero en ambos casos son “añadidos” que complementan la funcionalidad principal. No es algo que viniera contemplado en el diseño inicial, por lo que, de alguna forma, esos complementos no dejan de ser una solución pobre y externa a la aplicación base. Por otro lado, Pandora FMS fue concebido desde sus inicios para hacer ambas cosas simultáneamente, y ofrecerlas como funcionalidades principales.
Como ya llevamos haciendo desde hace unos meses, queremos seguir probando herramientas para ayudar a la comunidad de este blog a tomar una de las decisiones más importantes: la instalación de la herramienta de monitorización de sus sistemas.
Cacti, Nagios y Pandora FMS: almacenamiento y gestión de los datos
Cacti se define como una solución de gráficas de red para sacar todo el poder de RRDTool, lo cual explica cómo gestiona los datos, utilizando RRTool, una herramienta muy extendida para almacenar series de datos numéricas en escalas de tiempo.
Podríamos decir que Cacti no es una base de datos al uso, lo que la limita a la hora de usar esos datos en otro ámbito que no sea gráficas, impidiéndonos relacionar datos de diferentes fuentes en consultas condicionales o agrupadas, cosa que sí podemos hacer con Pandora FMS y en menor medida con Nagios (con los add-ons adecuados).
Esto no significa que Cacti no use una base de datos relacional, que la tiene, sino que solo la utiliza para guardar información sobre las gráficas, los informes y otros detalles, pero no para almacenar o procesar la información que visualiza en las gráficas.
Cacti, Nagios y Pandora FMS: Monitoreo de red
Se podría decir que Cacti surge de una evolución de MRTG, un clásico de 1994. Originalmente fue creado para medir tráfico en routers a través de SNMP, y más tarde se amplió para medir cualquier cosa que pudiera devolver información a través de una interfaz SNMP. Finalmente, ha evolucionado hasta ser capaz de medir “cualquier cosa que devuelva un dato numérico”, ya sea el tráfico de una red, el número de paquetes perdidos, o el consumo de CPU de un servidor.
Monitorizar una red es mucho más que medir consumos de ancho de banda, medir pérdidas de paquetes o comprobar los tiempos de latencia de una red. Nos dejamos lo más importante: saber si hay conectividad de un punto a otro, es decir, lo que se conoce como Ping.
Por otro lado, la autoexploración, detección de sistemas y creación de un mapa topológico, es algo que se suele pedir a cualquier herramienta de monitoreo de red, sobre todo si puede hacerlo a nivel dos (a nivel de enlace).
En entornos serios es casi obligatorio poder obtener información tanto de estados como de rendimiento, a través de monitorización asíncrona basada en recepción de traps SNMP.
El último nivel a este respecto estaría en la capacidad de trabajar con flujos de red (Netflow) para visualizar en tiempo real el consumo de la red, en función de filtros definidos por el usuario. Esas estadísticas del tráfico se generan en los routers y los colectores la procesan para generar informes y gráficas.
De todo esto, Cacti solo es capaz de realizar una pequeñísima parte, ya que no dispone de capacidad suficiente para saber si se ha caído un enlace de red, o para explorar la red, y menos aún para hacer un mapa. Tampoco tiene la capacidad de recibir traps, ni tampoco puede trabajar con Netflow.
En su origen, Nagios se creó para detectar si un host estaba caído. Poco a poco, se fueron añadiendo cosas, pero tampoco cumple con todos los propósitos que debería tener un sistema completo de monitoreo de red. La gestión de traps es muy básica (para Nagios un trap no deja de ser una línea de un log), y los mapas que detecta y dibuja no son personalizables y son únicamente a nivel de red, no a nivel de enlace. Por otro lado, la capacidad de medir datos de forma gráfica es bastante nueva en Nagios y hasta hace poco era necesario instalar plugins de terceros. Nagios dispone de análisis de flujos (Netflow).
Pandora FMS cubre todas las funcionalidades y resulta especialmente notable en el apartado de descubrimiento y mapeo de redes a nivel 2 y nivel 3. El sistema de gestión de traps de Pandora FMS es similar al que realiza CA Spectrum o BMC Patrol, y puede procesar variables dinámicas dentro de traps con varios bindings, generando módulos de datos (visibles en gráficos graficables) a partir de los mismos, así como generar alertas o eventos a partir de un valor específico en cierta variable de un trap. Además, Pandora FMS es capaz de pintar gráficas de consumo de tráfico en una interfaz SNMP, ver tiempos de latencia, disponibilidad de un servicio, etc.
Nagios
Pandora FMS
Gestión de eventos
Los eventos son el resultado de lo que ocurre cuando se monitorea algo y ocurren cambios a lo largo del tiempo: si un elemento monitorizado que estaba bien pasa a estar mal, se produce un evento (caída), y cuando este elemento caído se recupera, se produce otro evento (recuperación). Lo mismo pasa cuando el sistema detecta elementos nuevos, cuando se dispara una alerta o cuando hay diferencias entre un elemento con información detallada (cambios en configuración). La idea de la gestión de eventos en monitorización es que, de un vistazo, se vea lo que está mal y sirva de punto de inicio para investigar. Además, sirve de histórico para ir viendo las cosas que han sucedido a lo largo de las últimas horas y para, en caso de tener que ausentarse, tener la posibilidad de recurrir a un histórico y ver qué pasó en su ausencia.
Esta tecnología es habitual en herramientas orientadas al mundo empresarial, donde existen equipos de operación que gestionan la monitorización y la operación de un gran entorno. Software como HP OpenView, IBM Tivoli, BMC Patrol o CA Spectrum lo tienen, al igual que Pandora FMS o ZenOSS. Sin embargo, ni Nagios ni Cacti pueden ofrecer la misma funcionalidad. Nagios, en sus últimas versiones, ha incorporado un histórico de eventos, pero su propósito no deja de ser ver el histórico de sucesos, sin poder gestionar la monitorización ni utilizar los eventos para correlar, autovalidar o formar parte del flujo de la monitorización. Nagios ofrece lo más básico, el registro de un suceso, pero no tiene ni remotamente lo que se consigue con otras herramientas.
Nagios
Pandora FMS
Descentralización y gestión distribuida
Tanto Pandora FMS como Nagios tienen presente el problema de tener que obtener información de redes inaccesibles para el servidor central. Nagios lo resuelve a duras penas con su catálogo de agentes, mientras que Pandora FMS tiene un servidor específicamente diseñado para ello, que se puede desplegar de forma autónoma y que detecta, explora y monitoriza la red en entornos de alto rendimiento (más de 50,000 dispositivos por cada servidor autónomo). Además de eso, Pandora FMS tiene herramientas específicas para entornos distribuidos (Export Server, Consolas en modo réplica, Metaconsola, Servidores de respaldo). Por otra parte, Nagios se puede instalar en entornos distribuidos, aunque requiere de múltiples herramientas de terceros para hacerlo posible, ya que no contempla en su propia arquitectura un contexto distribuido y descentralizado.
Cacti no se plantea estas capacidades.
Plugins y monitorización “out of the box”
Nagios necesita la instalación de muchos plugins para ser eficiente y ofrecer un conjunto de funcionalidades completas. En Cacti ocurre algo similar, aunque el tamaño de su librería de plugins y extensiones es mucho menor que el de Nagios. Tanto es así, que no hay información de cómo integrarlo con herramientas empresariales como Oracle, Exchange, Active Directory, Informix, SAP, etc.
Nagios tiene una gran librería, pero muy mal mantenida al ser todos los plugins 100% open y no tener una empresa detrás que los mantenga o gestione.
Pandora FMS tiene una librería más reducida que la de Nagios (no llega a 500 plugins), pero está atendida por una empresa, y a pesar de que algunos son Enterprise (de pago) está muy enfocada a productos “reales” del día a día y no exclusivamente a tecnología libre. La versión open de Pandora FMS viene con una colección de plugins y módulos “listos para usar” que sirven para cosas sencillas, tanto con agentes como chequeos remotos. Además, incorpora un explorador SNMP y varios wizard SNMP y WMI para monitorizar remotamente equipos de red y servidores.
Por otro lado, Cacti tiene un sistema ingenioso de plantillas que permite “reutilizar” la definición de un tipo de fuente y usarlo de forma masiva, lo que simplifica el despliegue en entornos muy similares, pero su utilidad está restringida a entornos muy homogéneos que ya conocemos.
Para monitorizar con Nagios hay que acostumbrarse a brear con cientos de scripts personalizados, que cuando los ha hecho otra persona se convierten casi en magia negra. Es muy complicado de gestionar entre diferentes personas, de manera que Nagios acaba siendo una mezcla entre software y desarrollo a medida.
Para poder sacarle el máximo partido a Nagios se necesitan entre cuatro y cinco “addons” de la comunidad (check_mk, HighCharts, OMD, NRPE, NSCA, ndoutils, thruk, nagvis), más otros proyectos complejos completos (como puppet) para gestionar las configuraciones, además de miles de líneas de scripts propios. Pandora FMS en ese sentido es una solución mucho más autónoma.
Comunidad de usuarios
Al ser Nagios el primer llegado, su comunidad es la más grande. De hecho, tiene una cantidad de forks casi infinita: OpsView, Op5, Centreon, Icinga, Naemon, Shinken. Esto implica un ecosistema caótico a la hora de implementar plugins o herramientas pasadas de uno a otro. Cada rama tiene una filosofía diferente y, con el tiempo, hace que sea totalmente incompatible con las otras ramas y con el proyecto padre (Nagios).
Cacti tiene un foro y un repositorio de plugins y extensiones, que aporta la mayor parte de funcionalidades que no vienen de serie y que mantiene un usuario de forma particular. Cacti es un sistema bastante extendido, por lo que existe una gran variedad de plantillas de dispositivos de electrónica de red.
La comunidad de Pandora FMS es pequeña pero compacta. Al menos un tercio de la librería de módulos de Pandora FMS está generada y mantenida por la propia comunidad, y existen foros que van creciendo día a día. Además, Pandora FMS cuenta con una comunidad de empresas que utilizan esta herramienta como solución profesional, y con sus peticiones para mejorar determinados aspectos del software.
Gestión y configuración
Una de las cosas que más llama la atención de Cacti en un entorno profesional es la ausencia de perfilado por grupos y permisos, lo que lo hace poco apropiado para un entorno de trabajo con operadores, clientes y gestores. La gestión de permisos es muy básica, y consiste en asignar permisos por recurso (por gráfica) a cada usuario.
Tanto Nagios como Pandora FMS tienen un sistema de perfilado de usuarios mucho más potente. Pandora FMS, en este punto, permite integrar el perfilado en un Active Directory, Ldap o SAML, reducir el número de vistas (funcionalidades) a determinados usuarios o incluso definir qué partes de un nodo son accesibles a un usuario, cosa que Nagios no es capaz de hacer.
La gestión en Cacti se limita a crear fuentes de datos (basados en scripts y/o en SNMP), gestionar gráficas, crear usuarios y poco más, es decir, es muy básica. Gran parte del trabajo de bajo nivel en Cacti se realiza desde la consola de terminal, editando ficheros de texto.
Nagios dispone de un sinfín de plugins para mejorar parte de la gestión, ya que muchos de ellos tienen su propia interfaz de gestión, e incluso su propio sistema de permisos, lo que hace que gestionar un Nagios sea como estar delante de un collage heterogéneo, incluso visualmente, que despista bastante. Pese a todo ello, Nagios va a requerir un extensivo trabajo de personalización desde la shell, editando ficheros de configuración.
Por otra parte, Nagios (y algunos forks nuevos como Naemon) siguen usando CGI’s escritos en C. Esta tecnología se inventó en los años 80, no es que la tecnología sea mala (de hecho es rápida y muy sólida), pero hace que sea complicado expandirla o mejorarla. Implica que para hacer un cambio sencillo haya que parchear el código monolítico de la arquitectura y compilar manualmente, y recordemos que el ecosistema de Nagios se basa en cientos de parches para diferentes versiones de cada Fork. Es literalmente, un bazar. Recordemos que la configuración de Nagios se basa en ficheros de texto; cada vez que haya que hacer un cambio habrá que reiniciar.
Pandora FMS es totalmente homogéneo y coherente en este aspecto. Los plugins, extensiones y tecnologías de terceros se engarzan perfectamente en la interfaz de gestión sin que podamos notar la diferencia. En Pandora FMS el 99% de la gestión se realiza desde la consola WEB, sin tener que tocar ficheros de texto o ir a la shell.
Dashboards / Paneles Visuales
Cacti en este punto es prácticamente nulo. Tanto Pandora FMS como Nagios tienen el concepto de “pantalla personalizable de usuario, aunque en Nagios es necesario usar un plugin que tiene su propia “entidad” (nagvis). En Pandora FMS este plugin viene implementado de serie, y podemos decir que es el software con el que se pueden lograr los mejores resultados:
Pandora FMS
Nagios
Cacti
Cacti no dispone de este tipo de pantallas, aunque existe alguna extensión que permite mostrar gráficas de usuario en rejillas o tablas, pero no permite la representación de estados o valores. Muy alejado de todo lo que pueden hacer Nagios o Pandora FMS.
Comparativa de Informes en Cacti, Nagios y Pandora FMS
Los informes que puede generar Nagios son muy pobres. Cacti no tiene informes de serie, y se puede decir que lo más parecido que tiene son pantallas con gráficas apiladas. No obstante, dispone de algunos plugins que realizan una funcionalidad similar a los informes de Nagios. Ninguno de ellos cuenta con el concepto de informe como “algo que entregar a un cliente o a un jefe”. Este concepto solo lo tiene Pandora FMS. Incluso en la versión gratuita tiene un generador de informes muy potente que permite personalizar los informes mucho más allá de lo que hace Nagios.
Pandora FMS
Nagios
Cacti (con el plugin de informes)
Tecnología de agentes: monitorización de servidores / APM
Aunque algunas personas consideran que la tecnología de monitorización basada en agentes está “pasada de moda”, lo cierto es que fabricantes potentes (CA, HP, IBM) a veces enmascaran sus tecnologías remotas haciéndolas pasar por 100% sin agentes, cuando lo que hacen es copiar un agente, ejecutarlo y luego borrarlo.
Para muchas tareas de monitorización sigue siendo necesario un agente en la máquina. Nagios tiene varios (NRPE, NCPA, NRDP y otros), que como casi todo en Nagios son bastante “hágaselo usted mismo”, y que en muchas ocasiones no están bien mantenidos y se han quedado desfasados. El hecho de que haya agentes diferentes para una misma plataforma es un hecho consistente en la filosofía Nagios.
Cacti no tiene agentes ni nada remotamente parecido (similar al caso de ZenOSS), mientras que Pandora FMS tiene, con diferencia, los agentes más potentes de todos ellos. Si comparamos técnicamente en detalle la cantidad y calidad de funcionalidades de los agentes de Nagios y Pandora FMS, apreciamos que Pandora FMS dispone de muchas más funcionalidades complejas “integradas” en el propio agente, tales como recolección de eventos de forma nativa (utilizamos una API que viene de Windows NT4 y asegura compatibilidad y velocidad, nada que ver con los métodos WMI), recolección de inventario, watchdog de servicios y procesos, recolección en tiempo real de caída de procesos y servicios, interfaz nativa WMI para el usuario, recogida de parámetros del performance counter, chequeos de red integrados en el agente y muchas otras funcionalidades que no pueden ser implementadas con “scripts” o comandos, ya que implican que el agente trabaje a bajo nivel, no a nivel de usuario.
El no disponer de agentes limita muchísimo las capacidades de monitorización de servidores y monitorización de aplicaciones (tanto rendimiento como gestión de estados), ya que solo dispone de interfaz SNMP (remota) y WMI (como plugin adicional).
La potencia de los agentes de Pandora FMS permite hacer un autodescubrimiento a nivel de aplicación, sacando elementos de forma dinámica, en función del host donde se despliegue, generando por tanto información en función de la configuración específica del sistema anfitrión, evitando métricas genéricas y obteniendo siempre la información más útil de forma adaptativa.
Cacti vs Nagios vs Pandora FMS: escalabilidad
El propio Cacti dice en el primer párrafo de su web: “Cacti provee un interfaz de uso fácil e intuitivo desde redes LAN hasta redes de cientos de dispositivos”. Lo que implica que no llega a miles de dispositivos, y menos aún a decenas de miles.
Si bien existen casos conocidos de instalaciones de Nagios para varias decenas de nodos, lo cierto es que en la propia web de Nagios no se pueden leer casos documentados de clientes con más de 15000 nodos. Con Pandora FMS pasa algo similar; aunque en pruebas de laboratorio se han llegado a monitorizar más de medio millón de nodos, lo cierto es que solo podemos hablar de clientes con 15,000 nodos entre nuestros casos públicos de éxito. Lo cierto es que tanto Nagios como Pandora FMS están muy por encima de los límites de Cacti.
Conclusiones de la comparativa de Nagios vs Cacti vs Pandora FMS
Pocas recomendaciones más podemos hacer tras haber explicado las principales diferencias entre estos tres sistemas, sobre todo cuando estamos hablando de estos productos en el blog de Pandora FMS.
Es importante insistir en que esta comparación se ha hecho tras la instalación de las distintas herramientas en nuestro laboratorio, y hemos intentado transmitir la visión más objetiva de los resultados obtenidos.
Esperamos que este artículo comparativo os sirva de ayuda para tomar una decisión acertada a la hora de monitorizar vuestros sistemas.
Finalmente, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.
¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí: https://pandorafms.com/es
O si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.
Además, recuerda que si tus necesidades de monitorización son más limitadas tienes a tu disposición la versión OpenSource de Pandora FMS. Encuentra más información aquí: https://pandorafms.org/es/
No dudes en enviar tus consultas. ¡El equipazo de Pandora FMS estará encantado de atenderte!
El equipo de redacción de Pandora FMS está formado por un conjunto de escritores y profesionales de las TI con una cosa en común: su pasión por la monitorización de sistemas informáticos. Pandora FMS’s editorial team is made up of a group of writers and IT professionals with one thing in common: their passion for computer system monitoring.