La mayoría de los equipos de ingeniería no se dan cuenta de que su stack de observabilidad tiene un problema de residencia de datos hasta que algo falla. Estás depurando un incidente en producción, tus trazas están alojadas en una plataforma SaaS con sede en Estados Unidos y alguien del equipo legal empieza a hacer preguntas incómodas sobre qué datos de telemetría acaban de cruzar el Atlántico. Es una situación cada vez más habitual a medida que los equipos de infraestructura en Europa adoptan arquitecturas cloud-native sin plantearse seriamente dónde viven sus datos operacionales.

La observabilidad completa, es decir, la combinación de logs, métricas y trazas trabajando de forma coordinada, ha dejado de ser opcional para los equipos que gestionan sistemas distribuidos. Pero la forma en que la implementas importa enormemente, sobre todo si operas bajo el RGPD o manejas cargas de trabajo sensibles en sectores regulados.

Este artículo recorre la arquitectura práctica de la observabilidad cloud-native: qué aporta cada tipo de señal, cómo OpenTelemetry lo une todo y por qué vale la pena pensar desde el principio en mantener tu pipeline de telemetría dentro de las fronteras de la infraestructura europea.

Los tres pilares, y por qué los necesitas todos

Los logs, las métricas y las trazas se suelen presentar como un trío, pero en la práctica responden a preguntas fundamentalmente distintas. Los logs te dicen qué ocurrió. Las métricas te dicen cómo se está comportando tu sistema a lo largo del tiempo. Las trazas te dicen dónde se fue el tiempo a lo largo de una petición distribuida. Si te falta cualquiera de ellas, estás depurando con una mano atada a la espalda.

Las métricas son tu sistema de alerta temprana. Un pico en la tasa de errores o un percentil de latencia que sube poco a poco dispara una alerta antes de que los usuarios empiecen a quejarse. Pero las métricas solas no pueden decirte qué servicio, dentro de una cadena de quince microservicios, introdujo esa latencia. Ahí es donde la infraestructura de trazas distribuidas demuestra su valor.

Las trazas te dan la imagen completa del recorrido de una petición: cada salto, cada llamada a base de datos, cada dependencia externa, con los tiempos adjuntos. Combina eso con logs estructurados a nivel de span y podrás pasar de una anomalía en una métrica de alto nivel directamente a la línea de log exacta que la explica. Esto es lo que significa el cloud-native monitoring cuando funciona como debe.

OpenTelemetry como capa unificadora

Si estás empezando una implementación de observabilidad desde cero hoy, OpenTelemetry debería ser tu estándar de instrumentación. Es neutral respecto al proveedor, está ampliamente adoptado y separa la responsabilidad de generar telemetría de la de hacia dónde enviarla. Este último punto tiene más importancia de la que parece a primera vista.

El OpenTelemetry Collector es el componente que hace real esa separación. Lo despliegas como agente o como gateway, instrumentas tus servicios una sola vez usando el SDK de OTel y después configuras el Collector para enrutar las señales al backend que elijas. ¿Quieres cambiar de un almacén de métricas a otro? Cambias la configuración del exportador, no el código de tu aplicación.

Conclusión clave: OpenTelemetry sobre infraestructura cloud europea te da un pipeline de telemetría donde la instrumentación, la recolección y el almacenamiento están completamente bajo tu control. Tú decides qué datos van a dónde, y puedes demostrarlo.

Para los equipos europeos, esta arquitectura tiene una ventaja concreta en materia de cumplimiento normativo. Como el Collector se sitúa entre tus servicios y tus backends, puedes aplicar reglas de filtrado, redacción y enrutamiento antes de que cualquier telemetría salga de tu entorno. Campos sensibles en los cuerpos de log, identificadores de usuario en atributos de traza, direcciones IP en spans HTTP: todo esto puede limpiarse o enmascararse en la capa del Collector, antes de que los datos lleguen a ningún backend de almacenamiento.

Mantener la telemetría dentro de los límites del RGPD

El problema práctico al que se enfrentan los equipos de infraestructura europeos es el siguiente: muchas de las plataformas SaaS de observabilidad más populares tienen su sede fuera de la UE, y sus acuerdos de procesamiento de datos, por muy bien redactados que estén, implican en algún punto del pipeline que los datos salgan del continente. Para algunas cargas de trabajo eso es aceptable. Para otras, especialmente en sanidad, finanzas o el sector público, no lo es.

Ejecutar tu stack de observabilidad en infraestructura europea no significa construirlo todo desde cero. Significa tomar decisiones conscientes sobre dónde corre cada componente. Un despliegue propio o gestionado de un backend de métricas, un sistema de agregación de logs y un almacén de trazas, todo ejecutándose en centros de datos europeos, te da plena residencia de datos sin sacrificar capacidad.

Un stack práctico a considerar

Hay varias combinaciones de código abierto que funcionan bien en este contexto. Un patrón habitual es el siguiente:

  • OpenTelemetry Collector para la ingesta, transformación y enrutamiento de los tres tipos de señales
  • Prometheus o VictoriaMetrics para el almacenamiento y la consulta de métricas
  • Loki para la agregación de logs con indexación basada en etiquetas
  • Tempo para el almacenamiento de trazas distribuidas con correlación traza-log y traza-métrica
  • Grafana como capa unificada de consulta y visualización para los tres backends

Este stack es completamente open source, escalable horizontalmente y desplegable en su totalidad dentro de regiones cloud europeas. El ecosistema de Grafana Labs, en particular, ha invertido mucho en hacer que estos componentes interoperen, de modo que la correlación entre señales que hace útil la observabilidad está integrada de serie, no añadida a posteriori.

Dónde los servicios gestionados reducen la carga operacional

El reto real de autoalojar este stack es la carga operacional. La gestión de la retención en Prometheus, la configuración del almacenamiento de chunks en Loki, la compactación en Tempo: nada de esto es trivial a escala y requiere atención continua a medida que crecen los volúmenes de datos.

Ese es el hueco que cubre un servicio de observabilidad gestionado sobre infraestructura europea. Obtienes las garantías de residencia de datos y el control arquitectónico, sin necesitar un equipo de plataforma dedicado a mantener los backends en buen estado. En DIVERSITY ejecutamos estos componentes como servicios gestionados dentro de centros de datos de la UE, lo que significa que tu telemetría nunca sale de los límites del RGPD y no cargas con el peso operacional de la infraestructura subyacente.

Patrones de instrumentación que realmente escalan

Tener los backends bien configurados es solo la mitad del problema. La otra mitad es la instrumentación: cómo generas telemetría desde tus servicios de forma consistente y útil.

Algunos principios que se sostienen en la práctica. Primero, usa la auto-instrumentación donde exista. La mayoría de los lenguajes principales tienen librerías de auto-instrumentación de OpenTelemetry que capturan llamadas HTTP, gRPC y de base de datos sin ningún cambio en el código. Empieza por ahí y después añade spans manuales para los flujos críticos de negocio.

Segundo, sé deliberado con tu esquema de atributos. Los atributos de traza y las etiquetas de log son la forma en que filtras y correlacionas entre servicios. Si un equipo usa service.name y otro usa app, tus consultas entre servicios se vuelven un dolor de cabeza. Acuerda un esquema desde el principio, aplícalo en la capa del Collector si hace falta y trátalo como un contrato de API.

Tercero, piensa en el muestreo desde el inicio. Trazar cada petición en un sistema de alto rendimiento es costoso. El muestreo basado en cola, donde conservas las trazas que contienen errores o alta latencia y descartas el resto, es la opción predeterminada correcta para la mayoría de los entornos de producción. El OpenTelemetry Collector lo soporta de forma nativa.

La soberanía digital también es una cuestión de fiabilidad

La soberanía digital en observabilidad no es solo una cuestión de cumplimiento normativo. También es una cuestión de independencia operacional. Si tu plataforma de observabilidad es un servicio SaaS y sufre una caída, pierdes visibilidad sobre tus propios sistemas justo en el momento en que más podrías necesitarla. Ejecutar tu pipeline de telemetría en infraestructura que controlas tú, o que un proveedor europeo de confianza gestiona en tu nombre, significa que tu observabilidad no comparte dominio de fallo con lo que estás intentando observar.

Es un argumento de fiabilidad tanto como regulatorio. Y para los equipos que gestionan cargas de trabajo críticas, suele ser el razonamiento más convincente a la hora de defenderlo internamente.

Si estás evaluando cómo implementar observabilidad cloud en infraestructura europea, las decisiones de arquitectura que tomes ahora definirán lo que es posible para tu equipo durante años. Tener bien resueltos desde el principio la recolección de señales, los límites de almacenamiento y los patrones de instrumentación es considerablemente más sencillo que adaptarlos después. Vale la pena pensarlo con calma antes de comprometerte con una dirección.