Las buenas prácticas en el monitoreo empiezan mucho antes de elegir o implantar una herramienta. No se trata de reglas fijas sino de una forma de trabajo y de entender cómo usar un software de monitoreo. Todo esto se aplica a cualquier software, sea este Tivoli, OpenView, Spectrum, Zabbix, Nagios, Pandora FMS o ZenOSS.

Algunas herramientas de monitoreo serán más flexibles y permitirán que el proceso sea más fácil de implementar y otras nos forzarán a hacer las cosas a su manera, impidiendo que se adapten a nuestra filosofía. A través de nuestra experiencia de muchos años en diferentes tipos de empresas que trabajan con diferentes aplicaciones, hemos creado nuestra pequeña guía de buenas prácticas de monitorización, un planteamiento que esperamos os ayude en vuestro trabajo del día a día.

Fase 1. Identificando los problemas cuando estos suceden.

Identificar tus activos
Esto incluye todo aquello susceptible de ser monitorizado. Deberás establecer una jerarquía, ya que existen relaciones entre los diferentes elementos. Por ejemplo, la relación entre elementos clave, como las bases de datos y los sistemas que los alimentan. Un fallo en la BBDD afectará a todo. Esto debes tenerlo en cuenta.

Identifica qué debe ser monitorizado y que no ¿cómo hacerlo?, por criticidad. Añade en esa lista, una columna nueva, que sea criticidad. Esto te ayudará a empezar pues puede que te salgan varios cientos de elementos a ser monitorizados. Deberías empezar por lo que es verdaderamente crítico.

Si tienes una política de seguridad, puedes “canibalizar” esa lista ya que en ella encontrarás cosas tan importantes como las bases de datos de negocio, los backups y los sistemas críticos de infraestructura. Todos esos elementos son los primeros que deberías monitorizar.

Clasificar tus activos
Una vez que tienes la lista y un campo de importancia para cada elemento, céntrate en los elementos críticos y en aquellos que están relacionados. Por ejemplo, una base de datos crítica dependerá del sistema base, que a su vez tendrá memoria, disco y CPU. Todos esos elementos son críticos por “relación directa” con el elemento.

Puedes crear una jerarquía de elementos que te ayudará a entender cómo se relacionan estos, por ejemplo:

Traducido en algo puramente técnico podría escribirse como:

● Verificación de servicio accesible (Puerto TCP o transacción WEB)
● Proceso de aplicación, que esté activo, recursos RAM / CPU
● Consumo CPU del SO base, RAM libre en el SO base, Disco libre en el SO base.
● Estado general de la máquina: Load Average, Tráfico de red.
● Conectividad básica de la máquina (ping)

Esto se debería agrupar en un único elemento de forma que de “un vistazo” se pueda ver fácilmente. Hay muchas formas de agruparlas, por servicio, por tecnología o por origen (nodo/agente), todo dependerá de si el servicio es más o menos complejo y forma parte de un cluster. En cualquier caso cada aplicación dispone de diferentes formas de hacerlo. En Pandora se puede hacer utilizando servicios, grupos o tags.

Definir qué hacer cuando hay problemas
Este punto suele pasar desapercibido y es esencial en nuestras buenas prácticas de monitoreo. ¿De qué sirve si detectamos los problemas, incluso antes de que ocurran, si no lo notificamos eficazmente?. La monitorización de un entorno complejo puede ser muy extensa. Incluso a través del sistema de gestión por excepción (gestion por eventos), corremos el riesgo de no identificar los problemas urgentes de forma rápida y eficaz.

Ya tenemos una lista de servicios críticos, y los elementos que incluyen, el siguiente paso en nuestras buenas prácticas de monitoreo es el de identificar un responsable que pueda actuar rápidamente cuando un problema lo afecte. Aquí podemos elegir el método de notificación (email, SMS, mensaje emergente vía app) y el grado de escalado, en función de a qué elemento afecte dentro del servicio, o la recurrencia de la alerta. En resumen, notificaremos cuando la CPU del sistema base del servicio se pone muy alta a un operador, y por SMS al responsable del servicio cuando este no responda.

Categorizar las alertas
Es muy importante definir de todas las alertas que queremos destapar y la categoría de la misma con el fín de evitar alarmar por cosas innecesarias y que nuestros soportes sepan con que criticidad atender cada tipo de alertas. A priori podríamos clasificar nuestras alertas en los siguientes grupos: Crítico, Warning y Mensaje.

Hasta aquí, hemos pasado por tres puntos: Enumerar activos, clasificar servicios y criticidades y definir responsables y métodos de comunicación. Todo esto a través de una hoja de cálculo por lo que hasta el momento, todas estas buenas prácticas de monitoreo son útiles paracualquier herramienta de monitoreo. Dedicar tiempo a hacer esto antes de empezar a implementar la monitorización nos asegurará lo siguiente:

1. Nos evitará pasar por alto la monitorización de elementos relevantes de nuestros sistemas. Es decir, cuando haya problemas podremos estar seguro de que no puede ocurrir nada realmente grave sin que seamos conscientes de ello. Esto es una de las cosas más importantes, ya que nos permitirá “fiarnos” de nuestra propia monitorización. No hay nada peor que algo malo ocurra y nos demos cuenta de que ha sido culpa nuestra por no monitorizarlo.
2. Cuando algo malo ocurra, tendremos datos relativos al problema, fáciles de acceder e interpretar porque se decidió tomar información del servicio en conjunto y no de forma aislada. Esto ayudará a determinar la causa del problema (root cause analysis) de una forma natural, definida por nosotros mismos, sin depender de la supuesta magia que ofrecen algunos fabricantes.
3. Cuando suceda un problema, las partes implicadas ya estarán implicadas e informadas. No perderemos tiempo informando del problema, sino que trabajaremos directamente en la solución.
4. Ofrecer únicamente la información necesaria. Esto es especialmente importante, ya que si tenemos toda la pantalla en rojo, mezclando alertas irrelevantes con alertas críticas, nos costará mucho determinar el origen del problema y nuestra respuesta no será ni rápida ni eficiente. El exceso de información puede ser incluso más dañino que la falta de la misma.

Una vez definido el método de trabajo, se puede aplicar esta metodología descomponiendo el problema general (la monitorización de toda la organización) por partes, como haría cualquier ingeniero competente: podemos hacerlo por servicios, por criticidades, por tecnologías, por departamentos, por ubicaciones geográficas, etc.

Fase 2. Identificando los problemas antes de que sucedan.

Una vez que tenemos lo básico, que es identificar sin género de duda cuando sucede algo malo, podemos afrontar en una segunda fase, algo mucho más difícil, que es determinar cuando se acerca un problema. Esta funcionalidad, junto a la de detectar la causa de los problemas de forma automática y la de configurar las herramientas de monitoreo de forma automática (umbrales inteligentes, monitorización dinámica, correlación de eventos, big data monitoring, etc), son las funcionalidades más perseguidas por cualquier software de monitoreo.

En nuestras buenas prácticas de monitoreo debemos tener mucho cuidado con los falsos positivos y los falsos negativos, los cuales empiezan a surgir cuando dejamos que el sistema interprete los datos. Estos resultados pueden provocarnos que malinterpretemos una situación compleja y tomemos malas decisiones. Todos los operadores con el tiempo desarrollan un instinto basado en su conocimiento de lo que es normal y lo que no lo es, es decir, no pueden decir que algo esté mal, pero pueden tener la intuición de que algo no está bien.

Con esto, si queremos insistir en que aún nadie ha conseguido la automatización completa y siempre recomendamos a nuestros usuarios y clientes que utilicen mucho la cabeza y no busquen la automatización extrema, la cual puede llevar a diferentes errores que sólo saldrán cuando tengamos un gran problema en nuestras instalaciones y ya quizás sea demasiado tarde.

Monitorización por intuición es un término que todavía no he oído, si siquiera en boca de los analistas de Gartner, pero todo llegará.

¿En qué consiste la monitorización por intuición?

Hay dos formas de hacerlo, la pseudo automatizada o la puramente visual. En la primera, definiremos pequeñas alertas que nos avisen cuando algo se sale de los umbrales operativos “normales”. No significa que entren en umbrales “dañinos” o de error, simplemente que entran en umbrales diferentes a lo normal. Para eso deberemos crear una categoría de alertas como comentábamos en la primera fase que deje bien claro que no son problemas, sino cosas sospechosas, eliminando el concepto de “criticidad” en ellas, para que en caso de tener muchos eventos de todo tipo, estos sean fáciles de ocultar si es preciso.

La otra manera es crear cuadros de mando, pantallas o dashboards (cada herramienta tiene su propia forma de venderlo) que deben servir para poner en una pantalla muy grande un montón de gráficas en tiempo real. Un operador que mire siempre las mismas pantallas, en el mismo orden, con el tiempo adquiere la habilidad innata de decir “algo no va bien”.

Herramientas imprescindibles

No voy a hablar de aplicaciones, si no de funcionalidades que son imprescindibles a la hora de implementar cualquier monitorización útil para una organización que se tome en serio la operación.

Los elementos imprescindibles en cualquier software que se precie son los siguientes:

● Alertas. Deben de permitir un escalado, una agrupación de elementos (correlación) y la definición de acciones complejas (más allá de enviar un email o un SMS). Hoy día que muchas organizaciones trabajan con herramientas colaborativas (como Slack o Whatsapp), la capacidad de insertar un evento en un grupo, incluyendo una gráfica y una descripción del problema junto con un enlace directo a la monitorización, permite una respuesta mucho más rápida que un simple SMS.
● Gráficas. Deberían ser una herramienta, no algo estático, es decir, deben ser filtrables, estrujables, se deben poder combinar dinámicamente con otras series de datos, poder ver la evolución detallada a lo largo de grandes períodos de tiempo, que se puedan comparar con valores en intervalos similares de otros meses, etc. Las gráficas son la principal fuente de análisis numérico de que disponemos. Una gráfica aporta muchísima información de forma muy fácil. Un sistema con gráficas estáticas puede ser bonito, pero no útil.
● Logs. El siguiente paso ante un problema o la sospecha de un problema es analizar la información en bruto. Esto puede ser simplemente tablas de datos o datos en crudo del sistema (entradas de log). En caso de ausencia de estos datos, estamos limitados a gráficas y eventos.
● Acceso directo a la fuente. Esto ya se excede de lo que sistema de monitorización hace por lo general. Pero si tenemos información precisa (alertas), series de datos que nos ayudan a entender el comportamiento (gráficas) y datos concretos que ayudan a concretar nuestro análisis (logs) el siguiente paso lógico es acceder directamente al sistema que genera toda es información. Que una herramienta de monitorización nos permite acceder fácilmente a ese sistema es el cierre del círculo.

Esperamos que con este artículo de buenas prácticas de monitoreo os hayáis hecho una mejor idea de como llevar a cabo una buena monitorización. Para cualquier necesidad que tengáis no dudéis en contactarnos y estaremos encantados de responder a vuestras dudas.

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 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 sólo 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 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 al 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.

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 Nagios, ya que este, aunque presenta una compleja configuración, esta  está 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.

https://www.zenoss.com/sites/default/files/documentation/Zenoss_Core_Installation_Guide_r5.0.x_d1051.15.343.pdf

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í, sino 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 como 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, 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, reusando 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 como 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, y muy por encima de las que Nagios permite.

Gestión de eventos

ZenOSS, como Pandora 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 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:

La filosofía respecto a grandes despliegues (8000 nodos o más) es similar entre Pandora 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 orientada 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 que sean onmipotentes 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 como 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 pesada para el uso diario. No es fluida.

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 agente 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.