La especificación OpenTelemetry GenAI semconv define en 2026 los atributos estándar para instrumentar llamadas a LLMs, ejecución de herramientas y operaciones de agentes. Se instrumenta una vez con el SDK de Anthropic, se recolectan trazas con OTel Collector y se consultan con TraceQL en Grafana Tempo. El resultado es un dashboard portable que sobrevive a cambios de modelo, proveedor y framework sin reescritura.
Después de año y medio llenando tableros con agentes en producción, la pregunta que separa equipos que envían fiable de los que van a ciegas sigue siendo la misma: ¿cómo mides que el agente está funcionando?
Una selección de postmortems publicados entre 2025 y 2026 por equipos que operan sistemas con IA en producción revela patrones repetidos: fallos en guardrails, deriva silenciosa de modelos, dependencia oculta del proveedor y una colección de sustos que vale la pena destilar.
Los cuadros de mando con IA llevan un par de años prometiendo detección de anomalías mágica y causa raíz automática. La realidad es más modesta pero también más útil, si se sabe separar el ruido del valor real. Repaso honesto de qué funciona y qué no.
Tras una década de Prometheus, tres años de consolidación alrededor de OpenTelemetry y la madurez definitiva del stack abierto con Grafana, Loki y Tempo, recomendaciones concretas para equipos que arrancan o revisan su capa de observabilidad. Qué encaja, qué sobra y qué evitar.
Los agentes que encadenan llamadas a modelos, herramientas y memoria son difíciles de depurar sin una instrumentación pensada para ellos. Después de un año largo operando agentes en producción, repaso qué hay que medir primero, qué estándares están consolidándose y qué errores caros evita tener trazas bien hechas desde el inicio.
La combinación de Parca para perfiles continuos, Beyla para auto-instrumentación vía eBPF y Grafana como capa de visualización ofrece observabilidad profunda sin tocar código. Repaso a cómo encajan y dónde se sufren los límites.
El profiling continuo con eBPF toma muestras del stack de cada proceso cada pocos milisegundos sin tocar el código, y guarda el historial para comparar el rendimiento de una semana con otra. El coste medido en producción está entre el 1% y el 3% de CPU, y compensa sobre todo en bases de datos, pasarelas de API y servicios de alta concurrencia.
Han pasado siete años desde que Google publicó el Workbook, y buena parte del libro no ha envejecido. Repaso los patrones que de verdad aplicamos en equipos pequeños y los que resultaron ser cultura de campus.
Dos años después de que Zero Trust dejase de ser palabra de marketing, toca mirar cómo conecta con el SIEM del día a día. Reflexión sobre señales útiles, ruido evitable y decisiones que de verdad cambian la postura de seguridad.
El profiling continuo con eBPF captura flame graphs de CPU de todos los procesos de un nodo Linux las 24 horas, sin instrumentar código ni reiniciar servicios, con menos del 1 % de overhead. Parca cubre el clúster completo, Beyla añade métricas y trazas HTTP/gRPC automáticas, y Pyroscope aporta detalle nativo por lenguaje en los servicios más críticos.
Las aplicaciones basadas en LLM necesitan tres planos de observabilidad distintos: trazas de prompt y respuesta para depurar alucinaciones, seguimiento de costes por token y por función, y evaluación de calidad de respuesta. Herramientas como Langfuse, LangSmith y Helicone cubren estos planos con instrumentación específica.
Los SLOs y error budgets solo funcionan cuando el budget informa decisiones reales. Un feature freeze que se dispara al agotarse el presupuesto, una velocidad de despliegue que se ajusta al consumo. Con dos o tres SLIs bien elegidos, una policy de freeze clara y herramientas como Prometheus con Sloth, un equipo consigue equilibrar velocidad y fiabilidad de forma sostenible.
Loki indexa solo labels, no el contenido del log, lo que reduce el coste de almacenamiento frente a Elasticsearch. El principal riesgo en produccion es la cardinalidad explosiva cada combinacion unica de label-valores genera un stream y degrada las queries. Separar los paths de lectura y escritura garantiza que una consulta pesada no sature la ingesta.
Falco es un proyecto graduado de la CNCF que engancha el kernel de Linux con eBPF y detecta comportamientos anómalos en syscalls sin instrumentar ninguna aplicación. Se despliega como DaemonSet en Kubernetes, emite eventos en JSON y necesita proceso de triaje para aportar valor. En producción, la alert fatigue es el problema más común.
Para escribir alertas de Prometheus que no acaben ignoradas, alerta sobre síntomas observables por el cliente (latencia, error rate, saturación) en vez de causas internas como CPU o memoria, define SLOs con burn rate multi-ventana para dosificar la gravedad, añade una alerta watchdog que confirme que el sistema sigue vivo y revisa el ratio señal/ruido cada trimestre.
6 min2843,9
Usamos cookies propias y de terceros para analizar el tráfico del sitio. Puedes aceptarlas, rechazarlas o configurar tu elección.
Más información sobre las cookies
Preferencias de cookies
NecesariasImprescindibles para el funcionamiento del sitio. Siempre activas.
AnalíticasNos ayudan a entender cómo se usa el sitio (Google Analytics).
