implementação da ferramenta zabbix para monitoramento reativo

IMPLEMENTAÇÃO DA FERRAMENTA ZABBIX PARA
MONITORAMENTO REATIVO
Thiago Fachini <[email protected]>
Alexandre Timm Vieira - Orientador <[email protected]>
Universidade Luterana do Brasil (ULBRA) – Tec. Rede de Computação
Canoas – RS – Brasil
27 de novembro de 2010
RESUMO
Este artigo descreve a implementação da ferramenta de monitoramento Zabbix em uma empresa de
desenvolvimento de software e prestadora de serviços de TI. Este documento demonstra a analise feita sobre o
parque computacional, a modelagem da ferramenta para o cenário existente na empresa, e demonstra como
automatizar a recuperação de determinados serviços, sem intervenção humana.
Palavras-chave: monitoramento; ativo ; infraestrutura.
ABSTRACT
Title: “Implementation of tool Zabbix for reactive monitoring”
This paper describes the implementation of the Zabbix monitoring tool in a software development company
and provider of IT services. This paper demonstrates the analysis done on the park computational modeling tool
for the existing scenario in the company, and demonstrates how to automate the recovery of certain services,
without human intervention.
Keywords: monitoring; active; infrastructure.
1
INTRODUÇÃO
Segundo Lessa (1999), “Estatisticamente, enquanto 30% dos custos de uma infraestrutura
computacional estão diretamente associados à aquisição de hardware, os 70% restante dizem respeito à
manutenção e suporte aos recursos e serviços nela contida.” Portanto, o monitoramento da infraestrutura
computacional, torna-se uma atividade que contribui decisivamente para o funcionamento contínuo dos
serviços oferecidos, garantindo que a qualidade destes mantenha-se em níveis satisfatórios pelo maior tempo
possível.
Apesar das recentes e constantes pesquisas na área de gerenciamento e monitoramento de
infraestrutura computacional, ainda há carência de técnicas e ferramentas que suportem tanto o
desenvolvimento, quanto a implementação de agentes reativos em sistemas de monitoramento. As
ferramentas desta área, possuem muitos recursos úteis, mas entre elas não há alguma que possua a
capacidade de reagir aos resultados coletados, executando ações no ativo monitorado, dando ao sistema de
monitoramento a inteligência e autonomia necessária para atuar na correção de falhas detectadas.
Ou seja, as ferramentas de monitoramento atuais apenas colhem informações dos ativos e no
máximo reportam ao operador se alguma falha ocorrer, tendo este que resolver simples problemas
manualmente e com um gasto maior de tempo, do que se a falha fosse resolvida logo após ter sido detectada
pelo próprio sistema de monitoramento. Sendo então, de extrema importância o apoio de uma ferramenta
que possua as condições de fazer a análise e efetuar as ações necessárias para corrigir a falha detectada no
serviço, interagindo então no menor tempo possível de atraso, sem intervenção humana.
O objetivo principal deste artigo é demonstrar a possibilidade de automatizar as resoluções de falhas
e evitar possíveis falhas, utilizando a própria ferramenta que estará monitorando o serviço ou ativo, visando
também incentivar a adoção e aprimoramento deste tipo de ferramenta pelas empresas e equipes de TI.
Neste artigo, serão utilizadas as áreas de gerenciamento e monitoramento de infraestrutura
computacional, adotando as boas práticas da biblioteca ITIL, e um pouco da área de inteligência artificial,
mais especificamente na área de agentes, onde haverá um sistema de monitoramento, com banco de regras e
ações pré-definidas, que através dos resultados dos dados coletados reagirá ao status dos serviços, atuando
como um agente reativo.
A fundamentação teórica utilizada neste artigo esta descrita na Seção 2, seguida pela Seção 3, onde
descreve-se a analise e modelagem do ambiente, e pela Seção 4, descrevendo a implementação, e os
resultados descritos na Seção 5.
2
FUNDAMENTAÇÃO TEÓRICA
Independente do tamanho de uma rede de computadores, ela precisa ser gerenciada, para garantir aos
usuários qualidade e disponibilidade de serviços ao um nível de desempenho aceitável. Por isso é importante
para uma equipe de TI (Tecnologia da Informação) conhecer informações sobre os componentes de sua rede,
como: seus equipamentos de rede (switch, repetidores, roteadores, etc), especificação de hardware e software
dos seus servidores e estações, os serviços disponíveis aos seus usuários e etc.
Segundo Rigney (1996): “O gerenciamento de rede é o procedimento que consiste em controlar
todos os componentes de hardware e software da rede.”
Os usuários esperam sempre uma melhoria dos serviços oferecidos, ou no mínimo, a mesma
qualidade, quando novos recursos são adicionados ou quando são distribuídos, e seus vários grupos de
usuários necessitam de recursos computacionais diferentes, sendo função da equipe de TI atribuir e controlar
os recursos para balancear estas várias necessidades.
Para auxiliar a equipe de TI, no gerenciamento de seu parque computacional e seus serviços
fornecidos, ou seja suas necessidades de governança, há várias abordagens com modelos para a
implementação de um sólido sistema de gerenciamento, como CobIT, FCAPS, ITIL, ISO/CMIP, MOF, e
outros. Há uma grande esforço, atualmente, para adotar modelos baseados na entrega e no suporte de
serviços, como a biblioteca ITIL, desenvolvido pela United Kingdom ́ s Office of Government Commerce
(OGC).
2.1
ITIL (Information Technology Infrastructure Library)
A ITIL é uma série de livros e manuais, que foi criado como um esforço para disciplinar e permitir a
comparação entre as propostas dos diversos proponentes a prestadores de serviços de TI para o governo
britânico, haja vista a grande adoção da metodologia de gerenciamento denominada outsourcing e da
subcontratação de serviços de TI pelos seus diferentes órgãos, agências e instituições, objetivando garantir
um mínimo de padronização de atendimento em termos de processos, terminologia, desempenho, qualidade
e custo.
Dentre os fatores motivadores da atual corrida pela adoção das práticas reunidas na ITIL, pode-se
citar o incremento dos seguintes aspectos:
•
Custos de entrega e manutenção dos serviços de TI.
•
•
•
•
•
Requerimentos da organização em relação à qualidade e ao custo/benefício dos serviços de TI.
Demanda em obter a medição do retorno dos investimentos em TI.
Complexidade da infraestrutura de TI.
Ritmo de mudanças nos serviços de TI.
Necessidade de disponibilidade dos serviços de TI.
•
Aspectos relacionados com a segurança.
Ou seja, com suas métricas claras e objetivas, a ITIL permitiu medir a real contribuição da área de
TI em relação aos lucros, a redução de custos, a melhoria dos serviços e principalmente transmitir aos
investidores a mensagem de que agora temos no “pé da empresa o sapato de número correto”. A ITIL trata a
gestão da infraestrutura de TI de diversas formas, sendo o resultado final um aumento na confiança nos
serviços de TI. Este aumento traduziu-se na redução de riscos, pois o grau de certeza das atividades de
negócio que tem TI como meio de execução tornou-se maior e os custos das redundâncias operacionais
foram eliminados.
Os livros sobre ITIL adotados para este artigo são o Service Support e o Service Delivery, eles
descrevem os principais objetivos do gerenciamento de serviços e os processos chave para melhorar a
qualidade dos serviços de TI, alinhando-os com as necessidades do negócio da empresa. Os processos de
gerenciamento de serviços podem ser agrupadas em operacionais (Service Support) e táticas(Service
Delivery), conforme descritos a seguir.
As competências operacionais (Service Support) são:
• Incident Management – Tem por meta o restabelecimento da normalidade operacional dos
serviços de TI no menor tempo possível. Este processo define as atividades e responsabilidades
para minimizar os impactos e atender os níveis de serviços acordados.
• Problem Management – Tem por meta identificar as causas dos incidentes e corrigir os erros de
forma preventiva. O processo define as atividades e responsabilidades para solucionar os erros,
reduzir o tempo necessário para resolver os problemas dentro dos níveis de serviços acordados.
• Change Management – A meta deste processo é melhorar a operação do dia-a-dia de TI. O
processo assegura o correto uso de padrões e processos para um rápido e eficiente atendimento
das mudanças através do planejamento, controle e suporte das mudanças e identificação dos
riscos e impactos.
• Configuration Management – Tem por meta controlar a infraestrutura de TI assegurando o uso do
hardware e software homologados. O processo define as atividades de controle e relacionamentos
dos itens de configuração que compõe a infraestrutura de TI.
• Release Management – A meta deste processo é assegurar que somente versões autorizadas e
corretas estejam disponibilizadas, e que apenas softwares licenciados sejam instalados. O
processo assegura que todos os aspectos (técnicos ou não) sejam atendidos.
E as competências táticas (Service Delivery) são:
• Service Level Management – A meta deste processo é manter e melhorar o nível de qualidade
dos serviços de TI através da eliminação dos serviços de baixa qualidade. O processo define as
atividades de planejamento, coordenação, desenvolvimento, monitoração e comunicação dos
acordos dos níveis dos serviços. Também define as atividades de revisão dos acordos para
garantir a melhoria constante da qualidade com redução dos custos.
• Capacity Management - O processo define as atividades de gestão e previsão de recursos de TI
através da monitoração, análise e planejamento das métricas e condições operacionais. O
processo visa manter o equilíbrio da oferta e procura dos recursos da tecnologia.
• Availability Management – A meta deste processo é otimizar a infraestrutura, serviços e suporte
de TI para que a disponibilidade (com custos aceitáveis) permita que o negócio alcance os seus
objetivos. O processo define com o negócio os requisitos da infraestrutura, serviços e suporte de
TI, para endereçar as necessidades da oferta e demanda da disponibilidade de TI.
• IT Continuity Management – É o processo de gerenciamento dos recursos organizacionais,
técnicos e humanos para garantir que os serviços de TI estejam dentro do risco aceitável de
continuidade do negócio. O processo define um ciclo contínuo de avaliação de riscos, medidas de
contorno, revisão dos cenários e planos de contingência para garantir a aderência contínua ao
Plano de Continuidade do Negócio.
• Financial Management – Tem como meta dar transparência aos custos de TI. O processo define a
metodologia e as atividades para o desenvolvimento e acompanhamento do orçamento e dos
critérios de rateio do investimento e despesa de TI.
2.2
Gerenciamento de rede
O gerenciamento de redes pode ser dividido em duas categorias de atividades:
• Monitoramento: É uma função destinada a observação e análise do estado e comportamento dos
dispositivos gerenciados.
• Controle: É uma função destinada a alteração de parâmetros de gerenciamento que acarretam
ações junto aos dispositivos gerenciados.
“Um sistema de gerenciamento de rede é composto por ferramentas para o monitoramento e controle
da rede”(Teixeira, 1999, p.356), que são controladas pela equipe de TI, e que cabe a ela escolher as melhores
ferramentas e a melhor maneira de controlar esses recursos.
Os softwares utilizados no gerenciamento são divididos em agentes e gerentes e estão presentes em
estações de trabalho, servidores, switches, roteadores, e outros. Ou seja, estão presentes nos ativos.
Um bom ambiente de gerenciamento de rede deve ser composto pelas entidades que se deseja
monitorar (agentes), e por uma entidade responsável para adquirir as informações (gerente), sendo assim
centralizando a fonte de informações.
• Entidade Gerente: Também conhecido como NMS (Network Management Stations), consiste em
uma entidade de rede que usa determinados protocolos das camadas de transporte, de rede e de
aplicação, para a comunicação com a entidade de rede gerenciada (agente). O gerente
compreende um tipo de software que permite a obtenção e o envio das informações de
gerenciamento, junto aos mecanismos gerenciados mediante comunicação com um ou mais
agentes. As informações de gerenciamento podem ser obtidas com o uso de requisições efetuadas
pelo gerente ao agente, como também, mediante envio automático disparado pelo agente a um
determinado gerente. Tipicamente um gerente está presente em uma estação de gerenciamento de
rede.
“O computador gerente é considerado como o coração do sistema de
gerenciamento de rede e como tal deve-se fornecer atenção redobrada ao mesmo.”
(TEIXEIRA,1999,p.358)
• Entidade Agente: O agente por sua vez consiste na materialização da entidade gerenciada,
compreendendo um tipo de software presente junto aos dispositivos gerenciados. A função
principal de um agente compreende o atendimento das requisições enviadas por um software
gerente e o envio automático de informações de gerenciamento ao gerente, indicando a
ocorrência de um evento previamente programado. Também compete ao agente efetuar a
interface entre os diferentes mecanismos usados na instrumentação das funcionalidades de
gerenciamento inseridas em um determinado dispositivo gerenciado. Para os agentes, não existe
passado nem futuro, pois as suas ações são baseadas nas informações colhidas pelo sensor
naquele instante e atua no meio através das regras contidas na sua base de conhecimentos. Por
isso, quando cessa a percepção do ambiente cessa a ação.
2.3
Inteligência Artificial (IA)
Tem-se como definição histórica que a IA é a área da Ciência da Computação que, ao mesmo tempo
que é recente -1956- é também muito antiga, pois já vem sendo formada a partir de ideias cientificas e
tecnológicas herdadas de outras ciências, tendo como exemplo a lógica com seus 23 séculos.
“IA é a parte da ciência da computação voltada para o desenvolvimento de
sistemas de computadores inteligentes, i.e. sistemas que exibem características, as
quais nós associamos com a inteligência no comportamento humano - e.g.
compreensão da linguagem, aprendizado, raciocínio, resolução de problemas, etc.”
(FEIGENBAUM, 1981).
Na IA os agentes, segundo Wooldridge (1994), são definidos como “sistemas que apresentam um
comportamento que é determinado por um processo de raciocínio baseado na representação de suas atitudes,
tais como crenças, comprometimentos e desejos. Um sistema pode ser visto como um agente se possuir as
seguintes propriedades: autonomia, habilidade social, reatividade e pró-atividade.” E, segundo Russell
(1995), “um agente é tudo o que pode ser considerado capaz de perceber seu ambiente por meio de sensores
e de agir sobre esse ambiente por intermédio de atuadores”.
Estes conceitos, com uma visão mais atualizada, também são encontrados na obra de Koch e
Westphall (2001):
• Agentes podem ser guiados por metas e baseados em regras, sendo que um conjunto de regras
constitui a base de conhecimento para qualquer sistema e as metas são os objetivos de trabalho
dos agentes. Definimos metas estáticas como parâmetros de configuração fixados na criação do
agente, e metas dinâmicas aquelas adicionadas ao comportamento inicial do agente e que foram
derivadas de mudanças do ambiente ou de mensagens recebidas.
• Agentes devem ser capazes de aprender novas habilidades (skills), e essas novas regras podem
ser armazenadas dinamicamente nas bases locais de conhecimento dos agentes; outra
possibilidade é inferir novas regras a partir do conhecimento atual do ambiente.
Na IA também encontramos um bom conceito para um Sistema Multiagente, que segundo Ferber
(1999), “consiste em uma aplicação distribuída composta por um conjunto de processos autônomos,
heterogêneos, distribuídos e inteligentes denominados “agentes”, que cooperam entre si para a resolução de
um problema complexo que está além das suas capacidades individuais”.
2.4
Sistemas Especialistas
Segundo Rolston (1988), “programas de computador que tentam resolver problemas que os seres
humanos resolveriam emulando o raciocínio de um especialista, aplicando conhecimentos específicos e
inferências são ditos Sistemas Especialistas”.
Ou seja, sistemas especialistas são sistemas que solucionam problemas que são solucionáveis apenas
por pessoas especialistas (que acumularam conhecimento exigido) na resolução destes problemas.
A solução de um problema proposto por um sistema especialista é voltado para uma determinada
área de conhecimento e é fornecido por pessoas que são especializadas nesta área. Esse conhecimento
adquirido permite-lhe emitir decisões, justificadas e apoiadas, por uma base de informações, agindo como se
fosse um especialista humano de determinada área de conhecimento.
2.5
Agentes Inteligentes em Gerência de Redes
Analisando as áreas de gerência de redes, considerando-se suas características estáticas ou
dinâmicas, e conforme o tipo de comportamentos para solucionar os problemas: reativo ou pró-ativo.
Devemos primeiramente, preocupar-nos em definir o problema, e se o problema poderá ser representado
matematicamente por uma função. Resolvê-lo será então encontrar um modo de implementar esta função ou
de aproximá-la com o conhecimento que se dispõe.
Após a definição do problema é necessário definir o comportamento de gerência que será adotado:
reativo quando as ações de gerência são realizadas após o aparecimento de algum problema; ou, pró-ativo no
caso de se adotar um gerenciamento com ações preventivas.
Outra questão é determinar se a solução do problema deve ter características estáticas ou dinâmicas.
Estáticas quando não existe o conceito de estado, e dinâmicas quando forem identificados trocas de estados
na solução do problema.
Com base na metodologia apresentada, e ilustrado no Quadro 1 a seguir, indica-se as seguintes
aplicações para as principais áreas funcionais de gerência de redes definidas pelo modelo de referência ITIL.
Quadro 1: Características das áreas funcionais de gerência de redes
Comportamento de Gerência
Características
Área Funcional
Reativa
Pró-ativa
Estáticas
Dinâmicas
Falha
Desempenho
Configuração
Contabilização
Segurança
A gerência de falha pode assumir os dois tipos de comportamento. Reativo no caso de falhas
impossíveis de se prevenir, como é o caso das falhas provocadas pela ação do ambiente ou provocadas pela
má qualidade de peças e equipamentos utilizados. Ou poderá ser pró-ativo no caso de falhas relacionadas ao
desempenho da rede, como por exemplo, a sobrecarga da rede. Estes comportamentos poderão ter problemas
de caráter estático ou dinâmico.
A gerência de desempenho deve ser pró-ativa em todos os seus aspectos. É uma forma preventiva de
garantir a qualidade do serviço oferecido aos usuários. A gerência de configuração normalmente é reativa
com características dinâmicas. O dinamismo é identificado pelo crescimento do número de equipamentos e
de usuários que altera o estado da rede.
A gerência de contabilização é estática e reativa. E a gerência de segurança pode ser tanto reativa
quanto pró-ativa. Contém características dinâmicas, uma delas é o controle de acesso que é diretamente
ligado ao número de usuários. Com esta interpretação é possível definir se o problema a ser resolvido
necessita de agentes autônomos estáticos ou dinâmicos.
A utilização de agentes no processo de gerência de redes de computadores introduz as seguintes
características:
• Diminuição do tráfego entre o agente e o nó gerenciável: A redução do tráfego de rede é uma
consequência natural neste modelo de gerenciamento de redes, uma vez que o processo de
aquisição e análise de informações é levado mais perto do (ou mesmo no próprio) local do objeto
gerenciado. Ele age como um filtro das informações coletadas do dispositivo e repassadas para os
gerentes do sistema de gerenciamento.
• Maior abstração dos objetos gerenciáveis pelos gerentes: Tendo em vista que muitas decisões
podem ser tomadas diretamente pelos agentes, algumas das características e atributos do objeto
gerenciado podem ser abstraídas pelos módulos gerentes ou mesmo alguns objetos gerenciados
podem ser agregados em uma unidade abstrata.
• Maior agilidade na tomada de decisões: Sendo que as decisões estão mais próximas dos objetos
gerenciados, trazendo-se o processo de decisão para perto destes objetos evita-se a necessidade de
comunicação com um sistema central.
• Maior adaptabilidade do sistema: O ideal dos agentes é estar preparado para quaisquer mudanças
no ambiente onde estiver inserido e pronto para reagir positivamente a estas. Com agentes, o nó
gerenciável passa a ter "autonomia" com relação aos gerentes do ambiente, principalmente em
questões não críticas. Desta forma, a gerência de rede torna-se mais automatizada.
2.6
A Ferramenta Zabbix
Zabbix é uma ferramenta de monitoramento com capacidade para um vasto número de parâmetros,
ele é idealizado para monitorar e controlar o funcionamento dos ativos e seus serviços. O Zabbix possui um
flexível mecanismo de alarmes que permite aos usuários configurar e-mail, mensagem instantânea e SMS
para receber os alertas se algum evento ocorrer com os mecanismos gerenciados, e sendo corretamente
configurado pode executar comandos remotos permitindo uma fácil resolução do problema encontrado nos
ativos monitorados.
Zabbix oferece excelentes características de relatórios e visualização de dados armazenados, isso o
torna ideal para o planejamento de capacidade. Todos os relatórios e estatísticas do Zabbix, bem como as
configurações dos parâmetros são acessados através de uma interface gráfica na web. Propriamente
configurado o Zabbix pode ter um papel importante em monitorar toda a infraestrutura de TI, isso é
aplicável tanto para pequenas empresas com poucos servidores, quanto para grandes empresas com muitos
servidores.
Zabbix possui suporte para mecanismos polling (forma de capturar dados de tempo em tempo) e
trapping (notificação de alarmes), oferecendo agentes de alta performance nativos, entre as principais estão
GNU/Linux, Microsoft® Windows®, IBM® AIX®, HP-UX® e a família BSD, monitoramento sem um agente
instalado, ou com agentes SNMP ou IPMI, autenticação segura de usuário utilizando criptografia dos dados,
permissões flexíveis de usuários, flexível notificação de eventos predefinidos, execução de comandos
remotos, alto nível de visualização de recursos monitorados.
Uma ferramenta de gerência de redes deve possuir algumas funções básicas para tratar as áreas da
gerência, então se baseando nestas funções, o Zabbix possui as seguintes características:
• Monitoramento de recursos (desempenho): Um dos mais importantes usos do Zabbix é o
monitoramento da utilização dos recursos, como carga de processamento, quantidade de
processos ativos, atividade no disco rígido, utilização da memória virtual e disponibilidade da
memória física são alguns de inúmeros parâmetros de sistemas que ele é capaz de monitorar. Mas
não apenas a utilização geral dos recursos do ativo, como também individualizar e monitorar
cada serviço e seus recursos consumidos. Ele prove informações em tempo real sobre os recursos
de um ativo. Além disso, ele pode produzir gráficos de tendências para ajudar na identificação de
gargalo no desempenho do sistema.
• Mecanismo de alerta e execução de comandos remotos: O Zabbix possui um poderoso
mecanismo de notificação automatizado e dependendo do caso a autorrecuperação do serviço
com a execução de comando remoto ordenado pela entidade gerente à entidade agente. Com ele,
um administrador pode definir uma possível condição para um gatilho, usando flexíveis
expressões. Em algum momento quando essas condições forem verdadeiras (ou falsas), um alerta
será enviado por e-mail para um endereço definido pelo administrador e o(s) comando(s)
executado(s) no cliente. Programas externos podem ser usados para notificar o usuário como
SMS (notificação por celular) e Jabber (mensagem instantânea). Com a utilização de expressões
flexíveis, para os gatilhos, o Zabbix permite que a equipe de TI seja notificada bem antes do
estado do sistema alcançar um nível crítico.
• Verificação de Integridade: Zabbix é capaz de verificar a integridade do ativo. Todos os arquivos
de configuração críticos, binários, kernel, scripts e páginas HTML de servidores web podem ser
monitorados permitindo que o administrador possa ser alertado toda vez que um desses arquivos
forem alterados.
• Armazenamento de Dados e Serviços de Auditoria: Todos os valores dos parâmetros monitorados
são armazenados em banco de dados (MySQL, PostgreSQL ou Oracle). Os dados coletados
podem ter seu armazenamento ajustado dinamicamente de acordo com a preferencia, e serem
usados mais tarde para qualquer propósito. O Zabbix também gera uma auditoria das alterações
realizadas pelos usuários, para em caso de algum problema possa tentar identificar quem as fez e
o que foi feito.
3
MODELAGEM
A empresa de desenvolvimento de software Fachini System Ltda, atua na área de criação de sistemas
de ERP, BI, CRM e utilitários de manutenção destes sistemas. Fornecem também aos seus clientes serviços
de manutenção e monitoramento dos servidores que possuem os seus sistemas.
Neste artigo além de abordarmos o monitoramento da estrutura de ativos da Fachini System,
também abordaremos o monitoramento da Fachini Diesel Ltda, o principal cliente da Fachini System, que
atua como distribuidor no comércio de peças para motor à diesel.
A Fachini System utiliza várias ferramentas de monitoramento, como Cacti, MRTG e Ntop, e
algumas desenvolvidas pela própria empresa para sanar determinadas necessidades, mas essas ferramentas
não geram alertas e muitas são descentralizadas e individuais, como o Ntop, onde o operador deve acessar os
ativos individualmente para poder analisar os dados capturados.
Então visando criar um ambiente amigável e único aos operadores de suporte, tanto para monitorar
quanto para alertá-los sobre as falhas, será realizado um estudo sobre seus ativos de rede, para assim poder
ter um levantamento exato de quais suas necessidades de monitoramento, avaliando desta forma como será
estruturada a ferramenta Zabbix, para assim atender melhor as necessidades da Fachini System.
3.1
Analise do ambiente
Conforme ilustrado na Figura 1 a seguir, o parque computacional da Fachini System é formado por
quatro servidores, dois roteadores, alguns equipamentos de clientes para VPN (Virtual Private Network),
dois links para acesso à Internet. A rede ethernet é fornecida pelo switch Dell PowerConnect 2724, sendo
dividida em duas zonas separadas por vlan (Virtual Local Address Network), a rede denominada VLAN0 é
portadora do domínio de colisão da LAN (Local Area Network), enquanto a rede denominada VLAN1 é
portadora do domínio de colisão da DMZ (DeMilitarized Zone). Estas vlan são configuradas diretamente no
switch, onde a VLAN0 inicia no porta 1 e termina na porta 16, e a VLAN1 inicia na porta 17 e termina na
porta 24.
Figura 1 – Rede Fachini System
A seguir a Figura 2 ilustra a rede da Fachini Diesel Ltda, esta empresa além de utilizar os aplicativos
desenvolvidos pela Fachini System, também utiliza os serviços de manutenção e monitoramento dos seus
servidores. A Fachini Diesel possui oitos lojas espalhadas pelo Brasil. Conforme demonstrado na Figura 2,
há uma loja em cada estado, e sua estrutura computacional é igual em todas as lojas, tendo um servidor para
área de trabalho remota e um servidor de dados, com diferença apenas para os Centro de Distribuição em
“Filial – SC” e “Filial – MT” que possuem apenas o servidor de dados. A comunicação entre as lojas é feita
pela Internet por VPN entre seus roteadores.
Figura 2 – Rede Bombas Diesel Ltda
Com os cenários acima especificados, foi realizado uma analise das necessidades de monitoramento
de cada ativo, como muitos ativos possuem igualdade tanto de hardware quando de serviço oferecido, eles
foram agrupados, e seus serviços subdivididos, conforme demonstrados no Quadro 2 a seguir, sendo
também especificado a criticidade do serviço, os critérios para os gatilhos e as ações que estes gatilhos irão
disparar.
Ativos
server01
srvts01
tssp01
tsrs01
tspr01
tsms01
Serviços
Quadro 2 – Avaliação dos ativos
Critici Métrica de monitoramento Critério para gatilho
dade
Hospedagem de
site
Média
Gerenciamento
de banco de
dados
Média
Armazenar e
compartilhar
arquivos
Alta
Controle de
versões
Alta
Área de trabalho
remota
Alta
Consumo geral de
processador, memória física
e virtual, atividade de rede e
espaço em armazenamento
livre.
Consumo de memória por
serviço.
Disponibilidade do ativo e
seus serviços.
Integridade dos principais
arquivos.
Ações
Inatividade do
servidor
Comunicar por email
Inatividade dos
serviços
Comunicar por email e iniciar
serviço
Espaço livre menor
que 10%
Comunicar por email e adicionar
espaço
Alto consumo de
memória e
processamento por
dez minutos
Comunicar por email
Alterações
nos Comunicar por earquivos monitorados mail
Consumo geral de
processador, memória física
e virtual, atividade de rede e
espaço em armazenamento
livre.
Quantidade de usuários.
Disponibilidade do ativo e
seus serviços.
Integridade dos principais
arquivos.
Inatividade do
servidor.
Comunicar por email
Inatividade do
serviço.
Comunicar por email
Espaço livre menor
que 10%.
Comunicar por email
tsgo01
tsmg01
dadossp01
dadosrs01
Gerenciamento
de banco de
dados
dadospr01
Armazenar e
compartilhar
dadosms01 arquivos
Alta
Alta
dadosgo01
Consumo geral e por serviço
de processador, memória
física e virtual, atividade de
rede e espaço em
armazenamento livre.
Disponibilidade do ativo e
seus serviços.
Integridade dos principais
arquivos.
dadosmg01
dadossc01
proxy01
Comunicar por email
Inatividade do
servidor.
Comunicar por email
Inatividade dos
serviços.
Comunicar por email e iniciar
serviço
Espaço livre menor
que 20%.
Comunicar por email
Alto consumo de
memória e
processamento por
vinte minutos
Comunicar por email
Alterações nos
Comunicar por earquivos monitorados mail
dadosmt01
ftp01
Alto consumo de
memória e
processamento por
trinta minutos
Transferência de Média
arquivos por FTP
Proxy web
Média
Cache DNS
Média
srvdmz01
Filtrar entrada e
saída (netfilter)
Alta
router01
Tradução de IP
(NAT)
Alta
Consumo geral e por serviço
de processador, memória
física e virtual, atividade de
rede e espaço em
armazenamento livre.
Disponibilidade do ativo e
seus serviços.
Inatividade do
servidor.
Comunicar por email
Inatividade dos
serviços.
Comunicar por email
Espaço livre menor
que 5%.
Comunicar por email
Consumo geral e por serviço
de processador, memória
física e virtual, atividade de
rede e espaço em
armazenamento livre.
Disponibilidade do ativo e
seus serviço.
Inatividade do
servidor.
Comunicar por email
Inatividade dos
serviços.
Comunicar por email
Espaço livre menor
que 5%.
Comunicar por email
Consumo geral de
processador, memória física
e virtual, atividade de rede e
espaço em armazenamento
livre.
Disponibilidade do ativo.
Integridade dos principais
arquivos.
Inatividade do
roteador.
Comunicar por email
Alto consumo de
memória e
processamento por
dez minutos
Comunicar por email
Alterações nos
Comunicar por earquivos monitorados mail
VPN entre as
lojas
Alta
Proxy web
Média
rtpr01
Proxy MSN
Média
rtms01
Cache DNS
Média
rtgo01
Priorizar entrada
e saída (QoS)
Alta
Filtrar entrada e
Alta
rtsp01
rtrs01
rtmg01
Consumo geral de
processador, memória física
e virtual, atividade de rede e
espaço em armazenamento
livre.
Consumo de memória por
serviço.
Disponibilidade do ativo e
seus serviços.
Integridade dos principais
arquivos.
Inatividade do
roteador.
Comunicar por email
Inatividade dos
serviços.
Comunicar por email e iniciar
serviço
Espaço livre menor
que 10%.
Comunicar por email
Alto consumo de
memória e
processamento por
dez minutos
Comunicar por email
rtsc01
saída (netfilter)
Comunicar por eAlterações nos
mail
arquivos monitorados
rtmt01
xen01
Virtualização
Média
xen02
Disponibilidade do ativo e
seus serviços.
Integridade dos principais
arquivos.
Inatividade do
servidor.
Comunicar por email
Alterações nos
Comunicar por earquivos monitorados mail
A comunicação por e-mail será apenas para o endereço de suporte ([email protected]), pois há
uma ferramenta que captura esses e-mails e repassa ao responsável pelo suporte em forma de tarefa, e este
delega as tarefas aos operadores do suporte.
O Quadro 3, a seguir, detalha como deverá ser realizado o monitoramento de cada item do ativo,
como tipo de valor e o intervalo de captura, esse detalhamento é necessário para que possamos parametrizar
corretamente os gatilhos.
Quadro 3 – Detalhamento dos itens
Descrição do Item
Tipo de valor
Intervalo de captura
(segundos)
Disponibilidade do
ativo
Booleano
60
Tempo de resposta do
ativo
Segundos
30
Espaço em
armazenagem livre
Porcentagem (%)
1800
Informações Gerais
Caracteres
86400
Tempo de atividade
Tempo
3600
Memória física e
virtual total
Bytes
86400
Memória física e
virtual livre
Porcentagem (%)
120
Carga média de
processamento (load
average)
Decimal fracionário
120
Processamento ocioso
ou utilizado
Porcentagem (%)
120
Trafego de rede
(entrada e saída)
Bytes
60
Integridade de
arquivos
Checksum
3600
Consumo de memória
do serviço
Bytes
120
Atividade do serviço
na rede
Booleano
60
Tempo de resposta do
serviço
Segundos
60
Processos do serviço
em execução no ativo
Decimal
120
4
IMPLANTAÇÃO
Com o ambiente anteriormente especificado e suas necessidades de monitoramento mapeadas,
partiremos para a implementação da ferramenta de monitoramento Zabbix.
Um dos pontos fortes do Zabbix é a utilização dos templates (modelos), pois com eles é possível
ajustar parâmetros uma única vez para os diversos tipos de ativos que serão monitorados. É conhecido que a
ferramenta trás consigo na instalação uma grande variedade de templates, mas estes não serão utilizados,
porem alguns parâmetros dos templates existentes serão utilizados, como base e exemplo para a criação dos
templates que serão criados.
Nos templates serão criados e ajustados os parâmetros dos itens e das triggers (gatilhos), e alguns
gráficos, a ferramenta automaticamente gera gráficos e históricos individuais para todos os itens, mas
também podemos definir gráficos mais específicos com a junção de vários itens. As triggers serão
disparadas de acordo com os valores do itens, gerando o sinal de alerta, e somente com este sinal o gerente
da ferramenta Zabbix, irá realizar as ações pré-definidas, como enviar e-mail ou enviar os comandos que os
agentes irão executar.
O Zabbix disponibiliza uma rica dashboard (painel de indicadores), ilustrado na Figura 3 a seguir,
onde o operador pode visualizar as atividades principais da ferramenta, como os itens monitorados e os
gatilhos disparados. Ao passar ou clicar com o mouse em cima dos itens em vermelho, como em “Status do
sistema” e “Status do Host”, aparecerá uma janela com os detalhes e os gatilhos que acusam o problema.
Figura 3 - Dashboard
4.1
Instalação da ferramenta Zabbix
Para instalação do ambiente em que o servidor Zabbix será executado, Zabbix Server, foi utilizado o
S. O. Debian Lenny x86, encontrado em “http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian506-i386-CD-1.iso”, após a instalação do sistema básico a partir da imagem, foi instalado as ferramentas
complementares requeridos pelo Zabbix, através da ferramenta “aptitude”, da própria distribuição, que são:
apache2, dbconfig-common, fping, libapache2-mod-php5, libcurl3-dev, libcurl3-gnutls, libiksemel3,
libmysqlclient15-dev, libsnmp-dev, mysql-server, php5, php5-gd, php5-mysql, php-net-socket, php-xmlparser, php-xml-util, sendemail, snmpd, openipmi, libphp-jabber, libiksemel-dev, libopenipmi-dev, e suas
dependências.
Após a preparação do ambiente acima, foi realizado o download da ferramenta Zabbix em
“http://sourceforge.net/projects/zabbix/files/ZABBIX%20Latest%20Stable/1.8.3/zabbix1.8.3.tar.gz/download” e seguido o passo a passo de instalação que está disponível no site do desenvolvedor
da ferramenta, em “http://www.zabbix.com/documentation/1.8/manual/installation#zabbix_server1”, não
entraremos nos detalhes da compilação e instalação da ferramenta do servidor Zabbix, pois conforme o link
acima o seu desenvolvedor possui uma vasta documentação para este fim. Para a instalação dos agentes,
Zabbix Agent, em ambiente GNU/Linux foi utilizado as versões disponibilizadas pelas próprias
distribuições e no ambiente Microsoft ® Windows® será utilizado os agentes fornecidos, também pelo
desenvolvedor da ferramenta, disponibilizado em “http://www.zabbix.com/download.php”.
Cabe ressaltar que a versão gerente, o Zabbix Server, está hospedado no servidor xen01, mas logo e
de acordo com a necessidade ele será migrado para um equipamento dedicado. Isso é possível não apenas
porque ele trabalha com banco de dados, mas também porque permite exportar todos os templates, ativos
monitorados, telas, mapas e outras configurações para arquivos XML, que poderão ser importados em
qualquer servidor Zabbix.
4.2
Criação de Templates
Para o monitoramento dos ativos será criado dois templates, um para o S. O. GNU/Linux e outro
para o S.O. Microsoft® Windows®, e um template especifico para cada serviço a ser monitorado.
Na Figura 4, a seguir, temos um exemplo dos templates para S. O. GNU/Linux e Microsoft®
Windows®, neles podemos verificar que para cada item a ser monitorado, ou seja cada informação a ser
coletada, serão ajustados parâmetros como a “Chave” utilizada pelo Zabbix Server para solicitar a
informação ao Zabbix Agent, o intervalo de tempo, em segundos, em que cada captura será realizada, e por
quantos dias serão armazenados os históricos e as estatísticas dessas capturas. Há também o “Status” do item
monitorado, que pode ser ajustado para “Ativo” ou “Inativo”, mas se este valor for ajustado no template,
será ajustado para todos os ativos vinculados a ele, sendo o ideal realizar esse ajuste diretamente no ativo. O
template para o S. O. Microsoft ® Windows® é praticamente idêntico, sendo diferenciado pela integração com
o “Perfomance Monitor”(perf_counter), do próprio Windows ®, em alguns itens.
Figura 4 – Template GNU/Linux e Microsoft® Windows®
A seguir, na Figura 5, temos um exemplo de “Item” do template GNU/Linux, nele vemos que
podemos definir uma série de valores, como os mencionados anteriormente, sendo mais importante os itens
como o “Tipo” de agente utilizado para a captura, podendo ser o agente Zabbix passivo ou ativo, agentes
SNMP versão 1, 2 e 3, IPMI, SSH, Telnet, monitoração simples, como um ping, e outros. O “Tipo de
informação” será definido de acordo com o valor a ser recebido e armazenado pelo Zabbix Server, podendo
ser fracionário, inteiro sem sinal, carácter, log ou texto. Em conjunto com o “Tipo de informação” está a
“Unidade”, como para o Zabbix Server a resposta do Zabbix Agent é apenas um dado, devemos especificar
o que esse dado representa e, se necessário, como tratá-lo nos campos “Use custom multiplier” e
“Armazenar valor”, no caso do exemplo, a coleta de bytes entrante na interface de rede para o S. O.
GNU/Linux é retornado em Bps, bytes por segundo, enquanto no S. O. Microsoft ® Windows® é retornado
em bps, bits por segundo. Outro parâmetro muito importante é flexibilização do intervalo de captura, onde
temos o campo para intervalo fixo e padrão, e outro campo que poderemos incluir vários intervalos
diferenciados, apenas para ilustrar o exemplo estamos utilizando um intervalo padrão de 120s (segundos),
enquanto no intervalo flexível ajustamos a captura para 60s no horário das 07hs (horas) até as 20hs, nos dias
semanais de segunda-feira até sábado.
Ainda na Figura 5, temos o campo “Mostrar valor”, que realiza o mapeamento de valores como um
simples ping que se retornar 0 (zero) será mapeado como “Down” e se rertonar 1 (um) será mapeado como
“Up” ou como o retorno de valores do Dell OpenManage que ao retornar 3 será “OK”, 4 “Advertencia” e 5
“Erro”, e por último o campo “Aplicações” que serve como um classificador, juntando os itens em um
conjunto comum para melhor visualização no monitoramento.
Figura 5 – Exemplo de item
Em geral os templates criados para os S.O. GNU/Linux e Microsoft® Windows®, abrangem a captura
de informações sobre o status e desempenho do ativo monitorado, com consumo de processador e memória,
vazão de dados na interface de rede, disponibilidade de armazenamento em disco, integridade de arquivos e
informações do ativo.
Já os templates criados para monitorar os serviços, além de monitorarem o consumo destes, também
verificam a disponibilidade e o tempo de resposta para o usuário do serviço, conforme ilustrado na Figura 5
a seguir, que através do Zabbix Agent captura medidas sobre a atividade do processo. Um exemplo a parte é
o que demonstra a Figura 6, pois nele temos uma integração do Zabbix Agent com a ferramenta
“squidclient”, uma ferramenta de comunica com a API da ferramenta Squid para coletar dados sobre o status
do serviço de cache/proxy web. Essa integração funciona com o Zabbix Agent sendo uma agente ativo para
coletar as informações, e passivo apenas para reportar os dados coletados, ou seja, o Zabbix Agent possuirá
uma lista de itens para coletar automaticamente, armazenando-os temporariamente até o Zabbix Server
solicitar os dados.
Como exemplo dessa integração, temos o item “Squid – Cache em Disco Usado”, que coletará a
porcentagem de cache em disco usada pelo Squid através da ferramenta “squidclient”, essa coleta ocorre
com o Zabbix Agent executando o comando “squidclient mgr:storedir | grep "Percent Used"| ...”no ativo,
armazenando os resultados em buffer, conforme parâmetro ajustado no agente e ilustrado na Figura 6 em
fundo preto, e a cada 300s o Zabbix Server solicita ao agente as informações coletadas.
Figura 6 – Template de Serviço
Na Figura 7 a seguir temos a ilustração das triggers para o “Template_Linux”, nela podemos
verificar que as triggers são classificados de acordo com a criticidade no campo “Risco” (Informação,
Advertência, Médio, Alto ou Desastre), e que cada “Expressão” está relacionada a um ou vários itens. Essa
possibilidade de se utilizar vários itens em uma trigger nos dá a possibilidade de criar gatilhos como o
“Alterado regras de netFilter em {HOSTNAME}”, onde juntamos os itens que verificam a integridade dos
arquivos de regras de netfilter (iptables) em uma única trigger, sendo apenas separados por um “OU” lógico,
sem a necessidade de se criar uma trigger para cada item. Assim como a trigger “Alto consumo de Memoria
em {HOSTNAME}”, que é um “E” lógico entre os itens “Memoria Fisica Livre” e “Memoria Virtual
Livre”, sendo este gatilho apenas ativado quando a memória física estiver durante dez minutos menor que
10% e a memória virtual livre estiver, também no intervalo de dez minutos, menor que 70%.
Figura 7 - Triggers
4.3
Cadastramento de ativos (Hosts)
O cadastramento de ativos é um processo simplificado e intuitivo, conforme ilustrado na Figura 8 a
seguir, em parte graças aos templates, sendo as informações mais importantes o “Nome DNS” ou “Endereço
IP”, para que possamos dizer ao Zabbix como conectar-se ao ativo no parâmetro “Conectado a”, os
templates utilizados pelo ativo e seu inventário, onde podemos descrever tudo sobre o ativo, como tipo de
ativo, qual S. O., o número de série ou de imobilizado, descrição de hardware e software, datas de instalação
e compra, a localidade do ativo e outros.
Figura 8 – Cadastro de ativos
4.4
Ações
O cadastro das ações a serem executadas, podem ser parametrizadas para um único ativo ou para
vários ativos, conforme ilustrada a seguir na Figura 9, temos uma ação que irá enviar um comando para o
agente executar no ativo monitorado. Neste exemplo temos a demonstração da ação para executar o script
“add_squid”, ilustrado com fundo preto, que estará armazenado no ativo, no campo “Condições de ação”
devemos ajustar as condições e o tipo de cálculo, neste caso a ação somente será executada se a trigger
“Espaço em disco livre menor que 10% em /squid” (D) estiver com o valor indicativo de “PROBLEMA” (E)
se o intervalo não for de segunda a sábado das 05hs até as 0hs (F), e somente poderá ser executada nos
ativos especificados, como o server01 (A), ou RTSP01 (B) ou RTRS01 (C).
Figura 9 – Exemplo de ação
O exemplo da Figura 9 anteriormente demonstrada, também está com os parâmetros ajustados para
o envio de e-mail, conforme visto na janela “Ação”, estes parâmetros são as variáveis de ambiente, que o
Zabbix trata como macros, que são coletados ou preenchidos na hora da execução da ação. Conforme Figura
9 o campo “Assunto” do e-mail será composto pelo nome do ativo e o status da trigger, o corpo da
mensagem trará informações como data e hora do envio da mensagem, um histórico contendo data, hora e a
quanto tempo ocorre o problema, a descrição com o último valor capturado, e sua criticidade. Para o envio
da mensagem de aviso por e-mail o usuário que será notificado deve ter um e-mail ajustado no seu cadastro,
e este e-mail deve estar ajustado na campo “Operações da Ação”.
5
RESULTADOS
Os dados capturados podem ser acompanhados em tempo real, de forma geral pela dashboard ou
detalhadamente pela guia “Dados Recentes”, ilustrada na Figura 10 a seguir. Na “Dados Recentes” podemos
verificar quando foi realizado a última captura, o último valor captura e a variação deste valor com relação
ao anterior, no “Histórico” podemos gerar um gráfico com todos os valores capturados ou apenas visualizar
os valores em uma tabela.
Figura 10 – Dados recentes
A melhora obtida pela automatização de ações como adição de espaço de armazenagem e
inicialização de serviços parados foi significativa. Conforme exemplo ilustrado na Figura 11 a seguir,
podemos verificar um aumento no espaço de armazenamento livre da partição “/apache” de 8,2% para
54,1%, ação que foi realizado automaticamente pelo Zabbix, pois ao receber as informações da captura
constata que está abaixo dos 10% estipulados e altera a trigger para o estado indicativo de “PROBLEMA”,
o que faz disparar a ação que envia o comando ao Zabbix Agent, que executará o script.
Figura 11 – Demonstração de ação
Para ter certeza que foi a ferramenta Zabbix quem realizou a operação descrita no paragrafo anterior,
é gerado um registro de eventos. Na Figura 12, a seguir, esta o registro da ação que adicionou o espaço de
armazenamento na partição “/apache”, nele podemos contatar o “Status” como executado no campo “Ações
de comando”, se a ação tivesse falhado o “Status” estaria como falha. Também podemos certificar a
agilidade que a ferramenta Zabbix realizou o procedimento, ao verificarmos o campo “Data” em “Detalhes
do evento” e o campo “Data” em “Ações de comando”, constatamos que a ferramenta levou apenas 2s para
processar o dado recebido, disparar o gatilho e efetuar a ação, claro que o procedimento do script levou mais
que 2s para finalizar sua execução no ativo, pois conforme a Figura 11, houve um intervalo de captura
(14:16) sem dados retornado, justamente porque o procedimento estava em execução.
Figura 12 – Registro de ação executada
Os resultados obtidos com a inicialização dos serviços estão ilustrados na Figura 13 a seguir, onde
propositalmente realizamos a parada do serviço Apache (invoke-rc.d apache2 stop), e seguindo intervalo de
captura de 120s ajustado para o serviço, constatamos que o Zabbix após a coleta (22:10:15), iniciou o
serviço automaticamente, ou seja, o serviço após parado ficou inativo por menos de dois minutos, sendo
inicializado sem intervenção humana.
Figura 13 – Ação serviço
6
CONSIDERAÇÕES FINAIS
O problema de descentralização e da existência de várias ferramentas para o monitoramento da
infraestrutura e dos ativos, foi sanado com a implementação da ferramenta Zabbix, a qual trouxe outros
ganhos com sua capacidade de reagir ao ambiente monitorado, seja enviando simples alertas por e-mail,
como também a execução de ações nos ativos, corrigindo falhas ou evitando que elas ocorram.
Como a ferramenta Zabbix possui uma grande capacidade de integração com o ambiente
monitorado, e graças a essa integração reage de forma eficaz, acredito que o objetivo de demonstrar a
possibilidade de automatizar a prevenção e resolução de falhas, utilizando-se da reatividade de uma
ferramenta de monitoramento está cumprida, como também acredito que essas funcionalidades podem ser
aprimoradas e aperfeiçoadas pelos seus utilizadores e por pesquisadores das áreas de gerência de redes e
inteligência artificial.
O que nossa equipe de TI está analisando e testando atualmente é a integração com os gerenciadores
de banco de dados Firebird e InterBase, para retirar as estatísticas de utilização dos bancos de dados, e
realizar o backup e a restauração destes, no momento ou antes de chegaram nos limites dos registradores. E
se possível realizar ações para corrigir bancos de dados danificados.
Duas grandes funcionalidades que não foram abordadas neste artigo, por no momento não haver
utilidade para a Fachini System, é o Zabbix Proxy, e a procura e registro automatizados dos ativos, onde o
Zabbix Server irá vascular a rede local identificando ativos e adicionando-os automaticamente ao seu
monitoramento, ou identificando os Zabbix Agent que irão automaticamente se comunicar com ele.
O Zabbix Proxy atua como um Zabbix Server colhendo informações dos ativos, mas de acordo com
o intervalo configurado, envia esses dados para o Zabbix Server principal, mantendo assim centralizado a
informação para os operadores da ferramenta. Esta ferramenta pode ser útil onde boa parte dos clientes
possuam, internamente, a mesma faixa de endereçamento IPv4, o que poderia levar a problemas de NAT e
colisões com mesmo endereço IPv4 nos ativos monitorados, ou mesmo evitando sobrecarregar o trafego de
rede, com o trafego gerado pelo monitoramento.
REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, Maicon Melo. Linux: Performance & Monitoramento. Ed. Brasport, 2009. 201p.
COSTA. Felipe. Ambiente de Rede Monitorado com Nagios e Cacti. Ed. Ciência Moderna, 2008. 216p.
FEIGENBAUM, Edward A. e Barr, Avron. The Handbook of Artificial Intelligence. Wm. Kaufman,
1981.
FERBER, Jacques. Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence.
Addison-Wesley Professional, 25 fev. 1999. 528p.
KOCH, Fernando Luiz e WESTPHALL, Carlos Becker. Decentralized Network Management using
Distributed Artificial Intelligence. Journal of Network and Systems Management. Plenum Publishing
Corporation. Estados Unidos da América, 2001. p. 291-313.
LESSA, Demian, O Protocolo de Gerenciamento RMON. Rede Nacional de Ensino e Pesquisa (RNP) 15
jan. 1999. Disponível em: <http://www.rnp.br/newsgen/9901/rmon.html>. Acesso em: 17 fev. 2010
MAGALHÃES, Ivan Luizio e PINHO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática . Ed.
Novatec, 2007. 672p.
OGC. Service Delivery. Londres – Inglaterra: The Stationary Office, 2000.
OGC. Service Support. Londres – Inglaterra: The Stationary Office, 2000.
RIGNEY, Steve. Planejamento e gerenciamento de redes. Ed. Campus, 1996. 257p.
ROLSTON, David W. . Principles of Artificial Intelligence and Experts Systems. Mcgraw-Hill, jan.
1988. 257p.
RUSSELL, Stuart, NORVIG, Peter. Artificial Intelligence: A Modern Approach. Prentice-Hall, 30 dec.
2002. 1132p.
SOARES, Vicente N. Redes de Dados, teleprocessamento e gerência de redes. Ed. Érica, 1990. 200p.
TEIXEIRA, Ramos. Redes de Computadores, serviços, administração e segurança. Ed. Makron Books,
1999.
VIEIRA. Prof. Alexandre Timm. Disciplina Gerência de Redes, 2009 [material disponibilizado em aula]
WOOLDRIDGE, Michael, JENNINGS, Nicholas. Intelligent Agents: Theory and Practice. Knowledge
Engineering Review, 1994.