Observabilidade: logs, métricas, traçáveis

Observabilidade: logs, métricas, traçáveis

1) Por que é necessário

• As métricas são unidades compactas para SLI/SLO e alertação de sintomas.
• Traçados - Cadeias de causa e efeito de solicitação (end-to-end).
• Logi - eventos detalhados para investigação e auditoria.

Objetivo: RCA rápido, alertas preventivos e confiabilidade controlada dentro do error budet.

2) Princípios da arquitetura

Contexto único: «trace _ id», «span _ id», «tenant _ id», «request _ id», «user _ agente», «cliente _ ip _ hash».
Padrões: (OTel) para SDK/agentes, formato JSON de logs (canônico, com esquema).
Sintomas> causas: alertim por sintomas personalizados (latência/erro), não por CPU.
Comunicação de sinais: da métrica → em spans (exemplars) → em logs específicos por 'trace _ id'.
Segurança e privacidade: camuflagem PII em logs, criptografia in transit/at rest, registros imutáveis para auditoria.
Multiplicidade: separação de espaços de nomes/chaves/políticas.

3) Taxonomia de sinais e circuitos

3. 1 Métricas

RED (Rate, Errors, Duration) para serviços e USE (Utilization, Saturation, Errors) para infraestrutura.
Типы: counter, gauge, histogram/summary. Para a latência, historograma com bucket 'ami fixo.
Exemplars: referência para 'trace _ id' nos bins quentes do histograma.

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 Traçados

Span = operação com 'name', 'start/end', 'atributes', 'events', 'status'.
W3C Trace Context para portabilidade.
Sampling: básico (head) + dinâmico (tail) + regras de «importância» (erros, p95 altos).

3. 3 Logs

Apenas um JSON estruturado; níveis: DEBUG/INFO/WARN/ERRO.
Os campos obrigatórios são: 'ts _ utc', 'level', 'mensagem', 'trace _ id', 'span _ id', 'tenant _ id', 'end', 'service', 'region', 'hosts',' labels\'.
Segredos, tokens, PAN, senhas. PII - apenas tocado/mascarado.

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) Coleta e transporte

Agentes/exportadores (daemonset/sidecar) → tampão no nó → pneu/ingeste (TLS/mTLS) → armazenamento de sinais.
Requisitos: back-pressure, retraí, dedução, limitação de radicalidade (labels!), proteção contra «jobs storms».

Métricas: pull (Prometheus-compatível) ou push por OTLP.
Traçados: OTLP/HTTP (gRPC), samplers tail no coletor.
Logi: coleta local (jornald/docker/stdout) → parser → normalizador.

5) Armazenamento e retenção (tiered)

Métricas: TSDB quente 7-30 dias (com downsample), unidades por mais tempo (90-365 dias).
Rastreamento: 1-7 dias cheio, depois agregados/spans serviços «importantes»; armazenar os índices por «service», «status», «erro».
Logi: índice quente 7-14 dias, quente 3-6 mes, arquivo até 1-7 anos (complacência). Auditoria - WORM.

Otimização de custos: downsampling, filtragem DEBUG em venda, quotas de editoras, sampling para trilhas.

6) SLI/SLO, alerting e serviço

SLI: disponibilidade (% de pedidos bem-sucedidos), latência (p95/p99), proporção de 5xx, frescura de dados, proporção de bem-sucedidos.
SLO: alvo em SLI (por exemplo, 99. 9% de sucesso ≤ 400 ms).
Error budget: 0. 1% de «direito a erro» → regras de fish/experimentos.

• `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`.
• Silos-alerts (CPU/Disk) - apenas como auxiliares, sem paging.

7) Correlação de sinais

A métrica «vermelha» é → clicada no excempar → específica 'trace _ id' «→» lento «span» → abrimos os logs pelo mesmo 'trace _ id'.
Correlação com lançamentos: atributos 'version', 'imagem _ sha', 'função _ flag'.
Para os dados/ETL: 'datpra _ urn', 'run _ id', ligação com lineage (consulte o artigo apropriado).

8) Semeadura e cardealidade

Métricas: Limitamos as editoras (sem 'user _ id', 'direction _ id'); quotas/validação de inscrição.
Traçados: Combinamos head-sample (na entrada) e tail-sample (no coletor) com as regras: «Tudo o que é 5xx, p99, erros é 100%».
Logi: níveis e drosselação; para erros repetitivos frequentes - eventos agregadores (chave 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) Segurança e privacidade

In Transit/At Rest: criptografia (TLS 1. 3, AEAD, KMS/HSM).
PII/segredos: saneamento antes de envio, toquenização, disfarce.
Acesso: ABAC/RBAC para leitura; separação de papéis de producers/readers/admins.
Auditoria: registro de acesso imutável a logs/pistas; exportar - de forma criptografada.
Multiplicidade: namespaces/tenant-labels com políticos; isolamento das chaves de encriptação.

10) Perfis de configuração (fatias)

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) Dados/ETL e streaming

SLI para dados: frescura (max lag), abrangência (rows vs exposição), qualidade (validadores/duplicados).
Alerts: janela de omissão, Conselheiro, DLQ de crescimento.
Correlação: 'run _ id', 'datpra _ urn', evento lineage; traçado para pipas (span por batch/partition).
Kafka/NATS: métricas produtor/consoante, liga/rejeição; traçados por headers (como 'traceparent').

12) Perfilação e eBPF (sinal adicional)

Caminhos quentes de baixo nível CPU/alloc/IO; perfis para o incidente.
A telemetria eBPF (atrasos de rede, DNS, chamadas de sistema) está vinculada a 'trace _ id '/PID.

13) Testes de observabilidade

Contrato de sinais: verificação da exportação de métricas/editoras/histogramas para CI.
Sintético protes: RUM/clientes simulados para SLI externos.
Chaos/Fire drills: desligamentos de dependências, degradação - ver como alertas e agentes de serviço reagem.
Smoke em venda: teste pós-deplom que os novos endpointos têm métricas e traçados.

14) Custo e controle de volume

Orçamentos por sinal/comando; O porta-bolas é «pé por sinal».
Cardinalidade sob orçamento (SLO de cardinality), limites para novas editoras.
Downsampling, reticências de classe de dados, arquivos «frios» e WORM para auditoria.

15) Operação e plataforma de observabilidade SLO

plataforma SLO: 99. 9% de ingestas bem sucedidas; atraso para índice de métricas ≤ 30 c, logs ≤ 2 min, pistas ≤ 1 min

Alertas de plataforma: ligueira, crescimento de drop, erro de assinatura/criptografia, abarrotamento de buffers.
DR./HA: Multiplicidade, replicação, cópias de segurança de configs/regras.

16) Folhas de cheque

• Por todo o lado está "trace _ id '/' span _ id '; Os logs JSON com o esquema.
• As métricas RED/USE com histogramas; exemplar → da pista.
• O tail-sampling está ativado; regras 5xx/p99 = 100%.
• Alertas de sintomas + runibuki; relógio silencioso/anti-flap.
• Agentes de saúde PII; criptografia at rest/in transit; WORM para auditoria.
• Reticências e orçamentos para volume/cardealidade.

• Visão mensal de alertas (ruído/precisão), sintonização de liminares.
• Relatório de erro budet e medidas adotadas (fichfreys, hardening).
• Verificar revestimentos de dashboards/logs/trilhos para caminhos críticos.
• Incidentes de treinamento e atualização de runbook's.

17) Runbook’и

RCA: crescimento de p99/pay

1. Abra o dashboard RED para 'checkout'.
2. Ir para o exemplar → pista lenta → identificar «span estreito» (por exemplo, 'gateway. call`).
3. Abra os logs por 'trace _ id' → veja os temporizadores/retrai.
4. Incluir a bandeira de reversão/limite de RPS, notificar os proprietários de dependência.
5. Após a estabilização - RCA, tíquetes para otimização, teste de reprodução.

1. SLI «frescor» vermelho → pista de jobs → failing passo.

2. Verificar a liga do corretor/DLQ, erros do conector.

3. Iniciar reprocess, notificar os consumidores (BI/produto) através do canal status.

18) Erros frequentes

Logs sem padrão e sem 'trace _ id'. As investigações demoram muito.
Alertas de infraestrutura em vez de sintomas. Paging vai para o leite.
A imensidão das métricas. Explosão de custos e instabilidade.
Todas as pistas são 100%. Não é necessário; Liguem a semilação inteligente.
PII/segredos nos logs. Inclua agentes sanitários e listas vermelhas.
Fici mudas. Novo código sem métricas/trilhos/logs.

19) FAQ

Em: É necessário guardar o texto cru dos logs?
Sim, mas com retenção e arquivos; Para alertas e SLO, há equipamentos suficientes. A auditoria está no WORM.

Em: O que escolher para as pistas - head ou tail sampling?
A: Combinar: head-propabilistic para revestimento básico + tail-rulas para erros e anomalias.

Em: Como associar métricas e técnicas personalizadas?
O: Através do «trace _ id» geral e das editoras de negócios («road», «tenant», «place») e através de eventos do produto (conversões) com correlação às pistas.

Como não se afogam em alertas?
Bata por sintomas, insira relógios silenciosos, dedução, agrupamento, priorização SLO e proprietário padrão para cada alert.

• «Auditar e Registos Imutáveis»
• Criptografia In Transit/At Rest
• «Gestão de segredos»
• Origem dos dados
• «Privacy by Design (GDPR)»
• «Garantia de entrega de webhooks»