O verdadeiro grande irmão - PDF
Download "O verdadeiro grande irmão"
Ilda Franco Coimbra
1 CAPA Vigilância de sistemas O verdadeiro grande irmão O versátil Nagios monitora sua rede através de plugins, e emite alertas antes que haja problemas com máquinas e serviços. Aprenda em profundidade como instalar, usar e gerenciar esse ícone do monitoramento de redes. por Julian Hein Contatos Membro Grupo de Contatos Notificação de Grupos de máquinas Algumas soluções avançadas de monitoramento de redes são vendidas por milhares de reais, e valem o investimento caso sejam capazes de manter a rede de uma empresa funcionando sem interrupções. Porém, se o objetivo for uma ferramenta versátil e confiável que informe o administrador sobre eventos na rede, sem no entanto estourar o orçamento, a ferramenta livre de monitoramento Nagios pode ser a solução. De acordo com o site do Nagios, a proposta desse programa é...informar ao administrador os problemas de rede antes que seus clientes, Comando de notificação de máquina Comando de notificação de serviço Membro de Notificação de serviço Notificação de máquina Notificação de acesso Comandos Máquinas Períodos de tempo Serviços Figura 1 Os arquivos de confi guração do Nagios freqüentemente referem-se a outros arquivos de confi guração. usuários finais ou chefes o façam. O programa monitora as máquinas da rede, verificando sintomas de possíveis problemas. Pode-se usá-lo para monitorar serviços de rede, recursos das máquinas (como carga do processador e espaço disponível em disco) e fatores ambientais, como a temperatura na sala dos servidores. O Nagios é facilmente extensível pode-se fazê-lo monitorar quase todos os problemas de rede potenciais. É possível exibir sua saída em um gráfico ou numa tabela HTML. Até mesmo alertas podem ser enviados através dele, caso apareça algum problema. O Nagios não é exatamente uma solução de monitoramento completa, mas sim um daemon que gerencia o processo de monitoramento (figura 1). A configuração do programa define as máquinas e serviços que ele deve monitorar, e programas pequenos e independentes, conhecidos como plugins, obtêm e retornam as informações de status. Vários plugins pré-definidos estão disponíveis no site, e também é possível criar os seus próprios. As máquinas e serviços monitorados pelo Nagios são todos definidos através dos arquivos de configuração do software. Esses arquivos contêm ainda configurações do daemon do programa propriamente dito, assim como informações sobre os contatos que receberão os alertas dele. Instalação No momento da redação deste artigo, a versão estável ideal para redes pequenas e médias mais atual do Nagios era a 2.7. Já para monitorar grandes redes, com 300 ou 400 máquinas, pode ser mais interessante experimentar a próxima versão, 3.0, que promete grandes avanços em desempenho, principalmente em ambientes avantajados. É possível baixar o Nagios a partir da página do projeto [1]. No entanto, muitas distribuições Linux, como Debian [2], Fedora, Red Hat Enterprise e Gentoo incluem uma versão do programa, e pode-se baixar os pacotes do Suse a partir dos populares mirrors FTP. Muitos usuários acham mais fácil compilar o progra- 32
2 Nagios CAPA ma a partir do código-fonte, pois isso permite uma instalação mais rápida de patches de segurança. Para compilar seu próprio Nagios, é necessário instalar os pacotes apache, apache2, libgd, libjpegdevel e openssl-devel, incluindo suas dependências. Os comandos a seguir preparam o servidor para a instalação: #useradd nagios #groupadd nagios #mkdir /usr/local/nagios #chown nagios:nagios #/usr/local/nagios #useradd nagcmd #groupmod -A nagcmd www-data #groupmod -A nagcmd nagios A etapa a seguir descompacta e instala o código-fonte: #tar zxvf nagios-2.7.tar.gz #cd nagios-2.7 #./configure --with-command- group=www-data #make all O comando./configure -help mostra um panorama dos parâmetros disponíveis para a compilação. Após terminá-la, pode-se instalar o aplicativo digitando-se make install. Outros comandos make instalam um script de inicialização, um exemplo de configuração e um pipe para comunicação entre as interfaces web e o daemon: #make install-init #make install-config #make install-commandmode O pacote do Nagios propriamente dito não contém plugins, sendo necessário instalá-los separadamente. É possível baixá-los a partir do site [1]. A versão dos plugins é a atual. Entretanto, vários plugins não poderão ser compilados, a menos que sejam especificados determinados arquivos de cabeçalho ou bibliotecas clientes instaladas no sistema. Além disso, alguns plugins só estão disponíveis como scripts Perl, ou estão Exemplo 1: Configuração do objeto Timeperiod 01 define timeperiod { 02 timeperiod_name nonworkhours 03 alias outside working hours 04 monday 00:00-09:00,17:00-24:00 05 tuesday 00:00-09:00,17:00-24:00 06 wednesday 00:00-09:00,17:00-24:00 07 thursday 00:00-09:00,17:00-24:00 08 friday 00:00-09:00,17:00-24:00 09 saturday 00:00-24:00 10 sunday 00:00-24:00 11 } localizados no subdiretório contrib do pacote do plugin. Será necessário copiar esse tipo de plugin para /usr/local/nagios/libexec. Configuração O arquivo central de configuração, /usr/local/nagios/etc/nagios.conf, contém configurações globais do daemon do programa. Um arquivo de configuração de exemplo é gerado automaticamente quando se compila os binários. Quando se utiliza uma versão empacotada do software, ou quando a versão foi préinstalada no sistema, o arquivo de configuração deve estar localizado nos diretórios do Nagios (veja a seção Arquivos de configuração, mais adiante, para mais informações sobre arquivos de exemplo). O arquivo de configuração contém mais opções de configuração do que este artigo pode Quadro 1: Objetos do Nagios cobrir. A documentação completa do arquivo de configuração está disponível em [3]. Uma das configurações mais importantes nesse arquivo de configurações globais é uma referência ao(s) arquivo(s) de definição de objetos que será usado pelo programa: cfg_file = nome_do_arquivo O arquivo de definição de objetos contém a maioria das informações específicas que descrevem as máquinas e serviços a serem monitorados. Dependendo do tamanho e da complexidade da rede em questão, pode ser interessante espalhar essas informações de objetos ao longo de diversos arquivos. Nesse caso, é possível usar a diretiva de configuração cfg_file múltiplas vezes, ou aplicar a diretiva cfg_dir O Nagios necessita de ao menos uma entrada de configuração para os seguintes objetos: Timeperiods : períodos de tempo para monitoramento e notifi cação; Commands : checagens de monitoração e notifi cação; Contacts : contatos e s; Contactgroups : grupos de contatos; Hosts : dispositivos e suas confi gurações; Hostgroups : grupos de hosts; Services : confi guração de serviços de monitoramento. Os seguintes objetos não são estritamente necessários, mas são oferecidos como opções de confi guração estendidas: Servicegroups : grupos de serviços monitorados; Dependencies : defi nição de dependências entre máquinas ou serviços; Escalations : regras de escalação para notifi cações; ExtendedInformation : confi gurações estendidas para a interface web. Linux Magazine #31 Junho de
3 CAPA Nagios Exemplo 2: Definição de comando 01 define command { 02 command_name check_smtp 03 command_line $USER1$/check_smtp -H $HOSTADDRESS$ -p $ARG1$ -w $ARG2$ -c $ARG3$ 04 } Exemplo 3: Contatos no Nagios 01 define contact { 02 contact_name jdoe 03 alias Jon Doe 04 service_notification_period nonworkhours 05 host_notification_period nonworkhours 06 service_notification_options w,u,c,r 07 host_notification_options d,u,r 08 service_notification_commands notify-by- 09 host_notification_commands host-notify-by } Exemplo 4: Definição de Host 01 define host { 02 host_name linux1 03 alias Linux Server 1 04 address parents main-switch 06 check_command check-host-alive 07 max_check_attempts 5 08 check_period always 09 contact_groups linux-admins 10 notification_interval notification_period always 12 notification_options d,u,r 13 } Exemplo 5: Configuração de checagem de serviço 01 define service { 02 service_description smtp check 03 host_name linux1 04 check_command check_smtp!25!10!20 05 max_check_attempts 3 06 normal_check_interval 5 07 retry_check_interval 1 08 check_period always 09 notification_interval notification_period always 11 notification_options w,c,r 12 contact_groups linux-admins 13 } para especificar um diretório com os arquivos de definição de objetos: cfg_dir = nome_do_diretorio Essencialmente, um objeto do Nagios é qualquer elemento que o programa precise conhecer, como um serviço que deva ser monitorado, um comando a ser executado, uma máquina em operação na rede ou um contato selecionado para receber notificações em caso de emergências. O quadro 1 lista alguns dos possíveis objetos no arquivo de definição de objetos. O site oferece uma descrição completa de objetos pré-definidos[4]. A seguir estão descritos alguns dos mais importantes. As configurações de Timeperiod (período de tempo) definem quando monitorar ou notificar. O objeto Timeperiod mostra as informações de período de tempo (exemplo 1). A propriedade mais importante associada a ele é timeperiod_name, que é consultada por várais outras funções de configuração do Nagios. A interface web utiliza o apelido estendido (extended alias name). Valores de tempo individuais sempre referemse a um dia da semana. É preferível usar um arquivo de configuração separado para períodos de tempo, como /usr/local/ nagios/etc/objects/timeperiods.cfg. Inicialmente, serão necessárias três definições das situações mais comuns, como por exemplo, always, workhours e nonworkhours. O Nagios refere-se a qualquer tipo de definição combinada que chame um programa ou script de shell como um comando. No exemplo 2, o objeto de comando manda-o chamar o plugin check_ smtp com parâmetros específicos. $HOSTADDRESS$ refere-se a uma macro que recebe os dados apropriados ao ser chamada. O parâmetro de plugin -p significa o número da porta SMTP, e -w e -c introduzem os limites WARNING e CRITICAL. A informação passada para o plugin depende de qual esteja sendo usado. O monitoramento HTTP exige parâmetros como o nome do servidor, caminho, nome do usuário e senha, enquanto uma verificação por ping apenas requer um endereço IP. A forma mais fácil de descobrir quais parâmetros são necessários para um plugin do Nagios é executar o plugin com o parâmetro --help. O programa define as pessoas e endereços de contato com o objeto Contacts (veja o exemplo 3). Os contatos são usados principalmente em caso de problemas, mas também são utilizados para atribuir privilégios de acesso à interface web. 34
4 Nagios CAPA Quadro 2: Monitoramento de servidores Windows com o Nagios Obviamente o Nagios oferece várias soluções para monitorar servidores Windows. Além do NRPE, que possui uma versão para Windows, o NsClient faz referência ao nome NetSaint, que era como o Nagios se chamava até O NsClient++ é um sucessor que combina as funcionalidades das duas alternativas em um único agente. A instalação é extremamente simples: após descompactar o arquivo ZIP, só é necessário copiar os arquivos para um local adequado no servidor Windows, como C:\Arquivos de Programas\NsClient, e modificar as configurações presentes para refletirem as exigências locais. Em particular, é necessário ativar os módulos individuais no início do arquivo de configuração. Feito isso, o administrador do Windows precisa reiniciar o serviço através do Iniciar Executar, digitando C:\Arquivos de Programas\NsClient++ /install e, em seguida, net start nsclient++. Como o agente contém ambos seus antecessores, é possível utilizar qualquer um dos dois plugins no servidor Nagios, ou seja, check_nt ou check_nrpe. O primeiro possui valores para os parâmetros CLIENTVERSION, CPULOAD, UPTIME, MEM-USE, USE- DDISKSPACE, SERVICE-STATE e PROCSTATE, além de todos os contadores PerfMon do Windows. Uma chamada para consultar o status de um serviço do Windows é assim:./check_nt -H <endereço_da_máquina> -p <porta> -s <senha> -v SERVICESTATE -l <serviço> A forma mais fácil de se descobrir o nome dos serviços consultados no Windows é através das propriedades do gerenciador de serviços do Windows, que fica em Iniciar Administração Serviços. Enquanto a maioria dos outros parâmetros é auto-explicativa, os contadores de performance, ou performance counters, precisam de alguma explicação. O monitor de desempenho do Windows é uma interface central para valores de desempenho. Os administradores podem usá-lo tanto para consultar dados internos de desempenho do Windows quanto para dados de várias outras aplicações do servidor, como o Exchange Server ou o SQL Server. Para isso, a sintaxe é: #./check_nt -H <endereço_da_máquina> -p <porta> -v COUNTER -l \\Performanceobject(Instance)\\Indicador O valor de retorno pode ser reformatado para a saída no plugin. O exemplo 3 é o primeiro relacionado a um objeto definido com outro objeto: por exemplo, nonworkhours é definido no objeto Timeperiods (exemplo 1). notify-by- e host-notify-by- representam comandos que o Nagios utiliza para passar mensagens. Para evitar a necessidade de listar grandes números de contatos individuais, pode-se acrescentar os contatos aos grupos: define contactgroup { contactgroup_name linux-admins alias Linux administrators members jdoe,mtestmann,wadmin } Qualquer dispositivo que deva ser monitorado precisa ser definido como uma máquina (exemplo 4). As propriedades mais importantes de uma máquina são seu nome e endereço IP. A variável max_check_ attempts define com que freqüência se deve repetir uma verificação antes de o Nagios considerar uma falha e notificar o administrador. Enquanto isso, contact_groups especifica grupos a notificar em caso de falha. Nosso exemplo utiliza um grupo de contato que configuramos antes. Máquinas individuais podem ser coletadas em grupos arbitrários de máquinas para um gerenciamento facilitado: Figura 2 O Nagios fornece resumos detalhados das informações de status. define hostgroup { hostgroup_name linux-servers alias Linux Server members linux1,linux2,tux,webse rver,mybox } Assim que tiverem sido definidas as configurações de tempo, máquinas e contatos, já será possível definir os serviços. Uma definição de serviços especifica os recursos a serem monitorados. É aí que tudo que especificamos começa a se unir (exemplo 5). Linux Magazine #31 Junho de
5 CAPA Nagios Exemplo 6: Configuração da interface web do Nagios 01 ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin <Directory /usr/local/nagios/sbin > 04 Options ExecCGI 05 AllowOverride None 06 Order allow,deny 07 Allow from all 08 AuthName Nagios Access 09 AuthType Basic 10 AuthUserFile /usr/local/nagios/etc/htpasswd.users 11 Require valid-user 12 </Directory> Alias /nagios /usr/local/nagios/share <Directory /usr/local/nagios/share > 17 Options None 18 AllowOverride None 19 Order allow,deny 20 Allow from all 21 AuthName Nagios Access 22 AuthType Basic 23 AuthUserFile /usr/local/nagios/etc/htpasswd.users 24 Require valid-user 25 </Directory> O exemplo 5 também demonstra como passar parâmetros para um comando de verificação. É importante notar que os parâmetros ficam separados por!. Isso passa os valores para as macros $ARG1$, $ARG2$ e assim por diante, que em seguida são passados para o plugin. Em operações normais, faz sentido distribuir a configuração do Nagios através de múltiplos arquivos individuais e, dependendo dos requisitos do projeto, organizar os arquivos em vários subdiretórios. Por enquanto, provavelmente um arquivo único deve ser suficiente. As fontes do Nagios incluem um arquivo chamado localhost.cfg ou minimal.cfg, que é perfeito para seus primeiros passos. Após criar ou modificar os arquivos de configuração do programa, é possível realizar uma verificação da configuração. A opção -v o faz verificar a configuração completa para erros de sintaxe e, sobretudo, certificar-se de que as referências a outros objetos possam ser resolvidas da forma correta. Como argumento, o Nagios espera apenas o nome do arquivo de configuração principal: /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Em caso de sucesso, a verificação da configuração exibe uma mensagem: Things look okay. No serious problems were detected during the pre-flight check. Iniciando o daemon É possível iniciar o daemon com o seguinte comando: /etc/init.d/nagios start. Se o daemon já estiver rodando, pode-se simplesmente mandá-lo recarregar-se, para que ele utilize a nova configuração /etc/init.d/nagios reload. Presumindo que o Nagios não exiba mensagens de erro, agora o daemon foi iniciado para monitorar as máquinas e serviços que foram configurados. Para descobrir quais etapas o programa está realizando no momento, pode-se verificar o arquivo de log tail -f /usr/local/ nagios/var/nagios.log. Interface web Em controles normais e, acima de tudo, para verificar o status atual de todos os servidores monitorados, o Nagios traz uma interface web (figuras 2 e 3)integrada, que deve ser integrada à instalação local do Apache. Se o Apache2 estiver sendo utilizado, a melhor forma é criar um arquivo chamado /etc/ apache2/conf.d/nagios com as entradas mostradas no exemplo 6. Para permitir que os usuários entrem na interface web do programa, é necessário definir entradas de conta em htpasswd.users. Se esse arquivo não existir, será necessário criá-lo utilizando o htpasswd: touch /usr/local/nagios/etc/ htpasswd.users htpasswd /usr/local/nagios/etc/ htpasswd.users jdoe Os nomes de usuários precisam estar de acordo com os contatos criados anteriormente, para que a interface web possa identificar os usuários corretos e mostrar-lhes apenas as máquinas atribuídas a eles. O arquivo cgi.cfg lida com outras funções da interface web e configurações de privilégio. Plugins Um plugin do Nagios é essencialmente um pequeno utilitário que obtém informações do sistema. Como mencionado antes, há toda uma coleção de plugins disponíveis para download no site. Num site do SourceForge dedicado ao desenvolvimento de novos plugins[5], existem links para plugins de terceiros e informações sobre a criação de seus próprios plugins. Como os plugins são programas independentes, pode-se simplesmente rodar um plugin na linha de comando para testá-lo. É bom trabalhar sob a conta de usuário 36
6 Nagios CAPA do servidor do Nagios, já que será ela a executar os plugins. A linha de comando é diferente para cada plugin, como cada tipo de verificação pode demandar parâmetros diferentes. Dito isso, todos os plugins devem possuir uma opção -h ou --help implementada. Chamar a ajuda oferece um breve resumo das várias opções. Considerando o plugin check_disk: nagios#./check_disk -w 50% -c 20% -p /$$ DISK OK - free space: / MB (64% inode=98%); /=25137MB;37080 ;59328;0;74160 Os plugins fornecem um valor de código de retorno que não fica diretamente visível por padrão. Pode-se mostrar o código de retorno digitando-se echo $?. Os códigos de retorno numéricos representam os seguintes resultados: 0 para OK, 1 para WARNING, 2 para CRITICAL e 3 para UNKNOWN. A segunda parte da saída do plugin são os resultados visíveis exibidos na interface web. Vários plugins traduzem o valor de retorno para uma mensagem clara, como a DISK OK mostrada acima. Entretanto, não se deve confiar cegamente nisso em caso de dúvida, é importante verificar o código de retorno. A terceira parte dos resultados fica separada do resto por um pipe ( ). O Nagios chama essa seção de dados de performance. Os plugins processam esses valores, convertendo-os em tabelas ou gráficos que demonstram as mudanças. Se o programa não conseguir encontrar o plugin, ou se este não for executável, ou ainda se o plugin não retornar a resposta correta para o daemon, a interface web exibe um status de UNKNOWN (desconhecido) e uma mensagem de erro Return Code of 127 is out of bounds. Figura 3 O Nagios mantém um resumo dos eventos de notificação. Os parâmetros listados anteriormente, -w e -c, estão definidos para a maioria dos plugins, pois também estabelecem os limites para WARNING e CRITICAL. Nosso exemplo especifica o limite de espaço livre em disco em 50 ou 20%. Ao testar um plugin na linha de comando, é necessário escolher um limite bem baixo, exatamente para verificar se o plugin realmente retorna o status esperado. Se os resultados da preparação e das checagens estiverem a contento, pode-se acrescentar uma entrada referente ao plugin na configuração do Nagios: define command { command_name check_disk command_line $USER1$/check_disk - w $ARG1$ -c $ARG2$ -p $ARG3$ } Não é típico fixar os limites de valores de alerta ou os nomes das partições no arquivo de configuração; em vez disso, normalmente é recomendável especificar esses valores ao definir o serviço. Para preservar o máximo possível de flexibilidade, o Nagios utiliza Exemplo 7: Exemplos do NRPE macros, que são cadeias de caracteres iniciadas pelo símbolo $; a cadeia é substituída pelos dados em tempo de execução do programa. Macros do tipo $ARGx$ são mais importantes, pois são utilizadas para armazenar parâmetros de definições de serviço. Monitoramento remoto Ao monitorar recursos remotos, o Nagios diferencia as checagens diretas das indiretas. As diretas são iniciadas localmente no servidor Nagios. Quase todas as verificações relacionadas a protocolos de rede, como ping, DNS, SMTP e HTTP, são feitas como checagens diretas que simulam o acesso como qualquer cliente normal: nagios#./check_http -H linuxmagazine.com.br -w 5 -c 10 HTTP OK HTTP/ OK bytes in seconds Checagens indiretas são usadas caso o plugin precise requisitar dados de uma máquina remota. Então, o programa precisa conectar-se à máquina antes de exe- 01 -w 5 -c w 15,10,5 -c 30,25, w 20 -c 10 -p /dev/hda1 04 -w 20 -c 10 -p /dev/hdb1 Linux Magazine #31 Junho de
7 CAPA Nagios cutar o plugin diretamente nela. Para isso, a forma mais fácil é criar conexões SSH entre o servidor Nagios e os clientes, sem atribuir senhas, e usar o SSH para chamar os plugins. O pacote de plugins fornece um plugin chamado check_by_ssh para esse propósito. Para iniciar o plugin check_disk remotamente em outro servidor, é necessário encapsulá-lo no check_by_ssh. A definição na linha de comando fica assim: define command { command_name check_ssh_disk command_line $USER1$/check_by_ ssh -t 60 -H $HOSTADDRESS$ -C $USER2$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ O comando check_by_ssh é iniciado localmente. Ele estabelece uma conexão com o servidor, e em seguida executa o plugin check_disk, que se encontra instalado no servidor. O caminho dos plugins em servidores remotos é guardado na variável $USER2$, para que não seja necessário especificá-lo. Outra opção é o Nagios Remote Plugin Executor (NRPE), um programa clienteservidor para o Nagios que executa plugins remotos. Figura 4 A interface WAP do Nagios é capaz de enviar um alerta para telefones celulares aptos a acessar a Internet. Para usá-lo é necessário instalar o servidor NRPE, assim como os plugins nos servidores a serem monitorados. O NRPE consiste em um daemon para os clientes Nagios e um plugin de checagem para o servidor. É interessante compilar o plugin diretamente no servidor Nagios. Após descompactá-lo, digite simplesmente./configure && make all. Isso cria o arquivo check_nrpe, que depois pode ser copiado para o diretório local com os outros plugins, antes de se prosseguir à configuração de um comando respectivo: define command{ command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } Para economizar esforço, pode-se instalar o serviço NRPE nos clientes a partir dos pacotes, ou copiá-lo do servidor Nagios. Recomenda-se executar o NRPE com o inetd ou xinetd, e usar um TCP wrapper. O arquivo README do pacote NRPE contém instruções. Ao final, deve-se informar as checagens que se deseja que o NRPE faça remotamente, em nrpe.cfg (exemplo 7). O arquivo sample contém exemplos (veja o exemplo 6). Embora o NRPE seja a ferramenta oficial para checagens remotas, ele possui algumas desvantagens em comparação com o SSH; por exemplo, ele necessita de um daemon adicional, e também exige a abertura de mais uma porta. SNMP O SNMP é a ferramenta ideal para coletar informações de hardware remoto. Existe um pacote de plugin para o Nagios que fornece o check_snmp. Pode-se usar o check_snmp para se obter valores através do OID do MIB do vendedor. Seguindo o padrão familiar de outros plugins do programa, a linha de comando para isso é nagios#./check_snmp -H <endereço_ip> -o <OID> -w warning -c critical -m :. O último argumento, -m :, é importante, mas mal documentado. Ele impede que o plugin tente carregar MIBs instalados localmente. Isso ocasiona mensagens de erro com todas as versões do plugin. Entretanto, é necessário encontrar os OIDs certos manualmente, seja verificando os MIBs do vendedor ou por tentativa e erro com o snmpwalk. Todo esse monitoramento de rede é inútil se o administrador não for notificado em caso de problemas. Mais uma vez, o Nagios possui uma coleção de sofisticadas funções de alerta. A cada vez que um erro é detectado em algum local do sistema, ele inicia um complexo processo de análise. O software começa verificando se alguém está ciente do erro (veja max_check_attempts), se a parada do serviço foi planejada pela interface web e se o alerta está ativado para a hora atual do dia (veja notification_interval). Contatos Após fazer isso, o Nagios descobre os contatos atribuídos à máquina, e confere suas configurações de notificação para saber se os contatos devem ser notificados; em caso positivo, que tipo de notificação é esperado (veja notification_options). Finalmente, o programa verifica se o contato deseja ser avisado imediatamente (veja notification_period). Graças a esse esquema, ele suporta um controle altamente granular das notificações. Dependendo da máquina, hora e contato, pode-se enviar diferentes mensagens através de canais distintos. Para enfocar esse mecanismo ainda mais, as escalas oferecem aos administradores a possibilidade de alterar a forma como os alertas subseqüentes para programas já existentes serão feitos. 38
8 Nagios CAPA Para enviar de fato um alerta, o Nagios manda um comando similar aos de checagem. Em outras palavras, as notificações não estão fixadas no Nagios. Em vez disso, o programa executa um comando ou script de shell (exemplo 8). A parte importante da configuração do alerta são os dados enviados ao programa de . Mais uma vez são usadas macros para transmitir os dados. A documentação do Nagios inclui uma lista completa de macros disponíveis. Arquivos de configuração Exemplo 8: Configuração de notificação 01 define command { 02 command_name notify-by- 03 command_line /usr/bin/printf %b $$ 04 ***** Nagios 1.0 *****\n\n $$ 05 Notification Type: $NOTIFICATIONTYPE$\n\n $$ 06 Service: $SERVICEDESC$\n $$ 07 Host: $HOSTALIAS$\n $$ 08 Address: $HOSTADDRESS$\n $$ 09 State: $SERVICESTATE$\n\n $$ 10 Date/Time: $DATETIME$\n\n $$ 11 Additional Info:\n\n $$ 12 $OUTPUT$ /usr/bin/mail -s $$ 13 ** $NOTIFICATIONTYPE$ alert -$HOSTALIAS$/$SERVICEDESC$ $$ 14 is $SERVICESTATE$ ** $CONTACT $ 15 } Como ponto de partida para nossos experimentos, o Nagios inclui vários arquivos de exemplo. O arquivo minimal. cfg simplesmente implementa algumas checagens para o localhost, enquanto bigger.cfg possui exemplos mais sofisticados. Entretanto, mesmo que só se queira monitorar uma pequena rede, faz sentido dedicar-se à organização de sua configuração de objetos. Distribuir os objetos ao longo de arquivos separados de acordo com o tipo de objeto é altamente recomendável. Por exemplo, pode-se usar os arquivos maquinas.cfg, servicos.cfg, contatos.cfg. Todavia, até mesmo essa abordagem pode rapidamente tornarse difícil de acompanhar, e não há motivos reais para se manter tipos de objetos individuais separados. O Nagios encontra os objetos independentemente de quantos arquivos (ou até diretórios) separados estejam em uso, contanto que seu arquivo nagios. cfg aponte para os locais corretos. É interessante usar subdiretórios para estruturar logicamente uma configuração. Por exemplo, guardar as configurações globais e de rede nos níveis mais altos. O nível seguinte conteria, então, subdiretórios individuais para cada cliente, departamento ou tipo de dispositivo. Então, pode-se incluir no arquivo de configuração os objetos relacionados, como uma máquina, junto com os serviços e contatos associados a ela. O melhor método é organizar os objetos de forma a facilitar sua procura. Conclusões O Nagios oferece muito mais do que se pode descrever em um artigo. Inúmeros recursos e projetos adicionais oferecem aos administradores a possibilidade de acrescentar funções de monitoramento para qualquer cenário plausível. Ele também suporta sistemas de notificação alternativos que usem SMS, e pode até realizar chamadas telefônicas (figura 4). O portal de programas adicionais (add-ons)[3] é o melhor lugar para se procurar extensões e plugins do programa. Não importa quão incomuns sejam suas necessidades, há um plugin adequado para elas, ou ao menos um que possa ser usado como ponto de partida para a criação da sua própria solução personalizada. Não se esqueça, é claro, de compartilhar seu novo plugin com a comunidade. Mais Informações [1] Página do Nagios: [2] Repositório do Debian com pacotes do Nagios: [3] Documentação do arquivo de configuração do Nagios: net/docs/2_0/configmain.html [4] Objetos do Nagios: nagios.sourceforge.net/ docs/2_0/xodtemplate.html [5] Plugins do Nagios: nagiosplug.sourceforge.net/ [6] Plugins e add-ons: O autor Julian Hein é o fundador e CEO da empresa alemã NETWAYS (http://www.netways. de), que atua na implementação e operação de redes complexas há mais de dez anos. Linux Magazine #31 Junho de