La observabilidad es el término técnico para comprender el comportamiento de un sistema utilizando factores reconocibles externamente. Sin embargo, los microservicios plantean un desafío particular. Recopilar datos y analizarlos es complicado.
El término observabilidad se remonta originalmente al ingeniero Rudolf E. Kalman. Esto lo trajo a colación en el contexto de una tesis sobre la teoría del control en sistemas dinámicos lineales. Lo definió como el valor de qué tan bien se pueden derivar los estados internos de un sistema a partir de resultados reconocibles externamente.
En pocas palabras: ¿pueden las mediciones externas determinar si hay un error? ¿Puedes siquiera decir qué es? La ventaja es obvia: el sistema no tiene que ser perforado «a ciegas» para eliminar un problema.
Observabilidad y software
Esta definición básica se aplica a todas las áreas hasta el día de hoy. Yuri Shkuro también agregó una demarcación simple al monitoreo: esa es la medición de funciones que se desarrollaron de antemano. La observabilidad, por otro lado, se trata de determinar cosas que antes se desconocían a través de su propio sistema.
O, para decirlo de forma breve y sencilla: el seguimiento proporciona información sobre conductas indebidas. La observabilidad pregunta el «¿por qué?» Detrás del problema. En el área del software, por lo tanto, es un criterio de calidad, similar, por ejemplo, a la usabilidad. Y en los sistemas monolíticos, el manejo también es relativamente sencillo.
Los SLI (indicadores de nivel de servicio que miden el grado de funcionalidad de un servicio) se pueden identificar fácilmente. Si un valor cae, se encuentra la razón al mismo tiempo. A modo de ejemplo: si un programa de procesamiento de texto ya no cumple todas las funciones, hay un error en el código que conduce al fallo. Dado que es uno de los SLO (Service Level Objectives, objetivos para el grado de funcionalidad de un servicio) que todas las funciones funcionen, se elimina el error.
Observabilidad y microservicios
Sin embargo, los sistemas monolíticos son cada vez más raros. Los microservicios están ocupando su lugar. Estos suelen ser proporcionados conjuntamente por diferentes servicios en la nube. Surge una avalancha de datos. A menudo es difícil determinar su origen y su propósito preciso. Por lo tanto, a menudo se recopila demasiada información para la observabilidad. En otros casos, hay muy pocos.
Un ejemplo es una aplicación de teléfono inteligente que está conectada a un servicio en la nube. Al mismo tiempo, la nube del proveedor utiliza el sistema operativo para autenticar al usuario e interactuar con el resto del dispositivo. Los siguientes problemas no son infrecuentes, pero causan problemas importantes al asignar datos a la observabilidad:
- ¿Debería medirse el tiempo de inicio de sesión, aunque el usuario normalmente no haya cerrado la sesión?
- Algunas funciones proporcionadas por el sistema operativo (por ejemplo, copiar y pegar) no funcionan en la aplicación, ¿cómo se debe tener esto en cuenta?
- Los tiempos de carga de la aplicación difieren mucho entre los usuarios, a pesar de que usan el mismo modelo de dispositivo, ¿qué significa esto?
- ¿Los archivos de registro no se recopilan en su totalidad o no proporcionan la información relevante?
Herramientas de observabilidad en microservicios
Para solucionar este problema, las herramientas de observabilidad descansan sobre tres pilares que funcionan en los microservicios. Fluyen juntos, pero deben nombrarse por separado para facilitar su comprensión.
En primer lugar, se utilizan métricas: se mide todo lo que se puede medir. En segundo lugar, los seguimientos también se determinan como parte de la gestión del rendimiento de la aplicación. En pocas palabras, los «rastros» se trazan como caminos que toman las funciones. Los puntos de medición se anotan en estos. En tercer lugar, se evalúan los registros. Estos son los registros de acciones anteriores.
Estos pilares permiten evaluar en el marco de los microservicios qué tan bien funciona un servicio, dónde se ejecuta, cómo se ha comportado en el pasado y con quién interactúa. Sin embargo, la necesidad de poder de cómputo es tan alta para llevar a cabo este proceso de forma permanente que prácticamente solo pueden hacerlo los propios desarrolladores en la vida diaria.