Trazados distribuidos

Rastros distribuidos

1) ¿Por qué y qué es esto?

El rastreo distribuido es una forma de vincular las operaciones a lo largo de la ruta de la consulta: puerta de enlace API frontal → → microservicios → DB/caché → brokers → jobs/pipelines.
El resultado es un trace (trace) de span (span), donde cada span captura el trabajo de un componente con atributos, eventos y estado. Esto acelera el RCA, ayuda a mantener el SLO y reduce el MTTR.

• Visibilidad del camino crítico y «cuellos de botella».
• Correlación de síntomas (métricas) con causas (durmientes) y detalles (registros).
• Analítica de retraídas, colas, DLQ, fan outs, «sierra» de latencia.

2) Modelo de datos de seguimiento

Trace es un gráfico de llamadas con 'trace _ id'.
Span — операция: `name`, `kind` (SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL), `start/end`, `status`, `attributes`, `events`, `links[]`.
Attributes - clave-valor (route, db. system, messaging. system, cloud. región, etc.).
Eventos - etiquetas instantáneas dentro del espan (por ejemplo, 'retry', 'cache _ miss').
Span Links - conexiones fuera de «padre-hijo» (batchie, retraie, fan-in/out).
Resource - metadatos de proceso/servicio ('service. name ', versión, entorno).

3) Contexto y portabilidad

3. 1 W3C Trace Context

• 'traceparent': 'version-traceid-spanid-flags' (las banderas incluyen sampling).
• 'tracestate': estado específico para vendedores (al mínimo).
• Baggage son claves para el contexto empresarial (limitado, sin PII/secretos).

3. 2 Desplazamiento del contexto

HTTP: `traceparent`/`tracestate`; gRPC: metadatos; WebSocket: cuando se actualiza y en los mensajes;

Mensajes: en headers (Kafka/NATS/RabbitMQ): guardamos el contexto original de PRODUCER y lo transferimos a CONSUMER.
Bases: no «llevan» el contexto - lógicamos los atributos en span (query, rows, db. system), pero no los valores.

4) Sampling: cómo no arruinar

Head sampling (en la entrada): probabilístico/por reglas (route, tenant, endpoint).
Tail sampling (en el colector): mantenemos los tracks «interesantes» - errores, largos p95/p99, caminos raros.
Exemplars: métricas de histograma almacenan referencias a 'trace _ id' específicos.
Recomendación: combinar - head 5-20% + tail-reglas 100% para 5xx/timeout/p99.

5) Atributos y taxonomía (mínimo obligatorio)

• `service. name`, `service. version`, `deployment. environment`, `cloud. region`, `http. route`, `http. method`, `http. status_code`, `db. system`, `db. statement '(acortado/sin datos),' messaging. system`, `messaging. operation`, `peer. service`, `net. peer. name`, `tenant. id`, `request. id`.

Etiquetas de negocios: suavemente, sin PII. Ejemplo: 'order. segment`, `plan. tier`.

6) Escenarios asíncronos, colas y batches

PRODUCER → CONSUMER: creamos PRODUCTER span con contexto; en el mensaje - headers (traceparent, baggage). CONSUMER inicia SERVER/CONSUMER-span con link en PRODUCER (a menos que exista una jerarquía estricta).
Fan-out: una entrada - muchos outputs → los durmientes secundarios o enlaces.
Batch: CONSUMER lee un paquete de N mensajes → un mensaje con 'eventos' por cada messageId o 'links' en N contextos individuales.
DLQ: span 'messaging separado. dlq. publish` с reason и count.
Retray: 'evento: retry' + 'retry. count 'atributo; preferiblemente un nuevo CHILD-span para intentarlo.

7) Integración con logotipos y métricas

Los registros escribimos JSON con 'trace _ id '/' span _ id' → salimos de los registros con un clic.
Las métricas RED/USE contienen exemplars → de los picos p99 vamos a los durmientes «malos».
Las rutas generan señales técnicas (errores de dependencia) y señales de negocio (conversión) a través de eventos.

8) Rendimiento y costo

Sampling y trottling de eventos.
Reducción de la cardinalidad de los atributos (sin 'user _ id '/' session _ id' como etiqueta!).
Compresión/bateo por el exportador; los límites de los temporizadores de exportación.
Almacenamiento: caliente 1-7 días, encendido - agregados/solamente «problemáticos» de las carreras.
Categorías de gasto: colectores, índices, almacenamiento, egresos.

9) Seguridad y privacidad

In Transit: TLS 1. 3/mTLS kollektor↔agenty; At Nat: cifrado, claves nativas (consulte «Cifrado In Transit/At Nat»).
PII y secretos: no escribimos en atributos/eventos; tokenización/enmascaramiento en el productor.
Multiarrendamiento: 'tenant. id 'como recurso-etiqueta y aislamiento de espacios, políticas de lectura; auditar el acceso a las huellas (consulte «Auditoría y registros inmutables»).

10) Esquemas de implementación (referencia)

10. 1 OpenTelemetry SDK (pseudocódigo)

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10. 2 OTel Collector - muestra de tail (fragmento)

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10. 3 Kafka - transferencia de contexto (concepto)

PRODUCER: agregamos los titulares 'traceparent', 'baggage'.
CONSUMER: si un mensaje inicia un nuevo flujo, el nuevo SERVIDOR/CONSUMER-span desde el enlace al contexto desde los titulares.

11) Data/ETL и ML

Para pipelines batch: dormido en batch/partition con 'dataset. urn`, `run. id`, `rows. in/out`, `freshness. lag`.
Para ML: entrenamiento/infierno durmientes, versión del modelo, latency, feature store.
Ligamento con Lineage: 'run. id` и `dataset. urn 'permiten desde el trayecto ir al gráfico de origen de los datos.

12) Plataforma de rastreo SLO

Disponibilidad de ingestión: ≥ 99. 9%

Retraso antes de la indexación: ≤ 60 con p95

Cobertura de head-sample: ≥ 5-10% de rutas clave

100% de mantenimiento de tracks con estado ERROR y desde latency> umbral por directorio de «rutas críticas»

Alertas de la plataforma: el crecimiento de los drops, los timautas de las exportaciones, el trago del indexador, el sobrecalentamiento de la cardinalidad.

13) Pruebas y verificación

Contrato de rastreo en CI: la presencia de spans en endpoints clave, atributos obligatorios, 'traceparent' correcto vuela a través de gateway/proxy.
Muestras Synthetic/rum: recogen los tracks desde el exterior.
Chaos/incidentes: deshabilitar dependencias, comprobar que el sampler de tail «recoge» errores.
Smoke en venta: después de su lanzamiento - «si hay dormir» y exemplar → trais.

14) Hojas de cheques

Antes de la venta

• El W3C Trace Context está en todas partes; para los mensajes - headers.
• Se incluye el sampleo básico de cabeza; reglas de tail para 5xx/p99 configuradas.
• Atributos obligatorios: route, method, status, service. version, tenant. id.
• Registros JSON con 'trace _ id '/' span _ id', métricas con exemplares.
• Sanitarios PII; cifrado en tránsito/en reposo; directivas de acceso.
• Dashboards: «camino crítico», «errores de dependencia», «retraídas/timautas».

• Revisión mensual de la cardinalidad de los atributos; cupos.
• Sintonizando el tail-sampling por SLO (menos ruido, todo «caliente» está en la muestra).
• RCA de aprendizaje con transición métrica → exemplar → trace → logs.
• Validación de recubrimientos para colas, DLQ, ETL-jobs.

15) Runbook’и

RCA: crecimiento de p99 por/pay

1. Abrir RED-dashboard; de bin p99 ir por exemplar a trais.
2. Encuentra un «estrecho» CLIENT span (por ejemplo, 'gateway. call'), comprobar 'retry. count ', los timautas.
3. Comparar versiones de servicio/dependencia, región/zona.
4. Habilitar la degradación (caché respuesta/límite RPS), notificar a los propietarios de la dependencia.
5. Después de la fix - RCA y tickets de optimización.

DLQ ráfaga

1. Filtro de pistas por 'mensajería. dlq. publish`.
2. Comprobar las causas (eventos), correlacionar con la versión.
3. Iniciar reprocess, aumentar temporalmente el tiempo de espera de CONSUMER, notificar a los propietarios de downstream.

16) Errores frecuentes

No hay flujo de contexto a través de gateways/brokers. Solución: middleware/interseptores, bibliotecas únicas.
Todos los tracks son 100%. Caro y sin sentido - use tail-sampling.
Registros sin 'trace _ id'. Se pierde la correlación → MTTR ↑.
PII en atributos. Enmascarar/tokenizar; almacene sólo el contexto técnico.
Jobs de fondo «mudos». Agregue los durmientes a batch/partition y 'run. id`.
Un nombre común. Escriba el diccionario de nombres de spans y claves de atributos.

17) FAQ

P: ¿Es mejor un sampling de Head o tail?
R: Una combinación. Head proporciona una capa básica, tail garantiza la conservación de anomalías/errores.

P: ¿Cómo rastrear a través de Kafka sin una jerarquía rígida?
R: Utilice enlaces span entre PRODUCTER y CONSUMER; contexto - en los titulares.

P: ¿Qué hacer con los SQL sensibles?
O: 'db. statement 'acortado/normalizado (sin valores), o' db. operación '+ dimensiones/tiempo.

P: ¿Cómo asociar con métricas de negocio?
R: Agregue atributos de dominio sin PII (plan/segment), use eventos de «hitos de negocio» dentro del span y cambie de métricas de conversión por exemplar.

• «Observabilidad: registros, métricas, trazados»
• «Auditoría y registros inmutables»
• «Encriptación In Transit/At Nat»
• «Origen de los datos (Lineage)»
• «Privacy by Design (GDPR)»
• «Gestión de secretos»