Mientras la industria discute cómo llamar al stack moderno de observabilidad —observability 2.0 o ya 3.0—, detrás de la terminología se esconden tres desplazamientos concretos. La instrumentación salió del código y bajó al kernel (eBPF). La telemetría se estandarizó en torno a OpenTelemetry. Y la búsqueda de la causa raíz empezó a migrar del humano a la máquina. Cada capa siguiente solo se amortiza si la de abajo está en orden — y el orden de inversión es justo lo que los equipos confunden con más frecuencia.
El monitoring responde «¿funciona?». La observabilidad, «¿por qué no?»
El monitoring responde a «¿funciona el sistema y a qué velocidad?». La observabilidad responde a «¿por qué va lento y dónde exactamente?». En Kubernetes, sin lo segundo no se cierran los incidentes que cruzan componentes: el síntoma «subió la latencia» no puede conectarse con la causa «un nodo entró en MemoryPressure, el kubelet desalojó pods, los endpoints del servicio oscilaron» si solo ves métricas de la aplicación.
Por eso, a los tres pilares clásicos —métricas, logs, trazas— se les suma en Kubernetes una cuarta señal: los eventos del clúster y los metadatos de los workloads. OOMKills, desalojos, decisiones del HPA, fallos del scheduler, rechazos de admission — es el registro de decisiones del orquestador, y sin él el análisis del incidente degenera en «lo reiniciamos y funcionó».
La instrumentación bajó al kernel
Durante años el precio de entrada al distributed tracing fue alto: un SDK en cada servicio, una release, un ciclo de regresión. eBPF eliminó esa barrera. OBI —OpenTelemetry eBPF Instrumentation— se despliega como DaemonSet y en un día da al clúster una línea base sin un solo cambio de código: métricas RED, trazas HTTP y gRPC, flujos service-to-service, actividad de bases de datos y —un bonus inesperado— visibilidad del tráfico TLS sin descifrar, porque la interceptación ocurre a nivel de syscalls, antes del cifrado. Los requisitos son modestos: kernel de Linux 5.8+ y privilegios BPF.
eBPF tiene un techo: ve la red y las syscalls, pero no el contexto de negocio — qué order_id, qué tenant. De ahí la regla de trabajo «Observe first. Instrument later.»: primero una línea base eBPF para todo el clúster, después auto-instrumentación a nivel de infraestructura para la flota políglota, y solo en las rutas críticas que impactan ingresos, el SDK manual con atributos propios. La instrumentación deja de ser asunto del desarrollador y pasa a ser asunto de la plataforma.
OpenTelemetry es un contrato, no una herramienta
OTel es un estándar: SDK unificados, convenciones semánticas y un protocolo de transporte. Instrumentas la aplicación una vez y exportas a donde sea, de Tempo a un APM comercial, sin lock-in. Las convenciones semánticas (service.name, k8s.pod.name, http.status_code) dan a todas las señales un vocabulario común — y un vocabulario común más un trace_id de extremo a extremo es lo que convierte tres almacenes en un solo sistema.
Un punto clave para brownfield: OTel no exige tirar el Prometheus o VictoriaMetrics existente. El exportador prometheusremotewrite escribe las métricas en la misma TSDB; el scraping se queda para los targets legacy y el collector se añade para los nuevos. La migración es evolución, no revolución.
La capa de IA: el LLM nunca ve una métrica primero
La tentación de «enviemos las métricas a GPT y que encuentre las anomalías» se desmorona con datos reales: demasiado lento, demasiado caro, no determinista. El patrón de producción es otro — filter cheap, escalate smart. Detectores baratos absorben el 95–99 % de los eventos antes de cualquier IA: Isolation Forest sobre métricas (inferencia en microsegundos), minería de plantillas Drain3 sobre logs, líneas base de frecuencia. El LLM recibe solo el resto escalado — lo «desconocido» y los «picos» — y hace lo que sabe hacer: razonar sobre contexto desordenado, conectar la señal con los deploys recientes, redactar el borrador del postmortem. Es división del trabajo, no competencia: el ML hace thresholding numérico a escala; el LLM, el razonamiento.
El segundo pilar de la capa de IA es la correlación con los cambios: el 70–80 % de los incidentes de producción están relacionados con cambios. Marcadores de deploy desde ArgoCD, cambios de configuración, mutaciones IAM del audit log — un flujo de eventos aparte, junto a la telemetría. Ante una anomalía, la primera pregunta de la máquina es la misma que la de un SRE con experiencia: «¿qué se desplegó en la última hora?»
Las cifras del sector dan que pensar: los líderes recortan el MTTR un 40–70 %, pero solo el 4 % de las organizaciones ha operacionalizado la IA por completo y la mitad sigue atascada en pilotos. La paradoja: los presupuestos de observabilidad crecieron un 70 % y el toil manual, un 30 %. La razón — una IA atornillada sobre un stack fragmentado sin capa de contexto unificada trabaja mirando por el ojo de una cerradura en vez de ver el cuadro completo.
El orden de inversión
Las capas se amortizan estrictamente de abajo arriba. Primero, la capa unificada de señales: OTel, un trace_id de extremo a extremo, la cuarta señal de los eventos del clúster. Después, cobertura sin código: línea base eBPF y auto-instrumentación provista por la plataforma. Luego, filtros ML baratos y un flujo de change-events. Y solo sobre ese cimiento, un LLM para la causa raíz. La IA en observabilidad es el tejado, no los cimientos: empezar por el tejado significa pagar tokens por revisar diez mil métricas — un trabajo que resuelve un modelo de cincuenta líneas.