Monitoramento de redes

Monitoramento de
redes com Shinken
CAPA

Nagios, o campeão dos sistemas de monitoramento de código aberto, parece

estar com problemas. Embora o software tenha se estabelecido como padrão, seu
desenvolvimento estagnou e seus concorrentes estão afiando suas garras.
por Gerhard Lausser

O
sistema de monitoramento
Nagios é uma ferramen-
ta popular para controlar
serviços e dispositivos de rede. Ad-
ministradores de sistemas de todo o
mundo dependem do Nagios e de
sua galeria de plugins para manter os
sistemas em execução e detectar os
problemas antes que eles ocorram.
Porém, alguns usuários do Nagios
veem espaço para melhorias.
A arquitetura do Nagios é pra-
ticamente a mesma desde que o
projeto foi fundado há dez anos,
e seu sucesso provocou gargalos
que levaram a atrasos na execução
de patches importantes para a co-
munidade.
O fork do Nagios chamado Icin-
ga, anunciado em meados de 2009,
causou um breve agito entre os de-
senvolvedores, e dois deles foram
adicionados à equipe, mas a situação
pouco se alterou. O lançamento do

“nagios.cfg“ Worker 1
“objects.cfg“
Worker 2
“shinken-specific.cfg“‚ Poller
Worker n
checks >> E»
checagens
F<<results
results
Árbitro ping
Worker 1
“pack“
Worker 2
Reactionner
eventhandler
manipulador de >>
evento E
notifications >>
notificações E Worker n
<< results
F results
Agendador

Merlin module
broks E
NDO Oracle module
Broker
Perfdata module

Figura 1 O processo único do Nagios é substituído por cinco processos em um sistema Shinken mínimo.

40 http://www.linuxmagazine.com.br

Nagios XI, um produto comercial
baseado no núcleo livre do Nagios,
deu origem a especulações de que o
principal desenvolvedor do Nagios,
Ethan Galstad, estava assumindo
outras tarefas que poderiam com-
prometer ainda mais o seu tempo.
Ao mesmo tempo, os sistemas
de monitoramento alternativos
tornaram-se mais competitivos ao
longo dos anos. Outras ferramentas
de código aberto, como o Zabbix
e o OpenNMS, estão começando
a se destacar no segmento corpo-
rativo, com suas ativas equipes de
desenvolvimento e, por serem mais
novos, estes sistemas alternativos
oferecem maior suporte às lingua-
gens de programação modernas e
a ambientes distribuídos.
Jean Gabès respondeu a estes
desafios lançando o Shinken, uma
nova implementação do Nagios na
linguagem Python. No final de 2009,
Gabès lançou uma versão inicial do
Shinken e ousadamente convidou
desenvolvedores para se dedicarem
a desenvolver uma futura versão 4 do
Nagios baseada no Shinken.
De acordo com Gabès, o Shinken
foi projetado para resolver alguns
problemas do Nagios:
falta de suporte adequado a
grandes ambientes e técnicas
corporativas contemporâneas,
como clustering;
o código base do Nagios, feito
em C e com dez anos de ida-
de, apresenta limitações para se
adaptar à rápida evolução das
redes atuais.
O objetivo do Shinken é propor-
cionar um novo modelo distribuído
de múltiplos processos que se adap-
te bem a ambientes heterogêneos e
distribuídos.
Arquitetura
Em contraste com o Nagios, o
Shinken não depende de uma abor-
dagem no estilo três-em-um, que usa
Linux Magazine #67 | Junho de 2010
um único processo para analisar a
configuração, organizar agendamen-
tos, executar checagens e processar
scripts. Em vez disso, o Shinken
usa múltiplos processos, e cada um
deles executa apenas uma parte do
trabalho. Esta abordagem melhora
o desempenho e permite que várias
partes do sistema completem suas ta-
refas sem que uma atrapalhe a outra.
Um sistema Shinken inclui cinco
processos (figura 1):
 rbiter (árbitro): o Arbiter é
A – os processos satélites (Pollers e
o processo mais importante e
é executado por último. Ele
analisa e valida os arquivos de
configuração. Após completar a
configuração e converter o que
foi encontrado em uma represen-
tação interna (na forma de obje-
tos Python), o Arbiter também
pode realizar uma etapa exclusiva
do Shinken: se o usuário tiver
definido vários Schedulers (agen-
dadores), o Arbiter fragmenta a
configuração em uma série de
segmentos, denominados packs,
e os distribui uniformemente pe-
los Schedulers. Uma “Shinken”
é uma espada japonesa afiada, e
foi desse processo de segmenta-
ção que o autor Jean Gabès teve
a idéia para o nome.
Scheduler (agendador): o Sche-
duler é responsável por registrar
o status dos hosts e serviços que
Listagem 1: Balanceamento de Carga
01 define poller{
02 poller_name poller-All-1
03 address shinken1.muc
04 port 7771
05 realm All
06 }
07 define poller{
08 poller_name poller-All-2
09 address shinken2.muc
10 port 7771
11 realm All
12 }
Monitoramento de Redes | CAPA
lhe são atribuídos e por se certifi-
car da execução de verificações,
manipuladores de eventos e no-
tificações. Ele também decide
quando uma falha deve disparar
um alarme e quais dependências
devem ser levadas em conside-
ração. No entanto, o Scheduler
não é responsável pela execução
do serviço ou pela checagem
do host, dos manipuladores de
eventos e scripts de notificação
Reactionners) cuidam da execu-
ção. O Scheduler simplesmente
adiciona tarefas para as filas que
os satélites analisam e processam
a cada segundo. Os resultados são
colocados em outra fila, que é
então analisada pelo Scheduler.
Poller: os Pollers fazem todo o
trabalho pesado. Eles captam ta-
refas atribuídas pelo Scheduler
(checagem de serviços e hosts)
e se certificam de que um con-
junto de processos esteja execu-
tando-as. Os resultados, códigos
de saída e plugins de saída são
devolvidos ao Scheduler uma
vez por segundo para avaliação.
Diferentemente do Nagios, os
resultados da checagem não
são arquivos. A comunicação
ocorre somente na memória.
Um Scheduler pode lidar com
qualquer número de Pollers, por
41
 CAPA  | Monitoramento de Redes

Listagem 2: Daemons desocupados evento (mudança de status do

serviço, analise de configuração,
01 define poller{ tempo de inatividade etc.), o
02 poller_name poller-All-1 Scheduler despeja uma estrutura
03 address shinken1.muc de dados, ou brok, em uma fila
04 port 7771 analisada a cada segundo pelo
05 realm All processo Broker. Vários módulos
06 } com código para processamentos
07 ... em curso podem ser atribuídos
08 define poller{ ao Broker. A safra atual inclui
09 poller_name poller-All-spare módulos para um banco de da-
10 address shinken9.muc dos NDO, um banco de dados
11 port 7771 Merlin, arquivos de host e de
12 realm All serviço Perfdata e muito mais.
13 spare 1
14 } Esta abordagem de múltiplos
processos torna mais fácil criar um
módulo que encaminhe os dados
isso é possível evitar os gargalos sos de um tamanho arbitrário. gerados para qualquer tipo de siste-
de desempenho com o acrésci- As vantagens que este daemon ma de terceiros. Mais uma vez, em
mo de mais nós Poller. oferece são óbvias, se considerar- contraste com o Nagios, o tempo
Reactionner: o Reactionner é mos que seu modelo, o Nagios, de inatividade do banco de dados
outro tipo de processo satélite. fica bloqueado para outras tare- não irá atrapalhar a configuração
É basicamente parecido com fas durante a execução de um do monitoramento. Mesmo quando
um Poller, exceto pelo fato de manipulador de eventos. status.dat, que pode ser enorme, está
não controlar checagens; ele Broker: o processo Broker é res- sendo escrito, não haverá atraso no
simplesmente processa mani- ponsável pela integração das processo central, pois a operação de
puladores de eventos e scripts ferramentas externas. É a con- escrita é feita de forma assíncrona.
de notificação. Mais uma vez, trapartida dos módulos Event Após distribuir a configuração, o
existe um conjunto de proces- Broker do Nagios. Para cada Arbiter se dedica ao monitoramen-
to do sistema Shinken. Ele faz um
ping nos componentes individuais e
efetua atualizações se a reconfigura-
cfg-1 cfg-2
ção dos caminhos de comunicação
Árbitro Agendador 1 Agendador 2 Agendador adicional se fizer necessária após uma falha
do componente.
Poller 1-1 Poller 2-1 Os vários processos do Shinken
Poller 1-2 Poller 2-2
podem existir em várias instâncias
para ajudar a distribuir a carga. Eles
nem mesmo precisam ser executados
2. habilitar 3. Pronto
agendador 1. Falha!
cfg-2
na mesma máquina. É muito fácil
estabelecer o balanceamento de
Árbitro Agendador adicional
Agendador 1 Agendador 2 carga com o Shinken: o usuário só
precisa configurar Pollers múltiplos
Poller 1-1 Poller 2-1 no arquivo shinken-specific.cfg e se
Poller 1-2 Poller 2-2
5. Escolher tarefas certificar de que são executados em
e retornar resultados
4. Reconfigurar para novo endereço várias máquinas (figura 2). A confi-
árbitro
guração para isso seria parecida com
o trecho na listagem 1.
Figura 2 O Shinken utiliza ferramentas internas para lidar com a distribuição Caso vários Schedulers sejam
de carga e failover. Coisas que eram complexas no Nagios são configurados, o Arbiter irá distribuir
muito mais simples nele. a configuração. O resultado é que

42 http://www.linuxmagazine.com.br
 Monitoramento de Redes | CAPA

cada Scheduler tem que lidar com ciso desativar algumas verificações aos Pollers para que eles verifiquem
aproximadamente o mesmo número ativas. O Shinken, no entanto, dis- hosts localmente (figura 3). Em ter-
de serviços. seca automaticamente uma única mos concretos, isso significa que uma
configuração do Nagios e a distribui empresa brasileira poderia usar um
Daemons Listagem 3: Gerador de configuração
de reposição
Daemons de reposição podem impe- 01 use Monitoring::Generator::TestConfig;
dir que o sistema tenha problemas no 02 my $mgt = Monitoring::Generator::TestConfig->new(
caso de uma falha. Nenhuma tarefa é 03 ‘output_dir’ => ‘/tmp/shinken_test’,
atribuída a um daemon de reposição 04 layout => ‘shinken’,
quando ele é iniciado, mas se um pro- 05 binary => ‘/usr/local/nagios/bin/nagios’,
cesso ativo falhar, o processo de repo- 06 overwrite_dir => 1,
sição entra em cena para substituí-lo. 07 hostcount => 10, # livre escolha
Esse mecanismo está disponível para 08 routercount => 1, # livre escolha
qualquer tipo de daemon. A listagem 09 services_per_host => 10, # livre escolha
2 mostra um exemplo. 10 host_settings => {
Um processo Poller chamado pol- 11 check_period => ‘24x7’,
ler-All-1 é executado no nó Shinken1 12 },
e executa plugins continuamente. 13 service_settings => {
Se esse processo ou todo o servidor 14 check_interval => 5,
Shinken1 (que é o mais provável) 15 retry_interval => 1,
travarem, o Arbiter detecta o inci- 16 },
dente. Então, ele envia um pedido 17 # Somente se for usado um usuário separado para o Shinken.
de ajuda ao Poller no nó Shinken9. 18 # Caso contrário, é o usuário atual.
O Poller, por sua vez, busca o Sche- 19 ‘main_cfg’ => {
duler responsável pelo nó, toma as 20 ‘nagios_user’ => ‘shinken’,
tarefas do Scheduler e as executa, 21 ‘nagios_group’ => ‘shinken’,
retornando os resultados para a fila 22 },
de resultado do Scheduler. 23 );
Do ponto de vista do Scheduler, 24 $mgt->create();
basicamente, nada mudou. Na verda-
de, não importa ao Scheduler quem
irá tomar as tarefas de checagem e
Árbitro
retornar os resultados. Nagios
cfg Broker global

Domínios “EU”
O Shinken permite a organização do cfg-1
“EU” Realm “US” “US” Realm
Scheduler, do Poller, do Reaction- cfg-2
ner e do Broker em um grupo lógico
conhecido como realm (domínio). EU
EU Reactionner US Reactionner
Se o atributo opcional realm for de- Agendador

signado a hosts ou grupos de hosts, US

EU Poller 1 EU Poller 3
eles só irão funcionar dentro de seus Agendador
próprios grupos de processos. Como
EU Poller 2
os processos do Shinken podem ser US Poller
executados em diferentes servido-
res, esta abordagem torna possível Hosts e host groups Hosts e host groups
a criação de um sistema distribuído. com “EU” realm com “US” realm
Com o Nagios, configurações
individuais eram necessárias para Figura 3 Domínios mantêm caminhos curtos no monitoramento distribuído -
posições individuais, ou seria pre- mesmo além das fronteiras nacionais e de continentes.

Linux Magazine #67 | Junho de 2010 43

 CAPA  | VirtualBox

Listagem 4: brokerd.cfg Poller na Argentina para verificar os

clientes em sua subsidiária argentina.
01 [daemon]
02
03
workdir=/tmp/shinken_test/var
pidfile=%(workdir)s/brokerd.pid Ambiente de teste
04 interval_poll=5 O Shinken ainda não está pronto
05 maxfd=1024 para uso em produção, mas, caso
06 port=7772 haja interesse em testar o seu po-
07 host=0.0.0.0 tencial, as seções a seguir mostram
08 user=shinken como criar um ambiente de teste.
09 group=shinken
Se você já tiver familiaridade com o
10 idontcareaboutsecurity=no
11 modulespath=/tmp/shinken_test/shinken/src/modules Nagios, tenha em mente que existem
algumas diferenças muito evidentes
por causa dos processos diferentes e
dos novos arquivos de configuração.
Listagem 5: Configuração do Broker Para começar, crie um diretório
01 define broker{ temporário para armazenar os fontes
02 broker_name broker-All do Shinken e todos os seus arquivos
03 address localhost de configuração e plugins. Após com-
04 port 7772 pletar o teste, é possível excluir esse
05 spare 0 diretório caso o programa não seja
06 realm All satisfatório. Os fontes do Shinken es-
07 manage_sub_realms 1 tão hospedados no SourceForge [1].
08 manage_arbiters 1 Baixe os códigos mais recentes
09 modules Status-Dat,Simple-log para o teste:
10 }
11
cd /tmp/shinken_test/
12 define module{
git clone git://shinken.git.
13 module_name Simple-log
14 module_type simple_log sourceforge.net/gitroot/shinken/
15 path /tmp/shinken_test/var/nagios.log shinken
16 }
17 Este comando cria um diretório
18 define module{ Shinken/, contendo o subdiretório
19 module_name Status-Dat src/. Posteriormente, o sistema será
20 module_type status_dat
21 status_file
iniciado a partir desse diretório.
/tmp/shinken_test/var/status.dat O módulo Perl Monitoring::Gene
22 object_cache_file /tmp/shinken_test/var/objects.cache rator::TestConfig, de Sven Nierlein,
23 status_update_interval 15 que cria automaticamente as confi-
24 } gurações do teste [2], ajuda bastante.
Com este módulo, é possível gerar um
conjunto de arquivos de configura-
ção, incluindo plugins, que reside em
Listagem 6: Iniciando o Shinken um único diretório selecionável sem
dependências externas. Para simular
01 cd /tmp/shinken_test/shinken/src
um ambiente real, os estados de host
02 python shinken-broker.py -d -c /tmp/shinken_test/etc/brokerd.cfg
03 python shinken-reactionner.py -d -c /tmp/shinken_test/etc/ e de serviço podem mudar em inter-
reactionnerd.cfg valos selecionáveis. O script Perl da
04 python shinken-poller.py -d -c /tmp/shinken_test/etc/pollerd.cfg listagem 3 cria um ambiente simula-
05 python shinken-scheduler.py -d -c /tmp/shinken_test/etc/
schedulerd.cfg do no diretório /tmp/shinken_test/.
06 python shinken-arbiter.py -d -c /tmp A chamada do script cria os arqui-
vos em /tmp/shinken_test/. O arquivo
brokerd.cfg serve como um exemplo
de arquivos de configuração do dae-

44 http://www.linuxmagazine.com.br
 VirtualBox | CAPA

Quadro 1: Fundações
Por ser feito em Python, o Shinken pode ser executado em qualquer sistema que possua uma implementação do
Python: isso inclui o Windows, o que significa que o Shinken poderia ser executado no sistema operacional da Micro-
soft sem necessidade de portabilidade. Para as pequenas empresas que desejem empregar o monitoramento de códi-
go aberto, mas não possuem o know-how em Unix necessário, este recurso definitivamente é interessante.

Essa portabilidade também se aplica a ambientes e cenários maiores, onde parte da infraestrutura de monitoramento
poderá ser baseada em Windows. Por exemplo, é possível atribuir todos os seus clientes Windows a um realm windo-
ws e instalar um Scheduler e Pollers separados.Todos os controles do Windows serão então executados em Windows
pollers dedicados.

mon; será preciso personalizar algu-
mas das configurações (listagem 4).
Os arquivos de configuração do
daemon compartilham os parâmetros
workdir, pidfile, port, host@, ``user,
group e idontcareaboutsecurity. Esses
parâmetros são auto-explicativos e
definem onde reside o arquivo PID,
em que porta e em qual endereço
IP o daemon escuta, e a conta do
usuário para o daemon. O último
parâmetro, idontcareaboutsecuri-
ty, só é significativo se o servidor
estiver sendo executado como root.
Normalmente, isso não é permitido,
mas se houver uma boa razão para
fazê-lo, será necessário definir esse
parâmetro como yes.
Configuração
do Broker
O caminho a partir da qual os módulos
de processamento individual são car-
regados é importante para o Broker.
Para definir esse caminho, é preciso
definir o argumento modulespath com o
caminho correspondente no diretório
de teste. Neste exemplo, o caminho é
/tmp/shinken_test/src/modules/.
Vale a pena investigar o arquivo
shinken-specifig.cfg neste momento.
Este arquivo contém todos os compo-
nentes para a instalação do Shinken
e é usado principalmente pelo Arbi-
ter com a finalidade de monitorar o
sistema e controlar remotamente os
seus membros.
Antes de iniciar o Shinken pela
primeira vez, é preciso configurar
o Broker (listagem 5) de modo que será possível ler as informações que os
pelo menos dois módulos existam. processos individuais enviam quando
Um é simplesmente um arquivo estão sendo executados.
de log em um estilo similar ao do Como mencionado anteriormente,
Nagios.Também faz sentido usar é possível usar os CGIs pertencen-
o módulo tipo status_dat. Ele cria tes a uma instalação já existente do
os arquivos objects.cache e status. Nagios para adicionar uma interfa-
dat necessários para verificar a ins- ce web para a instância do Shinken
tância ativa do Shinken a partir da que acabou de ser iniciada. Para isso,
interface web de uma instalação e basta definir o parâmetro main_con-
uma instalação do Nagios. fig_file no arquivo /usr/local/na-
gios/cgi.cfg com o valor /etc/tmp/
Pronto para a batalha shinken_test/nagios.cfg.
Depois de temrinar a preparação, você Outra possibilidade é configurar
já pode iniciar o sistema Shinken. o Broker para gravar em um banco
Para isso, entre no diretório /tmp/ de dados usando o módulo do Mer-
shinken_test/Shinken/src e execute os lin DB para o MySQL. O banco
comandos mostrados na listagem 6 su- de dados Merlin também é a base
cessivamente. O parâmetro -d executa para a interface web Ninja [3]. Esta
os programas em segundo plano. Se
você quiser saber o que está aconte-
configuração também oferece uma
máquina virtual, embora seja um
cendo, é possível deixar esse parâmetro pouco antiquada.
de fora e executar cada processo em Saber mais sobre o Shinken, visite
uma janela separada. Ao fazer isso, o site [4]. n
O autor
Gerhard Lausser é responsável por monitoramento na empresa ConSol com sede em Munique,
Alemanha. Publicou um guia prático do Nagios, assim como muitos plugins. Gerhard usa Linux há
mais de 15 anos e se considera um evangelizador do código aberto. Em seu tempo livre, pratica
Krav Maga e ajuda a desenvolver o Shinken.Gerhard Lausser. Gerhard Lausser trabalha na Con-
Sol em Munique, Alemanha. Ele instalou sua primeira versão do Linux em 1992 com uma pilha de
disquetes. Seu envolvimento com o Nagios começou em 2003, quando gerenciou uma grande im-
plantação de Linux numa fabricante de automóveis.
Gostou do artigo?
Queremos ouvir sua opinião. Fale conosco em
cartas@linuxmagazine.com.br
Este artigo no nosso site:
http://lnm.com.br/article/3522

Linux Magazine #67 | Junho de 2010 45