ArtigoGerenciandoArquivosDeLog < GrupoLinux < TWiki

Transcrição

1 of 17
http://wiki.sintectus.com/bin/view/GrupoLinux/ArtigoGerenciandoArq...
GrupoLinux
Iniciar sessão ou
Registro
Editar
Anexar
Impressão
r3 - 07 Dec 2009 - 13:52:38 - HamiltonTarso
Você está aqui: TWiki >
Web GrupoLinux
> AdministracaoGNULinux > ArtigoGerenciandoArquivosDeLog
, create new tag
Pular para
Busca
English
Web GrupoLinux
Criar Novo Tópico
Índice
Busca
Alterações
Notificações
Estatísticas
Preferências
Webs
BrOffice
EaD
GrupoJava
GrupoLinux
GrupoLogica
GrupoWeb
Main
Ruby
SGBD
SO
Sandbox
TWiki
Wikeditora
WikiEdu
Anterior • Trilha D
• Próximo
comentar
Lição 1 - Gerenciando Arquivos de Log
Objetivo(s):
Direitos autorais e licença: Veja notas
de direitos autorais e licença no final da
lição.
Conteúdo
1.1 Introdução
1.2 O que são Logs?
Logs são registros de eventos que têm como
objetivo fornecer informação do comportamento
do sistema. Os eventos registrados podem ser
normais, como: login de usuário, acesso à uma
página Internet, execução de um comando, etc.
Também podem ser de eventos anormais, como:
falta de espaço em disco, travamento de um
aplicativo, invasão do sistema, etc. Assim,
através da análise dos logs, o técnico pode
orientar suas ações para corrigir ou melhorar a
configuração do sistema.
1.3 Formatos de arquivos de logs
O diretório padrão dos logs é /var/log e
geralmente utiliza dois formatos de arquivos:
texto - por exemplo, /var/log/messages ou
/var/log/syslog que são visualizados com
comandos como tail.
binário - por exemplo, /var/log/wtmp. que
é visualizado com o comando específico
last.
1.1 Introdução
1.2 O que são Logs?
1.3 Formatos de arquivos de logs
1.4 Utilidade dos logs
1.5 Análise de logs: processadores
1.6 O problema de espaço
1.7 Análise de travamento
1.8 Monitorando sistemas
1.9 Análise histórica ou imediata
1.10 Diretório /proc
1.11 Análise imediata: monitoradores
1.12 Servidor de logs
1.13 Sysklogd
1.14 Logger
1.15 Formato padrão
1.16 Configurando o syslog
1.17 Centralizando os logs da rede
1.18 Gerenciando o crescimento dos logs
1.19 Conhecendo os logs do sistema
1.20 Tabelas de controle de logs
1.21 Documentação da aplicação
1.22 Logs via syslogd
1.23 Outros logs em /var/log
1.24 Links Indicados
1.25 Termos utilizados
1.26 Exercícios de Revisão
1.27 - Direitos autorais e licença
1.28 - Comentários
Efetue logon e logoff como fulano em uma console virtual - tty3, por e visualize o final do
arquivo /var/log/messages, para visualize o resultado nos arquivos /var/log/messages (ou /var/log
/syslog no Debian) e /var/log/wtmp, com os comandos tail e last respectivamente:
# tail /var/log/messages
Jul
8 01:29:41 k2 login(pam_unix)[23780]: session opened for user
fulano by LOGIN(uid=0)
Jul
8 01:30:14 k2 login(pam_unix)[23780]: session closed for user
fulano
# last -f /var/log/wtmp | more
fulano
tty3
Tue Jul
8 01:29 - 01:30
(00:00)
Note na visualização do arquivo /var/log/messages: o registro da data e hora ('Jul 8 01:29:41'); a
aplicação e seu PID que gerou o log ('login(pam_unix)[23780]') e finalmente a mensagem ('session
opened for user akira by LOGIN(uid=0)'). No arquivo binário /var/log/wtmp, visualizado pelo
comando last e opção -f temos: a informação do login do usuário ('fulano'); a console virtual
11/5/2011 03:42
2 of 17
('tty3'); a data (' Tue Jul 8'); a hora de início e fim (' 01:29 - 01:30'); e a duração ('00:00').
1.4 Utilidade dos logs
Os logs então formam o meio de comunicação do sistema, necessários para que o administrador
realize ações corretivas convenientes, conforme o ciclo:
Sistema -- geram --> logs -- são analisados pelo --> administrador
^
V
|------------ realiza ações corretivas -----------------------|
Assim, os logs podem ser utilizados para:
monitorar falta de recursos: detectar quando um recurso está escasso, - como espaço
em disco ou memória - permitindo uma ação corretiva, antes que o sistema deixe de
funcionar.
reportar problemas de segurança: notificar quando alguma tentativa de invasão ocorreu,
permitindo a melhoria da segurança do sistema antes dele ser efetivamente invadido.
registrar uso indevido do sistema: quando desejamos encontrar culpados por uma
operação indevida - como acessar sites proibidos - necessitamos de auditar o sistema
através de logs apropriados.
auxiliar a instalação de software: é comum instalarmos um aplicativo e por um erro de
configuração ele não funciona. A melhor fonte de diagnósticos de erro são os logs.
registrar dados para otimização: quando desejamos otimizar um sistema, geralmente
necessitamos de analisar um aplicativo através de seus logs ao longo de um período.
1.5 Análise de logs: processadores
Outro problema também encontrado no uso dos logs é a sua análise. Muitas vezes necessitamos
analisar não um registro específico, mas informações derivadas do processamento do conjunto,
por exemplo, estatísticas de acesso a um site.
Neste sentido, utilizamos processadores, que podem ser criados pelo próprio usuário, através de
linguagens de programção apropriadas como awk [AWKa] ou perl [PERa]; ou até aplicativos
específicos como o webalizer [WEBa], que processa arquivos de acesso à páginas Internet.
A linguagem awk é bastante simples e complementa as funcionalidades dos scripts shell; no
entanto, é classificada em um nível de complexidade intermediária comparando-se com a
linguagem perl.
O Webalizer, assim como outros processadores de log [FREa], fornecem relatórios navegáveis,
em formato HTML, rico de gráficos e tabelas. Cabe ao administrador escolher os que mais
adequarem à sua necessidade.
1.6 O problema de espaço
Um dos problemas mais comuns encontrados em servidores com grande atividade, como
provedores de acesso à Internet, é o crescimento acelerado dos logs, podendo em poucos dias
ocupar todo o espaço de disco com arquivos de logs caso não seja realizado uma atitude de
liberação de espaço.
Cabe ao administrador criar ou fazer uso de ferramentas que auxiliem na liberação de espaço,
utilizando técnicas como: divisão; deleção; compressão; e/ou envio por e-mail de arquivos. Uma
das ferramentas mais utilizadas e que provê estas funcionalidades é o logrotate, que veremos
detalhadamente em uma seção mais à frente.
1.7 Análise de travamento
Logo que um aplicativo trava, geralmente é criado um arquivo core, que consiste basicamente da
imagem da memória logo após o travamento de um aplicativo. O desenvolvedor pode então
analisar o arquivo e investigar as causas do travamento através de ferramentas apropriadas. Para
o administrador, é importante controlar o espaço ocupado por estes arquivos, pois eles podem
ser grandes, geralmente na ordem de MB. Tome o cuidado de não deletar arquivos homônimos,
11/5/2011 03:42
3 of 17
executando o comando file antes.
Procure no seu sistema por arquivos core e determine se ele realmente é um arquivo core.
# find / -name “core*”
...
/home/fulano/core
...
#file /home/fulano/core
home/fulano/core: ELF 32-bit LSB core file of 'soffice.bin' (signal
6), Intel 80386, version 1
#rm /home/fulano/core
1.8 Monitorando sistemas
1.9 Análise histórica ou imediata
Em certas situações, é interessante realizar testes com um aplicativo ao mesmo tempo que é
analisado imediatamente seu arquivo de log. Isto agiliza os testes, pois o retorno é obtido
imediatamente em vez de vasculhar o arquivo de log por resultados. Para realizar isto, podemos
automatizar o comando tail, através da opção -f, que faz com que o arquivo seja relido
continuamente, de forma automática.
Abra dois terminais gráficos (xterm) como root; no primeiro, execute o comando tail com
opção -f no arquivo /var/log/messages; no segundo, execute o comando 'su - fulano' e em seguida
observe o resultado imediato na primeira console:
na primeira console:
# tail -f /var/log/messages | grep su
na segunda console:
# su - fulano
note na primeira console:
# tail -f /var/log/messages | grep su
Jul
8 09:26:48 k2 su(pam_unix)[1076]: session opened for user fulano by root(uid=0)
1.10 Diretório /proc
Outra forma de obter informação instantânea é através dos arquivos do diretório /proc. Apesar de
ser uma forma de obter informações do sistema, não são comumente classificados como arquivos
de log, mas sim um meio onde o kernel comunica com as aplicações. Por exemplo, o arquivo
/proc/uptime fornece instantaneamente os tempos de atividade e processamento do sistema,
medido em segundos.
Consulte mais de duas vezes o conteúdo do arquivo /proc/uptime, verificando a sua
atualização contínua. Execute também o comando uptime e compare os resultados.
# more /proc/uptime
899136.31 781767.12
# more /proc/uptime
899152.23 781774.30
#uptime
10:35am up 10 days, 9:46,
5 users,
load average: 0.25, 0.25, 0.26
Note que o comando uptime, além de consultar outras fontes de informações (data e hora do
sistema e quantidade de usuários), também fornece a quantidade de tempo que o servidor está
ligado (up) de uma forma mais compreensível ('10 days, 9:46').
O diretório /proc é também diferente dos demais pois ele não é montado em uma partição do
disco, mas sim em um espaço reservado na memória. Isto é necessário para otimização do
11/5/2011 03:42
4 of 17
desempenho de entrada/saída, pois a freqüência de atualização das informações pelo kernel é
muito alta. Comprove que o diretório /proc não é montado em partição de disco, mas sim em um
sistema de arquivos próprio (proc).
# cat /etc/fstab | grep proc
proc
/proc
proc
defaults
0
0
execute 'man proc' para saber dos detalhes de cada arquivo do diretório /proc.
O diretório /proc pode ser dividido em três tipos de informações:
1) informações de processos: são identificados por diretórios de formato numérico,
como /proc/N, onde N é o PID; por exemplo, o diretório /proc/1, contém informações
específicas do serviço inet, de PID=1. Cada diretório contém informações específicas de
cada processo, como: linha de comando utilizada para invocar o processo (cmdline);
variáveis de ambiente (environ); o mapa da ocupação em memória (maps); status
detalhado tal como prioridade, PID do processo pai, etc (stat ou status).
Identifique as variáveis de ambiente do processo inet (PID=1):
#cd /proc/1
#more environ
HOME=/TERM=linuxBOOT_IMAGE=linux-CL8+
2) variáveis do sistema: são os arquivos dentro do diretório /proc/sys, que possui vários
arquivos graváveis que permitem interagir com o kernel, permitindo modificar
imediatamente seu comportamento através dos valores dos arquivos. Por exemplo, o
arquivo /proc/sys/net/ipv4/ip_forward controla se é permitido (valor=1) ou não (valor=0)
repassar pacotes de rede IP de uma interface de rede para outra.
Consulte o valor do arquivo /proc/sys/net/ipv4/ip_forward, altere-o para testar a sua permissão
de gravação:
#cd /proc/sys/net/ipv4
#more ip_forward
1
#echo “0” > ip_forward
#more ip_forward
0
3) informações gerais do sistema: são os arquivos restantes, que fornece informações
gerais do sistema, como: dispositivos, sistemas de arquivos, partições, dentre outros.
Pode variar de sistema para sistema, pois depende do kernel e dos módulos carregados.
Uma descrição de alguns dos arquivos mais comuns do /proc são apresentados abaixo:
Arquivo
Descricao
cmdline
Parâmetros de inicialização repassados para o kernel pelo gerenciador de boot
cpuinfo
Informações sobre o processador do sistema (fabricante, velocidade, etc)
devices
Números principais (majors) para os vários tipos de dispositivos utilizados pelo
kernel.
filesystems Sistemas de arquivos disponíveis, é utilizado pelo comando mount.
interrupts
Lista dos números de interrupção e seu respectivo dispositivo para o qual está
alocado.
ioports
Faixas de memória alocadas para os dispositivos (portas de memória).
kcore
Contem informações sobre o conteúdo atual da memória RAM, seu conteúdo
somente pode ser lido por aplicativos apropriados.
meminfo
Estatísticas de uso da memória
modules
Armazena o nome dos módulos atualmente carregados no sistema (equivale a
execução do comando lsmod)
11/5/2011 03:42
5 of 17
mounts
Sistema de arquivos atualmente montados no sistema (equivale à execução do
comando mount)
pci
Detalhes dos dispositivos pci do sistema
uptime
Tempo em que o sistema está ativo
Verifique o conteúdo do arquivo /proc/modules e comprove se é equivalente ao resultado do
comando lsmod:
#more /proc/modules
...
ext3
59904
1
jbd
42900
1 [ext3]
#lsmod
Module
Size
Used by
Not tainted
...
ext3
59904
1
jbd
42900
1
[ext3]
Note que exceto o cabeçalho do resultado de lsmod, o conteúdo é idêntico
Vários comandos utilizam os arquivos do /proc como fonte de informação para gerar seus
resultados, como: free, ps, pstree, top, etc.
1.11 Análise imediata: monitoradores
Como foi dito, a análise das informações fornecidas pelo sistema pode ser histórica ou imediata.
Quando a análise é imediata, realizamos um monitoramento do sistema e para isto é utilizado
sistemas monitoradores. Um dos sistemas monitoradores mais utilizados é o
Nagios [NAGa], de licença GPL, que fornece uma rica interface web para o usuário, permite
monitorar vários sistemas simultaneamente e notifica o administrador por e-mail, pager, celular,
etc.
Caso você deseje utilizá-lo, sugerimos utilizar a documentação fornecida no próprio site oficial
[NAGb].
1.12 Servidor de logs
Conforme foi explicado, cada aplicativo pode gerar seu próprio log em arquivos e formatos
diversos, dificultando a análise do conjunto. No sentido de centralizar e padronizar o formato dos
logs é que foram criados os servidores de log, que pode receber logs de qualquer aplicativo do
sistema. Iremos estudar neste capítulo o servidor de logs sysklogd, que é atualmente o mais
popular e mais utilizado como padrão nas distribuições existentes.
1.13 Sysklogd
Na verdade o sysklogd é composto pelos daemons syslogd e klogd;o segundo é dedicado ao
registro de mensagens do kernel e por padrão envia suas mensagens para o primeiro. Verifique
se os daemons syslogd e o klogd estão rodando; reinicialize (ou inicialize) estes serviços:
# ps aux | grep log
660 ?
S
0:01 syslogd -m 0
672 ?
S
0:01 klogd -f /var/log/kernel.log
#cd /etc/init.d
#./syslog stop
Desligando syslogd:
[
OK
]
# ps aux | grep log
#./syslog start
Iniciando syslogd:
[
OK
]
Como pode ser notado, geralmente ambos serviços klogd e syslogd são inseridos em um mesmo
11/5/2011 03:42
6 of 17
script init, que tem o nome syslog ou sysklogd, dependendo da distribuição. Note também neste
exemplo, como o syslog e o klogd foram inicializados, conforme cada um de seus scripts init:
'syslogd -m 0' e 'klogd -f /var/log/kernel.log', respectivamente.
A opção '-m 0' do syslogd faz com que o syslog não gere linhas marcadoras, desabilitando seu
comportamento padrão de criação automática de linhas de 20 em 20 minutos quando não há
atividade de log, veja aqui um exemplo:
# cat /var/log | grep MARK | more
Jul
6 13:01:05 serv1 -- MARK --
Jul
6 13:21:05 serv1 -- MARK --
Pessoalmente não achei nenhuma utilidade para este comportamento padrão. Há também outras
opções que podem ser consultadas através das páginas de manual: 'man syslogd' ou 'man
sysklogd'.
A opção '-f /var/log/kernel' do klogd faz com que o klogd grave seus logs em um arquivo próprio,
no nosso caso /var/log/kernel, em vez de repassar para o syslogd. Caso você deseje saber mais
das opções de execução do klogd, acesse suas páginas de manual 'man klogd'.
1.14 Logger
Um comando útil testar o funcionamento do syslogd é o logger, que também pode ser utilizado em
scripts shell. Vejamos aqui alguns exemplos de uso, outros mais complexos serão mostrados mais
adiante:
Através do comando logger, envie uma mensagem simples como fulano para o syslog.
como fulano
$logger backup concluído
como root
#tail /var/log/messages | grep script concluído
Jul
8 17:25:15 k2 fulano: backup concluído
Note que o usuário comum fulano conseguiu executar o comando logger, remetendo a mensagem
“backup concluído” para o syslogd. Curiosamente isto ocorre porque o comando logger, na
maioria das distribuições, permite execução por todos; troque a permisssão padrão caso deseje
tornar o sistema mais seguro.
Iremos ver outros exemplos mais avançados do logger na medida do progresso dos capítulos.
1.15 Formato padrão
O formato padrão das mensagens do syslogd é como segue:
Jul
8 09:26:48 k2
|data
|hora
|servidor
su(pam_unix)[1076]: session opened ...
|rótulo (tag)
| mensagem
Sendo que o único campo opcional é o rótulo (tag) que tem formato livre, mas geralmente possui
o usuário, aplicativo, ou daemon juntamente com o seu PID.
Através do comando logger, envie uma mensagem simples como fulano para o syslog, mas
passando a tag 'bkpdia' e a mensagem 'backup diario iniciado', como fulano:
$ logger -t bkpdia backup diario iniciado
como root:
# tail /var/log/messages | grep backup
Jul 8 17:54:46 k2 bkpdia: backup diario iniciado
Solicite que o logger inclua o PID do processo, como fulano
$logger -i -t bkpdia backup diario iniciado
11/5/2011 03:42
7 of 17
como root
#tail /var/log/messages | grep backup
Jul
8 18:01:52 k2 bkpdia[2908]: backup iniciado
Note que com a opção '-i' do logger, o PID foi inserido no campo rótulo do log.
1.16 Configurando o syslog
O arquivo para a configuração do syslogd é o /etc/syslog.conf, que tem como principal função
classificar os tipos de logs e direcioná-los para arquivos determinados. O sua sintaxe básica é o
seguinte:
utilidade.prioridade
destino
Onde:
utilidade (facility): classifica a função do log, ou seja, informa para que o log serve.
Lembre-se que cada arquivo de log tem uma função de orientar as ações corretivas para
uma área, como: segurança, impressão, agendamento, etc. Para especificar uma utilidade,
é necessário utilizar palavras-chaves pré-determinadas, que aqui listamos as principais,
juntamente com o seu uso: auth(segurança), authpriv (sinônimo de authpriv, as duas devem
ser usadas em conjunto), cron (agendamento), daemon (serviços em geral), kern
(mensagens do kernel), local0 a local7 (arbitrário, escolhido por qualquer aplicação), lpr
(impressão), mail (serviços de e-mail), syslog (próprio syslogd), user (mensagens geradas
por usuários) e * (todos as utilidades). Execute 'man syslog.conf' para mais detalhes.
prioridade: a prioridade do log fornece a gravidade da mensagem. Assim como a
utilidade, também utiliza palavras-chaves, que segue a seguinte ordem crescente de
prioridade: debug (depuração), info (informativo), notice (estado normal), warning (alerta),
err (erro), crit (condição crítica), alert (prestes a travar) e emerg (inutilizável). Também é
possível utilizar o asterisco (∗) para expressar todas as prioridades, ou a palavra chave
none para negar todas as prioridades. Por padrão, quando especificamos algo como
'*.info', significa todas as prioridades a partir de info; quando utilizamos o sinal igual (=),
como '*.=debug', significa somente a prioridade específica, neste caso, somente debug; e
finalmente quando utilizamos o sinal exclamação (!), como '*.!err' significa negação da
prioridade e acima, ou '*.!=debug' significa a negação da prioridade específica.
destino: é para onde será remetido o log, por padrão é um arquivo regular ou terminal,
precedidido com barra (/), mas pode ser um: computador na rede, precedido por arroba
(@); lista de usuários do sistema, com cada usuário separado por vírgula (,); todos
usuários com logon aberto, utilizando asterisco (*); e um pipe nomeado ou fifo, precedido
por barra vertical (|). Quando o destino é um arquivo precedido pelo sinal de menos (-),
significa que o syslogd irá ganhar desempenho não gravando imediatamente um log que
recebe, correndo o risco de perde-lo, caso o sistema trave logo imediatamente após.
Crie um próprio arquivo de configuração syslog.conf, seguindo os seguintes critérios abaixo
(em nível de prioridade) e realize alguns testes com cada um deles com o utilitário logger, com
argumentos '-p utilidade.nível -t criterio mensagem':
critério 1: todos os logs de aplicativos de usuários serão armazenadas exclusivamente em
/var/log/user.log - exceto para fins de depuração e não necessitarão ter gravamento
automático imediato (syncing).
critério 2: todos os logs acima de críticos (prioridade crit) serão enviados para todos os
usuários com logon aberto;
critério 3: todos os logs para fins de depuração (prioridade debug) serão armazenados
exclusivamente no arquivo /var/log/debug;
critério 4: todas as mensagens relativas à segurança, e-mail, daemons em geral,
agendamento de tarefas, impressão e kernel deverão todas armazenadas exclusivamente
no diretório /var/log e especificamente nos arquivos secure, maillog e daemon.log, cron.log,
lpr.log e kern.log respectivamente;
critério 5: vários aplicativos específicos, por padrão, fornecem em sua documentação que
geram suas mensagens de inicialização e finalização utilizando a utilidade local7, que
deverão ser armazenadas em /var/log/boot.log.
critério 6: todos os outros restantes dos logs serão armazenados em /var/log/messages.
11/5/2011 03:42
8 of 17
Segue a criação de um novo arquivo /etc/syslog.conf, substituindo o atual:
#cd /etc
#cp syslog.conf syslog.conf.orig
#vi syslog.conf
|-> baixar o arquivo com o seguinte conteúdo:
##### syslog.conf de teste
#logs de usuários sem syncing
user.*
-/var/log/user.log
#logs acima de crit remetidos p/ todos os usuários
*.crit;user.none
*
#logs para fins de depuração armazenados no arquivo /var/log/debug
*.=debug;user.none
/var/log/debug
#logs padrões em seus arquivos usuais
auth,authpriv.*
mail.*
/var/log/secure
/var/log/maillog
daemon.*
/var/log/daemon.log
cron.*
/var/log/cron.log
lpr.*
/var/log/lpr.log
#mensagens de boot em /var/log/boot.log, conf. padrão dos programas
local7.*
/var/log/boot.log
#restantes dos logs armazenados em /var/log/messages.
*.*;user.none;auth,authpriv.none;\
mail.none;daemon.none;cron.none;\
lpr.none /var/log/messages
Para sua comodidade, baixe este mesmo arquivo em: http://www.sistemasabertos.com.br/linux
/adm_sist/exemplos/syslog.conf
Note neste exemplo, que pode-se utilizar a barra inversa (\) no final de uma linha de uma regra
longa, como '*.*;user.none;auth,authpriv.none;\', no sentido de continuar na outra linha.
testes com o logger
#logger -p user.crit -t criterio1 problema crítico do usuário
#tail /var/log/user.log | grep criterio1
Jul 10 12:18:04 k2 criterio1:
problema crítico do usuário
#logger -p mail.crit -t criterio2 falha crítica no e-mail
Message from syslogd@k2 at Thu Jul 10 17:11:46 2003 ...
k2 criterio2: falha crítica no e-mail
#logger -p lpr.debug -t criterio3 depurando o sistema abc
#tail /var/log/debug | grep criterio3
Jul 10 17:20:53 k2 criterio3: mensagem para depuração
#logger -p auth.warn -t criterio4 aviso de segurança
#tail /var/log/secure | grep criterio4
Jul 10 17:23:51 k2 criterio4: aviso de segurança
#logger -p local7.err -t criterio5 erro de inicialização
#tail /var/log/boot.log | grep criterio5
Jul 10 18:00:29 k2 criterio5: erro de inicialização
#logger -p local0.notice -t critério6 aplicativo xyz inicializado
Jul 10 18:16:44 k2 critério6: aplicativo xyz inicializado
11/5/2011 03:42
9 of 17
1.17 Centralizando os logs da rede
É comum encontrar empresas com vários servidores - algumas até com dezenas, dificultando a
análise dos logs. Para resolver este problema, podemos utilizar a capacidade do syslogd de envio
de logs para outro servidor, de forma que um único servidor da rede receba os logs de todos os
demais, centralizando e facilitando a análise de logs em um único servidor.
Conforme mostrado anteriormente, para envio de logs para outro servidor, basta preceder o host
com arroba (@) no campo destino, como '@10.0.0.1' ou '@servlog.dominio.com' e para permitir a
recepção de logs de outros hosts, basta inicializar o syslogd com opção '-r'.
Configure sozinho ou com outro parceiro, dois servidores com syslogd. Um servidor (de nome
serv1) remetendo todos os seus logs para outro (IP 10.0.0.1) da rede:
no servidor serv1
#cd /etc
#mv syslog.conf syslog.conf.bkp
#vi syslog.conf
|=> inclua a linha seguinte:
*.*
@10.0.0.1
#cd /etc/init.d
#./syslog restart
Desligando syslogd:
[
OK
]
Iniciando syslogd:
[
OK
]
no servidor de número IP 10.0.0.1:
#cd /etc/init.d
#vi syslog
|=> altere a inicialização do syslog:
...
start)
...
... syslogd -m 0 -r
...
stop)
#./syslog restart
Desligando syslogd:
[
OK
]
Iniciando syslogd:
[
OK
]
no servidor serv1
#logger testando servidor de log
=>no servidor de número IP 10.0.0.1
#tail /var/log/messages | grep testando
Jul 10 19:27:18 serv1 root: testando servidor de log
1.18 Gerenciando o crescimento dos logs
Iremos agora estudar o utilitário logrotate, que é essencial em servidores com atividade alta,
permitindo liberar espaço em disco, através de revezamento (rotate) automático, compressão,
remoção ou envio por e-mail dos arquivos de log. Sua execução é geralmente realizada
automaticamente por um gerenciador de tarefas (cron), que veremos em um capítulo mais
adiante.
O revezamento consiste em criar uma série de até N arquivos adicionais além do arquivo de log,
através dos seguintes sequência:
1) o último arquivo da série é deletado. Por exemplo, caso seja uma série de 4, então o
quarto arquivo é deletado.
2) cada arquivo é renomeado para o próximo da série. Por exemplo, o terceiro arquivo
é renomeado para quarto, o segundo para terceiro e assim por diante.
3) o arquivo de log é renomeado para o primeiro da série. Por exemplo, x.log é
11/5/2011 03:42
10 of 17
renomeado para x.log.1.
4) um novo arquivo de log é criado. Este arquivo é um arquivo vazio.
Por exemplo, veja o resultado do revezamento de uma série de 3 arquivos, em uma situação
antes e depois de um revezamento, realizado em 5 passos:
Antes
x.log
Depois x.log
|=>x.log.1 |=>x.log.2 |=>x.log.3 |=>deletado
x.log.1
Passos 5o
4o
3o
x.log.2
2o
x.log.3
1o
Seu arquivo de configuração padrão é o arquivo /etc/logrotate.conf e possui uma seção de
opções padrões globais e seções para cada arquivo, com opções específicas delimitadas por
chaves ({}).
Analise o seu arquivo /etc/logrotate.conf - caso algumas opções de seu arquivo não sejam
citadas aqui neste exemplo, consulte as páginas do manual ('man logrotate'):
#more /etc/logrotate.conf
weekly
rotate 4
create
errors root
#compress
include /etc/logrotate.d
/var/log/wtmp {
monthly
create 0664 root root
rotate 4
}
/var/log/maillog {
weekly
create 0644 root root
rotate 4
postrotate
/usr/bin/killall -HUP syslogd
endscript
}
...
Note neste exemplo, as seguintes opções padrões globais:
weekly - critério para revezamento dos logs baseado em tempo , ou seja, somente
ocorrerá revezamento caso a data de criação do arquivo atual for mais antiga que uma
semana. Outros valores possíveis são: daily (diário), monthly (mensal).
rotate 4 - determina a quantidade de arquivos para revezamento, ou seja, neste caso,
teremos até 4 arquivos na série, como: arquivo.log.1 arquivo.log.2 arquivo.log.3
arquivo.log.4.
Caso o seu sistema já tenha o logrotate em funcionamento, liste diretório /var/log e escolha um
arquivo com arquivos de log de revezamento, observando também o período de tempo decorrido
de um arquivo para outro:
#ls -l /var/log/wtmp*
-rw-rw-r--
1 root
root
-rw-rw-r--
1 root
root
405888 Jul
87552 Jul 11 10:45 wtmp
1 02:42 wtmp.1
-rw-rw-r--
1 root
root
543744 Jun
1 00:48 wtmp.2
-rw-rw-r--
1 root
root
465408 May
1 01:46 wtmp.3
-rw-rw-r--
1 root
root
317568 Mar 31 22:16 wtmp.4
Note nesta listagem que o arquivo escolhido é o /var/log/wtmp, que provavelmente possui um
revezamento mensal, com possivelmente 4 arquivos de revezamento (rotate 4).
create - esta opção determina que o arquivo vazio de log será recriado logo após algum
eventual revezamento.
errors root - determina para qual usuário será enviado um e-mail caso ocorra algum erro
11/5/2011 03:42
11 of 17
de revezamento. Um erro que ocorre com frequência é quando o arquivo de log não existe,
porém pode ser desabilitada através da opção missingok (faltando ok). Você pode utilizar
um e-mail para outro servidor, como [email protected].
#compress - comprime os arquivos da série logo após o revezamento. Neste nosso caso,
esta opção está comentada com cerquilha (#), ou seja, assume o valor padrão
nocompress, não comprimindo os arquivos da série.
include /etc/logrotate.d - todos arquivos de configuração no diretório indicado são
incluídas neste arquivo. Por exemplo, todos arquivos no diretório /etc/logrotate.d serão
processados pelo logrotate, como ftpd (servidor ftp), cron (agendador de tarefas), apache
(servidor de páginas web), dentre outros. Assim, é possível criar arquivos adicionais, cada
um com um conjunto de seções específicas para os arquivos de log de um aplicativo
específico. Por exemplo, um arquivo para revezar os arquivos do servidor web apache /etc/logrotate.d/apache - pode ter o seguinte conteúdo:
/var/log/httpd/access_log {
missingok
}
/var/log/httpd/error_log {
missingok
postrotate
if [ -r /var/run/httpd.pid ]; then
xargs kill -HUP < /var/run/httpd.pid
fi
endscript
}
Note neste exemplo, que todas configurações padrões determinadas no arquivo principal
/etc/logrotate.conf serão herdadas aqui.
/var/log/wtmp - note nesta linha a abertura de uma seção de arquivo, simplesmente
informando o nome do arquivo, como seu caminho completo seguido de um bloco de
opções delimitado por chaves ({ bloco}).
monthly - note que aqui a opção local específica para o arquivo sobrepujou a opção
weekly global.
create 0664 root root - aqui é mostrado que além de criar um arquivo de log vazio logo
após o revezamento, define também as suas permissões (0644) e o usuário (root) e grupo
(root) donos.
postrotate... - define uma sequência de comandos que serão executadas pelo
interpretador de comandos padrão, logo após o revezamento. O bloco de código a ser
executado é delimitado com as palavras-chave postrotate e endscript. Caso você queira
executar antes do revezamento, use a diretiva prerotate. No nosso caso temos, um ótimo
exemplo:
...
postrotate
/usr/bin/killall -HUP syslogd
endscript
...
Significa que o comando '/usr/bin/killall -HUP syslogd' será executado logo após o revezamento.
Este comando, dentre outros procedimentos, faz com que o syslogd feche e reabra todos os
arquivos de log abertos. Isto é essencial para o funcionamento correto do logrotate, pois uma das
suas últimas ações é renomear o arquivo de log de x.log para algo como x.log.1, que
provavelmente pode antes ter sido aberto pelo syslogd e que se ainda continuar aberto, fará com
que o syslogd armazene erroneamente seus logs no arquivo x.log.1, em vez do novo arquivo x.log.
1.19 Conhecendo os logs do sistema
1.20 Tabelas de controle de logs
Na administração de um servidor, surgem várias dúvidas na análise dos logs, tais como: Como
11/5/2011 03:42
12 of 17
interpretar e para que serve o arquivo de log x.log? Quais logs e como auditar o acesso para o
aplicativo xyz? De um lado, desejamos saber a origem e a função das informações de um arquivo
de log; e por outro, necessitamos saber quais logs um aplicativo gera.
No sentido de organizar estas informações, sugerimos criar e levantar informações sobre os logs
de seu sistema e organizá-los em várias tabelas, uma para cada aplicação originadora de logs,
com os seguintes campos: arquivo de log (onde é armazenado?), descrição (o que é e para que
serve?), análise (como está sendo analisado?) e configuração do revezador (como o seu espaço
em disco está sendo tratado?). Assim, este conjunto de tabelas de controle de logs se torna uma
ótima fonte de informação para o administrador do sistema, que pode manter um controle melhor
através do conhecimento sistematizado do servidor.
Veremos a seguir, como obter informações de logs a partir da documentação da aplicação, do
servidor de logs syslogd e dos arquivos em /var/log.
1.21 Documentação da aplicação
Iremos exemplificar como obter informações de logs a partir do aplicativo login, procurando saber
quais e funções dos logs que ele gera, sua análise e seu tratamento de espaço em disco. Outros
aplicativos seguem uma investigação semelhante. Consulte a documentação da aplicação login e
identifique seus arquivos de log, descreva cada um deles e também descubra como ele é
analisado e revezado.
#man login
|=> gera os arquivos de log lastlog, utmp e wtmp
#man lastlog
|=> o visualizador é de mesmo nome: lastlog
#lastlog
...
Username Port
root
tty1
bim
pts/4
fulano
tty3
From
Latest
Qui Jul 10 11:38:51 -0300 2003
200.225.73.82.in Ter Jun 24 13:15:18 -0300 2003
Seg Jun 23 15:56:07 -0300 2003
silvia
**Never logged in**
...
Note na saída do comando lastlog: o arquivo lista os nomes de usuário pelo login em ordem de
UID (root tem UID=0); o usuário bim efetuou logon de uma estação externa (200.225.73.82) e os
usuários root e fulano por uma console local (tty1 e ty3, respectivamente); e que a usuária silvia
ainda não efetou nenhum login.
#man utmp
|=> informações de quem está conectado, seu visualizador é o who
#who
akira
tty1
Jul 15 09:33
leandro
pts/0
Jul 15 10:13 (10.1.0.5)
adriano
pts/1
Jul 15 10:31 (200.193.76.1)
#who /var/run/utmp
akira
tty1
Jul 15 09:33
leandro
pts/0
Jul 15 10:13 (10.1.0.5)
adriano
pts/1
Jul 15 10:31 (200.193.76.1)
Note que o comando who, pode ser executado isoladamente, visualizando o arquivo padrão; ou
passando como parâmetro um arquivo determinado.
#man wtmp
|=> informações de quem conectou, seu visualizador é o last
#last | more
akira
pts/4
200.101.122.249
Mon Jul 14 09:57
robson
pts/3
10.1.0.5
Mon Jul 14 09:49 - 11:41
still logged in
(01:51)
adriano
pts/1
10.1.0.25
Mon Jul 14 08:00 - 08:02
(00:02)
leandro
pts/0
200-181-048-108. Mon Jul 14 07:33 - 12:29
(04:56)
akira
pts/3
10.2.0.60
(02:59)
Fri Jul 11 19:15 - 22:15
11/5/2011 03:42
13 of 17
revalino pts/3
10.2.0.60
Fri Jul 11 18:30 - 18:33
(00:02)
10.2.0.141
Mon Jun 30 21:45 - 21:52
(00:06)
10.2.0.60
Mon Jun 30 15:01 - 16:34
(01:32)
...
#last -f /var/log/wtmp.1 | more
leandro
pts/1
revalino pts/1
...
Note que o last, mostra as sessões de logon, listando as mais recentes para as mais antigas,
com: login; console; número IP, caso seja remoto; data; hora inicial e final; e duração. Caso o
usuário esteja com a sessão aberta, é mostrado a mensagem “still logged in”. Note no segundo
exemplo do comando last, que é também possível passar um arquivo como parâmetro; neste
nosso caso, é um arquivo de revezamento, que faz parte do mês anterior (junho) ao arquivo atual
de log (julho).
Através da análise desta documentação, podemos então preencher a tabela da aplicação login. O
revezamento é hipotético:
Tabela de controle de log da aplicação login:
Arquivo de
log
Descrição
/var/log
/lastlog
Traz as informações sobre o
visualizado pelo
último logon de cada usuário do
comando lastlog.
sistema.
Não é necessário, pois
não cresce regularmente
/var/run/utmp
Contém informações de quem
está conectado.
visualizado pelo
comando who.
Desnecessário, pois não
cresce
/var/log/wtmp
Contém informações de
sessões atuais e realizadas.
visualizado pelo
comando last.
Mensal, com 4 arquivos.
Análise
Revezamento
1.22 Logs via syslogd
Para colher mais informações sobre seus logs, além da documentação de cada aplicativo, você
também pode encontrar informações no arquivo de configuração do syslogd: /etc/syslog.conf. O
syslogd classifica e grava os logs que lhe são repassados; conforme já vimos no nosso exemplo
anterior, os arquivos do diretório /var/log, como user.log, debug, secure, maillog, daemon.log,
cron.log, lpr.log, boot.log e messages, foram configurados para receber mensagens de qualquer
aplicativo, que repassem mensagens classificadas para: usuário, depuração, segurança, e-mail,
serviço, agendamento, impressão, inicialização e outros, respectivamente. No nosso caso, estes
arquivos de log pode auxiliar a identificar várias aplicações geradoras de log, bastando para isto
verificar o campo tag do log.
Analise algum arquivo de log do syslogd e identifique sua aplicação de origem.
#cat /etc/syslog.conf | grep secure
auth,authpriv.*
/var/log/secure
#more /var/log/secure
...
Jul 14 09:45:32 k2 su(pam_unix)[3469]: authentication failure;
logname=fulano uid=500 euid=0 tty= ruser= rhost= user=root
Jul 14 09:45:38 k2 su(pam_unix)[3611]: session opened for user root by
fulano(uid=500)
...
Note que o arquivo de log /var/log/secure trata das utilidades auth e authpriv, para todas as
prioridades (*), conforme pode ser visto na linha do arquivo /etc/syslog.conf. No campo tag (quinto
campo) da primeira linha de log, podemos identificar a aplicação, arquivo de biblioteca utilizada e
PID do processo que gerou o log: su, pam_unix e 3469, respectivamente. Note também que o su
pode criar vários tipos de mensagens, conforme a variação da segunda linha, com sintaxes
variadas e que a interpretação depende de sua documentação específica. Nota: o arquivo de
biblioteca pam_unix utilizado pelo su será estudado em uma outra publicação voltada para
segurança.
11/5/2011 03:42
14 of 17
Segue um exemplo de tabela de controle de log para o comando su, com análise e revezamentos
hipotéticos.
Tabela de controle de log da aplicação su (via syslogd):
Arquivo
de log
Descrição
Análise
Revezamento
/var/log
/secure
Registra execução do comando bem
sucedidos e mal-sucedidos, com detalhes
como: usuário e UID atuais; terminal,
usuário novo, etc.
Não está sendo
analisado
regularmente.
semanal, 4
arquivos.
1.23 Outros logs em /var/log
Para completar nossas tabelas de controle de log, o administrador deve vasculhar por todo os
arquivos e diretórios a partir de /var/log, buscando a aplicação de origem. Além do comando man,
você poderá descobrir informações através do gerenciador de pacotes (rpm - Red Hat ou dpkg Debian)
Analise alguns arquivos de log do diretório /var/log e identifique a aplicação de origem:
investigando somente arquivos de log não estudados
#ls /var/log/
...
XFree86.0.log
kdm.log
xferlog
httpd/
...
investigando a origem do arquivo XFree86.0.log
#man XFree86
|=> buscar pela palavra-chave “log”
Note que este arquivo faz parte dos logs do servidor XFree86 (Gráfico), conforme a
documentação, o valor '0' refere-se ao número da tela (display), que iremos estudar com mais
detalhes em capítulo mais adiante.
investigando a origem do arquivo kdm.log
#rpm -qi kdm
...
Gerenciador de login em modo gráfico do KDE...
...
Note que o kdm.log é o arquivo de log do gerenciador de login em modo gráfico do KDE - que
veremos em outro capítulo.
investigando a origem do arquivo xferlog
#man xferlog
...
...contains
logging information from the FTP server daemon...
...
Note que existe uma página de manual para este arquivo, e que se trata de um arquivo de log do
servidor FTP, para transferência de arquivos.
investigando a origem do diretório httpd
#rpm -qf /var/log/httpd
apache-...
#rpm -qi apache
11/5/2011 03:42
15 of 17
...O servidor web Apache...
Aqui podemos ver que o diretório /var/log/httpd e seus arquivos de log internos fazem parte do
pacote de software apache.
Cada um destes arquivos exemplificados aqui possui sintaxe e formatos que serão estudados
em outros momentos, quando for estudar a aplicação específica.
1.24 Links Indicados
[AWK] - Gnu Awk - Implementação da linguagem de processamento de texto
a. http://www.gnu.org/software/gawk/gawk.html
Awk é uma das linguagens mais apropriadas para criação de processadores de
logs.
[FRE] - Diretório System/Logging do Freshmeat - Localizando aplicativos para log
a. http://freshmeat.net/browse/148/?topic_id=148
Este é o diretório do localizador Freshmeat que contém dezenas de aplicativos
voltados para log.
[LOG] - Logrotate - revezador de logs
a. http://packages.qa.debian.org/l/logrotate.html
Não encontramos seu site oficial, mas neste site [a], você pode obter os códigosfontes mantidos por uma equipe de voluntários da distibuição Debian.
[NAG] - Nagios - Monitorador de sistemas com interface web
a. http://www.nagios.org
b. http://nagios.sourceforge.net/docs/1_0/toc.html
Este é um dos monitoradores de sistemas mais utilizados, com uma rica interface
web de usuário (WUI), que notifica administradores por e-mail e escalável para
monitorar vários hosts e sistemas. Seu site oficial (a) fornece uma documentação
completa (b).
[PERL] - Perl - Linguagem geral
a. http://www.perl.orgPerl é uma das linguagens mais utilizadas para scripting no
Linux, é muito utilizada em processadores de logs, porém mais complexa que Awk.
[SYS] - Sysklogd - servidor de logs
a. http://www.ibiblio.org/pub/Linux/system/daemons/
O sysklogd ou syslogd não possui site oficial, somente um local [a] onde se pode
baixar seus fontes.
[WEB] - Webalizer - Processador de logs de acessos à Internet
a. http://www.mrunix.net/webalizer/
O Webalizer é um dos processadores de logs mais populares que gera estatísticas
de acesso à Internet.
1.25 Termos utilizados
log
é um registro de um evento que tem como objetivo fornecer informação do comportamento
do sistema.
arquivo de log
é o arquivo onde os logs são armazenados.
revezamento de log
é o processo cíclico de dividir os logs em uma série de períodos de tempo (diário, semanal
ou mensal), deletando o mais antigo, alterando a ordem de cada um para o próximo da
série e criando um novo arquivo de log vazio, no sentido de preservar o espaço em disco.
Um bom exemplo é o sofware logrotate
monitorador
é o software que realiza o monitoramento de eventos instantâneos do sistema. Um bom
exemplo é o monitorador Nagios [NAGa].
visualizador de log
é um software que permite a visualização de arquivos de logs em formato binário. Um bom
exemplo é o comando last, que visualiza o arquivo binário /var/log/wtmp.
processador de log (log processor)
é um sofware que geralmente processa uma grande quantidade de logs, gerando
11/5/2011 03:42
16 of 17
estatísticas ou informação mais fácil de análise, como gráficos e tabelas. Um bom exemplo
é o webalizer [WEBa], que processa arquivos de log de servidores de páginas Web.
servidor de log (log server)
é um servidor que é dedicado a receber logs de aplicações, armazenando em arquivos
específicos, de acordo com uma classificação pré-determinada. Um bom exemplo é o
syslogd [SYSa].
utilidade (facility)
é a classifica a função do log, ou seja, informa para que o log serve. Também é descrito
em algumas documentações como o subsistema (parte essencial do sistema).
servidor de logs da rede
é o servidor de log configurado para receber os logs de outros servidores de log da rede,
no sentido de centralizar e facilitar o processamento e análise de logs da rede como um
todo.
1.26 Exercícios de Revisão
1. o que são logs e para que servem?
2. Por que que os logs devem ficar dentro do diretório /var? Cite duas razões para criar o
diretório /var em uma partição separada.
3. como resolver o problema de espaço crescente dos arquivos de logs?
4. Para que serve os processadores de log?
5. O conteúdo do diretório /proc pode ser considerado arquivo de log? Cite 3 arquivos e descreva
a função de cada um.
6. É possível como usuário comum criar arquivos em algum subdiretório do /proc? E o superusuário? Qual a finalidade deste tipo de permissão? E a alteração do conteúdo de arquivos, é
possível?
7. Para que serve os monitoradores de sistema?
8. O que é utilidade (facility) para o syslogd?
9. Descreva a linha de configuração do syslogd para:
a) obter logs do kernel e armazená-los em /var/log/kernel.log
b) enviar todos os logs do syslogd para outro servidor, de número IP 10.0.0.2
c) mostrar todas mensagens de nível warning (somente) para todos os usuários conectados
d) mostrar todas mensagens de nível crit acima para todos o arquivo /var/log/crit.log
10. Para que serve o comando logger? Crie 3 exemplos demonstrando várias opções de sua
sintaxe.
11. Demonstre como o utilitário logrotate poderia ser configurado para revezar (rotate) o arquivo
/var/log/messages, diariamente, com permissões 0600, dono root e comprimido após
revezamento. Explique também como e porque o syslogd deve ser recarregado (sinal HUP).
12. Por que certas aplicações não aparecem nos arquivos de log do syslogd, já que ele é o
servidor de logs?
13. Quais são os formatos dos arquivos /var/log/lastlog, /var/log/wtmp e /var/run/utmp? Qual são
os comandos que apresentam o seus conteúdos?
1.27 - Direitos autorais e licença
Autor(es): Marcelo Akira Inuzuka
Direito Autoral: Copyright © Sistemas Abertos
Licença: Esta obra está licenciada sob uma Licença Creative Commons.
11/5/2011 03:42
17 of 17
Anterior • Trilha D
• Próximo
1.28 - Comentários
Adicionar
LicaoForm
Titulo
Gerenciando Arquivos de Log
LicaoAnterior
ArtigoGerenciandoArquivosDeLog
NivelAcima
LicaoPosterior
Licenca
LicencaCreativeCommonsBySA ?
DireitoAutoral
Sistemas Abertos
Autoria
Marcelo Akira Inuzuka
PreRequisitos
SoftwareUtilizado
Objetivo
OrdemPadrao
1
TrilhaPadrao
D
Editar | Anexar | Impressão | Texto Puro | Referências: Web , Global | Histórico:
r3 < r2 < r1 | Mais ações de tópico
Copyright © 2003 - 2011, pelos autores colaboradores. Todo o conteúdo desta página pode ser utilizado segundo os termos da
Licença Creative Commons: Atribuição, Uso não Comercial e Permanência da Licença, salvo disposição em contrário indicada de
forma explícita no tópico correspondente.
11/5/2011 03:42

ArtigoGerenciandoArquivosDeLog < GrupoLinux < TWiki

Transcrição

Documentos relacionados

LOG IN Patrícia Sousa 02 May – September 2015 ROSA ET AL

MATEMÁTICA - UFJF/SIGA

Carta de apresentação - Logistica Cargo

Método AASHTO-93 - departamento de transportes da ufpr

Tutorial sobre dB - decibel

Ficha Técnica

Aditamento 16 - CCOMGEx

WhatsUp Event Log Management Suite

resoluções ufrgs mat 2010

Presente no Brasil há mais de 35 anos, a Parker Hannifin Divisão