Mcp on lo0 — Blog Técnico

MCP por dentro y su observabilidad profunda: el LSP de los agentes IA y cómo verlo todo con OpenTelemetry

Wed, 20 May 2026 06:00:00 +0200

TL;DR

Model Context Protocol (MCP) es el estándar que Anthropic publicó a finales de 2024 y que se ha convertido en 2026 en el protocolo dominante para conectar agentes IA con herramientas y datos externos. Su valor —el motivo por el que toda la industria lo ha adoptado en menos de 18 meses— es que resuelve un problema combinatorio: antes de MCP, integrar M apps IA con N herramientas requería M×N integraciones ad-hoc; con MCP, M + N. Es el mismo movimiento que hizo el Language Server Protocol en 2016 para los editores de código. La arquitectura es tres roles bien definidos —Host (la app IA), Cliente (la conexión, uno por servidor) y Servidor (la pieza que expone capacidades)—; las primitivas son seis —tres del lado servidor (Tools, Resources, Prompts), tres del lado cliente (Sampling, Roots, Elicitation)—; el protocolo es JSON-RPC sobre dos transportes —stdio para procesos locales, Streamable HTTP para remoto—. El reto operacional aparece cuando hay 10-20 servers MCP corriendo simultáneamente, cada uno con varias tools, conectados a un agente que encadena llamadas multistep: observar qué pasa, dónde fallan las cosas, cuánto cuesta cada tool, qué tenant invoca qué se vuelve crítico. La respuesta del ecosistema en 2026: las nuevas OpenTelemetry GenAI semantic conventions for MCP (ya estables), trace context propagation vía params._meta (porque JSON-RPC no lo trae nativo), FastMCP con instrumentación OTel built-in, MCP Gateways como capa centralizada (Traefik Hub, MintMCP, OpenObserve), y MCP Inspector para debugging interactivo. Este artículo recorre la arquitectura desde fuera hacia dentro, sitúa cada concepto en su lugar exacto, y baja al detalle de la observabilidad: trazas, métricas RED, casos de uso reales y trampas.

Este es el tercer post de la serie post-tracing. Posts previos: Evals y Guardrails. Aquí bajamos al protocolo que conecta agentes con herramientas, y cómo verlo en producción.

La analogía maestra (en tres versiones)

MCP es un protocolo de comunicación. Como cualquier protocolo, se entiende mejor con la analogía adecuada. Voy a darte tres porque cada una ilumina una faceta distinta y la combinación te deja entendiéndolo mejor que cualquier definición técnica.

Versión 1 — El USB-C de las apps IA (la oficial)

Es la analogía que Anthropic adoptó al presentarlo. Antes de USB-C, cada dispositivo electrónico tenía su propio conector. Tu móvil llevaba microUSB o Lightning, tu portátil un puerto propietario para alimentación, tus auriculares un jack 3.5mm, tu disco externo USB-A en una punta y mini-USB en la otra. Resultado: tres cajas llenas de cables específicos que se perdían, ninguno servía para dos cosas, comprar un dispositivo nuevo significaba comprar accesorios nuevos.

USB-C cambió eso. Un único conector físico que muchos protocolos atraviesan: datos (USB 3, USB 4, Thunderbolt), vídeo (DisplayPort), alimentación (Power Delivery), audio. Conectas cualquier cosa a cualquier cosa y funciona; los protocolos negocian arriba.

MCP juega el mismo rol para apps IA. Antes de MCP, cada aplicación que quería integrar herramientas con un LLM —Claude Desktop, Cursor, Continue, custom agents propios— inventaba su propia forma de hacerlo. Cada vendor de tools tenía que escribir N integraciones distintas, una por app. Resultado: fragmentación masiva, mucho código duplicado, integraciones que se rompían cuando una app cambiaba su API interna.

Con MCP, el conector es uno: cualquier app que hable MCP puede usar cualquier herramienta MCP. Igual que tu USB-C habla a impresoras, monitores y discos sin que la impresora “sepa” que el cable está conectado a un Mac o a un Linux.

Versión 2 — El LSP de los editores de código (la más técnicamente precisa)

Esta es mi preferida porque la analogía es estructuralmente idéntica, no solo metafórica.

Hasta 2016, si querías que tu editor de código soportara un lenguaje nuevo —Rust, Go, TypeScript— alguien tenía que escribir un plugin específico para tu editor concreto. VSCode tenía su plugin de Rust, IntelliJ otro distinto, Vim otro, Emacs otro. Cada feature decente (go-to-definition, autocompletado, refactoring) era una implementación duplicada N veces. M editores × N lenguajes = M·N integraciones.

Microsoft propuso en 2016 el Language Server Protocol (LSP): cada lenguaje implementa un único “language server” (un proceso que entiende ese lenguaje); cada editor implementa un único cliente LSP; cuando trabajas con código Rust en VSCode, VSCode lanza rust-analyzer como subproceso y le habla LSP por stdio. Cualquier editor LSP + cualquier servidor LSP = funciona. M + N.

MCP es literalmente este patrón, trasladado de “editor + language server” a “app IA + tool provider”. Y comparte hasta el detalle técnico: ambos pasan JSON-RPC sobre stdio (entre otros transportes). Cuando Anthropic diseñó MCP, miraron a LSP. Quien venga del mundo de editores e IDEs encontrará MCP familiar.

Versión 3 — El driver del sistema operativo (la operativa)

Por último, una analogía que ayuda a entender lo que hace un MCP server concreto.

Un sistema operativo no sabe directamente cómo hablar con tu impresora HP LaserJet específica. Lo que sabe es una interfaz genérica: “imprimir documento”, “consultar estado”, “cancelar tarea”. El driver de impresora es la pieza que traduce esa interfaz genérica a los comandos propietarios de tu impresora específica.

Un MCP server hace exactamente lo mismo:

Tu agente IA sabe una interfaz genérica: invocar una tool con un schema definido, leer un resource por URI, pedir un prompt template por nombre.
El MCP server es el driver: traduce esas operaciones genéricas a las API concretas del sistema underlying —tu base de datos PostgreSQL, tu filesystem, tu API GitHub, tu Stripe—.

Esto deja al agente IA libre de saber cómo se autentica con GitHub, qué SQL exacto usa PostgreSQL, qué endpoints tiene Stripe. Habla MCP; el server se encarga de los detalles.

Con las tres analogías combinadas: MCP es la capa entre el LLM y el mundo, un USB-C estándar implementado como LSP en JSON-RPC, con cada server actuando de driver para un sistema underlying concreto.

Qué problema concreto resuelve MCP

Antes de bajar a la arquitectura, conviene fijar el problema específico que MCP resuelve, porque sin eso muchas decisiones de diseño parecen arbitrarias.

El problema es el coste cuadrático de las integraciones.

Imagina que tienes M aplicaciones que usan LLMs (Claude Desktop, Cursor, Continue, ChatGPT Desktop, tu propio agente custom, …) y N herramientas externas que esos LLMs podrían usar (filesystem, GitHub, Slack, PostgreSQL, Jira, Notion, …). Sin un estándar:

Cada par (aplicación, herramienta) requiere una integración específica.
Cada vez que la aplicación cambia su API interna, hay que actualizar N integraciones.
Cada vez que la herramienta cambia su API, hay que actualizar M.
Para que tu herramienta nueva sea adoptada, tienes que escribir M integraciones.
Para que tu aplicación nueva soporte el ecosistema, tienes que escribir N.

Resultado real en 2023-2024: fragmentación masiva. Function calling de OpenAI no era compatible con tool use de Anthropic; cada framework (LangChain, LlamaIndex, dspy) tenía su propio wrapper; los plugins de Claude Desktop no funcionaban en Cursor; etc.

MCP rompe la cuadratura. Cada aplicación implementa el protocolo una vez; cada herramienta implementa el protocolo una vez; cualquier par funciona. M + N.

Es exactamente lo que pasó con USB-C, con LSP, con SQL (antes había APIs propietarias por base de datos), con POSIX (antes había APIs propietarias por sistema operativo). El patrón se repite porque resuelve siempre el mismo tipo de problema.

La arquitectura: tres roles, situados con claridad

Vamos a fijar dónde vive cada cosa, porque mezclar los roles es la fuente número uno de confusión en MCP.

Tres roles. Vamos a fijar qué hace cada uno y dónde vive físicamente.

Host: la aplicación IA

El Host es la aplicación que el usuario abre. Claude Desktop, Cursor, Continue, ChatGPT Desktop, un agente custom que tu equipo construye, una extensión de VSCode. Lo que el usuario percibe como “el producto”.

El Host es el responsable de:

Decidir qué servidores MCP conectar (configurados por el usuario en un archivo o vía UI).
Lanzar o conectar con cada servidor MCP.
Crear un Cliente MCP por servidor (es 1:1, no comparten).
Embeber el LLM (o llamarlo vía API) que toma las decisiones de qué herramientas usar.
Mediar la autorización del usuario para acciones sensibles (mostrarle al humano “el agente quiere ejecutar X tool, ¿permites?”).

Importante: el LLM vive dentro del Host, no en los servidores. Los servidores son tontos; ejecutan operaciones cuando se les pide. El razonamiento ("¿debería llamar a esta tool ahora?") vive en el LLM del host.

Cliente: la conexión, una por servidor

Un Cliente MCP es una conexión específica entre el Host y un Servidor. Si tu Host tiene 5 servidores MCP configurados, tiene 5 clientes, no uno compartido. Cada cliente:

Mantiene su socket o stdio pipe con el servidor.
Negocia capacidades en el handshake inicial (qué versión del protocolo, qué primitivas soportan ambos).
Serializa requests JSON-RPC al servidor y deserializa respuestas.
Es el punto donde el Host invoca operaciones del servidor.

La separación 1:1 cliente-servidor es importante porque permite que cada server tenga su propio estado de sesión, sus permisos específicos y su contexto autenticado independiente. No hay multiplexación en el cliente.

Servidor: la pieza que expone capacidades

El Servidor MCP es la pieza que implementa el lado tool-provider del protocolo. Recibe JSON-RPC del cliente, lo procesa, ejecuta la acción contra el sistema underlying y devuelve respuesta.

Hay dos sabores físicamente:

Servidor local: arranca como subproceso del Host, comunica por stdio. Su ciclo de vida es el del Host (cuando cierras Claude Desktop, los servidores locales mueren). Modelo típico: tu Host lanza node filesystem-mcp-server.js como hijo.
Servidor remoto: corre como servicio independiente, accesible por HTTP. Multi-tenant, autenticado, escalable. Modelo típico: una empresa publica https://mcp.acme.com/v1 y muchos hosts se conectan.

Esta diferencia tiene consecuencias enormes en observabilidad (volveremos en breve).

Resumen del lugar de cada cosa

Componente	Vive en	Hay cuántos	Habla qué con quién
Host	Máquina del usuario	1 (la app abierta)	UI con usuario; lanza clientes
LLM	Embebido en Host (o cloud API)	1 (el principal)	Razona; pide tools
Cliente	Host	1 por servidor	JSON-RPC con su servidor
Servidor local	Subproceso del Host	1 por integración local	stdio con su cliente
Servidor remoto	Servicio externo	1 por servicio	HTTP/SSE con sus clientes
Sistema underlying	Externo	Depende	API/DB/FS, no MCP

Si te confundes en discusión, vuelve a esta tabla. La fuente número uno de errores en MCP es decir “el servidor” cuando se quiere decir “el host”.

Las dos capas del protocolo

MCP separa data layer y transport layer. Esta separación es la que permite que el protocolo funcione por stdio local y por HTTP remoto sin cambiar nada en las primitivas.

Data Layer: JSON-RPC con extensiones MCP

La capa de datos define el vocabulario de los mensajes. Es JSON-RPC 2.0. Cada mensaje es un JSON con jsonrpc: "2.0", un method (eg tools/call, resources/read), params, e id para correlar request con response.

Encima de JSON-RPC, MCP añade:

Lifecycle: el handshake inicial (initialize, initialized) que negocia capacidades.
Las primitivas (siguiente sección): tools/*, resources/*, prompts/*, sampling/*, etc.
Notifications: mensajes sin respuesta (eg notifications/cancelled para abortar una tool en curso).
Meta-information: el campo params._meta por convención lleva metadata transversal (trace context, request IDs).

Transport Layer: cómo se mueven los mensajes

La capa de transporte define cómo viajan los mensajes JSON-RPC. Dos transportes oficiales:

stdio: el cliente lanza el servidor como subproceso y se comunican por sus stdin/stdout/stderr con JSON-RPC. Un mensaje por línea, separados por newline. Sin red, sin handshake TLS, sin auth (la confianza se hereda del propio sistema operativo: si lanzas el subproceso, le confías). Latencia mínima (~100 μs round-trip), ancho de banda máximo (memcpy, no socket).

Caso de uso: servidores locales que viven en la misma máquina que el host. La mayoría de servidores MCP que ves en directorios públicos son stdio.

Streamable HTTP: el cliente envía POST a un endpoint HTTP del servidor; el servidor responde con JSON, opcionalmente abre un stream Server-Sent Events para enviar notificaciones asíncronas o respuestas largas. Auth por bearer token, API key o headers custom.

Introducido en la spec de noviembre 2025, sustituye al transporte SSE puro de versiones anteriores que tenía limitaciones de bidireccionalidad. Caso de uso: servidores remotos que sirven a muchos clientes simultáneos, con autenticación y multi-tenancy.

Importante: las primitivas son las mismas en ambos transportes. Un tools/call es idéntico en stdio y en HTTP. El transport es accidental, no fundamental.

Las seis primitivas: situadas en la arquitectura

Aquí está la chicha. Hay seis primitivas en MCP. Suelen confundirse porque varias parecen hacer cosas similares. La clasificación clave: tres viven del lado servidor (server expone, cliente consume) y tres del lado cliente (cliente expone, servidor consume).

Server-side: lo que el servidor le da al host

Tools son acciones que el servidor expone. Cada tool tiene un schema (parámetros tipados, descripción) y una implementación. Cuando el LLM del host decide invocar una tool, el cliente envía tools/call al servidor, este la ejecuta y devuelve resultado.

Ejemplo: el server github-mcp expone create_issue(repo, title, body). El LLM del host decide “voy a crear un issue”, llama esta tool, github-mcp habla a la API de GitHub, devuelve el issue ID al LLM.
Lugar arquitectónico: el servidor las expone, el LLM las consume.

Resources son datos contextuales que el servidor expone, direccionables por URI. No son acciones; son lecturas de contenido. Un resource tiene URI (file:///path/to/doc.md, postgres://table/users), metadata y un endpoint para leer contenido.

Ejemplo: el server filesystem-mcp expone como resources los archivos de los directorios autorizados. El LLM pide resources/read con URI file:///docs/api.md y obtiene el texto.
Lugar arquitectónico: el servidor las expone, el host las lee (y opcionalmente las pasa al LLM como contexto).

Diferencia clave Tools vs Resources: Tools son verbos (ejecutan, modifican estado, tienen side effects); Resources son sustantivos (existen, se leen, son idempotentes). Si tienes algo que es “buscar texto en archivos” → probablemente Tool (acción). Si es “este archivo concreto” → Resource. La distinción importa para auditoría y permisos: tools requieren más control.

Prompts son plantillas de prompt parametrizadas que el servidor expone. El usuario o el host puede invocarlas para inyectar un patrón conversacional al modelo.

Ejemplo: un server code-review-mcp expone un prompt review_diff(diff_text, style="strict") que devuelve un prompt completo bien escrito para pedirle al LLM que revise código.
Lugar arquitectónico: el servidor las expone, el usuario o el host las invoca, el LLM las recibe como input.

Los prompts son la primitiva menos usada de las tres; muchos servers ni los implementan. Pero permiten que un equipo publique buenos prompts como librería reutilizable, separados del agente.

Client-side: lo que el host le da al servidor

Aquí es donde MCP se diferencia de protocolos como HTTP REST: el servidor también puede pedir cosas al host, no es solo una vía. Tres primitivas viajan en esa dirección.

Sampling: el servidor pide al host que ejecute una generación con su LLM. Es decir, el servidor toma prestado el LLM del host para razonar.

Ejemplo: el server search-mcp recibe una query del agente, busca en su corpus, encuentra 50 resultados y necesita resumirlos antes de devolver. En vez de tener su propio LLM, manda un sampling/createMessage al cliente; el host pasa esto a su LLM, ejecuta la generación con permisos del usuario, devuelve el resumen al servidor.
Lugar arquitectónico: el servidor lo pide, el host (con su LLM y la autorización del usuario) lo cumple.
Por qué importa: el usuario controla qué modelo se usa, qué coste se paga, qué permisos aplican. El servidor no necesita su propia API key de OpenAI.

Roots: el host le dice al servidor dónde mirar. Roots son URIs (directorios, repositorios, namespaces) que el host autoriza al servidor a explorar.

Ejemplo: tu Claude Desktop arranca filesystem-mcp con roots [file:///Users/yo/proyectos]. El servidor sabe que solo debe operar dentro de esa carpeta, no en /etc/passwd.
Lugar arquitectónico: el host las declara en el handshake, el servidor las respeta.

Elicitation: el servidor pide al host información adicional al usuario humano vía UI estructurada.

Ejemplo: el server stripe-mcp está a punto de procesar un refund de 5000€. Antes de ejecutar, manda elicitation/createMessage al cliente; el host muestra al usuario “Confirma este refund de €5000” con un botón; cuando el usuario confirma, devuelve OK al server, que entonces procede.
Lugar arquitectónico: el servidor pide, el host muestra al usuario, el usuario decide, la respuesta vuelve al servidor.
Es la primitiva clave para human-in-the-loop en acciones sensibles.

Visualización del flujo de las seis primitivas

 HOST SERVIDOR
│ │
Server-side ─────┼─────────────────────────────────────┤
│ │
tools/list ──────┼────── pregunta qué tools hay ──────▶│
│◀────── devuelve lista ──────────────│
│ │
tools/call ──────┼────── ejecuta esta tool ───────────▶│
│◀────── resultado ──────────────────│
│ │
resources/read ──┼────── lee este URI ────────────────▶│
│◀────── contenido ─────────────────│
│ │
prompts/get ─────┼────── dame este prompt ────────────▶│
│◀────── prompt compilado ──────────│
│ │
Client-side ─────┼─────────────────────────────────────┤
│ │
sampling ────────│◀────── necesito una generación ─────│
│── usa mi LLM ───┐ │
│── devuelve ─────▼──────────────────▶│
│ │
roots ───────────┼─── declarados en handshake ────────▶│
│ │
elicitation ─────│◀────── pregunta al usuario X ───────│
│── muestra UI ──┐ │
│── confirma ────▼───────────────────▶│

El JSON-RPC en acción: un ejemplo concreto

Para que la teoría se materialice, una conversación MCP real entre cliente y servidor filesystem-mcp:

// 1. Handshake inicial (cliente → servidor)
{
"jsonrpc": "2.0", "id": 1, "method": "initialize",
"params": {
"protocolVersion": "2026-03-01",
"capabilities": {
"sampling": {}, // este cliente soporta sampling
"roots": { "listChanged": true }
},
"clientInfo": { "name": "ClaudeDesktop", "version": "1.2.0" }
}
}
// 2. Server responde con sus capabilities
{
"jsonrpc": "2.0", "id": 1, "result": {
"protocolVersion": "2026-03-01",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true },
"prompts": {}
},
"serverInfo": { "name": "filesystem-mcp", "version": "0.5.2" }
}
}
// 3. Cliente pide listado de tools
{
"jsonrpc": "2.0", "id": 2, "method": "tools/list"
}
// 4. Server devuelve sus tools con schema
{
"jsonrpc": "2.0", "id": 2, "result": {
"tools": [
{
"name": "read_file",
"description": "Read a file from the filesystem",
"inputSchema": {
"type": "object",
"properties": { "path": { "type": "string" } },
"required": ["path"]
}
},
{ "name": "write_file", "description": "...", "inputSchema": {} },
{ "name": "list_directory", "description": "...", "inputSchema": {} }
]
}
}
// 5. El LLM decide llamar read_file; cliente envía tools/call
{
"jsonrpc": "2.0", "id": 3, "method": "tools/call",
"params": {
"name": "read_file",
"arguments": { "path": "/Users/yo/proyectos/notas.md" },
"_meta": { // ← extensión donde irá trace context
"traceparent": "00-abc123...-def456-01"
}
}
}
// 6. Server devuelve contenido del archivo
{
"jsonrpc": "2.0", "id": 3, "result": {
"content": [
{ "type": "text", "text": "# Mis notas\n\n..." }
]
}
}

Lo importante a notar: params._meta. Ese es el bag donde MCP convencionalmente pasa metadata transversal, incluyendo trace context. Volveremos en breve.

El problema de observabilidad: por qué tracing tradicional no basta

Hasta aquí la teoría. Bajemos al problema operacional: en un cluster de producción 2026, un agente típico tiene 5-15 servidores MCP conectados simultáneamente, cada uno con 5-20 tools, y cada conversación con el agente puede generar decenas de llamadas a tools encadenadas. Sin observabilidad, depurar incidencias es imposible.

Por qué el tracing genérico (Hubble, OTel sin convenciones MCP) no es suficiente:

Stdio no se ve en la red. Los servidores locales hablan por pipes del SO. Tu Hubble o tu Datadog APM no ven nada; no hay paquetes que capturar. AgentSight (visto en el post anterior de la serie eBPF) con stdiocap lo captura pero da el JSON-RPC en crudo, sin contexto semántico (qué tool es, qué resource, qué prompt).

HTTP genérico tampoco entiende MCP. Si trazas el HTTP a un servidor MCP remoto sin convenciones MCP, ves un POST a /v1 con un body JSON-RPC opaco. Pierdes “qué tool se invocó”, “qué argumentos”, “fue elicitation o sampling”. Métricas RED por endpoint no te sirven; necesitas RED por tool.

JSON-RPC no propaga trace context nativo. A diferencia de HTTP (W3C traceparent header) o gRPC (metadata), JSON-RPC no tiene un campo estándar para trace context. Si no propagas, cada llamada al servidor empieza un trace nuevo desconectado del trace del agente.

Multistep multi-server es muy difícil de seguir. Una sola conversación del usuario puede traducirse en: 1) call a github-mcp get_pr; 2) call a filesystem-mcp read_file para varios archivos; 3) llamada al LLM principal con todo el contexto; 4) call a postgres-mcp query; 5) call a slack-mcp send_message. Sin trace context propagado, son cinco traces inconexos. Con propagación, es un árbol.

La solución: OpenTelemetry semantic conventions for MCP, ya estables en 2026.

OpenTelemetry semantic conventions for MCP

Las GenAI MCP semantic conventions son el set de atributos estandarizados para spans y métricas relacionados con MCP. Se publicaron como parte del subgrupo GenAI de OpenTelemetry SIG y son la primera parte de las semantic conventions GenAI que llegó a estable.

Por qué semantic conventions específicas

Antes de tenerlas, los equipos instrumentaban MCP con las RPC semantic conventions genéricas (las que usarías para gRPC o XML-RPC). Funcionaba a medias. Las conventions MCP-específicas añaden:

Atributos para identificar qué primitiva se ejecutó (mcp.method.name = "tools/call").
Atributos para identificar qué tool/resource/prompt concreto se tocó (mcp.tool.name, mcp.resource.uri, mcp.prompt.name).
Atributos para el flujo bidireccional (sampling/elicitation requests del servidor al cliente).
Atributos para el handshake (mcp.protocol.version, mcp.client.name, mcp.server.name).
Métricas RED estandarizadas por tool (mcp.tool.call.duration, mcp.tool.call.errors).

Los atributos canónicos

Los atributos que cualquier instrumentación MCP-aware debería emitir:

Atributo	Significado	Ejemplo
`mcp.method.name`	Método JSON-RPC	`"tools/call"`
`mcp.tool.name`	Nombre de la tool	`"read_file"`
`mcp.resource.uri`	URI del resource	`"file:///docs/api.md"`
`mcp.prompt.name`	Nombre del prompt	`"code_review"`
`mcp.session.id`	ID de sesión MCP	`"sess-abc123"`
`mcp.protocol.version`	Versión del protocolo	`"2026-03-01"`
`mcp.client.name`	Identidad del cliente	`"ClaudeDesktop/1.2.0"`
`mcp.server.name`	Identidad del servidor	`"filesystem-mcp/0.5.2"`
`mcp.transport`	Transporte usado	`"stdio"` o `"http"`
`mcp.error.code`	JSON-RPC error code	`-32602` (Invalid params)
`gen_ai.usage.input_tokens`	Tokens consumidos (si sampling)	`1240`
`gen_ai.usage.output_tokens`	Tokens generados (si sampling)	`512`

Los dos últimos vienen de las semantic conventions GenAI genéricas y se aplican cuando la llamada MCP involucra sampling (servidor usando el LLM del cliente).

Métricas RED por tool

Más allá de los spans, las semantic conventions definen tres métricas core:

mcp.tool.call.duration (histograma): latencia de cada invocación.
mcp.tool.call.count (counter): número total de invocaciones.
mcp.tool.call.errors (counter): errores por tool.

Etiquetadas con mcp.tool.name, mcp.server.name, mcp.client.name. Pivotables en Grafana para responder “qué tool es la más lenta”, “qué tool falla más”, “qué cliente carga más a qué server”.

Trace context propagation: el truco del `params._meta`

JSON-RPC no tiene cabeceras como HTTP, así que MCP no puede usar traceparent header de W3C directamente. La solución que el ecosistema ha consensuado: propagar trace context en params._meta.

Cuando el cliente MCP envía un tools/call, su instrumentación OTel hace:

import json
from opentelemetry.propagate import inject

carrier = {}
inject(carrier) # rellena con traceparent/tracestate del span activo

params = {
 "name": "read_file",
 "arguments": {"path": "/notas.md"},
 "_meta": carrier, # ← propaga trace context
}

Cuando el servidor recibe, hace lo simétrico:

from opentelemetry.propagate import extract

ctx = extract(request.params.get("_meta", {}))
with tracer.start_as_current_span("tools/call", context=ctx):
 # esta span es hija de la del cliente
 return execute_tool(request.params)

Resultado: el span del servidor es hijo del span del cliente en el árbol de traces. Cuando ves la trace en Tempo o Phoenix, ves toda la cadena: usuario → host → cliente → server → ejecución → respuesta → cliente → host → respuesta al usuario.

Esto requiere que ambos extremos instrumenten consistentemente. Si el server no extrae el contexto, ves spans desconectados pero al menos tienes traceability del lado cliente.

Patrones de instrumentación

Hay tres caminos para instrumentar MCP, en orden creciente de esfuerzo:

1. FastMCP con OpenTelemetry built-in

FastMCP es uno de los frameworks Python más usados para construir servidores MCP. Trae instrumentación OpenTelemetry built-in: cada tool, resource template, prompt operation genera spans automáticamente con las conventions MCP correctas.

from fastmcp import FastMCP
from opentelemetry.sdk.trace.export import OTLPSpanExporter

mcp = FastMCP("my-server", otel_endpoint="https://otel-collector:4318")

@mcp.tool()
def search_docs(query: str) -> str:
 """Search the corpus for matching documents."""
 # esto genera automáticamente un span con
 # mcp.tool.name=search_docs, mcp.method.name=tools/call, etc.
 return run_search(query)

Cero código de instrumentación. Spans con conventions correctas. Es el patrón recomendado si arrancas un servidor MCP en Python desde cero.

2. OpenTelemetry SDK manual

Para servidores ya existentes o en otros lenguajes (TypeScript, Go), la opción es instrumentar manualmente con el SDK estándar OTel + emitir los atributos MCP convencionales:

from opentelemetry import trace
tracer = trace.get_tracer(__name__)

async def handle_tools_call(req: JSONRPCRequest):
 ctx = extract_trace_context(req)
 with tracer.start_as_current_span("mcp.tools.call", context=ctx) as span:
 span.set_attribute("mcp.method.name", "tools/call")
 span.set_attribute("mcp.tool.name", req.params["name"])
 span.set_attribute("mcp.server.name", "filesystem-mcp")
 try:
 result = await execute_tool(req.params)
 return result
 except Exception as e:
 span.set_attribute("mcp.error.code", -32603)
 span.record_exception(e)
 raise

Más boilerplate pero funciona con cualquier servidor existente.

3. MCP Inspector para debugging interactivo

MCP Inspector (oficial) es una herramienta de debugging interactivo a nivel protocolo. Lanza un proxy local (puerto 6277) entre tu cliente y el servidor, y abre una UI web (puerto 6274) donde ves cada mensaje JSON-RPC ida y vuelta en tiempo real.

No es observabilidad de producción —es desarrollo y depuración—. Pero es insustituible durante el bring-up de un servidor nuevo: ves exactamente qué requests llegan, qué responses se devuelven, qué errores se producen. Ahorra horas de logging ad-hoc.

MCP Gateways: la pieza centralizada para enterprise

Cuando tu organización tiene muchos agentes conectándose a muchos servidores MCP, gestionar la matriz de conexiones se vuelve operacionalmente serio. La pregunta natural —"¿puede haber un proxy delante de todos los MCP servers que centralice auth, rate limiting, logging y observabilidad?"— ya tiene respuesta: MCP Gateways.

Un Gateway MCP es un proxy que:

Acepta conexiones MCP de los hosts/agentes.
Las enruta a los servers MCP backend correspondientes.
Aplica autenticación y autorización centralizada (qué agente puede llamar qué tool).
Aplica rate limiting por agente, por tool, por tenant.
Observa: emite métricas OTel de cada operación pasante.
Propaga identidad del agente al servidor backend (con varios modelos: token forwarding, token exchange, impersonación).

Las opciones que se han establecido en 2026:

Traefik Hub MCP Gateway — del equipo de Traefik. Configuración declarativa, integración nativa con el ecosistema Kubernetes/Helm de Traefik.
MintMCP — gateway con foco en observabilidad y multi-tenancy. SaaS y self-host.
OpenObserve MCP Gateway — integrado con la plataforma de observabilidad OpenObserve.

Para deployments pequeños (un equipo, pocos agentes) un Gateway puede ser overkill. Para enterprise (decenas de agentes, decenas de servers, compliance regulado), es prácticamente obligatorio.

Casos de uso reales de la observabilidad MCP

Vamos a aterrizar con cinco casos donde la observabilidad MCP propiamente instrumentada da valor inmediato:

1. Audit por tool, por tenant, por agente

Pregunta: “¿quién ejecutó la tool delete_repo el mes pasado?”. Sin observabilidad MCP, imposible. Con conventions OTel + propagación de identidad: query en tu backend de traces filtrando por mcp.tool.name="delete_repo", agrupando por mcp.client.name o por user_id propagado en _meta. Compliance feliz.

2. Coste por tool y por tenant

Pregunta: “¿cuánto cuesta cada tool?”. Si las tools invocan APIs externas (Stripe, OpenAI sampling) o consumen recursos significativos (GPU para una tool de inferencia), saber su coste agregado importa. Con mcp.tool.call.duration + gen_ai.usage.* agregadas por tool y tenant, se construyen dashboards de cost accountability sin instrumentar nada extra.

3. Debug de cadenas multistep que fallan

Pregunta: “el agente falló al completar esta tarea, ¿dónde fue?”. El trace propagado conecta: span del usuario → span del LLM con su CoT → spans de cada tool invocada → span del LLM final. Si la cadena se rompió en la tercera tool, en Tempo se ve el span rojo con el mensaje de error específico. Reproducir el fallo es trivial.

4. Latencia y degradación de tools

Pregunta: “¿qué tool está degradando?”. Métricas RED por tool en Grafana muestran latencia p95/p99 a lo largo del tiempo. Cuando una tool empieza a subir de 200ms a 800ms (porque el servicio underlying se está colapsando), lo ves antes de que los usuarios se quejen.

5. Detección de loops y anomalías agentic

Pregunta: “¿algún agente está atascado en bucle?”. Si un agente llama tools/call read_file 80 veces en 30 segundos para el mismo path, claramente algo está mal. Alerta sobre mcp.tool.call.count agrupado por (session_id, tool_name) detecta esto. Combinado con detección de loops a nivel de razonamiento, cierra el círculo.

Trampas operativas

Falta de identity propagation

Tu Gateway autentica al agente, pero pasa requests al backend sin propagar identidad. Resultado: los logs del backend dicen “service-account” en todo, imposible auditar quién invocó qué. Elige una estrategia de propagación temprano: token forwarding (sencillo, expone tokens al backend), token exchange (más seguro), o impersonación con logging cruzado.

Servidores stdio que no aparecen en tu APM

Es la trampa nº1 del campo. Tu agente Cursor usa filesystem-mcp como stdio; no ves nada en Datadog porque no hay tráfico de red. Solución: instrumentar el servidor stdio con OTel SDK que exporta por OTLP a tu collector (vía gRPC o HTTP, OTel collector puede recibir aunque el server hable stdio con su cliente). O usar AgentSight stdiocap para capturar el JSON-RPC en crudo y procesarlo offline.

Múltiples versiones de protocolo en producción

Diferentes clientes usan distintas versiones de MCP simultáneamente. Tu metrics dashboard mezcla peras y manzanas. Etiqueta SIEMPRE con mcp.protocol.version y filtra/agrupa por ella.

`_meta` perdido al pasar por proxy

Tu Gateway acepta el request del cliente, lo reescribe para el backend, y se olvida de copiar params._meta. Resultado: trace roto en el Gateway, dos traces inconexos. Asegúrate de que tu Gateway preserva o re-inyecta trace context en cada hop.

Volumen de trazas con servers chatty

Algunos servers MCP emiten muchas pequeñas operaciones (filesystem listings, partial reads). Sin sampling, llenan tu backend de trazas inútiles. Aplica tail-based sampling que conserve sesiones completas o solo conserve traces con errores/latencia alta.

Cardinalidad en métricas

mcp.tool.call.duration con mcp.session.id como label explota la cardinalidad. No incluyas IDs únicos por sesión en labels; mantén la cardinalidad bajo control con labels que toman pocos valores discretos (tool name, server name, client name, error code).

Confundir spans del cliente y del servidor

Cuando ves el árbol, distingue: el cliente ve latencia total desde su perspectiva (incluye network); el servidor ve solo su trabajo. Si miras solo el span del servidor para depurar latencia percibida por el usuario, te pierdes el RTT. Usa ambos.

Lo que no hemos cubierto

MCP transport WebSocket experimental: alternativa a Streamable HTTP, aún no estándar.
Servidores MCP en cloud-native deployments con sidecars: patrón emergente de desplegar MCP servers como sidecars de pods.
MCP federation: composición de varios servers como uno solo (similar a GraphQL federation).
eBPF + MCP: cómo stdiocap de AgentSight y los hooks de Cilium se complementan con la instrumentación nativa.
MCP testing y contract tests: cómo validar que tu servidor cumple la spec.

Referencias

Especificación y conceptos:

Model Context Protocol — sitio oficial — entrada canónica.
MCP architecture overview.
Transports — MCP docs.
MCP Inspector (GitHub) — debugging interactivo.

OpenTelemetry GenAI MCP:

Semantic conventions for Model Context Protocol — OpenTelemetry — referencia normativa.
Adding OpenTelemetry Trace Support to MCP (Discussion #269) — historia de la propuesta.
How to Instrument MCP Servers with OpenTelemetry (OneUptime).
How to trace MCP server tool calls with OpenTelemetry and Elastic APM.
MCP Observability with OpenTelemetry (SigNoz).
Distributed tracing for agentic workflows (Red Hat Developer).
OpenTelemetry for AI Agents in MCP Workflows (MintMCP).

Frameworks y gateways:

FastMCP OpenTelemetry — instrumentación built-in.
Traefik Hub MCP Gateway — gateway de Traefik.
MintMCP — gateway con foco en observabilidad.
OpenObserve MCP Gateway guide.
What is an MCP Gateway (DEV Community).
OpenTelemetry MCP Server (Traceloop) — el patrón inverso: usar MCP para que agentes consulten traces OTel.

Cross-references:

Post anterior: Guardrails y safety.
AgentSight y el nuevo tracing de LLMs — donde se introdujo stdiocap para capturar stdio de servidores MCP locales.
Evals: la capa después del tracing.

Hubble: observabilidad de red en eBPF, estado del arte 2026 y la nueva frontera con los agentes IA

Tue, 19 May 2026 06:00:00 +0200

TL;DR

Hubble es la observabilidad de red nativa de Cilium, construida sobre los mismos programas eBPF que Cilium usa para enforcement. No duplica datapath ni instrumenta el kernel a su manera: escucha los hooks que Cilium ya tiene y produce flow logs estructurados con contexto Kubernetes incluido —pod, namespace, labels, service, verdict de policy, payload L7 cuando aplica—. Es lo que pasa cuando alguien decide que tcpdump con grep no escala a 10 000 pods y construye un sistema distribuido propio (Hubble server por nodo + Hubble Relay como agregador + CLI + UI) con overhead prácticamente cero porque la captura ya estaba ocurriendo. En 2026 está en versión 1.19.3 (abril 2026), con Cilium 1.19 marcando el décimo aniversario del proyecto; ha llegado el tracing por IP options, el filtrado por estado de cifrado, el drop event taggeado con la NetworkPolicy exacta que lo causó (atribución directa), el field mask API estabilizado, y la primera oleada de anomaly detection con ML aplicado a flows para predictive security en clusters IoT/5G. Y, lo más interesante para 2026: aparece una frontera nueva donde el mismo eBPF observa agentes de IA —Claude Code, Gemini CLI, agentes MCP— interceptando SSL/TLS y stdio sin instrumentar el código, lo que convierte el stack Cilium + Hubble + Tetragon + AgentSight en una pila completa para entender qué hace un sistema agentic dentro de un cluster.

Este artículo es la parte 3 de la serie sobre eBPF. Parte 1: eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP. Parte 2: Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel. Aquí completamos el cuadrante de observabilidad: red con Hubble, proceso con Tetragon, agente IA con AgentSight.

La analogía: tcpdump que habla Kubernetes

Si has administrado redes los últimos veinte años, tcpdump y Wireshark han sido el pan nuestro de cada día. Capturan paquetes en una interfaz, los parsean, te dejan filtrar con tcp.port == 443 and host 10.0.0.5. Funcionan, llevan funcionando desde los 90, y son lo primero que abres cuando algo huele raro.

Ahora pega tcpdump a un cluster Kubernetes de 10 000 pods. Los problemas saltan en orden:

Una sesión tcpdump por nodo. Querías “ver el tráfico entre el frontend y la API”; necesitas SSH a cada nodo, tcpdump por cada NIC, sincronizar timestamps, agregar a mano.
No hay contexto K8s. Ves un paquete de 10.244.5.7 a 10.244.8.42. ¿Qué pod era? ¿Qué namespace? ¿Qué label? Te toca correlar con kubectl get pod -A -o wide cada vez.
Sin entender L7. Ves un POST a HTTPS, no puedes saber qué método y path porque está cifrado en el cable. Si hay mTLS entre pods, peor.
Coste alto: captura completa de paquetes con copia a userspace ralentiza el datapath. En tráfico denso, lo notas.

Hubble es tcpdump rediseñado para todo eso. Reutiliza los programas eBPF que ya están procesando cada paquete (Cilium los pone ahí para enforcement) y, mientras toman su decisión de allow/deny, emiten un evento de flow con todo el contexto: identidad del pod origen y destino, namespace, labels, protocolo, verdict, y —si Cilium ha hecho parsing L7 vía Envoy— método HTTP, path, status code, DNS query, Kafka topic. Ese evento viaja por un ringbuffer a userspace, lo recibe el Hubble server que vive dentro del agent Cilium del nodo, y lo expone vía gRPC. Un servicio aparte, Hubble Relay, agrega los streams de todos los nodos y te da una única API cluster-wide. Por encima de eso: una CLI (hubble) y una UI web con grafo de servicios en tiempo real.

Cero copia adicional. Cero parsing duplicado. Y el resultado lo entiende cualquiera que sepa qué es un Pod.

Arquitectura: cuatro piezas que se ven desde fuera

Hubble se compone de cuatro componentes lógicos, todos opcionales según lo que quieras hacer:

1. Hubble Server (embedded en cada agent Cilium)

Vive dentro del proceso del agent Cilium (no es un binario aparte). Cada nodo expone localmente un endpoint gRPC en el socket Unix /var/run/cilium/hubble.sock. El server escucha los eventos que los programas eBPF emiten al ringbuffer, los enriquece con metadata Kubernetes (que el agent ya tiene en memoria), y los pone disponibles para consumidores.

Activación: --set hubble.enabled=true en el chart Helm de Cilium. Por defecto, el server solo es accesible localmente; si quieres consumirlo desde otro nodo, hace falta exponerlo (lo que hace Hubble Relay).

2. Hubble Relay (agregador)

Es un Deployment aparte (típicamente 1 réplica, escalable) que se conecta a todos los Hubble servers del cluster y agrega sus streams en una única API. Cuando tu CLI o UI pide “los últimos 1000 flows del cluster”, la Relay los recoge en paralelo de todos los nodos y devuelve la unión.

Activación: --set hubble.relay.enabled=true. Sin la Relay, solo ves el tráfico del nodo donde estás conectado, lo que es útil para debug local pero no para visión cluster-wide.

3. Hubble CLI (`hubble`)

Un binario en Go que habla gRPC con la Relay (o con un Hubble server local). Soporta dos modos principales:

hubble observe: stream de flows en tiempo real, con filtros muy expresivos (por namespace, pod, port, verdict, protocolo, label).
hubble status: estado del cluster Hubble (cuántos nodos conectados, lag, flow rate).

Y el equivalente a tcpdump’s pcap dump: hubble observe --output jsonpb > flows.json para procesar a posteriori con jq u otras herramientas.

4. Hubble UI

Frontend web que se conecta a Hubble Relay y muestra:

Grafo de servicios en tiempo real (qué Pod habla con qué Service, qué protocolos usa, qué verdict).
Lista de flows filtrable.
Detalles L7 cuando los hay (HTTP method/path/status, DNS query/response).

Activación: --set hubble.ui.enabled=true. Útil para presentaciones a equipos no-CLI; no sustituye a la CLI para debug serio.

Qué se ve: el flow log de Hubble por dentro

Un flow de Hubble en formato JSON tiene aproximadamente esta forma (simplificado):

{
 "time": "2026-05-19T03:12:45.182Z",
 "verdict": "FORWARDED",
 "source": {
 "ID": 5482,
 "identity": 24871,
 "namespace": "prod-api",
 "labels": ["app=checkout", "team=payments"],
 "pod_name": "checkout-7c9f-x8j2",
 "workloads": [{"name": "checkout", "kind": "Deployment"}]
 },
 "destination": {
 "ID": 12041,
 "identity": 18356,
 "namespace": "prod-db",
 "labels": ["app=postgres", "tier=primary"],
 "pod_name": "postgres-0"
 },
 "Type": "L3_L4",
 "l4": {
 "TCP": {
 "source_port": 41982,
 "destination_port": 5432,
 "flags": {"SYN": true}
 }
 },
 "node_name": "rke2-worker-03",
 "Summary": "TCP Flags: SYN"
}

Cuando hay parsing L7 activo (vía Envoy embebido o el parser ligero de Hubble), el mismo flujo añade:

"l7": {
 "type": "REQUEST",
 "http": {
 "code": 200,
 "method": "GET",
 "url": "/api/v1/cart/items",
 "protocol": "HTTP/1.1",
 "headers": [{"key": "user-agent", "value": "checkout/1.4.2"}]
 }
}

Los protocolos soportados nativamente para parsing L7:

HTTP/1.1 y HTTP/2 (incluyendo gRPC sobre HTTP/2).
DNS (queries y responses, con domains, tipos, response codes).
Kafka (topics, API keys).
TLS handshake (SNI, no el payload cifrado por defecto).
MySQL, Cassandra (con módulos opcionales).

Para HTTP y gRPC, Cilium puede activar el proxy Envoy embebido para los flujos que quieras inspeccionar (no todos; selectivo via CiliumNetworkPolicy con reglas L7). Sin Envoy hay parsing ligero pero menos detallado.

Verdict y atribución de drops

Cada flow tiene un verdict: FORWARDED, DROPPED, ERROR, AUDIT, REDIRECTED, TRACED, TRANSLATED. Para el caso DROPPED, Hubble incluye una razón estructurada (drop_reason) y, desde Cilium 1.19, la NetworkPolicy exacta que lo causó.

Esto último cambia la operativa. Antes, cuando un pod no podía hablar con otro, el flujo de debug era:

Ver el flow dropeado en Hubble.
Mirar todas las CiliumNetworkPolicy del namespace.
Razonar a mano cuál de ellas, con cuáles labels, lo está bloqueando.

Con la atribución de Cilium 1.19, el campo policy_match_info te dice directamente “lo dropeó la policy frontend-egress, regla 3”. Pasas de “Sherlock Holmes durante 20 minutos” a “kubectl get -o yaml de esa policy concreta”.

Métricas Prometheus y dashboards Grafana

Hubble también expone métricas agregadas en formato Prometheus, separadas del stream gRPC de flows. Activación: --set hubble.metrics.enabled=true (Helm) y enumeración del set que quieres exportar.

Los grupos de métricas habituales:

flow: total flows por verdict, source/dest, protocolo.
http: requests por método, código de respuesta, latencia (histograma).
dns: queries, response codes, dominios top-N.
tcp: handshakes, retransmisiones, ventana congestion.
drop: drops por razón, con NetworkPolicy attribution.
port-distribution: histograma de ports activos.
policy: hits por policy y verdict.

Estas métricas tienen labels K8s ricos (source_workload, destination_workload, namespace, etc.) que las hacen pivotables en Grafana. Hay dashboards prebuilt en Grafana Labs que cubren los casos comunes; importar uno y tener visión inmediata cuesta cinco minutos.

Coste: las métricas con muchos labels K8s pueden explotar la cardinalidad en Prometheus. Para clusters grandes (>1 000 pods), conviene revisar qué set exportas y usar drop rules en Prometheus para limitar.

Despliegue: Helm en una pantalla

Instalación canónica de Cilium con Hubble completo:

# values.yaml
hubble:
 enabled: true
 metrics:
 enabled:
 - dns:query;ignoreAAAA
 - drop
 - tcp
 - flow
 - port-distribution
 - icmp
 - httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction
 serviceMonitor:
 enabled: true # auto-discover por kube-prometheus-stack
 relay:
 enabled: true
 rollOutPods: true
 ui:
 enabled: true
 rollOutPods: true
 ingress:
 enabled: true
 className: cilium
 hosts:
 - hubble.example.local

Y la instalación:

helm upgrade --install cilium cilium/cilium -n kube-system -f values.yaml

Tras la instalación, valida con cilium status (CLI de Cilium) que la sección Hubble muestra OK, y prueba el primer flow con:

cilium hubble observe --namespace prod-api --pod checkout-7c9f-x8j2

Estado del arte en 2026

Cilium 1.19 se publicó en febrero de 2026 marcando el décimo aniversario del proyecto. Hubble alcanzó la versión 1.19.3 el 22 de abril de 2026. Las novedades relevantes:

Atribución directa de drops a NetworkPolicy

Ya cubierta arriba; es probablemente el cambio operacional más valioso del release. Cualquier flow dropeado lleva el nombre, namespace y regla específica de la policy responsable. Aplicable también vía métricas Prometheus, lo que permite alertas tipo “policy X está dropping >N peticiones/segundo”.

Tracing con IP options

Hubble puede ahora trazar paquetes individuales con IP options activado. Es un mecanismo similar al traceroute pero a nivel L3: pones una marca en el paquete y Cilium la reporta cada vez que el paquete atraviesa un nodo o una decisión de eBPF. Útil para debug de paths multi-cluster, fabric mesh, o NetworkPolicy que se aplican en distintas capas.

Filtrado por estado de cifrado

Nuevo flag en CLI: hubble observe --encryption-status=encrypted (o unencrypted). Útil para validar despliegues con WireGuard o IPsec activado pod-a-pod: confirmas que el tráfico que debería estar cifrado lo está, y detectas regresiones rápidamente.

Hubble field mask API estabilizado

El field_mask permite pedir solo las partes del flow que te interesan, reduciendo enormemente el ancho de banda y el procesamiento cuando solo necesitas, por ejemplo, source/dest y verdict. Antes era experimental, ahora está estable y es default-on en la CLI.

AI-driven anomaly detection (predictive security)

Esta es la incorporación más comentada de 2026. Cilium 1.19 añade hooks para que un consumer externo —típicamente un sistema ML— procese los flows en streaming y detecte anomalías estadísticas: pods que de pronto hablan con destinos nuevos, picos de latencia en una API, secuencias raras de DNS. La parte de detección ocurre fuera del agent Cilium (no se quiere ML pesado en el datapath), pero Cilium expone los flows con las features pre-calculadas que el modelo necesita. Los casos de uso publicados se enfocan en IoT y 5G donde el tráfico es alto en volumen y bajo en variedad, condiciones ideales para anomaly detection.

Escala a 10 000+ pods

Cilium 1.19 ha hecho trabajo serio en escalabilidad: Hubble Relay puede ahora agregar streams de cientos de nodos sin saturar; el field_mask por defecto reduce el ancho de banda inter-nodo; y los flows pueden samplearse en alta carga si tu uso es análisis estadístico (no debug forense).

Cilium 1.20 en desarrollo

Cilium 1.20 está en branch de desarrollo. Lo más relevante para Hubble:

Unificación de preferIpv6: el flag hubble.preferIpv6 se deprecó en favor del global preferIpv6 aplicable a todos los componentes Cilium.
tetragon-python SDK: aunque es de Tetragon, no de Hubble, marca tendencia: políticas eBPF escritas en Python en lugar de YAML. Probablemente Hubble seguirá camino similar.

La nueva frontera: eBPF y los agentes de IA

Hasta aquí el contenido clásico de Hubble. Pero hay un giro 2026 que merece la pena cubrir porque cierra el círculo con la otra serie de este blog.

Cuando un cluster Kubernetes empieza a ejecutar agentes de IA —Claude Code, Gemini CLI, agentes basados en LangGraph que llaman APIs y MCP servers—, el problema de observabilidad cambia de forma. Ya no basta con saber “qué pod habló con qué pod” (eso es Hubble) ni “qué proceso ejecutó qué” (eso es Tetragon). Necesitas saber:

A qué APIs externas está llamando el agente y con qué prompts.
Qué herramientas MCP está invocando, con qué argumentos.
Cuántos tokens consume, qué modelo elige, cuánto cuesta.
Si el agente se desvía del comportamiento esperado (out-of-policy queries, intentos de jailbreak, leakage de secretos).

Las soluciones tradicionales —instrumentar el código del agente con OpenTelemetry, parsear logs estructurados— no funcionan bien cuando el agente es un binario de terceros (Claude Code de Anthropic, Gemini CLI de Google) o cuando los MCP servers viven en otros lenguajes con stdio como transport.

AgentSight: zero-instrumentation para agentes LLM

AgentSight (proyecto del grupo eunomia-bpf, mismo ecosistema de varios runtimes eBPF de alto perfil) ataca este problema con la misma filosofía que Hubble: no instrumentes; escucha. Pone hooks eBPF en dos puntos críticos:

uprobes en bibliotecas SSL/TLS (libssl, boringssl, rustls). Captura el plaintext antes del cifrado en send y después del descifrado en recv. Para una llamada HTTP a https://api.anthropic.com/v1/messages, AgentSight ve el JSON completo del prompt y la respuesta sin descifrar nada en transit, simplemente porque ha llegado al nivel del syscall antes de que la TLS layer haga su trabajo.
stdiocap BPF: captura read, write, dup sobre los file descriptors de stdin/stdout/stderr de un proceso. Esto es lo que permite observar MCP servers que hablan stdio con su cliente —el patrón habitual de los servers MCP locales—. Capturas el JSON-RPC que va y viene sin que ni el cliente ni el server lo sepan.

Sobrecarga reportada: <3% CPU, comparable a Hubble en su régimen.

Cómo encaja con Hubble y Tetragon

Los tres se complementan limpiamente:

Hubble te dice: “el pod del agente abrió conexión TCP a api.anthropic.com:443 con verdict ALLOW”.
Tetragon te dice: “el proceso claude-code con PID 1843 hizo connect() a esa IP” (más el binario, los argumentos, el namespace de pod).
AgentSight te dice: “el contenido HTTPS de esa conexión era un prompt messages=[{role:'user', content:'analyze this repo and modify the firewall config'}] y la respuesta incluyó una tool call a read_file con argument /etc/passwd”.

Es la diferencia entre flujo, proceso y semántica. Para un equipo de seguridad que quiera vigilar agentes de IA en producción, los tres son necesarios. Para alguien que quiera entender el coste, los tres son útiles (Hubble para latencia de red, Tetragon para uso de recursos, AgentSight para tokens y modelo elegido).

Casos de uso emergentes

Los patrones que se están consolidando en 2026:

Audit trail de agentes: registrar cada llamada a LLM y cada tool call para compliance (sobre todo en sectores regulados).
Detección de jailbreak y prompt injection: aplicar reglas sobre los prompts capturados por AgentSight (similar a las TracingPolicy de Tetragon, pero sobre contenido semántico).
Cost accountability: ver qué team/agente consume qué tokens, sin instrumentar.
Replay y debug: reproducir el reasoning de un agente en producción sin pedirle que vuelva a ejecutar (que es no-determinístico).

Es un campo joven —AgentSight tiene meses, no años— pero el patrón “eBPF como observabilidad zero-instrumentation” está clarísimamente extendiéndose más allá de red y proceso. El próximo año va a ver consolidación y, probablemente, integración nativa con Hubble.

Casos de uso habituales de Hubble

Volviendo a Hubble propiamente, los casos en los que cualquier organización lo despliega:

1. Debug de NetworkPolicy

El uso clásico: “este pod no llega a este Service”. Sin Hubble, tocaba SSH, tcpdump, comparar reglas. Con Hubble:

hubble observe --from-pod prod-api/checkout --to-pod prod-db/postgres --verdict DROPPED

Si hay drops, ves la policy responsable (Cilium 1.19+). Si no hay drops, el problema no es policy: es DNS, routing o el target service.

2. Audit de comunicación inter-namespace

Para compliance: validar que namespaces aislados no están comunicándose contra lo declarado.

hubble observe --from-namespace prod-payments --to-namespace 'NOT prod-db' --output json

3. Detección de exfiltración

Tráfico saliente a destinos públicos sospechosos. Hubble los detecta por IP/SNI, no por payload (que está cifrado):

hubble observe --to-fqdn 'NOT *.example.com' --to-fqdn 'NOT *.internal' --protocol tcp

Combinado con métricas Prometheus y alertas en Grafana, esto da un radar de exfiltración a coste cero.

4. SLO de servicio en tiempo real

Métricas hubble:http:response_time_seconds con labels source_workload, destination_workload, method, status_code permiten dashboards SLO sin necesidad de instrumentar las apps. El SRE ve la latencia p95 de checkout → catalog directamente.

5. Performance debugging

hubble:tcp:retransmissions_total y hubble:tcp:flags_total{flag="RST"} son señales tempranas de problemas de red. Una subida correlada con regresión de latencia te apunta a algo en infraestructura (NIC, switch, MTU) antes de bajar a investigar la app.

6. Forensics post-incidente

Configurar Hubble para exportar flows a almacenamiento persistente (vía OTLP a Tempo/Loki, o hubble observe --output jsonpb a S3) te da capacidad forense: si en T+30 días detectas que algo iba mal en T, puedes reconstruir el tráfico.

Hubble y el resto del stack de observabilidad

Hubble no reemplaza Prometheus, Loki, Tempo ni Jaeger; los complementa:

Prometheus: recibe las métricas agregadas de Hubble. Hubble exporta endpoint Prometheus nativo.
Loki: recibe los flow logs estructurados si los exportas como logs. Hubble no tiene exporter nativo a Loki, pero un Fluent Bit con plugin OTLP o uno custom hace el puente fácilmente.
Tempo / Jaeger: el Cilium Operator tiene exportador OTLP de flows en formato traces (cada flujo HTTP/gRPC es un span). Integra con Tempo o cualquier otro tracing backend OTLP.
Grafana: ya hay dashboards públicos de Hubble. Combinados con Prometheus, Loki y Tempo, te dan un panel unificado: métricas, logs, traces, todo correlado por labels K8s.

La pila full-stack que se ve en producción 2026 (descrita en Building a Production eBPF Observability & Security Stack for Kubernetes in 2026):

Datos: Cilium + Hubble (red), Tetragon (proceso), AgentSight (agente IA).
Pipeline: OTLP Collector como router único.
Almacenamiento: Prometheus (métricas), Loki (logs), Tempo (traces).
UI: Grafana con dashboards específicos por dominio.
Alerting: AlertManager con reglas sobre las métricas Hubble + Tetragon.

Comparativa con alternativas

Sistema	Capa	Foco	Modelo
Hubble	L3-L7 red	Cluster K8s con Cilium	eBPF, pull metrics, push flows gRPC
GKE Dataplane v2 obs	L3-L7 red	GKE managed	eBPF (Cilium-based, gestionado)
Tigera Calico Whisker	L3-L7 red	Cluster con Calico	eBPF + pcap, UI propia
Tetragon	Proceso/syscall	Cluster K8s	eBPF, push events gRPC
Falco	Proceso/syscall	Cluster K8s	eBPF en userspace o módulo kernel
AgentSight	Agente LLM	Sistemas agentic	eBPF (SSL uprobes + stdio)
Beyla (Grafana)	Aplicación	App L7 + tracing	eBPF (uprobes en libs)
Pixie	App + sistema	Visibilidad cluster amplia	eBPF + script PXL
Parca	Profiling CPU/mem	Performance	eBPF profile sampling

Si tu CNI es Cilium, Hubble es el punto de entrada natural y no compite con los demás: complementa. Para clusters Calico, Whisker es el equivalente. Para profiling, Parca. Para agentes IA, AgentSight. La era del “una herramienta para todo” está pasando: la pila moderna combina varias piezas especializadas, todas basadas en eBPF, expuestas vía OTLP.

Trampas operativas

Cardinalidad en Prometheus

Las métricas Hubble con todos los labels K8s pueden explotar Prometheus. Mide la cardinalidad antes de exportar todo. Las métricas más prolíficas son flow y httpV2; empieza por drop y port-distribution y añade el resto incrementalmente.

L7 visibility cuesta CPU

Activar parsing L7 vía Envoy embebido añade carga al agent (no al datapath base, pero sí al envoy proxy del nodo). Para tráfico HTTP intenso, mide. Para flujos donde solo necesitas L4, deja Envoy desactivado.

Hubble Relay sin HA

Una sola réplica de Relay es un single point of failure para CLI y UI (no para el agent local, que sigue funcionando). Para producción, deploy con replicas: 2+ y topologySpreadConstraints para que no caigan ambas.

Encryption status reporting depende de Cilium config

El nuevo filtro --encryption-status solo da datos reales si Cilium tiene encryption activado (WireGuard o IPsec). Sin esto, todo es unencrypted y el filtro no aporta.

UI expuesta sin auth

Hubble UI no tiene auth nativa. Si la expones por Ingress, delante tiene que haber autenticación: OIDC vía oauth2-proxy, mTLS, IP allowlist. No es opcional.

Storage no escalado

Si guardas flows durante días para forensics, el volumen es serio. Para un cluster de 100 pods activos, fácilmente 1-10 GB/día de flow logs. Plantea el ciclo de vida (compactación, retención, cold storage) antes de habilitarlo.

Lo que no hemos cubierto

Mesh / multi-cluster Hubble: agregar flows de varios clusters Cilium en una sola Relay. Caso de uso: visión cross-cluster, debug de service mesh distribuido.
hubble export: persistencia local en disco del agent para forensics con baja retención.
Anomaly detection con modelos propios: cómo conectar el stream gRPC a un consumer ML personalizado.
AgentSight en profundidad: el proyecto merece su propio artículo. Próxima entrega.
eBPF para profiling de LLM serving: cómo medir TTFT, TPOT y throughput de vLLM sin instrumentar, usando uprobes en libcudart.

Referencias

Hubble y Cilium:

Hubble GitHub — repo principal.
Hubble — Network Observability (Cilium docs) — referencia oficial.
Cilium 1.19 release notes (InfoQ, feb 2026) — décimo aniversario y novedades 1.19.
Cilium releases — todos los releases.
Hubble L7 HTTP Metrics — Grafana dashboard 19423 — listo para importar.
End‑to‑end L7 Visibility with Cilium Hubble (cloud-cod.com, mar 2026).
Cilium Hubble Observability Platform Internal Analysis (Young-ju).
CiliumNetworkPolicy Python Hubble: L7 Visibility 2026 — uno de los hilos del SDK Python.

Estado del arte 2026 y stack completo:

eBPF + agentes IA:

AgentSight (GitHub eunomia-bpf) — el proyecto referenciado.
Harnessing eBPF for High‑Performance LLM Workloads (Klizo Solutions).

Cross-references:

Parte 1: eBPF de cero a Cilium.
Parte 2: Tetragon: el primo de seguridad de Cilium.
Serie de inferencia LLM: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s — donde el tráfico que Hubble observa lleva los prompts que AgentSight inspecciona.

Mcp on lo0 — Blog Técnico

MCP por dentro y su observabilidad profunda: el LSP de los agentes IA y cómo verlo todo con OpenTelemetry

TL;DR

La analogía maestra (en tres versiones)

Versión 1 — El USB-C de las apps IA (la oficial)

Versión 2 — El LSP de los editores de código (la más técnicamente precisa)

Versión 3 — El driver del sistema operativo (la operativa)

Qué problema concreto resuelve MCP

La arquitectura: tres roles, situados con claridad

Host: la aplicación IA

Cliente: la conexión, una por servidor

Servidor: la pieza que expone capacidades

Resumen del lugar de cada cosa

Las dos capas del protocolo

Data Layer: JSON-RPC con extensiones MCP

Transport Layer: cómo se mueven los mensajes

Las seis primitivas: situadas en la arquitectura

Server-side: lo que el servidor le da al host

Client-side: lo que el host le da al servidor

Visualización del flujo de las seis primitivas

El JSON-RPC en acción: un ejemplo concreto

El problema de observabilidad: por qué tracing tradicional no basta

OpenTelemetry semantic conventions for MCP

Por qué semantic conventions específicas

Los atributos canónicos

Métricas RED por tool

Trace context propagation: el truco del params._meta

Patrones de instrumentación

1. FastMCP con OpenTelemetry built-in

2. OpenTelemetry SDK manual

3. MCP Inspector para debugging interactivo

MCP Gateways: la pieza centralizada para enterprise

Casos de uso reales de la observabilidad MCP

1. Audit por tool, por tenant, por agente

2. Coste por tool y por tenant

3. Debug de cadenas multistep que fallan

4. Latencia y degradación de tools

5. Detección de loops y anomalías agentic

Trampas operativas

Falta de identity propagation

Servidores stdio que no aparecen en tu APM

Múltiples versiones de protocolo en producción

_meta perdido al pasar por proxy

Volumen de trazas con servers chatty

Cardinalidad en métricas

Confundir spans del cliente y del servidor

Lo que no hemos cubierto

Referencias

Hubble: observabilidad de red en eBPF, estado del arte 2026 y la nueva frontera con los agentes IA

TL;DR

La analogía: tcpdump que habla Kubernetes

Arquitectura: cuatro piezas que se ven desde fuera

1. Hubble Server (embedded en cada agent Cilium)

2. Hubble Relay (agregador)

3. Hubble CLI (hubble)

4. Hubble UI

Qué se ve: el flow log de Hubble por dentro

Verdict y atribución de drops

Métricas Prometheus y dashboards Grafana

Despliegue: Helm en una pantalla

Estado del arte en 2026

Atribución directa de drops a NetworkPolicy

Tracing con IP options

Filtrado por estado de cifrado

Hubble field mask API estabilizado

AI-driven anomaly detection (predictive security)

Escala a 10 000+ pods

Cilium 1.20 en desarrollo

La nueva frontera: eBPF y los agentes de IA

AgentSight: zero-instrumentation para agentes LLM

Cómo encaja con Hubble y Tetragon

Casos de uso emergentes

Casos de uso habituales de Hubble

1. Debug de NetworkPolicy

2. Audit de comunicación inter-namespace

3. Detección de exfiltración

4. SLO de servicio en tiempo real

5. Performance debugging

6. Forensics post-incidente

Hubble y el resto del stack de observabilidad

Trace context propagation: el truco del `params._meta`

`_meta` perdido al pasar por proxy

3. Hubble CLI (`hubble`)