Jaeger v2 y OpenTelemetry: cómo el tracing evoluciona para agentes de IA en entornos cloud

Introducción

En 2016, cuando los sistemas distribuidos migraron de arquitecturas monolíticas a microservicios, herramientas como Jaeger surgieron para resolver un problema concreto: ¿cómo seguir el rastro de una solicitud que cruza 15 servicios distintos en 3 regiones diferentes? La respuesta fue el distributed tracing, un estándar que hoy es pilar de la observabilidad en cloud. Pero en 2026, el problema ya no es solo rastrear microservicios, sino entender el flujo de ejecución de un agente de IA que orquestra herramientas externas, consulta vectores y toma decisiones en tiempo real. Jaeger, proyecto incubado en CNCF, está reescribiendo su núcleo para abordar este nuevo paradigma.

La migración a Jaeger v2 no es un cambio cosmético: es una reescritura que reemplaza su mecanismo de recolección original —basado en agentes específicos— por el OpenTelemetry Collector como columna vertebral del sistema. Esto no solo unifica la recolección de traces, métricas y logs en un solo binario, sino que permite integrar nativamente datos de aplicaciones de IA generativa. Según el blog de CNCF, esta transición se implementa en dos fases:

1. Reemplazo del núcleo: Jaeger v2 adopta OpenTelemetry como formato nativo, eliminando pasos intermedios de traducción.
2. Extensión de capacidades: Integración con protocolos abiertos (MCP, ACP, AG-UI) para que ingenieros y agentes de IA colaboren en el debugging.

Qué ocurrió

1. Jaeger v2: OpenTelemetry como columna vertebral

Hasta Jaeger 1.x, el sistema dependía de su propio agente (jaeger-agent) para recolectar datos y enviarlos al colector (jaeger-collector). Esto generaba fricciones:

• Doble parsing: Los datos llegaban en formato Jaeger y debían convertirse a OpenTelemetry (OTLP) para integrarse con otros sistemas.
• Falta de estandarización: Las convenciones para rastrear llamadas a modelos de IA (como los tokens de un LLM) no existían.

Jaeger v2 (lanzado en mayo de 2026) resuelve esto al adoptar el OpenTelemetry Collector como único componente de recolección. El cambio técnico clave es la eliminación del jaeger-agent y su reemplazo por un colector OTLP que:

• Ingiere datos directamente en OTLP (OpenTelemetry Protocol), sin conversiones intermedias.
• Unifica métricas, logs y trazas en un solo pipeline.
• Permite ejecutar el mismo binario tanto en desarrollo como en producción (gracias a que el colector OTLP es portable).

• Versión afectada: Jaeger v2.0.0 (lanzada el 20 de mayo de 2026).
• Componentes críticos:

– jaeger-query: Ahora consume datos directamente desde OTLP.

• Rendimiento: Reducción del 30% en latencia de ingestión (según benchmarks internos del proyecto).

2. Nuevos protocolos para agentes de IA: MCP, ACP y AG-UI

El segundo cambio es conceptual: Jaeger ya no solo rastrea servicios, sino también agentes de IA. Para esto, el proyecto adopta tres estándares abiertos:

Para diagnosticar un fallo en un pipeline de IA, un ingeniero podría escribir en la UI de Jaeger:

"Muestra todos los spans con errores 5xx en el servicio de pagos donde el tiempo de respuesta supera los 2 segundos, y agrupa por modelo de embedding utilizado."

El backend de Jaeger, usando ACP, traduciría esta consulta en lenguaje natural a una query OTLP como:

resource:
  service.name: "payment-service"
  telemetry.sdk.language: "python"
span:
  status.code: "ERROR"
  duration > 2000ms
group_by:
  - "ai.model.embedding"

3. Soporte para tracing de aplicaciones de IA generativa

Jaeger está incorporando convenciones semánticas para rastrear aplicaciones de IA, definidas en los drafts de OpenTelemetry:

• Generative AI Agentic Systems (Issue #2664): Para rastrear tareas, memoria y acciones de agentes autónomos.
• AI Sandboxes (Issue #3583): Para monitorear entornos efímeros de ejecución de código (como los usados en function calling de modelos).

{
  "trace_id": "abc123",
  "span": {
    "name": "retrieval_augmented_generation",
    "attributes": {
      "ai.model.name": "text-embedding-ada-002",
      "ai.token.usage.input": 128,
      "ai.token.usage.output": 45,
      "ai.tool.calls": ["vector_db_search", "external_api_call"],
      "ai.sandbox.id": "temp-env-456"
    }
  }
}

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y SRE

• Consistencia entre entornos: Jaeger v2 permite ejecutar el mismo colector OTLP en desarrollo (con un modelo pequeño de lenguaje local) y en producción (con un LLM en cloud). Esto evita el clásico problema de «en staging funciona, en producción falla».
• Reducción de complejidad: Al unificar métricas, logs y trazas en OTLP, se simplifica el pipeline de observabilidad. Según datos del proyecto, equipos que migraron a Jaeger v2 reportaron una reducción del 40% en el tiempo de configuración de alertas.

# Antes (Jaeger 1.x)
docker run -d -p 16686:16686 \
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
  jaegertracing/all-in-one:1.55

# Después (Jaeger v2)
docker run -d -p 16686:16686 \
  -e OTEL_COLLECTOR_CONFIG=/etc/otel-collector-config.yaml \
  jaegertracing/all-in-one:2.0.0

Cloud e Infraestructura

• Kubernetes: El proyecto recomienda usar el OpenTelemetry Operator para desplegar el colector OTLP. Un ejemplo de configuración:

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: jaeger-otlp
spec:
  mode: deployment
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
    exporters:
      logging:
      jaeger:
        endpoint: "jaeger-query:14250"
        tls:
          insecure: true
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [jaeger, logging]

• Costos: Al reducir pasos intermedios en el procesamiento de datos, Jaeger v2 optimiza recursos. En un cluster de 50 nodos, se reportó un ahorro del 15% en CPU (según pruebas internas con Prometheus).

Seguridad

• MCP y ACP: Estos protocolos permiten limitar el acceso de los modelos de IA a datos sensibles. Por ejemplo, un agente puede consultar un vector DB, pero MCP exige autenticación para cada acceso.
• Privacidad: Jaeger v2 soporta modelos pequeños locales (SLMs) para casos donde no se pueden usar LLMs en cloud por políticas de compliance.

Detalles técnicos

Arquitectura de Jaeger v2 con OpenTelemetry

La nueva arquitectura de Jaeger v2 sigue este flujo:

1. Aplicaciones envían datos a OTLP (usando SDKs como opentelemetry-python o opentelemetry-go).
2. OpenTelemetry Collector (en modo «jaeger») recibe los datos y los exporta a la UI de Jaeger.
3. Jaeger Query consume directamente desde OTLP, sin necesidad de un adaptador intermedio.

• Inyección de spans: Al usar OTLP nativamente, se evita la manipulación de datos en formatos propietarios.
• Exposición de datos: MCP requiere autenticación para acceder a fuentes externas.

Integración con modelos de IA

Para soportar agentes de IA, Jaeger implementa:

1. Un sidecar ACP: Actúa como traductor entre la UI de Jaeger y los agentes externos. Ejemplo en Go:

// issue #8295: ACP handler
func handleAIQuery(w http.ResponseWriter, r *http.Request) {
  var req ACPRequest
  if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
    http.Error(w, err.Error(), http.StatusBadRequest)
    return
  }

  // Traduce consulta en lenguaje natural a query OTLP
  otelQuery := translateNaturalLanguageToOTLP(req.Query)
  traces, err := queryJaeger(otelQuery)
  if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
  }

  w.Header().Set("Content-Type", "application/json")
  json.NewEncoder(w).Encode(traces)
}

1. Soporte para GenAI semantic conventions: Jaeger v2 mapea estos atributos a la UI:

# Convención OpenTelemetry GenAI draft
attributes:
  ai.model.name: "text-embedding-ada-002"
  ai.token.usage.input: 128
  ai.tool.calls: ["vector_db_search", "external_api_call"]

Qué deberían hacer los administradores y equipos técnicos

1. Migrar a Jaeger v2

1. Actualizar el colector:

   # Para sistemas Debian/Ubuntu
   sudo apt update && sudo apt install -y jaeger-all-in-one=2.0.0

   # Para Kubernetes
   kubectl apply -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/main/deploy/crds.yaml
   kubectl apply -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/main/deploy/service-account.yaml
   kubectl apply -f - <<EOF
   apiVersion: jaegertracing.io/v1
   kind: Jaeger
   metadata:
     name: jaeger-otlp
   spec:
     strategy: allInOne
     allInOne:
       image: jaegertracing/all-in-one:2.0.0
       options:
         collector.otlp.enabled: true
   EOF
   

1. Configurar el OpenTelemetry Collector:

   # otel-collector-config.yaml
   receivers:
     otlp:
       protocols:
         grpc:
         http:
   processors:
     batch:
   exporters:
     jaeger:
       endpoint: "jaeger-query:14250"
       tls:
         insecure: true
   service:
     pipelines:
       traces:
         receivers: [otlp]
         processors: [batch]
         exporters: [jaeger]
   

1. Validar la migración:

   # Verificar que los datos llegan en OTLP
   kubectl logs -l app.kubernetes.io/name=jaeger-otlp
   

2. Configurar integración con modelos de IA

1. Habilitar MCP en el colector:

   # otel-collector-config.yaml
   extensions:
     mcp:
       endpoints:
         - name: "vector_db"
           url: "http://vector-db:8080"
           auth:
             bearer_token: "$VECTOR_DB_TOKEN"
   

1. Configurar AG-UI en la UI de Jaeger:

   # Para entornos que usan Helm
   helm upgrade jaeger jaegertracing/jaeger \
     --set ui.features.aiAssistant.enabled=true \
     --set ui.features.aiAssistant.modelUrl=http://acp-sidecar:4000
   

4. Monitorear aplicaciones de IA

• Instrumentar pipelines de RAG:

  from opentelemetry import trace
  from opentelemetry.sdk.trace import TracerProvider
  from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

  # Configurar el tracer para enviar datos a Jaeger v2
  trace.set_tracer_provider(TracerProvider())
  trace.get_tracer_provider().add_span_processor(
      BatchSpanProcessor(
          OTLPSpanExporter(endpoint="jaeger-collector:4317", insecure=True)
      )
  )

  # Rastrear una llamada a un modelo de embedding
  tracer = trace.get_tracer(__name__)
  with tracer.start_as_current_span("ai_embedding") as span:
      span.set_attribute("ai.model.name", "text-embedding-ada-002")
      span.set_attribute("ai.token.usage.input", 128)
      # ... lógica de embedding ...
  

• Configurar alertas para métricas de IA:

  # Prometheus rule para alertar sobre latencia alta en modelos
  - alert: HighAIModelLatency
    expr: histogram_quantile(0.95, rate(ai_model_duration_seconds_bucket[5m])) > 2
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Latencia alta en modelo {{ $labels.model_name }}"
  

Conclusión

La evolución de Jaeger hacia Jaeger v2 y su integración con OpenTelemetry marca un punto de inflexión en la observabilidad de sistemas distribuidos: ya no basta con rastrear servicios, hay que entender el flujo de ejecución de agentes autónomos y aplicaciones de IA generativa. Esta transición, impulsada por estándares abiertos como MCP y ACP, no solo simplifica la recolección de datos, sino que abre la puerta a un nuevo paradigma donde ingenieros y IA colaboran en el debugging.

Para equipos de DevOps e infraestructura, los pasos clave son:

1. Migrar a Jaeger v2 para unificar el pipeline de observabilidad.
2. Adoptar OTLP como formato nativo y eliminar pasos intermedios.
3. Integrar protocolos como MCP/ACP para soportar modelos de IA en producción.
4. Instrumentar aplicaciones de IA con las nuevas convenciones semánticas de OpenTelemetry.

El cambio no es trivial, pero los beneficios —consistencia entre entornos, reducción de complejidad y soporte nativo para IA— justifican la migración. Como dijo Jonah Kowall en el blog de CNCF: «El futuro de la observabilidad no es solo ver datos, sino entender el contexto detrás de ellos».