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
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 completaLogs 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.
Tipos de logs
O Romeo gera diferentes tipos de logs, cada um com propósito e retenção específicos.
Categorias de logs
| Categoria | Propósito | Retenção | Acesso |
|---|---|---|---|
| Application | Eventos da aplicação (erros, warnings, info) | 30 dias | Dev + SRE |
| Access | Requisições HTTP (método, path, status, latência) | 90 dias | Dev + SRE |
| Database | Queries lentas, deadlocks, conexões | 14 dias | DBA + SRE |
| Security | Tentativas de acesso, bloqueios, anomalias | 1 ano | Security + DPO |
| Integration | Chamadas a APIs externas, webhooks | 30 dias | Dev |
| Background | Jobs assíncronos, filas, workers | 14 dias | Dev + SRE |
| Infrastructure | Kubernetes, load balancer, CDN | 7 dias | SRE |
Detalhamento por categoria
Eventos gerados pelo código da aplicação. Incluem erros com stack trace, warnings sobre condições inesperadas e info para fluxos importantes.
Cada requisição HTTP gera um registro: método, path, query params, status code, tempo de resposta, user-agent. IP é anonimizado após 24h.
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.
Estrutura dos logs
Todos os logs seguem formato estruturado (JSON), permitindo queries eficientes e correlação entre eventos.
Schema padrão
| Campo | Tipo | Descrição |
|---|---|---|
| timestamp | ISO 8601 | Momento do evento (UTC) |
| level | String | Severidade (debug, info, warn, error, fatal) |
| service | String | Nome do serviço que gerou o log |
| version | String | Versão do deploy |
| environment | String | prod, staging, dev |
| trace_id | String | ID para correlação distribuída |
| span_id | String | ID do span específico |
| request_id | UUID | ID único da requisição HTTP |
| tenant_id | UUID | Imobiliária (multi-tenancy) |
| user_id | UUID | null | Usuário autenticado (se houver) |
| message | String | Descrição do evento |
| context | Object | Dados adicionais específicos |
| error | Object | null | Stack 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íveisLogs NUNCA contêm dados sensíveis em plain text. CPF, cartão, senhas são sempre mascarados (últimos 4 dígitos) ou omitidos.
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ível | Quando usar | Alerta? |
|---|---|---|
| debug | Detalhes para desenvolvimento, desativado em prod | Não |
| info | Eventos normais do fluxo (início de job, request processado) | Não |
| warn | Situação inesperada mas recuperável (retry, fallback) | Não (agregado) |
| error | Falha que afeta uma operação (pagamento falhou, timeout) | Sim (imediato) |
| fatal | Falha que derruba o serviço (OOM, panic) | Sim (urgente) |
Critérios para alertas
Se mais de 1% das requisições geram erro em janela de 5 minutos, alerta é disparado para o time de plantão.
Mais de 100 erros por minuto (mesmo que < 1%) indica problema sistêmico e gera alerta.
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
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
Serviço emite log estruturado (JSON) para stdout
Fluent Bit captura logs dos containers (sidecar)
Logs são bufferizados em Kafka para absorver picos
Logstash enriquece, filtra e roteia logs
Elasticsearch indexa para busca em tempo real
Logs antigos vão para S3 (compactados, Parquet)
Infraestrutura
| Componente | Tecnologia | Capacidade |
|---|---|---|
| Coleta | Fluent Bit | ~100K logs/segundo |
| Buffer | Kafka | 7 dias de retenção, 3 réplicas |
| Processamento | Logstash | Cluster de 3 nodes |
| Indexação | Elasticsearch | 30 dias hot, 60 dias warm |
| Arquivo | S3 + Glacier | Ilimitado, lifecycle automático |
| Visualização | Kibana + Grafana | Dashboards 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.
Consulta e análise
O sistema oferece múltiplas interfaces para consultar logs, desde busca ad-hoc até dashboards pré-configurados.
Interfaces disponíveis
| Interface | Caso de uso | Acesso |
|---|---|---|
| Kibana | Busca ad-hoc, análise exploratória | Dev + SRE |
| Grafana Loki | Correlação com métricas | SRE |
| CLI (logcli) | Debug local, scripts | Dev |
| API (Elasticsearch) | Integrações, automações | Serviços |
| Alertmanager | Definição de alertas | SRE |
Queries comuns
CorrelaçãoO 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.
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:
| Requisito | Implementação |
|---|---|
| Data e hora (UTC) | Timestamp em ISO 8601 |
| Duração da sessão | Calculado via login/logout events |
| IP de origem | Registrado, anonimizado após 24h para análise |
| Identificação do usuário | user_id (UUID) |
| Retenção | 6 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:
Alertas automáticos identificam comportamento anômalo (múltiplas falhas de login, acesso a recursos não autorizados).
Logs identificam escopo do incidente: quais usuários, dados e sistemas foram afetados.
Reconstrução timeline completa: o que aconteceu, quando, como. Trace_id permite seguir toda a cadeia de eventos.
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.