Planteamiento y alcance
Una plataforma de microservicios multilingüe utiliza API de OpenTracing, shims de proveedores y SDK de OpenTelemetry. Desde marzo de 2026, la especificación de OpenTelemetry ya no requiere que las nuevas implementaciones proporcionen compatibilidad con OpenTracing, mientras que los shims existentes siguen siendo necesarios durante la transición. Diseña una migración que preserve las trazas, controle los costos y permita que un solo servicio pueda revertirse.
Qué evalúa el entrevistador
El entrevistador está evaluando si separas la compatibilidad a nivel de API, semántica de datos y protocolo de backend; si manejas el mapeo de atributos de trazas y spans, la propagación de contexto, la consistencia de muestreo, el costo de la escritura dual y el bloqueo de proveedor (vendor lock-in). Una respuesta sólida proporciona el orden de migración, métricas de aceptación y aislamiento de fallas en lugar de limitarse a reemplazar dependencias.
Preguntas para aclarar primero
- ¿Qué lenguajes y frameworks utilizan OpenTracing, y los shims han modificado su semántica?
- ¿El backend acepta OTLP, y deben permanecer estables los datos históricos y las dimensiones de consulta?
- ¿La prioridad es cero pérdidas, bajo overhead, semántica unificada o capacidad de reemplazo del proveedor?
- ¿Se permite la escritura dual temporal, y cuáles son los límites de muestreo y de costo por servicio?
Respuesta en 30 segundos
«Dividiría la migración en API, semántica, transporte y operaciones. Primero, congelaría las nuevas dependencias de OpenTracing e inventariaría shims, formatos de propagación y atributos clave. En un servicio, añadiría OpenTelemetry nativo mientras conservo el shim como punto de entrada de compatibilidad, comparándolos luego con un único contexto y decisión de muestreo. Una vez que la continuidad de trazas, tasa de errores, cobertura de atributos, latencia y costo cumplan los umbrales de aprobación, expandiría la migración por lenguaje y topología de dependencias. Ante una falla, se revierte la ruta de entrada o exportación de un único servicio, no la plataforma compartida de Collector».
Solución paso a paso
1. Inventariar llamadas y semántica
Crea un inventario de servicios, lenguajes, paquetes de OpenTracing, versiones de shims, formatos de propagación y rutas de exportación. Marca etiquetas personalizadas, registros (logs), baggage y nombres de spans, y luego mapea cada uno a atributos, eventos, enlaces (links) y baggage de OpenTelemetry. Comienza con servicios sin estado cuyas delimitaciones sean claras, no con el tracer más personalizado.
2. Definir el límite de compatibilidad
Mueve el código de la aplicación hacia tracers nativos de OpenTelemetry. Mantén un shim para las bibliotecas que aún no puedan modificarse, pero congela nuevas funcionalidades en los shims. La propagación del contexto debe mantenerse consistente en el ingreso (ingress), colas asíncronas, RPC y límites de procesamiento por lotes; nombres de API similares no garantizan un muestreo o relaciones de parentesco equivalentes.
3. Implementar escritura dual controlada
Prefiere el enrutamiento controlado en el límite de exportación del SDK o de Collector en lugar de generar dos conjuntos de spans en el código de negocio. Si se requiere escritura dual, establece topes de muestreo por servicio, límites de cola, reintentos y métricas de descarte, distinguiendo entre «span de negocio no creado» y «exportación fallida». Define una condición de salida explícita para la ventana de escritura dual.
4. Mantener la capacidad de consulta del backend
Congela los nombres de servicio, operación, estado y atributos críticos de negocio durante la migración. Envía el mismo conjunto de solicitudes a través de las rutas antigua y nueva, y compara el conteo de trazas, las relaciones padre-hijo, el estado de error, los percentiles de latencia y los ejemplares (exemplars). Si la semántica de consulta del backend cambia, proporciona un adaptador o dos versiones de tableros antes de cambiar la vista predeterminada.
5. Despliegue canary con límites de costo
Migra en lotes por lenguaje, equipo o árbol de dependencias. Rastrea la continuidad de trazas de extremo a extremo, la pérdida de spans, las colas de Collector, el uso de CPU y memoria, el egreso de red y el costo por millón de spans. Cuando se supere un umbral crítico, detén la incorporación de nuevos servicios preservando los servicios ya migrados y la evidencia sin procesar.
6. Revertir con controles de ciclo de vida
Mantén un interruptor de inicialización del tracer, la versión de dependencias y una instantánea de configuración para cada servicio. Revierte cambiando la ruta de entrada o exportación de ese servicio específico, en lugar de eliminar recursos compartidos de Collector. Antes de eliminar un shim, verifica que ninguna biblioteca aguas abajo obtenga aún contexto a través de un tracer global y conserva el monitoreo de compatibilidad durante una ventana definida.
Respuesta modelo
Congelaría el trabajo nuevo de compatibilidad con OpenTracing e inventariaría llamadas, semántica, propagación y exportaciones. Las API nativas de OpenTelemetry se incorporan servicio por servicio; las bibliotecas no modificables continúan a través de shims, con Context, muestreo y mapeo de atributos asegurados mediante pruebas de contrato. La escritura dual se limita en el límite del SDK o de exportación, con métricas de continuidad, cobertura de atributos, colas de Collector, latencia y costo. Se realiza despliegue canary por lenguaje y topología de dependencias. En caso de falla, se deshabilita la nueva ruta de un servicio y se restaura su exportación anterior conservando configuración, eventos y datos de comparación; los shims se eliminan solo después de que todos los servicios estén estables.
Errores comunes
- Solo reemplazar importaciones → la semántica de padres, baggage o atributos cambia → probar la propagación y los contratos semánticos.
- Escritura dual en cada llamada de negocio → el volumen de spans y los costos se disparan → centralizar y limitar el enrutamiento en el límite del SDK o de exportación.
- Monitorear solo el éxito de Collector → la aplicación ya perdió spans antes de llegar allí → separar las métricas de creación, encolado, exportación y backend.
- Migrar todos los servicios a la vez → el radio de impacto es demasiado grande → aplicar canary por lenguaje y topología de dependencias.
- Eliminar los shims de inmediato → una biblioteca no modificada falla al iniciar → congelar nuevas dependencias y verificar que las referencias hayan desaparecido.
Preguntas de seguimiento y respuestas
¿Por qué no exigir que todos los equipos cambien al mismo tiempo?
Las bibliotecas compartidas, los calendarios de lanzamiento y los SDK de cada lenguaje difieren, por lo que un corte sincronizado genera un radio de impacto masivo. La compatibilidad por capas mantiene los servicios en funcionamiento mientras las API nativas se convierten en el foco del nuevo desarrollo.
¿Cómo demuestras que no se perdieron trazas?
Inyecta un identificador estable en solicitudes repetibles, compara el ingreso, la propagación entre servicios, la recepción en Collector y los conteos de consultas en el backend; luego inspecciona mediante muestreo los enlaces padre, el estado y los atributos clave.
¿Puede la escritura dual alterar el muestreo?
Sí. Muestrear de forma independiente en dos tracers puede fragmentar una traza o duplicar los costos. Decide el muestreo en el contexto compartido y haz que ambas rutas hereden esa decisión.
¿Cuándo se puede eliminar la capa de compatibilidad?
Una vez que los análisis de dependencias no encuentren puntos de entrada de OpenTracing, las pruebas de contrato cubran la propagación y la semántica, las métricas canary cumplan con sus umbrales y no ocurra ninguna reversión durante la ventana de retención. Luego se retira el shim y se conserva un registro de auditoría.