Collectd: Monitorando servidores - Revista Infra Magazine 5

O monitoramento em um ambiente de infraestrutura de TI é um dos componentes básicos que o administrador de sistemas precisa para oferecer um serviço de qualidade. Imagine ter que entrar em servidor por servidor para saber se está tudo funcionando bem em seu ambiente. Em um ambiente pequeno, isso é possível, mas desnecessário, pois esse tempo pode ser gasto em outras tarefas.

Atualmente, muitas vezes, só se sabe que algo está com problema quando o usuário final liga para informar. Isso é algo que pode ser evitado. Quando o cliente ligar para reclamar, o administrador do sistema deve conhecer quais itens estão com problema e qual a previsão para normalizar. Isso demonstra que o administrador tem controle sobre sua infraestrutura e traz confiança para seu cliente, seja ele interno ou externo. Trabalhar de forma proativa é muito melhor do que de forma reativa e para isto é necessário um processo de monitoramento bem estabelecido.

O monitoramento deve contemplar todos os itens de infraestrutura que envolvam o funcionamento normal do seu ambiente, ou seja, ativos de rede (roteadores e switches), servidores e o que mais for possível monitorar.

Um sistema de monitoramento bem definido faz com que o administrador saiba o que está acontecendo no ambiente sem sequer se autenticar em um servidor. Em outras palavras, o administrador deve conter uma tela única que aponte se existe problema no ambiente computacional ou não. Para atingir este nível de maturidade, leva-se um tempo. Portanto não é preciso se preocupar se, no início, não for possível chegar a essa situação. Um processo contínuo de revisão e melhoria deve ser instaurado até que se alcance a qualidade esperada de monitoramento.

Monitoramento de servidores

Existem dois tipos de monitoramento em servidores: monitoramento ativo e monitoramento passivo. Basicamente, o monitoramento ativo é aquele onde o servidor busca as informações no item monitorado (máquina em que se executa um processo cliente). Por sua vez, o monitoramento passivo é aquele onde o processo cliente envia os dados para o servidor de monitoramento. A arquitetura e as ferramentas para isso devem ser avaliadas de acordo com o tipo de negócio e as necessidades.

Atualmente, no ambiente computacional aplicam-se ambos os tipos de monitoramento, pois além de ter a visão do servidor, é necessário ter a visão do usuário. Explica-se: imagine monitorar de forma passiva o processo do ntpd (network time protocol daemon). O processo está rodando, mas por algum motivo, o sincronismo de horário não está sendo feito. Então, de forma ativa, monitoram-se quantos minutos o servidor está diferente do servidor ntp (Network Time Protocol). Assim, tem-se a visão do sistema operacional (processo rodando) e a visão do usuário (quantos minutos de diferença de horário). Este tipo de estratégia deve ser aplicado em todo monitoramento.

Outro item importante é chegar ao valor do limite ideal para o monitoramento. Esse valor, chamado threshold, é o valor mínimo ou máximo que o item monitorado deve trabalhar. Por experiência, definem-se valores comumente utilizados, conforme citado nas explicações a seguir. Porém é conceitualmente errado predefinir o threshold para monitoramento, pois este deve ser adequado ao ambiente que se quer monitorar. Quando estiver montando o ambiente computacional, o administrador deve gastar um tempo analisando os gráficos de utilização dos recursos para chegar aos valores ideais. Se o administrador implementar o ambiente computacional sem esta tarefa, problemas com falsos-positivos podem ocorrer. Chamam-se falso-positivos os alarmes que aparecem no monitoramento, mas não correspondem a um problema real no ambiente. Isso é um erro de configuração do monitoramento e o processo de monitoramento deve ser reavaliado.

Monitoramento passivo

O monitoramento passivo é feito por um processo cliente instalado no item monitorado que coleta as informações de tempos em tempos e envia para o servidor central. O tempo de coleta no processo cliente pode ser diferente do tempo configurado na monitoração. Por exemplo, a coleta é realizada em intervalos de um minuto e o monitoramento é realizado a cada cinco minutos. Isso pode ser útil, pois ao gerar gráficos com o intervalo menor, o administrador do sistema terá maior visibilidade do comportamento do item monitorado. Porém, quanto menor o intervalo do monitoramento, mais carga haverá no cliente e no servidor. Por isso é importante avaliar os recursos disponíveis e sua necessidade. Se o ambiente possuir muitos servidores e não houver muitos recursos para o monitoramento, é possível melhorar o ambiente com o intervalo de coleta de 5 minutos.

CPU

Para o monitoramento de CPU, geralmente utiliza-se o valor de CPU idle (ociosa) com threshold mínimo de 10% do tempo de ociosidade para critical e 20% do tempo de ociosidade para warning, ou seja, quando a utilização for maior que 80% da capacidade total da CPU, está na hora de preocupar-se em aumentar a capacidade de processamento ou adicionar mais um servidor no grupo de servidores. Porém este threshold deve ser ajustado de acordo com a característica do serviço. Por exemplo, um servidor que faz processamento de logs tem seu threshold de warning em 95% e critical em 100%, pois a característica do serviço é de alto consumo de CPU. Então, o fato da CPU estar em 90% é aceitável. Porém, para um servidor de memcached pode-se diminuir bastante o threshold da CPU. Quando a CPU está acima de 80% de carga de processamento o administrador deve começar a se preocupar para evitar futuros problemas.

Memória

Quando se fala de monitoramento de memória, o ideal é monitorar sempre a memória utilizada e a memória de buffers, pois em sistemas de alto desempenho, o papel do cache é extremamente significativo para o sistema operacional, posto que operações de escrita e leitura em memória são muitas vezes mais rápidas do que as mesmas em disco. Portanto uma parte da memória total deve estar sendo para realizar cache.

Swap

Quando a área de swap começa a ser utilizada é porque a memória do sistema já foi alocada e o sistema operacional precisa disponibilizar mais memória para um processo. Conforme mencionado anteriormente, operações de escrita e leitura são muito mais lentas em disco do que em memória. O total da memória swap deve ser pequeno, senão o servidor perderá desempenho significativamente até ocasionar seu próprio travamento. Alguns megabytes ou no máximo um gigabyte já é o suficiente para um momento de maior consumo. Se o servidor em questão fizer swapping frequentemente, deve-se analisar o aumento da memória ou alguma aplicação com memory leak. A falha memory leak é causada quando o sistema não desaloca memória. Sendo assim, o processo irá consumir cada vez mais memória até ocupar toda a área de swap ou travar. Em casos onde não é necessário alto desempenho por todo o tempo, o uso de swap pode se tornar aceitável.

Sistema de arquivos

O monitoramento do sistema de arquivos é realizado por porcentagem utilizada ou quantidade de espaço livre. O que vai determinar a melhor forma de monitorar é o tamanho do sistema de arquivos. Se o tamanho total do sistema de arquivos for pequeno (menor que 100 gigabytes), utiliza-se porcentagem de espaço livre. Porém, se for grande (maior que 100 gigabytes) é melhor utilizar o total de espaço livre. O /usr normalmente tem entre 3 e 8 gigabytes. Para esse tamanho estabelece-se o threshold de 80% para warning e 90% para critical, pois este tamanho é considerado pequeno. Porém, para um servidor de arquivos de um terabyte, é melhor monitorar por espaço livre.

Network File System

Pelo lado do servidor, deve-se utilizar as estatísticas do servidor Network File System (NFS), ou seja, a quantidade das chamadas de cada tipo, por exemplo: read, write, create, commit etc. Pelo lado do cliente, deve-se certificar que o sistema de arquivos esteja em modo de leitura e escrita. A forma mais comum de realizar esta monitoração é escrever um arquivo no sistema de arquivos, medir o tempo da escrita, realizar a leitura do arquivo e medir o tempo da leitura.

Discos

Um item importante para monitorar em disco é o tempo de resposta, ou seja, quanto tempo leva cada operação de escrita e leitura no disco. Quanto menor for esse tempo melhor desempenho terá seu ambiente. O tempo varia muito entre fabricantes. Se o disco é local ou storage, qual modelo de RAID adotado, se a tecnologia é SATA, SSD, Storage FC, NAS etc. Outra alternativa é a quantidade de operações por segundo (IOPS). Quanto maior esse valor, mais carga haverá no disco. Um valor muito alto aumentará o tempo de resposta.

Processos

É importante observar todos os processos que precisam estar funcionais no servidor. Os processos do sistema operacional são mais comuns, por exemplo, syslog, ntp, sshd, crond e sendmail. Os processos de aplicações variam bastante, sendo que os mais comuns são o Hypertext Transfer Protocol Daemon (httpd) ou simplesmente servidor web e os processos Java. Pode-se monitorar apenas a quantidade de processos ou threads ou então entrar em um detalhamento melhor, ou seja, monitorar a quantidade de memória, a quantidade de escrita e leitura, e o tempo de uso da CPU do processo específico. Com as ferramentas aqui expostas, o administrador do sistema conseguirá chegar ao nível alto de detalhamento.

Monitoramento ativo

O monitoramento ativo pode ser feito pelo próprio servidor de monitoramento ou por outro servidor. Isso vai depender da quantidade de itens monitorados e da quantidade de recursos do servidor alocado para essa tarefa.

Quando o processo de monitoramento estiver atrapalhando o próprio monitoramento, ou seja, quando a utilização dos recursos feita pelos processos que correspondem ao monitoramento dos clientes for maior que a utilização dos recursos feita pelo processo do sistema de monitoramento, o administrador deve separar as tarefas em servidores diferentes.

Para definir o monitoramento ativo, deve-se cumprir basicamente duas tarefas:

1. Monitoramento de portas (TCP e UDP): O monitoramento de portas TCP/UDP consiste em um teste de conectividade na porta e protocolo determinado. Por exemplo: telnet para TCP e netcat para UDP.

2. Scripts que simulam a situação atual do ambiente: Esses scripts devem reproduzir as ações do usuário final.

Alguns exemplos de como fazer o monitoramento ativo são apresentados a seguir. A Tabela 1 mostra que para monitorar o serviço Syslog configura-se o monitoramento da porta 1514 TCP e 514 UDP. Porém, habitualmente, não se cria nenhum script para monitorar o serviço.

Tabela 1. Serviços, portas e scripts.

Para monitorar o serviço de NTP configura-se o monitoramento da porta 123 TCP e 123 UDP e cria-se um script para monitorar a diferença de horário entre o servidor de monitoramento e o item monitorado. Nesse caso, é preciso se certificar do horário do servidor de monitoramento.

No caso de um servidor de correio eletrônico, é preciso que o protocolo Simple Mail Transfer Protocol (SMTP) esteja funcionando no servidor. Para monitorá-lo cria-se um script que envia uma mensagem eletrônica.

É importante destacar que, sempre que for necessária a autenticação para monitorar o serviço – por exemplo: uma query no banco de dados – é preciso ter um usuário específico para monitoramento.

Hands on

Agora se propõe um laboratório para ver as coisas funcionando! Neste artigo, demonstram-se algumas ferramentas, mas nada que impeça o usuário de montar sua própria arquitetura e escolher suas ferramentas. O usuário pode fazer seus próprios monitores. Porém, se já existe algo bom que funciona, não é preciso gastar tempo desenvolvendo os próprios monitores. Deve-se criar os próprios monitores em casos muitos específicos, ou seja, quando não existir um plugin já pronto.

O sistema operacional em questão é o Mac OS X 10.6.8 e o Parallels Desktop para criar as máquinas virtuais. Deve-se criar no mínimo três servidores: um para compilar os pacotes (não é recomendado que se compile os pacotes no servidor que roda o serviço), outro para representar o papel de servidor central e, por último, outro para representar o papel de cliente. Os nomes dos servidores serão: builder01, server01 e client01. O sistema operacional de todas as máquinas virtuais é o CentOS 5.7 x86_64.

Na seção de downloads da Revista Infra Magazine, disponibiliza-se dois arquivos para instalação do Sistema Operacional. Se o usuário possuir o software kickstart, deve utilizar o arquivo anaconda-ks.cfg, senão deve usar o rpm-qa.txt. Se o usuário seguir esses passos, o sistema operacional deverá ter os mesmos pacotes apresentados no arquivo rpm-qa.txt. Caso ocorram problemas, o usuário deve verificar se todos os pacotes foram instalados corretamente.

Após a instalação do sistema operacional, é preciso configurar a rede. A máscara de rede será 255.255.255.240. Assim a sub-rede pode ter até 14 máquinas virtuais (VM), mais que suficiente para esse caso. Os endereços IP serão 10.211.55.9, 10.211.55.10 e 10.211.55.11 para os servidores builder01, server01 e client01, respectivamente. Além disso, cada máquina virtual tem 1 vCPU e 512 megabytes de memória RAM.

Compilando pacotes

O servidor para compilar os pacotes necessários para nosso laboratório será o builder01. Deve-se executar a sequência de comandos a seguir para instalar o compilador:

  # ssh 10.211.55.10
  # yum -y install gcc

O gcc é um compilador de programas na linguagem C. Em servidores de produção em que sua função não é atuar como um compilador, não é recomendado que este pacote seja instalado, pois com um compilador C disponível é muito mais complexo garantir a segurança no servidor.

RRDtool

O RRDtool é uma ferramenta para gerenciar dados e gráficos coletados de tempos em tempos. Para o ambiente proposto, o binário rrdcached, que é provido pelo pacote do RRDtool, e a biblioteca librrd.h, serão necessários para compilar o plugin RRDtool e o rrdcached. Veja mais sobre isso mais adiante neste texto.

O rrdcached armazena uma quantidade pré-configurada de dados antes de atualizar o RRD, ou seja, diminui significativamente a quantidade de escrita e leitura em disco feitas para gerar os gráficos. Detalhes sobre o plugin rrdcached podem ser consultados no wiki do collectd. Execute a sequência de comandos mostrada na Listagem 1 para instalar o RRDtool.

Listagem 1. Instalando o RRDtool.

  # yum -y install cairo-devel pango-devel libxml2-devel
  # cd /usr/src
  # wget http://oss.oetiker.ch/rrdtool/pub/rrdtool.tar.gz
  # tar xzvf rrdtool.tar.gz
  # cd rrdtool-1.4.7/
  # ./configure --prefix=/opt/rrdtool-1.4.7
  # make && make install

O comando yum é utilizado para gerenciar os pacotes do sistema operacional.

O comando wget é utilizado para baixar arquivos da internet. Provavelmente, de dentro da rede, o usuário não terá acesso para baixar arquivos da internet. Assim, o usuário deve solicitar o acesso ou baixar os códigos fontes e copiá-los para o servidor.

O tar é um comando para compactar/descompactar arquivos. A Tabela 2 apresenta alguns parâmetros para utiliza-lo. Para consultar todos os parâmetros, deve-se executar o comando man tar.

Tabela 2. Parâmetros do comando tar.

O próximo comando é o configure, que é um script padrão contido em todos os arquivos fontes para o usuário preparar o sistema. Se quiser conhecer mais sobre, deve-se executar o comando ./configure --help. O comando make compila os códigos fontes para gerar os binários, bibliotecas, arquivos de configuração, documentos etc. A inclusão do parâmetro && significa que se o comando make for executado com sucesso o próximo comando será executado em seguida. Caso contrário, o comando seguinte não será executado.

O comando make install instala, isto é, copia todos os arquivos gerados pelo comando make para o caminho informado através do parâmetro --prefix do script de configure.

Collectd

O collectd é um agente de monitoramento bastante utilizado atualmente. Foi escrito visando consumir o mínimo de recursos possíveis. Para monitorar os recursos é preciso utilizar outros recursos, por isso o coletor de dados deve ser o mais leve possível. O collectd e a maioria dos plugins foram escritos na linguagem de programação C, portanto utilizam pouco recurso do servidor monitorado. O usuário pode ter um servidor para gerar os gráficos ou então o próprio servidor monitorado pode gerar os gráficos. Deve-se avaliar bem a segunda alternativa, pois gerar gráficos usa muitas operações de escrita em disco.

Seguem algumas características do collectd:

· Possui um escalonador próprio. Deste modo, não tem aquele velho conhecido problema do cron de não rodar os scripts ou de precisar de um sistema de automação pago;

· Possui muitos plugins para monitorar diversos serviços. Exemplos: httpd, nginx, mysql, oracle, smtp etc.

O collectd é uma ferramenta muito bem documentada. No wiki (http://collectd.org/wiki/index.php) encontra-se uma explicação detalhada sobre cada funcionalidade, ou seja, cada item de configuração e plugin disponível.

Preparar a instalação

Este é um ponto crucial. Aqui o usuário deve preparar seu sistema, ou seja, habilitar todos os plugins que utilizará. Por padrão, o script ./configure do collectd tenta compilar todos os plugins, porém ele só habilitará os plugins cujo as bibliotecas necessárias estiverem disponíveis.

Com os pacotes instalados anteriormente, nem todos os plugins estarão habilitados, pois nem todas as bibliotecas necessárias para a compilação dos plugins estão instaladas. Instale o pacote de acordo com o plugin que quer habilitar conforme a Tabela 3.

Tabela 3. Plugins e pacotes.

Após instalar todas as bibliotecas necessárias, execute a sequência de comandos da Listagem 2. Se nunca usou o CPAN e não sabe configurá-lo, quando for executá-lo pela primeira vez, ele solicitará as informações necessárias para funcionar. Assim, basta escolher sempre a resposta padrão que já vem informada no prompt. CPAN (www.cpan.org) é onde se encontram todos os códigos e módulos Perl.

Listagem 2. Instalando o collectd.

  # cd /usr/src
  # wget http://collectd.org/files/collectd-5.0.1.tar.gz
  # tar xzvf collectd-5.0.1.tar.gz
  # cd collectd-5.0.1 
  # ./configure --prefix=/opt/collectd-5.0.1 --enable-debug --with-librrd=/opt/rrdtool-1.4.7
  # make && make install
  # mkdir /opt/collectd-5.0.1/contrib
  # cp /usr/src/collectd-5.0.1/contrib/redhat/init.d-collectd /opt/collectd-5.0.1/contrib/
  # sed -i 's/\/etc\/collectd.conf/\/opt\/collectd\/etc\/collectd.conf/g' /opt/collectd-5.0.1/contrib/init.d-collectd
  # sed -i 's/\/usr\/sbin\/collectd/\/opt\/collectd\/sbin\/collectd/g' /opt/collectd-5.0.1/contrib/init.d-collectd
  # # sed -i 's/\"collectdmon\"/\/opt\/collectd\/sbin\/collectdmon/g' /opt/collectd-5.0.1/contrib/init.d-collectd
  # perl -MCPAN -e 'install HTML::Entities, Config::General, URI::Escape, Regexp::Common'
  # tar czvf perl-HTML-Entities.tar.gz /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/HTML/Entities.pm
  # tar czvf perl-Config-General.tar.gz /usr/lib/perl5/site_perl/5.8.8/Config/General /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Config/General /usr/lib/perl5/site_perl/5.8.8/Config/General.pm
  # tar czvf perl-URI-Escape.tar.gz /usr/lib/perl5/site_perl/5.8.8/URI/Escape.pm
  # tar czvf perl-Regexp-Common.tar.gz /usr/lib/perl5/site_perl/5.8.8/Regexp/Common /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Regexp/Common /usr/lib/perl5/site_perl/5.8.8/Regexp/Common.pm
  # tar czvf perl-HTML-Parser.tar.gz /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/HTML/Parser.pm /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/HTML/Parser
  # cd /usr/src/collectd-5.0.1/contrib/
  # tar czvf /opt/collection3.tar.gz collection3

Os gráficos que serão gerados pelo collectd serão armazenados em um RRD. Devido à forma de armazenamento do RRD para visualizar os gráficos, precisa-se de um sistema front-end, ou seja, um sistema para nos mostrar os dados que o collectd está coletando. Existem vários atualmente, como collection3, collectgraph, heymon, entre outros. Neste artigo aborda-se o collection3.

Enviando os arquivos para outros servidores

Após compilar e instalar o collectd, deve-se copiar os arquivos para o servidor que executará a tarefa. Para isso, crie um arquivo compactado no formato tar de cada sistema instalado, ou seja, RRDtool, collectd e collection3. Execute a lista de comandos da Listagem 3.

Listagem 3. Copiando arquivos para servidor e cliente.

  # cd /opt
  # tar czvf rrdtool-1.4.7.tar.gz rrdtool-1.4.7/
  # scp rrdtool-1.4.7.tar.gz 10.211.55.10:/opt/
  # tar czvf collectd-5.0.1.tar.gz collectd-5.0.1
  # scp collectd-5.0.1.tar.gz 10.211.55.10:/opt/
  # scp collection3.tar.gz perl-* 10.211.55.10:/opt/
  # scp collectd-5.0.1.tar.gz 10.211.55.11:/opt/

O leitor realizou as seguintes atividades: entrou no diretório onde os arquivos foram instalados, compactou os arquivos do RRDtool e copiou o tar para o servidor de monitoramento, server01. Depois, fez a mesma coisa com o collectd e enviou para ambos os servidores, client01 e server01. O builder01 é o servidor onde gera-se os pacotes, portanto não se deve copiar nada para ele.

Configurando client01

O client01 será o servidor monitorado. Portanto instale o collectd e configure o envio dos dados para o server01. Para isso, execute a sequência de comandos da Listagem 4.

Listagem 4. Configurando collectd no cliente.

  # cd /opt
  # tar xzvf collectd-5.0.1.tar.gz
  # ln -s /opt/collectd-5.0.1 /opt/collectd
  # ln -s /opt/collectd/contrib/init.d-collectd /etc/init.d/collectd
  # vi /opt/collectd/etc/collectd.conf

Crie um link simbólico para organização dos seus pacotes, utilizando o comando ln, de acordo com a Listagem 4. Muitas vezes é preciso manter duas ou mais versões do sistema no servidor, geralmente em caso de atualização. Assim, deve-se apontar o script de inicialização do collectd para o caminho especificado no link simbólico.

Dessa forma, não será preciso fazer atualizações do script de inicialização somente por causa de uma atualização de versão do collectd, pois o nome do link simbólico permanecerá o mesmo, apesar da alteração da versão. Outra vantagem de criar o link simbólico é que o usuário saberá mais facilmente qual versão está em funcionamento.

É importante destacar que neste texto, apenas os principais parâmetros do arquivo de configuração do collectd são abordados. Porém existem muitas outras funcionalidades que podem ser conhecidas no arquivo de configuração e também no wiki (http://collectd.org/wiki/index.php).

Neste momento o arquivo do collectd deve ser editado com os seguintes parâmetros:

· #Interval 10: indica o intervalo de coleta. Vem comentado, pois o intervalo padrão é de 10 segundos. Neste caso altere para 60 segundos, ou seja, um minuto e remova o comentário;

· #ReadThreads 5: Indica a quantidade de threads que o collectd utilizará para fazer as coletas. Nesse caso não se deve alterar;

· LoadPlugin syslog: Vem habilitado por padrão. Comente a linha, pois o log será específico, ou seja, ao invés de enviar os logs para o syslog, vamos criar um arquivo separado. Desta forma fica mais fácil verificar os logs;

· #LoadPlugin logfile: Vem desabilitado por padrão, remova o comentário para habilitá-lo. A configuração do plugin ficará conforme apresentado na Listagem 5 e a explicação dos parâmetros aparece a seguir:

o LogLevel: debug, info ou error. Debug para imprimir todos os logs; info para imprimir logs informativos e de erros; e error para apenas imprimir logs de erros;

o File: Arquivo onde será gerado o log. As aspas duplas não devem ser esquecidas;

o Timestamp: true ou false. Imprimir ou não a data no log. Para conseguir investigar problemas ou erros são necessárias as informações da data no log;

o PrintSeverity: true ou false. Imprimir ou não loglevel no arquivo de log.

Em seguida retire os comentários de alguns plugins, removendo o caractere #:

· #LoadPlugin contextswitch: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora a troca de contexto da CPU. Não é necessária nenhuma configuração;

· #LoadPlugin df: Vem desabilitado por padrão, mas deve ser habilitado. Este plugin monitora todos os sistemas de arquivos. Não é necessária nenhuma configuração;

· #LoadPlugin disk: Vem desabilitado por padrão, mas deve ser habilitado e configurado conforme a Listagem 6. Este plugin monitora os discos, quantidade de IOPS, response time etc.;

· #LoadPlugin network: Vem desabilitado por padrão, mas deve ser habilitado e configurado conforme a Listagem 7. Esse é o plugin que envia os dados para o servidor;

· #LoadPlugin swap: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora o swap;

· # LoadPlugin protocols: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora os protocolos de rede (TCP, UDP, ICMP etc.);

· #LoadPlugin tcpconns: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora a quantidade de conexões por determinado estado (established, listen, time_wait etc.);

· #LoadPlugin uptime: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora o tempo que o sistema operacional está ligado;

· #LoadPlugin users: Vem desabilitado por padrão, mas deve ser habilitado. Esse plugin monitora a quantidade de usuários com sessão aberta no servidor.

Listagem 5. Configuração do plugin logfile.

  <Plugin logfile>
    LogLevel info
    File “/opt/collectd/var/log/collectd.log”
    Timestamp true
    PrintSeverity true
  </Plugin>

Listagem 6. Configuração do Plugin disk.

  <Plugin disk>
    Disk "/^[h|s]d[a-f][0-9]?$/"
    # IgnoreSelected false
  </Plugin>

Listagem 7. Configuração do plugin network cliente.

  <Plugin network>
    # cliente setup:
    Server "10.211.55.10" "25566"
  </Plugin>

O arquivo que está sendo editado deve ser salvo como collectd.conf.

Demonstra-se a seguir algumas configurações adicionais que podem ser aplicadas no arquivo collectd.conf, se desejar monitorar o serviço.

O Postfix, por exemplo, é um sistema de e-mail bastante completo e utilizado. Observe a Listagem 8 para verificar como monitorar uma fila de e-mails. Além disso, adicione o texto LoadPlugin filecount no arquivo collectd.conf.

Listagem 8. Monitorando a fila do postfix.

  <Plugin filecount>
    <Directory "/var/spool/postfix/active/">
      Instance "active"
    </Directory>
    <Directory "/var/spool/postfix/bounce/">
      Instance "bounce"
    </Directory>
    <Directory "/var/spool/postfix/corrupt/">
      Instance "corrupt"
    </Directory>
    <Directory "/var/spool/postfix/deferred/">
      Instance "deferred"
    </Directory>
    <Directory "/var/spool/postfix/incoming/">
      Instance "incoming"
    </Directory>
    <Directory "/var/spool/postfix/hold/">
      Instance "hold"
    </Directory>
  </Plugin>

O banco de dados MySQL é atualmente utilizado por empresas de grande porte e diversas soluções de código aberto. Observe a Listagem 9 para configurar o monitoramento da instância MySQL. Além disso, adicione o texto LoadPlugin mysql no arquivo collectd.conf.

Listagem 9. Monitorando o MySQL.

  <Plugin mysql>
    <Database mysql>
      Database "mysql"
    </Database>
  </Plugin>

Conforme mencionado anteriormente, o serviço de NTPD é responsável pelo sincronismo do horário. Para habilitar sua monitoração, adicione a linha abaixo no arquivo de configuração do collectd:

LoadPlugin ntpd

Para concluir, é importante monitorar os processos do sistema operacional. Observe na Listagem 10 um exemplo de configuração do plugin para isso. Em seguida, insira o texto LoadPlugin processes no arquivo collectd.conf.

Listagem 10. Monitorando processos do SO.

  <Plugin processes>
    Process "klogd"
    Process "syslogd"
    Process "portmap"
    Process "crond"
    Process "sshd"
    Process "httpd"
    Process "mysqld"
    Process "mysqld_safe"
    Process "ntpd"
    Process "collectdmon"
    Process "collectd"
  </Plugin>

Até este momento, apenas algumas configurações prévias necessárias foram feitas para que o serviço do collectd funcione adequadamente. Agora é preciso definir como o collectd será instanciado quando a máquina monitorada for inicializada. Isso é feito ao se executar a sequência de comandos da Listagem 11.

Listagem 11. Inicialização do collectd cliente.

  # chmod +x /etc/init.d/collectd
  # /etc/init.d/collectd start
  # tail -f /opt/collectd/var/log/collectd.log
  # chkconfig --add collectd
  # chkconfig --list collectd

Segue a explicação dos comandos executados:

1. Adição da permissão de execução para o script de inicialização do collectd;

2. Inicialização do daemon;

3. Leitura das últimas linhas do arquivo e apresentação das próximas linhas escritas. Com isso verifica-se a ocorrência de algum erro durante o processo de inicialização do collectd;

4. Adição do script de inicialização do collectd para ser executado no boot do servidor;

5. Listagem dos run level e verificação se o script é executado ou não.

Configurando server01

O servidor server01 será o servidor de monitoramento. Ele receberá os dados do collectd cliente para gerar os gráficos e fazer o monitoramento. Execute a sequência de comandos da Listagem 12 para configurar o RRDtool. O conteúdo do arquivo /etc/init.d/rrdcached é apresentado na Listagem 13. Este arquivo é o script de inicialização do rrdcached. Não vem disponível no código fonte, por isso disponibiliza-se um caso necessite.

Listagem 12. Configuração do RRDtool no servidor.

  # cd /opt
  # tar xzvf rrdtool-1.4.7.tar.gz
  # ln -s /opt/rrdtool-1.4.7 /opt/rrdtool
       
  # vi /etc/init.d/rrdcached
  # chmod +x /etc/init.d/rrdcached 
  # /etc/init.d/rrdcached start
  # /etc/init.d/rrdcached status
  # chkconfig --add rrdcached
  # chkconfig --list rrdcached

Listagem 13. Arquivo de inicialização do rrdcached.

  #!/bin/bash
  #
  # by Thiago Nache > thiago.borges@tivit.com.br || thiagonbcarvalho@gmail.com # 20111229
  #
  # chkconfig: 2345 15 85
  # description: script to management rrdcached
  # processname: rrdcached
   
  # enviroment
  RRDCACHEDBIN="/opt/rrdtool/bin/rrdcached"
  RRDCACHEDPARAMS=" -l /var/run/rrdcached.sock -w 1200 -z 480 -t 36 -F > /dev/null 2>&1"
   
  # source function library
  . /etc/init.d/functions
   
  RETVAL=0
   
  start() {
    echo -n $"Starting rrdcached service: "
   
    if [ ! -x ${RRDCACHEDBIN} ];
    then
      echo -n $"Cannot execute rrdcached bin: ${RRDCACHEDBIN}!"
    fi
   
    daemon "${RRDCACHEDBIN} ${RRDCACHEDPARAMS}"
    RETVAL=$?
    echo
  }
   
  stop() {
    echo -n $"Shutting down rrdcached service: "
    killproc ${RRDCACHEDBIN}
    RETVAL=$?
   
    echo
  }
   
  case "$1" in
    start)
      start
      ;;
    stop)
      stop
      ;;
    restart|reload)
      stop
      sleep 2
      start
      ;;
    status)
      status ${RRDCACHEDBIN}
      RETVAL=$?
      ;;
    *)
      echo $"Usage: $0 {start|stop|restart|status}"
      exit 1
  esac
   
  exit $RETVAL

Conforme o parâmetro –w (em segundos) contido no script de inicialização, os gráficos serão atualizados a cada vinte minutos. Deve-se adequá-lo conforme o ambiente a se monitorar. Se o intervalo for pequeno, a quantidade de entrada e saída (I/O) gerada pelo collectd não diminuirá muito. Se for muito alto demorará muito para ver os gráficos.

A configuração inicial do collectd será exatamente igual aos passos da configuração do cliente. Portanto, deve-se executar a sequência de comandos da Listagem 4 até a parte de editar o arquivo collectd.conf. Vamos então conhecer o que difere a partir deste ponto.

Resumindo, a diferença da configuração do collectd é que os plugins UnixSock e rrdcached são carregados (eles não são utilizados na configuração do cliente) e o plugin network terá configuração diferente. Ao invés de informar o servidor, cria-se uma porta em estado de receber conexão (listening).

O plugin UnixSock é necessário para conseguir ler os dados do collectd server. Observe a configuração do mesmo na Listagem 14. Para concluir esta etapa, adicione LoadPlugin unixsock no arquivo collectd.conf.

Listagem 14. Configuração do plugin unixsock.

  <Plugin unixsock>
    SocketFile "/var/run/collectd-unixsock"
    SocketGroup "root"
    SocketPerms "0666"
    # DeleteSocket false
  </Plugin>

Analisando os parâmetros:

· SocketFile: Indica o caminho onde o socket será criado;

· SocketGroup: Indica o grupo que é o dono do arquivo;

· SocketPerms: Indica a permissão do socket.

O plugin rrdcached, por sua vez, armazenará os dados do RRD em memória cache. Observe a Listagem 15 para saber como configurá-lo. Para findar esta etapa, adicione LoadPlugin rrdcached no arquivo collectd.conf.

Listagem 15. Configuração do plugin rrdcached.

  <Plugin rrdcached>
    DaemonAddress "unix:/var/run/rrdcached.sock"
    DataDir "/opt/collectd-5.0.1/var/lib/collectd/rrd"
    CreateFiles true
    CollectStatistics true
  </Plugin>

Analisando os parâmetros:

· DaemonAddress: Indica o caminho para o socket. Esse caminho deve ser o mesmo que o do script de inicialização do rrdcached;

· DataDir: Indica o diretório onde os rrds serão criados;

· CreateFiles: true ou false. Sempre configure como true, pois do contrário os arquivos nunca serão criados;

· CollectStatistics: true ou false. Opção para gerar ou não os gráficos de estatísticas do rrdcached.

Já no plugin network, configura-se o endereço IP e a porta que o collectd irá receber as conexões. A configuração do mesmo é apresentada na Listagem 16. Assim como realizado nos passos anteriores, adicione LoadPlugin network no arquivo collectd.conf.

Listagem 16. Configuração do plugin network servidor.

  <Plugin network>
    # server setup:
    Listen "10.211.55.10" "25566"
  </Plugin>

Como mencionado anteriormente, será necessário um front-end para exibir os gráficos. Dessa forma, para configurar o collection3, execute a sequência de comandos da Listagem 17. O conteúdo do arquivo /etc/httpd/conf.d/colletion3 é exibido na Listagem 18.

Listagem 17. Configurando o collection3 no servidor.

  # yum -y install httpd
  # vi /etc/httpd/conf.d/collection3
  # cp -r /opt/collectd-5.0.1/lib/perl5/site_perl/5.8.8/Collectd /usr/lib/perl5/site_perl/5.8.8/
  # cp -r /opt/rrdtool-1.4.7/lib/perl/5.8.8/x86_64-linux-thread-multi/* /usr/lib/perl5/site_perl/5.8.8/
  # cd /opt
  # tar xzvf perl-HTML-Entities.tar.gz -C /
  # tar xzvf perl-HTML-Parser.tar.gz -C /
  # tar xzvf perl-Config-General.tar.gz -C /
  # tar xzvf perl-URI-Escape.tar.gz -C /
  # tar xzvf perl-Regexp-Common.tar.gz -C /
  # tar xzvf collection3.tar.gz -C /var/www/html/
  # chown -R apache: /var/www/cgi-bin/collection3/
  # echo "DataDir \"/opt/collectd-5.0.1/var/lib/collectd/rrd\"" >> /var/www/cgi-bin/collection3/etc/collection.conf
  # echo "UnixSockAddr \"/var/run/collectd-unixsock\"" >> /var/www/cgi-bin/collection3/etc/collection.conf

Listagem 18. Configuração do collection3 para o httpd.

<Directory "/var/www/html/collection3/bin/">
    AllowOverride None
    Options +ExecCGI
    Order allow,deny
    Allow from all   
  </Directory>

Nestas listagens instala-se o Apache httpd através do yum, configura-se um virtual host para o collection3 e descompacta-se as bibliotecas Perl.

Conclusão

Por fim, se todas as configurações e comandos sugeridos foram realizados com sucesso, o browser apresentará os gráficos quando apontado para o endereço http://10.211.55.10/cgi-bin/collection3/bin/index.cgi. Lembre-se de considerar o tempo de atualização do rrdcached, pois configuramos para atualizar a cada 20 minutos.

Pronto, o monitoramento passivo está finalizado. Os dados já estão sendo monitorados e disponibilizados. Para completar sua infraestrutura de monitoramento, os próximos passos são analisar o ambiente para definir os thresholds e configurar um software para gerar os alertas.