Casos de éxito
ES EN

dev

Abecedario de observabilidad: la vida de un proyecto de la A a la I.

Juan Mas Aguilar Hace 1 día Cargando comentarios…

¡Ay, la observabilidad! ¡Eso que aparece ahora tan a menudo en LinkedIn! Eso que todo el mundo dibuja en todos los proyectos como un elemento fundamental y necesario, pero que probablemente tenga el mismo éxito en su implementación que las buenas prácticas de seguridad: mal y tarde.

Como profesional de este pequeño mundo de los sistemas informáticos, últimamente me llama poderosamente la atención el aumento de iniciativas dedicadas a la observabilidad, más por la forma en que se plantean que por el hecho en sí mismo. Las conversaciones siempre empiezan por el mismo punto: ¿qué es la observabilidad y qué diferencia tiene con la monitorización tradicional? Recuerdan vagamente a los proyectos de adopción del cloud, cuando las conversaciones trataban el concepto de cloud, responsabilidad compartida y CAPEX vs OPEX.

Sin embargo, en última instancia, este tipo de proyectos no son sino un producto de la tendencia de mercado actual. Y es ahí donde quiero incidir. Merece la pena, por tanto, hacer un pequeño viaje por el panorama de la observabilidad para entender qué es la observabilidad, cómo (en mi humilde opinión) se deberían plantear este tipo de proyectos y por qué últimamente esto ha florecido como una disciplina “redescubierta”. No lo digo yo, podemos verlo, por ejemplo, en este artículo (Mok et al., 2024).

Este será el primer post de una serie dedicada al desarrollo de proyectos de observabilidad. Está orientado a todo tipo de público: tanto si eres un pobre alma en pena buscando ayuda en un aluvión de post en Medium con el objetivo de implementar observabilidad, como si eres una persona de negocio intentando entender de qué va esto y por qué se habla de ello. En el segundo post abordaremos los conceptos de la J a la R y cerraremos la serie desarrollando los que van de la S a la Z. No será una lectura de 5 minutos, pero vale la pena.

A de “¿Alguien sabe qué es esto?”

No quiero dedicar este texto a una extensa definición del concepto, han corrido ríos de tinta al respecto (Dynatrace, 2024, Splunk, n.d., Grafana, n.d.) y lo que yo aporto no es más que una vuelta más a lo mismo. Pero las costumbres y estructuras clásicas de una exposición me obligan a ello. No me miréis a mi, culpad a los lingüistas.

La realidad es que mucha gente habla de observabilidad como si fuera una novedad extraordinaria, hija de un tiempo de inteligencia artificial, automatización y agilismo recalcitrante. Nos gusta imaginarnos que nuestros sistemas se cuidan solitos y no hay llamadas a las 3 de la madrugada. La realidad es que no: la observabilidad no va de eso. Y, al mismo tiempo, sí tiene algo que ver.

PD: las llamadas no van a desaparecer.

Para entender mejor el concepto de observabilidad, mejor definámoslo formalmente en comparación con el de monitorización. De esta forma, no nos volveremos a confundir:

Viendo ambas definiciones, la conclusión es obvia: para monitorizar hay que observar. ¿Es, por tanto, algo que no hayamos hecho nunca antes? La respuesta sencilla es no. Siempre se han observado sistemas.

B de “Bueno, pero algo más tendrá”

Efectivamente. Pese a que la definición formal no deja mucho lugar a la interpretación ni al vendehumismo endémico del mercado IT, sí ha sido matizada y ampliada gracias al nuevo panorama tecnológico.

Tradicionalmente, la monitorización era sota, caballo y rey: instalabas un agente, recogías logs, alguna métrica y con algún dashboard ya tenías el chiringuito montado. Respondemos a las preguntas básicas: qué y cuándo.

Actualmente, cuando hablamos de observabilidad, queremos decir que conocemos mucho más del sistema. Podemos responder a más preguntas: dónde, cómo y por qué. La clave consiste en que la observabilidad moderna responde a estas preguntas aportando contexto, transformando los datos que recogemos en información ya útil para la compañía.

La clave no reside en la literalidad de las preguntas, sino en nuestra capacidad de obtener esta información. Al final, en estas preguntas introducimos algo propio de la monitorización (el análisis de la causa raíz) pero, gracias a una correcta política de observabilidad, podemos provocar una inversión del esfuerzo, delegando más carga al sistema.

Primer caso

Nos llega una alerta de que la máquina i12345 ha dejado de funcionar por 15 minutos. Podría llegar a informar de que ha sido por saturación de recursos y que es parte del entorno de producción.

Normalmente, el equipo técnico aporta mucho conocimiento en el análisis de la causa raíz, sabe que se trata de una máquina de producción y que en ella se aloja el backend. Conoce también la dependencia con la base de datos y el histórico (la principal fuente de conocimiento) le pone sobre la pista de que pueda haber queries lentas o algún otro tipo de problema con la base de datos.

Segundo caso

Nos llegan varias alertas (lo cubriremos más tarde, pero una correcta cobertura también es parte de la observabilidad): una relativa al nodo de computación (la máquina i1234) con saturación de recursos, otra de la aplicación (las métricas derivadas de las trazas muestran latencias y errores disparados) y otra de la base de datos (existen queries lentas). Disponemos de un mapa de componentes donde se nos muestra un aumento de la latencia y errores en las comunicaciones entre la aplicación y la base de datos. Viendo las gráficas en el tiempo, se observa que el aumento de recursos coincide con el momento en que empiezan a generarse queries.

La dependencia con la experiencia del equipo técnico se reduce, tanto las alertas como la información disponible se encuentra contextualizada en el mapa de componentes y se conoce el estado de las comunicaciones entre ellos. Además, el equipo técnico no depende tanto de su conocimiento del histórico sino que, gracias a las alertas, la trazabilidad de las queries y los logs de la aplicación es capaz de ver fácilmente la relación causa-efecto.

Pero, ¡si esto tampoco es tan complicado de hacer con lo que ya teníamos! Bueno, nadie dice que sea imposible hacerlo de la manera tradicional pero, ciertamente, requiere mucho conocimiento interno (qué máquina/contenedor corresponde a qué aplicación, con quién interactúa, etc), refactorización de las aplicaciones y tiempo. Al final, la observabilidad no es un qué, es un cómo.

La idea, por tanto, consiste en darle la vuelta. Es ahora el propio sistema el que nos va a informar de quién es y dónde se encuentra y, su entorno, el que nos va a comunicar cuándo, cómo y por qué deja de funcionar. Por lo tanto, nuestra capacidad de responder a estas preguntas va a radicar en nuestra capacidad de obtener esta información, no en nuestra capacidad de montar queries complejas en base a nuestro conocimiento del sistema. En definitiva, ahora la clave es la obtención de la información, es decir, la observabilidad.

C de “Como no me pongas un ejemplo…”

Venga, vamos a darle una vuelta más. Es importante dejar este punto claro. Propongamos un caso sencillo:

“Disponemos de una aplicación web tradicional: un frontal que llama a un backend independiente y una base de datos que almacena toda la información. Tanto el frontend como el backend se encuentran en Kubernetes, mientras que la base de datos se encuentra en una máquina virtual. El entorno es On-Premise y el frontend se expone a través de un Ingress multi-aplicación.”

En un paradigma tradicional, disponemos de un agente en los nodos de Kubernetes que nos devuelve información sobre el estado del clúster y de los nodos. Al mismo tiempo, nuestras aplicaciones generan logs que recogemos con otro agente y los almacenamos. Por último, un tercer agente se encarga de la monitorización de la base de datos. Existe, además, una última capa de cuadro de mandos y alertado.

Bien, supongamos entonces que la aplicación empieza a experimentar errores y recibimos una alerta relativa a un incremento de errores HTTP 502 Bad Gateway. Esto normalmente indica que no hay nada respondiendo al otro lado de un proxy o forwarder. Aquí es donde empieza el jaleo:

Si reflexionamos sobre todas estas preguntas, teniendo en cuenta que todas ellas llevan bajo el brazo su consiguiente investigación en los logs o métricas de cada componente, ¿cuánto tiempo estamos tardando simplemente en conocer dónde se ha generado el error?

Imaginemos, además, que la persona técnica que lleva a cabo la investigación no conoce la aplicación, puesto que el clúster es compartido por varios equipos y existen muchas aplicaciones desplegadas. ¿Cuánto le costaría a esa persona técnica simplemente tener en mente el mapa de componentes de esta aplicación en concreto? En un caso óptimo le llevaría poco tiempo porque todo el clúster y sus cargas estarían estandarizadas. En un caso más realista, le llevaría bastante más de lo que nos gustaría.

Podríamos ponernos en un caso mucho más optimista y bastante común en compañías de una cierta entidad en el que todos los componentes ya están relacionados en un cuadro de mandos y se puede ver todo de un vistazo. La pregunta entonces sería: ¿cuánto ha costado crear este dashboard? ¿Qué conocimientos y nivel de profundidad se han requerido? ¿Es industrializable? ¿Cuánto cuesta modificarlo?

D de “¿Dónde mejora el proceso?”

En el caso anterior, un perfil senior que tenga un conocimiento profundo de la aplicación y su ecosistema sería capaz de solucionar el problema de una manera, en principio, sencilla. Esta persona conoce las herramientas, sabe cómo se relacionan, tiene queries ya preparadas y sabe dónde mirar. Experiencia de perro viejo.

Sin embargo, incluso esto empieza a ir en su detrimento cuando el paisaje de aplicaciones empieza a escalar. Algunas compañías gestionan cientos de aplicaciones. ¿Podemos esperar entonces que un equipo de operaciones tenga el conocimiento de todas ellas? Eso es directamente irreal.

Como hemos comentado antes, ahora queremos darle la vuelta. Con un modelo de observabilidad bien implantado, nuestro caso cambia ligeramente.

Cada aplicación exporta logs, métricas y trazas (todo ello estandarizado). Cada log, además, incluye el ID de la traza que corresponde a la operación. Las métricas pueden incluir KPIs y pueden definir otro tipo de métricas orientadas al negocio. Todo ello es recogido de la misma manera y enviado para su procesamiento y monitorización.

La telemetría (proceso que permite recoger información de forma remota de otros sistemas) (LogicMonitor, 2024), lleva asociada una serie de metadatos relativos al origen de la misma, tales como el entorno de despliegue, el nombre del servicio o la versión. Mantenemos los agentes tanto de Kubernetes como de la base de datos. Disponemos de herramientas más potentes que nos permiten relacionar la información en base a los metadatos de la telemetría y existen nuevas formas de representar la información.

Ya solo el leerlo da la sensación de “modernidad” y “caso ideal”, ¿verdad? En el momento en el que recibamos la alerta de los errores HTTP 502, sabremos exactamente qué componente, qué aplicación emite el error, en qué entorno y, por ende, buscar el error concreto sería sencillo. ¿Quiere decir que mágicamente eliminamos la necesidad de investigar? No, ni mucho menos. Pero el conocimiento necesario para llevar a cabo la investigación se reduce significativamente (lo que ahora está de moda llamar “carga cognitiva”) y, en general, todo será mucho más ágil.

Es entonces el propio sistema el que nos está diciendo quién es y dónde le duele. La interrelación entre los distintos tipos de señales (me adelanto un poco aquí pero aguantad conmigo un poco más) nos da una ventaja que antes no teníamos: el ya mencionado contexto.

E de “En realidad no cambia tanto”

¡No! No lo hace. Si somos avispados y avispadas, nos daremos cuenta de que es en realidad un cambio en la forma de atacar el problema. Un cambio de mentalidad.

Eso no quiere decir que no lleve consigo cambios tecnológicos (depende mucho de lo que la compañía disponga en ese momento), pero las bases son las mismas. De hecho, reflexionando con tranquilidad, rápidamente se puede entender que el quid de la cuestión radica realmente en la estandarización e industrialización.

F de “Fin de la chapa. Ahora, los hechos”

Hasta aquí toda la introducción (¡y vaya introducción!) para que entendamos claramente a qué nos referimos en la actualidad con observabilidad y, sobre todo, por qué es interesante invertir en proyectos de este tipo. Hemos llegado a la conclusión de que queremos una estrategia estandarizada e industrializable que nos permita entender al máximo el estado de nuestros sistemas y aplicaciones de forma contextualizada.

No obstante, esto no es una mera cuestión técnica. El primer paso en toda iniciativa de este tipo es alinear la estrategia con la estructura interna de la compañía. Por ejemplo, no es lo mismo disponer de un solo equipo de soporte y operaciones para todas las aplicaciones que disponer de uno por aplicación. En ese sentido, debemos entender que la forma en la que planteamos todo esto debe estar gobernada y alineada con todas las áreas.

Y sí, negocio incluido. Pero de eso ya hablaremos más adelante.

No tiene sentido lanzarnos a tirar líneas de código o a montar dashboards sin tener claro lo que queremos conseguir. Establezcamos por tanto las líneas de trabajo fundamentales en las que nos vamos a basar para desarrollar toda la estrategia (y cada una requerirá de actores distintos):

Identificadas todas, la implementación tecnológica será rápida y ajustada a las expectativas. Además, permitirá hacer mejores estimaciones tanto en tiempo como en coste.

G de “Genial, lo que tú digas. ¿Por dónde empezamos?”

Como todo en la vida, depende. Y la respuesta no es sencilla. En el panorama actual, es complicado que una compañía apueste por una implementación “de cero”. Normalmente, disponen de herramientas consolidadas (algunas de ellas con licencias a largo plazo) que no pueden o no están dispuestas a sustituir. En ese sentido, es importante entender el punto en el que está la compañía y la capacidad que puede tener de adoptar este tipo de forma de hacer las cosas.

Por ello, una herramienta muy extendida es un modelo de madurez. Este tipo de modelos nos van a permitir:

Quiero lanzar un aviso: no existe un modelo unificado. Muchos actores del sector han liberado sus propios modelos de madurez para ayudar a las empresas a adoptar sus productos. Casi todos coinciden en las bases, pero difieren en el número de estados y la forma de medirlos. Repasemos algunos de ellos:

El panorama en este sentido es abrumador. Resulta complicado elegir un modelo, y muchas veces cuesta mucho definir los criterios de evaluación.

H de “Hay que elegir uno, queda claro. Pero, ¿cuál?”

En Paradigma Digital hemos participado en varias iniciativas de esta índole y, en los últimos tiempos, hemos propuesto un modelo de madurez propio basado en una mezcla del estado del arte (no queremos reinventar la rueda) y nuestra propia experiencia. Usaré este modelo para adentrarnos en el reto de la implementación de una estrategia de observabilidad (sí, sí, usad el que queráis, los conceptos que subyacen son los mismos). Las fases serían las siguientes:

Para ello, revisaremos estado por estado el modelo, indicando qué características técnicas dispone y qué capacidades aporta a la compañía en todos sus niveles.

I de “Iniciando motores”

Como hemos comentado anteriormente, la implementación de un proyecto de observabilidad organizacional depende directamente del estado inicial en el que se encuentre la compañía. Con el objetivo de poder analizar un caso completo, diremos que nos encontramos en el primer estado de todos: monitorización tradicional.

Las empresas en este estadio suelen plantear una situación como la siguiente:

Por desgracia, en este estado es en el que se encuentran la gran mayoría de las empresas. Muchas de ellas sí pueden disponer de algunas características más avanzadas, pero normalmente se basan fuertemente en desarrollo propios o ad-hoc. El problema de este tipo de situaciones es la no cobertura de todo el catálogo de sistemas y aplicaciones y la falta de control sobre lo que se observa y lo que no. Adicionalmente, las métricas que se recogen suelen ser de infraestructura, dejando toda la carga de monitorización del comportamiento de la aplicación al logging.

Habitualmente, también nos encontramos con que cada solución es observada y monitorizada de una forma pensada únicamente para ella. Esto suele provocar salidas a producción sin una cobertura mínima razonable de monitorización debido a la lentitud en la adopción del stack que se esté utilizando. Muchas veces, incluso se requiere de scripting personalizado para generar y mandar la telemetría.

En última instancia, solemos encontrarnos con un puñado de aplicaciones que tienen una monitorización sólida más por la longevidad y criticidad de las mismas que por la (no) estrategia de observabilidad de la compañía, dejando atrás a otra miríada de aplicaciones más pequeñas que pueden llegar incluso a no ser observadas en absoluto.

¿Cómo empezar entonces nuestro camino hacia la observabilidad moderna? La respuesta es sencilla y, al mismo tiempo, de un calado enorme: sentando las bases. Soy consciente de que suena obvio, pero el siguiente escenario en nuestro modelo de madurez es la observabilidad fundacional, por lo que lo primero que debemos hacer es enfrentarnos a un rediseño de los fundamentos.

¡Pero si estamos en el final del post! ¿Y el resto? Bueno, ya hemos mencionado que esto es una serie de post, siendo este el primero. En el siguiente continuaremos nuestro viaje, identificando qué elementos debemos tener en cuenta para diseñar la estrategia fundamental que queremos implementar.

¡Nos vemos pronto! 😉

Referencias

Juan Mas Aguilar

Curioso, motivado y con más preguntas que respuestas en el vasto mundo de la arquitectura de sistemas. Disfruto investigando nuevas formas de hacer las cosas con el objetivo de hacer la vida fácil a todas las personas que usan las plataformas.

Ver más contenido de Juan.

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete