Centralizar logs

1) Por que centralizar os logs

• acelera a busca das raízes dos incidentes (correlação de request-id/trace-id);
• constrói alertas de sinalização sobre os sintomas (erros, anomalias);
• dão uma pista de auditoria (quem/quando/o que fez);
• reduzem o custo com unificação de reticência e armazenamento.

2) Princípios básicos

1. Apenas logs estruturados (JSON/RFC5424) - nada de "free-text' sem chaves.
2. Um único esquema de chaves: 'ts, level, service, end, region, tenant, trace _ id, span _ id, request _ id, user _ id (masked), msg, kv...'.
3. Correlação padrão: coloque trace _ id de gateway para backends e logs.
4. Nível mínimo de ruído: níveis corretos, sempling, dedução de repetições.
5. Segurança by design: camuflagem PII, RBAC/ABAC, imutável.
6. Economia: hot/warm/cold, compactação, agregações, TTL e rehdration.

3) Arquiteturas típicas

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka — опц.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Pesquisa e agregação universal.
Loki-similares (logic-indexação por rótulos): Promtail/Fluent Bit → Loki → Grafana. Mais barato para grandes volumes, forte filtro label + visualização linear.
Nuvens: CloudWatch/Cloud Logging/Not Analytics + exportação para armazenamento frio (S3/GCS/ADLS) e/ou para SIEM.
Data Lake abordagem: shipper → armazenamento de objetos (parquet/iceberg) → consultas analíticas baratas (Athena/BigQuery/Spark) + camada online (OpenSearch/Loki) para os últimos dias N.

A recomendação é para manter a camada on-line (7-14 dias hot) e arquivo (meses/anos) em lake com a opção rehdrate.

4) Esquema e formato de logs (recomendação)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Padrões: RFC3339 para o tempo, level do conjunto 'TRACE/DEBUG/INFO/WARN/ERRO/FATAL', chaves no snake _ case.

5) Níveis de loging e sempling

O DEBUG é apenas em dave/estágio; em prod por bandeira e com TTL.
O INFO é um ciclo de vida de consultas/eventos.
WARN - Situações suspeitas sem impacto sobre o SLO.
ERROR/FATAL - Impacto na consulta/usuário.

• rate-limit para erros repetitivos (por exemplo, 1/segundo/chave).
• trechos tail-sempling (deixar os logs/trailers completos apenas para «maus» pedidos).
• dinâmico: Quando uma tempestade de erros reduz o detalhe, mantenha o resumo.

6) Entrega de logs (agentes e espinhos)

O site: Fluent Bit/Filebeat/Promtail coleta arquivos stdout/jornal, faz parsing, disfarce, tampão.
Filas de rede: Kafka/NATS para suavizar picos, retrações e ordenamento.
Confiabilidade: backpressure, tampões de disco, confirmação de entregas (at-least-once), índices idempotentes (chave-hash).
Filtragem na borda: «conversa» e segredos antes de entrar na rede.

7) Indexação e armazenamento

Partilha por tempo (daily/weekly) + por 'eng/region/tenant' (por meio de índice-mestre ou editoras).

• Hot (SSD, 3-14 dias): busca rápida e alertas.
• Warm (HDD/freezer, 30-90 dias): às vezes procuramos.
• Cold/Arquive (objetos, meses/anos): Complacência e raras investigações.
• Compactação e rotação: ILM/ISM (políticas de ciclo de vida), gzip/zstd, downsampling (tabelas de agregação).
• Rehdration: reposição temporária de partituras de arquivo para um cluster de investigação.

8) Pesquisa e análise: pesquisas típicas

Incidente: filtro de hora x 'service =...' x 'level> = ERRO' x 'trace _ id '/' request _ id'.
Provedores: 'código: PSP _' e 'kv. provider: psp-a 'com facção regional.
Anomalias: aumento da frequência de mensagens ou mudança de distribuição de campos (detectores ML, rule-based).
Auditoria: 'category: audit' + 'ator '/' resource' + resultado.

9) Correlação com métricas e traçados

Identificadores idênticos: 'trace _ id/span _ id' nos três sinais (métricas, logs, trailers).
Links de gráficos: transição clicando do painel p99 para os logs por 'trace _ id'.
Anotações de lançamento: versões/canários em métricas e logs de referência rápida.

10) Segurança, PII e complacência

Classificação de campos PII/segredos/finanças - disfarçar ou remover na entrada (Fluent Bit/Lua-filtros, Re2).
RBAC/ABAC: acesso a índices/editoras por papel, row-/field-level-security.
Imutável (WORM/append-only) para a auditoria e exigências dos reguladores.
Retenção e «direito de esquecimento»: TTL/remoção por chave, toquenização 'user _ id'.
Assinaturas/hachês: integridade de registros críticos (ação Admin, pagamentos).

11) SLO e métricas de logs de pipline

Entrega: 99. 9% dos eventos na camada hot ≤ 30-60 segundos.
Perdas: <0. 01% em 24h (rótulos de controle).
Disponibilidade de pesquisa: ≥ 99. 9% em 28 dias.
Latitude de solicitação: p95 ≤ 2-5 segundos em filtros típicos.
Custo: $/1M eventos e $/armazenamento/GB em corte de camadas.

12) Dashboards (mínimo)

Saúde Pipline: entrada/saída de shippers, retraí, preenchimento de buffers, liga Kafka.
Erros de serviços/códigos: top-N, tendências, percalços 'latency _ ms'.
Atividade de auditoria, acção, erros de provimento, acessibilidade.
Economia: volume/dia, índice-aumento, valor por camada, consultas «caras».

13) Operações e playbooks

Tempestade de logs: ativar o sempling agressivo/rate-limit no agente, levantar os tampões, transferir temporariamente parte do fluxo para warm.
À deriva do esquema: alert para novas chaves/tipos, iniciar a negociação de esquemas (schema-catalog).
Pesquisa lenta: cruzamento de índice, aumento de réplicas, análise de consultas pesadas, arquivamento de partituras antigas.
Incidente de segurança: ativação imediata da imutabilidade, descarga de artefatos, restrição de acesso a papéis, RCA.

14) FinOps: como não falhar nos logs

Retire a verbosidade, transforme os stacktrace de várias linhas no campo 'stack' e semeie as repetições.
Ative o TTL diferente para 'eng '/' level '/' category'.
Use Loki/arquivo + on-demand rehdrate para acessar raramente.
Partições e compactação: Grandes partições são mais baratas, mas acompanhe a pesquisa SLA.
Materialize relatórios analíticos frequentes (agregados diários).

15) Exemplos de ferramentas

Fluent Bit (disfarçar e enviar para OpenSearch)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Nginx access log в JSON с trace_id

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

OpenSearch Política ILM (hot→warm→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Folha de cheque de implementação

• Padrão de campos e níveis de logs adotados; a correlação trace/request-id está ativada.
• Agentes configurados (Fluent Bit/Promtail) com disfarces e buffers.
• Camada on-line selecionada (OpenSearch/Loki/Nuvem) e arquivo (S3/GCS + parket).
• Políticas de retenção ILM/ISM + hot/warm/cold, rehydrate-processo.
• RBAC/ABAC, imutável para a auditoria, registro de acesso.
• Dashboards de Pipline, alertas de perda/liga/tampões de disco.
• Playbooks: tempestade de logs, esquema à deriva, busca lenta, incidente de segurança.
• Limites financeiros: $/1M eventos, quotas para consultas «caras».

17) Anti-pattern

Logs de texto sem estrutura → a impossibilidade de filtrar e agregar.
Stacktrace gigante em INFO → explosão de volume.
Nenhuma correlação → «tremor» em todos os serviços.
Armazenar tudo para sempre, a conta da nuvem como um avião.
Segredos/PII nos logs → riscos complicados.
As edições manuais de índice de venda → à deriva e longos intervalos de busca.

18) Total

Centralizar os logs é um sistema, não apenas uma pilha. Esquema normalizado, correlação, espinhos seguros, armazenamento pós-suprimento e políticas de acesso rigorosas transformam os logs em uma ferramenta poderosa para SRE, segurança e produto. Reticências e FinOps corretas mantêm o orçamento, enquanto o SLO pipline e playbooks tornam as investigações rápidas e reproduíveis.