Aula 18: Monitoramento e logs no FreeBSD

Bem-vindo à décima oitava aula do curso FreeBSD — Do Zero ao Avançado. Nesta etapa, vamos explorar a fundo o universo de monitoramento e logs no FreeBSD, competência essencial para qualquer profissional que administra servidores, seja em infraestrutura de produção, segurança da informação ou ambientes corporativos críticos. Você aprenderá a extrair informações valiosas do sistema operacional, identificar comportamentos anômalos, investigar incidentes e manter a saúde dos serviços sob controle. Sem um bom regime de monitoramento e gestão de logs, mesmo a configuração mais bem elaborada se torna uma caixa-preta impossível de auditar.

O FreeBSD oferece um ecossistema de logging excepcionalmente robusto, centrado no syslogd e no newsyslog, com total transparência e flexibilidade. Diferente de muitas distribuições Linux que migraram para o journald, o FreeBSD mantém arquivos de texto puro em /var/log, o que facilita a integração com ferramentas de análise, o uso de utilitários clássicos como grep, tail e awk, e o envio de logs para sistemas centralizados. Além disso, a base do sistema oferece um verdadeiro arsenal de ferramentas de monitoramento de desempenho, como top, vmstat, iostat, systat, gstat e netstat.

Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente as técnicas que você verá nesta aula para diagnosticar gargalos, auditar eventos de segurança e planejar capacidade em servidores FreeBSD que sustentam aplicações críticas de nossos clientes. A prática constante desses comandos e a leitura disciplinada dos logs são o que separa um administrador reativo de um profissional proativo que antecipa falhas antes que elas impactem o negócio.

Ao final desta aula, você será capaz de configurar o sistema de logging do FreeBSD de ponta a ponta, rotacionar logs automaticamente para evitar que o disco fique cheio, monitorar o desempenho de CPU, memória, discos e rede em tempo real, e interpretar as saídas para tomar decisões rápidas e embasadas. Também cobriremos os erros mais comuns que acontecem na prática e como resolvê-los de forma definitiva.

O que você vai aprender nesta aula

• Compreender a arquitetura do sistema de logs do FreeBSD e o papel do daemon syslogd
• Localizar, ler e interpretar os principais arquivos de log em /var/log
• Configurar o syslogd para filtrar mensagens por prioridade e facility, incluindo envio remoto
• Dominar a rotação e compressão automática de logs com o newsyslog
• Utilizar ferramentas de monitoramento em tempo real: top, vmstat, iostat, systat, gstat e netstat
• Verificar a integridade do sistema de logging com comandos de teste e diagnóstico
• Resolver problemas comuns de permissões, espaço em disco e configuração incorreta
• Aplicar boas práticas de retenção, auditoria e centralização de logs em ambientes corporativos

Pré-requisitos e Ambiente

Para acompanhar esta aula com total proveito, você deve ter concluído as aulas anteriores do curso, em especial aquelas que tratam de instalação do sistema, gerenciamento de serviços com rc.conf e administração básica de arquivos e processos. O ambiente mínimo necessário é uma máquina com FreeBSD 13.x ou 14.x instalado, com acesso root ou privilégios de sudo. Recomendamos o uso de uma máquina virtual ou servidor de testes dedicado, pois manipularemos daemons e arquivos de configuração sensíveis do sistema.

Certifique-se de que o sistema esteja atualizado com o comando freebsd-update fetch install e que o conjunto base esteja íntegro, pois todos os utilitários que usaremos fazem parte do sistema base, sem necessidade de instalar pacotes adicionais. Tenha um editor de texto de sua preferência disponível, como vi, ee ou nano (disponível no pkg). Também é importante ter uma noção básica de shell e do conceito de daemons, pois vamos reiniciar serviços e observar seus logs em tempo real.

Se você estiver utilizando ZFS, terá acesso a ferramentas adicionais de monitoramento de armazenamento que mencionaremos. Caso contrário, o UFS também será plenamente suportado em todos os exemplos. Não é necessária nenhuma configuração externa, mas se você tiver uma segunda máquina na rede, poderá testar o envio remoto de logs com syslogd de forma prática, simulando uma arquitetura de centralização de eventos.

Fundamentos de Monitoramento e logs no FreeBSD: arquitetura do syslogd

O syslogd é o daemon responsável por receber mensagens de log de vários programas do sistema e encaminhá-las para destinos configurados, como arquivos, terminais, pipes ou outros servidores. Ele é iniciado pelo script de inicialização /etc/rc.d/syslogd e lê sua configuração do arquivo /etc/syslog.conf. O FreeBSD utiliza o formato tradicional do syslog, herdado do BSD, que é simples, poderoso e amplamente documentado na página de manual syslog.conf(5).

No coração do syslog estão os conceitos de facility e severity. A facility indica a origem da mensagem: kern (kernel), auth (autenticação), mail, daemon, cron, lpr, news, ftp, local0 a local7, entre outras. A severity indica a gravidade, em ordem decrescente: emerg, alert, crit, err, warning, notice, info e debug. A combinação de facility e severity permite filtrar de forma extremamente granular quais mensagens serão registradas e para onde irão.

O arquivo /etc/syslog.conf tem um formato baseado em campos separados por espaços ou tabulações. A primeira coluna define o seletor (facility.severity), e as demais colunas definem o destino. Por exemplo, a linha mail.info /var/log/maillog instrui o syslogd a enviar todas as mensagens da facility mail com severidade igual ou superior a info para o arquivo /var/log/maillog. Esse modelo permite acumular mensagens de diferentes origens em arquivos específicos, facilitando a organização e a análise.

Além do arquivo de configuração, o FreeBSD emprega o mecanismo newsyslog para a rotação e compressão de logs. Enquanto o syslogd escreve os logs continuamente, o newsyslog é agendado via cron para arquivar, comprimir, renomear e remover logs antigos, impedindo que os arquivos cresçam indefinidamente. A configuração fica em /etc/newsyslog.conf e é executada automaticamente a cada hora pelo usuário root, conforme definido em /etc/crontab.

É importante compreender que o FreeBSD também possui o dmesg, que armazena o buffer de mensagens do kernel em memória, e o utilitário logger, que permite gerar mensagens de log manualmente a partir da linha de comando. Essas ferramentas, somadas ao syslogd e ao newsyslog, formam um ciclo completo de geração, captura, armazenamento, rotação e descarte de logs que é a base de qualquer estratégia de observabilidade em FreeBSD.

Monitoramento e logs no FreeBSD: configurando o syslogd passo a passo

Nesta seção, você vai personalizar o sistema de logging do FreeBSD para atender a cenários reais de administração. O objetivo é demonstrar o procedimento completo de configuração, incluindo a edição do arquivo /etc/syslog.conf, a reinicialização do serviço e a verificação dos resultados. Vamos criar uma configuração funcional que registre logs de autenticação, cron e kernel em arquivos específicos, além de habilitar o envio remoto para um servidor central de logs.

1. Faça backup do arquivo de configuração original: antes de alterar qualquer arquivo de sistema, copie o original. Execute cp /etc/syslog.conf /etc/syslog.conf.bak. Isso permite reverter rapidamente em caso de erro de sintaxe.
2. Abra o arquivo de configuração: use ee /etc/syslog.conf ou vi /etc/syslog.conf para editar. Observe que o arquivo usa tabulações como separadores de campo por padrão, embora espaços também funcionem na maioria das versões modernas.
3. Personalize os seletores e destinos: configure as linhas conforme o exemplo comentado que mostraremos a seguir. A linha-chave para envio remoto é *.* @192.168.1.100:514, que envia tudo para um servidor syslog na porta padrão 514.
4. Salve o arquivo e teste a sintaxe: execute syslogd -d -f /etc/syslog.conf para iniciar o daemon em modo debug e verificar se a configuração é carregada sem erros. O modo debug imprime as regras interpretadas na saída padrão.
5. Reinicie o serviço: use service syslogd restart para aplicar a nova configuração. O comando service é o wrapper padrão do FreeBSD para scripts de inicialização em /etc/rc.d.
6. Gere eventos de teste: utilize logger -p auth.info “Teste de log de autenticacao” e depois verifique se a mensagem aparece no arquivo destinado com tail /var/log/auth.log.
7. Verifique o status do serviço e as conexões: use sockstat -4 | grep syslogd para confirmar se o daemon está escutando na porta 514 e conectado ao servidor remoto configurado.

# Backup da configuração original
cp /etc/syslog.conf /etc/syslog.conf.bak

# Abrir o arquivo para edição (use o editor de sua preferência)
ee /etc/syslog.conf

O conteúdo completo do arquivo /etc/syslog.conf com os ajustes desta aula é mostrado abaixo. Repare nos comentários explicativos que adicionamos para documentar cada seção. Os espaços e tabulações foram mantidos para exemplificar o formato aceito pelo FreeBSD.

# /etc/syslog.conf — Configuração personalizada para Monitoramento e logs no FreeBSD
# Backup criado em /etc/syslog.conf.bak
#
# Formato: facility.severity         destino
# As facilities são: kern, user, mail, daemon, auth, syslog, lpr, news,
# cron, local0-local7, etc.
# As severities em ordem decrescente: emerg, alert, crit, err, warning,
# notice, info, debug.
#
# Mensagens de emergência para todos os usuários logados
*.emerg                                                 *

# Kernel: avisos e erros críticos para o console
kern.warning                                            /dev/console

# Mensagens gerais do sistema para /var/log/messages
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages

# Logs de segurança (facilities auth e authpriv)
security.*                                              /var/log/security
auth.info;authpriv.info                                 /var/log/auth.log

# Logs de correio eletrônico
mail.info                                               /var/log/maillog

# Logs do cron
cron.*                                                  /var/log/cron

# Logs de debug completo
*.=debug                                                /var/log/debug.log

# Mensagens do daemon do sistema
daemon.info                                             /var/log/daemon.log

# Logs de FTP
ftp.info                                                /var/log/xferlog

# Envio remoto de todos os logs para servidor central (porta 514 UDP)
*.*                                                     @192.168.1.100:514

# Fim do arquivo

Após salvar o arquivo, reinicie o syslogd com o comando a seguir. A opção service executa o script em /etc/rc.d/syslogd, que por sua vez chama o daemon com os parâmetros apropriados. Se houver algum erro de sintaxe no arquivo, o daemon não iniciará e uma mensagem de erro será exibida no terminal.

# Reiniciar o daemon syslogd para aplicar a nova configuração
service syslogd restart

# Verificar se o serviço está em execução
service syslogd status

# Confirmar que as regras foram carregadas (modo debug, sem iniciar em segundo plano)
syslogd -d -f /etc/syslog.conf

Stopping syslogd.
Starting syslogd.
syslogd is running as pid 834.
off & running
  logmsg: pri 56, flags 4, from host, msg: syslogd: restart
  syslogd: restarted
  syslogd: configured with 12 rules
  rule 0: facility 0, severity 0 -> /dev/console
  rule 1: facility 24, severity 4 -> /var/log/messages
  rule 2: facility 32, severity 4 -> /var/log/security
  rule 3: facility 24, severity 6 -> /var/log/auth.log
  rule 4: facility 16, severity 6 -> /var/log/maillog
  rule 5: facility 72, severity 7 -> /var/log/cron
  rule 6: facility 0, severity 7 -> /var/log/debug.log
  rule 7: facility 8, severity 6 -> /var/log/daemon.log
  rule 8: facility 40, severity 6 -> /var/log/xferlog
  rule 9: facility 0, severity 7 -> @192.168.1.100:514

Observe na saída acima que o daemon enumerou as regras interpretadas, mostrando a facility, a severidade e o destino de cada uma. A regra 9 corresponde ao envio remoto para o endereço 192.168.1.100 na porta 514. Esse tipo de verificação é extremamente útil para confirmar que a configuração foi interpretada exatamente como planejado, evitando surpresas em produção.

Monitoramento e logs no FreeBSD: rotação e retenção com newsyslog

O newsyslog é a peça-chave para impedir que os arquivos de log cresçam sem controle e consumam todo o espaço em disco. Ele trabalha de forma independente do syslogd, sendo acionado periodicamente pelo cron a cada hora. O arquivo de configuração /etc/newsyslog.conf define para cada arquivo de log: o modo, o dono, o grupo, o número máximo de rotações, o tamanho máximo, o horário de rotação e os comandos de pós-processamento.

O formato de cada linha do newsyslog.conf é composto por campos separados por espaços ou tabulações. O primeiro campo é o caminho absoluto do arquivo de log. O segundo é o modo de permissão no formato octal (por exemplo, 644 ou 640). O terceiro é o dono e o quarto é o grupo. O quinto campo é a quantidade de backups mantidos. O sexto campo é o tamanho máximo em kilobytes ou a palavra * para rotação por tempo. O sétimo campo é o horário de rotação no formato ISO (ex: @T00 para meia-noite) ou @ seguido de intervalo em horas. Os campos opcionais seguintes são flags e comandos.

# /etc/newsyslog.conf — Configuração de rotação de logs no FreeBSD
# Formato: arquivo  modo  dono  grupo  count  size  when  flags/comandos
#
# Rotação dos logs principais do sistema
/var/log/messages               644   root  wheel  7   *    @T00  J
/var/log/security               640   root  wheel  7   1024 @T00  J
/var/log/auth.log               640   root  wheel  7   1024 @T00  J
/var/log/maillog                640   root  wheel  7   1024 @T00  J
/var/log/cron                   640   root  wheel  7   1024 @T00  J
/var/log/debug.log              640   root  wheel  3   512  @T00  J
/var/log/daemon.log             640   root  wheel  3   512  @T00  J
/var/log/xferlog                644   root  wheel  3   1024 @T00  J

# Logs de pacotes de terceiros
/var/log/nginx/access.log       640   www   wheel  14   *    @T00  JGB
/var/log/nginx/error.log        640   www   wheel  14   *    @T00  JGB

# Fim do arquivo

No exemplo acima, a flag J indica que o arquivo deve ser comprimido com bzip2 após a rotação. A flag G indica que o newsyslog deve criar o arquivo caso ele não exista, e a flag B indica que o arquivo é binário (não deve receber inserção de mensagem de status). O campo @T00 na sétima coluna define a rotação diária à meia-noite. A quantidade de backups mantidos é o quinto campo: por exemplo, 7 significa que serão guardadas sete versões antigas antes de remover a mais antiga.

Para aplicar as configurações imediatamente ou testar a rotação de um arquivo específico, utilize o comando newsyslog -F -v. A opção -F força a rotação mesmo que o arquivo não atinja o limite de tamanho, e -v ativa o modo verboso. O newsyslog também pode ser chamado com -n para simular a rotação sem realmente executar as ações, o que é excelente para depurar configurações antes de colocar em produção.

# Simular a rotação de todos os logs (não altera nada, apenas mostra o que seria feito)
newsyslog -n -v

# Forçar a rotação de um arquivo específico
newsyslog -F -v /var/log/auth.log

# Verificar o resultado da rotação
ls -lh /var/log/auth.log*

/var/log/auth.log <3Z>: size (Kb): 1 [1024] -> rotating
        /var/log/auth.log.0 <3Z> -> /var/log/auth.log.1
        /var/log/auth.log <3Z> -> /var/log/auth.log.0
        creating /var/log/auth.log
-rw-r-----  1 root  wheel     1.2K Aug 29 14:35 /var/log/auth.log
-rw-r-----  1 root  wheel     518B Aug 29 14:35 /var/log/auth.log.0.bz2

A saída mostra o processo de rotação: o arquivo atual foi renomeado para auth.log.0, o arquivo antigo auth.log.0 foi renomeado para auth.log.1, um novo auth.log vazio foi criado e o backup foi comprimido com bzip2, exibindo a extensão .bz2. Esse fluxo garante que o log ativo esteja sempre disponível para novas mensagens, enquanto as versões antigas são compactadas para economizar espaço.

Monitoramento e logs no FreeBSD: monitoramento de desempenho do sistema

Além dos logs, o administrador precisa monitorar continuamente o desempenho do hardware e dos recursos do sistema. O FreeBSD inclui um conjunto poderoso de ferramentas no sistema base que dispensam instalação de pacotes adicionais. Começaremos com o top, que fornece uma visão dinâmica dos processos em execução, uso de CPU, memória física e swap. A tecla P ordena por CPU, M por memória, q sai, e a opção -S mostra processos do sistema também.

# Exibir top ordenado por uso de CPU, incluindo processos do sistema
top -S -o cpu

# Monitorar memória virtual com amostragem de 1 segundo, 5 iterações
vmstat 1 5

# Monitorar I/O de discos com detalhes estendidos
iostat -x -t da1

# Visualizar tráfego de rede e conexões ativas
netstat -m
sockstat -4

# Painel interativo completo de estatísticas do sistema
systat -v

last pid: 19234;  load averages:  0.45,  0.32,  0.28    up 3+14:22:11  14:35:27
65 processes:  1 running, 64 sleeping
CPU:  2.1% user,  0.0% nice,  3.4% system,  0.0% interrupt, 94.5% idle
Mem: 15M Active, 127M Inact, 312M Wired, 128K Buf, 814M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME    WCPU COMMAND
19234 root          1  20    0   142M  9256K CPU0     0:00   0.42% top
  824 root          1  20    0  1280M  4132K select   0:19   0.00% syslogd
  821 root          1  20    0   136M  4608K kqread   0:05   0.00% sshd
  820 root          1  20    0   138M  4500K kqread   0:00   0.00% cron

O comando vmstat 1 5 é extremamente útil para diagnosticar gargalos de CPU, memória e I/O. A saída exibe linhas com estatísticas de tempo de execução, paginação, disco e faults. Já o iostat com a opção -x mostra métricas estendidas como throughput, latência, utilização percentual e fila de espera por dispositivo, informações cruciais para identificar discos saturados ou com problemas de latência em sistemas UFS ou ZFS.

Para rede, o netstat -m exibe estatísticas de buffers e alocação de memória da pilha de rede, ajudando a detectar exaustão de recursos, enquanto o sockstat -4 lista todos os sockets IPv4 abertos com seus respectivos processos, o que é indispensável para auditoria de portas e detecção de serviços não autorizados. O systat -v oferece um painel interativo com múltiplas telas de estatísticas, alternáveis com as teclas :disk, :vm, :net, etc., tudo em tempo real.

Se o seu sistema utiliza ZFS, o comando zpool status e o zpool iostat 1 são ferramentas de monitoramento de armazenamento de primeira linha. Para discos com pool ZFS, a observação de erros de leitura/gravação, quantidade de blocos corrompidos e tempo de scrub é essencial para evitar falhas silenciosas. Já para sistemas com discos UFS, o gstat oferece uma visualização semelhante ao iostat, mas com foco em operações por segundo e tempo de serviço por partição.

Configuração Detalhada — arquivos de sistema e integração com rc.conf

Para que os serviços de logging e monitoramento iniciem automaticamente no boot, algumas variáveis devem ser configuradas no arquivo /etc/rc.conf. O FreeBSD segue a filosofia de que todos os scripts de inicialização em /etc/rc.d verificam as variáveis do rc.conf para decidir se devem iniciar e com quais opções. Para o syslogd, a variável syslogd_enable=”YES” é o mínimo necessário, embora ela já esteja presente por padrão em instalações novas.

# /etc/rc.conf — Trechos relevantes para logging e monitoramento no FreeBSD

# Habilitar o daemon de logs
syslogd_enable="YES"

# Opções adicionais para o syslogd:
# -s  : operar em modo seguro (não abre sockets desnecessários)
# -d  : modo debug (não usar em produção)
# -T  : não sobrescrever regras com nomes de host remotos
syslogd_flags="-s"

# Habilitar rotação automática de logs pelo cron (já é padrão)
newsyslog_enable="YES"

# Monitoramento de desempenho: carregar módulos de estatísticas
# (opcional, mas recomendado para vmstat e iostat)
kld_list="coretemp"

# Fim do arquivo

A opção -s no syslogd_flags coloca o daemon em modo seguro, impedindo que ele aceite mensagens de fontes externas não autorizadas, o que é uma boa prática de segurança em servidores voltados para a internet. Em ambientes que precisam receber logs de outros equipamentos, essa opção deve ser removida, e o daemon deve ser configurado com a flag -a para especificar os hosts permitidos, como em syslogd_flags=”-a 192.168.1.0/24″.

Além do rc.conf, o arquivo /etc/syslog.d/ pode ser utilizado em versões mais recentes do FreeBSD para modularizar a configuração de logs, embora o syslogd tradicional ainda dependa do arquivo /etc/syslog.conf principal. Verifique a página de manual syslog.conf(5) para confirmar o suporte a includes em sua versão específica.

Tabela de Referência — Arquivos de Log Comuns no FreeBSD

Tabela de Referência — Comandos de Monitoramento Essenciais

Verificando a Instalação / Testando a Configuração

Após configurar o syslogd, o newsyslog e as ferramentas de monitoramento, é imprescindível validar todo o ambiente. Nesta seção obrigatória, apresentamos uma bateria de testes com os comandos de verificação e suas respectivas saídas esperadas em um sistema funcional. Execute cada etapa na ordem indicada e confira se os resultados conferem com os exemplos.

# 1. Verificar o status do serviço syslogd
service syslogd status

# 2. Confirmar que o syslogd está escutando em sockets locais
sockstat -4 | grep syslogd

# 3. Testar a geração de uma mensagem de log
logger -p auth.notice "Teste de monitoramento e logs no FreeBSD"

# 4. Verificar se a mensagem foi gravada no arquivo correto
tail -n 5 /var/log/auth.log

# 5. Testar a rotação forçada de logs
newsyslog -F -v /var/log/auth.log

# 6. Monitorar o uso de memória e CPU em tempo real
vmstat 1 3

syslogd is running as pid 834.
root     syslogd    834   3  dgram  /var/run/log
root     syslogd    834   4  dgram  /var/run/logpriv
root     syslogd    834   5  udp4   *:514                 *:*
Aug 29 14:40:00 hostname auth.notice: Teste de monitoramento e logs no FreeBSD
Aug 29 14:40:00 hostname auth.notice: Teste de monitoramento e logs no FreeBSD
Aug 29 14:40:00 hostname auth.notice: Teste de monitoramento e logs no FreeBSD
 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0   in   sy   cs us sy id
 0 0 0    412M   815M   35   0   0   0    37   0   0  120  250  180  2  3 95
 0 0 0    412M   814M   20   0   0   0    25   0   0  115  230  170  1  2 97
 0 0 0    412M   814M   18   0   0   0    20   0   0  110  225  165  1  2 97

A primeira linha da saída confirma que o daemon está em execução com o PID 834. Em seguida, o sockstat mostra os sockets abertos pelo syslogd, incluindo o socket de datagrama local /var/run/log e o socket UDP na porta 514 para recebimento de logs remotos, caso configurado. A execução do logger gerou a mensagem de teste, que apareceu três vezes no auth.log, pois o arquivo foi recriado após a rotação forçada e as mensagens de teste anterior também foram registradas. Por fim, o vmstat confirmou estabilidade do sistema com 0 processos bloqueados, baixa utilização de CPU e zero páginas de swap em uso.

Se todas as saídas corresponderem às