Distribuição de sinais e métricas

(Secção: Ecossistema e Rede)

1) Alvo e área

• Uma única linguagem de telemetria e contratos de dados.
• Canais QoS controlados: prioridade de sinais críticos.
• SLI/SLO transparente e alerting previsível.
• Privacidade, isolamento e economia orçamentária de métricas.

2) Taxonomia de sinais

1. Eventos de negócios, fundos, depósitos/pagamentos, eventos de jogos, atribuições.
2. As métricas latency/throughput/código de erro, fila, uso de CPU/RAM/IO.
3. Logs: registros estruturados de operações e erros.
4. Traçados: spans de consulta/topic, correlação hop-to-hop.
5. Estados de saúde: sintético protes, readiness/liveness, heartbeat nós.
6. Sinais de risco/complacência: KYC/KYB/AML hits, eventos de sanção.

Cada classe tem um nível de criticidade e uma política de armazenamento/entrega.

3) Arquitetura de distribuição (arbitragem)

Edge coletores (SDK/Agentes) → Ingress (HTTP/OTLP/gRPC/QUIC) → Sheen (Kafka/Pulsar) → Processadores (stream-jobs) → Armazenamento (TSDB para métricas, objeto/invertebrado para logs/eventos, rastreador) → Vitrines/dashboards/alertas.
Multi-tenência: namespace/tenant-id em chaves, cota/limits/LCA.
Segmentação por QoS: crítica (P0), importante (P1), fundo (P2).
Egress: assinantes (Ops/BI/Third-party) através de subscrições para topics e materializações views.

4) Contratos e esquemas (eventos/métricas/trailers)

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/Historogram com editoras estáveis (cardealidade limitada).
Identificadores: 'metric _ name\service, region, tenant, version, road a.'.
Histogramas para latência/tamanho em vez de p99 no código.

4. 3 Trailers

Os campos obrigatórios são 'trace _ id', 'span _ id', 'parent _ id', 'service', 'peer', 'road', 'qos'.
Links entre domínios (consumer/producer) e hops de rede (relay/bridge).

5) QoS e priorizar

P0 (crítica): pagamentos/pagamentos de SLI, estatais de pontes/nós, burn-rate SLO → entrega rigorosa (acks, retries, idempotação), tempo mínimo.
P1 (importante): eventos alimentares/métricas básicas → entrega garantida dentro do SLO.
P2: logs detalhados, depuração → best-effort, podem ser puxados por sobrecarga.

Políticos: filas diferentes, cotas para produtores, backpressure, rate-limits, deadup por 'idempotency _ key'.

6) Cardinalidade e orçamento das métricas

Regra 6 editoras: no máximo 6 chaves por métrica, dicionários de valores fixos.
Cardinalidade ≤ 10k filas de tempo/métrica/tenante.
Semente: head-/tail-based para rastreamento; downsampling métricas de 10s→1m→5m→1h.
Cotas: limites de ponto/segundo e bytes/segundo por tentante e classe de QoS.
Linter de padrão: Desvia métricas com editoras «explosivas» (id, email, ip, etc.).

7) Coleta e entrega: push vs pull

Push (OTLP/StatsD/HTTP): flexibilidade, clientes móveis/edge, canais P0.
Pull (Prometheus): infraestrutura interna, metas previsíveis.
Híbrido: exporters→gateway→TSDB; federated scrapes para regiões.
Transporte: QUIC/HTTP/2, compressão, batidão, TLS/mTLS, retrai com jitter.

8) SLI/SLO e alerting

8. 1 SLI básico

Availability% endpoint/passarelas,

Latency p50/p95/p99 em rotas críticas,

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

Delivery lag por pneu, Queue depth,

Vitrines Freshness (atraso de ingest→serve).

8. 2 Exemplos 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 Burn-rate alerts (exemplo)

Janela de 2 horas: 'error _ budet _ burn ≥ 2 x' → page.
Janela de 6 horas: 'erro _ budet _ burn ≥ 1 x' → página/escalação.
Combinar com 'queue _ lag' e 'drop _ rate' P0.

9) Armazenamento e retenção

Métricas TSDB: alta frequência - 7-14 dias; As máquinas são 6-12 mes.
Eventos/logs: armazenamento quente 7-30 dias, frio (objeto) 6-24 mes.
Trailers: sampling 1-10%; salvar spans «lentos/errados» (tail-based).
Políticas de remoção/redação para PII e consultas de sujeitos de dados.

10) Privacidade, segurança e isolamento

Minimização PII: Tocinização/pseudonimização de campos, proibição de identificadores crus em métricas.
mTLS/assinaturas de eventos, pinning das chaves dos produtores.
ACL/ABAC para tópicos/serviços/tenentes, chaves individuais para write/read.
Tenant sandboxing: divisão lógica/física, limites e rate-limit per tenant.
Check trail: registros de acesso/alterações de configs imutáveis.

11) Fluxos de processamento (stream jobs)

Enrich: normalização, geo/versão/classe de tráfego.
Agregate: janelas 10s/1m/5m, histogramas, quântil esboços.
Detect: anomalias (EWMA/ESD), à deriva de distribuição, picos de fila.
Rota: fã-out em vitrines/alers/webhooks de parceiros.
Guard: «botão vermelho» - throttling/kill-switch por fonte/tema.

12) Dashboards (layouts)

Ops Core (hora/real tempo): p95 latency, erro-rate, delivery lag, queue depth, sucess-rate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Tenant Usage: filas/segundos, bytes/segundos, cardealidade, top-labels.
Security/Compliance: mTLS estatais, chaves de vencimento, acessíveis, edição PII.
Business Lens: conversão/pagamento/ponte SLI perto das métricas.

13) Exemplos de configuração

Classes de QoS e limites (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

Editoras 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

Alerts 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 dados e consultas

Maiúsculas (diretório)

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

Filas e jogos

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;

Cardinalidade por dentante

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) Processos e papéis

Telemetry Owner - esquemas/políticas/quotas, controle de radicalidade.
SRE/Ops - SLO, alertas, incidentes, escala.
Segurança/Compliance - chaves, acessíveis, PII, auditorias.
Produt/BI - vitrines KPI, analista, A/B-métricas.
Tenants (associados) - Integração correta do SDK, cumprimento de contratos.

16) Playbook incidentes

A. Explosão de cardealidade

1. Bloco automático produtor/métrica, 2) cortamos «más» editoras, 3) unidade retrô, 4) pós-mortem e regras linter.

B. Crescimento queue lag P0

1. Incluir prioridade, 2) ampliar partituras/consoantes, 3) reduzir temporariamente P2 sampling, 4) análise de estreitos.

C. Queda de vitrines Freshness

1. Mudar para conector de reserva, 2) ativar modo de degradação («últimos finalizados»), 3) notificar os donos das fontes.

D. Vazamento de PII em métricas

1. Bloqueio imediato de fluxo, 2) redação em camada quente, 3) notificação DPO/Compliance, 4) atualização de lenters/SDK.

E. Maciços 5xx/erros de rastreamento

1. Paige, 2) sampling tail-based ↑ para erros, 3) trace-diagnóstico da rota crítica, 4) relançamento do lançamento/flag-bandeira.

17) Folha de cheque de implementação

1. Aprovar contratos de eventos/métricas/trailers e lista de editoras válidas.
2. Ter aulas QoS, topics/filas, cotas e orçamento de métricas.
3. Ajustar ingest (push/pull), TLS/mTLS, retraí e idempotação.
4. Incluir diretórios de métricas/eventos e links de padrão.
5. Determinar SLI/SLO, burn-rate alert e escalação.
6. Construir dashboards Ops/Pipelines/Tenant/Security.
7. Execute testes de telemetria chaos (perda/jitter/spike).
8. Regularmente revalidar cardealidade, retenção e custo de armazenamento.

18) Glossário

QoS - classe de qualidade/prioridade de entrega.
Freshness - atraso na entrada dos dados na vitrine.
Burn-rate - velocidade de vazão do orçamento de erros em relação ao SLO.
Cardinality é o número de linhas exclusivas de métricas (combinações editoras).
Tail-based sampling é uma amostra de traços «lentos/errados».
Idempotency key é a chave para a dedução de repetições de eventos.

Resultado: a distribuição de sinais e métricas não é apenas «reunir e mostrar gráficos», mas uma disciplina de contratos, canais e orçamentos QoS. Seguindo este quadro, o ecossistema consegue uma observabilidade previsível, resistente a picos, privada a dados e útil para soluções, tanto no circuito operacional como no de negócios.