OpenTelemetry GenAI: cómo observar agentes de IA sin filtrar prompts ni tool calls

Checklist

Qué problema resuelve OpenTelemetry GenAI

Los agentes de IA rompen la observabilidad clásica porque una petición ya no es una sola llamada HTTP. Puede incluir planning, varias llamadas a modelo, tools locales, MCP remoto, retrieval, memoria, aprobaciones humanas, retries, streaming y costes por token. Si solo tienes logs de aplicación, verás el resultado final, pero no el camino.

OpenTelemetry GenAI propone un vocabulario común bajo atributos como `gen_ai.operation.name`, `gen_ai.provider.name`, `gen_ai.request.model`, `gen_ai.usage.input_tokens`, `gen_ai.tool.name` o `mcp.method.name`. La ventaja no es estética: si varios SDKs emiten el mismo esquema, puedes comparar proveedores, frameworks y backends sin reescribir dashboards cada trimestre.

La parte incómoda es que el estándar sigue en desarrollo. Eso no lo invalida; significa que debes adoptarlo como contrato operativo propio, con versionado y tests, no como magia que arregla toda la observabilidad del stack.

from opentelemetry import trace

tracer = trace.get_tracer("devai.agent")

def call_tool(tool_name: str, args: dict) -> dict:
    with tracer.start_as_current_span(
        f"execute_tool {tool_name}",
        attributes={
            "gen_ai.operation.name": "execute_tool",
            "gen_ai.tool.name": tool_name,
            "gen_ai.tool.type": "function",
            "app.agent.name": "repo-reviewer",
        },
    ) as span:
        try:
            result = run_tool(tool_name, args)
            span.set_attribute("app.tool.success", True)
            return result
        except Exception as exc:
            span.set_attribute("error.type", type(exc).__name__)
            span.record_exception(exc)
            raise

SENSITIVE_KEYS = {"api_key", "token", "password", "email", "customer_id"}

def safe_tool_args(args: dict) -> dict:
    return {
        key: "[redacted]" if key.lower() in SENSITIVE_KEYS else value
        for key, value in args.items()
    }

# Solo si hay opt-in explicito y una politica de retencion clara.
span.set_attribute("gen_ai.tool.call.arguments", json.dumps(safe_tool_args(args)))

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Puntos a revisar

Lo que conviene comprobar

Deja en opt-in el contenido: `gen_ai.input.messages`, `gen_ai.output.messages`, `gen_ai.system_instructions`, definiciones de tools, argumentos y resultados. Esos campos son valiosos para incidentes y evaluacion, pero tambien pueden contener secretos, PII, codigo privado, datos de cliente o instrucciones internas.

La regla operativa es simple: si activas captura de contenido, define antes mascarado, retencion, acceso, muestreo, entornos permitidos y razon de negocio. `Lo necesitamos para debug` no basta si acabas guardando prompts completos de produccion durante meses.

Checklist

MCP: la traza no debe morir en el transporte

MCP complica la observabilidad porque trabaja sobre JSON-RPC y puede usar stdio o Streamable HTTP. Un request de transporte no equivale necesariamente a una operacion MCP: puede haber streams, sesiones, retries y mensajes multiples. Por eso las convenciones MCP recomiendan spans propios y propagacion de contexto en `params._meta`.

Para tools MCP, `mcp.method.name=tools/call` y `gen_ai.operation.name=execute_tool` permiten que el backend trate la llamada como tool call GenAI y como operacion MCP a la vez. Esa doble lectura es util: el equipo de agentes ve la accion, y el equipo de plataforma ve transporte, sesion y servidor.

No metas URIs o argumentos de alta cardinalidad en nombres de span. Usa nombres estables y atributos filtrados. Si cada consulta genera un span name unico, tus dashboards se vuelven caros, lentos y poco agregables.

Checklist

Coste, latencia y calidad: tres tableros distintos

Un agente puede ser correcto y demasiado caro, barato y peligroso, rapido y ciego. Por eso no mezcles todo en un unico `score de agente`. Necesitas tablero de coste, tablero de fiabilidad y tablero de calidad.

El tablero de coste debe mostrar tokens por operacion, cache hits, modelo, proveedor, tool calls y coste estimado por tarea. El tablero de fiabilidad debe mostrar errores por tool, timeouts, retries, spans sin parent y MCP servers lentos. El tablero de calidad debe conectarse con evaluacion: groundedness, aprobaciones humanas, feedback y regresiones.

La observabilidad GenAI no reemplaza evaluaciones, pero las hace auditables. Cuando un gate RAG falla, una traza bien hecha te enseña query, retrieval, modelo, tool calls y respuesta. Sin esa evidencia, el equipo acaba discutiendo impresiones.

Puntos a revisar

Lo que conviene comprobar

Pero la decision madura no es `capturalo todo`. Es capturar lo suficiente para depurar y mejorar sin convertir observabilidad en una base de datos paralela de prompts sensibles. Si empiezas por metadata, tools, coste y errores, ya tendras mas señal que la mayoria de demos. El contenido completo puede venir despues, con politica y responsabilidad.

Fuentes y referencias

• OpenTelemetry GenAI semantic conventions
• OpenTelemetry GenAI systems overview
• OpenTelemetry GenAI agent spans
• OpenTelemetry MCP semantic conventions
• OpenTelemetry: GenAI observability
• OpenTelemetry: AI Agent Observability
• OpenTelemetry GenAI reference implementations
• OpenTelemetry OpenAI Agents instrumentation

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.