Observabilidad on lo0 — Blog Técnico

eBPF en inferencia local y detección estadística de drift: el cierre del ciclo de observabilidad LLM en 2026

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

TL;DR

Tracing, evals, guardrails, MCP observability: las capas que ya hemos cubierto ven qué está pasando ahora mismo. Lo que no ven es lo que cambia silenciosamente: el agente que la semana pasada respondía bien y esta semana, sin que nadie haya tocado nada, responde algo peor. Lo que no ven tampoco es la mecánica fina de la inferencia local: por qué un llama.cpp en un edge device tarda 200 ms cuando debería tardar 100, qué función del runtime concreta es el cuello. Este post cierra las dos series de la semana con las dos capas que faltaban: eBPF aplicado a inferencia local (uprobes en llama.cpp, vLLM, libcudart.so, hardware perf counters integrados, con <4% de overhead — formalizado en el paper ProfInfer 2026 que es a inferencia local lo que Hubble es a la red) y análisis estadístico de flows de agentes para detectar drift antes de que tu usuario lo note (KS, PSI, MMD, embedding-space clustering, con Evidently AI, NannyML y WhyLabs como herramientas dominantes). Las tres tipologías de drift LLM en 2026 — prompt drift, model drift, eval-score drift — exigen tests distintos. El stack completo —tracing, evals, guardrails, MCP observability, eBPF observability, drift detection— forma el bucle que cualquier sistema agentic serio necesita para operar con SLA real, no con esperanza.

Este post cierra dos series: la serie post-tracing (Evals, Guardrails, MCP observability) y la serie eBPF (eBPF de cero a Cilium, Tetragon, Hubble, AgentSight). Junta los dos hilos: eBPF aplicado al motor de inferencia local + análisis estadístico de los flows que todas las capas producen.

La analogía: el cardiograma del agente

Un médico que sólo mira síntomas agudos —el paciente llega con fiebre alta, hay que actuar— está haciendo medicina reactiva. Para hacer medicina preventiva, necesita series temporales: la tensión arterial cada año, el colesterol cada seis meses, el ECG cuando hay sospecha. No es información de “ahora mismo”, es información sobre cómo evoluciona algo que debería estar estable. Cuando una serie temporal se desvía de su línea base, hay que investigar antes de que sea fiebre alta.

Las capas de observabilidad LLM que llevamos vistas son medicina reactiva: tracing te dice qué pasó en una conversación concreta; evals te dice si esa conversación fue buena; guardrails te dice si había una amenaza específica; MCP observability te dice qué tools se invocaron y cómo. Todas miran eventos, no tendencias.

Drift detection es la medicina preventiva. Mira series temporales —de embeddings de prompts, de scores de evaluación, de distribuciones de tokens generados— y dispara alertas cuando algo se aleja de su normalidad. No te dice “esta respuesta es mala”; te dice “la distribución de prompts de las últimas 6 horas no se parece a la distribución del último mes”. Ahí decides si investigar.

Y la otra mitad del post —eBPF en inferencia local— es el equivalente al resonador magnético: cuando ya sabes que hay un problema, te permite ver el interior del modelo a una resolución que ningún wrapper externo da. Ver qué función concreta del runtime tarda, qué kernel CUDA es el cuello, cómo se mueven los tokens en los buffers internos antes de salir al cliente.

Las dos juntas cierran el ciclo: las series temporales detectan que algo va mal, el resonador localiza dónde.

Parte 1 — eBPF aplicado a inferencia local

Por qué la inferencia local cambia el juego

Cuando el LLM corre localmente —vLLM en un nodo Kubernetes, llama.cpp en un edge device, Ollama en una workstation, MLX en macOS— y no detrás de una API externa, la observabilidad cambia de forma:

Controlas el binario: puedes adjuntar hooks que de otra manera serían imposibles.
Los buffers internos existen en RAM accesible: el stream de tokens-output, los logits, las cachés KV, las estructuras de scheduler están ahí, en direcciones que un uprobe puede leer.
No hay cable que esnifar: la analogía de AgentSight con SSL hooks no aplica porque no hay TLS — el modelo te responde con un retorno de función en proceso, no con una respuesta HTTPS.
La distancia entre kernel y modelo es mínima: los kernels CUDA que ejecutan la atención están a una syscall de profundidad; eBPF puede observar ambos lados de esa frontera con el mismo trazador.

Esto abre una clase de observabilidad que con LLM-as-a-service (API de Anthropic, OpenAI, Vertex) es estructuralmente imposible. Para apps que sirven inferencia on-premise o on-edge — un cluster de inference, un dispositivo móvil, un servidor RTX 4090 en el rack — es una capa nueva.

ProfInfer: el paper que formaliza el patrón

ProfInfer (arxiv 2601.20755, 2026) es la pieza académica de referencia que sistematiza lo que el ecosistema venía haciendo de manera ad-hoc. El subtítulo del paper lo dice todo: An eBPF-based Fine-Grained LLM Inference Profiler.

Lo que propone:

Atachar uprobes dinámicamente a funciones runtime de motores como llama.cpp (y por extensión vLLM, Ollama). No recompila, no modifica el código fuente. Es como bpftrace para inferencia LLM.
Combinar runtime events con hardware performance counters. Una uprobe te dice cuándo se ejecuta llama_decode; un hardware counter te dice cuántas instrucciones flotantes se ejecutaron mientras estaba dentro. La correlación entre ambas es lo que da la resolución fina.
<4% overhead medido en cargas reales. Es coste de producción.
Visualizaciones en tres vistas: operadores (qué operaciones tensoriales se ejecutaron), grafos (cómo se relacionan), timelines (cuándo).

El paper se enfoca especialmente en modelos en plataformas móviles (Llama servido en un Pixel o iPhone), donde la observabilidad clásica con Prometheus y métricas exportadas casi no existe. Pero el patrón aplica a cualquier inferencia local.

Dónde hookear: el mapa por motor

Vamos al detalle de los hooks. Las funciones objetivo varían por motor:

llama.cpp

llama.cpp es C++ puro, símbolos visibles en el binario. Los hooks típicos:

llama_decode: la función que ejecuta una pasada de inferencia (procesa el batch actual). Spans para latencia por iteration, tokens procesados.
llama_token_to_piece: convierte un token ID a texto. Hook aquí captura el stream de tokens generados antes de devolver al caller. Es el equivalente local a las uprobes de SSL: ves la salida del modelo sin que llegue siquiera al consumidor.
llama_get_logits: lee los logits del último decode. Si quieres registrar las probabilidades del modelo (no solo el token elegido), aquí.
ggml_compute_forward_* (varias funciones): los kernels de operaciones (matmul, attention, layernorm). Hooks para profiling por operación.
ggml_backend_*: las funciones del backend (CPU, Metal, CUDA, ROCm). Hooks aquí desglosan el coste por dispositivo.

Ejemplo con bpftrace:

# Latencia y count de llama_decode
bpftrace -e '
uprobe:/path/to/llama-server:llama_decode {
 @start[tid] = nsecs;
}
uretprobe:/path/to/llama-server:llama_decode /@start[tid]/ {
 @decode_lat = hist((nsecs - @start[tid]) / 1000);
 delete(@start[tid]);
}
'

Salida: histograma de latencias de decode en microsegundos. Cero modificación al binario.

vLLM

vLLM es Python en su mayor parte. Los símbolos C/CUDA están en sus extensiones nativas (vllm._C, vllm._moe_C). Los hooks típicos:

uprobes en vllm._C.* para operadores custom (paged attention kernel, sampling kernel).
uprobes en libcudart.so y libcuda.so para capturar cudaMalloc, cudaLaunchKernel, cudaMemcpy. Sirve para mapear costes de transferencias host↔device y de lanzamientos de kernels.
Tracepoints Python con bpftrace sobre usdt puntos: vLLM no expone tracepoints estáticos nativos, pero se pueden colocar con USDT (dtrace style) en lugares estratégicos del scheduler.

vLLM expone además métricas Prometheus nativas (vllm:num_requests_running, vllm:gpu_cache_usage_perc, etc.). El valor añadido del enfoque eBPF es bajar de las métricas del scheduler a las funciones individuales: cuando una request es lenta, ver si fue prefill, decode, scheduler overhead, transferencia o sincronización.

CUDA en general

Independiente del motor, las uprobes en libcudart.so capturan toda la actividad CUDA del proceso:

cudaMalloc(size) → tracking de allocations en device memory.
cudaLaunchKernel(func, ...) → spans por cada lanzamiento de kernel.
cudaMemcpyAsync(dst, src, size, kind) → transferencias host↔device.
cudaStreamSynchronize(stream) → puntos de sincronización (donde el host espera al device).

Esto te da una timeline completa de actividad CUDA sin necesidad de NVIDIA Nsight Systems (que es excelente pero pesado y orientado a desarrollo, no a producción continua).

Hardware counters: la otra mitad

eBPF puede leer performance counters del PMU (Performance Monitoring Unit) del CPU/GPU. Esto incluye instrucciones ejecutadas, cache misses, branch mispredictions y, en GPUs con soporte, FLOPS, ocupación de SM, ancho de banda HBM.

Combinar:

uprobe: “se ejecutó llama_decode desde T1 a T2 con tokens=4”.
perf counter: “durante esa ventana, cache misses L2 = 15000, instrucciones = 2.3 millones”.

Permite responder: ¿por qué tarda? ¿es memory-bound (muchos cache misses), compute-bound (todas las instrucciones en FPU), bandwidth-bound (mucho movimiento de datos)? Estado del arte para profiling profesional.

Comparativa con AgentSight

Hay dos productos eBPF para LLMs hoy con foco distinto:

AgentSight (cubierto en la serie eBPF): observa agentes que llaman a APIs externas. Hookea SSL para ver el plaintext de las llamadas HTTPS al LLM remoto, más stdio para servers MCP locales. Visión cliente.
ProfInfer / patrón de eBPF en inferencia local: observa el motor que ejecuta el modelo localmente. Hookea las funciones internas del motor (llama.cpp, vLLM) y la capa CUDA. Visión servidor (interno).

Son complementarios. Si tu agente usa Claude API + tu propio vLLM local con Llama 3 para tareas específicas, AgentSight ve lo primero, eBPF/ProfInfer ve lo segundo. Si todo es local, dominio claramente del segundo. Si todo es API externa, del primero.

Casos de uso de eBPF en inferencia local

Tres casos donde es la herramienta correcta:

Profiling fino para optimización: tu vLLM tarda 50ms más por token de lo esperado. Con eBPF + hardware counters localizas en qué kernel concreto. Antes esto requería Nsight Systems en una sesión de desarrollo; ahora es continuo en producción.

Token-level observability sin modificar el motor: capturar el stream de tokens generados antes de devolverlos al cliente. Útil para auditoría, para drift detection sobre los outputs, para tracing local sin pasar por instrumentación del wrapping.

Detección de degradación específica: una versión nueva de vLLM mete una regresión sutil en el paged attention. Con baselines de perf counters, detectas el cambio incluso si la métrica externa (tokens/sec) parece igual.

Parte 2 — Análisis estadístico de flows: detectar drift

Pasamos al otro lado del problema: las series temporales.

Por qué tracing, evals y guardrails no detectan drift

Las capas que ya hemos visto operan sobre eventos individuales:

Tracing: una traza de una conversación.
Evals: un score de una respuesta.
Guardrails: un veredicto sobre un prompt o respuesta.
MCP observability: spans de una invocación de tool.

Cada uno responde a una pregunta puntual ("¿está bien esto?"). Ninguno responde a la pregunta de evolución ("¿está cambiando algo a lo largo del tiempo?").

El problema operacional: drift es invisible en eventos individuales. Si el score medio de eval baja de 0.92 a 0.85 a lo largo de tres semanas, ninguna evaluación individual marcará alarma —todas siguen siendo “razonables”—. Lo que cambia es la distribución. Y eso solo se ve mirando muchas evaluaciones agregadas en el tiempo.

Las tres tipologías de drift LLM en 2026

FutureAGI las consolida así, y la industria está convergiendo en este vocabulario:

1. Prompt drift: alguien actualiza el prompt sistema y los efectos secundarios rompen casos que antes funcionaban. Casi siempre intencional pero con consecuencias no anticipadas. Detección: comparar distribuciones de respuestas antes y después del cambio, monitorizar eval scores por versión de prompt (linked en Langfuse, ver post de AgentSight donde cubrimos prompt management).

2. Model drift: el proveedor (OpenAI, Anthropic) actualiza el modelo sin avisar. El mismo prompt produce respuestas con tonalidad ligeramente distinta, calidad similar pero diferente, o degradación en algún subset. Detección: comparar embeddings de respuestas de hoy con baseline; monitorizar rubric scores; alertar si la varianza intra-modelo crece.

3. Eval-score drift: la rolling mean de tus métricas de eval (faithfulness, answer relevancy, custom rubrics) tiende a la baja. Causa raíz puede ser cualquiera de las anteriores o un cambio en el mix de usuarios. Detección: alertas sobre tendencias de las series de evals.

A estas tres se suma una cuarta más sutil:

4. Persona drift / user mix shift: la población de usuarios que usa el sistema cambia. No es que el modelo o el prompt empeoraron; es que los nuevos usuarios hacen preguntas distintas y el sistema, aunque sigue siendo igual de bueno en lo que era bueno, falla en lo nuevo. Detección: embedding clustering de prompts, monitorizar aparición de clusters nuevos o crecimiento de uno minoritario.

El concepto técnico clave: embedding-space shift

Stack Pulsar lo dice claro: en LLMs, el drift se mide mejor en el espacio de embeddings. Las distancias clásicas en espacio de tokens no capturan semántica fina; en embedding space sí.

El pipeline canónico:

Establecer baseline: durante un periodo estable (digamos las primeras dos semanas tras un release), captura una muestra grande de embeddings de prompts y respuestas.
Monitorización continua: cada hora o cada día, captura una nueva muestra del tráfico de producción.
Comparar distribuciones: aplica un test estadístico que compare la distribución actual con la baseline en el espacio de embeddings.
Alertar: si la divergencia supera un umbral, dispara una alerta y un workflow de investigación.

Como bonus, monitorizar clusters: si tu baseline tiene 5 clusters de prompts (preguntas técnicas, soporte general, ventas, etc.) y de pronto aparece un sexto cluster que no estaba, lo más probable es que un nuevo segmento de usuarios haya llegado.

Tests estadísticos: KS, PSI, MMD

Tres tests que cualquier sistema de drift usa, cada uno con su lugar:

Kolmogorov-Smirnov (KS): no-paramétrico. Calcula la máxima distancia entre dos CDFs empíricas. Devuelve un statistic y un p-value. Ventaja: muy sensible a cambios sutiles, especialmente en colas. Desventaja: con datasets grandes, “demasiado sensible” — dispara alarmas por cambios reales pero clínicamente irrelevantes.

Population Stability Index (PSI): bineas la distribución de referencia y la actual, luego sumas (p_actual - p_ref) × log(p_actual / p_ref) sobre los bines. Interpretación canónica: PSI < 0.1 estable, 0.1-0.25 drift suave, > 0.25 drift significativo. Ventaja: interpretable, threshold-based, tradición de uso en credit scoring (Capital One, Goldman Sachs). Desventaja: menos sensible que KS — pierde drift en colas.

Maximum Mean Discrepancy (MMD): mide la divergencia entre dos distribuciones embebiendo cada una en un espacio de Hilbert vía kernel. Sirve para distribuciones multivariadas complejas (embeddings de alta dimensión). Ventaja: la única que escala razonablemente a embeddings de 768/1024/4096 dimensiones. Desventaja: más compleja de interpretar.

La práctica recomendada en 2026:

PSI para features simples (longitud de prompt, tokens, número de tools invocadas).
KS para features continuos donde quieras alta sensibilidad.
MMD para embeddings (espacios de alta dimensión).

Análisis de Evidently en datasets reales mostró que KS detecta drift 6+ horas antes que PSI en algunos incidentes. La consecuencia operativa: usa KS para early warning, PSI para confirmación con threshold interpretable.

Herramientas 2026

Tres productos dominan el campo:

Evidently AI

Evidently es open-source (Apache 2.0), Python-first. Su valor:

Drift reports HTML: generas un report comparando dos datasets (referencia vs actual) y obtienes un archivo HTML con todos los tests estadísticos, visualizaciones, conclusiones. Sin servidor, sin infra; un fichero compartible.
Soporte de LLM nativo: además de tabular, soporta texto. Compute embeddings, aplica los tests adecuados.
100+ métricas en la suite. Te lo cubre todo desde un único framework.
Integración con MLflow y kube: workflows de CI con reports en cada release.

from evidently import Report
from evidently.metrics import DataDriftPreset

ref = load_baseline_dataset() # prompts de la semana pasada
cur = load_current_dataset() # prompts de la última hora

report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=ref, current_data=cur)
report.save_html("drift_report.html")

Cuando esta funcionalidad detecta drift, además te dice qué columna y qué test disparó.

NannyML

NannyML tiene un foco distinto: estimar el rendimiento del modelo cuando no tienes ground truth. Las técnicas:

CBPE (Confidence-Based Performance Estimation): estima accuracy usando la confianza del modelo en sus predicciones.
DLE (Direct Loss Estimation): estima la pérdida directamente.

Útil cuando tu app LLM no tiene feedback humano inmediato pero quieres saber si su calidad ha bajado. Apache 2.0, Python.

WhyLabs

WhyLabs es comercial (con whylogs como librería OSS subyacente), enfocada a producción enterprise:

SaaS managed con SOC 2 Type 2 y HIPAA compliance.
Real-time monitoring vía ingesta continua de logs.
Embedding tracking: soporte nativo para distribuciones de embeddings, no solo features tabulares.
Token probability shifts: monitorea la distribución de probabilidades de tokens generados, no solo metadata.

Para empresas regulated que no quieren operar su propia plataforma de drift detection, es la opción de menos fricción.

Otras menciones

Arize Phoenix (visto en post de Evals) incluye drift detection como módulo. Galileo tiene productos comerciales especializados en LLM monitoring. Fiddler AI y Alibi Detect (Seldon) son alternativas más generalistas que también cubren LLM.

Herramienta	Licencia	Foco	Stack típico
Evidently AI	Apache 2.0	Drift reports + LLM	OSS Python, reports HTML
NannyML	Apache 2.0	Performance sin GT	OSS Python, batch
WhyLabs	Comercial (whylogs OSS)	SaaS enterprise, embeddings	Logs continuos, compliance
Arize Phoenix	ELv2	Tracing + drift unificado	OSS, OTel-native
Galileo	Comercial	LLM monitoring premium	SaaS, ML expert team
Alibi Detect	Apache 2.0	Drift detection general	OSS Python, Seldon ecosystem
Fiddler AI	Comercial	Explainability + monitoring	Enterprise SaaS

Parte 3 — El stack completo: cómo encaja todo

Recapitulemos las capas que las dos series han cubierto, ordenadas de más cercana al request individual a más cercana a la tendencia agregada:

EVENTOS individuales TENDENCIAS agregadas
│ │
Tracing ──→ Evals ──→ Guardrails ──→ MCP obs ──→ Drift detection
│ │
AgentSight ──→ Tetragon ──→ Hubble ──→ eBPF on-device
│ │
(qué pasa) (qué cambia)

Cada capa responde una pregunta distinta:

Capa	Pregunta que responde	Granularidad
Tracing (Langfuse, AgentSight)	¿Qué hizo el agente exactamente?	Una sesión
Evals	¿Fue buena la respuesta?	Una respuesta
Guardrails	¿Es seguro este prompt/respuesta?	Un mensaje
MCP observability	¿Qué tools invocó, cuánto coste?	Una llamada tool
eBPF en agente/red (AgentSight, Hubble)	¿Cómo se comportó el sistema?	Por proceso/conexión
eBPF en motor local (ProfInfer-like)	¿Cómo se ejecutó el modelo?	Por función runtime
Drift detection	¿Está cambiando algo silenciosamente?	Distribución

Ninguna sustituye a las demás. La cobertura completa requiere las siete. La operación práctica:

Capas 1-3 (tracing, evals, guardrails) son obligatorias desde el día uno. Cualquier app LLM en producción que no las tenga está pilotando a ciegas.
Capa 4 (MCP) se vuelve obligatoria cuando hay agentes con tools, que es la mayoría en 2026.
Capas 5-6 (eBPF) se vuelven valiosas cuando la escala justifica el coste de operación (>10 servicios, >100 pods de inferencia).
Capa 7 (drift) es la que más se descuida y más caro sale ignorar: se cubre con un día de trabajo para tener el pipeline básico y ahorra semanas de incidencias futuras.

Patrón operativo de drift en 2026

La receta mínima que cualquier app LLM seria debería tener:

Paso 1 — Establecer baseline

Durante un periodo estable post-release (2 semanas mínimo), almacena:

Embeddings de todos los prompts (vector + metadata: timestamp, user_segment, tenant).
Embeddings de las respuestas.
Scores de evals automatizados sobre muestra (eg 5-10% del tráfico con G-Eval).
Distribución de tools invocadas (qué tools, con qué argumentos típicos, con qué frecuencia).

Storage: cualquier vector store + relational. Cardinalidad razonable a la escala que tengas.

Paso 2 — Pipeline continuo de comparación

Cada hora (o cada día según escala):

Toma la muestra del periodo actual (última hora).
Aplica los tests estadísticos contra el baseline:
- PSI sobre features simples (longitud prompt, tokens, num tools).
- KS sobre features continuos (latencia, score).
- MMD sobre embeddings.
Genera un drift report (Evidently lo hace en una línea de Python).

Paso 3 — Alertas y workflow de investigación

Configurar thresholds y rutas:

PSI > 0.25 sobre tokens consumidos: alerta moderada (puede ser legítimo, investigar segmentos).
MMD significativo sobre embeddings de prompts: alerta alta (cambio en user mix o ataque coordinado).
Eval rubric score baja >5% en rolling 7d: alerta crítica.
Nuevo cluster en embedding space del 10%+ del tráfico: workflow de revisión (puede ser nuevo segmento legítimo o anomalía).

Cada alerta debe llevar a un dashboard de drill-down con los segmentos afectados, no a un Slack message vacío. La regla operativa: si alguien no puede investigar el alert en <5 minutos, no se va a investigar.

Paso 4 — Refresh de baseline

El baseline no es estático. Cada N semanas, refresca el baseline incorporando lo “estable nuevo”. Si en 3 meses el patrón de uso ha cambiado legítimamente (más usuarios internacionales, idiomas nuevos), el baseline debe reflejarlo. La cadencia típica: trimestral.

Trampas operativas

Baseline contaminado

Tomas el baseline de un periodo que ya contenía el problema en germen. Resultado: el baseline incluye el comportamiento malo, los tests no disparan nunca. Solución: verificar el baseline contra una segunda muestra independiente (por ejemplo, la primera semana vs la segunda) antes de bendecirlo.

Threshold demasiado bajo

PSI > 0.05 dispara constantemente. Tu equipo aprende a ignorar las alertas. Calibrar thresholds según el ruido natural de tu sistema: corre el sistema con baseline + muestras semanales sucesivas y mide la distribución de PSI; pon el threshold un par de desviaciones por encima de lo normal.

Embeddings no representativos

Usas el embedding model de OpenAI text-embedding-3-small para detectar drift en un sistema que sirve preguntas técnicas en español sobre redes Cisco. Resultado: el embedding model no captura la semántica fina del dominio. Solución: usar embeddings finetuned para tu dominio o uno fuerte en multilenguaje y técnico.

Sobrecarga de almacenamiento

Almacenar embedding de cada prompt en producción a escala (millones de prompts/día) llena disco y aumenta coste. Sampling estratificado: guarda 5-10% del tráfico, pero asegúrate de que los segmentos minoritarios están sobrerrepresentados para no perderlos.

Confundir drift con “el sistema funciona”

A veces el drift es buen drift: los usuarios nuevos descubren que el agente sabe hacer X cosa, y de pronto el 30% del tráfico es para X cosa. La distribución cambió porque el producto encontró un nuevo uso. Antes de tirar de la alarma, verifica si el cambio es deseable.

Privacy en almacenamiento de embeddings

Embeddings pueden ser invertidos parcialmente a su texto original con técnicas de embedding inversion. Si los prompts contienen PII, almacenar embeddings durante meses para drift detection es un vector de fuga. Cifrar at rest y rotar regularmente, o trabajar con embeddings agregados/promediados.

eBPF en producción sin profile guardrails

Adjuntar uprobes en funciones de hot path como llama_decode puede impactar throughput si no se hace con cuidado. Probar siempre en staging y monitorizar overhead. ProfInfer reporta <4%; lo que tú midas puede variar según tu binario y kernel.

Cerrando las dos series

Esta semana hemos escrito 12 artículos que recorren el stack moderno de inferencia LLM en producción de arriba abajo:

Serie inferencia LLM (4 artículos):

KV cache: la memoria de trabajo que sostiene la inferencia LLM — fundamentos.
vLLM en Kubernetes — el motor.
PagedAttention deep dive — cómo funciona por dentro.
Operators LLM en Kubernetes — orquestación.

Serie eBPF (4 artículos):

eBPF de cero a Cilium — el sustrato.
Tetragon — seguridad runtime.
Hubble — observabilidad de red.
AgentSight — observabilidad de agentes.

Serie post-tracing (4 artículos):

Evals — calidad reactiva.
Guardrails — seguridad preventiva.
MCP observability — protocolo de herramientas.
Este — drift detection y eBPF en inferencia local.

Si lees los doce en orden tienes un mapa razonablemente completo de qué hace falta para operar agentes IA en producción seria en 2026, con el detalle suficiente para no chocarte con los problemas habituales en el primer mes. Y, sobre todo, con la mentalidad de que observabilidad LLM es un stack, no un producto: cada capa resuelve un problema, ninguna las resuelve todas, y la combinación es lo que define a un sistema operable de uno que aguanta hasta el primer incidente.

Lo que queda para futuras series

MLOps específico para LLMs: fine-tuning continuo, RAG over data lakes, agent training.
Constitutional AI y alignment runtime: cómo el modelo se autorregula con guardrails internos.
GPU networking: InfiniBand, NCCL, GPUDirect — el ángulo que dejamos sin tocar.
Edge inference: llama.cpp en móviles, MLX en macOS, Snapdragon NPU.
Inference scheduling teórico: CFS-like algorithms aplicados a LLM serving multi-tenant.

Los iremos cubriendo. Hasta aquí, gracias por leer estos doce posts. Si te ha aportado algo, compártelo con un colega.

Referencias

eBPF en inferencia local:

ProfInfer: An eBPF-based Fine-Grained LLM Inference Profiler (arxiv 2601.20755) — paper de referencia 2026.
Monitor LLM Inference in Production 2026 (Glukhov) — Prometheus + Grafana para vLLM/TGI/llama.cpp.
AI Inference Server Observability in Kubernetes (ARMO) — las cuatro señales que MLOps tools no capturan.
vLLM vs llama.cpp: Choosing the right engine (Red Hat).

Drift detection conceptos:

Herramientas:

Evidently AI (GitHub) — open-source.
Evidently — sitio oficial.
NannyML — performance sin ground truth.
WhyLabs — managed observability.
Alibi Detect (Seldon) — drift detection general.
Arize Phoenix — drift integrado con tracing.

Tests estadísticos:

Data drift detection: PSI vs Kolmogorov–Smirnov (MLPipeline) — comparativa práctica.
Population Stability Index for Model Drift Detection.
Which test is the best? 5 methods to detect data drift (Evidently) — los 6 horas de ventaja de KS.

Cross-references (las tres series completas):

Serie inferencia LLM: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s.
Serie eBPF: eBPF de cero a Cilium, Tetragon, Hubble, AgentSight.
Serie post-tracing: Evals, Guardrails, MCP observability.

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.

AgentSight y el nuevo tracing de LLMs: zero-instrumentation con eBPF frente a Langfuse, LangSmith, Phoenix y compañía

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

TL;DR

Observar un agente de LLM en producción en 2026 se divide en dos enfoques con filosofías opuestas. El instrumentado, dominante hasta 2025, vive en herramientas como Langfuse, LangSmith, Arize Phoenix, Helicone, OpenLLMetry/Traceloop o Pydantic Logfire: instalas un SDK, decoras tus llamadas, emites spans con la convención OpenTelemetry GenAI (gen_ai.request.model, gen_ai.usage.input_tokens, etc.) y los exportas a un backend. Profundidad altísima cuando controlas el código; cero visibilidad cuando el agente es un binario opaco que ejecutas sin instrumentar. El zero-instrumentation, que AgentSight ha popularizado en la segunda mitad de 2025, gira la perspectiva 180º: pone hooks eBPF en las uprobes de las bibliotecas SSL/TLS y captura el plaintext de cada petición HTTPS antes del cifrado, sin tocar el código de la app, con menos del 3% de overhead y la garantía de ser tamper-proof (el agente no puede falsificar lo que se ve en el kernel). Combinado con captura BPF de stdio para servidores MCP locales, AgentSight te da observabilidad completa de cualquier agente —incluyendo binarios cerrados como Claude Code, Gemini CLI o Cursor— en un cluster Kubernetes. Las dos familias no son enemigas: la pila de referencia 2026 combina ambas (instrumented para apps propias con LangChain, eBPF para binarios opacos y compliance de tamper-proof) sobre OpenTelemetry GenAI semantic conventions como vocabulario común que el ecosistema está estabilizando este año.

Este es el cuarto y último post de la serie sobre eBPF. Parte 1: eBPF de cero a Cilium. Parte 2: Tetragon: seguridad de runtime. Parte 3: Hubble: observabilidad de red. Aquí cerramos el círculo con la dimensión semántica —qué hace un agente IA, no solo qué red abre o qué syscalls emite—.

La analogía: APM tradicional vs sniffer de red

Quien haya operado aplicaciones empresariales conoce las dos tribus del monitoring. La tribu APM (New Relic, AppDynamics, Datadog APM): instalas un agente o un SDK en cada aplicación, marcas spans, recoges traces con profundidad enorme dentro de cada proceso —líneas de código, queries SQL, métodos de Java—. La tribu wire-level (sniffers de red, herramientas tipo SolarWinds NPM, NetFlow): no toca la aplicación; observa el cable, ve protocolos, latencias, retransmisiones, identifica problemas que la app no sabe que tiene.

Cada una ve cosas distintas y las dos sirven. Quien ha vivido un incidente serio donde APM decía “todo verde” mientras los usuarios sufrían sabe que el wire-level habría detectado el problema (un middlebox saturado, un MTU mal configurado, un timeout de TCP). Quien ha intentado debuggear un memory leak con sniffers sabe que sin APM era imposible.

La observabilidad de agentes LLM en 2026 está exactamente en este punto. El APM-style lleva un par de años montado: Langfuse, LangSmith, Phoenix, OpenLLMetry. Profundidad enorme, requiere instrumentar la app. El wire-level con eBPF acaba de llegar: AgentSight es el primer proyecto que lo lleva a productivo. Profundidad menor en el interior del agente, pero ve cualquier agente sin tocar nada y es tamper-proof. Los dos sirven. La industria está en plena coexistencia.

Por qué observar agentes LLM es distinto

Antes de entrar en herramientas, vale la pena detenerse en qué hace específicos a los agentes LLM como sujetos de observabilidad:

No-determinismo. El mismo input puede producir outputs distintos. Reproducir un incidente requiere capturar exactamente la conversación, el modelo, los parámetros y, idealmente, la seed. Una métrica agregada “latencia p95” se queda corta; lo que necesitas es replay de la traza individual.

Cadena de invocaciones externas. Un agente típico llama LLM → herramientas (tool calling) → MCP servers → otras APIs → vuelta a LLM. Una sesión de chat puede generar decenas de llamadas encadenadas que hay que correlar por trace_id para entender la decisión.

Coste lineal en tokens. Cada llamada se paga en tokens. Sin trazar input/output tokens por petición, no puedes asignar coste a tenant ni equipo, ni detectar bucles que se comen tu presupuesto en una hora.

Riesgo semántico. Prompt injection (un user input que contiene instrucciones para manipular al modelo), jailbreaks, leakage de secretos via tool calls. Es un tipo de problema que no aparece en aplicaciones tradicionales y la observabilidad debe verlo.

Binarios opacos. En 2026, muchos equipos despliegan agentes de terceros —Claude Code, Cursor agent, Aider, Gemini CLI, Codex CLI— como herramientas internas. No son aplicaciones propias; son binarios cerrados que llaman a la API del vendor. Instrumentarlos es imposible. Observarlos requiere otra cosa.

Multi-agent y orquestación. Cada vez más arquitecturas tienen agentes que invocan a otros agentes (planner → executor → critic). La observabilidad debe entender la topología, no solo el span individual.

Con estos cinco puntos en mente, las herramientas que vamos a ver se diferencian principalmente en qué partes del problema cubren bien y qué partes dejan ciegas.

El enfoque instrumentado: cómo funciona

El modelo es directo y conocido:

Tu código llama al LLM o a herramientas usando una librería oficial: openai, anthropic, langchain, llama_index, dspy.
Instalas un SDK del tracer (Langfuse, LangSmith, OpenLLMetry, Logfire) que wrappea o monkey-patcha esas librerías.
Cada llamada emite un span OpenTelemetry con atributos estandarizados: modelo usado, tokens input/output, latencia, parámetros, mensajes, herramienta invocada, resultado.
Los spans se exportan vía OTLP a un backend que los muestra como un árbol de traces.

# Ejemplo típico con OpenLLMetry + cualquier SDK
from traceloop.sdk import Traceloop
from openai import OpenAI

Traceloop.init(app_name="my-agent", api_endpoint="https://otel-collector:4318")

client = OpenAI()
# este call emite automáticamente un span con
# gen_ai.request.model, gen_ai.usage.input_tokens, etc.
resp = client.chat.completions.create(
 model="gpt-4.1",
 messages=[{"role": "user", "content": "..."}]
)

Lo que ves después: un dashboard con cada conversación como un trace, cada llamada como un span, los prompts y completions completos (si optas in), el coste calculado, latencias por span, errores marcados.

OpenTelemetry GenAI semantic conventions: el vocabulario común

La fragmentación del campo se está mitigando con OpenTelemetry GenAI Semantic Conventions. Es el esfuerzo de la CNCF para que todas las herramientas emitan spans con los mismos nombres de atributos:

gen_ai.system — el proveedor (openai, anthropic, vertex_ai, etc.).
gen_ai.request.model — modelo solicitado (gpt-4.1, claude-3-5-sonnet).
gen_ai.response.model — modelo realmente usado (a veces difiere, eg fallbacks).
gen_ai.usage.input_tokens y gen_ai.usage.output_tokens — contadores.
gen_ai.request.temperature, gen_ai.request.top_p, etc. — parámetros.
gen_ai.response.finish_reasons — por qué terminó (stop, length, content_filter).
gen_ai.operation.name — el tipo de operación (chat, embedding, completion).

A principios de 2026, los client spans salieron de experimental a estable. El resto (server spans, multi-agent events) sigue en desarrollo. El significado operacional: si tu SDK emite estos atributos, cualquier backend que entienda OTel GenAI puede consumirlos. Cambiar de Langfuse a Phoenix a Helicone no implica re-instrumentar, solo cambiar el exporter.

La SIG está activamente desarrollando conventions for multi-agent systems: agent teams, tasks, actions, memory, artifact tracking. Esto es lo que falta para que las arquitecturas de agentes complejas tengan vocabulario común. En 2026 está experimental; se espera estabilización a finales de año o principios de 2027.

Herramientas instrumentadas: el panorama 2026

Herramienta	Licencia	Self-host	Foco	Donde brilla
Langfuse	MIT	Sí	LLM observability + evals + prompt mgmt	Mejor balance OSS, suite completa
LangSmith	Comercial	No	LangChain/LangGraph nativo	Si usas LangChain, integración cero-config
Arize Phoenix	ELv2 (OSS)	Sí	OTel-native, RAG fuerte	Vector DBs, retrieval, embeddings
Helicone	Comercial + OSS lite	Sí (lite)	Proxy simple	Setup minutos, OpenAI-only
OpenLLMetry / Traceloop	Apache 2.0	Sí	SDK OTel para LLMs	Vendor-neutral, exporta a cualquier OTel backend
Pydantic Logfire	Comercial	No	App + LLM unificado	Si usas Pydantic AI, integración nativa
Weights & Biases Weave	Comercial	Limitado	Experimentación + producción	Si ya usas W&B para training
Laminar / Braintrust	Comercial	No / Sí	Evals + tracing	Más recientes, foco en evaluación

Deep dive: Langfuse

Merece detenerse en Langfuse porque es, en 2026, la elección por defecto entre las opciones open-source y la que más equipos han adoptado este año. Es proyecto de YC W23, licencia MIT, y lleva un ritmo de release sostenido con cambios arquitectónicos serios entre versiones.

Cuatro pilares declarados: observability (tracing), evaluations, prompt management, playground/datasets. Cada uno por separado tiene productos comerciales completos detrás; Langfuse los integra en una sola plataforma con un solo backend.

El SDK v4: OTEL-native, no un sustituto

El gran cambio operacional reciente es el SDK v4, una capa fina sobre el cliente oficial de OpenTelemetry. La elección es deliberada: en lugar de mantener un cliente propio que se atrase respecto a las primitives OTel, Langfuse usa el SDK estándar y enriquece los spans con atributos y helpers específicos para LLM. La consecuencia: cualquier código que ya esté instrumentado con OpenTelemetry vainilla (@opentelemetry/sdk-node, opentelemetry-sdk en Python) puede exportar a Langfuse sin cambios mayores, y al revés, si mañana quieres migrar de Langfuse a otro backend OTel, los spans son portables.

En Python el decorador idiomático es @observe:

from langfuse import observe, get_client

langfuse = get_client()

@observe()
def buscar_documentos(query: str):
 # cualquier llamada interna también se traza
 return vector_store.similarity_search(query)

@observe(as_type="generation")
def llamar_llm(prompt: str):
 # marcada como "generation" para que aparezca con metadata LLM
 return openai_client.chat.completions.create(...)

@observe()
def pipeline_rag(pregunta: str):
 docs = buscar_documentos(pregunta)
 return llamar_llm(build_prompt(pregunta, docs))

El árbol de llamadas se captura automáticamente: la traza muestra pipeline_rag como root span, con buscar_documentos y llamar_llm como hijos, anidados. Sin escribir un solo with tracer.start_as_current_span(...) a mano.

En TypeScript el equivalente es modular: instalas @langfuse/tracing, @langfuse/otel y @opentelemetry/sdk-node, y puedes usar decoradores TS, context managers o spans manuales —los tres modelos interoperan—. La consecuencia: bibliotecas terceras que emiten spans OTel (openai, @anthropic-ai/sdk, instrumentaciones de Vercel AI SDK) se ven en Langfuse sin trabajo adicional.

Arquitectura self-host: pensada para producción seria

La arquitectura del backend Langfuse tiene dos decisiones explícitas que distinguen su despliegue self-host:

Persistencia primero en S3/Blob Storage. Cuando un evento de tracing entra, se persiste en object storage antes de tocar la base de datos. Solo cuando el procesado posterior confirma OK se inserta en Postgres/Clickhouse. Si la DB cae temporalmente, los eventos no se pierden; quedan en S3 esperando reproceso. Para producción donde perder traces de un incidente equivale a perder evidencia, esto es load-bearing.
Migraciones largas como background jobs. Los upgrades de schema que en otras plataformas implican ventana de downtime, en Langfuse se ejecutan en background mientras la aplicación sigue sirviendo. El downtime de upgrade se reduce drásticamente.

Los modos de despliegue soportados oficialmente:

Docker Compose: para desarrollo y POCs. Un comando, todo arriba.
VM: un único nodo, contenedores, sin orquestación. Para entornos pequeños.
Kubernetes con Helm: el modo recomendado para producción. Chart oficial mantenido. Soporta external Postgres, external Clickhouse, external S3, HPA.

Las dependencias externas en producción típica: Postgres (metadata, prompts, configuración), Clickhouse (eventos de tracing, queries de alta cardinalidad), S3 o blob compatible (eventos pendientes), Redis (cola entre componentes). Sí, son varias piezas; es lo que sostiene la durabilidad y la escala.

Prompt management como ciudadano de primera clase

Lo que diferencia a Langfuse de las plataformas centradas solo en tracing es que los prompts viven en Langfuse, no en el repo de la aplicación o en hojas de cálculo. Cada prompt tiene:

Nombre y versión (v1, v2, v3…). Cambiar el prompt no requiere redeploy de la app: la app pide el prompt al SDK, que lo cachea y refresca cuando hay versión nueva.
Variables tipadas: {{user_input}}, {{context}}. Render con validación.
Tags y labels: por entorno (production, staging), por equipo, por experimento.
Cache cliente y servidor: el SDK cachea localmente con TTL configurable, evita roundtrip a Langfuse en cada llamada.
Linkage con traces: cada trace recoge qué versión exacta de qué prompt se usó. Investigar “esta respuesta salió mal” lleva al prompt versión Y, no a “alguna versión del prompt en algún momento”.

from langfuse import get_client

langfuse = get_client()

prompt = langfuse.get_prompt("rag-system-prompt", version=3)
# o por label: langfuse.get_prompt("rag-system-prompt", label="production")

compiled = prompt.compile(context=docs_text, user_input=question)
# 'compiled' es el string final, listo para mandar al LLM

Para equipos que iteran sobre prompts a diario, esto es lo que evita el caos de “qué versión del prompt está corriendo realmente en producción ahora mismo”.

Evaluations: cuatro modelos de evaluación combinables

Langfuse cubre los cuatro patrones de evaluación de respuestas:

LLM-as-a-judge: configuras un modelo (típicamente GPT-4 o Claude) con una rúbrica y evalúa cada respuesta. Resultado: score numérico (0-1) y justificación. Aplicable a tracing automático (todas las respuestas) o batch (selección de dataset).
User feedback: la app permite al usuario marcar respuesta como buena/mala. El feedback se asocia al trace y al prompt version, lo que permite ver qué versiones tienen peor rate.
Manual labeling: una UI donde labelers humanos puntúan respuestas. Útil para datasets dorados y para evaluar el judge.
Custom evaluators vía API/SDK: evals propios (un test unitario, una métrica de negocio) reportan score vía API. Se integran con CI.

Combinadas, dan regression testing del prompt: cambias de v3 a v4, evalúas el dataset dorado con LLM-as-judge, comparas; si v4 empeora en alguno de los segmentos, el merge falla.

Integraciones

Langfuse no compite con OpenLLMetry, LangChain o LiteLLM: los integra. Las que están testeadas y documentadas:

OpenTelemetry: cualquier instrumentación OTel emite a Langfuse vía OTLP.
LangChain y LangGraph: callback nativo que captura toda la cadena.
LlamaIndex: callback nativo.
OpenAI SDK (Python y TS): wrapper que añade tracing automáticamente.
LiteLLM: integración como callback, lo que cubre 100+ proveedores via LiteLLM.
OpenLLMetry / Traceloop: emiten a Langfuse como cualquier backend OTel.
MLflow: vía exporter OTel desde MLflow a Langfuse.
Vercel AI SDK: instrumentación nativa.

La estrategia es clara: Langfuse es backend, no SDK. Tu equipo elige cómo instrumenta; Langfuse acepta cualquier camino. La consecuencia operativa: cambiar de Langfuse a otro backend OTel mañana es viable.

Cuándo Langfuse no es la respuesta

Para no presentarlo como bala de plata:

Si solo usas LangChain y no tienes recursos para self-host: LangSmith te dará integración más fluida (es el mismo equipo).
Si tu única necesidad es proxy con cost tracking sin evals: Helicone es más simple.
Si quieres una solución vendor commercial integrada: Datadog LLM Observability, New Relic AI Monitoring o Dynatrace AI son alternativas Enterprise con soporte 24/7.
Si tu carga es batch puro de inferencia masiva sin agentes: probablemente no necesitas tracing semántico; Prometheus + Grafana con métricas OTel basta.

Para todo lo demás —apps propias con tracing serio, multi-tenant con cuotas, equipos que iteran prompts a diario, RAG con evaluación continua—, Langfuse es la apuesta segura.

Resumen de elección rápido:

LangChain → LangSmith (cero esfuerzo, instrumentación automática).
Aplicaciones propias multi-framework con OSS → Langfuse (MIT, self-host, completo).
RAG con vector stores → Arize Phoenix (mejor visibilidad de retrieval).
Proxy simple, presupuesto bajo → Helicone.
Vendor neutrality estricta → OpenLLMetry/Traceloop.
Pydantic AI → Logfire (mismo equipo).

Fortalezas y debilidades del modelo instrumentado

Fortalezas:

Profundidad enorme: spans anidados con todo el contexto (chain steps, retrieval, embeddings, tool calls).
Vocabulario semántico: SDK conoce el dominio (LLM, vector store, agent).
Madurez: tres años de evolución, ecosistema rico, dashboards listos.
Evals integradas: las plataformas top combinan tracing con evaluación (judge LLM, datasets, regression).

Debilidades:

Requiere control del código: si no puedes instrumentar, no funciona.
Trust en la app: si la app reporta mal o tiene un bug, la traza también. No es tamper-proof.
Acoplamiento al SDK: cambios de versión de una librería pueden romper la instrumentación.
Cobertura desigual: SDKs de Python están maduros; Go, Rust, JS más jóvenes.

El enfoque zero-instrumentation: AgentSight

AgentSight es el proyecto del grupo eunomia-bpf que abandera el enfoque opuesto. Su paper en arxiv (2508.02736), presentado en el Workshop on Practical Adoption Challenges of ML for Systems, formaliza la propuesta. La premisa es directa:

Instead of instrumenting the agent, observe it at the system boundary.

Y “system boundary” significa el límite del kernel: el último punto antes de que un dato salga del proceso hacia la red o el filesystem. Ahí, con eBPF, se ven las cosas tal como son, sin que la aplicación pueda cooperar para esconderlas.

Arquitectura: tres planos

AgentSight monta tres capas:

Plano 1 — SSL/TLS uprobes. eBPF puede atar programas a funciones de bibliotecas userspace (uprobes). Las funciones objetivo son las de cifrado: SSL_write, SSL_read de OpenSSL/BoringSSL, equivalentes en Rustls. AgentSight les pone hooks que capturan los argumentos: el buffer plaintext que la app pasa para que sea cifrado, justo antes de que TLS lo procese. En la recepción, hace lo simétrico: hook después de SSL_read con el plaintext recién descifrado. Resultado: AgentSight ve el contenido completo de cualquier petición HTTPS que la app haga sin necesidad de man-in-the-middle ni certificados ni descifrar tráfico. El payload es plaintext porque se capturó antes de cifrarse.

Esto funciona porque las uprobes son baratas (~100 ns por invocación) y porque las apps usan bibliotecas de TLS comunes. Las pocas apps que implementan su propio TLS (raras en producción) escapan a este hook; para esas hace falta un kprobe diferente o instrumentación manual.

Plano 2 — Kernel events. Paralelamente, AgentSight observa syscalls relevantes a través de tracepoints: execve (qué procesos arrancan), connect/accept (red), read/write con file descriptors (filesystem y stdio), unlink, clone. Cualquier acción del agente que tenga efecto fuera del proceso pasa por aquí. Esto cubre, entre otros, comandos shell ejecutados por el agente —si un agente Claude Code decide ejecutar rm -rf para “limpiar el proyecto”, el execve se ve aunque la API LLM no lo reporte—.

Plano 3 — Correlation engine. Los dos planos anteriores producen streams de eventos asíncronos. AgentSight tiene un componente en userspace que los correlaciona causalmente cross-process: una petición HTTP saliente con bash -c rm -rf puede ser correlada con la respuesta LLM previa que la sugirió, vía PIDs, tiempos y heurísticas. El paper menciona el uso opcional de un LLM secundario (Anthropic Claude por ejemplo) que analiza la secuencia de eventos y produce alertas semánticas: “el agente respondió con una tool call que no estaba en la whitelist”, “la cadena de reasoning lleva 47 iteraciones sin converger”.

`stdiocap`: capturar stdio de servidores MCP locales

Una pieza específica que merece mención propia es stdiocap, una herramienta BPF separada incluida en el repo. El Model Context Protocol (MCP), popularizado por Anthropic en 2024 y mainstream en 2025-2026, tiene dos modos de transport: HTTP/SSE (red) y stdio (entre el cliente y el server que arranca como subproceso). Los servidores MCP locales —los que corren en la misma máquina y son arrancados por el cliente como hijos vía pipes— comunican por stdin/stdout/stderr con JSON-RPC.

stdiocap engancha read/write/dup sobre los file descriptors de stdin/stdout/stderr de un proceso target y registra todo el tráfico JSON-RPC entre cliente y server MCP. Es la misma idea que la captura SSL pero para stdio: observas la conversación sin que ni el cliente ni el server lo sepan. Caso de uso típico: ver qué tools del MCP server filesystem-mcp ha invocado un agente Claude Code en la última hora, qué argumentos pasó, qué errores recibió. Imposible con instrumentación clásica (los servers MCP suelen ser binarios de terceros).

Garantías: tamper-proof, kernel safety, <3% overhead

Tres propiedades hacen a AgentSight interesante para producción:

Tamper-proof: la observación ocurre en el kernel (uprobes, syscalls). Una aplicación maliciosa o comprometida no puede falsificar lo que se ve. Comparar con instrumentación: si el agente decide no emitir el span de su acción, no aparece en Langfuse. Aquí no tiene elección.
Kernel safety: eBPF verifica formalmente que los programas terminen y respeten bounds checks. No puede crashear el kernel. Igual que en el resto de la serie eBPF.
<3% CPU overhead medido sobre cargas reales de agentes (paper). El número compara favorablemente con instrumentación SDK que típicamente añade 5-10% en aplicaciones intensas.

Lo que detecta out of the box

El paper y la documentación destacan tres clases de detección:

Prompt injection en tiempo real: el correlation engine puede aplicar reglas o un modelo de detección sobre el plaintext capturado por las uprobes SSL. Si el prompt contiene patrones sospechosos —“ignore all previous instructions”, system prompt embebido en un user input, instrucciones para exfiltrar datos—, marca alerta.
Reasoning loops que gastan recursos: agentes que entran en bucles infinitos llamando a herramientas sin progresar. Detectables porque la cadena causal no converge a “respuesta final” y los tokens se acumulan. El correlation engine los marca.
Bottlenecks en multi-agent: cuando varios agentes coordinan, AgentSight ve la matriz de comunicaciones entre todos y puede detectar agentes que se bloquean esperando, deadlocks, fan-out excesivo.

El choque y la coexistencia

Las dos familias parecen competir, pero en realidad ven cosas distintas y se complementan en producción.

Lo que solo el instrumentado ve

Variables internas del agente que no salen al cable: el estado intermedio de un chain LangChain, los valores antes de pasarlos a una herramienta, el cómo se construye un prompt a partir de un template con vars internos.
Spans semánticos profundos: retrieval > embed > vector_search > rerank > format_context > prompt_template > llm. AgentSight ve solo la llamada final al LLM; el camino para construirla es invisible.
Evaluaciones: scoring de respuestas, judge LLMs, regresión de calidad. Esto vive solo en plataformas instrumentadas.

Lo que solo eBPF ve

Binarios opacos: Claude Code, Cursor, Gemini CLI, agentes de terceros. No tienes el código; no puedes instrumentarlos. Solo eBPF los ve.
Acciones a nivel sistema: el agente decide ejecutar git push --force o kubectl delete. La acción se ve en el execve. La instrumentación del agente puede no reportarla (especialmente si fue un comando que el agente generó como output sin pasar por una “tool” explícita).
Tamper-proof audit: para compliance regulatorio (HIPAA, SOC2, NIS2), tener observación que la app no puede burlar tiene valor formal. eBPF lo da.
MCP servers locales con stdio: invisibles para instrumentación clásica salvo que cada server emita sus propios spans (raro).

Lo que ambos ven, complementariamente

Prompts y completions: instrumentado los emite con metadata rica; eBPF los captura del cable. Cross-check perfecto para detectar discrepancias.
Llamadas a APIs externas: APM lo marca; eBPF lo confirma a nivel kernel.
Latencia: APM por span; eBPF mide RTT a nivel TCP y conectividad red.

Matriz de decisión

Caso	Instrumentado	eBPF (AgentSight)
App propia con LangChain	Sí, primero	Opcional
App propia multi-framework	Sí	Opcional
Binario de terceros (Claude Code, Cursor)	No funciona	Sí, único camino
Cumplimiento normativo tamper-proof	Insuficiente	Sí, requerido
Multi-tenant zero-trust	Insuficiente	Sí, requerido
Servidores MCP locales (stdio)	Difícil	Sí, con stdiocap
Evaluación de calidad de respuestas	Sí, requerido	No (fuera de scope)
Profundidad de chain interno	Sí, requerido	No (caja negra para AgentSight)
Reasoning loop detection	Posible con plumbing	Sí, integrado
Prompt injection en tiempo real	Posible (post-procesado)	Sí, en stream

La conclusión natural: para apps propias, instrumentado; para binarios opacos o compliance, eBPF; para todo lo importante, ambos.

Arquitectura de referencia 2026

Cuatro recetas que cubren el grueso de los casos reales:

Setup A — Aplicación propia con LangChain o similar

Necesidades: profundidad, evals, equipo cómodo con SDKs.

Langfuse self-host o LangSmith cloud como backend.
OpenLLMetry SDK o LangSmith SDK instrumentando el código.
OpenTelemetry Collector entre la app y el backend para flexibilidad de routing (a Langfuse + Tempo + Loki por ejemplo).
Hubble para la capa de red en el cluster (latencia inter-pod, drop attribution).

Setup B — Productivizar un binario opaco (Claude Code, Gemini CLI)

Necesidades: observar sin tocar, auditar, controlar coste.

AgentSight desplegado como DaemonSet sobre el cluster (o standalone en el nodo).
Grafana con dashboards alimentados por las métricas de AgentSight.
Exportador OTLP de AgentSight a un backend OTel (Tempo, Jaeger). Los spans usarán las semantic conventions GenAI cuando se estandaricen del todo.
Tetragon opcional para política sobre qué puede ejecutar el agente (Sigkill si intenta rm -rf o similar).

Setup C — Plataforma multi-tenant zero-trust

Necesidades: agentes de distintos clientes corriendo en el mismo cluster, auditoría obligatoria, ninguno confía en el otro.

AgentSight como capa de auditoría tamper-proof. Compliance lo requiere.
Langfuse multi-tenant para los clientes que sí instrumentan.
Tetragon con TracingPolicyNamespaced por tenant (políticas distintas por namespace).
Hubble con flow logs persistentes para forensics.
Cilium NetworkPolicy para aislar tenants entre sí en red.

Setup D — Servidor MCP local en una workstation

Necesidades: ver qué hace un agente con un MCP server stdio.

AgentSight stdiocap apuntando al PID del cliente o del server.
Captura JSON-RPC completo a fichero o a un endpoint OTLP.
Visualización: Grafana o simplemente jq sobre el log.

Caso de uso real: si estás integrando un MCP server propio y quieres ver qué tool calls hace un agente Claude Code o Cursor a tu server, stdiocap es la forma más limpia. No necesitas modificar ni cliente ni server.

Trampas operativas

Datos sensibles en prompts (instrumentado)

Por defecto, Langfuse, LangSmith y similares capturan el contenido completo de prompts y completions. Si tu app procesa PII, secretos, datos médicos, eso va a tu backend de observabilidad. Configurar redacción o content-opt-out antes de pasar a producción es obligado. OTel GenAI tiene flags específicos (OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=false) para evitarlo.

Datos sensibles en prompts (AgentSight)

Mismo problema, peor: AgentSight captura literalmente lo que va al cable, plaintext. Si el agente conversó con api.openai.com con un prompt que contenía datos sensibles, AgentSight tiene ese plaintext. Hay que cifrar o redactar antes de almacenar.

Certificados pinned o TLS no estándar

Algunas apps de seguridad alta hacen certificate pinning o usan implementaciones de TLS no convencionales (Go’s crypto/tls, BoringSSL custom). En esos casos, las uprobes a libssl no las cubren. AgentSight detecta cuándo no puede observar y reporta gap; igual hay que añadir hooks específicos al SDK alternativo.

Volumen de tokens y storage

Una aplicación con tráfico medio puede generar millones de tokens al día. Si los almacenas todos en Langfuse o Phoenix con retención largos, la base de datos crece deprisa. Estrategias: sampling agresivo, retención corta para sesiones normales y larga solo para errores/anomalías, redaction de contenido y guardar solo metadata.

Tracing con sampling y consistencia

Para reducir coste, muchas instalaciones samplean: solo 1 de cada N traces se persiste. Cuidado con el sampling no consistente: un trace puede llevar varios spans en múltiples servicios, y si la decisión de samplear se toma per-span, acabas con traces incompletos. OTel tiene head sampling (en el SDK al principio) que es consistente, y tail sampling (en el collector al final) que permite reglas más finas. Para LLM, el tail sampling es ideal: muestrea todo, descarta solo las traces “normales” y conserva las que tienen errores, latencia alta o cost alto.

Multi-agent y trace propagation

Cuando agente A llama a agente B, hay que propagar el trace context (W3C Trace Context headers) para que se vea como un árbol único. Si no lo haces, ves dos traces inconexos. Las plataformas modernas lo hacen automáticamente con inject/extract, pero si tu transport entre agentes es custom (vía Redis pub/sub, vía DB), tienes que propagar a mano.

Coste de las uprobes en bibliotecas críticas

Hookear libssl añade ~100 ns por invocación. En cargas de tráfico TLS extremo (decenas de miles de conexiones/s por core), eso suma. AgentSight lo mantiene por debajo de 3% en cargas típicas de agentes (que son chatty pero no networking-intensive). Si tu uso fuese sniffing de todo el HTTPS del nodo, podría doler más.

Lo que no hemos cubierto (próxima serie)

Evals: la siguiente capa después de tracing. Phoenix, Langfuse, LangSmith y compañía ofrecen evaluación de respuestas (judge LLM, datasets, regression). Es un mundo aparte.
Guardrails y safety: NeMo Guardrails, Llama Guard, Llama Prompt Guard, evaluadores específicos para prompt injection y jailbreaks.
MCP server observability profunda: cómo OpenTelemetry GenAI conventions están extendiéndose a MCP servers para trace-aware tools.
eBPF + on-device inference: cuando el LLM corre localmente vía vLLM o llama.cpp, las uprobes pueden ver la cola tokens-output ANTES de que vayan al cliente. Territorio nuevo.
Análisis estadístico de flows de agentes: detectar drift, outliers, patrones que indican degradación.

Cerrando la serie eBPF

Esta serie de cuatro artículos ha recorrido eBPF desde el primer principio hasta la frontera 2026:

eBPF de cero a Cilium — qué es eBPF, hooks de networking, cómo Cilium se salta la pila TCP/IP, BGP Control Plane v2.
Tetragon: seguridad de runtime — observabilidad y enforcement de procesos en el kernel.
Hubble: observabilidad de red — flow logs L3-L7 y la frontera con los agentes IA.
Este — AgentSight, tracing de LLMs, instrumentado vs zero-instrumentation.

Si has llegado hasta aquí tienes el mapa para sentarte con un equipo de plataforma, de seguridad o de IA en 2026 y reconocer qué hace cada pieza, qué problema resuelve y por dónde empezar. Toda esa pila —Cilium para CNI y BGP, Tetragon para seguridad de runtime, Hubble para observabilidad de red, AgentSight para agentes IA— compartiendo eBPF como sustrato común, gobernanza Cloud Native y vocabulario OpenTelemetry. Es la arquitectura limpia que la industria pidió hace una década y por fin existe.

Referencias

AgentSight:

AgentSight GitHub (eunomia-bpf) — el proyecto.
AgentSight: System-Level Observability for AI Agents Using eBPF (arxiv 2508.02736) — paper formal.
AgentSight ACM workshop publication.
AgentSight blog post (eunomia.dev) — descripción accesible.

OpenTelemetry GenAI semantic conventions:

Plataformas instrumentadas:

Langfuse — MIT, self-host + cloud.
LangSmith — LangChain team.
Arize Phoenix — OSS, OTel-native.
Helicone — proxy simple.
OpenLLMetry (Traceloop) — Apache 2.0, SDK OTel.
Pydantic Logfire — AI observability.

Comparativas 2026:

Cross-references de la serie:

eBPF de cero a Cilium.
Tetragon: seguridad de runtime.
Hubble: observabilidad de red.
Serie de inferencia LLM: KV cache, vLLM en Kubernetes, PagedAttention, Operators LLM K8s.

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.

Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel

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

TL;DR

Tetragon es el motor de seguridad y observabilidad de runtime que el proyecto Cilium publicó como complemento al CNI. Su trabajo no es enrutar paquetes —para eso ya está Cilium— sino observar lo que pasa dentro de los procesos del nodo en tiempo real: qué binario se ejecuta en cada pod, qué archivos abre, qué syscalls invoca, qué capabilities pide, qué conexiones de red establece, qué módulos del kernel se cargan. Lo hace cargando programas eBPF en los hook points del kernel (kprobes, tracepoints, uprobes, LSM hooks) y filtrando los eventos relevantes dentro del propio kernel con un lenguaje declarativo expresado como CRD (TracingPolicy y TracingPolicyNamespaced). El resultado es un flujo de eventos enriquecidos con metadata Kubernetes (pod, namespace, labels) que cuesta menos del 1% de CPU y, lo que diferencia a Tetragon de la competencia, puede bloquear acciones dentro del kernel —matar el proceso con SIGKILL o sobrescribir el retorno de un syscall— antes de que terminen de ejecutarse, sin race conditions. Frente a Falco (que parsea syscalls en userspace, 5-10% overhead, detection-only), Tetragon es “más barato y con enforcement”; frente al kernel desnudo, es “una capa declarativa que tu compañero de operaciones puede leer”. Este artículo es la introducción extensa que necesitas para abordarlo en serio: arquitectura, todos los hooks y selectors, los modos de operación, una guía de casos de uso (auditoría de exec, acceso a archivos sensibles, container escape, cryptomining, detección de rootkits, observabilidad de red) y las trampas que se ven en producción.

Este artículo es la parte 2 de la serie sobre eBPF. La parte 1 —eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP— cubrió eBPF básico, los hooks de networking (XDP, TC, sock_ops), cómo Cilium implementa el datapath y los CRDs del BGP Control Plane v2. Aquí cogemos esos mismos hooks de eBPF y los usamos para algo distinto: observar y, si hace falta, frenar lo que hacen los procesos del cluster.

La analogía: auditd con esteroides en eBPF

Quien lleve unos años administrando Linux ha usado auditd. Es el subsistema clásico del kernel para auditar syscalls: configuras una regla con auditctl (por ejemplo, “monitoriza cualquier open sobre /etc/shadow”) y el kernel envía eventos a un daemon en userspace que los persiste. Funciona, pero tiene dos limitaciones que pesan en clusters Kubernetes modernos:

Sin contexto Kubernetes. auditd reporta procesos por PID y UID. Saber qué pod, qué namespace, qué imagen, qué labels —la información que de verdad importa para responder a un incidente— requiere correlar a posteriori con datos de cri-o o containerd. Es operacionalmente miserable.
Sin enforcement granular. auditd puede generar eventos, pero no puede tomar la decisión de matar el proceso ofensor antes de que termine la syscall. Eso lo dejas a una capa superior que lee los eventos, los procesa y mata el proceso… si llega a tiempo. Carrera por design.

Tetragon es auditd con esteroides: las mismas ideas conceptuales —hooks en syscalls, eventos a userspace— pero implementadas con eBPF moderno, con filtrado dentro del kernel para no pagar el coste de despertar el daemon por cada syscall irrelevante, con metadata Kubernetes inyectada por un agente que conoce el cluster, y con acciones que se ejecutan dentro del propio kernel sin esperar a que userspace decida. Si la regla dice “mata cualquier proceso que abra /etc/shadow desde el namespace prod”, la decisión se toma en el kprobe del kernel y SIGKILL se entrega antes de que el open se complete. No hay race; no hay ventana entre detección y acción.

Qué es Tetragon, arquitectónicamente

Tetragon es un agent que se despliega como DaemonSet (un pod por nodo) y un conjunto de CRDs que definen las políticas a aplicar. El agent tiene cuatro responsabilidades:

Cargar programas eBPF en los hook points que las TracingPolicies activas demanden.
Mantener un cache de metadata Kubernetes (pods, namespaces, labels) leyendo el API server, para poder enriquecer cada evento con el contexto correcto.
Recolectar los eventos que los programas eBPF emiten (vía ring buffers) y serializarlos.
Exportar los eventos a destinos configurables: stdout JSON (típico en sidecars o agentes log-collection), gRPC streaming (para consumirlos desde Hubble u otro consumer), archivo, o Fluentd/Loki/SIEM.

Los programas eBPF no son escritos por el usuario. Tetragon genera el bytecode a partir de las TracingPolicies: lee la política declarativa, decide qué hooks atacar, qué argumentos leer del kernel, qué filtros aplicar en línea y qué acciones ejecutar. El usuario solo escribe YAML.

Esta separación policy declarativa → bytecode eBPF generado es lo que hace a Tetragon usable. Escribir programas eBPF a mano es trabajo de un especialista; escribir una TracingPolicy es trabajo de un SRE con un buen ejemplo a la vista.

Los dos CRDs: TracingPolicy y TracingPolicyNamespaced

Tetragon expone exactamente dos CRDs principales:

TracingPolicy (cluster-scoped, cilium.io/v1alpha1): se aplica a todo el cluster, todos los nodos, todos los pods. Adecuada para políticas de plataforma (todo el cluster debe ser auditado igual): por ejemplo, “registra todo execve en todos los pods” o “mata cualquier proceso que intente cargar un módulo del kernel”.
TracingPolicyNamespaced (namespaced, mismo grupo y versión): se define dentro de un namespace y solo se aplica a los pods de ese namespace. Adecuada para políticas con autonomía por tenant: por ejemplo, “en el namespace prod-payments, mata cualquier connect saliente a una IP fuera del rango corporativo”.

Ambos CRDs tienen exactamente la misma estructura interna. La diferencia es de scope. La distinción se introdujo precisamente para permitir multi-tenancy: que el equipo de seguridad central defina políticas TracingPolicy cluster-wide y que cada tenant pueda añadir las suyas con TracingPolicyNamespaced sin necesitar permisos cluster-admin.

Anatomía de una TracingPolicy

Una política se compone de:

Hook points: qué eventos del kernel observar.
Argumentos: qué datos leer cuando el hook se dispara.
Selectors: filtros que se evalúan dentro del kernel para descartar eventos no relevantes y, opcionalmente, ejecutar acciones cuando coinciden.

Hook points soportados

La documentación oficial enumera cinco familias de hook points:

kprobes: hookean una función del kernel. Las syscalls son un caso particular (cuando syscall: true) porque su ABI es distinta del de las funciones internas. Ejemplos típicos: sys_open, sys_openat, sys_connect, tcp_connect, do_mount, commit_creds. Es el hook más versátil y el que se usa el 80% del tiempo.
tracepoints: hookean tracepoints estáticos compilados en el kernel. Más estables entre versiones de kernel que los kprobes (no dependen de nombres de funciones que pueden cambiar). Ejemplos: syscalls/sys_enter_openat, sched/sched_process_exec.
uprobes: hookean funciones de bibliotecas o binarios en userspace. Sirven para observar primitivas de runtime como funciones de libssl, libc, Go runtime, JVM.
tracepoints USDT (User Statically Defined Tracepoints): tracepoints estáticos definidos en binarios userspace (como los que MySQL, PostgreSQL, OpenJDK exponen). Útiles para observabilidad de aplicaciones.
lsmHooks (LSM, Linux Security Module): hooks del subsistema LSM, donde se enchufa SELinux/AppArmor. Permiten políticas de seguridad muy similares a las de MAC tradicional pero programables con eBPF. Ejemplo: file_open, inode_unlink, socket_bind.

Argumentos

Cada hook puede leer los argumentos de la función a la que está atado. Los tipos soportados cubren los primitivos (int, uint64, bool, string, char_buf) y abstracciones más altas (file, path, sock, linux_binprm, capability, bpf_attr, cred). Los tipos altos son punteros a estructuras del kernel que Tetragon sabe parsear; en lugar de tener que leer un offset, escribes type: file y Tetragon te da el path completo del archivo del descriptor.

Hay un detalle importante de capacidad: en kernels ≥ 5.4, Tetragon puede leer hasta 327 360 bytes de un argumento si se activa el flag de buffers grandes. Es la diferencia entre poder auditar execve con todos sus argv largos completos vs truncarlos a 256 bytes y perder contexto.

Selectors: filtrado en el kernel

Los selectors son lo que hace a Tetragon barato. Sin ellos, cada syscall del nodo dispararía un evento que viajaría kernel → ring buffer → agent → procesado → filtrado → descartado. Con selectors, el filtrado ocurre dentro del propio programa eBPF, en el kernel, y solo los eventos que importan llegan al userspace.

Los selectors disponibles incluyen:

matchArgs: filtra por el valor de un argumento. Operadores: Equal, NotEqual, Prefix, Postfix, GreaterThan, LessThan, Mask, SPort (source port), DPort (dest port), Family (AF_INET vs AF_INET6), State (estado del socket).
matchPIDs: filtra por PID; útil para targeted observation.
matchBinaries: filtra por el binario que ejecuta el syscall (path absoluto), con Operator: In, NotIn, Prefix. Imprescindible para evitar el ruido de procesos legítimos del sistema.
matchNamespaces: filtra por namespace Linux (Pid, Mnt, Net, Ipc, Cgroup, User). Permite políticas específicas para procesos en contenedores vs el host.
matchCapabilities: filtra por capabilities efectivas del proceso. Bloquear acciones que requieran CAP_SYS_ADMIN que se ejecuten en pods que no deberían tenerlas.
matchNamespaceChanges: detecta cambios de namespace (típico de container escape).
matchCapabilityChanges: detecta cambios de capabilities (escalada de privilegios).
matchActions: las acciones que se ejecutan cuando todos los matchers anteriores aciertan.

Acciones: del simple Post al Sigkill

Cuando un selector matchea, se ejecuta una action. Tetragon define varias:

Post: emite un evento al userspace (el caso de observability). Soporta rateLimit para evitar inundar el agent si la condición se dispara mil veces por segundo. La sintaxis acepta 5 para 5 segundos, 5m para 5 minutos, 1h para 1 hora.
Sigkill: envía SIGKILL al proceso ofensor desde dentro del kernel, antes de que la syscall complete. Esto es lo único que garantiza enforcement sin race.
Override: sobrescribe el valor de retorno del syscall. Útil para hacer creer al proceso que el syscall falló (Override -EPERM) sin matarlo. Mejor experiencia para apps que pueden manejar errores; peor para apps que asumen éxito.
Signal: envía cualquier señal arbitraria (no solo SIGKILL).
NoPost: no emite evento, útil cuando se combina con otro selector que sí emite y solo quieres acción sin telemetría duplicada.
FollowFD y UnfollowFD: marcan un file descriptor para seguir su ciclo de vida y enriquecer eventos siguientes con el path original. Útil para audit de “qué proceso leyó este archivo después de abrirlo”.
TrackSock y UntrackSock: idem para sockets.
GetUrl y DnsLookup: hacen peticiones HTTP o resoluciones DNS desde el kernel. Pensado para integraciones con sistemas externos (webhooks de seguridad, lookups de reputación de IP).
NotifyEnforcer y CleanupEnforcerNotification: comunicación con el subsistema de enforcement de Tetragon para acciones complejas.

Modos: detection vs enforcement

Una política se puede declarar en uno de dos modos explícitos:

enforce: las acciones de enforcement (Sigkill, Override, Signal) están activas. Esto es producción.
monitoring: las acciones de enforcement son ignoradas; solo se emiten eventos Post. Esto es el modo “vamos a ver qué pasaría si esto estuviese activado”, crítico para probar políticas sin romper aplicaciones.

El control se hace con el campo spec.options[].name: policy-mode y value: monitoring o enforce. Es la mejor práctica: empezar en monitoring, recolectar eventos durante días, ajustar los selectors hasta que no salgan falsos positivos, y entonces cambiar a enforce.

Ejemplo completo: bloquear escrituras a `/etc/passwd` en namespace prod

Una política realista, comentada línea a línea:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: block-passwd-write
 namespace: prod
spec:
 kprobes:
 - call: "fd_install"
 syscall: false # función del kernel, no syscall
 args:
 - index: 0
 type: int  # file descriptor
 - index: 1
 type: "file" # struct file*
 selectors:
 - matchArgs:
 - index: 1
 operator: "Equal"
 values:
 - "/etc/passwd"
 matchActions:
 - action: Sigkill  # mata el proceso
 rateLimit: "1m" # max una vez por minuto
 options:
 - name: policy-mode
 value: enforce  # modo enforcement activo

fd_install se ejecuta cada vez que un proceso obtiene un nuevo file descriptor; el segundo argumento es la struct file del archivo. Tetragon sabe resolverla a su path absoluto. El matchArgs compara ese path con /etc/passwd. Si matchea, Sigkill mata el proceso antes de que el descriptor llegue siquiera a ser usable. rateLimit: 1m impide que el agent se sature si una aplicación malintencionada lo intenta en bucle.

Casos de uso habituales

Vamos al uso real. Estos son los seis casos que aparecen en cualquier despliegue serio de Tetragon en 2026.

1. Auditoría de ejecución (`execve`)

El caso de uso más básico y, sin embargo, el más valioso. ¿Qué binarios se están ejecutando en cada pod? En un container que se supone que corre solo nginx, ver de pronto un sh o un wget es bandera roja casi siempre.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: audit-execve
spec:
 tracepoints:
 - subsystem: "sched"
 event: "sched_process_exec"
 args:
 - index: 4
 type: linux_binprm  # struct linux_binprm*
 selectors:
 - matchActions:
 - action: Post  # solo eventos, no enforcement

Sin filtros: cada execve del cluster genera un evento. Con metadata K8s, el evento incluye pod, namespace, container, imagen, labels. Lo conviertes en flujo de eventos hacia tu SIEM y montas reglas: “alerta si veo sh, bash, nc, curl, wget, python ejecutándose en cualquier pod del namespace prod-api”.

Variación con enforcement: en lugar de Post, usar matchBinaries con Operator: NotIn y una whitelist, y Sigkill si el binario no está en la lista. Caja muy rígida pero efectiva en pods que son “single-binary” (como un microservicio Go).

2. Acceso a archivos sensibles

Detectar (o bloquear) lecturas y escrituras a archivos críticos: /etc/shadow, /etc/kubernetes/, montajes de Secrets, /var/run/docker.sock, /proc/*/cmdline.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: sensitive-file-access
spec:
 kprobes:
 - call: "security_file_open" # LSM-ish via kprobe
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/etc/shadow"
 - "/var/run/secrets/"
 - "/var/run/docker.sock"
 matchBinaries:
 - operator: "NotIn"
 values:
 - "/usr/bin/kubelet" # acceso legítimo de kubelet
 matchActions:
 - action: Post

El matchBinaries: NotIn es importante: kubelet y otros agentes legítimos del nodo acceden a estos paths constantemente y generarían ruido. Filtramos esos en el kernel.

En enforcement: cambiar Post por Override con argError: -1 (EPERM), de modo que la apertura falle pero el proceso ofensor siga vivo y produzca el error para que las herramientas de tracing lo recojan.

3. Conexiones de red salientes no autorizadas

Detectar conexiones outbound a destinos fuera del rango corporativo. Útil para detectar exfiltración de datos o command-and-control de malware.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: block-external-egress
 namespace: prod
spec:
 kprobes:
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "NotDAddr" # destino NO en estos CIDRs
 values:
 - "10.0.0.0/8"
 - "192.168.0.0/16"
 - "172.16.0.0/12"
 matchActions:
 - action: Sigkill
 options:
 - name: policy-mode
 value: enforce

Esto mata cualquier intento de conexión TCP a una IP que no esté en los CIDRs corporativos, en namespace prod. Cilium ya hace esto con NetworkPolicy, pero Tetragon tiene dos ventajas complementarias:

Te da el proceso que intentó la conexión, no solo “el pod X intentó conectar a Y”.
Funciona también para protocolos exóticos donde NetworkPolicy es menos expresiva.

4. Detección de container escape

Container escape es la pesadilla operacional: un proceso dentro de un contenedor consigue romper el aislamiento (vía un kernel exploit, una capability mal puesta, un mount hostPath mal configurado) y obtener acceso al host. Tres señales típicas:

Cambio de namespace del proceso (sale del namespace pid del contenedor).
setns o unshare en procesos no-init.
Acceso a /proc/1/root o /dev/ desde un contenedor.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: detect-container-escape
spec:
 kprobes:
 - call: "__x64_sys_setns"
 syscall: true
 args:
 - index: 0
 type: int
 - index: 1
 type: int
 selectors:
 - matchNamespaces:
 - namespace: Pid
 operator: NotIn
 values: ["host_ns"] # solo procesos NO en pid namespace del host
 matchActions:
 - action: Sigkill
 - call: "__x64_sys_unshare"
 syscall: true
 args:
 - index: 0
 type: int
 selectors:
 - matchNamespaceChanges:
 - unshare: true
 matchActions:
 - action: Post

__x64_sys_setns con destino el namespace del host desde un proceso en contenedor es prácticamente siempre malicioso (los containers legítimos no necesitan esto en runtime).

5. Cryptomining

Los procesos de minería tienen perfiles bastante reconocibles:

Procesos con nombres como xmrig, minerd, cgminer, o procesos legítimos como python ejecutando scripts con uso intensivo de CPU.
Conexiones outbound a pools de minería conocidas (lista pública de IPs y dominios).
Uso anómalo de /dev/cpu_dma_latency para evitar throttling.

Una política combinada:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: detect-cryptomining
spec:
 tracepoints:
 - subsystem: "sched"
 event: "sched_process_exec"
 args:
 - index: 4
 type: linux_binprm
 selectors:
 - matchArgs:
 - index: 4
 operator: "Postfix"
 values:
 - "/xmrig"
 - "/minerd"
 - "/cgminer"
 matchActions:
 - action: Sigkill
 kprobes:
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "DPort"
 values: ["3333", "5555", "7777", "14444"] # puertos comunes de pools
 matchActions:
 - action: Post  # solo registra

La doble política: matar binarios con nombres clásicos (cinturón) y registrar conexiones a puertos de pools (tirantes), para alertar también cuando alguien renombre xmrig a nginx-helper o use puertos exóticos.

6. Detección de rootkits y módulos del kernel sospechosos

Los rootkits modernos cargan módulos del kernel para parchear funciones (hide procesos, hide conexiones de red, esconder archivos). Detectarlos:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: kernel-module-load
spec:
 kprobes:
 - call: "do_init_module"
 syscall: false
 args:
 - index: 0
 type: "string"
 selectors:
 - matchActions:
 - action: Post
 - call: "security_kernel_read_file"
 syscall: false
 args:
 - index: 0
 type: "file"
 - index: 1
 type: int
 selectors:
 - matchArgs:
 - index: 1
 operator: "Equal"
 values: ["READING_MODULE"]
 matchActions:
 - action: Post

En un cluster Kubernetes “bien configurado” no se cargan módulos nuevos del kernel en runtime; cualquier evento aquí es altamente sospechoso. Combina con enforcement para máquinas donde los módulos deberían estar fijos: Sigkill al que intenta cargar uno.

Bonus: detección de modificación de eBPF maps por terceros

Como tendencia 2025-2026: cargar programas eBPF maliciosos para esconder presencia. Tetragon puede observar el bpf syscall:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: audit-bpf-syscalls
spec:
 kprobes:
 - call: "__x64_sys_bpf"
 syscall: true
 args:
 - index: 0
 type: int  # bpf cmd
 - index: 1
 type: bpf_attr
 selectors:
 - matchBinaries:
 - operator: "NotIn"
 values:
 - "/usr/bin/cilium-agent"
 - "/usr/bin/tetragon"
 - "/usr/bin/bpftool"
 matchActions:
 - action: Post

Cualquier proceso que no sea uno de los agentes legítimos cargando programas eBPF: te interesa saberlo.

Comparativa con Falco

Falco es el competidor más cercano: también es runtime security para Kubernetes, también basado originalmente en eBPF (y antes en kernel modules), también con políticas declarativas. Tres años atrás eran funcionalmente parecidos. En 2026 la divergencia es clara:

Dimensión	Tetragon	Falco
Filosofía	Cilium-native, integrado	Standalone, genérico
Filtrado	En el kernel (eBPF)	Parsing en userspace
Overhead típico	<1% CPU	5-10% CPU
Enforcement	Sí, in-kernel (Sigkill, Override)	No nativo (depende de plugins)
Race conditions	No (acción atómica con syscall)	Sí en enforcement vía plugins
Detección de falsos positivos	Baja (contexto K8s en kernel)	Más alta (parsing posterior)
Latencia de detección	5-26 ms	~10 ms (más constante)
Madurez del ecosistema	Joven, en crecimiento	Maduro, mucho material
Comunidad	Cilium / CNCF Incubating	CNCF Graduated
Integraciones	Hubble nativo	Falcosidekick, muchas
CRDs por política	TracingPolicy / Namespaced	Sin CRDs; reglas en YAML

Cuándo elegir cada uno:

Tetragon si ya usas Cilium, si necesitas enforcement en el kernel (no detection-only), si el overhead te importa (cargas con muchas syscalls), y si valoras la integración con Hubble. Detección de container escape y cryptomining es donde más se mide su ventaja sobre Falco.
Falco si quieres una herramienta independiente del CNI, si necesitas el catálogo de reglas pre-hechas y la comunidad amplia, si tu cluster no es Cilium, o si la integración con SIEMs y notificadores ya hechos (Falcosidekick) te ahorra trabajo.
Los dos si la organización es grande: Falco para amplitud de detección, Tetragon para enforcement quirúrgico en cargas críticas. Es lo que más se ve en empresas que llevan años con Falco y añaden Tetragon para casos específicos.

Hubble + Tetragon: observabilidad unificada

Hubble es el componente de observabilidad de tráfico de Cilium: muestra flow logs L3-L7 con cero impacto en latencia. Tetragon expone sus eventos por gRPC con el mismo formato y vocabulario que Hubble, lo que permite:

Verlos en la misma UI (Hubble UI muestra eventos Tetragon como una “capa” más).
Correlar eventos de red (Hubble) con eventos de proceso (Tetragon) en el mismo timeline.
Exportarlos juntos a Loki/Tempo/SIEM como un flujo único.

La sinergia clave: Hubble te dice “este pod hizo una conexión TCP a 1.2.3.4:80”. Tetragon te dice “este pod ejecutó curl 1.2.3.4 desde un binario bash lanzado por pid 1234”. Juntos te dan la historia completa.

Despliegue y operación

Helm

Instalación canónica con Helm:

helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon \
 --namespace kube-system \
 --set tetragon.exportFilename=/var/log/tetragon/tetragon.log \
 --set tetragon.exportFileMaxSizeMB=50 \
 --set tetragon.exportFileRotationInterval=24h

Tetragon despliega su DaemonSet, sus CRDs y un service para Hubble. Por defecto, expone los eventos en stdout del pod del agent (los recoge cualquier log aggregator del cluster).

CLI `tetra`

Tetragon trae una CLI llamada tetra para investigación interactiva:

# stream en tiempo real de eventos del nodo
tetra getevents -o compact --pods <pod-name>

# events JSON estructurado para procesar con jq
tetra getevents -o json --since 5m --namespace prod

# ver políticas cargadas
tetra tracingpolicy list

Es la mejor herramienta para depurar políticas en monitoring antes de pasarlas a enforce.

Exportar a SIEM

Tres rutas habituales:

stdout + log aggregator: el agent escribe JSON al stdout, Fluent Bit/Vector lo recoge y lo envía a Splunk/Datadog/Elastic. Simple, funciona con cualquier infraestructura de logging.
gRPC streaming: para integraciones de baja latencia. Un consumer gRPC propio o Hubble Relay.
Archivo + rotación: para entornos air-gapped o auditorías regulatorias que exigen logs persistentes con rotación controlada.

Performance

Los benchmarks publicados consistentemente sitúan a Tetragon en <1% de CPU del nodo en cargas reales, comparado con 5-10% de Falco en las mismas cargas. La razón es la separación arquitectónica: Tetragon filtra en el kernel y solo lleva a userspace los eventos que realmente importan; Falco lleva todos los syscalls a userspace y los filtra allí. En clusters con miles de pods haciendo cientos de miles de syscalls por segundo, la diferencia se nota en la factura.

Trampas operativas comunes

`monitoring` permanente

La mayor trampa es no llegar nunca a enforce: empezar bien con políticas en monitoring, recolectar eventos, ajustar selectors, y luego nunca conmutar. Resultado: tienes detection sin prevention, exactamente lo que Falco te daba sin pagar la complejidad de Tetragon. Si vas a usar Tetragon, planifica el camino a enforce de las políticas críticas.

Selectors demasiado laxos

Una política con un único matchActions: Post sin selectors específicos genera eventos por cada syscall del hook elegido. En un nodo serio son decenas de miles por segundo, que llenan logs, saturan exporters y esconden la señal en el ruido. Empieza siempre con filtros estrictos (matchBinaries, matchNamespaces, matchPIDs) y abre cuando sepas qué buscas.

Kernel demasiado viejo

Tetragon necesita features de eBPF modernas. Kernels < 5.4 no tienen el soporte de buffers grandes (necesario para execve con argv completos). Kernels < 5.10 no tienen muchos de los hooks LSM. Kernel 5.15+ es el mínimo recomendado para producción y 6.1+ para tener todas las features.

Hooks en funciones del kernel renombradas

Los kprobes están atados a nombres de funciones del kernel que pueden cambiar entre versiones. Una política que use __x64_sys_setns puede fallar silenciosamente en un kernel donde la función se llama __do_sys_setns. Soluciones: usar tracepoints estáticos cuando estén disponibles (más estables), o tener políticas alternativas con varios call por compatibilidad.

`Sigkill` en namespaces críticos

Aplicar Sigkill a procesos en kube-system o cilium-system puede romper el cluster. Las políticas de enforcement deben excluir explícitamente los namespaces de plataforma con matchNamespaces Operator: NotIn, o limitar el scope con TracingPolicyNamespaced para asegurar que no acciona en sistemas que no debe.

`rateLimit` ausente

Una política sin rateLimit en Post puede sufrir un fan-out catastrófico si la condición se cumple millones de veces en un instante (típico en bucles de ataque o en bugs de aplicación). El agent se satura, los eventos se pierden, los logs se desbordan. Pon siempre rateLimit sensato en políticas de detección, especialmente en hooks de alta frecuencia como tcp_connect o execve.

Lo que no hemos cubierto (próximos artículos)

eBPF LSM hooks en profundidad: cómo se relacionan con SELinux/AppArmor y cuándo Tetragon es la herramienta correcta vs MAC clásico.
Hubble UI con Tetragon overlay: configuración de la UI para mostrar la observabilidad de proceso y la de red en el mismo timeline.
Integración con OPA/Kyverno: cómo Tetragon complementa policy engines de admission (Kyverno valida en admission; Tetragon valida en runtime).
Forensics con eBPF: combinando Tetragon con herramientas como Beyla u OpenTelemetry para trazar la cadena completa de un incidente desde la conexión inicial hasta la syscall final.

Referencias

Documentación oficial (mayo 2026):

Tetragon — sitio oficial — punto de entrada.
Tetragon docs — Tracing Policy — referencia conceptual.
Tetragon docs — Hook points — kprobes, tracepoints, uprobes, LSM, USDT.
Tetragon docs — Selectors — referencia completa de filtros.
Tetragon docs — Enforcement Mode.
Tetragon docs — Kubernetes Identity Aware Policies — TracingPolicyNamespaced.
Tetragon GitHub.

Comparativas y análisis:

Comparative Analysis of eBPF-Based Runtime Security Monitoring (paper SciTePress 2025) — benchmark con números independientes.
Best eBPF Security Solutions for Kubernetes (ARMO, 2026) — comparativa Falco vs Tetragon vs KubeArmor.
Falco vs. Tetragon (Asim Mirza, Medium) — análisis con casos de uso.
Deep Dive into Tetragon (A Security Engineer) — recorrido por dentro del agente.
Tetragon Series, Part 2: Enforcing Sensitive File Access (Medium).

Ecosistema:

Cilium Hubble — observabilidad de red.
Falco — sitio oficial — el otro grande del campo.
KubeArmor — la tercera opción, con AppArmor + eBPF.

Cross-references:

Parte 1 de la serie: eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP — los fundamentos de eBPF que aquí damos por leídos.
Kubernetes con Cilium BGP: servicios accesibles sin Ingress — punto de partida del ecosistema Cilium en este blog.

Observabilidad on lo0 — Blog Técnico

eBPF en inferencia local y detección estadística de drift: el cierre del ciclo de observabilidad LLM en 2026

TL;DR

La analogía: el cardiograma del agente

Parte 1 — eBPF aplicado a inferencia local

Por qué la inferencia local cambia el juego

ProfInfer: el paper que formaliza el patrón

Dónde hookear: el mapa por motor

llama.cpp

vLLM

CUDA en general

Hardware counters: la otra mitad

Comparativa con AgentSight

Casos de uso de eBPF en inferencia local

Parte 2 — Análisis estadístico de flows: detectar drift

Por qué tracing, evals y guardrails no detectan drift

Las tres tipologías de drift LLM en 2026

El concepto técnico clave: embedding-space shift

Tests estadísticos: KS, PSI, MMD

Herramientas 2026

Evidently AI

NannyML

WhyLabs

Otras menciones

Parte 3 — El stack completo: cómo encaja todo

Patrón operativo de drift en 2026

Paso 1 — Establecer baseline

Paso 2 — Pipeline continuo de comparación

Paso 3 — Alertas y workflow de investigación

Paso 4 — Refresh de baseline

Trampas operativas

Baseline contaminado

Threshold demasiado bajo

Embeddings no representativos

Sobrecarga de almacenamiento

Confundir drift con “el sistema funciona”

Privacy en almacenamiento de embeddings

eBPF en producción sin profile guardrails

Cerrando las dos series

Lo que queda para futuras series

Referencias

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

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

`_meta` perdido al pasar por proxy

`stdiocap`: capturar stdio de servidores MCP locales

3. Hubble CLI (`hubble`)