En ingeniería de software , más específicamente en computación distribuida , la observabilidad es la capacidad de recopilar datos sobre la ejecución de los programas, los estados internos de los módulos y la comunicación entre los componentes. [1] [2] Para mejorar la observabilidad, los ingenieros de software utilizan una amplia gama de técnicas de registro y seguimiento para recopilar información de telemetría y herramientas para analizarla y utilizarla. La observabilidad es fundamental para la ingeniería de confiabilidad del sitio , ya que es el primer paso para clasificar una interrupción del servicio. Uno de los objetivos de la observabilidad es minimizar la cantidad de conocimiento previo necesario para depurar un problema.
El término proviene de la teoría de control, donde la " observabilidad " de un sistema mide qué tan bien se puede determinar su estado a partir de sus resultados. De manera similar, la observabilidad del software mide qué tan bien se puede entender el estado de un sistema a partir de la telemetría obtenida (métricas, registros, rastros, perfiles).
La definición de observabilidad varía según el proveedor:
una medida de qué tan bien puedes entender y explicar cualquier estado en el que pueda llegar tu sistema, sin importar cuán novedoso o extraño sea [...] sin necesidad de enviar código nuevo
— Panal [3]
Herramientas y prácticas de software para agregar, correlacionar y analizar un flujo constante de datos de rendimiento de una aplicación distribuida junto con el hardware y la red en la que se ejecuta.
— IBM Instana [4]
La observabilidad comienza enviando todos sus datos sin procesar al servicio central antes de comenzar el análisis.
— Delta del borde [5]
la capacidad de medir el estado actual de un sistema en función de los datos que genera, como registros, métricas y seguimientos
—Dynatrace [6 ]
La observabilidad es una herramienta o una solución técnica que permite a los equipos depurar activamente su sistema. La observabilidad se basa en la exploración de propiedades y patrones no definidos de antemano.
— Nube de Google [7]
Recopilar, visualizar y aplicar inteligencia de manera proactiva a todas sus métricas, eventos, registros y rastros, para que pueda comprender el comportamiento de su complejo sistema digital
— Nueva Reliquia [8]
El término se suele mencionar como su numerónimo o11y (donde 11 representa el número de letras entre la primera y la última letra de la palabra). Esto es similar a otras abreviaturas de la informática como i18n, l10n y k8s . [9]
A veces, los términos observabilidad y monitoreo se usan indistintamente. [10] A medida que las herramientas, las ofertas comerciales y las prácticas evolucionaron en complejidad, el término "monitoreo" pasó a denominarse observabilidad para diferenciar las herramientas nuevas de las antiguas.
Los términos se contrastan comúnmente en que los sistemas se monitorean utilizando conjuntos predefinidos de telemetría , [7] y los sistemas monitoreados pueden ser observables . [11]
Majors et al. sugieren que los equipos de ingeniería que sólo cuentan con herramientas de monitoreo terminan confiando en el conocimiento previo de los expertos (antigüedad), mientras que los equipos que cuentan con herramientas de observabilidad dependen del análisis exploratorio (curiosidad). [3]
La observabilidad se basa en tres tipos principales de datos de telemetría: métricas, registros y rastros. [6] [7] [12] A estos se los suele denominar "pilares de la observabilidad". [13]
Una métrica es una medida puntual ( escalar ) que representa un estado del sistema. Algunos ejemplos de métricas comunes son:
Las herramientas de monitoreo suelen estar configuradas para emitir alertas cuando ciertos valores de métricas exceden los umbrales establecidos. Los umbrales se establecen en función del conocimiento sobre las condiciones normales de funcionamiento y la experiencia.
Las métricas normalmente están etiquetadas para facilitar la agrupación y la búsqueda.
Los desarrolladores de aplicaciones eligen qué tipo de métricas utilizar para instrumentar su software antes de lanzarlo. Como resultado, cuando se encuentra un problema previamente desconocido, es imposible agregar nuevas métricas sin enviar código nuevo. Además, su cardinalidad puede hacer que el tamaño de almacenamiento de los datos de telemetría sea prohibitivamente caro rápidamente. Dado que las métricas están limitadas por la cardinalidad, a menudo se utilizan para representar valores agregados (por ejemplo, tiempo promedio de carga de página o promedio de 5 segundos de la tasa de solicitudes). Sin un contexto externo, es imposible correlacionar eventos (como solicitudes de usuarios) y valores de métricas distintos.
Los registros, o líneas de registro, son generalmente bloques de texto no estructurados y de formato libre [ aclaración necesaria ] que están pensados para que sean legibles por humanos. Los registros modernos están estructurados para permitir el análisis por máquina. [3] Al igual que con las métricas, un desarrollador de aplicaciones debe instrumentar la aplicación por adelantado y enviar código nuevo si se requiere información de registro diferente.
Los registros suelen incluir una marca de tiempo y un nivel de gravedad. Un evento (como una solicitud de usuario) puede estar fragmentado en varias líneas de registro y entrelazarse con registros de eventos simultáneos.
Una aplicación nativa de la nube generalmente se compone de servicios distribuidos que, en conjunto, cumplen una única solicitud. Un rastro distribuido es una serie interrelacionada de eventos discretos (también llamados intervalos) que rastrean la progresión de una única solicitud de usuario. [3] Un rastro muestra las relaciones causales y temporales entre los servicios que interactúan para cumplir una solicitud.
Instrumentar una aplicación con rastros significa enviar información de intervalos a un backend de rastreo. El backend de rastreo correlaciona los intervalos recibidos para generar rastros presentables. Para poder seguir una solicitud a medida que atraviesa múltiples servicios, los intervalos se etiquetan con identificadores únicos que permiten construir una relación padre-hijo entre ellos. La información de intervalos se comparte normalmente en los encabezados HTTP de las solicitudes salientes. [3] [14] [15]
La creación de perfiles continuos es otro tipo de telemetría que se utiliza para determinar con precisión cómo una aplicación consume recursos. [16]
Para poder observar una aplicación, es necesario recopilar o exportar telemetría sobre su comportamiento. La instrumentación implica generar telemetría junto con el funcionamiento normal de la aplicación. [3] Luego, un backend independiente recopila la telemetría para su posterior análisis.
En sistemas que cambian rápidamente, la instrumentación en sí misma es a menudo la mejor documentación posible, ya que combina la intención (¿cuáles son las dimensiones que un ingeniero nombró y decidió recopilar?) con la información actualizada en tiempo real del estado en vivo de la producción. [3]
La instrumentación puede ser automática o personalizada. La instrumentación automática ofrece una cobertura total y un valor inmediato; la instrumentación personalizada aporta un valor mayor, pero requiere una participación más íntima con la aplicación instrumentada.
La instrumentación puede ser nativa (realizada dentro del código, modificando el código de la aplicación instrumentada) o fuera del código (por ejemplo, sidecar, eBPF ).
La verificación de nuevas características en producción enviándolas junto con instrumentación personalizada es una práctica denominada "desarrollo impulsado por la observabilidad". [3]
Las métricas, los registros y los rastros se mencionan con mayor frecuencia como los pilares de la observabilidad. [13] Majors et al. sugieren que los pilares de la observabilidad son la alta cardinalidad, la alta dimensionalidad y la explorabilidad, argumentando que los manuales de ejecución y los paneles de control tienen poco valor porque "los sistemas modernos rara vez fallan exactamente de la misma manera dos veces". [3]
La autosupervisión es una práctica en la que las pilas de observabilidad se supervisan entre sí para reducir el riesgo de interrupciones imprevistas. La autosupervisión se puede implementar además de la alta disponibilidad y redundancia para evitar aún más fallas correlacionadas.