¿Qué es la observabilidad y por qué es importante?
La observabilidad es un rasgo de los sistemas de software que proporciona una visibilidad profunda de sus operaciones internas. Poseer una buena capacidad de observación facilita una resolución más rápida de los problemas al ayudar a los equipos de operaciones a identificar la causa de los problemas.
La definición más simple de software observable es un sistema que le permite deducir su estado interno observando los resultados que produce. Si su sistema no puede proporcionar estos resultados, no será completamente observable.
Considere una plataforma de software que parece funcionar más lentamente de lo normal. A primera vista, no tiene información suficiente para averiguar qué está causando la desaceleración. Pero si el sistema emitiera métricas de rendimiento para cada etapa de su ejecución, podría identificar inmediatamente el componente con un problema. La observabilidad del sistema ahora se ha mejorado.
¿No es la observabilidad lo mismo que el monitoreo?
La observabilidad no es lo mismo que el monitoreo, aunque los dos conceptos están estrechamente relacionados. Las buenas prácticas de monitoreo contribuyen a un sistema observable. No proporcionan una garantía de observabilidad. Por el contrario, un sistema podría ser razonablemente observable sin una pila de monitoreo completa.
El monitoreo en términos de DevOps generalmente se refiere al uso de varias métricas predefinidas para identificar cuándo un sistema está funcionando dentro de las expectativas. Las métricas que se cubren generalmente se relacionan con la utilización de recursos (uso de CPU, rendimiento de la red), pero también pueden revelar datos básicos sobre las operaciones de su sistema (número de solicitudes que causan un código de error 500).
La observabilidad es un poco más profunda y requiere una instrumentación más matizada. A diferencia del monitoreo, está acoplado a su sistema y sus características, en lugar del entorno circundante.
Un sistema supervisado le indica que el recuento de errores 500 es elevado y que los usuarios tienen problemas. Un sistema observado informa que su microservicio de autenticación está agotando el tiempo de espera, por lo que las sesiones de los usuarios no se están restaurando y su puerta de enlace está emitiendo un 500 como último recurso.
¿Cómo se vuelven observables los sistemas?
Analicemos las diferencias entre los dos ejemplos que se muestran arriba. En un enfoque tradicional, implementaría en su servidor y configuraría el monitoreo, quizás utilizando las alertas de métricas de su proveedor de nube. Si se detectó un problema, puede ir e inspeccionar los registros del servidor en busca de problemas.
Este modelo ya es observable hasta cierto punto. Sin embargo, el uso moderno de observabilidad transmite un poco más. Los registros de errores del servidor generalmente brindan el resultado final, pero no los estados que causaron que ocurriera. Para que un sistema sea realmente observable, debe poder determinar la secuencia de estados internos que condujeron a un resultado particular, sin tener que dedicar demasiado tiempo a recopilar la información manualmente.
Hay tres “pilares” principales de observabilidad, de los cuales un buen monitoreo es uno. Prestar atención a los tres pilares debería dar como resultado un sistema observable que sea una ayuda eficaz para diagnosticar problemas.
Métricas y Monitoreo
Un sistema observable debe proporcionar mediciones constantes para métricas predefinidas. Las mejores métricas son aquellas que presentan información procesable relevante para su aplicación y su rendimiento, no necesariamente gráficos genéricos de CPU y memoria.
Inicio sesión
El segundo pilar de la observabilidad es el registro. Esto describe un enfoque más estructurado para el registro que una escritura básica cuando ocurre un error. Los registros deben estar altamente integrados en su sistema para que cada evento se registre en un servicio de registro centralizado. Los registros en sí mismos deben estructurarse de manera estandarizada, de modo que las herramientas de visualización de registros puedan indexarlos automáticamente y formatearlos.
Rastreo
El último pilar es el rastreo. Los rastros capturan todo lo que sucede durante una ejecución particular a través del programa. Esto le brinda la información que necesita para reproducir la secuencia exacta de eventos que llevaron a un problema. El seguimiento es especialmente importante para los sistemas distribuidos donde una sola solicitud puede llegar a una docena o más de microservicios. Confiar solo en los registros de servicio no es realista, ya que no podrá ver qué sucedió con la solicitud una vez que finalizó con cada servicio. Un seguimiento a nivel de solicitud es más efectivo para identificar problemas.
Puede comenzar a hacer que un sistema sea más observable asegurándose de tener una cobertura de los tres pilares. Recuerde que la observabilidad no es una cosa específica: es un rasgo de un sistema, no un solo atributo. Lo más probable es que su sistema ya sea observable a través de métricas básicas y registros de errores, pero aún puede tener una observabilidad baja si no puede determinar fácilmente la causa raíz de los errores.
¿La observabilidad detiene los errores?
Vale la pena señalar que la observabilidad no está destinada a eliminar errores y fallas. En cambio, es en realidad una aceptación de que los problemas pueden ocurrir y ocurrirán. En lugar de asumir que su sistema es infalible, la observabilidad lo alienta a planificar lo impensable. Si se enfrentara a un apagón, ¿tendría las herramientas necesarias para encontrar la causa?
Para usar una analogía automovilística, es la diferencia entre una luz de control del motor y el software de diagnóstico del fabricante. Por indeseable e improbable que sea, las fallas en el camino ocurren. La mayoría de las personas sin equipo especializado ven una luz de advertencia genérica. Un automovilista o técnico dedicado tendrá las herramientas para leer la causa de esa luz.
Ahora volvamos a la nube. Una pantalla de métricas rojas no ayudará mucho durante una interrupción. De manera similar a cómo un mecánico de vehículos puede leer los diagnósticos, su sistema debe ser más observable para que pueda establecer rápidamente qué está mal sin mirar las tuercas y los tornillos. Es importante planificar para los desastres para que no te atrapen.
La observabilidad es continua
Mantener una buena observabilidad requiere un mantenimiento continuo. Deberá evaluar su instrumentación a medida que agrega nuevos servicios. De lo contrario, puede crear inadvertidamente vacíos en sus registros y seguimientos en los que desaparecen las solicitudes.
Puede identificar brechas en su implementación de observabilidad cuestionando el sistema y comprobando que puede obtener las respuestas que necesita. Debe pensar en la información que necesitaría para comenzar a abordar un problema. ¿Sería capaz de acceder a él durante una interrupción, sin una intervención manual prolongada?
Un sistema verdaderamente observable debería poder utilizar uno de los tres pilares para responder a las preguntas presentadas por los otros dos. ¿Por qué el uso de la memoria está en la zona de peligro? ¿Por qué se registró un error en los registros del servicio de autenticación? En ambos casos, los otros dos pilares deberían ser su primer puerto de escala para encontrar la respuesta.
Resumen
Observabilidad es una palabra inventada que a veces puede parecer vaga y opaca. En la práctica, el uso moderno del término se refiere a algo bastante simple: el unísono de monitoreo, registro y rastreo para ayudarlo a inferir el estado interno de un sistema a partir de sus resultados.
Una buena observabilidad es vital para las arquitecturas distribuidas donde la funcionalidad se distribuye entre microservicios. Un sistema no observable se convierte en un agujero negro que absorbe las solicitudes pero no devuelve nada. Esto comprometerá su capacidad para responder a los problemas y podría hacer que los usuarios informen sobre los problemas antes de que se dé cuenta.
Por el contrario, un sistema observable lo ayuda a adelantarse a los informes de errores. El tiempo de resolución se minimiza ya que el sistema ya estará esperando con la información que necesita.