El objetivo de la monitorización

0

La monitorización juega cada vez un papel más importante. El número de aplicaciones que tenemos que gestionar se multiplica cada año. Y si tenemos en cuenta que las nuevas arquitecturas priman el aislamiento de funcionalidades y la reducción de dependencias, hasta llegar a los microservicios o incluso los nanoservicios, la monitorización pasa a ser un tema vital. Además, los usuarios y nuestro negocio son cada vez más exigentes con los servicios de TI. Cada vez la dependencia es mayor, sobretodo con la ola de transformación digital que nos rodea. Así no nos podemos permitir el lujo de dejar que “nos avisen si algo va mal” tenemos que detectarlo nosotros solos. Y mejor aún si somos capaces de detectarlo antes de que pase, o antes de que el servicio se degrade.

Las empresas de hoy en día se han dado, o se están dando, cuenta de lo importante que es medirlo todo. Pero rápidamente llegamos a una sobresaturación de métricas. Métricas de los servidores, como CPU, memoria, disco; métricas de los web services, como peticiones por segundo, tiempos de respuesta, número de errores; métricas de uso de las web; métricas de negocio, como número de ventas, valor de las ventas, devoluciones; … Al final cada nuevo servicio o aplicación que se implanta trae con sigo decenas o centenares de métricas. Y eso lo tenemos que multiplicar por el número de servidores, centros de datos, localizaciones en la nube, o “tenants” en nuestro negocio. En este frenesí de querer medirlo todo, Nos emborrachamos de métricas y en vez de información comenzamos a tener ruido. Gigas y gigas de ruido diario (o incluso Teras).

Mi perfil académico es de ingeniero de telecomunicaciones, y en toda comunicación hay un concepto clave: SNR (Signal-to-Noise-Ratio). O lo que sería en castellano la relación de señal a ruido.

La relación señal/ruido o S/R (en inglés signal-to-noise ratio, abreviado SNR o S/N) se define como la proporción existente entre la potencia de la señal que se transmite y la potencia del ruido que la corrompe.

Wikipedia (junio 2018)

Es decir, la información que realmente queremos recibir, versus el ruido que recibimos. Si hay mucho ruido o interferencias, tendremos una mala recepción, ya que nos molestarán a medir la señal. Esto nos pasa con las métricas de hoy en día, toneladas de métricas, que se convierten en ruido, nos bajan el SNR y nos fastidian la comunicación importante: detectar cuando algo va mal.

Y es que ese es el objetivo principal por el que llenamos de monitores con Nagios, Icingas, Kibanas y Grafanas nuestras oficinas. Es por ello que nos gastamos un importante presupuesto en servidores y almacenamiento que sólo capturan métricas en nuevos tipos de bases de datos como Elastic Search, Graphite, InfluxDB o Prometheus. Teras de disco duro que se llenan en cuestión de horas en algunos casos. Teras de señal y de ruido, mucho ruido.

Esta muy bien querer capturarlo todo. Nos irá de perlas cuando tengamos un problema y podamos recuperar todos los logs y las métricas de esa petición en concreto. Pero ¿cuál es el coste? Yo os lo digo, mucho coste en TI y sistemas de monitorización, y mucho ruido.

Hoy en día el reto ya no está en monitorizarlo todo. Está en saber qué monitorizar. Y mejor aún, como sacar partido a esa monitorización. Hace unos años tener pantallas con métricas de las aplicaciones era ser vanguardista. Ahora lo vanguardista es tener información, y no ruido, en esas pantallas. Quiero información valiosa, no datos y datos y datos. Si fuese capaz de tener una pantalla que me dijese: “Todo va bien.” y pudiese confiar ciegamente en ella, sería lo mejor que me podría pasar.

Y cuando algo vaya mal, ya no basta con una alarma que nos diga lo que va mal. Queremos que se arregle solo.

Ese es el reto al que nos enfrentamos hoy en día, tanto los equipos  de desarrollo, como los de operaciones. Porque hoy en día nuestros objetivos son los mismos. La cultura de DevOps, cada vez más necesaria, tiene este reto: Hacer sistemas que funcionen, que nos informen de lo que necesitamos saber y que sean autónomos.

¿Cómo conseguirlo? Bueno, si fuese fácil contestar a esta pregunta no sería un reto. Hay muchas tendencias: cuadros de mando jerarquizados, machine learning, sistemas de alarmas, bots automáticos… ¿Cuál es la mejor? El tiempo nos dirá.

Pero lo que sé es que tenemos que tener claro el objetivo final de toda esta vorágine de monitorización que vivimos: saber si van bien las cosas, si van a seguir yendo bien y si no, saber qué se necesita para que no vayan mal.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios