---
title: "Como analisar logs de uma VPS Linux com journalctl e grep"
description: "Filtre logs da VPS por serviço, data e prioridade com journalctl, saiba o que olhar em auth.log, syslog e Nginx e controle o tamanho com logrotate."
url: "https://streethosting.com.br/guias/vps/analisar-logs-vps-linux"
category: "vps"
slug: "analisar-logs-vps-linux"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "analisar logs vps linux"
  - "journalctl filtrar por data"
  - "ver logs linux var log"
  - "auth.log tentativas ssh"
  - "configurar logrotate"
  - "log nginx erro 502"
---

# Encontrar a causa de um erro nos logs da VPS: journalctl, /var/log e logrotate

Quase todo problema de servidor deixa rastro em algum log. Veja onde cada registro fica no Ubuntu, como recortar por serviço, horário e gravidade e como manter os logs sem encher o disco.

> **Resposta rápida**
>
> Para **analisar logs de uma VPS Linux**, comece pelo journalctl: `journalctl -u nome-do-servico` filtra por serviço, `--since` e `--until` recortam o horário, `-p err` mostra só erros e `-b` limita ao boot atual. Complete com os arquivos de /var/log, como auth.log para acessos SSH, syslog para o sistema e os logs do Nginx, e configure o logrotate para os logs não encherem o disco.

## Onde ficam os logs no Linux

No Ubuntu, os logs moram em dois lugares ao mesmo tempo. O journald, parte do systemd, recebe a saída de todos os serviços e as mensagens do kernel e guarda tudo num formato binário indexado, que você lê com o journalctl. O rsyslog lê o mesmo fluxo e grava arquivos de texto em /var/log, como syslog e auth.log. Alguns programas, como Nginx e bancos de dados, ainda escrevem arquivos próprios que não passam pelo journal.

No Ubuntu 24.04, os dois mecanismos vêm ativos. No Debian 12, o rsyslog não é instalado por padrão, então syslog e auth.log podem nem existir; lá, o caminho é o journalctl para quase tudo.

| Onde | O que registra | Como ler |
| --- | --- | --- |
| Journal (journalctl) | Saída de todos os serviços do systemd e mensagens do kernel | journalctl com filtros |
| /var/log/syslog | Mensagens gerais do sistema e dos serviços | less, grep e tail |
| /var/log/auth.log | Logins SSH, uso de sudo e falhas de autenticação | grep por Failed ou Accepted |
| /var/log/kern.log | Mensagens do kernel: disco, rede e OOM killer | grep por error ou oom |
| /var/log/nginx/ | access.log com cada requisição e error.log com as falhas | tail, awk e grep |
| /var/log/apt/history.log | O que foi instalado, atualizado ou removido, e quando | less |
| /var/log/fail2ban.log | IPs banidos e liberados pelo Fail2ban | grep por Ban |
| /var/log/ufw.log | Pacotes bloqueados pelo firewall, se o log do UFW estiver ligado | grep por BLOCK |

Arquivos com final .1 ou .gz são versões antigas já rotacionadas. Os compactados podem ser lidos sem descompactar, com zgrep e zless.

Antes de qualquer investigação, confira se o relógio da VPS está no fuso certo. Log em UTC comparado com o horário de Brasília do seu celular rende três horas de confusão, e numa investigação o horário é tudo. O ajuste leva um comando e está em [fuso horário e idioma da VPS para o Brasil](https://streethosting.com.br/guias/vps/configurar-timezone-locale-vps-brasil).

## journalctl: serviço, data e prioridade

O journalctl sem filtro despeja tudo desde o registro mais antigo, o que não ajuda ninguém. A força dele está em combinar filtros:

```
# por serviço (nome da unidade do systemd)
journalctl -u nginx
journalctl -u ssh

# acompanhar em tempo real, como tail -f
journalctl -u minha-app -f

# últimas 100 linhas, sem paginador
journalctl -u minha-app -n 100 --no-pager

# por janela de tempo
journalctl --since "2026-09-28 08:00" --until "2026-09-28 09:30"
journalctl --since "30 min ago"
journalctl -u nginx --since yesterday --until today

# só erros e o que for mais grave
journalctl -p err -b

# boot atual, boot anterior e lista de boots
journalctl -b
journalctl -b -1
journalctl --list-boots

# mensagens do kernel
journalctl -k
```

O filtro `-u` usa o mesmo nome que você passa para o systemctl status. No Ubuntu, o serviço do SSH se chama ssh. O `-p err` mostra a prioridade informada e todas as mais graves (crit, alert e emerg), e aceita também warning quando você quer ver avisos. O `-b -1` mostra o boot anterior e é o filtro mais útil depois de um reinício inesperado, porque traz as últimas linhas antes de a máquina cair.

Se o `--list-boots` mostrar só o boot atual, o journal está sendo guardado apenas em memória e se perde a cada reinício. No Ubuntu recente ele já costuma ser persistente, mas, se não for, crie a pasta e reinicie o journald:

```
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
```

Três opções completam o arsenal. O `-g` procura um padrão dentro das mensagens, como `journalctl -u minha-app -g "timeout|refused"`. O `-o short-iso` troca a data para o formato ano, mês e dia, que ordena e compara melhor. E o `--disk-usage` mostra quanto espaço o journal ocupa. Uma consulta típica de investigação junta tudo: `journalctl -u minha-app -p warning --since today -o short-iso`.

## Os arquivos de /var/log que importam

Os arquivos de texto têm uma vantagem: funcionam com as ferramentas de sempre. Quatro comandos resolvem quase tudo:

```
sudo tail -f /var/log/syslog
sudo grep -i "error" /var/log/syslog | tail -n 50
sudo zgrep "Failed password" /var/log/auth.log*
sudo less +G /var/log/nginx/error.log
```

O tail -f acompanha o arquivo em tempo real. O grep -i ignora maiúsculas e minúsculas. O zgrep procura também nos arquivos rotacionados e compactados, então o asterisco no fim cobre as últimas semanas de uma vez. O less +G abre o arquivo já no fim, onde estão as linhas mais novas; dentro dele, Shift e F passam a acompanhar como o tail.

O auth.log é o diário de acesso da VPS. Linhas com Accepted publickey ou Accepted password são logins que deram certo. Failed password e Invalid user são tentativas que falharam. Uma VPS com IP público recebe milhares dessas tentativas por dia, feitas por robôs que varrem a internet; é ruído normal e o motivo para usar só chave SSH e [Fail2ban para proteger o SSH](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps).

O /var/log/apt/history.log responde a uma pergunta que aparece em toda investigação: o que mudou ontem? Ele mostra data, comando e pacotes de cada instalação ou atualização. Muitos casos de começou a dar erro do nada coincidem com uma atualização automática, registrada também em `/var/log/unattended-upgrades/`.

## Roteiro para investigar um erro

Quando algo quebrou e você não sabe por onde começar, vá do geral para o específico:

1. `systemctl --failed` lista as unidades que falharam.
2. `systemctl status nome` mostra estado, código de saída e as últimas linhas de log do serviço.
3. `journalctl -u nome -b -p warning` traz avisos e erros do serviço desde o boot.
4. Ache o horário do primeiro erro e abra a janela ao redor dele no sistema inteiro, sem filtro de serviço: `journalctl --since "09:12" --until "09:20"`.
5. Cruze com os logs próprios da aplicação, do Nginx e do banco no mesmo minuto.

O quarto passo é o que mais economiza tempo. O erro do seu serviço quase sempre é consequência de outra coisa: a aplicação caiu porque o banco recusou conexão, o banco recusou porque reiniciou, e ele reiniciou porque o kernel o encerrou por falta de memória. Olhando o sistema todo naquela janela, a cadeia aparece em ordem cronológica.

> **Dica**
>
> Aprenda a ler o código de saída no systemctl status. status=9/KILL indica processo encerrado à força, muitas vezes pelo OOM killer. status=203/EXEC indica que o systemd não conseguiu executar o binário, por caminho errado ou falta de permissão. status=1/FAILURE é a própria aplicação saindo com erro, e o motivo está nas linhas anteriores do log.

## Casos práticos: SSH, Nginx e memória

### Tentativas de login no SSH

```
# quantas falhas hoje
sudo journalctl -u ssh --since today | grep -c "Failed password"

# IPs que mais tentaram
sudo grep "Failed password" /var/log/auth.log | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head

# logins que deram certo
sudo grep "Accepted" /var/log/auth.log
```

A última lista é a que importa. Falha de login é ruído; um Accepted vindo de um IP que você não reconhece é incidente, e a primeira reação é trocar chaves, revisar os usuários com acesso e conferir o que foi feito a partir daquela sessão.

### Erros 5xx e IPs no Nginx

```
# requisições com status 5xx no log atual
sudo awk '$9 ~ /^5/' /var/log/nginx/access.log | tail -n 20

# IPs que mais fazem requisições
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# caminhos que mais geram 404
sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# o que o Nginx diz sobre a aplicação atrás dele
sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 20
```

No formato padrão do Nginx, o campo 9 é o código de status e o campo 7 é o caminho pedido. Um 502 Bad Gateway quase sempre aparece no error.log como `connect() failed (111: Connection refused) while connecting to upstream`: o Nginx está de pé, mas a aplicação atrás dele não está aceitando conexão. O próximo passo é o journalctl da aplicação.

Um único IP com milhares de requisições por minuto pode ser um robô de busca mal comportado, um scraper ou o começo de um ataque na camada de aplicação. Como separar pico legítimo de ataque está em [como identificar um ataque DDoS no servidor](https://streethosting.com.br/guias/infraestrutura/identificar-ataque-ddos-servidor).

### Processos encerrados por falta de memória

```
sudo journalctl -k -b | grep -i -E "out of memory|killed process"
sudo journalctl -k -b -1 | grep -i oom
```

Quando a memória acaba, o kernel escolhe um processo, normalmente o maior, e o encerra. A linha Killed process traz o nome e o PID dele. Se aparece com frequência, não adianta só reiniciar o serviço: é preciso reduzir o consumo, configurar limites ou aumentar a RAM.

## Logrotate e limite do journal

Log que só cresce acaba com o disco. O logrotate roda uma vez por dia, disparado por um timer do systemd, renomeia os arquivos, compacta os antigos e apaga os que passaram do limite. Pacotes como Nginx já instalam a própria regra em /etc/logrotate.d/. Para os logs da sua aplicação, crie um arquivo:

```
# /etc/logrotate.d/minha-app
/var/log/minha-app/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}
```

Com daily e rotate 14, ficam duas semanas de histórico. O compress usa gzip nos antigos e o delaycompress deixa o mais recente rotacionado sem compactar, para facilitar a leitura. O copytruncate copia o arquivo e esvazia o original no lugar, o que serve para aplicações que não reabrem o log sozinhas; o preço é perder as poucas linhas escritas durante a cópia. Se a aplicação sabe reabrir o arquivo por sinal, prefira um bloco postrotate com o reload. Teste antes de confiar:

```
sudo logrotate -d /etc/logrotate.d/minha-app   # simula, sem alterar nada
sudo logrotate -f /etc/logrotate.d/minha-app   # força uma rotação agora
```

O journal tem um limite próprio: por padrão, até 10% do sistema de arquivos, com teto de 4 GB. Numa VPS de 20 GB, isso pode chegar a 2 GB só de journal. Para definir um limite menor:

```
journalctl --disk-usage
sudo journalctl --vacuum-size=300M

# limite permanente em /etc/systemd/journald.conf
[Journal]
SystemMaxUse=300M

sudo systemctl restart systemd-journald
```

> **Atenção**
>
> Não apague com rm um log que um processo ainda está escrevendo. O arquivo some da listagem, mas o espaço só é liberado quando o processo fecha o arquivo. Para esvaziar sem esse problema, use `sudo truncate -s 0 /caminho/arquivo.log`. O caso completo, com o diagnóstico pelo lsof, está em [descobrir o que ocupa espaço na VPS](https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps).

## Quando o log aponta falta de recurso

Logs contam o que quebrou; métricas contam como a máquina chegou até ali. Se os logs repetem o mesmo padrão, como processos encerrados pelo OOM killer, timeout no banco em todo horário de pico ou No space left on device, a correção não está no log: a VPS ficou pequena para a carga. Para pegar esses sinais antes que virem queda, combine os logs com alertas de recursos, como descrito em [como monitorar uma VPS 24 horas por dia](https://streethosting.com.br/guias/vps/monitorar-vps-24-horas).

Quando a conclusão é falta de recurso, o upgrade pelo painel aumenta memória, vCPU e disco de uma vez, cobra só a diferença proporcional do ciclo e exige um reinício da VM. As VPS da StreetHosting rodam em KVM, com NVMe, acesso root e AntiDDoS, no datacenter de São Paulo. A linha Ryzen 9 9950X vai de R$ 39,00 (1 vCPU, 2 GB, 20 GB NVMe) a R$ 814,00 (14 vCPU, 64 GB, 640 GB) e a linha Xeon vai de R$ 23,00 (2 vCPU, 2 GB, 20 GB) a R$ 550,00 (24 vCPU, 64 GB, 640 GB). Em todos os degraus o disco cresce junto com a memória, o que dá espaço para logs e journal sem aperto. Veja as opções na [página de VPS](https://streethosting.com.br/vps).

## Perguntas frequentes

### Como ver o log de um serviço no Linux?

Use journalctl -u seguido do nome da unidade, como journalctl -u nginx. Acrescente -f para acompanhar em tempo real, -n 100 para ver só as últimas linhas e -b para limitar ao boot atual.

### Como filtrar o journalctl por data e hora?

Use --since e --until com a data e a hora entre aspas. Para o dia de hoje basta a hora, como --since 08:00 --until 09:30, e também valem expressões em inglês como yesterday, today e 1 hour ago, entre aspas quando têm espaço.

### Onde fica o log de tentativas de login SSH?

No Ubuntu, em /var/log/auth.log, e também no journal com journalctl -u ssh. Linhas com Failed password e Invalid user são tentativas que falharam. As linhas com Accepted mostram os logins que deram certo, e essa é a lista que merece mais atenção.

### Por que o journalctl não mostra nada antes do último reboot?

Porque o journal está sendo guardado só em memória. Crie a pasta /var/log/journal e reinicie o serviço do journald. A partir daí, os boots anteriores ficam guardados e journalctl -b -1 mostra o que aconteceu antes da queda.

### Posso apagar os arquivos de /var/log?

Os arquivos antigos já rotacionados, com final .gz ou numerados, podem ser removidos. Não apague com rm o log que está em uso, porque o processo continua gravando no arquivo apagado e o espaço não volta; esvazie com truncate -s 0 e deixe o logrotate cuidar do resto.

## Guias relacionados

- [Configurar Fail2Ban na VPS: SSH, Nginx e reincidentes](https://streethosting.com.br/guias/vps/configurar-fail2ban-ssh-vps.md)
- [O que está ocupando espaço na VPS: como descobrir e liberar](https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps.md)
- [Como monitorar uma VPS 24 horas: métricas, alertas e uptime](https://streethosting.com.br/guias/vps/monitorar-vps-24-horas.md)
- [Como ajustar o fuso horário e o idioma da VPS para o Brasil](https://streethosting.com.br/guias/vps/configurar-timezone-locale-vps-brasil.md)
- [Checklist de segurança para servidor Linux do zero ao seguro](https://streethosting.com.br/guias/infraestrutura/checklist-seguranca-servidor-linux.md)

## Produtos citados

- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Encontrar a causa de um erro nos logs da VPS: journalctl, /var/log e logrotate",
    "name": "Como analisar logs de uma VPS Linux com journalctl e grep",
    "abstract": "Quase todo problema de servidor deixa rastro em algum log. Veja onde cada registro fica no Ubuntu, como recortar por serviço, horário e gravidade e como manter os logs sem encher o disco.",
    "description": "Filtre logs da VPS por serviço, data e prioridade com journalctl, saiba o que olhar em auth.log, syslog e Nginx e controle o tamanho com logrotate.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/analisar-logs-vps-linux"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Como ver o log de um serviço no Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Use journalctl -u seguido do nome da unidade, como journalctl -u nginx. Acrescente -f para acompanhar em tempo real, -n 100 para ver só as últimas linhas e -b para limitar ao boot atual."
        }
      },
      {
        "@type": "Question",
        "name": "Como filtrar o journalctl por data e hora?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Use --since e --until com a data e a hora entre aspas. Para o dia de hoje basta a hora, como --since 08:00 --until 09:30, e também valem expressões em inglês como yesterday, today e 1 hour ago, entre aspas quando têm espaço."
        }
      },
      {
        "@type": "Question",
        "name": "Onde fica o log de tentativas de login SSH?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "No Ubuntu, em /var/log/auth.log, e também no journal com journalctl -u ssh. Linhas com Failed password e Invalid user são tentativas que falharam. As linhas com Accepted mostram os logins que deram certo, e essa é a lista que merece mais atenção."
        }
      },
      {
        "@type": "Question",
        "name": "Por que o journalctl não mostra nada antes do último reboot?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Porque o journal está sendo guardado só em memória. Crie a pasta /var/log/journal e reinicie o serviço do journald. A partir daí, os boots anteriores ficam guardados e journalctl -b -1 mostra o que aconteceu antes da queda."
        }
      },
      {
        "@type": "Question",
        "name": "Posso apagar os arquivos de /var/log?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Os arquivos antigos já rotacionados, com final .gz ou numerados, podem ser removidos. Não apague com rm o log que está em uso, porque o processo continua gravando no arquivo apagado e o espaço não volta; esvazie com truncate -s 0 e deixe o logrotate cuidar do resto."
        }
      }
    ]
  }
]
```