Distribución de señales y métricas

(Sección: Ecosistema y Red)

1) Objetivo y área

• Lenguaje único de telemetría y contratos de datos.
• Canales de QoS administrados: prioridad de las señales críticas.
• SLI/SLO transparentes y alerting predecible.
• Privacidad, aislamiento y ahorro de presupuesto métrico.

2) Taxonomía de señales

1. Eventos de negocios: onboarding, depósitos/pagos, eventos de juegos, atribución.
2. T-métricas: latency/throughput/código de error, cola, uso de CPU/RAM/IO.
3. Registros: registros estructurados de operaciones y errores.
4. Tracks: span de consultas/topics, correlación hop-to-hop.
5. Estados de salud: probes synthetic, readiness/liveness, nodos heartbeat.
6. Señales de riesgo/cumplimiento: KYC/KYB/AML hits, eventos sancionadores.

Cada clase tiene su propio nivel de criticidad y una política de retención/entrega.

3) Arquitectura de distribución (referencia)

Colectores edge (SDK/agents) → Ingress (HTTP/OTLP/gRPC/QUIC) → Bus (Kafka/Pulsar) → Procesadores (stream-jobs) → Almacenamiento (TSDB para métrica, objeto/columna - para registros/eventos, rastreador) → vitrinas/dashboards/alertas.
Multi-tenencia: namespace/tenant-id en claves, quota/limits/ACL separados.
Segmentación por QoS: crítica (P0), importante (P1), de fondo (P2).
Egress: suscriptores (Ops/BI/Third-party) a través de suscripciones a topics y vistas materializadas.

4) Contratos y esquemas (eventos/métricas/transacciones)

4. 1 Eventos (simplificado, YAML)

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4. 2 Métricas (OpenMetrics/OTLP)

Gauge/Counter/Histograma con etiquetas estables (cardinalidad limitada).
Identificadores: 'metric _ name {service, region, tenant, version, route}'.
Histogramas para latencia/dimensiones en lugar de p99 en el código.

4. 3 Tracks

Campos obligatorios: 'trace _ id', 'span _ id', 'parent _ id', 'service', 'peer', 'route', 'qos'.
Enlaces entre dominios (consumer/producer) y hops de red (relay/bridge).

5) QoS y priorización

P0 (crítico): pagos/pagos SLI, estados de puentes/nodos, burn-rate SLO → entrega estricta (acks, retries, idempotencia), timeout mínimo.
P1 (importante): eventos de productos/métricas básicas → entrega garantizada dentro de SLO.
P2 (fondo): los registros detallados, la depuración → el mejor efecto, se pueden perforar cuando se sobrecarga.

Políticas: diferentes colas, quota en los productores, backpressure, rate-limits, dedup por 'idempotency _ key'.

6) Cardinalidad y presupuesto de las métricas

Regla 6 etiquetas: no más de 6 claves por métrica, diccionarios de valores fijos.
Cardinalidad ≤ 10k series de tiempo/métrica/tenant.
Sampling: head-/tail-based para rastreos; downsampling métricas de 10s→1m→5m→1h.
Quotas: límites de puntos/segundos y bytes/segundos por tentante y por clase QoS.
Linter de esquemas: rechaza las métricas con etiquetas «en explosión» (id, email, ip, etc.).

7) Recogida y entrega: push vs pull

Push (OTLP/StatsD/HTTP): flexibilidad, clientes móviles/edge, canales P0.
Pull (Prometheus): infraestructura interna, objetivos predecibles.
Híbrido: exporters→gateway→TSDB; scrapes federados para las regiones.
Transporte: QUIC/HTTP/2, compresión, bateo, TLS/mTLS, retrés con jitter.

8) SLI/SLO y alerting

8. 1 SLI básicos

Availability% endpoints/gateways,

Latency p50/p95/p99 a través de rutas críticas,

Error-rate (5xx/timeout/abort),

Delivery lag bus, Queue depth,

escaparates Freshness (retardo de ingest→serve).

8. 2 Ejemplos de SLO

P0 pipelines: Availability ≥ 99. 95%, p99 latency ≤ 400 мс, Delivery lag p95 ≤ 2 с.
P1: Availability ≥ 99. 9%, Freshness p95 ≤ 3 min.
P2: Freshness p95 ≤ 15 мин, no-page.

8. 3 alertas Burn-rate (ejemplo)

Ventana de 2 horas: 'error _ budget _ burn ≥ 2 ×' → page.
Ventana de 6 horas: 'error _ budget _ burn ≥ 1 ×' → page/escalada.
Combinar con 'queue _ lag' y 'drop _ rate' P0.

9) Almacenamiento y retenciones

métricas TSDB: alta frecuencia - 7-14 días; unidades - 6-12 meses.
Eventos/registros: almacenamiento en caliente 7-30 días, frío (objeto) 6-24 meses.
Tracks: sampling 1-10%; guardar espanes «lentos/erróneos» (tail-based).
Políticas de eliminación/revisión para PII y consultas de los interesados.

10) Privacidad, seguridad y aislamiento

PII-minimización: tokenización/pseudonimización de campos, prohibición de identificadores «crudos» en métricas.
mTLS/la firma de eventos, pinning las claves de los productores.
ACL/ABAC sobre temas/servicios/tenantes, claves separadas para escribir/leer.
Tenant sandboxing: separación lógica/física, límites y rate-limit per tenant.
Audit trail: registros de acceso/cambios de configuración inmutables.

11) Flujos de procesamiento (stream jobs)

Enrich: normalización, geo/versión/clase de tráfico.
Aggregate: ventanas de 10s/1m/5m, histogramas, bocetos cuantiles.
Detalle: anomalías (EWMA/ESD), derivación de distribuciones, ráfagas de colas.
Route: fan-out en los escaparates/alerters/webhooks de los socios.
Guardia: «botón rojo» - throttling/kill-switch por fuente/tema.

12) Dashboards (diseños de referencia)

Ops Core (hora/tiempo real): p95 latency, error-rate, delivery lag, queue depth, success-rate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Tenant Usage: filas/segundos, bytes/sec, cardinality, top-labels.
Seguridad/Cumplimiento: estados mTLS, claves de caducidad, accesos, revisiones PII.
Business Lens: conversión/pagos/puentes SLI cerca de las métricas.

13) Ejemplos de configuraciones

Clases y límites de QoS (YAML)

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

Etiquetas métricas (política)

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

Alertas burn-rate

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14) Esquemas de datos y consultas

Registro de métricas (directorio)

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

Colas y

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

Cardinalidad por tentante

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15) Procesos y roles

Telemetry Owner - esquemas/políticas/cuotas, control de cardinalidad.
SRE/Ops - SLO, alertas, incidentes, escalas.
Seguridad/Cumplimiento: claves, accesos, PII, auditorías.
Product/BI - escaparates de KPI, análisis, A/B-métricas.
Tenants (partners) - integración correcta de SDK, cumplimiento de contratos.

16) Incidentes de Playbook

A. Explosión de cardinalidad

1. Auto-bloque productor/métricas, 2) cortar etiquetas «malas», 3) agregación retro, 4) post mortem y reglas linter.

B. Crecimiento de queue lag P0

1. Incluir prioridad, 2) ampliar lotes/consumidores, 3) reducir temporalmente el P2 sampling, 4) análisis de cuellos de botella.

C. Caída de los escaparates Freshness

1. Cambiar al conector de respaldo, 2) activar el modo de degradación («último finalizado»), 3) notificar a los propietarios de las fuentes.

D. Fuga de PII en las métricas

1. Bloqueo de flujo inmediato, 2) reducción en la capa caliente, 3) notificación DPO/Compliance, 4) actualización de cintas/SDK.

E. Errores totales 5xx/de las pistas

1. Page, 2) Saimpling Tail-based ↑ para errores, 3) Diagnóstico de Trais de Ruta Crítica, 4) Retroceso de Lanzamiento/Flag Ficha.

17) Lista de verificación de implementación

1. Aprobar contratos de eventos/métricas/tracks y una lista de etiquetas válidas.
2. Inicie clases QoS, topics/colas, quotas y métricas de presupuesto.
3. Configurar ingest (push/pull), TLS/mTLS, retraídas e idempotencia.
4. Habilitar directorios de métricas/eventos y linters de esquema.
5. Definir alertas y escalaciones SLI/SLO, burn-rate.
6. Construir dashboards Ops/Pipelines/Tenant/Security.
7. Ejecutar pruebas de telemetría chaos (pérdidas/jitter/spikes).
8. Revisa regularmente la cardinalidad, las retenciones y el costo de almacenamiento.

18) Glosario

QoS - clase de calidad/prioridad de envío.
Freshness - Retraso en la aparición de datos en el escaparate.
Burn-rate - tasa de gasto del presupuesto de errores con respecto a SLO.
Cardinalidad es el número de series únicas de métricas (combinaciones de etiquetas).
Muestra de tail-based: muestra de trazados «lentos/erróneos».
Idempotency key es la clave para deduplicar repeticiones de eventos.

En pocas palabras: la distribución de señales y métricas no es simplemente «recoger y mostrar gráficos», sino una disciplina de contratos, canales de QoS y presupuestos. Siguiendo este marco, el ecosistema obtiene una observabilidad predecible, resistente a las ráfagas, privada a los datos y útil para las soluciones tanto en el circuito operativo como en el empresarial.