Entrevista general: ¿Cuándo deberían volverse estables las convenciones semánticas de OpenTelemetry?

Planteamiento y contexto

Usted mantiene un contrato de observabilidad entre lenguajes utilizado por SDKs, recolectores, tableros y alertas. El equipo desea pasar las convenciones de desarrollo a estable para que los usuarios downstream puedan depender de ellas; el equipo de plataforma teme significados no resueltos, escrituras duales y altos costos de cardinalidad. Asuma que se dispone de tres meses de telemetría real y dos servicios piloto.

Qué evalúa el entrevistador

El entrevistador está evaluando si usted explica "estable" como una promesa de compatibilidad en lugar de como la completitud de la documentación. Una respuesta sólida verifica nombres, tipos, unidades, niveles de requerimiento, enums y límites de privacidad; mide la adopción, la corrección de consultas, la cardinalidad y el costo de migración; y preserva una ruta de transición para cambios incompatibles.

Aclaraciones que conviene hacer primero

• ¿Qué alertas downstream, reportes de facturación o reportes de cumplimiento dependen ya de los campos? Más dependencias requieren un estándar de estabilidad más alto.
• ¿Qué señales y lenguajes están cubiertos? Los valores predeterminados deben coincidir en todos los SDKs.
• ¿Existen valores de alta cardinalidad, datos confidenciales o enums ambiguos? Resuelva esto antes de la estabilización.
• ¿Cuánto tiempo debe durar la compatibilidad? Los recolectores existentes pueden requerir selección de versión o migración voluntaria (opt-in).
• ¿El éxito se define por la adopción, las consultas reutilizables o una menor cantidad de campos personalizados? El objetivo cambia las métricas del piloto.

Estructura de respuesta de 30 segundos

"No promovería una convención solo porque tenga suficientes campos. Auditaría la semántica, los tipos, las unidades, los niveles de requerimiento, los enums, la privacidad y el comportamiento entre SDKs, y luego validaría las consultas downstream reales. La promovería únicamente después de que los servicios piloto utilicen la versión estable, se superen las pruebas de compatibilidad, la cardinalidad y el costo se mantengan dentro de los límites de control, y las rutas de migración y desuso (deprecation) sean explícitas. De lo contrario, la mantendría en desarrollo o alpha y registraría el siguiente hito de decisión."

Respuesta detallada paso a paso

1. Definir la promesa. Las convenciones de OpenTelemetry utilizan los niveles de desarrollo, alpha, beta, release candidate y estable. Estable significa que los usuarios downstream pueden confiar en las garantías de compatibilidad.
2. Auditar la semántica. Verifique la coherencia de nombres, tipos de valor, unidades, niveles de requerimiento, enums y ejemplos. Devuelva a discusión aquellos atributos con casos de uso que suenen útiles pero que no estén claros.
3. Validar el uso real. Tome una muestra de tres meses de datos y reproduzca tableros, alertas, correlaciones de logs y consultas entre lenguajes. Registre los valores faltantes y desconocidos.
4. Controlar el costo y la privacidad. Mida la cardinalidad, el almacenamiento y el costo de consulta derivados de los nuevos atributos. Nunca incluya identificadores de usuario, contenido sin procesar ni secretos en los atributos; utilice hashing o categorías controladas cuando sea apropiado.
5. Diseñar el versionado. Mantenga las convenciones experimentales en un espacio de nombres de desarrollo. Durante la estabilización, proporcione selección de versión o adopción voluntaria (opt-in), compare los resultados antiguos y nuevos durante la escritura dual y publique una fecha de desuso.
6. Establecer condiciones de control (gates) y reversión. Promueva solo después de que dos servicios piloto cumplan con las pruebas de compatibilidad, 99.9% de corrección en las consultas, una tasa de valores faltantes inferior al 1% y un crecimiento de cardinalidad por debajo del 20% durante dos ciclos de lanzamiento. Cualquier incumplimiento revierte a opt-in.

Las alternativas incluyen lanzar primero en beta, estabilizar solo un conjunto de atributos principales, versionar cada señal por separado o mapear campos antiguos en una transformación del recolector. La estabilización no debe ocultar problemas no resueltos de muestreo, autorización o calidad de datos.

Respuesta modelo

"Trato 'estable' como una promesa de compatibilidad del producto. Primero hago un inventario de alertas, reportes, recolectores y SDKs que dependen de la convención, luego audito nombres, tipos, unidades, niveles de requerimiento, enums y privacidad. Reproduzco consultas críticas contra tres meses de telemetría real y comparo valores faltantes, valores desconocidos, cardinalidad y costo en dos servicios en diferentes lenguajes. Requeriría 99.9% de corrección en las consultas, una tasa de valores faltantes inferior al 1%, un crecimiento de cardinalidad por debajo del 20% durante dos ciclos de lanzamiento, además de una fecha de desuso, un plan de escritura dual y una ruta de reversión antes de marcarla como estable. Si el significado aún se discute, la mantengo en desarrollo o beta y especifico la evidencia requerida para la próxima revisión."

Errores comunes

• Error: Usar la adopción o la cantidad de campos como prueba de estabilidad → Por qué falla: La estabilidad es una promesa de compatibilidad → Solución: Agregar pruebas entre SDKs, de consultas y de migración.
• Error: Incluir cada campo de negocio en la convención → Por qué falla: La cardinalidad y el riesgo de privacidad crecen rápidamente → Solución: Mantener solo atributos con casos de uso claros y costos delimitados.
• Error: Reemplazar los campos antiguos de inmediato → Por qué falla: Las consultas downstream pueden cambiar de significado silenciosamente → Solución: Proporcionar selección de versión, escritura dual, comparación y desuso programado.
• Error: Ignorar valores desconocidos y faltantes → Por qué falla: Los tableros parecen completos mientras que las conclusiones no son confiables → Solución: Convertir la calidad de los datos en un requisito de control de estabilización.

Preguntas de seguimiento y respuestas

¿Puede una convención estable mantener un campo principal renombrado?

Si el cambio de nombre altera la semántica de las consultas downstream, conserve el campo anterior, agregue una versión, publique un mapeo y establezca un periodo de desuso. Considere un alias de compatibilidad solo cuando se demuestre la equivalencia semántica y el costo de migración.

¿Cómo maneja los diferentes valores predeterminados de los SDKs?

Construya pruebas de contrato entre lenguajes con las mismas entradas y verifique nombres de campo, tipos, unidades y niveles de requerimiento. No amplíe el alcance estable mientras los valores predeterminados no coincidan.

¿Qué ocurre si la cardinalidad aumenta pero las consultas de negocio se vuelven más precisas?

Evalúe las mejoras de precisión junto con los límites máximos de almacenamiento, latencia de consulta y costos. Incorpore primero los servicios de alto valor y agregue muestreo, agregación o reducción de dimensionalidad.

¿Cuándo debería detenerse la estabilización?

Deténgase y regrese a desarrollo o beta cuando persistan disputas semánticas, la tasa de valores faltantes o la cardinalidad superen los límites de control, la revisión de privacidad falle o las consultas piloto no se puedan reproducir. Registre la brecha de evidencia.