Utilice Telemetry con OpenTelemetry
Telemetry y OpenTelemetry resuelven partes relacionadas pero diferentes de un sistema de observabilidad. OpenTelemetry proporciona API, SDK, convenciones semánticas y un recopilador de seguimientos, métricas y registros independientes del proveedor. Telemetry proporciona una ruta administrada para resultados de aplicaciones JSON, tablas escritas, DataFusion SQL, paneles y alertas especialmente diseñados.
Actualmente, Telemetry no proporciona un punto final de ingesta de OTLP y no debe describirse como un backend del recopilador OpenTelemetry. Utilice el Colector OpenTelemetry con un backend de observabilidad compatible con OTLP para seguimientos, métricas y registros. Emita un evento Telemetry independiente cuando la aplicación alcance un resultado comercial u operativo que se beneficie de SQL.
Dale a cada señal un trabajo
| señal | La mejor pregunta inicial |
|---|---|
| Métrica | ¿Está cambiando la salud agregada de los servicios o de la infraestructura? |
| traza | ¿Dónde pasó el tiempo con esta solicitud distribuida? |
| Registro de diagnóstico | ¿Qué detalle local explica esta ruta de código? |
| Evento Telemetry | ¿Qué resultado final afectó a un usuario, cuenta, flujo de trabajo o centro de costos? |
Un seguimiento de pago puede mostrar la extensión de la base de datos y del proveedor. Un evento checkout_completed puede contener el estado del terminal, el ID de cuenta segura, el plan, la categoría de monto, el recuento de reintentos, la liberación y la latencia requerida para el impacto en los ingresos de SQL. Ninguno necesita duplicar al otro.
Correlacionar con identificadores aprobados
Lea el contexto de intervalo activo OpenTelemetry en el límite de resultado de la aplicación:
import { trace } from "@opentelemetry/api";
const spanContext = trace.getActiveSpan()?.spanContext();
await telemetry.log("checkout_completed", {
checkout_id: checkoutId,
status: "success",
latency_ms: 684,
trace_id: spanContext?.traceId,
span_id: spanContext?.spanId,
checkout_version: "v2",
release: process.env.APP_RELEASE,
});
Trate los ID de seguimiento y extensión como campos de búsqueda, no como dimensiones de gráfico. Confirme que el sistema de seguimiento y Telemetry tengan límites de acceso y retención compatibles antes de hacer que la correlación entre sistemas forme parte de un flujo de trabajo de incidentes.
No copie eventos de extensión, atributos de recursos, equipaje, indicaciones, cuerpos de solicitud ni seguimientos de pila al por mayor. Utilice una lista de permitidos. El equipaje OpenTelemetry en particular puede propagarse a través de los límites del servicio y no debe asumirse como seguro para los análisis.
Operar las tuberías de forma independiente.
El recopilador OpenTelemetry puede procesar por lotes, reintentar, filtrar y exportar sus señales admitidas. El Telemetry SDK o Log API tiene su propio comportamiento de entrega. Monitoree ambas tuberías y evite acoplar sus modos de falla:
- una entrega fallida de un evento de resultado no debería poner fin a una solicitud que de otro modo sería exitosa
- una exportación de seguimiento fallida no debería activar el registro de eventos recursivo
- Los resultados críticos de auditoría o facturación deben utilizar una ruta de aplicación explícitamente duradera.
- Las decisiones de muestreo deben ser específicas de la señal.
- La verificación de la implementación debe confirmar tanto la correlación como la disponibilidad independiente.
El Especificación de registro OpenTelemetry explica la correlación entre el contexto de seguimiento y registro. Utilice Guía de integración OpenTelemetry, Registros, métricas, seguimientos y eventos y Eventos amplios canónicos para elegir el conjunto de señales confiable más pequeño.