Pilha de observabilidade

1) Porquê uma pilha de observabilidade

RCA rápido e redução de MTTR de sintoma para causa em minutos.
Controle SLO: medição de erros/latência, alerting de orçamento errado.
Controle de lançamento: canários, auto-rollback por métricas.
Segurança e auditoria, pistas de acesso, anomalias, Legal Hold.
Transparência FinOps: custo de armazenamento/solicitação, custo-para-SLO.

Metodologias: Golden Signals (latency/traffic/errors/saturation), RED, USE.

2) Arquitetura básica da pilha

Componentes por camadas

Coletores/agentes: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-Protes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Armazenamento: S3/GCS/MinIO de objeto (frio prolongado), SSD (filas quentes).
Consulta/visualização: Grafana (painéis, SLO-widgets), Kibana (se ELK).
Gerenciamento: Alertmanager/Grafana Alerts, catálogo de serviços, RBAC, gerente de segredo.

Pattern de implantação

Managed (Grafana Cloud/Serviços de nuvem) - rápido e mais caro em volume.
Self-hosted em K8s - controle total, precisa de operação e FinOps.

3) Padrões de dados: um único «padrão de observabilidade»

3. 1 Métricas (Prometheus/OpenMetrics)

Editoras obrigatórias: «eng», «region», «cluster», «namespace», «service», «version», «tenant», «endpoint».
Nome: 'snake _ case', sufixos '_ total', '_ segunds', '_ bytes'.
Histogramas: fixos 'buckets' (SLO-orientados).
Cardinalidade: não incluir 'user _ id', 'request _ id' nas editoras.

3. 2 Logs

Formato: JSON; campos obrigatórios 'ts', 'level', 'service', 'eng', 'trace _ id', 'span _ id', 'msg'.
PII: camuflagem em um agente (PAN, tokens, e-mail, etc.).
Loki-editoras: Apenas baixa cardenalidade («app», «namespace», «level», «tenant»).

3. 3 Pistas

OTel semântica: 'service. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: caminho de destino p99 - 'always _ on '/tail-sampling, o resto é' parent/ratio '.
Incorporar ID: coloque 'trace _ id/span _ id' nos logs e métricas (labels/fields).

4) Correlação M-L-T (Metrics/Logs/Pistas)

O gráfico de alert (métrica) → logs filtrados por 'trace _ id' → uma pista específica.
Da pista (span lento), → a consulta de métricas de um backend específico no intervalo do span.
Os botões Drilldown nos painéis são «para os logs» e «para as pistas», substituindo variáveis («$ eng», «$ service», «$ trace _ id»).

5) OpenTelemetry Colector: pipline de referência

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Alerting: SLO e multi-burn

A ideia é que o alertim não é «CPU> 80%», mas sim no consumo da Errador Budet.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7) Dashboards: estrutura de pastas

00 _ Overview - plataforma SLO, p95, 5xx%, capacity, incidentes ativos.
10 _ Serviços - RPS, p95/p99, erros, lançamentos (anotações).
20 _ Infra - K8s/nodes/storage/rede, etcd, controladores.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40 _ Edge/DNS/CDN/WAF - ingress, LB, regras WAF.
50 _ Synthetic - botequim e guiões headless.
60_Cost/FinOps - armazenamento, solicitações, quente/frio, previsão.

Cada painel: descrição, unidades, proprietário, link runbook, drilldown.

8) Logs: LogQL workshop

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Pistas: TraceQL e fofocas

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Sintética e farmácia

Blackbox-expedter: HTTP/TCP/TLS/DNS-amostras de ≥3 regiões/ASN.
Headless: login/cenário deposit programado.
Quorum-alerts: activação se ≥2 regiões apresentarem rejeição.
Página de status: updates automáticos + comentários manuais.

11) Armazenamento e retenção

Métricas: mais quente de 7 a 30 dias (filas rápidas), downsampling/recording rulas, armazenamento frio de objetos (meses).
Logi: 3-7 dias quente, seguido por S3/GCS com índice (Loki chunk store/ELK ILM).
Pistas: 3 a 7 dias 'always _ on' + armazenamento longo para amostras (tail-sampled/reboque).

• Rollover em tamanho e tempo; orçamento para solicitações (quotas/limites).
• Políticas de prod/estágio e dados de segurança individuais.

12) Multi-tenência e acessibilidade

Divida por 'tenant '/' namespace '/Spaces, índice-pattern e resolução.
Selecione os recursos de billing «tenant», «service», «team».
Dashboards/alertas importados - em espaços de comandos específicos.

13) Segurança e complacência

TLS/mTLS de agentes a beckens, HMAC para health privados.
RBAC para leitura/gravação, auditoria de todas as solicitações e alertas.
Redação PII na borda; a proibição de segredos nos logs; DSAR/Legal Hold.
Isolamento: cluster/neymspace individuais para domínios sensíveis.

14) FinOps: custo de observabilidade

Reduzimos a radicalidade das editoras e a lógica no ingest (e não nas solicitações).
Caminhos de sampling + alvos always-on para caminhos críticos.
Downsampling/recording rulas para agregações pesadas.
Arquivamento de acesso raro a objeto frio.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD e testes de observabilidade

Linting métricas/logs em CI: proibição de «explosão» de radicalidade, verificação de histogramas/unidades.
Testes de observabilidade Contract: métricas/campos de logs obrigatórios, 'trace _ id' em middleware.
Canary: anotações de lançamento em gráficos, SLO-auto-rollback.

16) Exemplos: consultas rápidas

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

De logs para trilhas (Loki → Tempo): Passe 'trace _ id' como uma linha em Tempo UI/dashboard.

17) Qualidade da pilha: folha de cheque

• Esquemas de métricas/logs/trilhos e unidades de medição alinhados.
• 'trace _ id' em logs e métricas, drilldown de painéis.
• Alertas multi-burn SLO sem flapping (quorum/multi-window).
• Downsampling, quotas de consulta, limites de etapa/intervalo.
• As classes de retenção e armazenamento estão documentadas e aplicadas.
• RBAC/auditoria/edição PII incluídos.
• Dashbooks: proprietário, runbooks, ≤2 -3 tela, resposta rápida.
• FinOps-dashboard (volume, valor, top-board).

18) Plano de implementação (3 iterações)

1. MVP (2 semanas): Prometheus→Mimir, Loki, Tempo; OTel Collector; dashboards básicos e alertas SLO; blackbox-amostras.
2. Scale (3-4 semanas): tail-sampling, downsampling, multi-região ingest, RBAC/Spaces, FinOps-dashboard.
3. Pro (4 + semanas): auto-rollback por SLO, headless-sintético caminhos-chave, Legal Hold, portfólio SLO e relatórios.

19) Anti-pattern

«Gráficos bonitos sem SLO» - Nada de ação → nada útil.
Editoras de alta vitalidade ('user _ id', 'request _ id') - explosão de memória e custo.
Logs sem JSON e sem 'trace _ id' - não há correlação.
Alertas de recursos em vez de sintomas - ruído e queimar on-call.
A falta de uma política de retenção é um aumento descontrolado dos custos.

20) Mini-FAQ

O que escolher para Loki ou ELK?
ELK para pesquisa complexa/faceta; Loki é mais barato e rápido para este tipo de cenário grep. Muitas vezes usam híbrido.

Todos precisam de pistas?
Sim, pelo menos em vias-chave (login, checkout, payments) com tail-sampling - isso acelera drasticamente o RCA.

Como começar do zero?
OTel Colector → Mimir/Loki/Tempo → SLO básico e blackbox-amostras → depois dashboards e burn-alerts.

Resultado

A pilha de observabilidade não é um conjunto de ferramentas separadas, mas sim um sistema coerente: padrões de dados unificados → correlação M-L-T → SLO-alerting e sintético → segurança e FinOps. Fixe os circuitos, a disciplina de editoras e retensas, ligue o OTel, adicione o drilldown e auto-rollback - e você terá uma confiabilidade controlada com um custo compreensível.