UNIVERSIDADE ABERTA DO BRASIL ESAB CURSO DE PS GRADUAO LATO SENSU EM ENGENHARIA DE SISTEMAS

MARCO AURLIO FERREIRA

ZABBIX Ferramenta de gerenciamento e monitoramento

VILA VELHA ES 2013

MARCO AURLIO FERREIRA

ZABBIX Ferramenta de gerenciamento e monitoramento

Monografia apresentada ao Curso de Ps Graduao em Engenharia de Redes da Escola Superior Aberta do Brasil como requisito para obteno do ttulo de Especialista em Engenharia de Sistema, sob orientao do Prof. Dr. Caribe Zampirolli de Souza.

VILA VELHA ES 2013

MARCO AURLIO FERREIRA

ZABBIX Ferramenta de gerenciamento e monitoramento

Monografia aprovada em _ _ _ de _ _ _de 2014.

Banca examinadora

_________________________

_________________________

_________________________

VILA VELHA ES 2013

DEDICATRIA

A Deus e a famlia.

RESUMO

O presente trabalho tem como objetivo avaliar a viabilidade na implantao da ferramenta de monitoramento e gerenciamento: Zabbix analisando o desempenho e a disponibilidade do ambiente operacional que tem seus negcios sustentado pela Tecnologia da Informao TI, contextualizado na Diretria de Tecnologia da Informao da Prefeitura de Aparecida de Goinia Palavras-chave: Zabbix. Monitoramento. TCP/IP. SNMP.

LISTA DE TABELAS

Figura 1 Modelo OSI -----------------------------------------------------------------------------3 Figura 2 Servio -----------------------------------------------------------------------------------8 Figura 3 - Pontos de Acesso de servios (SAPs) -----------------------------------------10 Figura 4 Estrutura lgica da MIB ------------------------------------------------------------18 Figura 5 Planificao da MIBII ---------------------------------------------------------------20 Figura 6 Objetos gerenciados atravs de suas MIBs ----------------------------------23 Figura 7 Gerente e objetos gerenciados --------------------------------------------------24 Figura 8 Gerente e agente, TCP/IP ---------------------------------------------------------25 Figura 9 Mensagem SNMP -------------------------------------------------------------------27 Figura 10 Formato PDU, GET E SET ------------------------------------------------------27 Figura 11 Formato PDU, Trap ----------------------------------------------------------------27 Figura 12 Servidores com agente instalado, monitorado -----------------------------46 Figura 13 Elementos gerenciveis, windows server 2003 ----------------------------47 Figura 14 Elementos gerenciveis, SCO, servidor apache --------------------------48 Figura 15 Servidor gerenciado durante 3 meses, duas semanas e 1 dia --------49 Figura 16 Classificao dos eventos -------------------------------------------------------50 Tabela 1 Objetos passveis de informao-------------------------------------------------20

SMARIO

1. INTRODUO ------------------------------------------------------------------------------1 2. MODELO OSI ISO 7494 ----------------------------------------------------------------3 2.1 A CAMADA FSICA -----------------------------------------------------------------------5 2.2 A CAMADA DE ENLACE ----------------------------------------------------------------5 2.3 A CAMADA DE REDE -------------------------------------------------------------------6 2.4 A CAMADA DE TRANSPORTE -------------------------------------------------------6 2.5 A CAMADA DE SESSO ---------------------------------------------------------------7 2.6 A CAMADA DE APRESENTAO ---------------------------------------------------8 2.7 A CAMADA DE APLICAO -----------------------------------------------------------8 2.8 SERVIOS ----------------------------------------------------------------------------------9 2.8.1. Servios conectados e sem conexo ------------------------------11

3. PROTOCOLO SNMP ---------------------------------------------------------------------13 3.1 MIB - MANAGEMENT INFORMATION BASE -----------------------------------17 3.2 CONSTRUO -------------------------------------------------------------------------18 3.3 ESTRUTURA -----------------------------------------------------------------------------19 3.4 SNMP - Simple Network Management Protocol ---------------------------------22 4. ZABBIX ---------------------------------------------------------------------------------------29 4.1 CARACTERSTICAS DO ZABBIX --------------------------------------------------30 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.1.7. 4.1.8. Monitoramento de desempenho ------------------------------------31 Mecanismo de alerta ---------------------------------------------------31 Monitoramento de arquivos de logs -------------------------------32 Verificao de Integridade -------------------------------------------32 Servios de Auditoria --------------------------------------------------32 Capacidade de Planejamento ----------------------------------------33 Monitoramento do SLA -------------------------------------------------33 Visualizao de alto nvel dos recursos e servios de TI----33

4.2 REQUISITOS ----------------------------------------------------------------------------35 4.2.1. 4.2.2. 4.2.3. Requisitos de Hardware -----------------------------------------------35 Plataforma suportadas ------------------------------------------------- 35 Requisitos de Software -------------------------------------------------36

4.3 COMPONENTES DO ZABBIX -------------------------------------------------------37 4.4 INSTALAO ----------------------------------------------------------------------------38 4.4.1. 4.4.2. 4.4.3. Servidor ---------------------------------------------------------------------38 Agente -----------------------------------------------------------------------41 Interface WEB -------------------------------------------------------------43

5. ESTUDO DE CASO -------------------------------------------------------------------------44 5.1 CARACTERIZAO DO AMBIENTE ----------------------------------------------44 6. CONCLUSO --------------------------------------------------------------------------------50 7. REFERNCIAS -----------------------------------------------------------------------------51

1 1 Introduo

Devido a alta disponibilidade que a maioria dos sistemas computacionais requer, no ambiente cada vez mais competitivo a acesso a informao, incorporado pelos seus atributos: confidencialidade, integridade, disponibilidade, autenticidade; representa uma vantagem competitiva, um diferencial. Dessa maneira, seria vivel a implantao da ferramenta zabbix para o gerenciamento e monitoramento proativo do data center, infra estrutura, da Prefeitura de Aparecida de Goinia de modo eficiente almejando essa disponibilidade?

O presente trabalho tem como objetivo geral apresentar a viabilidade e as vantagens da implantao da ferramenta zabbix para o gerenciamento e o monitoramento pro ativo dos componentes de infraestrutura, data center, da Prefeitura de Aparecida tendo como objetivos especficos: Contextualizar, relacionar o conhecimento apresentado nas disciplinas do curso com a ferramenta de gerenciamento e monitoramento; Avaliar a possibilidade sugesto de aprimoramento da ferramenta de gerenciamento e monitoramento; Identificar o desempenho do sistema; Identificar a disponibilidade dos componentes da infraestrutura; Identificar a integridade do sistema; Analisar do valor/benefcios que a ferramenta esta agregando ao negcio.

O trabalho consistira no estudo de caso da ferramenta zabbix no data center da Prefeitura como ferramenta de gerenciamento e monitoramento.

Coleta de dados: Sero originados pelos prprios logs da aplicao.

Anlise de dados: Verificar a eficincia, a eficcia e a viabilidade na utilizao da ferramenta de

2 gerenciamento monitoramento observando se a mesma condizente com o referencial terico.

MODELO OSI - ISO 7498

Uma maneira interessante de se ter uma viso, compreenso mais ampla sobre determinada realidade, assunto que se apresente complexo dividir em partes menores de forma que as mesmas possibilitem o entendimento individualizado e assim tem-se a possibilidade da compreenso, viso do todo atravs de suas partes.

Dessa forma a fim de simplificar, padronizar a comunicao em redes de computadores, facilitando sua compreenso tem-se o padro internacional ISO 7498, denominado Open Systems Interconnection Reference Model RM-OSI 7498, fornecendo uma base comum que permite o desenvolvimento coordenado de padres para interconexo de sistemas.

A denominao Open Systems Interconnection , OSI, qualifica padres para o intercmbio de informaes entre sistemas. Para isso a ISO, Organizao de Padronizao Internacional, especificou os servios e ou funcionalidades que deveriam ser atendidas a fim de ter o estabelecimento de uma comunicao deixando livre a forma como cada fabricante envolvido nesse processo ir fazer para implementar o servio e ou funcionalidade (TANENBAUM, 2010).

Para que dois sistemas quaisquer possam trocar informaes necessrio que escolham opes compatveis de servios e ou funcionalidades atravs da implementao de protocolos especficos para cada uma das camadas do modelo, conforme se observar no decorrer do presente consistindo na definio de servio.

O projeto de protocolos em nveis a maneira mais organizada de se estruturar uma rede. Uma vez definida claramente a interface entre os diversos nveis, uma alterao na implementao de um nvel pode ser realizada sem causar impacto na estrutura global. O nmero, o nome, o conjunto de funes e servios e o protocolo de cada camada variam de uma arquitetura de rede para outra.

4 Inicialmente, cada fabricante desenvolveu sua prpria arquitetura. Tais arquiteturas foram denominadas proprietrias por serem controladas por uma nica entidade: o prprio fabricante. Para permitir o intercmbio de informaes entre equipamentos de fabricantes distintos tornou-se necessrio definir uma arquitetura nica. Foi com esse objetivo que a International Organization for Standardization (ISO) definiu o modelo denominado Reference Model for Open Systems Interconnection ISO 7498, que props uma estrutura com sete camadas, nveis, como referncia para a arquitetura dos protocolos das redes de computadores.

Embora o modelo OSI da ISO possa ser usado tanto em redes de longa distncia quanto em redes locais, ele foi, em princpio, pensado para o uso em redes de longa distncia. O conjunto de padres IEEE 802 foi uma iniciativa do Institute of Electrical and Electronics Engineers (IEEE) para definir padres para as camadas: fsica e enlace.

O modelo OSI composto por sete camadas apresentadas na figura 1. O modelo OSI no uma arquitetura, posto que no especifica os protocolos empregado pelas camadas. Entretanto, a ISO tem produzido protocolos para as sete camadas, publicados como padres internacionais.

Figura 1 Modelo OSI

2.1

A CAMADA FSICA

A camada fsica a responsvel pela gerao dos sinais eltricos, ticos ou eletromagnticos que sero propagados pelo meio fsico. A funo do nvel fsico permitir o envio de uma cadeia de bits por um meio fsico sem se preocupar com o seu significados ou com a forma como esses bits so agrupados, (COLCHER, 2005). Protocolos nesta camada especificam qual a durao e intensidade do sinal, tcnica de multiplexao, pinagem, etc.

2.2

A CAMADA DE ENLACE

A camada de enlace utiliza a camada fsica para a transmisso de quadros de dados (data frames). Tipicamente um quadro de dados e composto de algumas centenas de bytes. Quadros so delimitados por sequencias pre-estabelecidas de bits. A camada de enlace transmite (recebe) quadros de dados, aguardando (enviando) o respectivo quadro de reconhecimento de recepo.

6 A transmisso de quadros, mesmo com reconhecimento de recepo, no e confivel. Quadros podem ser duplicados ou chegar fora de ordem. A duplicao ocorre quando o quadro de reconhecimento e deformado, tornando-se ininteligvel pelo receptor. O receptor, neste caso, envia novamente o quadro de dados correspondente por falta de reconhecimento, gerando assim a sua duplicao.

A camada de enlace tambm controla o fluxo de quadros, evitando que um host envie quadros em uma taxa superior a que o receptor e capaz de processar. O principal objetivo desse nvel efetuar o controle de erros e o controle de fluxo em cada enlace da rede (COLCHER, 2005).

2.3

A CAMADA DE REDE

A camada de rede controla a operao da subrede. Uma de suas funes e o roteamento e o encaminhamento possibilitando independncia da camada de nvel superior: transporte para as funcionalidades mencionadas do host de origem ao host de destino (COLCHER, 2005). O roteamento pode apresentar caractersticas dinmicas, evitando gargalos em certos roteadores, ou estticas, empregando-se sempre a mesma rota entre dois hosts. Outra funo desta camada e a

fragmentao e remontagem de pacotes para atender a limites impostos por determinados segmentos da subrede de comunicao. Em subredes de difuso e redes locais esta camada e extremamente simples, dado que sua principal atribuio (roteamento) e inexistente nestas subredes.

2.4

CAMADA DE TRANSPORTE

7 A funo principal da camada de transporte e receber dados da camada de sesso, particionar estes dados em unidades menores e, em certos casos, garantir que estas unidades cheguem a seu destino sem duplicao e na ordem correta.

Esta camada possui tipicamente dois tipos de servios: um servio rpido onde mensagens so limitadas em tamanho e no existe garantia de entrega, ordem ou ausncia de duplicao; e um servio mais lento, porm altamente confivel e sem limites de tamanho nas mensagens. Um terceiro servio, difuso de mensagens para todos os hosts da subrede, pode estar disponvel nesta camada.

No caso de servio com entrega confivel, a camada de transporte e responsvel pela remontagem dos quadros oriundos da camada de rede, respeitando a ordem em que foram enviados e descartando duplicaes.

E funo tambm desta camada o controle do fluxo de dados entre dois processos comunicantes (a camada de rede controla o fluxo apenas entre roteadores).

No nvel de transporte a comunicao fim fim isto : a entidade do nvel de transporte da mquina de origem se comunica com a entidade de nvel de transporte da mquina de destino. O que no acontece nas camadas anteriores: fsica, enlace e rede em que a comunicao a nvel de enlace, (COLCHER, 2005).

2.5

CAMADA DE SESSO

Esta camada permite dois processos de aplicao (APs: Application Processes) estabelecerem sesses informao. entre si a fim de organizar e sincronizar a troca de as

Para tal, uma conexo de sesso e estabelecida, definindo-se

regras de dialogo entre os dois APs. Existem trs variantes de dialogo quanto ao sentido do fluxo de dados: TWS (Two Way Simultaneous): bidirecional

simultaneamente, TWA (Two Way Alternate): bidirecional alternadamente (um por

8 vez), e OW (One Way): unidirecional. Sesses podem ser suspensas e retomadas a posteriori, bem como manter pontos de sincronismo (checkpoint) para posterior retomada a estes pontos face a ocorrncia de erros.

2.6

CAMADA DE APRESENTAO

Esta camada fornece servios de representao cannica de dados, compresso de dados e criptografia. Uma representao cannica dos dados se faz necessria quando hosts de arquiteturas diferentes devem se comunicar.

Por exemplo, a representao de nmeros em ponto flutuante varia de arquitetura para arquitetura. Quando um float e transmitido, o mesmo e convertido para uma representao padronizada, enviado atravs da rede, e reconvertido na

representao adotada pelo host de destino. A camada de apresentao dispe de um protocolo para tal (EDR: External Data Representation).

Compresso de dados e teis para o envio de grandes massas de dados como imagens e textos. Criptografia e utilizada quando os dados a serem transmitidos so confidenciais e visa evitar sua interceptao em transito por pessoas no autorizadas. Protocolos para compresso e criptografia de dados tambm so definidos nesta camada.

2.7

A CAMADA DE APLICAO

Esta camada dispe de servios comumente utilizados por usurios de redes. Correio eletrnico, transferncia de arquivos, login remoto, servios de diretrio e gerencia de redes so exemplos destes servios. Esta camada tambm se constitui

9 no ponto de acesso a rede por processos de aplicao (APs) (COLCHER, 2005)

2.8

SERVIOS

O modelo de referncia no especifica por si s o comportamento de sistemas abertos, ou seja, servios e protocolos. Ele basicamente cria o contexto no qual uma detalhada especificao de servios e protocolos possa ser suportada pelo sistema aberto. Do ponto de vista da abstrao, os vrios nveis envolvidos

relacionando modelo de referncia, servios, protocolos e implementao de um protocolo, (TANENBAUM, 2010), como se observa na figura 2.

Figura 2 Servio

O modelo de referncia permite a especificao de varias classes de servio. Cada classe de servio permite a especificao de varias classes de protocolo onde o nvel mais baixo e representado pela implementao do protocolo. O modelo de referncia OSI procura fornecer uma viso global de um sistema organizado atravs de uma rede. Esta viso, por outro lado, divide a rede em camadas horizontais cuja finalidade consiste em:

permitir uma discusso da interao entre elementos pares, ou seja,

10 elementos que situam-se em uma mesma camada; esta discusso deve ocorrer sem levar em conta componentes das outras camadas; a funcionalidade de cada camada pode ser desenvolvida de forma modular e

gradual; o sistema aberto pode ser visto como uma sucesso de sub-sistemas

facilitando o desenvolvimento de uma implementao modular do mesmo.

Os elementos ativos em cada camada so chamados entidades. Uma entidade pode ser um componente de software: um processo, por exemplo; ou de hardware: um controlador de estrada/sada, por exemplo. As entidades na camada N

implementam servios usados na camada N + 1. Neste contexto, a camada N e denominada provedora de servios enquanto a camada N + 1 e denominada usuria de servios.

Servios so disponveis nos pontos de acesso de servios (SAP: Service Access Points), ou seja, a camada N + 1 acessa os servios oferecidos pela camada N nos SAPs desta camada. Cada SAP possui um endereo que o identifica nica e globalmente.

A figura 3 ilustra alguns conceitos associados aos pontos de acesso de servios. Da figura podemos observar que:

no mximo uma entidade e responsvel pelo suporte ao SAP; no mximo uma entidade-(N + 1)pode acessar um SAP-(N ) de cada vez; uma entidade-(N )pode suportar qualquer numero de SAPs-(N ); uma entidade-(N + 1) pode acessar servios em mais de um SAP-(N ).

A associao entre uma entidade-(N + 1) a um SAP-(N) como tambm a associao de uma entidade-(N) que suporta um SAP-(N) no so associaes permanentes podendo ser alteradas dinamicamente.

A natureza dos servios suportados por uma camada depende das primitivas que uma entidade-(N + 1) e uma entidade-(N) podem invocar relativamente ao SAP-(N ).

11

Figura 3 - Pontos de Acesso de servios (SAPs).

2.8.1 Servios conectados e sem conexo

Servios conectados so anlogos a um servio telefnico. Estabelece-se uma conexo (discagem / atendimento), utiliza-se a conexo para troca de informaes (conversao) e termina-se a conexo (volta ao gancho). Servios conectados estabelecem um canal lgico entre as entidades comunicantes. Neste canal, a ordem temporal no envio da informao e respeitada e duplicaes so inexistentes. O canal denominado logico ou virtual pelo fato de no dispor de uma conexo fsica exclusiva, ao contrario, mltiplos canais lgicos compartilham uma mesma conexo fsica.

Servios conectados se dividem em dois tipos: mensagens e cadeias de bytes. Mensagens tem suas fronteiras delimitadas, o que no ocorre com as cadeias de bytes. Servios tpicos que demandam conexo so transferncia de arquivos e login remoto.

Servios sem conexo so anlogos a servios postais. Envia-se uma mensagem a um destinatrio (carta ou telegrama) e faz-se votos que ele a receba. Servios sem

12 conexo so denominados servios de datagrama. Datagramas so mais rpidos que os servios conectados, mas a garantia de entrega, ausncia de duplicao e preservao da ordem de envio no so garantidas. Servios tpicos que podem ser baseados em datagrama so os do tipo requisio/resposta (acesso a banco de dados e sincronizao de relgios, por exemplo). Dentro do jargo ISO uma conexo e estabelecida por iniciativa de uma entidade-(N + 1) que invoca servio especfico da camada-(N) para estabelecimento de uma conexo logica com uma entidade-(N + 1) remota. A conexo e estabelecida entre SAPs-(N)

correspondentes. Todas as conexes estabelecidas em um mesmo SAP so suportadas pela entidade-(N) correspondente. De modo a permitir que a entidade(N + 1) e a entidade-(N ) possam distinguir varias conexes estabelecidas via um mesmo SAP, define-se o conceito de ponto final de conexo (CEP - Connection End Point). Para cada conexo, 2 CEPs so definidos, um para cada extremo da conexo Desta maneira, um ponto final da conexo-(N ) (CEP(N )) termina uma conexo-(N ) em um SAP-(N ). Um CEP-(N ) relaciona trs elementos, seja, uma entidade-(N + 1), uma entidade-(N ) e uma conexo-(N ). No caso do envio sem conexo so utilizados servios de transferncia de dados sem conexo suportados pela camada-(N ).

13

PROTOCOLO SNMP

As mudanas das caractersticas das redes de computadores de pequenas redes locais para grandes redes espalhadas geograficamente, de redes homogneas para redes heterogneas, bem como a evoluo dos equipamentos que interligam as redes e o aumento do nmero de usurios conectados a elas tem dificultado em muito a gerncia.

No incio da dcada de 80 o protocolo Simple Network Management Protocol

SNMP comeou a ser desenvolvido pelo Internet Engineering Task Force IETF, com o objetivo de disponibilizar uma forma simples e prtica de realizar o controle de equipamentos em uma rede de computadores.

A padronizao da primeira verso do protocolo SNMP foi publicada em maio de 1990, atravs da RFC 1157. Em abril de 1993, as RFCs 1442 a 1444 foram publicadas, tornando-se obsoletas com as publicaes das respectivas RFCs: 1902 a 1907, que, por sua vez, se tornaram obsoletas pelas RFCs 2578, 2579 e 2580. A terceira verso SNMP, surge em abril de 1999, com a RFC 2574, que foi substituda posteriormente pela RFC 3414.

A estratgia implcita no SNMP que o monitoramento do estado da rede num determinado nvel de detalhes seja realizado primeiramente por uma lista de informaes apropriadas. Um nmero limitado de mensagens espordicas guia o tempo e o foco da lista. Limitando o nmero dessas mensagens (traps) torna-se consistente, com a caracterstica de simplicidade e reduo do trfego gerado pela funo de gerenciamento da rede.

A arquitetura SNMP admite uma variedade de relacionamentos administrativos entre entidades que participam no protocolo. As entidades que residem nas estaes de gerncia e os elementos da rede que se comunicam usando o protocolo SNMP so

14 rotulados entidades de aplicao SNMP. Os processos ponto a ponto que implementa o SNMP, e consequentemente suportam as entidades de aplicao SNMP, so rotulados entidades do protocolo. Em redes IP, o sistema de gerenciamento segue o modelo gerente-agente, onde o GERENTE o prprio sistema de gerenciamento e o AGENTE um software que deve ser instalado nos equipamentos gerenciados. A tarefa do agente responder as requisies feitas pelo gerente em relao ao equipamento no qual o agente est instalado, (MIRANDA, 2008)

A combinao de agentes com algum conjunto arbitrrio de entidades de aplicao SNMP chamado comunidade SNMP. Cada comunidade SNMP nomeada por uma string de octetos (MIRANDA, 2008).

Uma mensagem SNMP originada por uma entidade de aplicao SNMP, que de fato pertena a uma comunidade SNMP, nomeada pela mensagem indicativa de componente da comunidade, chamada mensagem SNMP. O conjunto de regras para que uma mensagem SNMP seja identificada como uma mensagem autntica para uma comunidade particular chamado de esquema de autenticao. E, uma implementao da funo que identifica mensagens autnticas de acordo com um ou mais esquemas chamado de servio de autenticao.

O efetivo relacionamento administrativo entre entidades de aplicao requer servio de autenticao, podendo usar criptografia ou outra tcnica, que seja capaz de identificar mensagens autnticas com certo grau de certeza. No SNMPv3, a mensagem criptografada com Data Encryption Standard (DES), que cifra os dados a serem transmitidos atravs de uma chave secreta. Para alguns elementos da rede, o subconjunto de objetos contidos em suas MIBs so chamados vises da MIB.

Os elementos do conjunto como somente de leitura, ou de leitura e escrita so chamados modo de acesso. E, a combinao do modo de acesso com a viso MIB chamada perfil da comunidade. Um perfil de comunidade SNMP representa os privilgios de acesso especificados para as variveis na viso MIB.

15 A combinao de uma comunidade SNMP com um perfil da comunidade SNMP chamada poltica de acesso, que representa um perfil de comunidade especfica, permitido para um agente SNMP da comunidade especificada, para outros membros daquela comunidade.

A diferena entre os dois tipos de acesso aos dados da MIB SNMPv1 e SNMPv2 so: valores dos status de erros gerados; gerao de cdigos de exceo; uso do tipo de dado Counter64; formato dos parmetros proporcionados quando uma notificao gerada.

O acesso aos dados na MIB com base no SNMPv1, pode gerar valores de erros de status SNMPv1, mas nunca gerar cdigos de exceo nem uso do tipo de dados Counter64, e proporcionar parmetros no formato SNMPv1 para gerao de notificaes. Ele tambm nunca gerar um erro readOnly (somente de leitura), mas sim noSuchName em seu lugar.

Os parmetros de notificao SNMPv1 consistem de: um parmetro de negcio (OBJECT IDENTIFIER); um parmetro de endereo do agente (endereo de rede); um parmetro de trap genrica (INTEGER); um parmetro de trap especfica (INTEGER); um parmetro de tempo (TimeTicks); e uma lista de variveis de ligao (VarBindList).

J o acesso MIB, com base no SNMPv2, pode gerar valores de erro de status SNMPv2 e cdigo de exceo, usar tipo de dados Counter64 e proporcionar parmetros no formato SNMPv2 para gerao de notificaes. E, ele nunca gerar erros readOnly, noSuchName, ou badValues.

Os parmetros de notificao SNMPv2 consistem de: um parmetro de tempo ativo do sistema (TimeTicks), aparecendo na primeira varivel de ligao da trap ou solicitao de informao; um parmetro de identificao da trap SNMP (OBJECT IDENTIFIER); e uma lista de variveis de ligao (VarBindList).

A RFC 3414 descreve as caractersticas de segurana incorporada ao SNMPv3,

16 como o uso Hashed Message Authentication Code Message Digests 5 96 (HMAC-MD5-96) e Hashed Message Authentication Code Secure Hash Algorithm 96 (HMAC-SHA-96) como protocolos de autenticao, e o uso do Cipher Block Chaining Data Encryption Standard (CBC-DES) como protocolo de privacidade. O User-based Security Model (USM) permite, ento, que outros protocolos sejam usados com o SNMP ao invs de concorrer com eles.

Vrias ameaas clssicas para protocolos de rede so aplicveis ao problema de gerenciamento de rede, e, portanto so tambm aplicveis ao modelo de segurana utilizado no SNMPv1 e SNMPv2. Algumas dessas ameaas podem ser citadas: Modificao da informao : algumas entidades desautorizadas poderiam

alterar mensagens SNMP em trnsito geradas em interesse de um principal autorizado, e efetuar operaes de gerncia indesejadas como incluir valores falsos nos objetos; Masquerade: operaes de gerenciamento no autorizadas por algum usurio

podem ser tentadas com a identidade de algum outro usurio que tem autorizaes apropriadas; Divulgao: o perigo de algum monitorar as trocas e negociaes entre

agentes e estao de trabalho. Modificao da sequncia da mensagem : visto que o servio de transporte do

protocolo SNMP no orientado a conexo, a reordenao, o retardo, ou o reenviou de mensagens pode provocar anomalias nas operaes do protocolo.

Pelo menos dois tipos de ameaa ao modelo de segurana SNMPv3 no so abordados pela sua especificao:

Negao de servio: o atual modelo do protocolo SNMPv3 no tenta proteger

de uma ampla srie de ataques, para que servios em nome de usurios autorizados no sejam negados. De fato, ataques de negao de servios so, em muitos casos, indistinguveis de certos tipos de falhas de rede; Anlises de trfego: muitos padres de trfego so preditveis. Dispositivos

podem ser gerenciados numa base regular por um nmero relativamente pequeno de aplicaes. Alm disso, no h vantagens significativas para proteger contra

17 ataque de anlise de trfego.

3.1

MIB - MANAGEMENT INFORMATION BASE

Antes de definir o que uma MIB, introduziremos o conceito de objetos gerenciados. Um objeto gerenciado a viso abstrata de um recurso real do sistema. Assim, todos os recursos da rede que devem ser gerenciados so modelados, e as estruturas dos dados resultantes so os objetos gerenciados. Os objetos gerenciados podem ter permisses para serem lidos ou alterados, sendo que cada leitura representar o estado real do recurso e, cada alterao tambm ser refletida no prprio recurso. Dessa forma, a MIB o conjunto dos objetos gerenciados, que procura abranger todas as informaes necessrias para a gerncia da rede, (COMER, 2006)

A RFC - Request For Comment 1066 apresentou a primeira verso da MIB, a MIB I. Este padro explicou e definiu a base de informao necessria para monitorar e controlar redes baseadas na pilha de protocolos TCP/IP. A evoluo aconteceu com o RFC 1213 que props uma segunda MIB, a MIB II, para uso baseado na pilha de protocolos TCP/IP.

Basicamente so definidos trs tipos de MIBs: MIB II, MIB experimental, MIB privada. A MIB II, que considerada uma evoluo da MIB I, fornece informaes gerais de gerenciamento sobre um determinado equipamento gerenciado. Atravs das MIB II podemos obter informaes como: nmero de pacotes transmitidos, estado da interface, entre outras.

A MIB experimental aquela em que seus componentes (objetos) esto em fase de desenvolvimento e teste, em geral, eles fornecem caractersticas mais especficas sobre a tecnologia dos meios de transmisso e equipamentos empregados.

18 A MIB privada aquela em que seus componentes fornecem informaes especficas dos equipamentos gerenciados, como configurao, colises e tambm possvel reinicializar, desabilitar uma ou mais portas de um roteador.

3.2

Construo

As regras de construo das estruturas da MIB so descritas atravs da SMI Structure of Management Information. A estrutura de informaes de gerncia SMI um conjunto de documentos que definem:

Forma de identificao e agrupamento das informaes; Sintaxes permitidas; Tipos de dados permitidos.

Os objetos de uma MIB so especificados de acordo com a ASN.1 - Abstract Syntax Notation One. A notao sinttica abstrata uma forma de descrio abstrata dos dados com o objetivo de no se levar em considerao a estrutura e restries do equipamento no qual est sendo implementada. Para cada objeto so definidos: nome, identificador, sintaxe, definio e acesso. As instncias do objeto so chamadas de variveis.

O Object Name o nome do objeto, composto por uma string de texto curto. O Object Identifier o identificador do objeto, formado por nmeros que so separados por pontos. A Sintaxe, sintaxe do objeto, descreve o formato, ou o valor, da informao. Ela pode ser:

uma sintaxe do tipo simples que pode ser um inteiro, uma string de octetos,

um Object Identifier ou nulo; pode ser tambm uma sintaxe de aplicao podendo ser um endereo de

rede, um contador, uma medida, um intervalo de tempo ou incompreensvel.

19 A definio uma descrio textual do objeto.

O acesso o tipo de controle que se pode ter sobre o objeto, podendo ser: somente leitura, leitura e escrita ou no acessvel.

3.3

Estrutura

A rvore hierrquica abaixo foi definida pela ISO representa a estrutura lgica da MIB, mostra o identificador e o nome de cada objeto.

Figura 4 Estrutura lgica da MIB

O n raiz da rvore no possui rtulo mas possui pelo menos trs subnveis, sendo eles: o n 0 que administrado pela Consultative Committe for International Telegraph and Telephone - CCITT;

O n 1 que administrado pela International Organization for Standartization ISO; O n 2 que administrado em conjunto pela CCITT e pela ISO. Sob o n ISO

20 fica o n que pode ser utilizado por outras instituies: o org (3), abaixo dele fica o dod (6) que pertence ao departamento de defesa dos EUA.

O departamento de defesa dos EUA alocou um sub-n para a comunidade internet, que administrado pela International Activities Board - IAB e abaixo deste n temos, entre outros, os ns: management, experimental, private.

Sob o n management ficam as informaes de gerenciamento, sob este n que est o n da MIB II.

Sob o n experimental esto as MIBs experimentais.

Sob o n private fica o n enterprises e sob este n ficam os ns das indstrias de equipamentos.

Como exemplo de um objeto citaremos o ipInReceives do grupo IP:

ipInReceives Object Type Object Identifier: 1.3.6.1.2.1.4.3 Access: read-only Syntax: Counter32 Description: O nmero total de datagramas que chegam nas interfaces,

incluindo aqueles com erro.

MIB II Organizao Abaixo da subrvore MIB II esto os objetos usados para obter informaes especficas dos dispositivos da rede. Esses objetos esto divididos em 10 grupos, que esto presentes na tabela abaixo.
Tabela 1 Objetos passveis de informao

21

A planificao do n da MIB II fica:

Figura 5 Planificao da MIBII

Exemplos, alguns dos objetos pertencentes aos grupos da MIB II so:

Grupo System (1.3.6.1.2.1.1) sysDescr (1.3.6.1.2.1.1.1): Descrio textual da unidade. Pode incluir o nome

e a verso do hardware, sistema operacional e o programa de rede. sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares de segundos)

desde a ltima re-inicializao do gerenciamento do sistema na rede. sysContact (1.3.6.1.2.1.1.4): Texto de identificao do gerente da mquina

22 gerenciada e como contat- lo.

Grupo Interfaces (1.3.6.1.2.1.2) ifNumber (1.3.6.1.2.1.2.1): Nmero de interfaces de rede (no importando seu

atual estado) presentes neste sistema. ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface. ifInOctets (1.3.6.1.2.1.2.2.1.10): Nmero total de octetos recebidos pela

interface.

Grupo IP (1.3.6.1.2.1.4) ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade um gateway. IpInReceives (1.3.6.1.2.1.4.3): Nmero total de datagramas recebidos pelas

interfaces, incluindo os recebidos com erro. ipInHdrErrors (1.3.6.1.2.1.4.4): Nmero de datagramas que foram recebidos e

descartados devido a erros no cabealho IP.

Grupo SNMP (1.3.6.1.2.1.11) snmpInPkts (1.3.6.1.2.1.11.1): Nmero total de mensagens recebidas pela

entidade SNMP. snmpOutPkts (1.3.6.1.2.1.11.2): Nmero total de mensagens enviadas pela

entidade SNMP. snmpInTotalReqVars (1.3.6.1.2.1.11.13): Nmero total de objetos da MIB que

foram resgatados pela entidade SNMP.

3.4

SNMP - Simple Network Management Protocol

O SNMP um protocolo de gerncia definido a nvel de aplicao, utilizado para obter informaes de servidores SNMP - agentes espalhados em uma rede baseada na pilha de protocolos TCP/IP. Os dados so obtidos atravs de requisies de um gerente a um ou mais agentes utilizando os servios do protocolo de transporte UDP

23 - User Datagram Protocol para enviar e receber suas mensagens atravs da rede.

Dentre as variveis que podem ser requisitadas utilizaremos as MIBs podendo fazer parte da MIB II, da experimental ou da privada.

O gerenciamento da rede atravs do SNMP permite o acompanhamento simples e fcil do estado, em tempo real, da rede, podendo ser utilizado para gerenciar diferentes tipos de sistemas, (MIRANDA, 2008).

Este gerenciamento conhecido como modelo de gerenciamento SNMP, ou simplesmente, gerenciamento SNMP. Por tanto, o SNMP o nome do protocolo no qual as informaes so trocadas entre a MIB e a aplicao de gerncia como tambm o nome deste modelo de gerncia.

Os comandos so limitados e baseados no mecanismo de busca/alterao. No mecanismo de busca/alterao esto disponveis as operaes de alterao de um valor de um objeto, de obteno dos valores de um objeto e suas variaes.

A utilizao de um nmero limitado de operaes, baseadas em um mecanismo de busca/alterao, torna o protocolo de fcil implementao, simples, estvel e flexvel. Como consequncia reduz o trfego de mensagens de gerenciamento atravs da rede e permite a introduo de novas caractersticas.

O funcionamento do SNMP baseado em dois dispositivos o agente e o gerente. Cada mquina gerenciada vista como um conjunto de variveis que representam informaes referentes ao seu estado atual, estas informaes ficam disponveis ao gerente atravs de consulta e podem ser alteradas por ele. Cada mquina gerenciada pelo SNMP deve possuir um agente e uma base de informaes MIB.

24

Figura 6 Objetos gerenciados atravs de suas MIBs.

O Agente

um processo executado na mquina gerenciada, responsvel pela manuteno das informaes de gerncia da mquina. As funes principais de um agente so: Atender as requisies enviadas pelo gerente; Enviar automaticamente informaes de gerenciamento ao gerente, quando

previamente programado;

O agente utiliza as chamadas de sistema para realizar o monitoramento das informaes da mquina e utiliza as RPC (Remote Procedure Call) para o controle das informaes da mquina.

O Gerente

um programa executado em uma estao servidora que permite a obteno e o envio de informaes de gerenciamento junto aos dispositivos gerenciados mediante a comunicao com um ou mais agentes.

25

Figura 7 Gerente e objetos gerenciados

A figura 7 mostra como funciona o relacionamento de um gerente com o objeto gerenciado. O gerente fica responsvel pelo monitoramento, relatrios e decises na ocorrncia de problemas enquanto que o agente fica responsvel pelas funes de envio e alterao das informaes e tambm pela notificao da ocorrncia de eventos especficos ao gerente.

Figura 8 Gerente e agente, TCP/IP

A figura 8 mostra o relacionamento entre gerente e agente baseado no modelo TCP/IP

Operaes do Protocolo SNMP Existem duas operaes bsicas (SET e GET) e suas derivaes (GET-NEXT,

26 TRAP).

A operao SET utilizada para alterar o valor da varivel; o gerente solicita

que o agente faa uma alterao no valor da varivel; A operao GET utilizada para ler o valor da varivel; o gerente solicita que

o agente obtenha o valor da varivel; A operao de GET-NEXT utilizada para ler o valor da prxima varivel; o

gerente fornece o nome de uma varivel e o cliente obtm o valor e o nome da prxima varivel; tambm utilizado para obter valores e nomes de variveis de uma tabela de tamanho desconhecido; A operao TRAP utilizada para comunicar um evento; o agente comunica

ao gerente o acontecimento de um evento, previamente determinado. So sete tipos bsicos de trap determinados: coldStart: a entidade que a envia foi reinicializada, indicando que a

configurao do agente ou a implementao pode ter sido alterada; warmStart: a entidade que a envia foi reinicializada, porm a configurao

do agente e a implementao no foram alteradas; linkDown: o enlace de comunicao foi interrompido; linkUp: o enlace de comunicao foi estabelecido; authenticationFailure: o agente recebeu uma mensagem SNMP do gerente

que no foi autenticada; egpNeighborLoss: um par EGP parou; enterpriseSpecific: indica a ocorrncia de uma operao TRAP no bsica.

Mensagem no Protocolo SNMP

Uma mensagem SNMP deve definir o servidor do qual vai se obter ou alterar os atributos dos objetos, e que ser o responsvel pela converso das operaes requisitadas em operaes sobre a MIB. Aps verificar os campos de uma mensagem o servidor deve utilizar as estruturas internas disponveis para interpretar a mensagem e enviar a resposta da operao ao cliente que a solicitou.

As mensagens no protocolo SNMP no possuem campos fixos e por isso so

27 construdas de trs para frente. A mensagem possui trs partes principais: version, community, SNMP PDU: A version contem a verso do SNMP. Tanto o gerente como o agente devem

utilizar a mesma verso. Mensagens contendo verses diferentes so descartadas. A community que identifica a comunidade. utilizada para permitir acesso do

gerente as MIBs; A SNMP PDU a parte dos dados, possui PDU (Protocol Data Units) que so

constitudas ou por um pedido ou por uma resposta a um pedido.

Figura 9 Mensagem SNMP

A figura 9 mostra uma mensagem SNMP com seus campos e os seus componentes.

Existem cinco tipos de PDUs: GetRequest, GetNextRequest, GetResponse, SetRequest e Trap. Com dois formatos distintos, como nas figuras 10 e 11. O formato das PDUs GetRequest, GetNextRequest, GetResponse e SetRequest:

Figura 10 Formato PDU, GET E SET

28

Figura 11 Formato PDU, Trap

Algumas limitaes do SNMP so:

No apropriado para o gerenciamento de redes muito grandes, devido

limitao de performance de pooling; Traps SNMP no so reconhecidos; O padro SMNP bsico prov somente autenticao trivial; O modelo SNMP MIB limitado e no suporta aplicaes que questionam o

gerenciamento, baseadas em valores ou tipos de objetos;

No suporta comunicao manager-to-manager.

29

ZABBIX

ZABBIX um software, distribudo sob a licena GPL, que monitora um vasto nmero de parmetros de rede e o perfeito funcionamento dos servidores. ZABBIX usa um flexvel mecanismo de alarmes que permite aos usurios configurar um email para receber um alerta de algum evento que ocorra com os mecanismos gerenciados. Isso permite uma fcil resoluo do problema encontrado nos servidores. O criador Alexei Vladishev pensou em unificar em uma nica ferramenta solues de monitoramento permitindo o monitoramento em tempo integral.

ZABBIX oferece caractersticas de relatrios e visualizao de dados armazenados. Isso faz o ZABBIX ideal para o planejamento de capacidade. ZABBIX suporta polling (forma de capturar dados de tempo em tempo) e trapping (notificao de alarmes). Todos os relatrios e estatsticas do ZABBIX, bem como as configuraes dos parmetros so acessadas atravs de uma interface grfica na web. E esta interface assegura os estados de bom funcionamento da rede e de seus servidores possam ser acessados de qualquer lugar. Propriamente configurado ZABBIX pode ter um papel importante em monitorar toda a infraestrutura de TI. Isso igualmente verdadeiro para pequenas companhias com poucos servidores e para grandes companhias com grandes nmeros de servidores.

O ZABBIX oferece:

Suporte para ambos mecanismos de polling e trapping; Servidores para Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X; Agentes de alta performance nativos; Monitoramento de servidores sem um agente instalado; Autenticao de usurio segura utilizando criptografia dos dados; Permisses de usurios flexveis; Interface grfica web;

30 Flexvel notificao e predefinidos eventos por e-mail; Alto Nvel de visualizao (Negcios) de recursos monitorados.

utilizao

do

ZABBIX

traz

ao

administrador

alguns

benefcios

indispensveis nos dias de hoje, como:

Soluo de Cdigo aberto; Alta eficincia para agentes baseados nas plataformas UNIX e WIN32; Baixa curva de aprendizado; Alto retorno de investimento atravs dos dados coletados, diminuindo

o tempo gasto com solues erradas dos problemas; Baixo custo de implantao pois de fcil instalao; Muito simples de configurar;

Sistema de monitoramento centralizado. Todas informaes (configurao, dados de performance) so armazenadas em uma base de dados relacional;

Servio de rvore de alto nvel; Instalao muito fcil; Suporte para o SNMP (v1, v2). Ambos aceitam polling e trapping; Visualizao de capacidades; Procedimento interno de tarefas proprietrias.

4.1

CARACTERSTICAS DO ZABBIX

Um sistema de gerncia de redes possui algumas funes bsicas para tratar as reas da gerncia. Ento baseando-se nestas funes, o ZABBIX possui as seguintes caractersticas:

31

4.1.1 Monitoramento de desempenho

Um dos mais importantes usos do ZABBIX o monitoramento de desempenho. Carga do processador, nmero de processos rodando, nmero de processos, atividade no disco rgido, espao da memria swap e disponibilidade da memria so alguns de inmeros parmetros de sistemas que o ZABBIX capaz de monitorar. O ZABBIX prove ao administrador de sistemas informaes em tempo real sobre o desempenho de um servidor. Alm disso, ZABBIX pode produzir

grficos de tendncias para ajudar na identificao de gargalo no desempenho do sistema. Os grficos gerados pelo ZABBIX so mais eficientes em se comparando com o NAGIOS, por exemplo, pois utilizam o pacote RRDTool 1, em vez do MRTG2.

4.1.2 Mecanismo de alerta

Ter o monitoramento de desempenho em um sistema muito bom, mas ele seria pouco usado sem o poderoso mecanismo de notificao. Com o ZABBIX, um administrador pode definir virtualmente uma possvel condio para um gatilho, usando flexveis expresses. Em algum momento quando essas condies forem verdadeiras (ou falsas), um alerta ser enviado por e-mail para um endereo definido pelo administrador. Programas externos podem ser usados para

notificar o usurio como SMS, notificao por celular, etc.

RRDTool (Round Robin Database Tool) uma ferramenta para monitorao de trfego, que

reduz sensivelmente a carga gerada pela monitorao para a exibio dos grficos, o que possibilita uma representao visual em tempo real do trfego.

MRTG (Multi Router Traffic Grapher) outra ferramenta para monitorao de trfego. Ela

gera um relatrio que exibido em HTML com imagens.

ZABBIX pode

adivinhar comportamentos

32 futuros de parmetros monitorados

usando um Algoritmo do Mnimo Quadrado. Isso permite o usurio ser notificado bem antes de o estado do sistema alcanar o nvel crtico.

4.1.3 Monitoramento de arquivos de logs

O ZABBIX pode ser usado para o monitoramento de arquivos de logs. Como por exemplo, quando algum valor for impresso em um determinado arquivo de log, ele poder disparar um alerta para o Administrador.

4.1.4 Verificao de Integridade

ZABBIX capaz de verificar a integridade do servidor. Todos arquivos de configurao crticos, binrios, kernel, scripts e pginas HTML de servidores web podem ser monitorados permitindo que o administrador possa ser alertado toda vez que um desses arquivos forem alterados.

4.1.5 Servios de Auditoria

Todos

valores dos

parmetros

monitorados

so armazenados em banco de

dados. Os dados coletados podem ser usados mais tarde para algum propsito.

O ZABBIX gera uma auditoria das mudanas dos valores dos parmetros para que o administrador possa saber quem as fez, para em caso de algum problema possa

33 tentar identificar os culpados.

4.1.6 Capacidade de Planejamento

Observando tendncia de carga de processos, uso de disco rgido, atividade de banco de dados ou outras medidas importantes, o ZABBIX permite ao

administrador de sistemas uma viso clara para uma necessidade futura de atualizao de um hardware especfico, quando o mesmo estiver sobrecarregado.

4.1.7 Monitoramento do SLA

ZABBIX capaz de monitorar Servios ao Nvel de Contrato (Service Level Agreements - SLA). Mantm tambm SLA - os dados histricos relacionados que ajudam identificar e melhorar reas fracas de um infraestrutura de tecnologia de informao.

4.1.8 Visualizao de alto nvel dos recursos e servios de TI.

Uma escala de servios de alto nvel permite a criao de dependncias entre vrios recursos de tecnologia de informao. Tal representao permite as seguintes questes serem respondidas:

Quais os servios de TI dependem da disponibilidade dos recursos X?

Exemplo: Se a carga do processador est muito alta no servidor A, ento

34 estes servios de TI podero ser afetados: Servidor Oracle, Banco via web, Processamento de transaes online e etc.

Quais os recursos especficos um servio de TI depende?

Exemplo: Um portal WEB deve depender dos seguintes recursos:

Carga do processador no servidor A Provedor de servio internet (ISP) para conexo Espao de disco no servidor A Disponibilidade do banco de dados Oracle no servidor B Velocidade de execuo das requisies dos usurios Disponibilidade do servidor Apache no servidor C

Tais nveis de dependncia ajudam a identificar pontos fracos na infraestrutura de TI.

Exemplo: Se

diversos

servios

crticos

oferecidos

pelo departamento de TI

dependerem de, por exemplo, disponibilidade de espao em disco para alguns servidores, ento tempo de pensar sobre a distribuio de volume de carga de diferentes servidores ou preparar o disco para eliminar possveis riscos.

Outra caracterstica do sistema est relacionada em permitir a Anlise da Disponibilidade, ou seja, quando um determinado servidor gerenciado possa ter ficado indisponvel para uso. Alm disso a Representao Grfica de Informaes Coletadas pode ser usada para tomar decises, pois so mostrados em formas de relatrios. Outro ponto a forma de mostrar os elementos gerenciados ou

no em forma de Mapas de Redes permitindo assim uma melhor viso da rede. Mais uma caracterstica interessante a Personalizao de Telas, que permite ao administrador definir o formato de suas telas, ou seja, quais dados, grficos e mapas podero ser vistos.

35 4.2 REQUISITOS

Necessidades a serem atendidas para a instalao do Zabbix.

4.2.1 Requisitos de Hardware

Para a instalao do ZABBIX h a necessidade mnima de ter 32 Mb de memria fsica e 20 Mb de espao em disco. Porm, o nmero exato de memria e espao em disco requeridos dependero do nmero de hosts e parmetros que sero monitorados. Se for planejado um longo histrico de parmetros monitorados,

pode-se prever que o banco de dados ocupar gibabytes de espao em disco.

Cada processo do ZABBIX requer um nmero grande de conexes com o servidor. Uma quantidade de memria alocada para as conexes depende da configurao do banco de dados. importante ressaltar que quanto mais memria fsica a mquina estiver, mais rpido ser o banco de dados, e consequentemente o ZABBIX.

4.2.2 Plataforma suportadas

Devido a necessidade de segurana e a critica misso natural de monitoramento de servidores, UNIX o nico sistema operacional que pode consistentemente responder ao desempenho necessrio, tolerncia de falha e auto recuperao. ZABBIX opera sobre verses principais do mercado. ZABBIX testado nas seguintes plataformas:

36 Linux 2.xx Solaris 2.xx - HP-UX 11.xx - AIX 4.3 Free BSD 4.3 SCO Open Server 5.0.5 - Mac OS/X

Pelo

fato

de

ZABBIX

ter

sido

testado

somente

para

os sistemas

mencionados acima, nada impede de funcionar tambm em outros sistemas operacionais baseados em UNIX.

4.2.3 Requisitos de Software

ZABBIX construdo em cima do servidor WEB Apache, banco de dados MySQL ou PostgreSQL e a linguagem de script PHP. A seguir esto os aplicativos que so requisitos para rodar o ZABBIX:

Apache: Verso 1.3.12 ou maior. O apache pode ser encontrado em

http://www.apache.org. MySQL (ou PostgreSQL): Verso 3.22 ou maior. O MySQL pode ser

encontrado em http://www.mysql.com. PostgreSQL PostgreSQL pode (ou MySQL): Verso ser 7.0.2 ou maior:

encontrado em http://www.postgresql.org. Arquivos de desenvolvimento para MySQL ou PostgreeSQL,

normalmente encontrados como parte dos pacotes mysql-dev ou postgresql-dev. PHP: Verso 4.0 ou maior. PHP um modulo encontrado em

http://www.php.net. PHP deve ser compilado com o mdulo do Apache. PHP 5.0 suportado tambm. Mdulo PHP GD ou GD2: O mdulo requerido para mostrar mapas e

grficos. O mdulo suporta imagens no formato PNG. Mdulo PHP 4.0 MySQL ou PostgreSQL GNU Make: Necessrio para criar o ZABBIX ou seus agentes. No caso de

37 ser usado verses pr-criadas, GNU make no ser necessrio. Navegador Web: No lado do cliente e que suporte pginas HTML e

imagens PNG.

4.3

COMPONENTES DO ZABBIX

O ZABBIX consiste de diversos componentes de software e a responsabilidade de cada um est descrita a seguir:

Servidor ZABBIX: Esse o centro do software ZABBIX. O servidor pode

remotamente verificar servios de redes (como um servidor web ou um servidor de e-mail) usando simplesmente a verificao do servio, mas tambm o

repositrio central onde toda configurao, esttico e operacional so armazenadas. Alm disso a entidade do ZABBIX que ir ativar o alerta ao administrador do sistema toda vez que um problema aparecer em algum sistema monitorado. HD, Agente ZABBIX: para monitorar recursos locais e aplicaes (tais como memria, estatstica de processador) em sistemas na rede, esses

sistemas devem rodar o agente ZABBIX. Este agente ir coletar informaes operacionais do sistema no qual est rodando e relata os dados ao ZABBIX para processar mais adiante. Em caso de falhas (tais como HD cheio ou um processo que deixou de funcionar), o servidor ZABBIX pode imediatamente alertar o administrador que uma mquina especfica reportou um erro. O agente ZABBIX extremamente eficiente porque usa sistemas de chamadas nativo para coletar informaes estatsticas. O ZABBIX pode tambm monitorar outros dispositivos de redes que usem um agente SNMP. Interface WEB: A fim de permitir um fcil acesso ao monitoramento dos dados

e configuraes atravs do ZABBIX, uma interface web fornecida. A interface parte do servidor ZABBIX, e usualmente (no necessariamente) rodado em cima da mquina fsica e no roda no servidor ZABBIX.

38

4.4

INSTALAO

Para instalar o ZABBIX necessrio lembrar de ter todos os requisitos de software tambm instalados para que no ocorra nenhum erro durante a instalao.

4.4.1 - Servidor

O primeiro passo para a instalao do servidor a criao de um usurio no sistema operacional. Esse o usurio que o servidor ser rodado. Esta conta ser criada sem alguns privilgios. Pode ser usado qualquer nome para a criao do usurio, mas o mais comum 'zabbix'.

shell> adduser --system --group zabbix

Aps isso, preciso fazer a descompactao do arquivo 'tar.gz' salvo do site ZABBIX antes de prosseguir a instalao. Para isso, deve ser executado o seguinte comando:

shell> tar -zxvf zabbix.tar.gz

ZABBIX vem com scripts SQL usados para criar o esquema de banco de dados necessrio e tambm para inserir algumas configuraes iniciais. Esses scripts so separados por MySQL e PostgreSQL. Para isso basta acessar o diretrio onde esto os arquivos de instalao e executar os seguintes comandos:

Para MySQL: shell> mysql -u -p

39 mysql> create database zabbix; mysql> quit;

shell> cd create/mysql shell> cat schema.sql | mysql -u -pzabbix shell> cd ../data shell> cat data.sql | mysql -u -p zabbix

Para PostgreSQL: shell> psql -U psql> create database zabbix; psql> \q

shell> cd create/mysql shell> cat schema.sql | psql -u zabbix shell> cd ../data shell> cat data.sql | psql -u zabbix

Aps a criao do banco de dados, o administrador deve compilar o cdigo fonte tanto para o servidor quanto para o agente. Para compilar o cdigo fonte do servidor, dever ser especificado qual o banco de dados que ser usado.

shell> .configure --enable-server --with-mysql --with-netsnmp # Para MySQL ou shell> .configure --enable-server --with-pgsql --with-netsnmp # Para PostgreSQL

Se for necessrio distribuir binrios compilados para diferentes servidores, deve ser usada a flag --enale-static para ligar bibliotecas estaticamente.

A flag --with-ucd-snmp pode ser usada em vez de --withnet-snmp. Se no for necessrio o suporte ao SNMP, essas flags devem ser descartadas. Por fim para instalar basta executar o seguinte comando:

shell> make install

Por padro,

comando

make

install ir

instalar todos

os arquivos

em

40 /usr/local/bin, /usr/local/lib e etc. Pode ser usado tambm um prefixo de instalao usando o comando --prefix. Depois da instalao do cdigo, o administrador pode incluir as seguintes linhas no arquivo /etc/services.

zabbix_agent 10050/tcp zabbix_trap 10051/tcp

Estas linhas no so requisitos bsicos para o funcionamento. Entretanto, recomendado a incluso das mesmas. Se o administrador pretender usar o zabbix_agent em vez do recomendado, zabbix_agentd, as seguintes linhas devem ser adicionadas no arquivo /etc/inetd.conf. Para que as alteraes tenham efeito, o servio inet dever ser reiniciado.

zabbix_agent stream tcp nowait.3600 zabbix /opt/zabbix/bin/zabbix_agent

Aps isso, o arquivo /etc/zabbix/zabbix_agent.conf deve ser configurado para toda mquina que possuir o agente zabix_agent instalado. neste arquivo que deve conter o endereo IP do servidor ZABBIX. Conexes para outras mquinas devem ser eliminadas. Para fazer isso o administrador poder ver como exemplo o arquivo misc/conf/zabbix_agent.conf.

Outro arquivo a ser configurado em toda mquina que o agente zabix_agentd instalado o /etc/zabbix/zabbix_agentd.conf. neste arquivo que deve conter o endereo IP do servidor ZABBIX. Conexes para outras mquinas devem ser eliminadas. Para fazer isso o administrador poder ver como exemplo o arquivo /misc/conf/zabbix_agentd.conf.

Aps as configuraes necessrias para o agente, o administrador dever fazer as configuraes para o servidor no arquivo /etc/zabbix/zabbix_server.conf.

Para uma instalao pequena (menos de 10 mquinas gerenciadas), os parmetros padres so suficiente. Entretanto o administrador pode alterar os parmetros

41 padres para melhorar o desempenho do ZABBIX. Para fazer isso o administrador poder ver como exemplo o arquivo /misc/conf/zabbix_server.conf.

Para a execuo do zabbix_server do lado do servidor, o administrador dever executar o seguinte comando:

shell> zabbix_server

Para a inicializao dos agentes necessrio executar o zabbix_agentd quando necessrio. Para isto o administrador dever executar o seguinte comando para todas mquinas que tiverem o agente instalado.

shell> zabbix_agentd

4.4.2 Agente

Do lado cliente (agente) o processo bem parecido com a instalao do servidor (gerente).

necessrio que o administrador crie uma conta de usurio no sistema operacional. Esse o usurio que o agente ser rodado. Esta conta ser criada sem alguns privilgios. Pode ser usado qualquer nome para a criao do usurio, mas o mais comum 'zabbix'.

shell> adduser --system --group zabbix

Aps a criao do usurio, o administrador dever fazer a configurao

compilao do cdigo-fonte. O arquivo '.tar.gz' deve ser descompactado, como no processo de instalao do servidor e ento deve ser feita a compilao apenas do agente, uma vez que no h necessidade de instalao do gerente. Para isto o

42 administrador dever executar o seguinte comando:

shell> ./configure --enable-agent

Se for necessrio distribuir binrios compilados para diferentes servidores, dever ser usada a flag --enale-static para ligar bibliotecas estaticamente. Aps isso para fazer a instalao do agente, o administrador dever executar o seguinte comando:

shell> make

Depois necessrio copiar os arquivo criados dentro do diretrio bin/ para /opt/zabbix/bin ou algum outro diretrio. Outros diretrio comuns so /usr/local/bin ou /usr/loca/zabbix/bin. A configurao do arquivo /etc/service no um passo requerido. Entretanto, recomendado. Para isto basta adicionar as seguintes linhas para /etc/services das mquinas que sero agentes:

zabbix_agent 10050/tcp zabbix_trap 10051/tcp

Se o administrador deseja usar o zabbix_agentd, /etc/indetd.conf: as seguintes

zabbix_agent em vez do recomendado, devem ser adicionadas no arquivo

linhas

zabbix_agent stream tcp nowait.3600 zabbix /opt/zabbix/bin/zabbix_agent

Vale ressaltar que as alteraes feitas no arquivo /etc/inetd.conf, s tero efeito com a reinicializao do servio inet. necessrio configurar o arquivo /etc/zabbix/zabbix_agent.conf para toda mquina que possuir o agente zabix_agent instalado. neste arquivo que deve ser configurado o endereo IP do servidor ZABBIX. Conexes para outras mquinas devem ser excludas. Para fazer isso o administrador poder ver como exemplo o arquivo misc/conf/zabbix_agent.conf.

Outro

arquivo

que

administrador

precisa

configurar

/etc/zabbix/zabbix_agentd.conf

para

toda

mquina

que possuir

43 o agente

zabix_agentd instalado. neste arquivo que deve ser configurado o endereo IP do servidor ZABBIX. Conexes para outras mquinas devem ser excludas. Para fazer isso o administrador poder ver como exemplo o arquivo

misc/conf/zabbix_agentd.conf.

Por ltimo, o administrador deve iniciar os agentes nas mquinas gerenciadas, executando o seguinte comando:

shell> /opt/zabbix/bin/zabbix_agentd

importante ressaltar de que no h a necessidade de rodar o zabbix_agentd caso o administrador tenha escolhido usar o zabbix_agent.

4.4.3 Interface WEB

Para configurar a interface web, devem ser valores no arquivo frontends/php/include/db.inc.php:

alterados

os seguintes

$DB_TYPE=MYSQL; /* Ou POSTGRESQL para PostgreSQL */ $DB_SERVER=localhost; $DB_DATABASE=zabbix; $DB_USER=; $DB_PWD=;

Depois dessa configurao necessrio copiar os arquivos fontes PHP para um lugar onde o servidor web possa encontr-los. Os diretrios mais usados so /home/zabbix/html, /home/zabbix/public_html ou /var/www/html/zabbix. Por exemplo: shell> mkdir /home/zabbix/html shell> cp - R frontends/php/* /home/zabbix/html

44

ESTUDO DE CASO

Utilizao do Zabbix como ferramenta de monitoramento e gerenciamento de infra estrutura de data center, contextualizado pela Diretoria de Tecnologia da Informao / Prefeitura de Aparecida de Goinia.

5.1

CARACTERIZAO DO AMBIENTE

O data center da Prefeitura de Aparecida de Goinia, Gois, consiste em uma infraestrutura de servidores: HP ML 370G4 e IBM Bladecenter HS23; altamente virtualizados com 3 ou 4 sistemas operacionais por lmina, os quais sero objeto do monitoramento proativo; para cada hospedeiro. Consistindo desse modo em uma infraestrutura heterognea com diversos sistemas operacionais virtualizados, conforme figura 12.

45

Figura 12 Servidores com agente instalado, monitorado.

Nas figuras 13, 14 e 15 tem-se alguns dos elementos gerenciveis teis ao administrador de sistema/redes.

46

Figura 13 Elementos gerenciveis, windows server 2003.

47

Figura 14 Elementos gerenciveis, SCO, servidor apache.

48

Figura 15 Servidor gerenciado durante 3 meses, duas semanas e 1 dia

Na figura 16 observa-se na dashboard os servidores, se esto acessveis, tem algum indcio de uma futura indisponibilidade classificando em desastre j ocorrido ou na eminncia de ocorrer podendo ser: alta, mdia e baixa a possibilidade do mesmo; podendo para evento gerado o qual necessito gerenciar associ-lo a uma trigger que ao ser disparada enviar uma mensagem por e-mail, sms informando sobre o evento definido pela trigger e assim uma consequente tomada de deciso pra garantir a disponibilidade do acesso a informao, incorporada aos seus atributos.

49

Figura 16 Classificao dos eventos.

50

6. CONCLUSO

A possibilidade de estudar o modelo de referncia OSI, a parti de cada dispositivo, observar seu funcionamento correlacionando com a camada o qual pertence consequentemente poder gerenciar/analisar mais detalhadamente atravs da sua MIB a aplicao do protocolo SNMP, torna o presente bastante enriquecedor.

O estudo sobre uma ferramenta que auxilie na gerncia de rede vem da necessidade que os administradores de sistemas/redes possuem e atravs desse tipo de recurso otimizar os recursos da infra estrutura e ainda antever futuras falhas, seja ela usada numa rede empresarial ou residencial, independente do seu tamanho. A facilidade de entendimento e usabilidade de uma soluo usando o protocolo SNMP outra caracterstica recompensadora ao ver a teoria aplicada na prtica.

Dessa forma, observa-se que a ferramenta zabbix consiste em uma alternativa vivel como ferramenta de monitoramento e gerenciamento de infra estrutura do data center, garantindo o acesso informao incorporada pelos seus atributos: disponibilidade, integridade, confidencialidade e autenticidade.

Como aprimoramento do trabalho tem-se como sugesto para futuros trabalhos a adequao do zabbix s ISOs 27001 e 27005, sistema de gesto da segurana da informao e gesto de riscos, respectivamente. Ou ainda outras possibilidades da gerencia de configurao e SLAs que o zabbix possibilita e no teve tempo para os tpicos apresentados ou ainda porque estava fora do escopo.

51

7. REFERNCIAS

KUROSE, J. F. Redes de Computadores e a Internet: uma abordagem Top-Down. 3. ed. So Paulo: Pearson, 2006. STALLINGS W. Criptografia e Segurana de Redes, Princpios e Prticas , 4. ed Pearson. COMER D. E. Interligao de Redes com TCP/IP , 5 ed, Rio de Janeiro, Elsevier, 2006. TANENBAUM, A. S. Redes de Computadores. 5 ed. Rio de Janeiro: Prentice Hall, 2010. TANENBAUM, A. S. Sistemas Operacionais Modernos. 3 ed. So Paulo: Prentice Hall, 2010. MACHADO, Maia. Arquitetura de Sistemas Operacionais. 4. ed. Rio de Janeiro: LTC, 2007. MIRANDA A. D. A Introduo a redes de computadores, ESAB, 2008. BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML, 2 ed. Rio de Janeiro: Campus/Elsevier, 2007. DEITEL, H. M.; DEITEL, P. J. Java: Como Programar. 6. ed. So Paulo: Pearson, 2006. DATE, C. J. Introduo aos Sistemas de Banco de Dados , 8. ed. Rio de Janeiro: Campus/Elsevier, 2004. COLCHER, S.; GOMES, A. T. A.; OLIVEIRA A. S.; SOUZA G. L. F.; SOARES L. F. G. VOIP, Voz sobre IP, 5 edio 2005.

Cisco, disponvel em:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00 800b69ac.shtml#snmp1
Acessado em 01 de setembro de 2013 RFC 2574 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), disponvel em: http://www.faqs.org/rfcs/rfc2574.html . Acessado em 10 de setembro de 2013

RFC 2575 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), disponvel em: http://www.faqs.org/rfcs/rfc2575.html . Acessado em 20 de setembro de 2013 RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets:MIB-II, disponvel em: http://www.faqs.org/rfcs/rfc1213.html . Acessado em 01 de setembro de 2013 ZABBIX. disponvel em: http://www.zabbix.com. Acessado em 02 de setembro de 2013.