Logs em um VPS: journald, Loki ou OpenSearch

O que o gerenciamento de logs self-hosted em um único VPS realmente custa

O gerenciamento de logs self-hosted em um único VPS (servidor privado virtual) resume-se a uma pergunta: você precisa de um cluster de pesquisa ou precisa de rotação e grep? A maioria dos guias de fornecedores começa com três nós e 12 GB de RAM antes que uma única linha de log seja enviada. Em um único servidor, essa resposta não é útil. Por isso, a comparação abaixo considera o que cada opção exige de uma máquina pequena antes de armazenar qualquer dado.

Se você executa um ou dois servidores e quer saber o que aconteceu na última terça-feira, systemd-journald e logrotate já fazem esse trabalho, e você pode parar depois da próxima seção. Se várias máquinas precisam enviar os logs para um único local, com pesquisa ao longo de várias semanas, o Grafana Loki é adequado para uma máquina pequena, porque indexa os rótulos, não o texto das linhas. Elasticsearch e OpenSearch oferecem pesquisa de texto completo de verdade, mas exigem isso da memória, porque o heap da JVM (máquina virtual Java) tem um limite mínimo que não pode ser reduzido.

Comece pelo journald, porque a maioria das pessoas para aqui

O systemd-journald já está em execução em qualquer servidor Ubuntu ou Debian atual. Ele captura a saída padrão de cada unidade de serviço, as mensagens do kernel e tudo o que é enviado para o syslog. Quatro comandos cobrem a maioria dos incidentes.

journalctl -u nginx.service --since "2026-08-14 09:00" --until "2026-08-14 10:00"
journalctl -p err -b
journalctl -f -u ssh.service
journalctl --disk-usage

O último comando imprime uma linha como Archived and active journals take up 1.1G in the file system.. Esse é o número que determina se precisa de mais alguma coisa. Se indicar algumas centenas de megabytes e conseguir encontrar o que precisa com -u e --since, o trabalho está concluído.

A persistência do journal após um reboot depende de Storage= e da existência de /var/log/journal. Com a configuração comum Storage=auto, o journald escreve em /var/log/journal quando esse diretório existe e em /run/log/journal quando não existe. /run é suportado por memória. Assim, num sistema sem esse diretório, todos os logs são apagados no reboot, precisamente quando pretende consultá-los. As imagens Ubuntu incluem o diretório. Imagens minimalistas e baseadas em contentores muitas vezes não o incluem.

ls -d /var/log/journal
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Depois do reinício, journalctl --disk-usage deve indicar um tamanho inferior a /var/log/journal, e não a /run. Os valores predefinidos já têm limites, que são a principal razão para o journald ser uma solução adequada, e não uma alternativa de recurso. A página man de journald.conf define SystemMaxUse= como 10% do tamanho do sistema de ficheiros e SystemKeepFree= como 15%, limitando cada valor predefinido calculado a 4G. SystemMaxFileSize= tem o valor predefinido de um oitavo de SystemMaxUse=, com limite de 128M, pelo que normalmente mantém sete ficheiros rotacionados. MaxRetentionSec= tem o valor predefinido de 0, o que desativa a eliminação baseada na idade. Leia novamente esse último valor predefinido: por defeito, o journal é limitado apenas pelo tamanho, nunca pela idade.

[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=30day

Escreva isso em /etc/systemd/journald.conf.d/99-size.conf, reinicie o journald e confirme que journalctl --disk-usage se aproximou do novo limite. Para libertar espaço agora, sem esperar pela próxima rotação, execute sudo journalctl --vacuum-size=500M ou sudo journalctl --vacuum-time=14d. Ambos mostram todos os ficheiros removidos, portanto uma execução sem saída significa que não havia nada para eliminar.

Tudo o que estiver fora do journal, como /var/log/nginx/access.log, é da responsabilidade do logrotate, que é executado diariamente por um temporizador systemd. Há uma falha que vale a pena conhecer porque parece um problema em df. Depois de uma rotação, o ficheiro antigo desaparece da listagem do diretório, mas o daemon continua a mantê-lo aberto. Por isso, df -h indica que o disco está cheio, enquanto du -sh /var/log indica um valor muito inferior. O espaço só fica novamente disponível quando o processo reabre o log. É para isso que serve a linha de reload postrotate na configuração. sudo lsof -nP +L1 lista os ficheiros eliminados que ainda estão abertos e identifica o processo que mantém cada um deles aberto. Teste uma regra sem alterar nada usando sudo logrotate -d /etc/logrotate.d/nginx.

Enviar logs de vários servidores para um único coletor

Quando existe mais de um servidor, gerir vários servidores Linux ao mesmo tempo fica mais simples quando os logs chegam a um único local. O rsyslog já está instalado na maioria das distribuições, por isso o coletor central mais simples consiste num ficheiro em cada servidor emissor.

*.* action(type="omfwd" target="logs.example.com" port="514" protocol="tcp")

Guarde esse conteúdo como /etc/rsyslog.d/50-forward.conf e valide-o com sudo rsyslogd -N1. Este comando valida a configuração e termina sem iniciar nada. Em seguida, reinicie o rsyslog. No coletor, ative a entrada TCP.

module(load="imtcp")
input(type="imtcp" port="514")

Existem dois avisos, ambos relacionados com a configuração. O syslog simples não fornece encriptação nem autenticação. Qualquer sistema que consiga alcançar a porta 514 pode injetar linhas de log com exatamente o mesmo aspeto das suas. Ligue o serviço a uma rede privada ou a uma VPN e aplique regras de firewall à porta. Em segundo lugar, a fila de ações predefinida fica na memória. Quando o coletor está inacessível, a fila enche e as mensagens são descartadas sem que seja mantida uma cópia. Para este caso, o rsyslog documenta uma fila assistida por disco no seu tutorial de encaminhamento fiável.

Por que a stack ELK não cabe num VPS pequeno

ELK significa Elasticsearch para armazenamento e pesquisa, Logstash para o pipeline de ingestão e Kibana para a interface. O limite mínimo é o heap da JVM, definido antes de qualquer log chegar.

A documentação da Elastic recomenda definir o heap como, no máximo, 50% da memória total disponível para cada nó do Elasticsearch, porque o processo também usa buffers fora do heap e depende da cache de ficheiros do sistema operativo para ler rapidamente os ficheiros de índice. Assim, um heap de 2 GB implica uma máquina com 4 GB, antes do Kibana e antes de considerar o serviço para o qual o servidor foi realmente adquirido. A Elastic também afirma que o Elasticsearch dimensiona automaticamente o heap com base nas funções do nó e na memória total. Isso significa que uma máquina pequena recebe um heap pequeno e passa a maior parte do tempo a executar coleta de lixo.

O Logstash é o componente que torna inviável um orçamento pequeno. A própria página da Elastic sobre as definições da JVM recomenda um heap de pelo menos 4GB e, no máximo, 8GB para uma ingestão típica. Isso corresponde à memória total de um VPS de 4 GB, para um único processo no meio do pipeline.

[
  {
    "label": "Loki plus Alloy (no JVM)",
    "documented_heap_mb": 0
  },
  {
    "label": "OpenSearch demo compose",
    "documented_heap_mb": 512
  },
  {
    "label": "OpenSearch production example",
    "documented_heap_mb": 2048
  },
  {
    "label": "Logstash recommended minimum",
    "documented_heap_mb": 4096
  }
]

Estes são os valores publicados por cada projeto na sua própria documentação. Não são medições feitas numa máquina de teste, e a sua carga de trabalho pode alterá-los. O ficheiro compose de exemplo do OpenSearch define 512 MB por nó para uma demonstração e 2048 MB no exemplo de produção, enquanto o limite inferior recomendado para o Logstash é 4096 MB. A coluna do heap mostra 0 para Loki e Alloy porque são programas Go sem heap da JVM a reservar. Essa é toda a diferença expressa num único número: um componente baseado na JVM reserva esse espaço independentemente de chegarem logs.

Se quiser usar a stack Elastic num único servidor pequeno, remova o Logstash e envie os dados diretamente para o Elasticsearch com um collector leve. O Logstash existe para analisar e transformar dados em grande volume. Num único servidor, pode fazer esse trabalho na origem ou ignorá-lo.

O Elasticsearch e o OpenSearch também precisam que vm.max_map_count seja aumentado para 262144, porque fazem memory mapping dos ficheiros de índice e o limite predefinido do Linux é demasiado baixo para esse funcionamento. Um contentor que termina alguns segundos depois do arranque numa máquina nova normalmente está a falhar por esse motivo.

OpenSearch ou Elasticsearch: qual deles pode ser implementado?

O breve histórico das licenças é importante porque determina o que pode executar. Em janeiro de 2021, a Elastic deixou de distribuir o Elasticsearch e o Kibana sob a Apache 2.0 e passou a usar um modelo duplo com SSPL (server side public license) e Elastic License 2.0. A AWS criou um fork do último código Apache 2.0, chamado OpenSearch, que continua sob Apache 2.0. Em setembro de 2024, a Elastic adicionou a AGPLv3 (GNU Affero General Public License version 3) como outra opção para o código-fonte gratuito. Para uma pessoa que faz self-hosting num único VPS, todas essas licenças permitem o que está a fazer. As restrições das licenças tornam-se relevantes quando oferece o software a outras pessoas como um serviço gerido.

A diferença prática num servidor pequeno é menor do que o histórico sugere, porque ambos usam o mesmo motor subjacente. Os nomes diferem: a gestão do ciclo de vida dos índices chama-se ISM (index state management) no OpenSearch e ILM (index lifecycle management) no Elasticsearch. Em agosto de 2026, o OpenSearch 2.12 e versões posteriores recusam iniciar sem que seja definida uma palavra-passe de administrador na primeira execução.

sudo sysctl -w vm.max_map_count=262144
printf 'vm.max_map_count = 262144\n' | sudo tee /etc/sysctl.d/99-opensearch.conf
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" \
  -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" \
  opensearchproject/opensearch:latest

A linha sysctl -w aplica a configuração imediatamente, e o ficheiro em /etc/sysctl.d/ é a parte que permanece após um reboot. Confirme que o contentor iniciou com curl -k -u admin:<password> https://localhost:9200. Ele responde por https usando um certificado de demonstração; por isso, -k ignora a verificação. Uma resposta saudável é um pequeno bloco JSON que identifica o cluster e a versão. A página de instalação do OpenSearch também indica aos utilizadores do Docker Desktop que devem permitir pelo menos 4 GB de memória no host. Isto é um indicador razoável dos recursos esperados pelo processo.

Como o Loki se mantém pequeno: labels em vez de um índice de texto completo

O Loki mantém um índice sobre labels e armazena as linhas de log como chunks comprimidos. Uma consulta seleciona primeiro os streams e filtra o texto depois. {unit="ssh.service"} |= "Failed password" seleciona o stream pela sua label e, em seguida, procura a string nesses chunks. O conteúdo das linhas não é indexado, por isso a ingestão permanece barata e não há um índice invertido para manter na memória. O custo passa para o momento da consulta. Esta é uma boa troca quando normalmente já sabe que serviço está a analisar.

A documentação do Grafana indica o modo monolítico, ou seja, todo o Loki num único processo com -target=all, para volumes pequenos de leitura e escrita de até aproximadamente 20GB por dia. Um VPS fica bem dentro desse limite.

O risco está na cardinalidade das labels. Cada combinação distinta de valores de labels corresponde a um stream, e a quantidade de streams determina o consumo de memória e o tamanho do índice do Loki. Uma label que contenha um endereço IP de cliente ou um identificador de pedido cria um stream para cada valor. Assim, um servidor web movimentado pode produzir dezenas de milhares de streams num dia, fazendo o processo crescer até o kernel o terminar. Limite as labels a valores que conseguiria contar no papel: unit, host, job, level. Coloque os detalhes variáveis na própria linha, onde uma expressão de filtro os encontra no momento da consulta.

Instalar Loki e Alloy numa única VPS

Dois processos executam o trabalho. O Loki armazena os logs e responde às consultas. O Grafana Alloy lê os logs e envia-os. O Promtail era usado para enviar os logs, mas chegou ao fim de vida em 2 March 2026. Por isso, as novas instalações usam o Alloy, e o exemplo Docker do próprio Loki agora inclui uma configuração do Alloy.

wget https://raw.githubusercontent.com/grafana/loki/v3.7.0/cmd/loki/loki-local-config.yaml -O loki-config.yaml

Leia esse ficheiro antes de o utilizar. Ele define path_prefix: /tmp/loki com chunks em /tmp/loki/chunks, o que é correto para uma demonstração, mas incorreto para um servidor: nada dentro de /tmp do container sobrevive à recriação do container, por isso o histórico desaparece na atualização seguinte da imagem. Aponte-o para um caminho que seja montado.

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

docker volume create loki-data
docker run --name loki -d \
  -v $(pwd):/mnt/config -v loki-data:/loki \
  -p 127.0.0.1:3100:3100 \
  grafana/loki:3.7.0 -config.file=/mnt/config/loki-config.yaml
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3100/ready

Esse último comando deve apresentar 200, porque /ready devolve HTTP 200 quando o Loki está pronto para aceitar tráfego. Qualquer outro resultado significa que o processo ainda está a iniciar ou que a configuração foi rejeitada. docker logs loki indica o motivo. Há dois detalhes deliberados no comando de execução. A porta é publicada apenas em 127.0.0.1, porque a configuração de exemplo inclui auth_enabled: false e o Loki não fornece autenticação de utilizadores própria. Assim, qualquer origem com acesso à porta 3100 pode ler todos os logs e escrever logs falsos. Mantenha-o em loopback, atrás de uma VPN ou atrás de um reverse proxy com autenticação. O volume nomeado é importante porque a imagem é executada pelo utilizador loki com UID 10001. Por isso, um diretório do host montado por bind e pertencente a root não pode ser escrito pelo container.

sudo apt-get update && sudo apt-get install -y gpg wget
sudo mkdir -p /etc/apt/keyrings/
sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y alloy

O Alloy lê /etc/alloy/config.alloy. Esta configuração recolhe o system journal e um conjunto de ficheiros, e envia ambos para o Loki local.

loki.write "local" {
  endpoint {
    url = "http://127.0.0.1:3100/loki/api/v1/push"
  }
}

loki.relabel "journal" {
  forward_to = []
  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }
}

loki.source.journal "read" {
  forward_to    = [loki.write.local.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = {job = "systemd-journal", host = "app-01"}
}

local.file_match "nginx" {
  path_targets = [{"__path__" = "/var/log/nginx/*.log", "job" = "nginx", "host" = "app-01"}]
}

loki.source.file "nginx" {
  targets    = local.file_match.nginx.targets
  forward_to = [loki.write.local.receiver]
}

A regra de relabel copia o campo __journal__systemd_unit do journal para um label chamado unit. É isso que permite usar {unit="ssh.service"} mais tarde. Sem essa regra, o nome da unidade fica dentro da entrada e não num label. Assim, não pode selecioná-lo, e cada consulta tem de analisar tudo.

sudo systemctl reload alloy
systemctl show -p User alloy
sudo journalctl -n 5
sudo -u alloy journalctl -n 5

É aqui que a maioria das configurações fica bloqueada. O Alloy é executado pela sua própria conta de serviço, não por root. A leitura do system journal exige que essa conta pertença ao grupo systemd-journal. Já os ficheiros em /var/log/nginx pertencem ao grupo adm no Debian e no Ubuntu. Substitua a conta apresentada por systemctl show no último comando. Se este devolver muito menos entradas do que a execução como root, essa conta não consegue ler o system journal. Nesse caso, o Loki permanece vazio, por mais correta que esteja a configuração. Adicione os grupos e reinicie com sudo usermod -aG systemd-journal,adm alloy seguido de sudo systemctl restart alloy.

curl -G -s "http://127.0.0.1:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job="systemd-journal"}' \
  --data-urlencode 'limit=5' | jq '.data.result | length'

Um número superior a 0 significa que existem streams com esse label e que eles contêm entradas. 0 significa que ainda não chegou nada com esse label. Uma predefinição explica um alerta falso comum: loki.source.journal define max_age como 7h. Por isso, um arranque novo lê as últimas sete horas do journal e nada mais antigo. Para uma interface gráfica, execute o Grafana no mesmo servidor e aponte uma fonte de dados Loki para http://127.0.0.1:3100.. Os logs de containers exigem outra fonte: o Alloy descobre os containers Docker em execução e lê os respetivos logs. É isso que o exemplo de introdução do próprio Loki faz. Num cluster k3s de nó único numa VPS, esse trabalho passa para o diretório de logs dos pods onde o kubelet escreve.

Retenção: escolha o dia em que os seus logs são eliminados

Quase ninguém define um período de retenção antes de o disco ficar cheio. Quando isso acontece, a decisão é tomada às 3 a.m., com o serviço parado. Defina-o logo no primeiro dia com base em duas perguntas: até que ponto recua nas consultas e o que ainda precisa de ter durante uma análise de incidente no próximo mês. Para um único servidor, 14 a 30 dias respondem às duas.

O Loki não elimina nada até ativar o compactor. A retenção está desativada por predefinição. Isto surpreende quem fica com o volume cheio enquanto retention_period permanece na configuração sem fazer nada.

limits_config:
  retention_period: 744h

compactor:
  working_directory: /loki/retention
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
  delete_request_store: filesystem

744h correspondem a 31 dias. Quatro regras documentadas regem esse bloco:

• A retenção é aplicada pelo compactor, e a documentação do Grafana indica que o compactor deve ser executado como uma única instância. Num VPS, isso acontece automaticamente.
• O período mínimo de retenção é 24h, e a retenção só funciona quando o período do índice é 24h. O exemplo schema_config já usa period: 24h, por isso mantenha-o.
• delete_request_store é obrigatório quando retention_enabled é verdadeiro. Identifica o armazenamento que contém os pedidos de eliminação. Num nó único com backend no sistema de ficheiros, corresponde ao object_store: filesystem já definido no schema.
• Os chunks são primeiro marcados e removidos depois de retention_delete_delay, que neste caso é 2h. Por isso, o espaço livre só é recuperado mais tarde do que a política indica. Não avalie a configuração pelo df cinco minutos depois de recarregar a configuração.

O OpenSearch elimina índices completos, não linhas individuais. Por isso, os índices de logs são criados por dia. Uma política ISM move um índice entre estados e elimina-o quando atinge a idade definida. Um ism_template associa a política aos índices novos, para que não tenha de o fazer manualmente.

{
  "policy": {
    "description": "delete log indexes after 14 days",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "14d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ],
        "transitions": []
      }
    ],
    "ism_template": { "index_patterns": ["logs-*"], "priority": 100 }
  }
}

Independentemente do sistema utilizado, um valor de retenção só é adequado se for acompanhado por uma verificação do espaço livre. Eliminar logs após 14 dias não ajuda se 10 dias de logs já ocuparem todo o volume. Por isso, associe a política a monitorização da saúde do disco num VPS e a um alerta aos 80% de utilização.

Quantos GB de disco por GB de logs

A resposta exata depende das suas linhas e dos seus campos. Meça nos seus próprios dados em vez de confiar numa proporção publicada. Os mecanismos são suficientemente diferentes para permitir prever a tendência. O OpenSearch e o Elasticsearch escrevem um índice invertido para cada campo indexado, além do documento armazenado. Por isso, o que chega ao disco ocupa mais espaço do que o texto bruto. Cada réplica multiplica esse consumo. Num único nó, defina o número de réplicas como 0, porque um shard de réplica no mesmo nó não pode sobreviver à falha desse nó. Se o deixar em 1, duplica o espaço em disco e mantém a saúde do cluster permanentemente em yellow. O Loki escreve chunks comprimidos e um índice pequeno de labels. O espaço ocupado acompanha, portanto, o tamanho comprimido das linhas.

sudo du -sh /var/lib/docker/volumes/loki-data/_data
curl -k -u admin:<password> "https://localhost:9200/_cat/indices?v&h=index,docs.count,store.size"

Execute o método aplicável em dois dias consecutivos. A diferença corresponde ao crescimento diário. Multiplique esse valor pelo número de dias de retenção e acrescente cerca de 30% de margem para compactação e merges. Depois, compare o resultado com o volume. Se não houver espaço suficiente, reduza a retenção antes de comprar mais disco. Um volume maior apenas adia o mesmo problema por algumas semanas.

O que falha primeiro num servidor pequeno

A memória esgota-se primeiro. O OOM killer do kernel escolhe um processo grande, e o maior processo num servidor de logs é a JVM. journalctl -k | grep -i "killed process" mostra a eliminação com o nome do processo entre parênteses retos. A vítima nem sempre é a stack de logs: o sshd ou a base de dados também podem ser escolhidos. É assim que uma experiência de logging pode derrubar a aplicação da qual pretendia obter logs. Defina limites máximos explícitos para os containers, para que a falha ocorra no componente que escolheu. É essa a finalidade dos limites de memória no Docker Compose.

O disco esgota-se em seguida, e os motores de pesquisa falham de uma forma específica e reconhecível. O Elasticsearch e o OpenSearch monitorizam a utilização do disco em vários níveis. O limite inferior é 85% e o limite superior é 90%. No flood stage de 95%, todos os índices com um shard nesse nó recebem o bloqueio index.blocks.read_only_allow_delete, e as escritas falham com blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]. O bloqueio é removido quando a utilização volta a ficar abaixo do limite superior. Liberte espaço primeiro. Remova o bloqueio manualmente apenas se este persistir.

curl -k -u admin:<password> -X PUT "https://localhost:9200/_all/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.blocks.read_only_allow_delete": null}'

O Loki falha de forma mais silenciosa. Não tem um modo somente de leitura para ativar. Por isso, um volume cheio aparece como pushes falhados no remetente e lacunas nos resultados das consultas. O problema de cardinalidade manifesta-se como um aumento lento da memória, não como um erro. Monitorize regularmente o tamanho do diretório de chunks, e não apenas depois de um incidente.

A última falha consiste em inserir dados inadequados. Um sistema de logs não é um sistema de métricas: guardar como texto a carga da CPU recolhida a cada 10 segundos é dispendioso e dificulta a criação de gráficos. Essa tarefa pertence a algo como um servidor de monitorização Zabbix no Ubuntu 24.04. As exceções das aplicações precisam de agrupamento, deduplicação e uma vista da stack trace. Essa é a função de um rastreador de erros autoalojado. Saber simplesmente que o site está indisponível é outra tarefa, respondida por uma página de disponibilidade e estado como o Uptime Kuma. Use o sistema de logs para linhas de texto que uma pessoa irá ler.

FAQ

Preciso do Elasticsearch para pesquisar os logs do meu servidor?

Não para um ou dois servidores. journalctl já filtra por unidade, prioridade, boot e intervalo de tempo, e os ficheiros rodados respondem a grep e zgrep. Um cluster de pesquisa justifica a memória quando tem muitas máquinas, precisa de pesquisa de texto livre em todas ao mesmo tempo ou várias pessoas precisam de uma interface partilhada. Abaixo disso, o journald com um limite de tamanho e um período de retenção faz o mesmo trabalho sem RAM adicional.

De quanta RAM preciso para gerir logs num servidor próprio?

Use os valores publicados por cada projeto em vez de uma regra geral. Loki e Alloy são programas Go sem heap que tenha de ser reservado antecipadamente, e a Grafana documenta o Loki monolítico para até aproximadamente 20GB por dia. O compose de exemplo do OpenSearch define 512 MB de heap para uma demonstração e 2 GB no exemplo de produção, e a Elastic indica que o heap deve permanecer em ou abaixo de 50% da memória total. Portanto, um heap de 2 GB requer uma máquina com 4 GB antes de instalar o Kibana. A documentação do Logstash recomenda pelo menos 4GB de heap apenas para o próprio serviço. Estas são configurações documentadas, não benchmarks. Meça a sua carga antes de dimensionar o plano.

Qual é a diferença real entre Loki e OpenSearch para logs?

O modelo de índices. O Loki indexa apenas os labels e mantém o corpo do log em blocos comprimidos que são analisados no momento da consulta. Por isso, as escritas são baratas e as consultas custam mais quando são abrangentes. O OpenSearch indexa o conteúdo dos campos. Assim, a pesquisa arbitrária de texto completo é rápida, mas tanto a memória como o disco suportam o custo do índice. Escolha Loki quando sabe qual é o serviço e o intervalo de tempo pretendidos. Escolha OpenSearch quando precisa de pesquisar texto que não consegue prever antecipadamente.

Durante quanto tempo devo manter os logs num VPS?

Escolha o número antes que o disco o escolha por si. Defina-o num único local por sistema: MaxRetentionSec= e SystemMaxUse= para o journald, retention_period com o compactador ativado para o Loki e uma política ISM com min_index_age para o OpenSearch. Na maioria das configurações de um único servidor, 14 a 30 dias são suficientes para depuração e análise de incidentes. Tudo o que tiver de ser mantido durante mais tempo deve ficar numa cópia armazenada fora do servidor, porque um log mantido apenas no servidor que falhou não é um registo.

O Promtail ainda é a forma recomendada de enviar logs para o Loki?

Não. O Promtail chegou ao fim de vida em 2 March 2026, e o Grafana Alloy substitui-o. O exemplo de instalação do Loki com Docker agora inclui uma configuração do Alloy, e a Grafana disponibiliza um conversor que transforma uma configuração existente do Promtail na sintaxe do Alloy. Uma instalação existente do Promtail continua a funcionar, mas já não recebe correções. Trate a migração como manutenção, e não como uma atualização que possa adiar indefinidamente.