http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 1 of 17 11/5/2011 03:42 GrupoLinux Iniciar sessão ou Registro 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 Você está aqui: TWiki > Web GrupoLinux > AdministracaoGNULinux > ArtigoGerenciandoArquivosDeLog, create new tag Anterior Trilha D Próximo comentar Conteúdo Editar Anexar Impressão 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. 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. r3-07 Dec 2009-13:52:38 - HamiltonTarso 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 2 of 17 11/5/2011 03:42 ('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 ^ ------------ 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, V
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 3 of 17 11/5/2011 03:42 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 4 of 17 11/5/2011 03:42 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 cmdline cpuinfo devices Descricao Parâmetros de inicialização repassados para o kernel pelo gerenciador de boot Informações sobre o processador do sistema (fabricante, velocidade, etc) 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 ioports kcore meminfo modules Lista dos números de interrupção e seu respectivo dispositivo para o qual está alocado. Faixas de memória alocadas para os dispositivos (portas de memória). Contem informações sobre o conteúdo atual da memória RAM, seu conteúdo somente pode ser lido por aplicativos apropriados. Estatísticas de uso da memória Armazena o nome dos módulos atualmente carregados no sistema (equivale a execução do comando lsmod)
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 5 of 17 11/5/2011 03:42 mounts pci uptime Sistema de arquivos atualmente montados no sistema (equivale à execução do comando mount) Detalhes dos dispositivos pci do sistema 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 #lsmod Module 42900 1 [ext3] ext3 59904 1 jbd Size Used by Not tainted 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 6 of 17 11/5/2011 03:42 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 su(pam_unix)[1076]: session opened data hora servidor 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 7 of 17 11/5/2011 03:42 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.
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 8 of 17 11/5/2011 03:42 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.* daemon.* cron.* lpr.* /var/log/secure /var/log/maillog /var/log/daemon.log /var/log/cron.log /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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 9 of 17 11/5/2011 03:42 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 é
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 10 of 17 11/5/2011 03:42 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 x.log.1 x.log.2 x.log.3 Depois x.log =>x.log.1 =>x.log.2 =>x.log.3 =>deletado Passos 5o 4o 3o 2o 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 87552 Jul 11 10:45 wtmp -rw-rw-r-- 1 root root 405888 Jul 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 11 of 17 11/5/2011 03:42 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 root@outroservidor.com.br. #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 fi endscript xargs kill -HUP < /var/run/httpd.pid Note neste exemplo, que todas configurações padrões determinadas no arquivo principal /etc/logrotate.conf serão herdadas aqui. postrotate /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: /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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 12 of 17 11/5/2011 03:42 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 From Latest root tty1 Qui Jul 10 11:38:51-0300 2003 bim pts/4 200.225.73.82.in Ter Jun 24 13:15:18-0300 2003 fulano tty3 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 still logged in robson pts/3 10.1.0.5 Mon Jul 14 09:49-11:41 (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 Fri Jul 11 19:15-22:15 (02:59)
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 13 of 17 11/5/2011 03:42 revalino pts/3 10.2.0.60 Fri Jul 11 18:30-18:33 (00:02) #last -f /var/log/wtmp.1 more leandro pts/1 10.2.0.141 Mon Jun 30 21:45-21:52 (00:06) revalino pts/1 10.2.0.60 Mon Jun 30 15:01-16:34 (01:32) 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 Análise Revezamento /var/log /lastlog Traz as informações sobre o último logon de cada usuário do sistema. visualizado pelo comando lastlog. 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. 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.* #more /var/log/secure /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.
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 14 of 17 11/5/2011 03:42 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
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 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 15 of 17 11/5/2011 03:42
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 16 of 17 11/5/2011 03:42 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.
http://wiki.sintectus.com/bin/view/grupolinux/artigogerenciandoarq 17 of 17 11/5/2011 03:42 Anterior Trilha D Próximo 1.28 - Comentários Adicionar LicaoForm Titulo LicaoAnterior NivelAcima LicaoPosterior Gerenciando Arquivos de Log ArtigoGerenciandoArquivosDeLog ArtigoGerenciandoArquivosDeLog ArtigoGerenciandoArquivosDeLog Licenca LicencaCreativeCommonsBySA? DireitoAutoral Autoria Sistemas Abertos 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.