Loki sem Kubernetes, escalando pra 400 servidores com OCI Object Storage

Por que single-node em vez de cluster #

Loki é comumente associado a deploy em Kubernetes, modo microserviços, múltiplos componentes distribuídos. Pra uma frota de até 400 servidores enviando log, isso é complexidade que não se paga — um único node rodando Loki + Grafana, com o armazenamento pesado (chunks e índices) delegado pro Object Storage da OCI, é suficiente e muito mais simples de operar.

enterprise-XXX (até 400x)        Servidor central
┌─────────────────────┐          ┌───────────────────────┐
│ PostgreSQL, API,     │          │  Loki 2.9 LTS  :3100  │
│ RabbitMQ, Redis,     │─Promtail▶│  Grafana 10.4  :3000  │
│ Webhooks             │          └──────────┬────────────┘
└─────────────────────┘                     ▼
                                  ┌────────────────────────┐
                                  │  OCI Object Storage     │
                                  │  (chunks + índices)     │
                                  └────────────────────────┘

O storage nunca fica no disco local do node #

Loki delega chunks e índices pro Object Storage da OCI (compatível com S3) em vez de disco local — o node central fica sem estado pesado, o que simplifica backup (o dado importante já está no object storage, durável por padrão) e permite trocar o node sem migração de volume.

Detalhe que trava quem configura pela primeira vez: o Object Storage da OCI não usa as credenciais de login do console — precisa gerar Customer Secret Keys especificamente (OCI Console → Perfil do Usuário → Customer Secret Keys), e a Secret Key só é exibida uma única vez no momento da criação. Confundir isso com a API key normal do OCI CLI é o erro mais comum na primeira tentativa de deploy.

Cliente enxuto: só Promtail #

Cada enterprise-XXX roda só o agente Promtail, coletando syslog e log de container Docker, mandando pro servidor central — sem duplicar componente pesado em cada host da frota. Requisito de rede mínimo: conectividade TCP na porta 3100 do servidor central, nada além disso.

Por que isso importa em escala #

Com 400 hosts potenciais enviando log, a decisão de arquitetura mais importante não é “qual motor de log usar” — é onde o dado pesado mora. Colocar no Object Storage desde o início evita o problema clássico de log centralizado: disco do servidor de logs enchendo mais rápido que qualquer plano de capacidade previu.

Tecnologias #

Loki 2.9 LTS · Grafana 10.4 LTS · Promtail · OCI Object Storage · Docker Compose