IMPLEMENTAÇÃO DA FERRAMENTA ZABBIX PARA MONITORAMENTO REATIVO

Transcrição

1 IMPLEMENTAÇÃO DA FERRAMENTA ZABBIX PARA MONITORAMENTO REATIVO Thiago Fachini Alexandre Timm Vieira - Orientador <xanditv@gmail.com> 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.

2 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.

3 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

4 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 é 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

5 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.

6 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 , 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 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.

7 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

8 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 Controle de versões Área de trabalho remota 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 Inatividade dos serviços e iniciar serviço Espaço livre menor que 10% e adicionar espaço Alto consumo de memória e processamento por dez minutos 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. Inatividade do serviço. Espaço livre menor que 10%.

9 tsgo01 tsmg01 dadossp01 dadosrs01 Gerenciamento de banco de dados dadospr01 Armazenar e compartilhar dadosms01 arquivos 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 Inatividade do servidor. Inatividade dos serviços. e iniciar serviço Espaço livre menor que 20%. Alto consumo de memória e processamento por vinte minutos 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) router01 Tradução de IP (NAT) 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. Inatividade dos serviços. Espaço livre menor que 5%. 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. Inatividade dos serviços. Espaço livre menor que 5%. 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. Alto consumo de memória e processamento por dez minutos Alterações nos Comunicar por earquivos monitorados mail VPN entre as lojas Proxy web Média rtpr01 Proxy MSN Média rtms01 Cache DNS Média rtgo01 Priorizar entrada e saída (QoS) Filtrar entrada e 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. Inatividade dos serviços. e iniciar serviço Espaço livre menor que 10%. Alto consumo de memória e processamento por dez minutos

10 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. Alterações nos Comunicar por earquivos monitorados mail A comunicação por será apenas para o endereço de suporte (suporte@fachini.com.br), pois há uma ferramenta que captura esses s 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 Tempo de atividade Tempo 3600 Memória física e virtual total Bytes 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

11 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 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 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, send , 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 e seguido o passo a passo de instalação que está disponível no site do desenvolvedor

12 da ferramenta, em 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 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.

13 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.

14 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

15 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 , conforme visto na janela Ação, estes parâmetros são as variáveis de ambiente, que o

16 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 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 o usuário que será notificado deve ter um ajustado no seu cadastro, e este 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

17 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 , 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

18 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, p. COSTA. Felipe. Ambiente de Rede Monitorado com Nagios e Cacti. Ed. Ciência Moderna, p. FEIGENBAUM, Edward A. e Barr, Avron. The Handbook of Artificial Intelligence. Wm. Kaufman, FERBER, Jacques. Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence. Addison-Wesley Professional, 25 fev p. 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, p LESSA, Demian, O Protocolo de Gerenciamento RMON. Rede Nacional de Ensino e Pesquisa (RNP) 15 jan Disponível em: < Acesso em: 17 fev MAGALHÃES, Ivan Luizio e PINHO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática. Ed. Novatec, p. OGC. Service Delivery. Londres Inglaterra: The Stationary Office, OGC. Service Support. Londres Inglaterra: The Stationary Office, RIGNEY, Steve. Planejamento e gerenciamento de redes. Ed. Campus, p. ROLSTON, David W.. Principles of Artificial Intelligence and Experts Systems. Mcgraw-Hill, jan p. RUSSELL, Stuart, NORVIG, Peter. Artificial Intelligence: A Modern Approach. Prentice-Hall, 30 dec p. SOARES, Vicente N. Redes de Dados, teleprocessamento e gerência de redes. Ed. Érica, p. TEIXEIRA, Ramos. Redes de Computadores, serviços, administração e segurança. Ed. Makron Books, 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.