{"id":1202,"date":"2026-06-21T18:05:17","date_gmt":"2026-06-21T21:05:17","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/06\/21\/aula-17-logs-do-sistema-journalctl-syslog-e-rsyslog\/"},"modified":"2026-06-21T18:05:17","modified_gmt":"2026-06-21T21:05:17","slug":"aula-17-logs-do-sistema-journalctl-syslog-e-rsyslog","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/06\/21\/aula-17-logs-do-sistema-journalctl-syslog-e-rsyslog\/","title":{"rendered":"Aula 17: Logs do sistema \u2014 journalctl, syslog e rsyslog"},"content":{"rendered":"

Bem-vindo \u00e0 Aula 17 do curso Linux \u2014 Do Zero ao Avan\u00e7ado<\/strong>. Hoje mergulhamos em um dos pilares mais subestimados \u2014 e ao mesmo tempo mais cr\u00edticos \u2014 da administra\u00e7\u00e3o de sistemas: os logs do sistema<\/strong>. Se voc\u00ea j\u00e1 precisou diagnosticar uma falha em produ\u00e7\u00e3o \u00e0s 3h da manh\u00e3, sabe que o dom\u00ednio sobre journalctl<\/strong>, syslog<\/strong> e rsyslog<\/strong> separa um profissional reativo de um engenheiro de infraestrutura preparado. Esta aula foi projetada para profissionais de TI, analistas de seguran\u00e7a da informa\u00e7\u00e3o e entusiastas que desejam extrair intelig\u00eancia real dos arquivos de log \u2014 n\u00e3o apenas l\u00ea-los, mas compreend\u00ea-los, centraliz\u00e1-los e utiliz\u00e1-los como ferramenta proativa de gerenciamento.<\/p>\n

Em nossos projetos na JRT Technology Solutions<\/strong>, lidamos diariamente com ambientes onde uma an\u00e1lise incorreta de logs pode significar horas de downtime desnecess\u00e1rio ou, pior, uma brecha de seguran\u00e7a n\u00e3o detectada. Por isso, estruturamos este conte\u00fado com a mesma abordagem que usamos em nossos treinamentos corporativos: fundamento te\u00f3rico s\u00f3lido, procedimentos completos e verific\u00e1veis, e configura\u00e7\u00f5es que funcionam em Ubuntu\/Debian<\/strong> e CentOS\/RHEL\/Rocky Linux<\/strong>. Cada comando mostrado aqui j\u00e1 foi executado, validado e documentado em ambientes reais de produ\u00e7\u00e3o.<\/p>\n

Nesta aula, voc\u00ea vai compreender a arquitetura de logging do Linux moderno \u2014 desde o tradicional daemon syslog<\/strong> e sua evolu\u00e7\u00e3o com o rsyslog<\/strong>, at\u00e9 o sistema bin\u00e1rio de journals do systemd<\/strong>. Vamos configurar regras de filtragem, rotacionar logs automaticamente, centralizar eventos de m\u00faltiplos servidores e, principalmente, utilizar o journalctl<\/strong> como ferramenta forense para consultas precisas e poderosas. Este \u00e9 o n\u00edvel intermedi\u00e1rio do curso: voc\u00ea j\u00e1 sabe administrar usu\u00e1rios, processos e servi\u00e7os; agora vai aprender a auditar tudo o que acontece no sistema.<\/p>\n

Ao final desta aula, voc\u00ea ser\u00e1 capaz de interpretar qualquer entrada de log, configurar facilidades e severidades do syslog, criar regras condicionais de roteamento com rsyslog, consultar journals com filtros por tempo, servi\u00e7o e prioridade, al\u00e9m de diagnosticar problemas comuns que impedem a gera\u00e7\u00e3o ou o registro correto de eventos. Prepare seu terminal: vamos transformar logs de um emaranhado de texto em um painel de controle completo sobre seus sistemas Linux.<\/p>\n

O que voc\u00ea vai aprender nesta aula<\/h3>\n
    \n
  • Compreender a arquitetura de logs do sistema<\/strong> no Linux e a diferen\u00e7a entre syslog tradicional, rsyslog e journald<\/li>\n
  • Instalar, configurar e gerenciar o rsyslog<\/strong> em distribui\u00e7\u00f5es Debian e Red Hat<\/li>\n
  • Dominar o journalctl<\/strong> para consultas avan\u00e7adas com filtros por tempo, unidade systemd, prioridade e campos personalizados<\/li>\n
  • Criar regras de roteamento de logs baseadas em facility e severity<\/li>\n
  • Configurar o armazenamento persistente do journal e integrar journald com rsyslog<\/li>\n
  • Diagnosticar e resolver os erros mais comuns em sistemas de logging<\/li>\n
  • Aplicar boas pr\u00e1ticas de reten\u00e7\u00e3o, rota\u00e7\u00e3o e seguran\u00e7a dos arquivos de log<\/li>\n<\/ul>\n

    Pr\u00e9-requisitos e Ambiente<\/h3>\n

    Para acompanhar esta aula com aproveitamento m\u00e1ximo, voc\u00ea precisa ter acesso a um sistema Linux com systemd<\/strong> \u2014 recomendamos duas m\u00e1quinas virtuais: uma rodando Ubuntu Server 24.04 LTS<\/strong> e outra com Rocky Linux 9<\/strong> (ou CentOS Stream 9). O systemd \u00e9 pr\u00e9-requisito porque o journalctl<\/strong> \u00e9 parte integrante do ecossistema systemd. Voc\u00ea tamb\u00e9m deve ter conclu\u00eddo as aulas anteriores do curso, em especial a Aula 12 (Gerenciamento de servi\u00e7os com systemd) e a Aula 15 (Permiss\u00f5es e propriedade de arquivos), pois manipularemos arquivos em \/var\/log<\/strong> e \/etc\/rsyslog.d\/<\/strong> com privil\u00e9gios de root.<\/p>\n

    Verifique se os pacotes essenciais est\u00e3o presentes. No Ubuntu\/Debian, o rsyslog<\/strong> costuma vir instalado por padr\u00e3o, mas voc\u00ea pode confirmar com dpkg -l | grep rsyslog<\/strong>. No Rocky\/CentOS, utilize rpm -qa | grep rsyslog<\/strong>. Ambos os sistemas j\u00e1 incluem o journald<\/strong> como parte do systemd. Se por acaso o rsyslog n\u00e3o estiver presente, instalaremos na se\u00e7\u00e3o dedicada. Garanta tamb\u00e9m que seu usu\u00e1rio tenha acesso a sudo<\/strong>. Vamos executar todos os comandos como root ou com sudo, conforme indicado, e cada procedimento ser\u00e1 completamente reproduz\u00edvel.<\/p>\n

    Conceitos Fundamentais de Logs do Sistema<\/h3>\n

    Antes de executar comandos, precisamos estabelecer a base conceitual que sustenta os logs do sistema<\/strong>. No Linux, logging \u00e9 o mecanismo pelo qual o kernel, os servi\u00e7os e as aplica\u00e7\u00f5es registram eventos \u2014 erros, avisos, informa\u00e7\u00f5es de debug, tentativas de autentica\u00e7\u00e3o, tr\u00e1fego de rede e muito mais. Esses registros s\u00e3o armazenados em arquivos de texto no diret\u00f3rio \/var\/log<\/strong> (no modelo tradicional) ou em bancos de dados bin\u00e1rios gerenciados pelo journald<\/strong> (no modelo systemd). Compreender essa dualidade \u00e9 essencial: muitos sistemas modernos operam com ambos simultaneamente, e voc\u00ea precisa saber quando consultar cada um.<\/p>\n

    O protocolo syslog<\/strong> (RFC 5424) define um formato padronizado para mensagens de log, composto por tr\u00eas elementos fundamentais: facility<\/strong> (a origem ou categoria do evento), severity<\/strong> (a gravidade ou prioridade) e a mensagem propriamente dita. A facility identifica o subsistema gerador \u2014 por exemplo, auth<\/strong> para eventos de autentica\u00e7\u00e3o, kern<\/strong> para mensagens do kernel, mail<\/strong> para servidores de email, e local0<\/strong> a local7<\/strong> para aplica\u00e7\u00f5es customizadas. J\u00e1 a severity segue uma escala num\u00e9rica de 0 (emerg\u00eancia total do sistema) a 7 (debug detalhado). Esta classifica\u00e7\u00e3o dupla permite filtrar e rotear mensagens com precis\u00e3o cir\u00fargica.<\/p>\n

    O rsyslog<\/strong> (rocket-fast syslog) \u00e9 a implementa\u00e7\u00e3o moderna do protocolo syslog, presente na maioria das distribui\u00e7\u00f5es Linux atuais. Ele estende o syslog tradicional com capacidades como: suporte a m\u00faltiplos protocolos de transporte (UDP, TCP, TLS), enfileiramento de mensagens em mem\u00f3ria para alta performance, parsing baseado em express\u00f5es regulares, e m\u00f3dulos din\u00e2micos para sa\u00edda em bancos de dados SQL, Elasticsearch e outros destinos. J\u00e1 o journald<\/strong>, parte do systemd, armazena logs em formato bin\u00e1rio com indexa\u00e7\u00e3o por dezenas de campos \u2014 ID do processo, UID, GID, unidade systemd, linha de execu\u00e7\u00e3o e muito mais. O journalctl<\/strong> \u00e9 a ferramenta de consulta desse banco de dados, oferecendo capacidades forenses que v\u00e3o muito al\u00e9m de um simples grep<\/strong> em arquivos de texto.<\/p>\n

    Na pr\u00e1tica, o fluxo de logging em um sistema Linux moderno funciona assim: aplica\u00e7\u00f5es e servi\u00e7os podem enviar mensagens diretamente ao syslog socket (\/dev\/log<\/strong>) ou ao journald<\/strong> via API nativa do systemd. O journald armazena tudo em \/var\/log\/journal\/<\/strong> (se configurado para persist\u00eancia) e, opcionalmente, encaminha uma c\u00f3pia para o rsyslog via socket \/run\/systemd\/journal\/syslog<\/strong>. O rsyslog, por sua vez, aplica suas regras de roteamento e grava as mensagens em arquivos de texto tradicionais como \/var\/log\/syslog<\/strong>, \/var\/log\/auth.log<\/strong> e \/var\/log\/kern.log<\/strong>. Essa arquitetura em camadas garante que voc\u00ea tenha tanto o poder anal\u00edtico do journalctl quanto a compatibilidade e simplicidade dos arquivos de texto plano.<\/p>\n

    O Ecossistema de Logs no Linux: syslog, rsyslog e journald<\/h3>\n

    Agora que voc\u00ea compreende os fundamentos, vamos detalhar cada componente do ecossistema de logs do sistema<\/strong>. O protocolo syslog<\/strong>, embora antigo, permanece onipresente por sua simplicidade e interoperabilidade. Ele define que cada mensagem possui um PRI<\/strong> (priority) composto pela combina\u00e7\u00e3o de facility e severity, calculado como (facility * 8) + severity<\/strong>. Por exemplo, uma mensagem de kernel com severidade “error” (facility=0, severity=3) tem PRI=3. Este valor num\u00e9rico viaja no cabe\u00e7alho de cada mensagem syslog e permite que servidores de log tomem decis\u00f5es de roteamento sem precisar interpretar o texto.<\/p>\n

    As facilities<\/strong> padronizadas s\u00e3o 24 (0 a 23), mas as mais comuns no dia a dia s\u00e3o apenas algumas. A tabela abaixo lista as facilities essenciais que voc\u00ea encontrar\u00e1 em qualquer servidor Linux. Memorizar pelo menos estas 10 \u00e9 um investimento que trar\u00e1 retorno imediato na sua capacidade de configurar regras de logging:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Tabela 1 \u2014 Facilities do syslog (RFC 3164\/5424)<\/caption>\n
    C\u00f3digo<\/th>\nFacility<\/th>\nDescri\u00e7\u00e3o<\/th>\nExemplo de uso<\/th>\n<\/tr>\n<\/thead>\n
    0<\/td>\nkern<\/strong><\/td>\nMensagens do kernel<\/td>\nDetec\u00e7\u00e3o de hardware, drivers<\/td>\n<\/tr>\n
    1<\/td>\nuser<\/strong><\/td>\nMensagens de processos de usu\u00e1rio<\/td>\nAplica\u00e7\u00f5es gen\u00e9ricas<\/td>\n<\/tr>\n
    2<\/td>\nmail<\/strong><\/td>\nSistema de email<\/td>\nPostfix, Sendmail, Dovecot<\/td>\n<\/tr>\n
    3<\/td>\ndaemon<\/strong><\/td>\nDaemons do sistema<\/td>\nsshd, cron, rsyslog<\/td>\n<\/tr>\n
    4<\/td>\nauth<\/strong><\/td>\nAutentica\u00e7\u00e3o e autoriza\u00e7\u00e3o<\/td>\nlogin, sudo, su, pam<\/td>\n<\/tr>\n
    5<\/td>\nsyslog<\/strong><\/td>\nMensagens internas do syslog<\/td>\nEventos do pr\u00f3prio rsyslog<\/td>\n<\/tr>\n
    6<\/td>\nlpr<\/strong><\/td>\nImpress\u00e3o<\/td>\nCUPS, spoolers<\/td>\n<\/tr>\n
    7<\/td>\nnews<\/strong><\/td>\nServidores de not\u00edcias USENET<\/td>\nINN, NNTP<\/td>\n<\/tr>\n
    10<\/td>\nauthpriv<\/strong><\/td>\nAutentica\u00e7\u00e3o sens\u00edvel<\/td>\nLogins, falhas de senha<\/td>\n<\/tr>\n
    13<\/td>\naudit<\/strong><\/td>\nAuditoria do sistema<\/td>\nauditd, SELinux<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    As severities<\/strong> (ou prioridades) seguem uma hierarquia num\u00e9rica onde valores menores indicam maior gravidade. Quando voc\u00ea configura uma regra com uma determinada severity, o rsyslog captura aquela prioridade e todas as superiores<\/strong>. Por exemplo, especificar warn<\/strong> (4) far\u00e1 com que sejam registradas tamb\u00e9m as mensagens de err (3), crit (2), alert (1) e emerg (0). Esta l\u00f3gica \u00e9 frequentemente fonte de confus\u00e3o para iniciantes, ent\u00e3o grave bem este comportamento antes de prosseguir:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
    Tabela 2 \u2014 Severities do syslog e seu significado<\/caption>\n
    C\u00f3digo<\/th>\nSeverity<\/th>\nPalavra-chave<\/th>\nSignificado<\/th>\n<\/tr>\n<\/thead>\n
    0<\/td>\nEmergency<\/td>\nemerg, panic<\/strong><\/td>\nSistema inutiliz\u00e1vel<\/td>\n<\/tr>\n
    1<\/td>\nAlert<\/td>\nalert<\/strong><\/td>\nA\u00e7\u00e3o imediata necess\u00e1ria<\/td>\n<\/tr>\n
    2<\/td>\nCritical<\/td>\ncrit<\/strong><\/td>\nCondi\u00e7\u00f5es cr\u00edticas<\/td>\n<\/tr>\n
    3<\/td>\nError<\/td>\nerr, error<\/strong><\/td>\nCondi\u00e7\u00f5es de erro<\/td>\n<\/tr>\n
    4<\/td>\nWarning<\/td>\nwarn, warning<\/strong><\/td>\nCondi\u00e7\u00f5es de aviso<\/td>\n<\/tr>\n
    5<\/td>\nNotice<\/td>\nnotice<\/strong><\/td>\nEventos normais, mas significativos<\/td>\n<\/tr>\n
    6<\/td>\nInformational<\/td>\ninfo<\/strong><\/td>\nMensagens informativas<\/td>\n<\/tr>\n
    7<\/td>\nDebug<\/td>\ndebug<\/strong><\/td>\nMensagens de depura\u00e7\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    O journald<\/strong>, por sua vez, n\u00e3o utiliza o conceito de facilities do syslog, mas mapeia as severities para campos bin\u00e1rios indexados. Quando voc\u00ea consulta com journalctl -p err<\/strong>, est\u00e1 filtrando por prioridade m\u00e1xima “error” ou superior (0-3), similar ao comportamento do syslog. A grande vantagem do journald \u00e9 sua capacidade de armazenar metadados ricos \u2014 cada entrada de log inclui automaticamente dezenas de campos como _PID<\/strong>, _UID<\/strong>, _GID<\/strong>, _COMM<\/strong>, _EXE<\/strong>, _SYSTEMD_UNIT<\/strong>, _TRANSPORT<\/strong> e muitos outros. Esses campos s\u00e3o indexados e podem ser consultados com precis\u00e3o milim\u00e9trica usando os filtros do journalctl.<\/p>\n

    Na arquitetura moderna, os logs do sistema<\/strong> fluem por tr\u00eas camadas que coexistem: o journald<\/strong> atua como coletor central e armazenamento estruturado, o socket \/run\/systemd\/journal\/syslog<\/strong> permite que o rsyslog leia os journals como se fossem mensagens syslog tradicionais, e o rsyslog<\/strong> persiste os dados em arquivos de texto, bancos SQL ou servidores remotos. Essa arquitetura garante que mesmo se o rsyslog falhar, os logs continuam sendo coletados pelo journald (que \u00e9 parte do PID 1) e podem ser recuperados posteriormente. Em nossos treinamentos na JRT Technology Solutions, sempre enfatizamos: nunca desabilite o journald em favor do rsyslog; use ambos em conjunto.<\/p>\n

    Instalando e Configurando o rsyslog no Ubuntu\/Debian e Rocky Linux\/CentOS<\/h3>\n

    Embora o rsyslog<\/strong> venha pr\u00e9-instalado na maioria das distribui\u00e7\u00f5es, \u00e9 importante verificar sua presen\u00e7a e garantir que o servi\u00e7o esteja ativo e habilitado para iniciar com o sistema. Em ambientes m\u00ednimos (containers Docker, instala\u00e7\u00f5es cloud m\u00ednimas), o rsyslog pode estar ausente. Vamos executar o procedimento completo de verifica\u00e7\u00e3o e instala\u00e7\u00e3o em ambas as fam\u00edlias de distribui\u00e7\u00f5es. Todos os comandos devem ser executados como root ou com sudo<\/strong>.<\/p>\n

    Come\u00e7amos pela fam\u00edlia Debian. No Ubuntu Server 24.04 LTS<\/strong>, execute os seguintes passos em sequ\u00eancia para verificar, instalar se necess\u00e1rio e iniciar o servi\u00e7o:<\/p>\n

    # Passo 1: Verificar se o pacote rsyslog est\u00e1 instalado\nsudo dpkg -l | grep rsyslog\n\n# Passo 2: Caso n\u00e3o apare\u00e7a nada na sa\u00edda, instale o pacote\nsudo apt update\nsudo apt install -y rsyslog\n\n# Passo 3: Verificar o status do servi\u00e7o rsyslog\nsudo systemctl status rsyslog\n\n# Passo 4: Habilitar o rsyslog para iniciar automaticamente no boot\nsudo systemctl enable rsyslog\n\n# Passo 5: Iniciar o servi\u00e7o (caso n\u00e3o esteja rodando)\nsudo systemctl start rsyslog<\/code><\/pre>\n
    # Sa\u00edda esperada do comando 'systemctl status rsyslog' no Ubuntu:\n\u25cf rsyslog.service - System Logging Service\n     Loaded: loaded (\/lib\/systemd\/system\/rsyslog.service; enabled; vendor preset: enabled)\n     Active: active (running) since Sun 2026-06-21 10:15:22 -03; 2min 34s ago\nTriggeredBy: \u25cf syslog.socket\n       Docs: man:rsyslogd(8)\n             https:\/\/www.rsyslog.com\/doc\/\n   Main PID: 1245 (rsyslogd)\n      Tasks: 4 (limit: 9422)\n     Memory: 3.2M\n        CPU: 134ms\n     CGroup: \/system.slice\/rsyslog.service\n             \u2514\u25001245 \/usr\/sbin\/rsyslogd -n -iNONE<\/code><\/pre>\n
    Agora, na fam\u00edlia Red Hat. Em Rocky Linux 9<\/strong> ou CentOS Stream 9<\/strong>, o procedimento \u00e9 similar, mas utilizamos o gerenciador de pacotes dnf<\/strong>:<\/p>\n
    # Passo 1: Verificar se o pacote rsyslog est\u00e1 instalado\nsudo rpm -qa | grep rsyslog\n\n# Passo 2: Caso n\u00e3o apare\u00e7a nada, instale com dnf\nsudo dnf install -y rsyslog\n\n# Passo 3: Verificar o status do servi\u00e7o\nsudo systemctl status rsyslog\n\n# Passo 4: Habilitar no boot e iniciar\nsudo systemctl enable rsyslog\nsudo systemctl start rsyslog<\/code><\/pre>\n
    # Sa\u00edda esperada do comando 'systemctl status rsyslog' no Rocky Linux:\n\u25cf rsyslog.service - System Logging Service\n     Loaded: loaded (\/usr\/lib\/systemd\/system\/rsyslog.service; enabled; vendor preset: enabled)\n     Active: active (running) since Sun 2026-06-21 14:20:05 UTC; 1min 12s ago\n       Docs: man:rsyslogd(8)\n             https:\/\/www.rsyslog.com\/doc\/\n   Main PID: 982 (rsyslogd)\n      Tasks: 4 (limit: 22996)\n     Memory: 3.1M\n        CPU: 89ms\n     CGroup: \/system.slice\/rsyslog.service\n             \u2514\u2500982 \/usr\/sbin\/rsyslogd -n<\/code><\/pre>\n
    Note que em ambas as distribui\u00e7\u00f5es, o estado deve ser active (running)<\/strong> e enabled<\/strong>. Se o servi\u00e7o estiver inativo, verifique os logs com sudo journalctl -xeu rsyslog<\/strong> para diagnosticar o problema antes de prosseguir. A diferen\u00e7a sutil na linha de comando do processo (com -iNONE<\/strong> no Ubuntu) est\u00e1 relacionada a configura\u00e7\u00f5es de compila\u00e7\u00e3o e n\u00e3o afeta o funcionamento. O importante \u00e9 que o daemon rsyslogd<\/strong> esteja rodando como processo filho do systemd.<\/p>\n
    Trabalhando com o journalctl \u2014 Consultas Essenciais<\/h3>\n
    O journalctl<\/strong> \u00e9 a principal ferramenta de consulta aos logs do sistema<\/strong> armazenados pelo journald. Diferente do tradicional cat \/var\/log\/syslog | grep algo<\/strong>, o journalctl oferece filtros integrados que exploram a indexa\u00e7\u00e3o bin\u00e1ria do journal \u2014 as consultas s\u00e3o ordens de magnitude mais r\u00e1pidas e precisas. Vamos explorar os comandos mais importantes, come\u00e7ando do b\u00e1sico e avan\u00e7ando para filtros complexos que voc\u00ea usar\u00e1 diariamente como administrador de sistemas.<\/p>\n
    O comando mais simples \u00e9 journalctl<\/strong> sem argumentos, que exibe todos os logs do sistema desde o boot atual, paginados com less<\/strong>. Use as setas para navegar e q<\/strong> para sair. Para ver logs de boots anteriores (extremamente \u00fatil para diagnosticar falhas que ocorreram antes de um reboot):<\/p>\n
    # Listar todos os boots registrados no journal\nsudo journalctl --list-boots\n\n# Exibir logs de um boot espec\u00edfico (ex: boot -1 = boot anterior)\nsudo journalctl -b -1\n\n# Exibir logs do boot atual com explica\u00e7\u00f5es estendidas\nsudo journalctl -xe<\/code><\/pre>\n
    # Sa\u00edda esperada de 'journalctl --list-boots':\n-3 f9a8c2b3d1e64d7a9b5c3d4e5f6a7b8c Fri 2026-06-19 08:15:11 -03\u2014Fri 2026-06-19 18:30:45 -03\n-2 3d7e8a9b1c2f4e5d6a7b8c9d0e1f2a3b Sat 2026-06-20 09:00:02 -03\u2014Sat 2026-06-20 22:45:18 -03\n-1 a1b2c3d4e5f67890abcdef1234567890 Sat 2026-06-20 23:10:55 -03\u2014Sun 2026-06-21 02:33:41 -03\n 0 d4e5f6a7b8c901234567890abcdef1234 Sun 2026-06-21 10:15:22 -03\u2014Sun 2026-06-21 14:45:09 -03<\/code><\/pre>\n
    A flag -x<\/strong> adiciona explica\u00e7\u00f5es textuais (help texts) para cada mensagem, mostrando informa\u00e7\u00f5es do cat\u00e1logo de mensagens do systemd. A flag -e<\/strong> pula diretamente para o final do journal (as mensagens mais recentes). Combinadas em -xe<\/strong>, voc\u00ea obt\u00e9m as \u00faltimas entradas com contexto explicativo \u2014 o comando de diagn\u00f3stico r\u00e1pido por excel\u00eancia.<\/p>\n
    Agora, avan\u00e7amos para filtros por tempo, essenciais para isolar eventos em uma janela espec\u00edfica durante an\u00e1lises forenses ou troubleshooting:<\/p>\n
    # Exibir logs gerados nas \u00faltimas 2 horas\nsudo journalctl --since \"2 hours ago\"\n\n# Exibir logs entre dois timestamps espec\u00edficos\nsudo journalctl --since \"2026-06-21 08:00:00\" --until \"2026-06-21 12:00:00\"\n\n# Exibir logs de hoje\nsudo journalctl --since today\n\n# Exibir logs dos \u00faltimos 30 minutos\nsudo journalctl --since \"30 min ago\"<\/code><\/pre>\n
    Os formatos de data aceitos pelo –since<\/strong> e –until<\/strong> s\u00e3o extremamente flex\u00edveis: voc\u00ea pode usar “2026-06-21”<\/strong>, “yesterday”<\/strong>, “2 weeks ago”<\/strong>, “2026-06-21 14:30:00”<\/strong> ou qualquer combina\u00e7\u00e3o que o GNU date entenda. Isso elimina a necessidade de c\u00e1lculos manuais de timestamps e torna as consultas muito mais intuitivas.<\/p>\n
    Um dos filtros mais poderosos e frequentemente subutilizados \u00e9 o -u<\/strong> para filtrar por unidade systemd. Se voc\u00ea sabe qual servi\u00e7o est\u00e1 investigando, este filtro restringe os resultados exatamente \u00e0quele contexto:<\/p>\n
    # Exibir logs do servi\u00e7o ssh\nsudo journalctl -u ssh.service\n\n# Exibir logs do ssh com explica\u00e7\u00f5es, \u00faltimos 100 registros\nsudo journalctl -xe -u ssh.service -n 100\n\n# Exibir logs do ssh desde a \u00faltima hora\nsudo journalctl -u ssh.service --since \"1 hour ago\"\n\n# Acompanhar logs em tempo real (similar a tail -f)\nsudo journalctl -u ssh.service -f<\/code><\/pre>\n
    O filtro por prioridade -p<\/strong> segue a mesma l\u00f3gica das severities do syslog: ao especificar um n\u00edvel, voc\u00ea recebe aquela prioridade e todas as superiores. Por exemplo, -p err<\/strong> mostra emerg, alert, crit e err, mas n\u00e3o warn, notice, info ou debug:<\/p>\n
    # Exibir apenas logs com prioridade error ou superior\nsudo journalctl -p err\n\n# Exibir logs de warning ou superior do servi\u00e7o nginx (se instalado)\nsudo journalctl -u nginx.service -p warning\n\n# Combinar filtros m\u00faltiplos: erros do ssh nas \u00faltimas 24h\nsudo journalctl -u ssh.service -p err --since yesterday<\/code><\/pre>\n
    Para finalizar esta se\u00e7\u00e3o, apresentamos o uso de campos personalizados com a flag _FIELD=VALUE<\/strong>. O journald indexa automaticamente dezenas de campos para cada entrada. Voc\u00ea pode listar todos os campos dispon\u00edveis com journalctl –output=verbose<\/strong> e ent\u00e3o filtrar por qualquer um deles. Exemplos pr\u00e1ticos:<\/p>\n
    # Filtrar logs de um usu\u00e1rio espec\u00edfico (UID 1000)\nsudo journalctl _UID=1000\n\n# Filtrar logs gerados por um bin\u00e1rio espec\u00edfico\nsudo journalctl _EXE=\/usr\/sbin\/sshd\n\n# Filtrar logs do kernel\nsudo journalctl _TRANSPORT=kernel\n\n# Combinar campos: mensagens do sshd com prioridade info\nsudo journalctl _EXE=\/usr\/sbin\/sshd _PRIORITY=6<\/code><\/pre>\n
    Conforme mencionamos, nossos especialistas da JRT Technology Solutions<\/strong> utilizam diariamente combina\u00e7\u00f5es como journalctl _SYSTEMD_UNIT=nginx.service _PID=12345 –since “30 min ago”<\/strong> para isolar rapidamente o contexto de um processo espec\u00edfico em produ\u00e7\u00e3o. A indexa\u00e7\u00e3o do journald faz com que mesmo journals com centenas de milhares de entradas sejam consultados em fra\u00e7\u00f5es de segundo.<\/p>\n
    Configura\u00e7\u00e3o Detalhada do rsyslog \u2014 Arquivos e Regras<\/h3>\n
    A configura\u00e7\u00e3o do rsyslog<\/strong> \u00e9 definida em arquivos localizados em \/etc\/rsyslog.conf<\/strong> (configura\u00e7\u00e3o principal) e \/etc\/rsyslog.d\/<\/strong> (arquivos de configura\u00e7\u00e3o adicionais). A filosofia moderna \u00e9 manter o arquivo principal enxuto e colocar suas regras customizadas em arquivos separados dentro de \/etc\/rsyslog.d\/<\/strong> \u2014 tipicamente nomeados como 50-nome-da-regra.conf<\/strong>. O n\u00famero no in\u00edcio (50, 99, etc.) define a ordem de carregamento, permitindo que voc\u00ea controle a preced\u00eancia das regras.<\/p>\n
    Vamos examinar o conte\u00fado completo do arquivo \/etc\/rsyslog.conf<\/strong> padr\u00e3o do Ubuntu e comentar cada se\u00e7\u00e3o relevante. Este arquivo define os m\u00f3dulos carregados, as configura\u00e7\u00f5es globais e as diretivas de inclus\u00e3o:<\/p>\n
    # \/etc\/rsyslog.conf \u2014 Configura\u00e7\u00e3o principal do rsyslog\n# Este \u00e9 o arquivo padr\u00e3o do Ubuntu 24.04 LTS\n\n#################\n#### MODULES ####\n#################\n\n# M\u00f3dulo para suporte a syslog sobre UDP tradicional (porta 514)\n# Comentado por padr\u00e3o \u2014 descomente se precisar receber logs remotos\n#module(load=\"imudp\")\n#input(type=\"imudp\" port=\"514\")\n\n# M\u00f3dulo para syslog sobre TCP (mais confi\u00e1vel que UDP)\n#module(load=\"imtcp\")\n#input(type=\"imtcp\" port=\"514\")\n\n# M\u00f3dulo para receber logs do journald via socket\nmodule(load=\"imjournal\" StateFile=\"imjournal.state\")\n\n###########################\n#### GLOBAL DIRECTIVES ####\n###########################\n\n# Formato de timestamp tradicional (compat\u00edvel com RFC 3164)\n$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat\n\n# Habilita recebimento de mensagens via socket \/dev\/log (aplica\u00e7\u00f5es locais)\n$ModLoad imuxsock\n\n# Suporte a recebimento de logs do kernel\n$ModLoad imklog\n\n# Ativa o processamento de templates avan\u00e7ados\n$WorkDirectory \/var\/spool\/rsyslog\n\n# Incluir todos os arquivos de configura\u00e7\u00e3o do diret\u00f3rio\n$IncludeConfig \/etc\/rsyslog.d\/*.conf\n\n# Diretiva para onde enviar mensagens por padr\u00e3o (catch-all)\n*.*;auth,authpriv.none   -\/var\/log\/syslog\n\n# Arquivos espec\u00edficos por facility\/severity\nauth,authpriv.*          \/var\/log\/auth.log\n*.*;auth,authpriv.none   -\/var\/log\/syslog\nkern.*                   -\/var\/log\/kern.log\nmail.*                   -\/var\/log\/mail.log\nmail.err                 \/var\/log\/mail.err\n\n# Cron (tarefas agendadas)\ncron.*                   \/var\/log\/cron.log\n\n# Mensagens de emerg\u00eancia para todos os usu\u00e1rios logados\n*.emerg                  :omusrmsg:*<\/code><\/pre>\n
    Cada linha de regra segue o formato facility.severity    a\u00e7\u00e3o<\/strong>. O asterisco *<\/strong> funciona como coringa: *.*<\/strong> significa “todas as facilities, todas as severities”. A sintaxe auth,authpriv.none<\/strong> na regra do \/var\/log\/syslog<\/strong> instrui o rsyslog a N\u00c3O gravar mensagens de auth e authpriv nesse arquivo (elas j\u00e1 v\u00e3o para auth.log, e duplic\u00e1-las seria redundante). O h\u00edfen –<\/strong> antes do caminho do arquivo (ex: -\/var\/log\/syslog<\/strong>) indica que a grava\u00e7\u00e3o deve ser ass\u00edncrona \u2014 o rsyslog n\u00e3o for\u00e7a um sync a disco ap\u00f3s cada escrita, melhorando performance em sistemas com alto volume de logs, mas com um pequeno risco de perda das \u00faltimas mensagens em caso de crash.<\/p>\n
    Agora, vamos criar um arquivo de configura\u00e7\u00e3o customizado para uma necessidade comum: separar logs de um servidor web Nginx em seu pr\u00f3prio arquivo, utilizando a facility local0<\/strong>. Este \u00e9 o procedimento padr\u00e3o para aplica\u00e7\u00f5es que n\u00e3o possuem facility nativa no syslog:<\/p>\n
    # Criar arquivo de configura\u00e7\u00e3o customizado\nsudo nano \/etc\/rsyslog.d\/50-nginx.conf\n\n# Conte\u00fado completo do arquivo 50-nginx.conf:\n# ------------------------------------------------------------\n# Regra: Todas as mensagens enviadas para facility local0\n# com qualquer severidade ser\u00e3o gravadas em \/var\/log\/nginx\/access.log\n# com rota\u00e7\u00e3o ass\u00edncrona (h\u00edfen)\nlocal0.*    -\/var\/log\/nginx\/access.log\n\n# Regra adicional: erros de local0 v\u00e3o para arquivo separado\nlocal0.err  \/var\/log\/nginx\/error.log\n# ------------------------------------------------------------\n<\/code><\/pre>\n
    Ap\u00f3s criar o arquivo, precisamos verificar a sintaxe da configura\u00e7\u00e3o antes de reiniciar o servi\u00e7o. O rsyslogd<\/strong> possui um modo de valida\u00e7\u00e3o que detecta erros de sintaxe sem aplicar as mudan\u00e7as:<\/p>\n
    # Verificar a configura\u00e7\u00e3o do rsyslog (modo de valida\u00e7\u00e3o)\nsudo rsyslogd -N1\n\n# Se a sa\u00edda for limpa, reiniciar o servi\u00e7o para aplicar as mudan\u00e7as\nsudo systemctl restart rsyslog\n\n# Verificar se o servi\u00e7o reiniciou sem erros\nsudo systemctl status rsyslog<\/code><\/pre>\n
    # Sa\u00edda esperada do comando 'rsyslogd -N1':\nrsyslogd: version 8.2312.0, config validation run (level 1), master config \/etc\/rsyslog.conf\nrsyslogd: End of config validation run. Bye.<\/code><\/pre>\n
    Se houver algum erro de sintaxe, o rsyslogd reportar\u00e1 a linha exata e o tipo de erro. Nunca reinicie o rsyslog sem antes validar a configura\u00e7\u00e3o<\/strong> \u2014 um erro de sintaxe pode silenciosamente impedir que todos os logs do sistema sejam gravados, criando um apag\u00e3o de visibilidade perigoso em produ\u00e7\u00e3o. Em nossos treinamentos na JRT Technology Solutions, sempre refor\u00e7amos este mantra: valide, depois reinicie.<\/p>\n
    Configurando o Armazenamento Persistente do Journal<\/h3>\n
    Por padr\u00e3o, o journald<\/strong> armazena seus logs em \/run\/log\/journal\/<\/strong>, que \u00e9 um sistema de arquivos em mem\u00f3ria (tmpfs) \u2014 ou seja, os logs s\u00e3o perdidos a cada reboot. Para manter os logs do sistema<\/strong> persistentes entre boots, voc\u00ea precisa configurar o armazenamento em disco e criar o diret\u00f3rio \/var\/log\/journal\/<\/strong>. Este \u00e9 um passo fundamental em servidores de produ\u00e7\u00e3o, onde a capacidade de auditar eventos p\u00f3s-reboot \u00e9 mandat\u00f3ria para conformidade e troubleshooting.<\/p>\n
    O procedimento \u00e9 id\u00eantico em Ubuntu\/Debian e Rocky\/CentOS, pois mexe no arquivo de configura\u00e7\u00e3o do systemd-journald e na estrutura de diret\u00f3rios gerenciada pelo systemd:<\/p>\n
    # Passo 1: Editar o arquivo de configura\u00e7\u00e3o do journald\nsudo nano \/etc\/systemd\/journald.conf\n\n# Descomente e altere a linha Storage=auto para Storage=persistent\n# (Remova o # do in\u00edcio da linha e defina o valor como persistent)\n# Storage=persistent\n\n# Passo 2: Criar o diret\u00f3rio de armazenamento persistente\nsudo mkdir -p \/var\/log\/journal\n\n# Passo 3: Aplicar permiss\u00f5es corretas (o systemd-journald roda como root)\nsudo chown root:systemd-journal \/var\/log\/journal\nsudo chmod 2755 \/var\/log\/journal\n\n# Passo 4: Reiniciar o servi\u00e7o do journald para aplicar as mudan\u00e7as\nsudo systemctl restart systemd-journald\n\n# Passo 5: Verificar se o diret\u00f3rio foi populado com arquivos de journal\nls -la \/var\/log\/journal\/<\/code><\/pre>\n
    # Sa\u00edda esperada do 'ls -la \/var\/log\/journal\/':\ntotal 16\ndrwxr-sr-x 3 root systemd-journal 4096 Jun 21 14:50 .\ndrwxrwxr-x 10 root syslog         4096 Jun 21 14:50 ..\ndrwxr-sr-x 2 root systemd-journal 4096 Jun 21 14:50 f9a8c2b3d1e64d7a9b5c3d4e5f6a7b8c<\/code><\/pre>\n
    O diret\u00f3rio com nome hexadecimal \u00e9 o machine ID<\/strong> do seu sistema, obtido de \/etc\/machine-id<\/strong>. Dentro dele, voc\u00ea encontrar\u00e1 arquivos com extens\u00e3o .journal<\/strong> \u2014 estes s\u00e3o os bancos bin\u00e1rios que cont\u00eam todos os logs persistentes. Para for\u00e7ar o journald a rotacionar os arquivos imediatamente (\u00fatil ap\u00f3s ativar a persist\u00eancia), use sudo journalctl –rotate<\/strong>. Para verificar o uso de disco atual do journal, execute sudo journalctl –disk-usage<\/strong>.<\/p>\n
    A configura\u00e7\u00e3o de limite de tamanho \u00e9 cr\u00edtica: em servidores com pouco espa\u00e7o em disco, o journal pode crescer descontroladamente. No arquivo \/etc\/systemd\/journald.conf<\/strong>, voc\u00ea pode definir SystemMaxUse=<\/strong> (limite m\u00e1ximo em disco), SystemKeepFree=<\/strong> (espa\u00e7o livre m\u00ednimo a manter) e SystemMaxFileSize=<\/strong> (tamanho m\u00e1ximo por arquivo de journal). Os valores padr\u00e3o s\u00e3o razo\u00e1veis (SystemMaxUse normalmente 10% do tamanho do filesystem, cap em 4GB), mas em servidores de log \u00e9 comum aumentar para 10GB ou mais, dependendo da reten\u00e7\u00e3o exigida:<\/p>\n
    # Trecho relevante do \/etc\/systemd\/journald.conf ap\u00f3s edi\u00e7\u00e3o:\n[Journal]\nStorage=persistent\nSystemMaxUse=5G\nSystemKeepFree=10G\nSystemMaxFileSize=1G\nMaxRetentionSec=30day<\/code><\/pre>\n
    Ap\u00f3s alterar estes par\u00e2metros, reinicie o systemd-journald<\/strong> com sudo systemctl restart systemd-journald<\/strong> e verifique se os limites foram aplicados corretamente com journalctl –disk-usage<\/strong>. A gest\u00e3o adequada do espa\u00e7o em disco para logs do sistema<\/strong> evita surpresas desagrad\u00e1veis como servidores que param de responder porque o \/var\/log encheu completamente.<\/p>\n
    Verificando a Instala\u00e7\u00e3o \/ Testando a Configura\u00e7\u00e3o<\/h3>\n
    Nesta se\u00e7\u00e3o obrigat\u00f3ria, vamos executar uma s\u00e9rie de verifica\u00e7\u00f5es pr\u00e1ticas para garantir que todo o ecossistema de logs do sistema<\/strong> est\u00e1 funcionando corretamente \u2014 desde o journald at\u00e9 o rsyslog, passando pelas regras customizadas que criamos. Seguiremos um roteiro ordenado: gerar eventos de teste, verificar sua presen\u00e7a no journal, confirmar que o rsyslog os capturou e inspecionar os arquivos de destino.<\/p>\n
    Primeiro, geramos um evento de teste utilizando o comando logger<\/strong>, que envia mensagens diretamente ao socket do syslog. Vamos simular mensagens com diferentes facilities e severities para validar nossas regras:<\/p>\n
    # Enviar uma mensagem de teste com facility local0 e severity info\nlogger -p local0.info \"TESTE_AULA17: Mensagem de info para local0\"\n\n# Enviar uma mensagem com facility local0 e severity err\nlogger -p local0.err \"TESTE_AULA17: Mensagem de erro para local0\"\n\n# Enviar uma mensagem de autentica\u00e7\u00e3o simulada (facility authpriv)\nlogger -p authpriv.warning \"TESTE_AULA17: Tentativa de login falhou para usuario teste\"<\/code><\/pre>\n
    A flag -p<\/strong> do logger especifica a prioridade no formato facility.severity<\/strong>. O texto em mai\u00fasculas (TESTE_AULA17) \u00e9 nossa string marcadora \u2014 facilita a localiza\u00e7\u00e3o nos logs. Ap\u00f3s enviar as mensagens, verificamos se elas aparecem nos destinos esperados:<\/p>\n
    # Verificar no journal as mensagens marcadas\nsudo journalctl -g \"TESTE_AULA17\" --no-pager\n\n# Verificar no arquivo \/var\/log\/syslog (Ubuntu) ou \/var\/log\/messages (RHEL)\nsudo grep \"TESTE_AULA17\" \/var\/log\/syslog\n\n# Verificar no arquivo customizado do nginx (se criado)\nsudo cat \/var\/log\/nginx\/access.log | grep \"TESTE_AULA17\"\nsudo cat \/var\/log\/nginx\/error.log | grep \"TESTE_AULA17\"\n\n# Verificar no arquivo de autentica\u00e7\u00e3o\nsudo grep \"TESTE_AULA17\" \/var\/log\/auth.log<\/code><\/pre>\n
    # Sa\u00edda esperada do 'journalctl -g \"TESTE_AULA17\"':\nJun 21 15:00:01 ubuntu-server unknown[5678]: TESTE_AULA17: Mensagem de info para local0\nJun 21 15:00:05 ubuntu-server unknown[5680]: TESTE_AULA17: Mensagem de erro para local0\nJun 21 15:00:10 ubuntu-server unknown[5682]: TESTE_AULA17: Tentativa de login falhou para usuario teste\n\n# Sa\u00edda esperada do 'grep \"TESTE_AULA17\" \/var\/log\/syslog':\nJun 21 15:00:01 ubuntu-server unknown: TESTE_AULA17: Mensagem de info para local0\nJun 21 15:00:05 ubuntu-server unknown: TESTE_AULA17: Mensagem de erro para local0\nJun 21 15:00:10 ubuntu-server unknown: TESTE_AULA17: Tentativa de login falhou para usuario teste\n\n# Sa\u00edda esperada do 'grep \"TESTE_AULA17\" \/var\/log\/auth.log':\nJun 21 15:00:10 ubuntu-server unknown: TESTE_AULA17: Tentativa de login falhou para usuario teste<\/code><\/pre>\n
    Agora verificamos a integridade do servi\u00e7o e a comunica\u00e7\u00e3o entre journald e rsyslog. O socket \/run\/systemd\/journal\/syslog<\/strong> deve existir e o rsyslog deve estar lendo a partir dele. Para confirmar, podemos inspecionar os sockets abertos pelo rsyslogd:<\/p>\n
    # Verificar se o socket journal-syslog est\u00e1 sendo utilizado pelo rsyslog\nsudo ss -lpx | grep syslog\n\n# Verificar estat\u00edsticas do journal (entradas, tamanho, etc.)\njournalctl --disk-usage\n\n# Teste final: gerar um evento e acompanhar em tempo real\nlogger -p daemon.info \"TESTE_AULA17_FINAL: Verificacao concluida\" && \\\nsudo journalctl -f -n 1 & sleep 2; kill %1<\/code><\/pre>\n
    # Sa\u00edda esperada de 'ss -lpx | grep syslog':\nu_str LISTEN 0      4096    \/run\/systemd\/journal\/syslog 12345       * 0\nu_str LISTEN 0      4096    \/dev\/log                     12346       * 0\n\n# Sa\u00edda esperada de 'journalctl --disk-usage':\nArchived and active journals take up 48.7M in the file system.<\/code><\/pre>\n
    Se voc\u00ea conseguiu ver todas as mensagens de teste nos arquivos e no journal, com o rsyslog ativo e consumindo do socket correto, seu sistema de logging est\u00e1 plenamente funcional. A capacidade de gerar, rastrear e confirmar logs em m\u00faltiplos destinos \u00e9 uma habilidade que diferencia administradores competentes \u2014 e esta verifica\u00e7\u00e3o sistem\u00e1tica deve fazer parte de qualquer procedimento de deploy ou troubleshooting.<\/p>\n
    Erros Comuns e Como Resolver<\/h3>\n
    Em nossa experi\u00eancia na JRT Technology Solutions<\/strong>, encontramos repetidamente os mesmos problemas de configura\u00e7\u00e3o de logs do sistema<\/strong> em ambientes de clientes. Documentamos aqui os quatro erros mais frequentes, com suas causas, sintomas e solu\u00e7\u00f5es completas \u2014 para que voc\u00ea possa diagnostic\u00e1-los rapidamente e resolv\u00ea-los sem escalar para n\u00edveis superiores de suporte.<\/p>\n