Observabilidad: registros, métricas, trazados

Observabilidad: registros, métricas, trazados

1) Por qué es necesario

• Las métricas son unidades compactas para SLI/SLO y alerting por síntomas.
• Tracks - Cadenas de consulta causales (end-to-end).
• Registros - Eventos detallados para investigaciones y auditorías.

Objetivo: RCA rápido, alertas preventivas y fiabilidad administrada dentro del error budget.

2) Principios de arquitectura

Contexto único: en todas partes, vamos a 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash'.
Estándares: OpenTelemetry (OTel) para SDK/agentes, formato de registro JSON (canónico, con esquema).
Síntomas> causas: alertis por síntomas del usuario (latencia/errores) y no por CPU.
Comunicación de señales: de la métrica de → a los durmientes (exemplars) → a los registros específicos por 'trace _ id'.
Seguridad y privacidad: enmascaramiento PII en los logs, encriptación in transit/at nat, registros inmutables para auditoría.
Multiarrendamiento: separación de espacios de nombres/claves/políticas.

3) Taxonomía de señales y circuitos

3. 1 Métricas

RED (Rate, Errors, Duration) para servicios y USE (Utilization, Saturation, Errors) para infraestructura.
Типы: counter, gauge, histogram/summary. Para latencia, un histograma con bucket's fijos.
Exemplars: una referencia a 'trace _ id' en las barras de barras 'hot'.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Trazados

Span = operación con 'name', 'start/end',' attributes ',' events', 'status'.
W3C Trace Context para portabilidad.
Sampling: básico (head) + dinámico (tail) + reglas de «importancia» (errores, p95 alto).

3. 3 Registros

Sólo JSON estructurado; niveles: DEBUG/INFO/WARN/ERROR.
Campos obligatorios: 'ts _ utc', 'level', 'message', 'trace _ id', 'span _ id', 'tenant _ id', 'env', 'service', 'region', 'host', 'labels {}'.
Prohibido: secretos, tokens, PAN, contraseñas. PII: sólo tokenizado/enmascarado.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) Recogida y transporte

Agentes/exportadores (daemonset/sidecar) → un búfer en el nodo → bus/ingest (TLS/mTLS) → almacenamiento de señales.
Requisitos: back-pressure, retraídas, deduplicación, limitación de cardinalidad (¡labels!), protección contra "log storms'.

Métricas: pull (Prometheus-compatible) o push a través de OTLP.
Tracks: OTLP/HTTP (gRPC), samplers de tail en el selector.
Registros: colección local (journald/docker/stdout) → parser → normalizador.

5) Almacenamiento y retén (tiered)

Métricas: TSDB caliente 7-30 días (con downsample), agregados por más tiempo (90-365 días).
Tracks: 1-7 días llenos, luego agregados/durmientes de servicios «importantes»; almacenar índices por 'service', 'status', 'error'.
Registros: índice caliente 7-14 días, cálido 3-6 meses, archivo hasta 1-7 años (cumplimiento). Auditoría - WORM.

Optimización de costes: downsampling, filtrado DEBUG en venta, cuotas de etiquetas, sampling para pistas.

6) SLI/SLO, alerta y servicio

SLI: disponibilidad (% de solicitudes exitosas), latencia (p95/p99), fracción de 5xx, frescura de datos, fracción de job exitosos.
SLO: objetivo en SLI (por ejemplo, 99. 9% de éxito ≤ 400 ms).
Error budget: 0. El 1% de «derecho de error» → las reglas de fiecfrisis/experimentación.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silo-alertas (CPU/Disco) - sólo como auxiliar, sin paging.

7) Correlación de señales

La métrica es «roja» → haga clic en exemplar → «trace _ id» en particular → mire «lento» → abra los registros por el mismo «trace _ id».
Correlación con las versiones: atributos 'version', 'image _ sha', 'feature _ flag'.
Para datos/ETL: 'dataset _ urn',' run _ id ', relación con lineage (ver artículo correspondiente).

8) Semplado y cardenalidad

Métricas: limitamos las etiquetas (sin 'user _ id', 'session _ id'); cuotas/validación en el registro.
Tracks: Combine head-sample (en la entrada) y tail-sample (en el selector) con las reglas: «todo lo que 5xx, p99, errores - 100%».
Registros: niveles y aceleración; para errores frecuentes repetidos - eventos de agregación (clave dedupe).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Seguridad y privacidad

In Transit/At Nat: cifrado (TLS 1. 3, AEAD, KMS/HSM).
PII/secretos: saneadores antes del envío, tokenización, enmascaramiento.
Acceso: ABAC/RBAC para lectura; separación de roles producers/readers/admins.
Auditoría: registro de acceso a logs/rutas sin cambios; exportación - en forma cifrada.
Multiarrendamiento: namespaces/tenant-labels con políticas; aislamiento de claves de cifrado.

10) Perfiles de configuración (fragmentos)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Datos/ETL y streaming

SLI para los datos: frescura (max lag), plenitud (rows vs proyección), «calidad» (validadores/duplicados).
Alertas: pase de la ventana, corte del consumer, crecimiento del DLQ.
Correlación: 'run _ id', 'dataset _ urn', eventos lineage; tracks para paipelines (span en batch/partition).
Kafka/NATS: métricas de productor/consumidor, valor/rechazo; traceparent (en inglés: «traceparent»).

12) Perfilado y eBPF (señal dop)

Vías de acceso de bajo nivel CPU/alloc/IO; perfiles sobre el incidente.
telemetría eBPF (retardos de red, DNS, llamadas del sistema) con enlace a 'trace _ id '/PID.

13) Pruebas de observabilidad

Contrato de señales: verificación de la exportación de métricas/etiquetas/histogramas en CI.
Ensayos sintéticos: scripts RUM/clientes simulados para SLIs externos.
Chaos/Fire drills: apagar dependencias, degradar - ver cómo reaccionan las alertas y los oficiales de servicio.
Smoke en venta: comprobación post-deply de que los nuevos endpoints tienen métricas y trazados.

14) Costo y control de volúmenes

Presupuestos por señal/comando; dashboard «costa per signal».
Cardinalidad bajo presupuesto (SLO por cardinalidad), límites a las nuevas etiquetas.
Descarga, retenciones por clase de datos, archivos «fríos» y WORM para auditoría.

15) Operación y SLO de la plataforma de observación

Plataforma SLO: 99. 9% de los ingredientes exitosos; retraso al índice de métricas ≤ 30 s, registros ≤ 2 min, pistas ≤ 1 min.
Alertas de la plataforma: Magic Engest, crecimiento de drops, error de firma/encriptación, desbordamiento de búferes.
DR/HA: multizonalidad, replicación, backups de configuraciones/reglas.

16) Hojas de cheques

• 'trace _ id '/' span _ id' está en todas partes; Registros JSON con esquema.
• Métricas RED/USE con histogramas; exemplar → la pista.
• Tail-sampling está habilitado; reglas 5xx/p99 = 100%.
• Alertas por síntomas + rúnicas; reloj silencioso/anti-flap.
• Sanitarios PII; encriptación en el paso/en el paso; WORM para auditoría.
• Retenciones y presupuestos para volúmenes/cardinalidad.

• Revisión mensual de alertas (ruido/precisión), ajuste de umbrales.
• Informe sobre error budget y medidas adoptadas (fichfrisis, hardening).
• Comprobación de los recubrimientos de dashboards/logs/senderos para rutas críticas.
• Incidentes de entrenamiento y actualización de runbook's.

17) Runbook’и

RCA: crecimiento p99/pay

1. Abrir RED dashboard para 'checkout'.
2. Ir por exemplar → una pista lenta → revelar un «span estrecho» (por ejemplo, 'gateway. call`).
3. Abrir los registros por 'trace _ id' → ver los tiempos de espera/retratos.
4. Activar el indicador de reversión de fichas/límite de RPS, notificar a los propietarios de la dependencia.
5. Después de la estabilización - RCA, tickets de optimización, prueba de reproducción.

1. SLI «frescura» el → rojo de la pista de joba → el paso de falla.

2. Comprobar el valor del corredor/DLQ, errores del conector.

3. Iniciar reprocess, notificar a los consumidores (BI/producto) a través del canal de estado.

18) Errores frecuentes

Registros sin esquema y sin 'trace _ id'. Las investigaciones se retrasan a veces.
Alertas de infraestructura en lugar de síntomas. Paging se va «a la leche».
La cardinalidad ilimitada de las métricas. Explosión de costos e inestabilidad.
Todas las pistas son 100%. Caro y no necesario; Incluya sampling inteligente.
PII/secretos en los logs. Incluya los sanitarios y las «listas rojas».
«Mudos». Nuevo código sin métricas/rutas/registros.

19) FAQ

P: ¿Es necesario almacenar el texto crudo de los registros?
R: Sí, pero con retencia y archivos; hay suficientes unidades para alertas y SLO. Auditoría - en WORM.

P: ¿Qué elegir para las pistas - head o tail sampling?
R: Combinar: head-probabilistic para cobertura básica + tail-rules para errores y anomalías.

P: ¿Cómo vincular métricas personalizadas y técnicas?
R: A través del 'trace _ id' general y las etiquetas empresariales ('route', 'tenant', 'plan'), así como a través de eventos de producto (conversiones) con correlación a las pistas.

P: ¿Cómo no ahogarse en las alertas?
R: Bate por síntomas, introduce horas tranquilas, deduplicación, agrupación, priorización por SLO y propietario por defecto por cada alerta.

• «Auditoría y registros inmutables»
• «Encriptación In Transit/At Nat»
• «Gestión de secretos»
• «Origen de los datos (Lineage)»
• «Privacy by Design (GDPR)»
• "Garantías de entrega de webhooks'