Phase 17 - Lesson 13

LLM Observability Stack Selection

El mercado de observabilidad en 2026 se divide en dos categorías. Las plataformas de desarrollo (LangSmith, Langfuse, Comet Opik) agrupan el monitoreo con evaluaciones (evals), administración de prompts y replays de sesión. Las herramientas de gateway/instrumentación (Helicone, SigNoz, OpenLLMetry, Phoenix) se enfocan en telemetría. Langfuse posee un núcleo con licencia MIT y un sólido equilibrio de código abierto (50K eventos/mes gratis en la nube). Phoenix es nativo de OpenTelemetry bajo Elastic License 2.0 — excelente para visualización de desvíos (drift)/RAG, pero no como backend persistente de producción. Arize AX utiliza integración de copia cero con Iceberg/Parquet, afirmando ser 100x más barato que la observabilidad monolítica. LangSmith lidera para LangChain/LangGraph, costando $39/usuario/mes, con auto-hospedaje disponible solo en la versión Enterprise. Helicone se basa en proxy con configuración de 15-30 minutos, ofreciendo 100K solicitudes/mes gratis, pero con menor profundidad en trazas (traces) de agentes. Patrón común en producción: Gateway (Helicone/Portkey) + plataforma de evaluación (Phoenix/TruLens) integrados a través de OpenTelemetry.

Type: Learn Languages: Python (stdlib, toy trace-sampling simulator) Prerequisites: Phase 17 · 08 (Inference Metrics), Phase 14 (Agent Engineering) Time: ~60 minutos

Learning Objectives

• Distinguir plataformas de desarrollo (paquete completo: evaluaciones + prompts + sesiones) de herramientas de gateway/telemetría (solo trazas + métricas).
• Mapear seis herramientas principales (Langfuse, LangSmith, Phoenix, Arize AX, Helicone, Opik) de acuerdo con sus licencias, precios y casos de uso ideales.
• Explicar el patrón de integración mediante OpenTelemetry que permite combinar una herramienta de gateway con una plataforma de evaluación independiente.
• Identificar el elemento diferenciador de costo en 2026 (enfoque de copia cero de Arize AX vs ingesta monolítica) e indicar el multiplicador aproximado de 100x.

El Problema

Has implementado una funcionalidad basada en LLM. Funciona. No obstante, no tienes visibilidad sobre fallas de prompt, loops de herramientas (tool loops), regresiones de latencia, picos de costo o tasa de acierto en el caché de prompts. Al buscar "LLM observability" en Google, te encuentras con ocho herramientas que afirman resolver el mismo problema con tres rangos de precios diferentes.

No resuelven el mismo problema. LangSmith responde "¿por qué falló esta ejecución de LangGraph?". Phoenix responde "¿mi pipeline de RAG está sufriendo desvíos?". Helicone responde "¿qué aplicación está consumiendo tokens?". Langfuse responde "¿puedo auto-hospedar toda la estructura?". Herramientas diferentes, públicos diferentes.

La elección involucra cuatro ejes: stack (¿LangChain? ¿SDK puro? ¿multi-vendor?), tolerancia de licencia (¿solo MIT? ¿sirve Elastic? ¿comercial está bien?), presupuesto (¿capa gratuita? ¿

Opik (Comet) — Plataforma de Desarrollo OSS

• Licenciado bajo Apache 2.0, totalmente de código abierto.
• Conjunto de características similar a Langfuse con la herencia de Comet.
• Punto fuerte: equipos de ML que ya utilizan Comet y desean observabilidad de LLM en el mismo panel.

SigNoz — Monitoreo de Rendimiento (APM) Completo con OpenTelemetry

• Licenciado bajo Apache 2.0. Gestiona APM tradicional y llamadas de LLM a través de OpenTelemetry.
• Punto fuerte: observabilidad unificada entre servicios y llamadas de LLM.

La integración: OpenTelemetry + Convenciones Semánticas de GenAI

OpenTelemetry publicó convenciones semánticas de GenAI a finales de 2025 (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens). Las herramientas que consonem OTel pueden interoperar con facilidad. El patrón que emerge en producción es:

1. Emitir datos OTel con convenciones de GenAI desde cada llamada de LLM.
2. Enrutarlos a un gateway (Helicone / Portkey) para el monitoreo del día a día.
3. Direccionar los datos simultáneamente a una plataforma de evaluación (Phoenix / Langfuse) para monitorear regresiones.
4. Archivar en el data lake (Iceberg) para análisis de largo plazo a través de Arize AX o DuckDB.

La trampa: instrumentar en la capa incorrecta

Instrumentar dentro de tu framework de agentes (por ejemplo, agregando trazas de LangSmith) te acopla a ese framework específico. Instrumentar en la capa HTTP o en el SDK de OpenAI (a través de OpenLLMetry o tu gateway) es una opción portable.

Muestreo — no puedes conservar todo

Con más de 1 millón de solicitudes por día, el costo de retención total de trazas supera el costo de las llamadas de LLM. Utiliza reglas de muestreo (sampling): 100% para errores, 100% para casos de alto costo, 5% para éxitos rutinarios. Conserva los datos agregados siempre; guarda los logs brutos para la cola larga.

Números que deberías recordar

• Capa gratuita de Langfuse en la nube: 50K eventos/mes.
• LangSmith: $39/usuario/mes.
• Capa gratuita de Helicone: 100K solicitudes/mes.
• Promesa de Arize AX: ~100x más barato que soluciones monolíticas a escala.
• Convenciones de GenAI de OpenTelemetry: lanzadas en 2025, ampliamente adoptadas en 2026.

Pruébalo

code/main.py simula un día de 1 millón de trazas bajo diferentes estrategias de retención (100% de ingesta, muestreo simple, muestreo + errores). Presenta el costo de almacenamiento y la pérdida de datos en cada una.

Envíalo a Producción

Esta lección produce outputs/skill-observability-stack.md. Con base en la stack, la escala, el presupuesto y las licencias de la organización, elige la(s) mejor(es) herramienta(s).

Ejercicios

1. Tu equipo usa LangChain y quiere una solución de observabilidad de código abierto auto-hospedada. Elige entre Langfuse u Opik y justifica tu elección.
2. En un volumen de 5 millones de trazas/día donde el presupuesto de Datadog es de
   50K/mes, calcula el punto de equilibrio financiero para la adopción de Arize AX.
3. Diseña un conjunto de atributos de GenAI de OpenTelemetry que la directiva de tu empresa debería exigir en cada llamada de LLM.
4. Argumenta si Phoenix por sí solo es suficiente para entornos de producción. ¿Cuándo deja de serlo?
5. Helicone añade 20ms de sobrecarga de proxy. Con un TTFT de P99 de 300 ms, ¿es aceptable esa sobrecarga? ¿Qué pasa si el SLA del producto es de 100 ms?

Términos Clave

Lecturas Recomendadas

• SigNoz — Top LLM Observability Tools 2026
• Langfuse — Arize AX Alternative analysis
• PremAI — Setting Up Langfuse, LangSmith, Helicone, Phoenix
• OpenTelemetry GenAI Semantic Conventions
• Arize Phoenix docs
• Helicone docs