La comunidad de OpenTelemetry inició la transición para dejar de recomendar Span.AddEvent y Span.RecordException, y concentrar la emisión de eventos en Logs API con correlación por contexto. El cambio apunta a simplificar instrumentación, reducir ambigüedad entre señales y mantener compatibilidad operativa mediante puentes de SDK.
Introducción
OpenTelemetry viene madurando una idea que impacta directo en equipos de plataforma y observabilidad: tratar los eventos como logs correlacionados con trazas, en lugar de mantener dos caminos paralelos para representar el mismo concepto. Esta semana, el proyecto publicó formalmente la deprecación de la API de Span Events para nuevo desarrollo, con una ruta de migración gradual que evita romper pipelines existentes.
La novedad no implica “borrar” los eventos en trazas de un día para otro. El foco está en unificar cómo se generan los eventos hacia adelante: Logs API como vía preferida, correlación por contexto y mecanismos de compatibilidad para quienes todavía dependen de vistas centradas en spans.
Qué ocurrió
En su anuncio oficial, OpenTelemetry explica que la coexistencia de dos APIs para eventos —span events y log-based events— estaba generando fricción técnica: guías divididas para autores de instrumentación, experiencias inconsistentes entre lenguajes y mayores costos de evolución del estándar. La decisión, alineada con el plan de OTEP 4430, es deprecar métodos como Span.AddEvent y Span.RecordException como recomendación para código nuevo.
La propuesta mantiene un principio clave: compatibilidad operativa. Las implementaciones podrán seguir exponiendo eventos en vistas de traza y, cuando haga falta, un procesador a nivel SDK podrá convertir eventos basados en logs a span events para preservar expectativas de backends heredados o tableros ya desplegados.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos que operan plataformas de observabilidad, el impacto principal es de gobernanza técnica. En vez de documentar dos rutas para instrumentar excepciones y eventos, se consolida una sola convención para desarrollo nuevo. Esto mejora consistencia entre servicios, simplifica onboarding y reduce deuda en librerías internas.
En entornos cloud y multi-equipo, la unificación también facilita políticas de procesamiento: filtrado, enrriquecimiento, ruteo y retención pueden centrarse en pipelines de logs con correlación a trace/span context. En seguridad y respuesta a incidentes, disponer de eventos bajo el modelo de logs permite reglas más homogéneas para detección y auditoría, especialmente cuando ya existen motores SIEM o data lakes orientados a logs.
Para SRE, la transición obliga a validar vistas operativas: algunos equipos tienen runbooks construidos sobre eventos incrustados en spans. La buena noticia es que la deprecación viene con transición progresiva, no con corte abrupto. La mala noticia es que quien no planifique pruebas de compatibilidad puede descubrir diferencias de visualización en plena incidencia.
Detalles técnicos
El anuncio técnico describe cuatro puntos que los equipos deberían seguir de cerca:
- Logs API como ruta recomendada: OTLP para eventos basados en logs ya tiene base estable, y permite enviar nombre de evento, severidad, cuerpo y atributos con mayor flexibilidad para procesado posterior.
- Deprecación de APIs de span events: la especificación de tracing avanzará hacia deprecar
AddEventyRecordExceptioncomo patrón recomendado en instrumentación nueva. - Backcompat en SDK: el plan contempla procesadores que transformen eventos log-based en span events cuando se necesite conservar comportamiento histórico.
- Migración en semconv: para excepciones, el estándar propone adopción controlada con
OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN, permitiendo modoslogsologs/duppara rollout gradual.
En términos prácticos, esto no es solo un cambio de API: es un ajuste de contrato operativo entre instrumentaciones, collectors, backends y paneles. Si alguno de esos componentes asume que “evento” siempre llega embebido en span, habrá que revisar configuración y pruebas.
Qué deberían hacer los administradores o equipos técnicos
- Inventariar dependencias: identificar servicios, SDKs y auto-instrumentaciones que emiten
span eventsen forma intensiva (errores, retries, timeouts, hitos de negocio). - Probar dualidad antes de migrar: activar entornos de staging con emisión duplicada (
logs/dupcuando esté disponible) para comparar dashboards, alertas y queries. - Revisar pipelines de Collector y backend: confirmar que el procesamiento de logs preserve correlación con trace/span IDs y que los costos de ingesta estén controlados.
- Actualizar guías internas de instrumentación: para nuevos servicios, documentar Logs API como default y limitar nuevas dependencias en
AddEvent/RecordException. - Definir fecha de corte por dominios: migrar por producto o por plataforma reduce riesgo versus un cambio “big bang” en toda la organización.
- Alinear observabilidad y seguridad: aprovechar la convergencia a logs para unificar políticas de retención, masking y detección en telemetry pipelines compartidos.
Conclusión
La deprecación de Span Events en OpenTelemetry no es una ruptura, sino una consolidación. El ecosistema se mueve hacia un modelo más coherente para eventos, con menos ambigüedad para quienes instrumentan y más control para quienes operan plataformas observables a escala. Para equipos DevOps/SRE, la oportunidad está en convertir esta transición en una mejora de estándar interno: menos excepciones de implementación, más consistencia operativa y mejor capacidad de análisis cruzado entre señales.
Como en toda transición de observabilidad, el éxito no depende solo del estándar: depende de validar flujos reales, ajustar tableros y preparar runbooks antes de mover tráfico crítico.
Fuentes
- OpenTelemetry Blog: Deprecating Span Events API
- OTEP 4430: Span Event API deprecation plan
- OpenTelemetry Logs API Specification