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 catorce meses probando herramientas DevOps con IA integrada en varios equipos, el stack que se queda es reducido: Claude Code, Cursor y Aider para código; PagerDuty AIOps, Datadog Bits AI y Grafana Assistant para triage de alertas; y OpenTofu con OPA para generar infraestructura acotada por reglas de política.
Los agentes de IA fallan en producción: lo que importa es cómo respondes en los primeros veinte minutos. Este runbook cubre clasificación de severidad, aislar antes de investigar, purgar memoria contaminada, comunicar sin inventar datos y convertir cada incidente en una prueba de regresión antes de darlo por cerrado.
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.
cAdvisor sigue incluido en kubelet y cubre métricas de superficie, pero en un cluster Kubernetes de producción no basta. El stack mínimo moderno combina cAdvisor con kube-state-metrics, node-exporter, Prometheus y Grafana como base; eBPF para visibilidad profunda de red y syscalls; y OpenTelemetry para contexto de aplicación.
Fluent Bit es el recolector de logs de la CNCF: un binario en C de apenas 1,5 MB que rara vez supera los 30 MB de memoria en producción. Compite con Promtail, Vector y Filebeat, y gana cuando hay varios destinos o nodos con pocos recursos, gracias a un pipeline de entradas, parsers, filtros y salidas fácil de razonar y depurar.
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.
eBPF es una tecnología del kernel de Linux que permite cargar y ejecutar programas verificados con alto rendimiento, sin recompilar el kernel ni reiniciar el sistema. Corre de forma segura en una máquina virtual dentro del kernel y es la base de herramientas como Cilium, Pixie, Falco y Tetragon para tracing, redes y seguridad en tiempo real.
PostgreSQL 16, publicado en septiembre de 2023, suma replicación lógica desde un standby, la vista pg_stat_io para desglosar el I/O por tipo de operación y contexto, y paralelismo en FULL OUTER JOIN. Migrar desde la 15 es sencillo; la 13 pierde soporte en noviembre de 2025, así que conviene planificar la actualización cuanto antes.
El stack Grafana combina tres proyectos open source: Loki para logs, Tempo para trazas y Mimir para métricas. Los tres guardan los datos en object storage (S3/GCS) con un índice mínimo, en vez de indexarlo todo como Elasticsearch, lo que abarata mucho el coste a gran volumen y permite correlacionar métrica, log y traza desde un mismo panel de Grafana.
OpenTelemetry es el proyecto de la CNCF, graduado en mayo de 2026, que unifica logs, métricas y trazas bajo un único SDK y el protocolo OTLP, sin atarte a un backend concreto. Las trazas son estables desde 2021 y las métricas desde 2023; los logs siguen madurando, pero ya compensan en proyectos nuevos.
Kubernetes 1.28 introduce sidecar containers nativos en alpha mediante KEP-753: añadir el campo restartPolicy Always a initContainers garantiza el orden de arranque y apagado correcto. Resuelve el problema de Jobs que nunca terminan. Istio, Linkerd y agentes de observabilidad como Fluent Bit son los beneficiarios directos.
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.
Pixie usa eBPF para instrumentar automáticamente clústeres de Kubernetes sin modificar el código de la aplicación. Un agente por nodo captura tráfico HTTP, gRPC, SQL y Redis a nivel de kernel y expone en minutos mapa de servicios, perfiles de CPU y trazas SQL. Complementa a Prometheus para diagnóstico reactivo sin sidecars ni redeploys.
eBPF (Extended Berkeley Packet Filter) es una tecnología del kernel de Linux que ejecuta programas verificados directamente en el kernel, sin módulos ni cambios de código fuente. El verificador rechaza cualquier programa inseguro antes de ejecutarlo, y permite monitorizar llamadas al sistema, tráfico de red y operaciones de E/S con menor coste de CPU que las sondas externas tradicionales.
5 min2684,3
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).
