Universidade do Porto

Transcrição

1 Universidade do Porto FERRAMENTAS DE MONITORIZAÇÃO IMPLEMENTAÇÃO NAS REDES LOCAIS DA UPORTO V. 1.0 URT, DUD Fevereiro 2012

2 Conteúdo Introdução... 3 Uma pequena apresentação do conceito de monitorização... 3 Nagios... 4 Como se configura?... 4 Cacti... 7 Como se configura?... 7 ZenOSS Como se configura? Zabbix Como se configura? Munin Como se configura? Tabela comparativa das funcionalidades suportadas pelas ferramentas de monitorização apresentadas Resumo comparativo DUD/URT 2/

3 Introdução A monitorização de redes e servidores tornou-se uma parte essencial da gestão de infraestruturas e sistemas críticos de IT. A monitorização permite que o administrador seja alertado no caso de algum problema ou indisponibilidade, mas também pode ajudar bastante a ter uma perspectiva geral da infra-estrutura gerida. No entanto, o crescimento acentuado do número de aplicações associadas à utilização das redes de computadores torna mais difícil, a cada dia que passa, a tarefa de monitorização desse ambiente. A melhor forma de reduzir a complexidade administrativa desse esforço é a utilização de ferramentas auxiliares de controlo e monitorização de equipamentos e serviços de rede. Felizmente, existe já uma enorme variedade de soluções para monitorizar uma rede, mas isso também implica que a opção por uma ou outra tenha que ser baseada num estudo criterioso da adequação da ferramenta às necessidades e ao ambiente específico de cada instituição. Assim, o objectivo deste documento é auxiliar na escolha de uma ferramenta de gestão de rede, apresentando as características principais das aplicações mais conhecidas, o seu foco e algumas vantagens e desvantagens. Uma pequena apresentação do conceito de monitorização A monitorização é baseada em certos protocolos standard, sendo o ICMP, o SNMP e o WMI os mais utilizados. O SNMP é de longe a plataforma mais comum, existindo na maioria dos equipamentos que compõem um infra-estrutura IT, ou seja, servidores, switches, routers, firewalls, impressoras, storage, e praticamente tudo o que tenha um endereço de IP. O SNMP utiliza o conceito de comunidade, definido por uma string que, uma vez configurada no equipamento que pretendemos monitorizar e no servidor de monitorização, nos vai permitir aceder a dados importantes acerca do estado físico do equipamento e dos seus atributos. Existem muitas variáveis que podem ser monitorizadas. Entre elas encontram-se, obviamente, parâmetros básicos como a ocupação do disco, da memória, utilização do CPU ou alertas de disponibilidade. Mas, para além destes exemplos, existem muitos outros conjuntos de variáveis que podem ser observadas e controladas, desde os serviços interrompidos ou iniciados em determinada máquina a quaisquer eventos que possam ser identificados nos logs de servidores. Nestes casos, é ainda possível configurar alertas diferentes para cada um dos tipos de eventos definidos (erros, avisos, etc). Por outro lado, existem essencialmente dois tipos de software de monitorização disponível os baseados em agentes e os sem-agente. Um agente é um software que pode ser instalado em qualquer equipamento que necessite de ser monitorizado, normalmente um servidor, e que envia toda a informação útil para um equipamento central. Já os sistemas sem-agente são capazes de monitorizar o equipamento sem necessidade de instalar qualquer tipo de software. Existem vantagens e desvantagens para cada um dos métodos, e não se pode dizer em absoluto que um é preferível ao outro, pois são duas abordagens diferentes ao mesmo problema: como monitorizar uma rede de computadores. DUD/URT 3/

4 Nagios O Nagios é considerado uma das mais populares, se não a mais popular, ferramenta em código aberto de monitorização de redes de computadores. O Nagios permite monitorizar serviços de rede (SMTP, POP3, http, NNTP, ICMP, SNMP, FTP, SSH) e recursos de máquinas (utilização do processador, ocupação do disco, logs de sistema, etc), entre outros. A monitorização remota é feita através de túneis encriptados SSH e SSL. O Nagios usa uma filosofia de plugins que torna fácil a criação de verificações de serviço, mais conhecidas por checks, baseadas nas necessidades e especificidades de cada utilizador, onde se incluem as ferramentas de desenvolvimento da preferência dele (Bash, C, Perl, Python, etc). Para detectar e diferenciar entre as máquinas ou equipamentos que estão indisponíveis e aqueles que estão simplesmente inalcançáveis, o Nagios permite, através da definição de elementos pai, a criação de uma hierarquia de pontos de rede. Quando é detectado um problema de rede ou de serviço, o Nagios permite notificar os responsáveis pela gestão da rede de variadas formas, tais como correio electrónico ou SMS, por exemplo. Como se configura? Após instalar o Nagios no servidor escolhido para fazer a monitorização, é necessário criar ou editar os ficheiros de configuração para que ele comece a monitorizar qualquer coisa. O ficheiro principal de configuração é o nagios.cfg (usualmente, em /usr/local/nagios/etc/nagios.cfg) e nele podemos encontrar muitas directivas que afectam a forma como o Nagios vai operar. É um ficheiro que será lido tanto pelo processo do Nagios como pelos CGIs. Algumas das variáveis mais importantes que podemos modificar neste ficheiro são: qual a directoria e o ficheiro de configuração de objectos, qual o ficheiro de configuração de recursos, o ficheiro de estado, o ficheiro de log, de quanto em quanto tempo se actualiza o ficheiro de estado, quais os privilégios do utilizador que o processo Nagios usa para correr, entre outros. DUD/URT 4/

5 Quando se corre o script de configuração, é criada uma amostra do ficheiro principal de configuração que é colocada na subdirectoria etc/. De seguida, será necessário editar o ficheiro de configuração de objectos. É aqui que definimos que equipamentos queremos monitorizar e como pretendemos fazê-lo, sendo que objectos é apenas um nome genérico para descrever o conjunto de definições necessárias à monitorização da rede. Os objectos a definir incluem: services, hosts, host groups, contacts, contact groups, commands, time periods, service escalations, service dependencies, host escalations, host dependencies e host group escalations. define host{ use host_name alias address } tpl-windows-servers ;Inherit values template windowshost ; name of the server My First Windows Server ; another name ; IP address of the server Exemplo da definição de um host define service{ use generic-service host_name windowshost service_description CPU Load check_command check_nrpe!alias_cpu } Exemplo da definição de um serviço Existem 2 métodos para definir a informação dos objectos: o velho método e o método por modelos. A escolha entre um e outro depende, essencialmente, da forma como foi compilado o programa principal e os CGIs, no entanto, recomendamos o método por modelos uma vez que, para além de mais flexível e fácil de compreender, permite a utilização de modelos para definir múltiplos equipamentos ou serviços de forma mais rápida e simples. DUD/URT 5/

6 define host{ name tpl-windows-servers ; Name of this template use generic-host ; Inherit default values check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 10 check_command check-host-alive notification_period 24x7 notification_interval 30 notification_options d,r contact_groups admins register 0 ; DONT REGISTER THIS - ITS A TEMPLATE } Exemplo de um modelo O ficheiro de configuração de CGI é onde se define, como o nome indica, o funcionamento dos CGIs. Tal como no caso do ficheiro principal de configuração, também é gerada uma amostra de ficheiro de configuração de CGIs aquando da instalação inicial. Por último, é importante referir ainda a aplicação NRPE (Nagios Remote Plugin Executor) que permite fazer verificações a serviços que não são directamente acessíveis pela máquina central de monitorização. Essas verificações são realizadas por outros equipamentos e os resultados enviados para a máquina central como se fosse ela própria a fazer as verificações. Uma vantagem importante desta solução é que, em conjunto com algum código, torna possível monitorizar praticamente qualquer coisa, desde o estado do RAID ao tamanho da mailqueue, passando pela consistência de bases de dados MySQL ou do conjunto de regras de uma firewall. Diagrama do funcionamento do NRPE DUD/URT 6/

7 Cacti O Cacti é uma ferramenta de tratamento e apresentação de dados, mais do que uma ferramenta de monitorização propriamente dita. Foi concebida como um frontend do RRDTool, que é o verdadeiro responsável por armazenar os dados colectados nas máquinas ou pontos de rede através de SNMP ou scripts, limitando-se o Cacti a gerar os gráficos resultantes dessa informação. O interface com o utilizador está desenvolvido em PHP e pode utilizar dois backends : cmd.php, mais adequado a pequenas instalações, ou o spine (antigamente conhecido por cactid), um controlador baseado em C que pode acomodar milhares de dispositivos. O Cacti pode monitorizar qualquer tipo de máquina ou ponto de rede através de executáveis ou scripts. Actualmente, permite, inclusive, configurar a própria colecta dos dados, disponibilizando algumas configurações de monitorização que não necessitam de configuração manual do RRDTool. Como se configura? A instalação do Cacti é bastante simples e existe bastante documentação disponível acerca do assunto. Depois de descarregar o instalador (normalmente, comprimido), basta configurar o PHP, configurar o Apache - servidor Web, e configurar ou instalar a base de dados MySQL. Tudo isto demora apenas alguns minutos pois, na sua maioria, consiste em adicionar ou modificar algumas linhas em outros tantos ficheiros. As instruções disponíveis online são bastante simples de seguir, até para quem tenha menos experiência. De seguida, fazemos login, mudamos a pasword por defeito e, para começar a monitorização basta indicar ao Cacti quais os equipamentos que pretendemos monitorizar. O interface Web do Cacti é prático e intuitivo, e este processo de identificação dos elementos de rede acaba por tornar-se bastante simples, pois o Cacti inclui modelos para uma extensa lista de equipamentos mais comuns, tais como servidores Linux, routers Cisco, servidores Netware e até estações de trabalho Windows2000/XP. Caso o equipamento em questão não se encontre nessa lista, é possível criar o dispositivo genérico, especificar os parâmetros que se pretende monitorizar e gravar esse modelo para utilizações futuras. DUD/URT 7/

8 Exemplo de adição de um dispositivo a monitorizar Depois de criar os dispositivos, é necessário configurar quais os parâmetros que pretendemos monitorizar em cada um deles e, por último, criar os gráficos. O Cacti também fornece modelos para os parâmetros mais comuns, tais como utilização do CPU, tráfico de rede, utilizadores registados e outros, sendo também possível criar modelos específicos. Exemplo de definição dos parâmetros de um gráfico Mas toda esta informação que o Cacti recolhe só se torna interessante se for apresentada de forma correcta. Em instalações mais pequenas, é possível lidar e avaliar os gráficos gerados rapidamente, mas se estivermos a monitorizar centenas de parâmetros, essa tarefa torna-se praticamente impossível. Para ajudar na compreensão e descodificação dos dados, o Cacti permite organizar os gráficos de várias maneiras, como àrvores de gráficos ou coleccionando todos os gráficos de um dos tipos por baixo de um gráfico-mor, só para citar alguns exemplos. Há uma infinidade de formas de organizar os gráficos, tudo depende das necessidades do administrador de rede. DUD/URT 8/

9 Também é possível alimentar o Cacti com dados de outras fontes que não o SNMP. Basta indicar-lhe o caminho do script (qualquer linguagem que corra da linha de comando Linux serve) e ele recolhe a informação num cron e popula as bases de dados. Estão disponíveis mais de 20 scripts já desenvolvidos por outros utilizadores que vão desde recolher dados de filas Sendmail até armazenar estatísticas do Apache. DUD/URT 9/

10 ZenOSS O ZenOSS é uma plataforma de gestão de serviços, máquinas e pontos de rede baseada no servidor aplicacional Zope e que permite ao administrador de rede monitorizar a disponibilidade, inventário, configuração, performance e eventos da sua rede de dados. Ecrã principal do ZenOSS Existem duas versões, o ZenOSS Core que é livre, ou seja em código aberto e sem custos de licenciamento, e o ZenOSS Enterprise que tem maior capacidade de monitorização mas também maiores custos. O ZenOSS Core fornece as seguintes possibilidades de monitorização: - Monitorização da disponibilidade de equipamentos de rede através de SNMP, SSH e WMI; - Monitorização de serviços de rede, como o http, POP3, NNTP, SNMP e FTP; - Monitorização de recursos de máquinas (utilização do processador, ocupação do disco) na maioria dos sistemas operativos; - Monitorização da performance de dispositivos através de sequências temporais de dados; - Maior capacidade de monitorização de máquinas Microsoft Windows via Windows Management Instrumentation, através do SAMBA e das extensões de código aberto do ZenOSS; - Ferramentas de gestão de eventos para melhor tomar nota de alarmes do sistema; - Descoberta automática da rede e de alterações à configuração e topologia da mesma; - Sistema de alerta que providencia notificações baseadas em regras e calendário; - Suporta o sistema de plugins do Nagios. DUD/URT 10/

11 A versão Enterprise providencia suporte comercial e capacidades adicionais, como transações Web sintéticas e vistas globais do sistema. Como se configura? O processo de instalação do ZenOSS é relativamente fácil e a documentação oficial é abundante e de boa qualidade. Depois de instalar as dependências, basta descarregar o ficheiro comprimido do ZenOSS e correr o script de instalação que vêm com ele. O interface Web corre na porta Um utilizador casual consegue descobrir equipamentos e máquinas clicando aqui e ali, mas sem uma noção de como funciona o ZenOSS um administrador de rede facilmente fica frustrado. Basicamente, tudo está, ou pode ser, organizado em Classes. Existem outros componentes organizativos, como Sistemas, Localizações e Grupos, mas fundamentalmente os equipamentos acabam enquadrados numa Classe. Esta classificação é muito importante pois é nela que assentam as principais vantagens da utilização do ZenOSS. Janela de configuração das propriedades de uma Classe Para adicionar um equipamento manualmente, a única informação necessária é o hostname e a Classe a que este pertence, pois o processo de descoberta automática do ZenOSS faz o resto. A partir do momento em que o equipamento for descoberto, não demora muito tempo até que se comecem a ver gráficos de utilização de largura de banda, de performance do CPU ou memória, e outra informação interessante. Durante o processo de descoberta automática, o ZenOSS vai agrupando todos equipamentos semelhantes (switches Cisco, servidores HP, etc) nas Classes definidas, disponibilizando assim fáceis pontos de acesso a toda a informação recolhida. DUD/URT 11/

12 Relatórios multi-gráfico do ZenOSS Como adicionar elementos manualmente pode ser um pouco trabalhoso, o ZenOSS também é capaz de descoberta automática de Layer 3, ou seja, é capaz de encontrar informação IP, como tabelas de roteamento por exemplo, e enumerar as máquinas encontradas automaticamente. Fazer esta descoberta automática numa sub-rede pode não ser, no entanto, um processo directo ou rápido e implica sempre que, mais tarde, se perca algum tempo a adicionar os dispositivos encontrados às respectivas Classes. Quando queremos adicionar equipamentos de rede, o processo ainda se torna mais simples: basta fornecer ao ZenOSS as nossas strings de comunidade SNMP e ele descobre automaticamente a topologia de Layer 3 e desenha um mapa interactivo da rede de dados. Neste mapa, se colocarmos o rato sobre um qualquer equipamento podemos ver imediatamente gráficos de utilização de largura de banda, por exemplo, ou listas de interfaces e as suas descrições. Para aproveitar todas as funcionalidades do ZenOSS, no entanto, será ainda necessário, como no caso das máquinas, atribuir manualmente uma Classe a cada um dos equipamentos descobertos. Exemplo de um mapa de rede do ZenOSS DUD/URT 12/

13 Por fim, a configuração da alarmística é toda ela feita em ambiente gráfico, o que é uma vantagem, mas ainda assim resulta numa das partes mais complexas e difíceis de configurar no ZenOSS. DUD/URT 13/

14 Zabbix O Zabbix é uma solução de código aberto para monitorização distribuída de pontos de rede e monitoriza numerosos parâmetros de rede, bem como a saúde e integridade de servidores. Usa um sistema de notificações flexível, que permite ao utilizador configurar alertas para praticamente todo o tipo de eventos. O Zabbix também oferece uma óptima visualização dos dados e um excelente sistema de relatórios, o que o torna especialmente útil no planeamento da capacidade de uma rede de dados. Dashboard do Zabbix Todos os relatórios e estatísticas do Zabbix, bem como os parâmetros de configuração, estão acessíveis através de um frontend baseado em páginas Web, o que assegura que o administrador de rede possa aceder à informação em qualquer sítio do mundo. O Zabbix é, essencialmente, constituído por 3 componentes: - O servidor Zabbix: o centro de comando da aplicação. É o elemento para o qual todos os agentes reportam as informações relativas às máquinas monitorizadas e é nele que se armazena toda a configuração, estatísticas e dados operacionais. Para além disso, também permite a monitorização remota de serviços de rede através de controlos simples e é o componente responsável pelo alerta aos administradores quando surgir um problema de rede nos equipamentos monitorizados; - O interface Web: permite o fácil acesso à informação de configuração e monitorização do Zabbix, em qualquer lugar e em qualquer plataforma. A interface é uma parte do servidor Zabbix, um programa executado por ele, mas, apesar de isso não ser comum, pode ser corrido numa máquina física diferente; - O agente Zabbix: para o servidor Zabbix poder acompanhar activamente recursos e aplicações locais, alguns sistemas necessitam da instalação de um agente Zabbix. É esse agente que vai recolher os dados relevantes e enviá-los para o servidor para posterior processamento. DUD/URT 14/

15 Exemplo da relação entre servidor e agente na monitorização de um equipamento Como se configura? Para instalar o Zabbix é necessário fazer duas coisas: instalar o servidor e instalar o agente. Tanto para o servidor como para o agente, deve-se descarregar o ficheiro comprimido, criar o utilizador, e o respectivo grupo, que vai correr o Zabbix, descomprimir os ficheiros e recursos, criar a base de dados e populá-la e, finalmente, configurar, compilar e correr o instalador do Zabbix e o do agente. De seguida, é necessário ainda preparar o resto do sistema, adicionando as permissões e a definição das portas que o Zabbix vai utilizar para comunicar com o agente. Depois de iniciar o servidor e o agente, passamos à configuração do interface Web. É uma configuração simples que se resume a acrescentar algumas linhas nos ficheiros de configuração do Apache. frontends/php/include/db.inc.php $DB_TYPE ="MYSQL"; $DB_SERVER ="localhost"; $DB_DATABASE ="zabbix"; $DB_USER ="root"; $DB_PWD ="secret"; mkdir /home/zabbix/public_html cp -R frontends/php/* /home/zabbix/public_html/ cd../public_html && chown -R zabbix.zabbix. vi /etc/apache/httpd.conf <Directory /home/*/public_html> AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec <Limit GET POST OPTIONS PROPFIND> Order allow,deny Allow from all </Limit> <LimitExcept GET POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Directory> DUD/URT 15/

16 /etc/init.d/apache restart Exemplo de configuração do Apache para o Zabbix De seguida, apontamos o navegador para o endereço do Zabbix e efectuamos o login. Os primeiros passos para a configuração do sistema de monitorização são utilizar os tabs Configuration e Hosts para criar um host-group e, de seguida, adicionar-lhe alguns modelos de dispositivos, como por exemplo Aplication.SQL, Host.SNMP, Host.Unix, etc. A partir desse momento, os parâmetros começam a ser importados para o sistema e se formos ao tab Monitoring podemos ver os valores a serem processados à medida que chegam. Alguns exemplos dos gráficos gerados pelo Zabixx O resto da configuração pode ser bastante complexa e específica relativamente à rede a monitorizar, pelo que sai fora do âmbito deste documento. DUD/URT 16/

17 Munin O Munin é uma ferramenta de monitorização de recursos de rede que ajuda a analisar tendências e problemas do tipo o que é que aconteceu para reduzir drasticamente a minha performance de rede?. Exemplo de uma janela do Munin Foi desenhado para ser extremamente Plug and Play e, por isso, uma instalação por defeito é capaz de gerar bastantes gráficos com muito pouco trabalho por parte do administrador da rede. Tal como o Cacti, o Munin utiliza o RRDTool para apresentar os dados recolhidos em forma de gráfico através de um interface Web. Utiliza uma arquitectura cliente/servidor em que o servidor requisita aos elementos monitorizados (clientes), em intervalos de tempo regulares, a informação pretendida. Exemplo de uma janela do Munin O Munin torna bastante simples detectar qual foi o problema quando existe uma degradação da performance de rede e aferir com muita clareza qual a real utilização de recursos mais escassos. DUD/URT 17/

18 Como se configura? O Munin foi desenhado para ser uma ferramenta simples de usar, por isso não é surpresa que a instalação e configuração sejam também bastante simples. É necessário descarregar e instalar a aplicação central e a aplicação cliente, e a configuração é toda feita através de ficheiros de configuração que ficam na directoria /etc/munin. # The data storage area dbdir /var/lib/munin # The place to put the generated web pages htmldir /var/www/munin # The log files logdir /var/log/munin # Temporary run files (pid file etc) rundir /var/run/munin # Where to look for the HTML templates tmpldir /etc/munin/templates No ficheiro munin.conf fazemos a configuração da parte que recolhe a informação e desenha os gráficos. A configuração por defeito está feita de modo a monitorizar a própria máquina onde o Munin está instalado, mas no próprio ficheiro podemos encontrar exemplos de como adicionar mais equipamentos para monitorização. [localhost.localdomain] address use_node_name yes O munin-node.conf é o responsável pela configuração do software cliente e é onde especificamos, por exemplo, quais os servidores que o podem contactar e recolher os dados relevantes. O ficheiro plugin-conf.d na directoria munin-node/ serve, como o nome indica, para configurar os plugins no software cliente. A sintaxe é bastante simples, basta indicar o nome do plugin e, por baixo, definir os parâmetros que se apliquem. DUD/URT 18/

19 Exemplo da vista com todas as informações monitorizadas de um cliente (node) Existe ainda uma directoria plugins/ onde cada ficheiro é uma ligação simbólica para um plugin real colocado em /usr/share/munin/plugins. Se um determinado plugin estiver presente na directoria é porque os parâmetros que especifica vão ser verificados e serão gerados gráficos com a informação recolhida. É importante não esquecer que depois de adicionar os plugins é necessário ainda configurar no munin-node.conf os privilégios do utilizador e respectivo grupo que o vai correr. Para verificar se a instalação do plugin foi bem sucedida, a maioria dos plugins podem ser corridos na linha de comandos com o parâmetro autoconf../exim_mailstats autoconf yes O Munin cria um cron através do ficheiro /etc/cron.d/munin que vai correr o /usr/bin/munincron. Ao correr este ficheiro estamos na realidade a contactar cada um dos clientes, a recolher a informação e a criar os gráficos em /var/www/html que podem depois ser acedidos em DUD/URT 19/

20 Exemplo de gráficos gerados pelo Munin DUD/URT 20/

21 Tabela comparativa das funcionalidades suportadas pelas ferramentas de monitorização apresentadas Name IP SLA Reports Logical Grouping Trending Trend Prediction Auto Discovery Agent SNMP Syslog Plugins Triggers / Alerts WebApp Distributed Monitoring Inventory Data Storage Method License Maps Access Control IPv6 Cacti Sim Sim Sim Sim Via plugin Não Sim Sim Sim Sim Controlo Total Sim Sim RRDtool, MySQL GPL Via Plugin Sim Sim Nagios Via plugin Sim Sim Não Via plugin Suportado Via plugin Via plugin Sim Sim Controlo Total Sim Via plugin Flat file, SQL GPL Sim Sim Sim Zabbix Sim Sim Sim Sim Sim Suportado Sim Sim Sim Sim Controlo Total Sim Sim Oracle, MySQL, PostgreSQL,IBM DB2, SQLite GPL Sim Sim Sim Zenoss Sim Sim Sim Sim Sim Não Sim Sim Sim Sim Controlo Total Sim Sim ZODB, MySQL, RRDtool Versão livre e comercial Sim Sim Não Munin Não Não Sim Sem informações Não Sim Sim Não Sim Parcial Visualização Sem informações Sem informações RRDtool GPL Sem informações Sem informações Sim DUD/URT 21/

22 Resumo comparativo O Nagios é a mais popular das aplicações apresentadas o que, visto estarmos a falar de aplicações de código aberto, implica que possui o maior número de plugins, tem mais suporte técnico e menos bugs; O Nagios é a mais antiga das aplicações apresentadas. Não foi, portanto, desenhada para ser de fácil utilização e configuração, nem tem algumas das opções e capacidades que as ferramentas mais recentes já oferecem, como a possibilidade de prever tendências na rede por exemplo; O Nagios não tem boa escalabilidade; O Cacti é óptimo como ferramenta de estatísticas e visualização de tendências de uma rede de dados, produzindo gráficos muito bonitos e completamente costumizáveis; O ZenOSS não tem suporte para IPv6; O Zabbix, apesar da melhoria que representa o seu ambiente gráfico, é de configuração bastante complexa pelo que implica algum tempo de exploração e habituação para se conseguir tirar partido de todas as suas capacidades; O ZenOSS tem a possibilidade de descoberta automática dos elementos de rede; A grande vantagem do Cacti são as diferentes formas de apresentação da informação que permitem tirar conclusões muito interessantes acerca do funcionamento da rede; O Nagios é muito flexível, sendo possível integrar nele algumas das outras ferramentas apresentadas; O Cacti tem uma óptima definição de permissões. É possível criar um utilizador que apenas tenha acesso a visualizar um determinado gráfico numa determinada àrvore; O ZenOSS tem integração com o Google Maps, o que permite uma melhor visualização de estado em redes geograficamente muito dispersas; A versão código aberto é bastante limitada quando comparada com a versão comercial; O Zabbix produz gráficos em real-time (os valores são recolhidos cada 30 segundos), pelo que é fácil apercebermo-nos de um eventual erro de configuração da monitorização; O Zabbix guarda a informação recolhida numa base de dados. Assim, os períodos durante os quais esta é guardada são configuráveis e tudo o que é necessário fazer é backup da base de dados; O Zabbix tem óptima performance devido ao sistema de recolha de informação através de um agente. O servidor apenas necessita de uma boa performance I/O e de bastante memória para lidar com a base de dados; O Zabbix é difícil de configurar e depurar. É necessária alguma paciência para apreender os conceitos em que se baseia, o interface Web tem inúmeras opções, e o programa nem sempre fornece informação acerca do estado dos seus processos; O Munin é muito simples de configurar e instalar, e a instalação por defeito produz muitos gráficos quase sem trabalho nenhum; DUD/URT 22/

23 O Munin produz informação que torna mais simples detectar o que mudou na eventualidade de um problema de rede; O Munin foi desenhado com a simplicidade em vista, pelo que não é muito poderoso. Tem uma arquitectura de Plug-and-Play que permite que se instalem plugins com bastante facilidade, mas que perde para outras ferramentas em termos de configurabilidade. DUD/URT 23/