La observabilidad ya no es responsabilidad exclusiva de los equipos de fiabilidad de sitios; cada vez se exige más a los desarrolladores que añadan traces, logs y metrics al código que escriben, para poder diagnosticar fallos y comprender el comportamiento de las aplicaciones antes y después de que lleguen a producción. En una entrada publicada en el blog de la CNCF el 25 de agosto de 2026, Adriana Villela, directora de la comunidad de OpenTelemetry y embajadora de la CNCF, y Diana Todea, colaboradora de la documentación de OpenTelemetry y embajadora de la CNCF, presentan un camino práctico para reducir la carga de esta tarea mediante OpenTelemetry.
Las autoras parten de una objeción habitual entre los desarrolladores: añadir instrumentación significa mantener más código, incorporar complejidad adicional y aumentar la posibilidad de que aparezcan errores o deuda técnica. Sin embargo, relacionan este coste con beneficios prácticos directos, entre ellos reducir el tiempo de depuración, acelerar la finalización y el despliegue de funcionalidades, descubrir rutas lentas, reintentos no visibles y casos límite, además de mejorar la comprensión de los sistemas distribuidos. Las autoras consideran que la observabilidad también ayuda a descomponer aplicaciones producidas con ayuda de herramientas de inteligencia artificial cuando su calidad es desigual.
Empieza por la automatización y añade lo que falte
La primera recomendación es utilizar Zero-code instrumentation cuando esté disponible. Este mecanismo añade instrumentación a la aplicación sin modificar el código fuente, interceptando en tiempo de ejecución o durante la compilación las llamadas a frameworks y bibliotecas habituales. Según el artículo, este tipo de soporte está disponible para los lenguajes Java, .NET, Python, JavaScript, PHP y Go.
Las autoras no consideran la automatización una solución completa; no necesariamente sabe qué es importante en la propia lógica de la aplicación. Por ello, debe complementarse con Manual instrumentation para añadir traces, metrics, logs, propagación del contexto y atributos específicos del código. También proponen practicar Observability-driven development, es decir, añadir observabilidad mientras se escribe código nuevo en lugar de volver a él días después, cuando los detalles del diseño están menos presentes en la mente del desarrollador.
¿Qué merece la pena medir?
- Unidades de trabajo importantes: añade spans para las solicitudes entrantes, como las llamadas HTTP, y para las conexiones salientes a bases de datos, cachés, API y colas, además de para las operaciones críticas para el negocio. El artículo advierte contra la creación de un span para cada llamada pequeña, porque eso puede generar ruido que oculte las señales importantes.
- Eventos relevantes: utiliza logs para explicar por qué ocurrió algo concreto, centrándote en los errores, los fallos de validación, las rutas de reintento y alternativas, y los eventos de seguridad, como los fallos de autenticación y los rechazos de permisos.
- Tiempo de respuesta: las métricas de latencia ayudan a determinar por qué una solicitud concreta tarda más de lo habitual, especialmente en rutas de varios pasos, como añadir un artículo al carrito y completar después la compra.
- Frameworks y bibliotecas internas: la instrumentación de los frameworks y bibliotecas desarrollados por el propio equipo puede proporcionar una cobertura amplia, porque gran parte de la aplicación pasa por ellos.
Usa la inteligencia artificial como asistente, no como sustituto de la revisión
Las autoras consideran que las herramientas de programación basadas en inteligencia artificial pueden reducir el tiempo necesario para explorar las interfaces de OpenTelemetry y los distintos SDKs, y también pueden ayudar a trabajar con código antiguo. Sin embargo, aprovecharlas requiere una orientación precisa. Proponen definir el papel del asistente, el objetivo, la ubicación del código y el lenguaje utilizado, así como los resultados deseados, e incluir enlaces a la documentación o ejemplos de código pertinentes.
También aconsejan pedir al agente que explique sus decisiones y, cuando sea posible, utilizar otro agente como juez para cuestionarlas; después, repetir el proceso y mejorar los resultados en lugar de aceptar la primera modificación que proponga la herramienta. Estas recomendaciones reflejan la opinión y la experiencia de las autoras, y no garantizan que el código producido por la inteligencia artificial sea correcto o adecuado para la aplicación.
Un camino local para comprender los datos de telemetría
La instrumentación no está completa sin un medio para leer los datos generados. El artículo explica que OpenTelemetry Collector funciona como un agente neutral respecto a los proveedores: recibe traces, logs y metrics de múltiples fuentes, los procesa cuando es necesario y después los envía a uno o más destinos. Está compuesto por Receivers para recibir los datos, Processors para modificar, ocultar o muestrear atributos, Exporters para enviarlos y Pipelines para definir la ruta de cada tipo de señal, además de Connectors para conectar dos rutas.
Para fines de desarrollo, el artículo propone una configuración sencilla que recibe datos mediante OTLP usando gRPC o HTTP y los exporta a un módulo Debug, con el uso de SpanMetrics Connector para convertir la duración del span en datos metrics que ayuden a detectar problemas de latencia. Después presenta tres herramientas de código abierto que pueden ejecutarse con Collector y Docker Compose: OTel Desktop Viewer para visualizar traces; otel-tui para visualizar traces, logs y metrics, así como las relaciones entre servicios, mediante una interfaz de terminal; y OTel Front para mostrar los mismos tres tipos con un panel de control.
Limitaciones que deben tenerse en cuenta
La experiencia demuestra que estas herramientas no están exentas de obstáculos. Para las autoras, su configuración resultó más sencilla gracias a su experiencia previa con OpenTelemetry Collector y Docker, mientras que los principiantes pueden enfrentarse a mayores dificultades. Además, las herramientas dependen de proyectos de código abierto de terceros, que no siempre pueden mantenerse al día con las versiones más recientes de OpenTelemetry API y SDK ni ofrecer una paridad completa de funcionalidades.
El artículo destaca desafíos más amplios del ecosistema, como la actividad desigual de los grupos de interés de cada lenguaje, la ausencia de automatización para algunos lenguajes, como Rust y Elixir, y la abundancia de opciones entre SDKs, eBPF e instrumentación durante la compilación, además de problemas de estabilidad de las interfaces de programación, actualización de dependencias y una Cardinality elevada en algunos atributos.
Lectura editorial: el valor práctico aquí no reside en añadir una herramienta nueva, sino en convertir la observabilidad de una tarea pospuesta en una parte del ciclo de desarrollo del código. La guía establece un punto de partida de baja fricción y, después, delimita claramente lo que la automatización no puede conocer. Sin embargo, la fuente no ofrece una comparación cuantitativa del rendimiento entre las herramientas ni demuestra que un único camino sea adecuado para todos los lenguajes o entornos; por ello, las recomendaciones deben tratarse como un marco inicial, probando las configuraciones y revisando el volumen de datos, su coste y su adecuación a la aplicación real.