¿Qué es la observabilidad y por qué es importante? – CloudSavvy IT

Especialista en seguridad que trabaja en el centro de control.
Gorodenkoff / Shutterstock.com

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 la resolución más rápida de 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 emitió métricas de rendimiento para cada etapa de su ejecución, podría identificar inmediatamente el componente con un problema. Ahora se ha mejorado la observabilidad del sistema.

¿No es lo mismo la observabilidad que el seguimiento?

La observabilidad no es lo mismo que el seguimiento, aunque los dos conceptos son relaciones estrechas. Las buenas prácticas de seguimiento contribuyen a un sistema observable. No ofrecen 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 mostrar datos básicos sobre las operaciones de su sistema (número de solicitudes que causan un 500 código de error).

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 monitoreado le dice que el 500 el recuento de errores es elevado y los usuarios tienen problemas. Un observado el sistema informa que su microservicio de autenticación está agotando el tiempo de espera, por lo que las sesiones de usuario no se están restaurando y su puerta de enlace está emitiendo un 500 como último recurso.

RELACIONADOS: Introducción a los principios de DevOps para principiantes

¿Cómo se vuelven observables los sistemas?

Analicemos las diferencias entre los dos ejemplos que se muestran arriba. En un enfoque tradicional, lo implementaría en su servidor y configuraría el monitoreo, tal vez utilizando las alertas de métricas de su proveedor de nube. Si se detecta 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 suelen proporcionar el resultado final, pero no los estados que lo provocaron. Para que un sistema sea verdaderamente observable, debe poder determinar la secuencia de estados internos que llevaron a una salida en particular, sin tener que dedicar demasiado tiempo a recopilar la información manualmente.

Hay tres “pilares” principales de observabilidad, uno de los cuales es un buen seguimiento. Prestar atención a los tres pilares debería resultar en un sistema observable que sea una ayuda eficaz para diagnosticar problemas.

RELACIONADOS: ¿Qué es el desarrollo de código bajo y sin código?

Métricas y seguimiento

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 la tala. 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 propios registros deben estructurarse de manera estandarizada, de modo que las herramientas de visualización de registros puedan autoindexarlos y formatearlos.

Rastreo

El último pilar es el rastreo. Las trazas capturan todo lo que sucede durante una ejecución en 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 afectar 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 después de que haya terminado con cada servicio. Un seguimiento a nivel de solicitud es más eficaz para identificar problemas.

Puede comenzar a hacer que un sistema sea más observable asegurándose de tener cobertura de los tres pilares. Recuerde que la «observabilidad» no es una cosa específica, es un rasgo de un sistema, no un atributo único. Es probable 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.

RELACIONADOS: Cómo el abastecimiento de eventos lo ayuda a rastrear el estado de su aplicación

¿La observabilidad detiene los errores?

Vale la pena señalar que la observabilidad no está destinada a eliminar errores y errores. En cambio, en realidad es 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 una interrupción, ¿tendría las herramientas que necesita para encontrar la causa?

Para usar una analogía del motor, es la diferencia entre una luz de verificación del motor y el software de diagnóstico del fabricante. Por indeseable e improbable que sea, ocurren fallas en el camino. 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 los desastres para que no lo 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, sin saberlo, puede crear vacíos en sus registros y rastros en los que desaparecen las solicitudes.

Puede identificar las brechas en su implementación de observabilidad cuestionando el sistema y verificando que puede obtener las respuestas que necesita. Debe pensar en la información que necesitaría para comenzar a abordar un problema. ¿Podrías acceder a él durante un apagó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 inobservable se convierte en un agujero negro que absorbe solicitudes pero no devuelve nada. Esto pondrá en peligro su capacidad para responder a los problemas y podría hacer que los usuarios informen de los problemas antes de que usted se dé cuenta.

Por el contrario, un sistema observable le 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.

Deja un comentario

En esta web usamos cookies para personalizar tu experiencia de usuario.    Política de cookies
Privacidad