Comunidad Redes Tecnología

Buenas Prácticas de monitoreo

agosto 10, 2016

Buenas Prácticas de monitoreo

El post está disponible también en : Inglés

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:

buenas practicas monitoreo

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.


    Written by:



    One comment
    1. Jimmy Olano

      Muy importante estos artículos teóricos que cimentan la práctica diaria. Nunca debemos perder de vista estos objetivos y consideraciones y debemos siempre aplicarlo en cada esquema de monitorización que implantemos.

    Leave a comment

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.