OpenTelemetry: seguir una operación completa cuando los registros no bastan

Un usuario informa de que una operación tarda demasiado, pero cada servicio parece funcionar. Los registros contienen mensajes sueltos y el equipo dedica tiempo a reconstruir qué petición corresponde a cada uno. La observabilidad busca hacer ese recorrido más comprensible. OpenTelemetry ofrece componentes y convenciones para producir y transportar telemetría, de modo que una aplicación pueda relacionar tiempos, errores y contexto. El primer paso útil no es registrar más cosas, sino poder seguir una tarea importante de principio a fin.

Escoge una operación que hoy cueste investigar

Selecciona un flujo con valor operativo y varias etapas: recibir una solicitud, consultar datos, llamar a un servicio y completar trabajo en segundo plano. Dibuja el recorrido esperado y anota dónde se pierde actualmente la información. Define preguntas concretas: qué tramo consume tiempo, dónde apareció el error y si hubo esperas o repeticiones. Este alcance permite comprobar si la instrumentación resuelve un problema real antes de extenderla a toda la aplicación.

Relaciona trazas, métricas y registros

Una traza representa el recorrido de una operación mediante unidades de trabajo llamadas spans. Cada una aporta duración y contexto, y puede relacionarse con otras para mostrar la secuencia. Las métricas permiten observar tendencias agregadas; los registros añaden detalle sobre eventos concretos. La documentación de OpenTelemetry explica cómo el contexto compartido conecta spans de distintos procesos. En la práctica, esa relación permite pasar de una subida de errores a ejemplos concretos y de ahí a los mensajes que ayudan a investigar su causa.

Propaga el contexto entre fronteras

La instrumentación automática puede cubrir llamadas habituales, pero hay que comprobar los límites del flujo real. Mensajería, trabajos programados y bibliotecas propias pueden necesitar tratamiento explícito. Si el contexto se pierde al enviar un mensaje, el consumidor aparecerá como una actividad aislada y será difícil relacionarlo con la solicitud inicial. Verifica también que intermediarios y clientes compatibles conservan la información necesaria. No confíes en que instalar una biblioteca produzca automáticamente una traza completa de cualquier arquitectura.

Utiliza nombres estables y atributos con significado. Una operación puede identificarse por su tipo sin incluir un nombre de usuario o una URL completa con parámetros sensibles. Documenta convenciones pequeñas para que distintos equipos describan lo mismo de la misma manera. La consistencia facilita búsquedas y evita que los paneles necesiten conocer cada detalle de cómo una persona decidió nombrar la instrumentación.

Protege lo que envías a la plataforma

Los cuerpos de peticiones, cabeceras y consultas pueden contener información que no debe copiarse íntegra a telemetría. Define qué atributos se admiten y revisa los valores que se capturan automáticamente. Evita tokens, contraseñas y contenido personal innecesario. Acuerda acceso, conservación y destino de los datos con las personas responsables. La observabilidad mejora la investigación, pero también crea otro conjunto de información que debe mantenerse y protegerse durante su ciclo de vida.

• Identifica el nombre del servicio, entorno y versión desplegada.
• Comprueba que una operación completa comparte contexto entre componentes.
• Revisa atributos para retirar secretos y datos que no aportan diagnóstico.
• Define conservación y muestreo según volumen e importancia de los casos.
• Simula un error y una demora para verificar que pueden localizarse desde la telemetría.

Controla volumen y coste con una pregunta clara

Capturar todo indefinidamente no suele ser necesario. Evalúa el volumen, la sobrecarga y los casos que no quieres perder antes de elegir una estrategia de muestreo. Los identificadores muy variables en etiquetas de métricas pueden multiplicar el número de series; reserva el detalle individual para mecanismos adecuados. Si conservas solo una muestra de trazas, explica esa limitación a quienes investigan. La ausencia de una traza no demuestra que una operación no haya ocurrido.

Convierte la instrumentación en una herramienta de trabajo

Prepara una vista inicial con latencia, errores y volumen, y una forma sencilla de llegar a trazas representativas. Relaciona los cambios con la versión de la aplicación para investigar regresiones. Ensaya un fallo conocido en un entorno controlado y pide a otra persona que lo localice utilizando únicamente la información disponible. Si necesita acceder al código para entender cada nombre, quizá falta contexto. Si la señal útil queda enterrada entre miles de eventos, conviene simplificar.

La instrumentación debe evolucionar con el producto. Revisa los puntos ciegos detectados en incidencias y retira datos que nadie utiliza. Un objetivo inicial realista es reducir el tiempo necesario para responder dónde falló una operación y qué parte fue lenta. Cuando ese recorrido resulta claro, ampliar la cobertura tiene un propósito concreto y la observabilidad deja de ser una colección de gráficos que se consulta solo después de un problema.