Logs centralizados com Loki em VPS: quanto recurso?

Resposta direta

Uma VPS para logs centralizados com Loki costuma começar bem com 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe quando o volume é baixo, algo como 1 a 5 GB de logs por dia com retenção curta. Para produção com várias aplicações, Docker, Nginx, bancos e alertas no Grafana, o ponto mais seguro fica em 4 vCPUs, 8 GB de RAM e 160 a 320 GB de NVMe, sempre calculando retenção antes de contratar o disco. Loki não substitui Prometheus, ele complementa métricas com logs pesquisáveis. Prometheus mede séries temporais, Loki guarda eventos textuais. O desenho ideal junta Loki, Grafana, Promtail ou Grafana Alloy, regras de retenção, backups testados e limites de ingestão para evitar que uma aplicação verbosa derrube o servidor.

Resumo rápido

• Loki é indicado para centralizar logs de aplicações, containers, servidores Linux, Nginx, workers e jobs em um painel Grafana.
• Para uso inicial, pense em 2 vCPUs, 4 GB de RAM e 80 GB de disco rápido, desde que a retenção seja curta.
• Em produção pequena ou média, 4 vCPUs, 8 GB de RAM e 160 a 320 GB de NVMe dão mais folga para consultas e ingestão.
• Retenção é a variável que mais pesa no custo, pois 10 GB por dia durante 30 dias exigem planejamento de centenas de GB.
• Labels no Loki precisam ser controladas. Usar user_id, request_id ou IP como label pode explodir a cardinalidade.
• Prometheus monitora métricas como CPU, RAM e latência. Loki centraliza logs e ajuda a investigar erros e incidentes.
• Snapshots ajudam na recuperação rápida, mas não substituem backup externo nem política de retenção.

Quando faz sentido centralizar logs com Loki em uma VPS

Centralizar logs com Loki em uma VPS faz sentido quando você tem mais de um serviço gerando eventos e já percebe que entrar por SSH em cada máquina virou perda de tempo. Um cenário comum é uma aplicação Node.js ou Laravel em Docker, um Nginx na frente, um banco PostgreSQL separado e alguns workers processando filas. Quando um cliente reclama de erro 500, você precisa cruzar logs de aplicação, proxy reverso e job em background. Sem centralização, a investigação vira caça ao arquivo certo em /var/log, docker logs e painéis diferentes.

Loki foi criado para armazenar logs de forma mais econômica que soluções que indexam o texto inteiro de cada linha. A ideia é indexar labels, como app, env, host e container, e deixar o conteúdo do log comprimido para consulta. Isso reduz custo e consumo de recursos, mas exige disciplina no desenho dos labels. Se o time usa Grafana para dashboards, a integração fica natural, pois o mesmo painel pode mostrar logs, métricas e alertas.

O papel do Loki na observabilidade

Observabilidade não é apenas ver gráfico bonito. Em produção, você quer responder perguntas rápidas: qual deploy começou a gerar erro, qual endpoint está retornando 502, qual worker travou, qual host está emitindo logs de autenticação suspeitos. Loki entra nessa camada de investigação. Ele não precisa armazenar todos os logs para sempre. Muitas operações trabalham bem com 7, 14 ou 30 dias de retenção, desde que eventos críticos também sejam enviados para backup ou armazenamento apropriado.

Se você já está estudando métricas, o artigo sobre VPS para monitoramento com Grafana e Prometheus ajuda a separar as responsabilidades. Prometheus coleta números ao longo do tempo, enquanto Loki guarda linhas de log. Na prática, o alerta pode nascer em uma métrica, como aumento de taxa de erro, e a investigação acontece no Loki, filtrando {app="api", env="prod"} nos minutos em que o problema apareceu.

VPS, Cloud Server e instância cloud no mesmo projeto

Uma VPS tradicional pode atender bem um ambiente pequeno de logs, principalmente se você tem tráfego previsível e retenção curta. Um Cloud Server ou instância cloud costuma facilitar upgrades de CPU, RAM e disco, além de permitir snapshots e redes privadas dependendo do provedor. A diferença prática aparece quando o volume cresce. Se você sair de 2 GB para 20 GB de logs por dia, talvez precise aumentar disco e CPU sem migrar tudo às pressas. Nesse ponto, flexibilidade operacional pesa tanto quanto preço mensal.

Dimensionamento de CPU, RAM e NVMe para Loki

O dimensionamento de uma VPS para logs centralizados com Loki começa por uma pergunta simples: quantos logs entram por dia? Muita gente tenta escolher o plano pela quantidade de servidores, mas isso engana. Um único serviço em modo debug pode gerar mais volume que dez aplicações estáveis. Para estimar, rode por algumas horas comandos como du -sh /var/log/*, docker logs --since 1h nome_container | wc -c ou monitore o volume enviado pelo Promtail. Depois multiplique por 24 e acrescente margem de 30% a 50% para picos.

Para laboratório, homologação ou produto pequeno, 2 vCPUs e 4 GB de RAM costumam ser suficientes, com Loki, Grafana e Promtail rodando na mesma VPS. Use 80 GB de SSD ou NVMe se a retenção ficar entre 7 e 14 dias e o volume diário não passar de 3 a 5 GB. Em produção com várias aplicações, 4 vCPUs e 8 GB de RAM deixam consultas mais confortáveis, principalmente quando alguém abre o Grafana e pesquisa uma janela de 24 horas em vários serviços ao mesmo tempo.

Ingestão diária muda tudo

A ingestão influencia CPU, memória e disco. Loki recebe streams, escreve chunks, comprime dados e mantém índices. Se a ingestão é baixa, o gargalo raramente será CPU. Se há picos de milhares de linhas por segundo, a CPU passa a trabalhar mais na compressão e no processamento de queries. Um exemplo prático: uma API que gera 2 GB por dia pode rodar bem em 2 vCPUs. Uma plataforma multi-tenant que gera 30 GB por dia, com logs JSON detalhados, deve começar com 4 a 8 vCPUs e avaliar separação entre Loki, Grafana e agentes de coleta.

A RAM também precisa de margem. Grafana, Loki e consultas simultâneas consomem memória. Se o servidor tem 4 GB, evite rodar junto banco de dados de produção, runners de CI e outros serviços pesados. Swap pode evitar queda imediata, mas consultas em logs usando swap ficam lentas. Um ajuste comum é reservar a VPS de logs para observabilidade e deixar aplicações em outro servidor. Se você ainda está escolhendo recursos, o guia sobre como escolher CPU, RAM e NVMe ajuda a traduzir carga real em configuração.

Por que o disco rápido ajuda, mas não faz milagre

NVMe ajuda em escrita e leitura, especialmente durante compactação, consulta em janelas grandes e retenção com muitos chunks. Ainda assim, disco rápido não corrige cardinalidade ruim, retenção exagerada ou logs verbosos. Se cada requisição registra corpo completo, cabeçalhos, payload sensível e stack trace repetido, o problema é de engenharia de logs. Primeiro reduza ruído, depois compre mais disco. Em produção, prefira NVMe quando o orçamento permitir, mas valide por plano e localidade no provedor escolhido, pois storage e disponibilidade podem variar.

Retenção, compactação e custo de disco

Retenção é a decisão que mais muda o tamanho do servidor. Guardar 2 GB por dia durante 7 dias é um problema pequeno. Guardar 20 GB por dia durante 90 dias é outro desenho de infraestrutura. O Loki comprime logs, e a taxa real depende do conteúdo. Logs repetitivos de Nginx e mensagens estruturadas em JSON podem comprimir bem. Logs com payloads variados, IDs únicos e stack traces longos comprimem menos. Como regra conservadora, calcule primeiro sem confiar demais na compressão, depois ajuste com dados reais após uma semana de operação.

Uma fórmula simples ajuda: volume diário bruto multiplicado por dias de retenção, mais 30% de folga para índice, picos e operação. Se você gera 5 GB por dia e quer 14 dias, são 70 GB brutos. Com margem, pense em pelo menos 100 GB úteis. Se gera 10 GB por dia por 30 dias, já estamos falando de 300 GB brutos e algo como 400 GB planejados. Nesse caso, uma VPS com apenas 80 GB vai parecer barata no início, mas ficará apertada rapidamente.

Como calcular retenção sem chutar

Antes de definir retenção, separe logs por criticidade. Logs de aplicação em produção podem precisar de 14 a 30 dias. Logs de debug talvez devam ficar 24 ou 48 horas, ou nem entrar no Loki em produção. Logs de autenticação, auditoria e acesso administrativo podem exigir política própria, inclusive fora do Loki, dependendo de requisitos internos ou regulatórios. O erro clássico é tratar todo log como se tivesse o mesmo valor.

Um exemplo prático: uma SaaS pequena com API, painel web, worker e Nginx pode enviar 4 GB por dia. Ela pode manter 14 dias para env="prod", 7 dias para env="staging" e 2 dias para logs de debug, com filtros no agente de coleta. Essa decisão economiza disco sem prejudicar investigação. Em Loki, limites e retenção podem ser configurados no arquivo de configuração, usando blocos como limits_config e políticas de compactor quando o modo escolhido suporta retenção.

Políticas diferentes por ambiente

Ambiente de desenvolvimento não precisa guardar tudo. Staging costuma gerar logs úteis para depuração de deploy, mas raramente precisa de 30 dias. Produção merece mais cuidado, pois incidentes podem ser descobertos horas ou dias depois. Uma boa política começa com produção em 14 ou 30 dias, staging em 7 dias e desenvolvimento em 1 a 3 dias. Se algum cliente exige auditoria longa, não jogue essa responsabilidade apenas no Loki da VPS. Use exportação, armazenamento externo ou pipeline dedicado.

Também pense no que acontece quando o disco chega a 85% ou 90%. Configure alertas no Grafana ou no Prometheus para uso de disco, taxa de ingestão e erros do Loki. Sem alerta, o servidor de logs pode parar justamente durante um incidente, que é quando você mais precisa dele. A retenção deve ser uma escolha explícita, não o resultado acidental de um disco cheio.

Pipeline de coleta: Promtail, Alloy, Docker e syslog

O Loki sozinho não coleta logs. Você precisa de um agente ou pipeline para ler arquivos, containers ou syslog e enviar os dados. Promtail ainda aparece em muitos tutoriais e ambientes existentes, mas o Grafana Alloy vem ganhando espaço como agente unificado para logs, métricas e traces. Em servidores Linux simples, o agente lê /var/log/nginx/access.log, /var/log/auth.log e logs da aplicação. Em Docker, ele pode descobrir containers, aplicar labels e enviar cada stream ao Loki.

A arquitetura básica fica assim: aplicações escrevem logs em stdout ou arquivo, o agente coleta, adiciona labels controladas e envia para o endpoint HTTP do Loki, geralmente http://loki:3100/loki/api/v1/push em rede privada. O Grafana consulta o Loki como data source. Em uma VPS única, todos os componentes podem rodar via Docker Compose. Em produção mais séria, os agentes ficam nas máquinas de aplicação e o Loki central fica isolado, aceitando tráfego apenas de IPs autorizados.

Labels demais viram problema

O ponto mais delicado do Loki é cardinalidade. Labels são ótimas para filtrar, mas péssimas quando recebem valores infinitos. Use labels como app, env, host, service, container e level. Evite user_id, email, request_id, path completo com IDs, IP de cliente e qualquer campo com milhões de combinações. Esses dados podem ficar no corpo do log e ser pesquisados com filtros de texto quando necessário.

Exemplo de label saudável: {app="checkout", env="prod", level="error"}. Exemplo problemático: {app="checkout", user_id="839201", request_id="abc-123"}. No segundo caso, cada usuário ou requisição cria streams demais, aumentando índice, memória e lentidão. Se o time quer investigar por request ID, deixe o request ID no conteúdo do log e pesquise com |= "abc-123" no LogQL.

Exemplo prático de configuração

Um docker-compose.yml simples para laboratório pode ter três serviços: Loki, Grafana e Promtail ou Alloy. Loki expõe a porta 3100 apenas para a rede interna. Grafana expõe 3000 atrás de Nginx com HTTPS. Promtail monta /var/log como leitura e o socket Docker quando for necessário descobrir containers. Para começar, use limites conservadores, como retenção de 7 dias, ingestão controlada e logs em nível info ou warn.

Um trecho conceitual de labels no agente poderia mapear o nome do container para container, o ambiente para env="prod" e o nome do host para host. Não coloque segredos no arquivo. Tokens, senhas e chaves devem vir por variável de ambiente ou secret manager. Também revise a aplicação para não registrar Authorization headers, cookies, CPF, cartões ou payloads sensíveis. Centralizar logs aumenta poder de investigação, mas também concentra dados que precisam ser protegidos.

Alertas, consultas e diferença entre Loki e Prometheus

Loki e Prometheus trabalham muito bem juntos, mas não fazem a mesma coisa. Prometheus coleta métricas numéricas em intervalos, como uso de CPU, memória, taxa de requisições, latência p95 e quantidade de erros HTTP. Loki armazena eventos textuais, como stack traces, mensagens de aplicação, logs de acesso e falhas de autenticação. Se a CPU sobe para 95%, Prometheus mostra o gráfico e dispara o alerta. Loki ajuda a descobrir o que estava acontecendo no mesmo minuto.

Essa diferença evita duas armadilhas. A primeira é tentar usar logs como métrica principal para tudo. Dá para contar ocorrências no Loki com LogQL, mas métricas frequentes e críticas costumam ser melhores no Prometheus. A segunda é achar que Prometheus guarda contexto detalhado de erro. Ele pode mostrar que http_500_total subiu, mas não armazena a stack trace completa. O desenho maduro usa os dois.

Logs respondem perguntas diferentes de métricas

Pense em um deploy que começou às 14h05. Às 14h12, a taxa de erro 500 sobe. Prometheus mostra o aumento e alerta no Grafana. No Loki, você consulta {app="api", env="prod", level="error"} |= "payment" entre 14h00 e 14h20 e encontra stack traces ligados a uma variável de ambiente ausente. Esse fluxo reduz tempo de diagnóstico. Sem Loki, alguém teria que acessar servidores, procurar arquivos e torcer para o container ainda existir.

Consultas úteis no dia a dia incluem filtrar erros por serviço, contar ocorrências por intervalo, buscar mensagens específicas de deploy e comparar logs antes e depois de uma mudança. Em LogQL, expressões como count_over_time({app="api", env="prod"} |= "ERROR" [5m]) ajudam a transformar logs em sinais para alerta. Só não exagere. Alertas baseados em texto muito amplo podem gerar ruído e cansar o time.

Alertas úteis sem barulho

Bons alertas têm ação clara. “Erro apareceu no log” é amplo demais. Melhor: “mais de 20 erros 500 em 5 minutos no checkout em produção”. Outro alerta útil é aumento de falhas de login administrativo, por exemplo mais de 10 ocorrências de Failed password em 2 minutos para o mesmo host. Para infraestrutura, combine Loki com métricas de disco, CPU e memória. O servidor de logs precisa ser monitorado como qualquer outro serviço crítico.

Se você já tem Prometheus, configure alertas de saúde do Loki, latência de queries, uso de disco e erros de ingestão. Se ainda não tem, comece pelo básico no Grafana e evolua. Uma VPS pequena pode rodar tudo junto, mas em produção vale separar responsabilidades conforme o volume cresce. Logs centralizados são ótimos para investigar incidentes, mas métricas continuam sendo o melhor radar para perceber que algo saiu do normal.

Segurança, backup e recuperação do servidor de logs

Um servidor de logs centralizados concentra informações sensíveis sobre sua operação. Ele pode revelar rotas internas, nomes de serviços, IPs, erros de banco, usuários, e às vezes dados que nem deveriam ter sido registrados. Por isso, a VPS do Loki não deve ficar aberta na internet sem controle. A porta 3100 do Loki deve aceitar conexões apenas da rede privada, VPN ou IPs específicos dos agentes. O Grafana deve usar HTTPS, autenticação forte e, quando possível, 2FA ou integração com provedor de identidade.

No Linux, o básico inclui SSH com chave, bloqueio de login root por senha, firewall ativo, atualizações de segurança e usuários separados. Em Docker, evite containers privilegiados sem necessidade. Monte volumes com permissões restritas e não exponha o socket Docker ao que não precisa dele. Logs também devem passar por higiene na origem. Se a aplicação registra tokens, cookies ou dados pessoais, o problema não é o Loki, é a forma como o software escreve logs.

Firewall, TLS e acesso administrativo

Uma configuração segura comum usa Nginx ou Caddy na frente do Grafana, certificado TLS válido e Loki sem exposição pública. Agentes remotos podem enviar logs por VPN WireGuard, rede privada do provedor ou túnel autenticado. Se você precisa expor endpoint de ingestão, coloque autenticação, limite de IP e rate limit. Também registre quem acessa o Grafana, quais usuários têm permissão de administração e quais dashboards podem visualizar logs de produção.

Não coloque senhas do Grafana, tokens de API ou credenciais de banco em arquivos versionados. Use variáveis de ambiente, arquivos .env fora do Git ou secret manager. Parece básico, mas incidentes de observabilidade muitas vezes começam por descuido operacional. Um painel de logs é atraente para invasores porque resume o funcionamento interno do ambiente.

Snapshots não substituem retenção bem planejada

Snapshots são úteis para voltar o servidor a um ponto recente depois de atualização quebrada, erro de configuração ou corrupção de volume. Eles não substituem retenção, backup externo nem exportação de logs críticos. Se o disco encher e o Loki parar de ingerir dados, um snapshot antigo não recupera os logs que nunca foram gravados. Se você quer entender melhor esse papel, veja o conteúdo sobre VPS com snapshots para recuperação rápida, especialmente a diferença entre restauração operacional e proteção histórica.

Para produção, teste restauração. Não basta ativar backup e confiar. Suba uma cópia, verifique se o Loki inicia, se o Grafana reconhece o data source e se as consultas retornam dados. Também documente o procedimento: onde estão os volumes, qual versão do Loki, como recuperar o docker-compose.yml, como restaurar certificados e quais DNS precisam ser ajustados. Durante um incidente, documentação curta e atual vale mais que memória do time.

Comparativo de perfis para Loki em VPS

A tabela abaixo não é um comparativo de preço entre provedores. Ela serve para dimensionar perfis de uso. Valores de preço, regiões, armazenamento e disponibilidade de NVMe variam por empresa e plano, então precisam ser verificados nas páginas oficiais antes da contratação. Para workloads de logs, os fatores mais importantes são volume diário, retenção, velocidade do disco, facilidade de aumentar armazenamento e qualidade da rede entre servidores de aplicação e Loki.

Perfil de uso	Volume diário estimado	Configuração inicial sugerida	Retenção prática	Observações operacionais
Laboratório e dev solo	500 MB a 2 GB por dia	2 vCPUs, 4 GB RAM, 80 GB SSD ou NVMe	3 a 7 dias	Pode rodar Loki e Grafana juntos, com Docker Compose e poucos alertas
Produto pequeno em produção	2 a 8 GB por dia	4 vCPUs, 8 GB RAM, 160 GB NVMe	7 a 14 dias	Separar logs por app e ambiente, monitorar disco e limitar labels
Time com múltiplos serviços	8 a 25 GB por dia	4 a 8 vCPUs, 16 GB RAM, 320 GB ou mais em NVMe	14 a 30 dias	Avaliar rede privada, backup testado, dashboards por serviço e alertas no Grafana
Produção regulada ou auditoria	Acima de 25 GB por dia	Arquitetura dedicada, disco expansível e possível storage externo	30 dias ou mais	Loki pode ser parte da solução, mas logs críticos devem ter política própria

Alguns provedores conhecidos no mercado de cloud, como DigitalOcean, Vultr, Linode Akamai, AWS Lightsail e Hetzner, oferecem instâncias que podem rodar Loki, mas região, tipo de disco, tráfego incluso e expansão de volume variam. No Brasil, provedores com datacenter local ou opção de pagamento em reais podem reduzir latência administrativa e simplificar cobrança para empresas brasileiras. LetsCloud pode entrar nessa análise quando localidade, tipo de storage e recursos do plano forem confirmados no site oficial, sem assumir que NVMe, snapshots ou backup automático existem em todos os planos.

O ponto decisivo não é escolher o maior plano de cara. É medir ingestão, limitar ruído, acompanhar crescimento e reservar margem. Se a sua ingestão dobra a cada três meses, escolha uma plataforma em que aumentar disco não seja traumático. Se o time faz muitas consultas no horário comercial, RAM e CPU ganham peso. Se os agentes estão em outra região, latência e transferência de dados entram na conta.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo, freelancer ou maker rodando uma ou duas aplicações, a melhor estratégia é começar simples. Uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe dá conta de Loki, Grafana e agente local quando o volume fica abaixo de 2 GB por dia. Use retenção curta, algo entre 3 e 7 dias, e mantenha logs em nível info ou warn em produção. Evite registrar payload completo de requisições. O maior ganho aqui é praticidade: abrir o Grafana, filtrar por aplicação e encontrar erros sem entrar em cada container. Se o projeto crescer, você já terá histórico de ingestão para decidir o próximo upgrade com base em dados, não em chute.

Time pequeno

Um time pequeno com API, painel administrativo, workers, Nginx e banco separado deve tratar Loki como serviço interno de produção. Comece com 4 vCPUs, 8 GB de RAM e 160 GB de NVMe, mantendo 7 a 14 dias de retenção. Configure labels por app, env, host e level, além de dashboards por serviço. O time também deve criar alertas objetivos, como aumento de erros 500, falhas de login administrativo e queda de ingestão. Nesse perfil, a VPS de logs não deve hospedar tarefas paralelas pesadas. Ela precisa estar disponível durante incidentes, então firewall, backup testado e monitoramento do próprio Loki entram no pacote mínimo.

Produção com auditoria e crescimento

Para produção com auditoria, múltiplos clientes ou crescimento rápido, Loki em uma única VPS pode continuar funcionando, mas o desenho precisa ser mais cuidadoso. Considere 8 vCPUs, 16 GB de RAM e 320 GB ou mais de NVMe como ponto inicial para volumes acima de 10 GB por dia, validando com teste de carga e consultas reais. Separe ambientes, aplique retenções diferentes e defina quais logs precisam ser exportados para armazenamento externo ou solução específica de auditoria. Não dependa só de snapshots. Documente restauração, controle acesso ao Grafana e monitore cardinalidade. Se a operação exige retenção longa, alta disponibilidade ou compliance rígido, avalie arquitetura distribuída ou serviço gerenciado antes que a VPS vire gargalo.