Zenoss vs Nagios vs Pandora FMS; una comparativa
En este artículo realizaremos otra comparativa que esperamos os ayude a poder tomar una decisión. Hoy en día la comparativa más común es la de nagios vs zabbix (la cual os recomendamos leer antes de profundizar en este artículo), debido a que Nagios ha sido durante muchos años el principal software de monitorización y ahora está perdiendo terreno frente a otros sistemas, siendo Zabbix uno de los que más está proliferando.
En esta ocasión, nos vamos a encargar de dar ayudar a aquellos administradores o profesionales IT que están buscando alguna alternativa a su Nagios o su Zenoss y buscan una comparación de estas dos herramientas de monitorización.
El objetivo de nuestras comparativas es dar una visión objetiva de las herramientas comparadas, pero añadiendo en la comparativa a Pandora FMS, para que podáis comprobar las funcionalidades y capacidades de esta herramienta, nuestra herramienta (esperamos nos permitáis esta licencia).
El resultado final
Para los que tengáis mucha prisa, a continuación os mostramos el resultado de nuestro análisis. Si queréis más detalle solo tenéis que seguir leyendo.
¿Cómo se ha realizado la comparativa de Zenoss vs Nagios?
Para realizar esta comparativa hemos montado en nuestro laboratorio dos máquinas, instalando una herramienta en cada máquina. A partir de ahí hemos empezado a monitorear nuestros sistemas y hemos probado las funcionalidades que creemos son más importantes en un software de monitoreo.
Zenoss vs Nagios vs Pandora FMS
ZenOSS representa la alternativa a NetCool, más que la alternativa a productos basados en agentes como Nagios, Zabbix o Pandora FMS. Ubicado en Austin (Texas) ZenOSS pretende ser líder en innovación en un campo de TI que está muy trillado, ITOM (IT Operation Management), apostando por lo que en su día alguien dijo que sería el futuro: la monitorización sin agentes.
Es cierto que la utilización de agentes representa cierta resistencia: hay que instalarlos al fin y al cabo. Por esta razón, en muchas ocasiones la utilización de agentes presenta una gran desventaja al tener que realizar un despliegue inicial. Lo que no se suele decir es que, para que sistemas supuestamente sin agentes como NetCool o ZenOSS funcionen, hay que configurar dichos sistemas. Lo que incluye a menudo acceder remotamente y, en muchos casos, activar o instalar componentes de software en nuestros sistemas que antes no teníamos. Mucho trabajo para que tengamos solo una fracción de la información que podríamos tener con agentes. En la monitorización sin agentes debemos tener muy en cuenta los siguientes factores, que en ocasiones pueden generar muchos problemas: que la carga en el sistema es igual o superior que con un agente y que la seguridad se puede ver comprometida, ya que se requiere que un sistema externo acceda a la máquina anfitrión para sacar información, sea por WMI, SNMP o ejecuciones remotas (SSH generalmente). Para poder obtener determinada información,no queda más remedio que ejecutar comandos; en Windows activando el subsistema WinRM que permite ejecuciones remotas. NetCool, por ejemplo, copia una especie de agente “personalizado” cada X tiempo, lo ejecuta y luego lo borra. Frente a eso, los agentes de Pandora FMS no permiten conexiones entrantes; eso es mucho más seguro que activar la ejecución remota en cada servidor.
¿Quieres conocer Pandora FMS Enterprise?
Visita nuestra Home y descubre el software de monitorización más flexible del mercado, capaz de monitorizar dispositivos, servidores, aplicaciones, servicios y procesos de negocio
Zenoss vs Nagios en la configuración a bajo nivel. Un comienzo difícil
Aunque ZenOSS se vende como una herramienta muy visual, lo cierto es que la instalación y post-configuración están llenas de ficheros de texto, comandos arcanos y muchísimas interacciones con diferentes piezas del sistema operativo y aplicaciones de terceros. Solo hay que ver la documentación para darse cuenta que hay más “pantallazos” de la consola y ficheros de texto que pantallas visuales. En esto ZenOSS es peor que en Nagios, ya que este, aunque presenta una compleja configuración, la tiene muy centralizada. No hay tantos sitios diferentes donde tocar. Comparado con Pandora FMS, que tiene un sistema centralizado y un diseño mucho más sencillo, uno se pregunta por qué la gente de ZenOSS sigue diciendo de sí mismos que quieren ser la herramienta de monitorización más sencilla de usar.
En este enlace (la documentación de instalación oficial de ZenOSS) podemos ver lo complejo que es y la cantidad de ficheros, comandos de consola y diferentes subcomponentes que deberemos tocar.
Muchos usuarios huyen de las configuraciones complejas. A veces es cierto que una buena expresión regular puede ser la solución más compacta y precisa. Pero ZenOSS se pasa; desde la Universidad yo no había oído hablar de la Notación Polaca Inversa para definir una operación. ZenOSS la usa para postprocesar valores. Muy preciso. Quizás haya que tener título universitario para usar ZenOSS.
Flexibilidad y crecimiento en la monitorización. Monitorización para todo. Sí, todo con ZenPacks
Es fácil decir que existe monitorización para cualquier cosa… que tenga un zenpack, sí, si no usted mismo puede fabricarse un ZenPack, siempre que se estudie a fondo la documentación de cómo hacerse ingeniero de ZenPacks. A diferencia de Nagios o Pandora FMS, para implementar pequeños chequeos hay que hacerlo siguiendo unas directrices muy estrictas y aprender una tecnología bastante encorsetada.
Esto último, combinado con la ausencia de agentes, se hace cuesta arriba cuando es necesario obtener información de sistemas. El manual de ZenOSS explica cómo conectarte a esos sistemas por terminal y cómo se deben configurar para que reporten información de manera remota. Es cierto que, en un mundo ideal, si se configurara como es debido todos los sistemas estos serían siempre monitorizables de forma remota. Pero el mundo real está lleno de problemas y, sobre todo, de la necesidad de aprovechar mejor nuestro tiempo que no añadiendo configuraciones al fichero snmpd.conf de nuestros Linux.
Frente a la alegre anarquía de Nagios y la flexibilidad de Pandora FMS, en ZenOSS prima la rigidez de su planteamiento. Es cierto que una vez definida la forma de monitorizar, definido el modelo y la jerarquía de elementos, identificados los flujos de información, configuradas las diferentes fuentes de datos y ajustados otros cientos de detalles, ZenOSS puede hacer una aproximación mejor que los otros dos al santo grial del “Análisis de causa raíz” (detectar qué problema hay y la causa del mismo) que se lleva persiguiendo tanto tiempo en la monitorización, pero a costa de un corsé demasiado rígido que impide que el día a día de la realidad de un equipo de operación pueda sacar las cosas con holgura. Además de un ZenOSS necesitarán una formación, tiempo para planificación, un pequeño equipo de desarrollo que les ayuden a fabricar sus propios ZenPacks y un equipo de ingenieros que mantenga el monstruo. Al menos para hacerlo “bien”, tal como recomiendan. Por supuesto, siempre existen caminos intermedios, atajos, y en casos extremos, formas de doblar las esquinas.
Zenoss vs Nagios atendiendo a la Integración con terceros
La integración con herramientas de terceros es vital en toda herramienta de monitorización, pues uno de los objetivos de estas herramientas es el de poder ir incluyendo en el mismo panel de monitorización el mayor número de herramientas posibles a monitorizar. En Zenoss destacamos una gran rigidez a la hora de integrar la herramienta con aplicaciones de terceros, tanto en la forma de obtener información (a través de procesos complejos, definidos por el usuario, con herramientas previas) como a la hora de producir resultados (notificaciones) en terceras partes, rehusando tecnología de terceros. Las herramientas de que dispone ZenOSS -porque, en teoría, se puede hacer de todo- son inflexibles y establecen de forma sistemática cómo se tiene que hacer cada cosa, de forma que tareas muy sencillas, como interactuar con una BBDD externa a la hora de notificar un problema, puede ser mucho más complejo que un simple script de cuatro líneas, tal como se resolvería en Nagios o Pandora.
No obstante, es cierto que ZenOSS dispone de una api de tipo rest (JSON API) que permite integraciones de una forma similar a las de Pandora FMS, y muy por encima de las que Nagios permite.
Gestión de eventos
ZenOSS, como Pandora FMS, se nota que han “bebido” de las mismas fuentes a la hora de trabajar con eventos, cosa que ni Zabbix, ni Nagios ni otras herramientas han hecho. La influencia de gestión de eventos de plataformas tradicionales como Tivoli o Patrol se notan: autovalidación, gestión de ciclo de vida del evento, iteración con workflows, notificaciones y correlación son algunas de las cosas que ZenOSS y Pandora FMS resuelven de formas bastante similares.
Zenoss vs Nagios en cuanto al Escalado y Arquitectura
La Naturaleza es sabia. Por eso encontramos muchas curvas en la Naturaleza, la evolución hace que las formas que mejor se adaptan al entorno sobrevivan. Por eso encontramos diseños similares en diferentes puntos del planeta. Lo mismo ocurre con la arquitectura para grandes entornos de ZenOSS y Pandora FMS:
La filosofía respecto a grandes despliegues (8000 nodos o más) es similar entre Pandora FMS y Zenoss, quedando Nagios fuera de juego. Ambos, ZenOSS y Pandora, aseguran a través de casos de éxito, con nombres y apellidos, el éxito del despliegue en entornos de producción con cifras mareantes. Nagios se queda nuevamente fuera.
Zenoss vs Nagios en Gráficas e Informes
A nivel de gráficas ZenOSS y Pandora FMS son muy similares, ofreciendo al usuario final no solo capacidad para ver datos de forma gráfica sino para utilizar el motor gráfico y los datos almacenados como una herramienta de análisis en tiempo real, algo muy por encima de lo que Nagios puede hacer.
Desde el punto de vista de Informes, ZenOSS vuelve a aplicar una filosofía demasiado técnica. Permitiendo al administrador crear informes definidos en base a las “clases” de objetos, y filtrando los resultados a través de expresiones TALES (algo similar a una expresión regular), ofreciendo informes útiles para técnicos. Desde este punto de vista, ZenOSS ofrece una interfaz para técnicos e informes para técnicos. Falla, ya que no permite que un usuario sin conocimientos profundos del sistema pueda generar un informe, ni que dichos informes puedan ser interpretados por un gestor o un cliente final. Pandora FMS está pensado para ofrecer una interfaz de creación de informes para clientes finales y los informes finales se pueden presentar tal cual -directamente en PDF en el buzón del cliente- ya que fue el propósito del sistema de informes desde el principio. Nagios en este punto está bastante por detrás tanto de ZenOSS como de Pandora FMS.
Gráfico de informe en Zenoss:
Gráfico de informes en Nagios (Highcharts):
Gráfico de informes de Pandora FMS:
Unificación de la monitorización
Este es uno de los puntos fuertes de ZenOSS. Su arquitectura distribuida y su conjunto de tecnologías orientadas al mundo corporativo permite que pueda utilizarse en redes complejas, distribuidas geográficamente, monitorizando además aplicaciones de negocio, servidores, entornos virtuales, operando en entornos híbridos locales/cloud. Ofrece diferentes dashboard y pantallas resumen que le permiten presumir de estas capacidades, similares a las de Pandora FMS pero muy por encima de la pobre integración de Nagios, que no puede aspirar a monitorizaciones de red complejas, aplicaciones de negocio complejas o entornos híbridos.
Monitorización predictiva
Al igual que los sistemas de CA e IBM, ZenOSS apuesta por lo que ellos llaman análisis predictivo y sistemas heurísticos de detección de causa raíz. La magia, en este caso, se basa en la definición previa y clasificación de todos los activos en una serie de clases relacionadas. Es un sistema muy bien diseñado y que aporta un orden necesario muchas veces, pero que por otro lado hace que el despliegue pueda ser muy complejo, ya que obliga a los que despliegan la monitorización a que sean omnipotentes y conozcan muy bien el sistema que necesitan monitorizar, cosa que en el mundo real -a no ser que cuentes con un sistema muy pequeño- no suele suceder.
El gráfico de dependencias -parte de la esencia de su magia para análisis de causa raíz- es un gráfico muy bonito basado en flash, que permite ver cómo los sistemas están conectados pero no muestra ninguna información adicional además de si están vivos o no. Hacer click tampoco te lleva a ningún lado, es decir, no es demasiado útil para el día a día.
Resumen final de la comparativa Zenoss vs Nagios vs Pandora FMS
El interfaz gráfico de Zenoss es visualmente atractivo pero resulta ser un poco pesado para el uso diario. No es fluido.
El descubrimiento automático que prometen solo funciona bien para entornos de red con rutas estáticas, file systems e interfaces de red. Todo lo que no es obvio toca describirlo a mano. Al ser remoto suele ser un proceso doblemente tedioso que si fuera basado en agentes y tuviera acceso real al SO, no a través de interfaces remotas WinRM o SNMP.
Al estar diseñado para no usar agentes, sus capacidades SNMP, WMI y de ejecuciones remotas son muy potentes, configurables y bien probadas pero, de nuevo, requieren que en el otro extremo permitan acceso completo a ZenOSS.
Antes de despedirnos, ¿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.
