El mero hecho de disponer de más datos no basta para explicar un incidente (Observabilidad, parte 2)

Los routers proporcionan métricas de rendimiento, los componentes de seguridad registran eventos y el servicio de asistencia técnica recoge las quejas. Sin embargo, la investigación de una aplicación en la nube que funciona con lentitud suele comenzar con la recopilación manual de información procedente de diferentes fuentes. Lo que falta es la conexión entre los datos ya disponibles: ¿qué métrica se corresponde con qué sitio, ruta de acceso y aplicación?

Si bien la monitorización revela condiciones técnicas y tendencias, la observabilidad también requiere que existan conexiones claras entre esas observaciones. La clave está en determinar qué pregunta operativa pueden responder los datos. Eso determina qué señales son necesarias y a qué contexto deben vincularse.

Qué señales responden a qué preguntas

Los distintos tipos de datos ofrecen diferentes perspectivas sobre el comportamiento de un servicio:

• Las métricas describen características cuantificables, como la utilización de la red, la latencia y la pérdida de paquetes. Revelan tendencias y desviaciones, pero por sí solas no pueden explicar sus causas.
• Los registros recogen eventos individuales, como un intento de acceso fallido o la aplicación de una regla de seguridad. Su valor depende de si los eventos relevantes se registran realmente.
• Los datos de flujo describen los patrones de comunicación y los volúmenes de datos transferidos. Ayudan a identificar qué sistemas se comunican entre sí y cómo varía el tráfico a lo largo del tiempo.
• Las pruebas sintéticas realizan intentos de acceso predefinidos. Muestran cómo se comporta un servicio desde un punto de medición concreto. Sin embargo, una prueba realizada desde un centro de datos no refleja automáticamente la experiencia de un empleado que utiliza la red LAN inalámbrica local.

La investigación de una aplicación lenta puede requerir varias de estas perspectivas. El alcance y la selección dependen del servicio afectado y de las posibles causas a lo largo de toda la ruta de la red.

De las métricas al contexto

Imaginemos una sucursal en la que los empleados informan por la mañana de tiempos de respuesta lentos en una aplicación en la nube. Una prueba sintética realizada desde la sucursal confirma el retraso. Al mismo tiempo, la utilización de la red en la sucursal está aumentando. La sospecha inicial parece razonable: la conexión de la sucursal está sobrecargada.

Para comprobar esta hipótesis, las mediciones deben coincidir tanto en el tiempo como en el alcance técnico. ¿Sigue la prueba la misma ruta de red que la aplicación? ¿Se refiere la cifra de utilización al enlace que transporta el tráfico de la aplicación? ¿Cubren realmente las mediciones el mismo periodo? Solo cuando se establezcan estas relaciones podrá el equipo evaluar si las observaciones están relacionadas.

La obtención de más información puede cambiar el rumbo de la investigación. Los datos de flujo podrían revelar que, al mismo tiempo, se está produciendo una transferencia de datos de gran volumen a través del enlace afectado. Las pruebas de pérdida de paquetes aportarían información adicional para evaluar la conexión. Sin embargo, si solo los empleados que utilizan la red LAN inalámbrica local experimentan retrasos, mientras que una prueba realizada a través de una conexión por cable no muestra ningún problema, también debería investigarse la red inalámbrica.

Por lo tanto, la observabilidad requiere un modelo de contexto compartido. Este describe cómo se relacionan entre sí los emplazamientos, los dispositivos, los proveedores de servicios, las aplicaciones y las rutas de red. La información sobre las normas de seguridad y los cambios anteriores aporta un contexto adicional. Esto permite identificar a qué parte de un servicio se refiere una métrica o un evento. Los eventos que se producen al mismo tiempo sirven de punto de partida para la investigación; no obstante, la causa debe confirmarse mediante un análisis más detallado.

Conectar los sistemas existentes donde es necesario

Estas relaciones también pueden establecerse entre múltiples sistemas especializados. Los sistemas de monitorización, las herramientas de seguridad, los sistemas en la nube y el servicio de asistencia técnica pueden conservar sus respectivas funciones. Para facilitar un análisis compartido, la información relevante debe conectarse a través de interfaces y asignarse de forma coherente.

Por lo tanto, antes de ampliar la recopilación de datos, los responsables de TI deberían comprobar si las fuentes existentes ya son utilizables. ¿Están actualizadas las correspondencias con los sitios y los servicios? ¿Son comparables las marcas de tiempo? ¿Es suficiente la resolución temporal para detectar breves periodos de deterioro del rendimiento? Las correspondencias que faltan o están desactualizadas pueden llevar a conclusiones erróneas, incluso cuando se recopilan grandes cantidades de datos.

Para un servicio concreto, los requisitos pueden plasmarse en una sencilla matriz: cuestión operativa, señal requerida, fuente de datos y contexto necesario. Cuando esto revele lagunas, los equipos podrán tomar una decisión específica sobre si necesitan mediciones adicionales o mejores conexiones entre la información existente. El análisis asistido por IA también depende de datos subyacentes fiables y de asignaciones claras y trazables.

¿Quieres saber qué datos te ayudarán a comprender cuáles son tus servicios más importantes? Nuestros expertos pueden ayudarte a evaluar las fuentes existentes, identificar el contexto que falta y determinar qué integraciones te resultarían útiles.


Imagen: creada con IA