Infraestrutura · Observabilidade
Infraestrutura · DevOps

Logs e Rastreabilidade

Sistema de logs do Romeo: eventos técnicos para debug, métricas operacionais, rastreabilidade para compliance e investigação de incidentes.

Versão
1.0
Atualizado
junho/2026
Volume
~50GB/dia
Status
operacional
1

Resumo

O sistema de logs do Romeo é a fundação da observabilidade. Captura eventos de todas as camadas da aplicação — desde requisições HTTP até operações de banco de dados — permitindo debug, monitoramento e investigação.

Diferente dos logs de auditoria (focados em ações de usuários), os logs de sistema capturam eventos técnicos: erros, performance, integrações, jobs assíncronos e comportamento da infraestrutura.

Observabilidade completa
Logs são apenas uma perna do tripé. Junto com métricas (Prometheus) e traces (OpenTelemetry), formam a base para entender o que acontece no sistema.
2

Tipos de logs

O Romeo gera diferentes tipos de logs, cada um com propósito e retenção específicos.

Categorias de logs

CategoriaPropósitoRetençãoAcesso
ApplicationEventos da aplicação (erros, warnings, info)30 diasDev + SRE
AccessRequisições HTTP (método, path, status, latência)90 diasDev + SRE
DatabaseQueries lentas, deadlocks, conexões14 diasDBA + SRE
SecurityTentativas de acesso, bloqueios, anomalias1 anoSecurity + DPO
IntegrationChamadas a APIs externas, webhooks30 diasDev
BackgroundJobs assíncronos, filas, workers14 diasDev + SRE
InfrastructureKubernetes, load balancer, CDN7 diasSRE

Detalhamento por categoria

Application logscore

Eventos gerados pelo código da aplicação. Incluem erros com stack trace, warnings sobre condições inesperadas e info para fluxos importantes.

Access logshttp

Cada requisição HTTP gera um registro: método, path, query params, status code, tempo de resposta, user-agent. IP é anonimizado após 24h.

Security logssensível

Eventos de segurança: logins falhos, rate limiting acionado, tokens inválidos, tentativas de SQL injection, anomalias de comportamento.

Separação física: Security logs ficam em bucket separado com acesso restrito. Apenas time de segurança e DPO podem consultar.

3

Estrutura dos logs

Todos os logs seguem formato estruturado (JSON), permitindo queries eficientes e correlação entre eventos.

Schema padrão

CampoTipoDescrição
timestampISO 8601Momento do evento (UTC)
levelStringSeveridade (debug, info, warn, error, fatal)
serviceStringNome do serviço que gerou o log
versionStringVersão do deploy
environmentStringprod, staging, dev
trace_idStringID para correlação distribuída
span_idStringID do span específico
request_idUUIDID único da requisição HTTP
tenant_idUUIDImobiliária (multi-tenancy)
user_idUUID | nullUsuário autenticado (se houver)
messageStringDescrição do evento
contextObjectDados adicionais específicos
errorObject | nullStack trace se for erro

Exemplo de log estruturado

{
  "timestamp": "2026-06-15T14:32:17.123Z",
  "level": "error",
  "service": "api-gateway",
  "version": "2.4.1",
  "environment": "prod",
  "trace_id": "abc123def456",
  "span_id": "span789",
  "request_id": "req-xyz",
  "tenant_id": "imob-abc",
  "user_id": "user-456",
  "message": "Failed to process payment",
  "context": {
    "payment_id": "pay-123",
    "amount": 1500.00,
    "gateway": "stripe"
  },
  "error": {
    "type": "PaymentGatewayError",
    "message": "Card declined",
    "code": "card_declined",
    "stack": "PaymentGatewayError: Card declined\n    at..."
  }
}
Dados sensíveis
Logs NUNCA contêm dados sensíveis em plain text. CPF, cartão, senhas são sempre mascarados (últimos 4 dígitos) ou omitidos.
4

Níveis e severidade

Os níveis de log seguem convenção padrão da indústria, com critérios claros para uso de cada um.

Definição dos níveis

NívelQuando usarAlerta?
debugDetalhes para desenvolvimento, desativado em prodNão
infoEventos normais do fluxo (início de job, request processado)Não
warnSituação inesperada mas recuperável (retry, fallback)Não (agregado)
errorFalha que afeta uma operação (pagamento falhou, timeout)Sim (imediato)
fatalFalha que derruba o serviço (OOM, panic)Sim (urgente)

Critérios para alertas

Error rate> 1%

Se mais de 1% das requisições geram erro em janela de 5 minutos, alerta é disparado para o time de plantão.

Error absoluto> 100/min

Mais de 100 erros por minuto (mesmo que < 1%) indica problema sistêmico e gera alerta.

Fatalqualquer

Qualquer log fatal gera alerta imediato com acionamento automático do time de plantão (PagerDuty).

Agregação de warnings

Warnings não geram alertas individuais, mas são agregados:

  • Relatório diário de warnings por categoria
  • Alerta se warning específico aumentar 5x vs. média da semana
  • Dashboard de tendências para identificar degradação gradual
5

Coleta e armazenamento

A arquitetura de logs do Romeo é projetada para alta disponibilidade, baixa latência de ingestão e custo otimizado de armazenamento.

Pipeline de logs

1
Aplicação

Serviço emite log estruturado (JSON) para stdout

2
Coletor

Fluent Bit captura logs dos containers (sidecar)

3
Buffer

Logs são bufferizados em Kafka para absorver picos

4
Processamento

Logstash enriquece, filtra e roteia logs

5
Indexação

Elasticsearch indexa para busca em tempo real

6
Arquivo

Logs antigos vão para S3 (compactados, Parquet)

Infraestrutura

ComponenteTecnologiaCapacidade
ColetaFluent Bit~100K logs/segundo
BufferKafka7 dias de retenção, 3 réplicas
ProcessamentoLogstashCluster de 3 nodes
IndexaçãoElasticsearch30 dias hot, 60 dias warm
ArquivoS3 + GlacierIlimitado, lifecycle automático
VisualizaçãoKibana + GrafanaDashboards pré-configurados

Custo otimizado: Logs em hot storage por 30 dias (~$2/GB), warm por 60 dias (~$0.50/GB), depois archive (~$0.01/GB). Volume médio: 50GB/dia = ~$3K/mês total.

6

Consulta e análise

O sistema oferece múltiplas interfaces para consultar logs, desde busca ad-hoc até dashboards pré-configurados.

Interfaces disponíveis

InterfaceCaso de usoAcesso
KibanaBusca ad-hoc, análise exploratóriaDev + SRE
Grafana LokiCorrelação com métricasSRE
CLI (logcli)Debug local, scriptsDev
API (Elasticsearch)Integrações, automaçõesServiços
AlertmanagerDefinição de alertasSRE

Queries comuns

Erros de um usuário específico
level:error AND user_id:"user-456"
Requisições lentas (> 2s)
service:api-gateway AND context.duration_ms:> 2000
Falhas de integração
service:integration-* AND level:error AND context.gateway:*
Trace completo de uma requisição
trace_id:"abc123def456" | sort timestamp asc
Correlação
O trace_id permite seguir uma requisição através de todos os serviços. Uma busca por trace_id retorna logs de API, workers, integrações — tudo.
7

Logs para compliance

Além do uso operacional, logs são fundamentais para atender requisitos regulatórios e investigações de incidentes.

Marco Civil da Internet

O Marco Civil (Lei 12.965/2014) exige guarda de registros de acesso à aplicação por 6 meses. O Romeo atende com:

RequisitoImplementação
Data e hora (UTC)Timestamp em ISO 8601
Duração da sessãoCalculado via login/logout events
IP de origemRegistrado, anonimizado após 24h para análise
Identificação do usuáriouser_id (UUID)
Retenção6 meses em hot/warm, depois archive por 5 anos

LGPD

Para atender requisitos da LGPD, os logs implementam:

  • Minimização: apenas dados necessários para a finalidade
  • Anonimização: IPs são anonimizados após 24h para análise agregada
  • Acesso restrito: apenas funções autorizadas podem consultar
  • Expurgo automático: logs são excluídos após período de retenção

Investigação de incidentes

Em caso de incidente de segurança, os logs permitem:

1Detecção

Alertas automáticos identificam comportamento anômalo (múltiplas falhas de login, acesso a recursos não autorizados).

2Contenção

Logs identificam escopo do incidente: quais usuários, dados e sistemas foram afetados.

3Análise

Reconstrução timeline completa: o que aconteceu, quando, como. Trace_id permite seguir toda a cadeia de eventos.

4Evidência

Logs são preservados com integridade (hash) para uso como evidência em processos legais se necessário.

Tempo de resposta: Incidentes de segurança devem ser investigados em até 72 horas (LGPD). Os logs permitem análise inicial em minutos.