Faculdade de Engenharia da Universidade do Porto

Monitorizao de SLA IP
Paulo Jorge Lopes Soares Vaz

Relatrio de Projecto realizado no mbito do

Mestrado Integrado em Engenharia Electrotcnica e de Computadores
Major Telecomunicaes
Orientador: Prof. Joo Manuel Couto das Neves
Julho de 2010

 Paulo Vaz, 2010

ii

Resumo

Com o crescimento exponencial da Internet e a sua contnua evoluo, assiste-se a um

aumento da importncia e dependncia nos servios de rede por parte das empresas, o que as
leva a procurar junto das operadoras e fornecedoras de servios maiores garantias de
desempenho e qualidade de servio, uma vez que uma eventual falha pode ser muito
prejudicial, quer ao nvel financeiro, quer ao nvel da competitividade da empresa.
Para tal existe o chamado Service Level Agreement, um contrato entre um Service
Provider e um cliente (empresa) que define quais as expectativas que ambos devem ter em
termos de definio de servios, disponibilidade, desempenho e operacionalidade do sistema.
Para essa contratualizao quer o administrador da rede quer os SP tm de saber quais as
mtricas a monitorizar, quem as vai monitorar e como elas iro ser monitorizadas. Se isto no
estiver bem definido pode levar a confuses sobre as responsabilidades atribudas a cada
entidade e insatisfao com o SLA acordado.
Este projecto procura desenvolver uma ferramenta que utilizando um interface Web
permita a monitorizao, gerao de alertas e gesto dos vrios SLA contratados para
circuitos ou servios e sistemas de uma rede empresarial.

iii

iv

Abstract

With the exponential growth of Internet and its continuing evolution, we are witnessing
an increasing importance and reliance on network services for businesses, which leads them
to look at operators and service providers for greater assurance in terms of quality and
performance service, since a failure can be very damaging, both financial and in terms of
competitiveness.
To this end, there is the Service Level Agreement, a contract between a Service Provider
and a client that defines the expectations that both should have in terms of services,
availability, performance and operability of the system. For such contracts, either the
network administrator or the SP has to know what metrics to monitor, how they will be
monitored and those who will monitor. If this is not well defined, it can lead to confusion
about the responsibilities assigned to each entity and to dissatisfaction with the agreed SLA.
This project seeks to develop a tool using a web interface that allows monitoring, alarm
generation and management of various SLA contracted for circuits or services and systems in
a corporate network.

vi

NDICE
INTRODUO ............................................................................................ 1
1.1

TEMA E CONTEXTO .............................................................................. 1

1.2

OBJECTIVO ...................................................................................... 3

1.3

ESTRUTURA DA DISSERTAO .................................................................... 3

SLA ........................................................................................................ 5
2.1

OBJECTIVOS E PROCESSO DE DESENVOLVIMENTO .................................................. 5

2.2

DESCRIO ...................................................................................... 6

2.3

PROBLEMAS ..................................................................................... 7

2.4

SLA EM REDES IP ............................................................................... 7

ESTADO DA ARTE ....................................................................................... 9

3.1

NAGIOS ......................................................................................... 9

3.2

CACTI .......................................................................................... 14

3.3

OPSVIEW ....................................................................................... 18

3.4

OPENNMS ..................................................................................... 22

3.5

ZABBIX ......................................................................................... 24

3.6

ZENOSS ........................................................................................ 26

3.7

CISCO IOS IP SERVICE LEVEL AGREEMENTS ..................................................... 28

3.8

CONCLUSES ................................................................................... 31

PLANO DE TRABALHO ................................................................................ 33

4.1

PLANO DE TAREFAS ............................................................................. 33

4.2

CALENDARIZAO .............................................................................. 34

REFERNCIAS ........................................................................................... 35

vii

viii

Lista de figuras

Figura 1.1 - Tripla redundncia de rede............................................................. 2

Figura 3.1 Nagios: Interface Grfica .............................................................. 10
Figura 3.2 Nagios: Sumrio ......................................................................... 10
Figura 3.3 Nagios: Estado dos servios ............................................................ 11
Figura 3.4 Nagios: Alertas........................................................................... 11
Figura 3.5 Nagios: Notificaes .................................................................... 14
Figura 3.6 Cacti: Princpios de Funcionamento ................................................. 15
Figura 3.7 Cacti: Equipamentos .................................................................... 16
Figura 3.8 Cacti: rvore de grficos .............................................................. 17
Figura 3.9 Cacti: Gesto Utilizadores ............................................................. 17
Figura 3.10 Opsview: Interface Grfica........................................................... 18
Figura 3.11 - Opsview: Estado de host e servios ................................................. 20
Figura 3.12 Opsview: Mapa da rede ............................................................... 20
Figura 3.13 OpenNMS: Interface Grfica ......................................................... 22
Figura 3.14 - OpenNMS: Alertas e Notificaes ................................................... 23
Figura 3.15 Zabbix: Organizao .................................................................. 24
Figura 3.16 Zabbix: Interface Grfica............................................................. 25
Figura 3.17 Zenoss: Interface Grfica ............................................................ 27
Figura 3.18 Zenoss: Viso Geral ................................................................... 28
Figura 3.19 Cisco IOS IP SLA funes, mtricas e operaes ................................. 30

ix

Lista de tabelas

Tabela 1.1 - Disponibilidade: Tempo de downtime em minutos ................................ 2

Tabela 4.1 Calendarizao do Projecto .......................................................... 34

xi

xii

Lista de acrnimos e abreviaturas

AP

Access Point

CLI

Command Line Interface

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name System

FCAPS

Fault, Configuration, Accounting, Performance, Security

FTP

File Transfer Protocol

GPL

General Public License

HTTP

Hypertext Transfer Protocol

ICMP

Internet Control Message Protocol

IETF

Internet Engineering Task Force

IP

Internet Protocol

IPMI

Intelligent Platform Management Interface

LDAP

Lightweight Directory Access Protocol

MAC

Media Access Control

MPLS

Multiprotocol Label Switching

NMS

Network Management System

NNTP

Network News Transfer Protocol

NRPE

Nagios Remote Plugin Executor

POP3

Post Office Protocol verso 3

QoS

Quality of Service

RRD

Round Robin Database

RTT

Round-Trip Delay Time

SLA

Service Level Agreement

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

SP

Service Provider

SQL

Structured Query Language

SSH

Secure Shell

UPS

Uninterruptible Power Supply

WMI

Windows Management Instrumentation

xiii

xiv

Captulo 1
Introduo
Este captulo pretende apresentar uma viso geral do trabalho a desenvolver para a
presente dissertao, atravs da exposio do tema abordado, descrio dos seus objectivos e
finalmente a apresentao da estrutura do relatrio.

1.1

Tema e Contexto

Com o crescimento exponencial da Internet e a sua contnua evoluo, que permitiu o

acesso a novos tipos de servio, verifica-se actualmente um aumento da importncia e da
dependncia nos servios de rede por parte das empresas, o que as leva a procurar maiores
garantias de desempenho e qualidade de servio por parte das operadoras e fornecedoras de
servios, uma vez que uma eventual falha pode ser muito prejudicial, quer ao nvel
financeiro, quer ao nvel da competitividade da empresa.
Um administrador de rede tem de controlar um sistema mais complexo, com um nmero
cada vez maior de equipamentos e servios, o que aliado necessidade de obteno de
informao rpida sobre problemas que tenham ocorrido ou que estejam prestes a acontecer
devido aos prejuzos que uma eventual falha na rede ou um tempo de downtime, por mnimo
que seja podem provocar, tornam incomportvel a monitorizao manual do sistema.
Assim as empresas necessitam de ter uma forma de previso e monitorizao de servios
IP independentemente do custo. A entra o SLA (Service Level Agreement), que por definio,
um contrato entre um SP (Service Provider) e um cliente que define as expectativas que
ambos devem ter em termos de definio de servios e consequente disponibilidade,
desempenho e operacionalidade do sistema. Para a gesto apropriada dos servios deve haver
um consenso sobre os servios entre o SP e o cliente.
Com um SLA o administrador da rede tem a capacidade de definir quais os nveis de
servio adequados para aplicaes e servios crticos e essenciais para o normal
funcionamento da empresa, tendo em ateno a eficincia da rede e a experincia de
utilizao por parte do utilizador comum, podendo proceder a alteraes na configurao da
rede com base em mtricas de desempenho optimizadas. Ao isolar de forma proactiva os
1

Introduo

problemas da rede podem tambm reduzir o tempo de deteco e reparao de problemas.

Na ptica do cliente, os SLA servem tambm para verificar se o SP est a cumprir com os
nveis acordados e contratados e em caso de falha procurar ser ressarcido pelos eventuais
prejuzos causados.
Como tal as empresas procuram junto dos SP garantir nveis de disponibilidade de servio
altos para que os tempos de downtime sejam os mais reduzidos possveis. Essa
disponibilidade, tal como descrito em [1], pode ser expressa como uma percentagem de
uptime por ano, ms, semana, dia ou hora comparada com o tempo total desse perodo.
Algumas empresas podero mesmo necessitar de 99,999%, os chamados cinco noves, de
disponibilidade, que tal como se encontra indicado na Tabela 1.1, indica 5 minutos de
downtime por ano.

Tabela 1.1 - Disponibilidade: Tempo de downtime em minutos

Disponibilidade

Hora

Diria

Semanal

Anual

Anual (Horas)

99,999%

0,0006

0,01

0,1

99,98%

0,012

0,29

105

1h 45min

99,95%

0,03

0,72

263

4h 23min

99,90%

0,06

1,44

10

526

8h 46min

99,70%

0,18

4,32

30

1577

26h 17min

99,50%

0,3

7,2

50,4

2628

43h 48min

Algo que para se conseguir obter implica tripla redundncia, isto, 3 ISP diferentes a
fornecer o servio a uma mesma empresa, tal como apresentado na Figura 1.1.

Figura 1.1 - Tripla redundncia de rede, em [1]

Introduo

Esta, ou outras solues que garantam qualidade de servio com nveis inferiores, pode
apresentar custos muito elevados, o que aliado necessidade que a empresa tem de verificar
se o acordo com os SP est a ser cumprido, implementando solues de monitorizao e
gesto de servios, pode levar a que a empresa seja incapaz de suportar os custos associados
a este conjunto de solues.
Para os SP a definio dos SLA tambm tem vantagens. Obtm maiores margens de lucro,
aumentam a satisfao do cliente e melhoram a posio competitiva.

1.2

Objectivo

O objectivo desta dissertao passa por desenvolver uma ferramenta que permita
monitorar e gerir os SLA contratados para circuitos ou sistemas de uma rede empresarial.
Esta ferramenta resultar da integrao e configurao de ferramentas open source,
utilizando um interface Web que permitir a monitorizao, gerao de alertas e gesto dos
vrios SLA definidos para servios e sistemas na rede.

1.3

Estrutura da dissertao

Este relatrio encontra-se organizado em quatro captulos.

No primeiro captulo descrita a motivao para o desenvolvimento desta dissertao e
os objectivos da mesma.
No segundo captulo descrito o que so SLAs e IP SLAs fazendo referncia a mtricas
tpicas, operaes suportadas e a sua evoluo.
No terceiro captulo so apresentadas solues actuais, disponveis no mercado, para a
monitorizao de SLAs IP.
No quarto captulo apresentado o plano de trabalho a desenvolver, bem como a
calendarizao das diferentes fases de trabalho.

Introduo

Captulo 2
SLA
Neste captulo descrito o que so SLAs e IP SLAs fazendo uma breve apresentao sobre
os objectivos, desenvolvimento e problemas.

2.1

Objectivos e processo de desenvolvimento

Os objectivos de um SLA passam por ser um meio de preveno e resoluo de conflitos,

melhor gesto dos recursos financeiros, definio da qualidade de servio entre outras. Deve
ser definido e usado de acordo com as caractersticas dos servios pretendidos pelo cliente e
especificam as obrigaes que clientes e SPs devem respeitar em termos de desempenho,
disponibilidade e segurana de servios bem como os procedimentos a realizar em caso de
falha desse servio. Um SLA pode ser especificado quer para servios j utilizados pelo
cliente, quer para sistemas que ainda nem sequer foram projectados.
O processo de desenvolvimento de um SLA passa por:
Identificao das necessidades do cliente;
Determinao dos nveis de servio;
Acordo entre cliente e SP em termos de:
o Nveis de servio;
o Preveno de conflitos;
o Gesto de expectativas;
Definio das regras de colaborao entre cliente e SP.

2.2

SLA

Descrio

Um SLA a formalizao de QoS (Quality of Service) num contrato entre um cliente e um

SP, tal como descrito em [1].
Geralmente um SLA, tal como descrito em [2] composto por:
Descrio do servio a ser disponibilizado;
Descrio do nvel de desempenho do servio, definindo parmetros como fiabilidade,
disponibilidade e segurana;
Descrio de procedimentos para comunicao de problemas, desde entidade a
contactar at forma de apresentao formal do problema;
Definio do tempo mximo de resposta (tempo desde que o problema comunicado
pelo cliente at que algum do SP o comece a resolver) a um problema;
Definio de tempo mximo de resoluo do problema;
Descrio da forma como se processa a monitorizao e gesto dos servios, quem
est a monitorizar o sistema, que tipos de dados podem ser monitorizados, perodo de
amostragem, onde e como esses dados devem ser guardados e permisses de acesso a
esses dados;
Descrio das consequncias a que o SP est sujeito em caso de falha no cumprimento
das obrigaes acordadas, que passam por condies para resciso de contrato at
indemnizaes a atribuir em caso de perda de receitas por falha de servio;
Definio das condies que permitem ao SP no respeitar, num determinado
momento, os nveis de servio acordados.
Um SLA dever assim apresentar uma viso geral dos diferentes parmetros que compem
os servios contratados, as situaes em que podem ocorrer falhas e como resolv-las,
procurando encontrar um equilbrio entre as necessidades e expectativas do cliente e aquilo
que o SP pode ou quer fornecer.
Um SLA deve ser especificado em termos de eficincia e caractersticas de negcio:
o Conhecimento das necessidades do cliente leva correcta identificao das
prioridades em relao aos elementos que compem um SLA;
o O peso relativo dos elementos de um SLA deve ter em conta as caractersticas
do negcio da empresa;
O desenvolvimento de um SLA deve ser efectuado de forma organizada e estruturada
o que permite evitar tomadas de decises precipitadas que possam levar obteno
de um SLA incompleto;
Um SLA mais efectivo se tanto o SP como o cliente compreendam o seu contedo;
Um SLA deve ser baseado em elementos como disponibilidade, segurana,
desempenho, apoio ao utilizador e preveno de desastres de preferncia utilizando
termos que possam ser mensurveis de forma a aumentar o nvel de compreenso e
limitar os problemas e conflitos que especificaes subjectivas podem provocar;
Diferentes grupos de utilizadores tm diferentes necessidades, o que deve levar a
uma diferenciao de servios e a uma mais eficiente utilizao destes.

SLA

2.3

Problemas

Tal como descrito em [3] os SLA apresentam alguns problemas que passam por:
Especificao do esforo vs especificao de resultados: Geralmente os SLAs referem
apenas o esforo que um SP tem de despender em caso da ocorrncia de falhas na
rede, no existe referncias para os objectivos que um dado servio deve cumprir;
Especificao de mtricas pouco clara: Alguns dos termos utilizados na especificao
dos elementos dos SLAs podem ser de difcil compreenso. Por exemplo, ser que um
cliente sabe o que quer dizer uma disponibilidade de servio de 98%? Saber qual a
diferena entre disponibilidade de 98% ou 99%?
Especificao de servios incompleta: Existe dificuldade em especificar com
exactido parmetros como controlo de segurana e previso de catstrofes, uma vez
que geralmente s aps estes problemas ocorrerem que se consegue descrever com
exactido tudo o que pode ocorrer;
Gesto de custos incorrecta: Apesar de indicar qual o custo que um determinado
servio possu, geralmente este no se encontra diferenciado e relacionado com as
necessidades do cliente. Ou seja a relao preo/desempenho para o cliente no
optimizada.
Como consequncia, um SLA pode torna-se um documento de difcil compreenso, restrita
apenas a um pequeno conjunto de pessoas com elevada formao tcnica, o que pode levar a
confuses sobre as responsabilidades atribudas a cada entidade, dificuldade de interpretar
correctamente os servios acordados e insatisfao do cliente com o SLA acordado.

2.4

SLA em Redes IP

Tal como descrito em [2] no contexto das redes IP um SLA pode ser fornecido para trs
tipos de ambientes, servios de conectividade de rede, servios de alojamento e servios de
integrao entre os servios de conectividade e alojamento, sendo os recursos dentro da rede
fornecidos para cumprir os objectivos de desempenho e disponibilidade desejados, reduzindo
dessa forma o custo operacional sem provocar um impacto negativo na satisfao do cliente.
Nos servios de conectividade de rede, as redes dos clientes encontram-se ligadas
directamente rede do ISP atravs de routers que se encontram nos APs (Acess Points). Para
este tipo de redes os limites de disponibilidade e desempenho passam por exemplo por:
Latncia atravs da rede do ISP entre 2 routers de acesso do cliente na mesma rea;
Latncia atravs da rede do ISP entre 2 routers de acesso do cliente no mesmo pas;
Latncia atravs da rede do ISP entre 2 routers de acesso do cliente em continentes
diferentes;
Tempo de quebra de ligao (perda de 100% de pacotes medidos atravs de um ping).

SLA

Servios de alojamento so oferecidos por operadores que suportam e alojam os

diferentes tipos de servidores dos seus clientes. Estes servios vo desde alojamento de stios
Web (Web Hosting), locais para guardar servidores, manuteno de servidores ou dos
contedos e aplicaes alojadas no stio.
Os SLA oferecidos para este tipo de servios passam pelos tempos de uptime e o nvel de
desempenho dos servidores que esto a ser alojados. Estes operadores controlam apenas as
comunicaes do lado do servidor, no tm nenhum controlo sobre as comunicaes do lado
do cliente, nem sobre o desempenho da rede. Pode tambm alojar mltiplos clientes num
mesmo stio e dessa forma responsvel por assegurar que a performance de um servidor de
um cliente no afectada pelos pedidos direccionados a outros clientes.
Elementos tpicos de performance e disponibilidade so os seguintes:
Tempo de indisponibilidade de um servidor alojado;
Nmero de pedidos que um servidor pode suportar;
Nmero mnimo de servidores disponveis em todo o momento;
Throughput (taxa de transferncia) suportado por um determinado servidor.
Um terceiro tipo de servio fornece um servio consolidado em que o SP controla a rede
bem como a infra-estrutura de alojamento. Alguns exemplos de elementos presentes num SLA
so os seguintes
Tempo mximo de pesquisa;
Downtime, no programado, do servidor de correio electrnico.
Em todos estes ambientes operacionais, a natureza dos servios fornecidos, os objectivos
de desempenho e disponibilidade e os mecanismos usados para monitorizar o desempenho dos
servios diferentes, mas os componentes dos SLA so relativamente semelhantes.

Captulo 3
Estado da Arte
Neste captulo so apresentadas solues actuais, disponveis no mercado, para a
monitorizao de SLAs IP.

3.1

Nagios

O Nagios uma ferramenta open source para monitorizao de sistemas de rede,

desenhada para correr em ambientes Unix e licenciada nos termos da licena GNU GPL
(General Public License) verso 2, sendo por isso um software livre.
Faz a monitorizao de servios de rede como o SMTP (Simple Mail Transfer Protocol),
POP3 (Post Office Protocol verso 3), HTTP (Hypertext Transfer Protocol), NNTP (Network
News Transfer Protocol), ICMP (Internet Control Message Protocol), SNMP (Simple Network
Management Protocol), FTP (File Transfer Protocol), SSH (Secure Shell) e DNS (Domain Name
System) bem como a monitorizao de recursos (como carga do processador ou utilizao de
disco) de diversos tipos de equipamentos como servidores (Windows ou Unix), routers,
switches ou impressoras.
O Nagios, tal como indicado em [4] e [5], apresenta informao ou atravs de um pagina
Web, apresentada na Figura 3.1, ou atravs de e-mail ou mesmo por SMS de acordo com os
parmetros definidos pelo administrador da rede que est a ser monitorizada.

10

Estado da Arte

Figura 3.1 Nagios: Interface Grfica, em [6]

A interface Web apresenta informao diversificada, desde um sumrio da situao geral,

Figura 3.2, apresentao de servios problemticos, estado de servios, Figura 3.3,
procurando apresentar a informao de forma estruturada e individualizada, apresentando
por exemplo quem foi informado e que tipo situao ocorreu, Figura 3.4.
Geralmente as condies de servio encontram-se divididas em trs categorias:
Funcionamento normal (apresentao grfica a verde na pgina Web);
Aviso (apresentao grfica a amarelo na pgina Web);
Situaes crticas (apresentao grfica a vermelho na pgina Web).

Figura 3.2 Nagios: Sumrio, em [6]

Estado da Arte

11

Figura 3.3 Nagios: Estado dos servios, em [6]

Figura 3.4 Nagios: Alertas, em [6]

12

Estado da Arte

O Nagios utiliza o conceito de objectos. Como objectos entende todos os elementos que
esto envolvidos na lgica de monitorizao e notificao. Esses objectos so
Hosts equipamentos fsicos da rede (servidores, workstations, routers, switches e
impressoras identificados por um endereo (IP (Internet Protocol) ou MAC (Media
Acess Control)), podendo ter um ou mais servios associados e ter uma relao
pai/filho com outros hosts. Podem ser associados nos chamados Host Groups de forma
a permitir uma visualizao mais simplificada do seu estado ou configuraes na
interface Web;
Servios Associados a hosts representam recursos destes como carga do processador,
utilizao de disco, ou servios oferecidos como HTTP, FTP, SSH, DNS podendo
tambm eles ser agrupados em Service Groups com o mesmo efeito dos Host Groups;
Contactos Pessoas que esto envolvidos no processo de notificao, onde est
englobado mtodos de notificao, tipos de notificao a receber. Tambm podem
ser agrupados em Contact Groups de forma a facilitar a definio de utilizadores a
notificar;
Perodos de Tempo Engloba perodos de monitorizao de hosts e servios e de
notificao a contactos;
Comandos Utilizados para indicar ao Nagios que programas ou scripts deve executar.
Aqui encontram-se os hosts, service checks e as notificaes.
Ao contrrio de outras ferramentas de monitorizao o Nagios apresenta uma estrutura
modular, utilizando programas externos, criados geralmente por elementos da comunidade,
que adicionam novas funcionalidades de monitorizao, informao e notificao,
melhorando o desempenho do Nagios e tornando-o uma ferramenta mais poderosa. Esses
programas so denominados de plugins, e podem ser obtidos em [7] e [8]. Estes plugins so
executados quando necessrio verificar o estado de um host ou servio retornando os
resultados para o Nagios, que por sua vez processa esses resultados e toma as medidas
necessrias, como por exemplo notificar contactos. Desde que o plugin tenha sido criado, o
Nagios pode testar tudo aquilo que possa ser medido electronicamente, desde temperatura e
humidade de salas de servidores, a muitos outros tipos de informao desde que essa
informao possa ser avaliada a partir de um computador.
O Nagios realiza vrios testes distinguindo esses testes entre host check e service check.
Um host check, realiza testes simples como um ping para verificar e testar a atingibilidade de
mquinas especficas, sendo realizado em intervalos de tempo regulares (definindo para isso
as opes ceck_interval e retry_interval nas definies de host) ou ento apenas quando lhe
solicitado. Por exemplo, se um dos servios monitorizados estiver acessvel, assumido que
a mquina onde est a correr tambm est disponvel e este tipo de testes descartado. Os
hosts verificados podem encontrar-se em um de trs estados possveis:
UP;
DOWN;
UREACHABLE.
Estes estados traduzem as informaes (OK, WARNING, UNKNOWN e CRITICAL) que so
retornadas pelos plugins que so quem realiza este tipo de testes.

Estado da Arte

13

J um service check testa individualmente servios como o HTTP, o SMTP e o DNS, mas
tambm a carga do processador e os processos a correr nas mquinas. Tal como um host
check pode ser feito em intervalos de tempo regulares ou apenas quando solicitado. Um
teste possvel consiste em verificar, para um dado servio, se a porta que ele utiliza se
encontra aberta e se ele se encontra escuta nela. Para verificar se um servio est
realmente a funcionar o Nagios testa servios de forma mais aprofundada. Os servios podem
encontrar-se em um de quatro estados possveis:
UP;
WARNING;
UNKNOWN;
CRITICAL.
O Nagios pode monitorizar os hosts e os servios de forma activa ou passiva. Os chamados
active checks so o mtodo mais comum para fazer a monitorizao, podendo ser iniciados
por um processo do Nagios ou ento executados regularmente. Quando o Nagios necessita de
verificar o estado de um host ou servio executa um plugin indicando a informao que
preciso verificar. Esse plugin verifica o estado operacional do host ou servio e retorna os
resultados para o Nagios, que os processa realizando depois as aces necessrias.
Os passive checks pelo contrrio no so executados pelo Nagios mas sim por
aplicaes/processos externos que submetem os resultados obtidos ao Nagios para serem
processados. Este tipo de verificao til para a monitorizao de servios de natureza
assncrona ou que se encontram localizados atrs de uma firewall no podendo dessa forma
serem verificados activamente. Exemplos de servios deste tipo incluem os SNMP traps e
alertas de segurana.
Possui um sistema de notificao, apresentado na Figura 3.5, podendo-se configurar grupo
de contacto (que contm um ou mais contactos individuais) que deve ser informado para um
determinado host ou servio, horas a que essas notificaes podem e devem ser feitas ou se
simplesmente as notificaes podem ser descartadas. Tem em ateno que um contacto pode
ser membro de mais do que um grupo de contacto pelo que antes de enviar notificaes
remove todas as notificaes duplicadas para um contacto.
Para alm de permitir controlar quando que os host e service checks podem ser
realizados, ou quando as notificaes podem ser enviadas, o Nagios tambm permite
programar quando um host ou servio pode ser desligado para, por exemplo, realizar
operaes de manuteno.

14

Estado da Arte

Figura 3.5 Nagios: Notificaes, em [6]

3.2

Cacti

O Cacti uma ferramenta open source para monitorizao de redes. Para poder ser
utilizado necessita que o sistema tenha instalado RRDTool, MySQL, PHP e um servidor Web
como, por exemplo, o Apache, e pode ser instalada quer em ambientes Unix quer em
ambientes Windows.
Os seus pontos fortes passam pela facilidade de configurao, ter uma interface Web
flexvel, ter um frum pblico com uma comunidade bastante activa, o que permite a
introduo de novas funcionalidades e melhoramentos, partilha de templates entre
utilizadores e a integrao com outras ferramentas como o NTOP.
Tal

como indicado em [9] e [10] o seu funcionamento passa por trs princpios:
Obteno de dados;
Armazenamento de dados;
Apresentao de dados.

Estado da Arte

15

Figura 3.6 Cacti: Princpios de Funcionamento

A obteno de dados feita utilizando uma ferramenta denominada Poller que

executada a partir do programa responsvel pelo agendamento de operaes num sistema
operativo. Em Unix o crontab. Devido complexidade dos sistemas actuais, elas possuem
diversos tipos de equipamentos como routers, switchs, servidores, UPS (Uninterruptible
Power Supply), entre outros. Para obter dados deste conjunto de equipamentos o Cacti usa o
SNMP, podendo monitorizar todos os equipamentos que so capazes de utilizar SNMP. A
configurao desta ferramenta pode ser feita a partir da interface.
Para o armazenamento dos dados o Cacti utiliza o RRDTool. O RRD (Round Robin
Database) um sistema que permite armazenar e apresentar dados como largura de banda da
rede, temperatura de mquinas e carga do servidor de forma rpida e fcil uma vez que
armazena esses dados de uma forma compacta utilizando para o efeito funes de
consolidao como o AVERAGE; MAXIMUM, MINIMUM e LAST.
A partir da interface grfica do Cacti possvel fazer toda a gesto da monitorizao da
rede. Tal como se apresenta na Figura 3.7 pode-se adicionar equipamentos para monitorizar,
tendo a possibilidade de indicar informaes como descrio, hostname (endereo IP ou
hostname que ser resolvido por DNS), template para grficos (listas de grficos para serem
usados neste host) e opes de disponibilidade e conectividade, como definio de Ping
(mtodo, porta e tempo de timeout), opes de SNMP (verso, porta e tempo de timeout) ou
opes relacionadas com segurana.

16

Estado da Arte

Figura 3.7 Cacti: Equipamentos, em [11]

A apresentao de dados tambm baseada no RRDTool e na sua funo de criao de

grficos que combinada com o servidor Web permite que os grficos criados sejam acedidos a
partir de um qualquer browser ou plataforma. Quase tudo no Cacti est relacionado com
grficos e no menu da interface grfica encontra-se o item Graph Management para fazer a
gesto e listagem de todos os grficos disponveis. Criam-se, modificam-se ou apagam-se
grficos para os equipamentos introduzidos. Possu diversas opes desde a escolha de tipos
de grfico, variveis, sendo que a maior parte das opes j se encontram configuradas no
template do grfico. Pode-se, por exemplo, apresentar os grficos hierarquicamente, usando
para o efeito rvores de grficos, tal como apresentado na Figura 3.8.

Estado da Arte

17

Figura 3.8 Cacti: rvore de grficos, em [11]

Permite gesto de utilizadores, tal como apresentado na Figura 3.9, indicando, nome,
nome de utilizador, palavra passe e outros parmetros como as permisses de visualizao de
equipamentos e grficos a que um utilizador pode aceder.

Figura 3.9 Cacti: Gesto Utilizadores, em [11]

Uma grande vantagem do Cacti, que o distingue dos demais a utilizao de templates.
Estes templates permitem facilitar a configurao de recolha de dados, sem que para isso
interesse o equipamento que os ir disponibilizar. O Cacti usa trs tipos de template, para
dados, grficos e para hosts.

18

Estado da Arte

Os templates de dados so usados para definir os parmetros para a obteno dos dados,
desde tipo, mtodos e intervalos de actualizao. Os templates de grficos definem um
esqueleto de um grfico, ou seja, como que os dados recolhidos iro ser visualizados com
parmetros que vo desde tipo de dados a visualizar, formato de imagem, resoluo, escala
entre outros. Um template para host associa os templates de dados e grficos mais
convenientes para um determinado tipo de equipamento, seja ele router, switch ou servidor.
Pode-se utilizar templates j presentes no Cacti, ou ento criar-se templates prprios
com os parmetros que se acharem mais convenientes ou ento exportar templates criados
por outros utilizadores. Isso possvel devido ao facto do Cacti permitir importar e/ou
exportar templates a partir da interface grfica.
Outra funcionalidade existente o PHP Script Server, ferramenta que permite a recolha
de dados a partir de scripts PHP, que pela sua natureza torna o processo de pesquisa e
recolha de dados bem mais rpido e eficiente. Tal como acontece com os templates, tambm
aqui existe a possibilidade de utilizar scripts que j vm instalados (o Cacti j possu dois
scripts para recolha de dados sobre espao em disco e utilizao de processadores) ou ento
scripts prprios que um utilizador cria para recolher a informao que pretende em um
determinado equipamento.

3.3

Opsview

O Opsview Community, [12] uma ferramenta open source para monitorizao de redes,
servidores e aplicaes, distribuda sob a licena GPL verso 2. Fornece uma interface Web
para administrao, configurao e visualizao de sistemas, Figura 3.10.

Figura 3.10 Opsview: Interface Grfica, em [13]

Estado da Arte

19

A particularidade desta ferramenta ela ser baseada e construda a partir de tecnologia e

ferramentas open source j existentes, entre as quais encontram-se:
Perl Linguagem de programao principal do Opsview;
Catalyst Framework para desenvolvimento de aplicaes Web, baseado no padro
de arquitectura de software MVC (Model-view-controller);
MySQL Base de dados;
Apache Servidor Web;
Nagios: Que providencia a base das capacidades de monitorizao do Opsview;
Net-SNMP: Para suporte SNMP;
RRDTool Para grafismo.
O Opsview corre em Linux, tendo suporte para as distribuies CentOS, Debien, Red Hat e
Ubuntu, bem como para o sistema operativo Solaris. Para alm disso suporta tecnologias de
virtualizao como o VMware Player, Server e ESX, Parallels, Xen Hypervisor e KVM
Hypervisor.
Suporta o uso de agentes de monitorizao para a recolha de dados de equipamentos
localizados remotamente. Os mais comuns so o SNMP, o NRPE (Nagios Remote Plugin
Executor) e o NSClient++, usado para plataformas Microsoft Windows, sendo que um qualquer
agente que seja compatvel com o Nagios deve funcionar com o Opsview.
Uma vez que o Nagios encontra-se integrado nesta soluo, o Opsview utiliza a quase
totalidade dos conceitos do Nagios em termos de hosts, services, host checks, service checks,
active checks e passive checks. Os estados de servio (OK, CRITICAL, WARNING E UNKOWN) e
de host (UP, DOWN E UNREACHABLE) tambm so os mesmos. A diferena encontra-se no
conceito de service group. No Nagios um service group uma lista de servios associados a
um host, j no Opsview um service group um conjunto de service checks sem qualquer
associao a um host, pelo que o Opsview no tem nenhum tipo de configurao para um
service group do Nagios.
Tal como o Nagios utiliza plugins para a realizao de active checks, sendo estes os
responsveis por verificar se um equipamento ou sistema se encontra a funcionar ou no,
podendo ser utilizados mltiplas vezes em servios diferentes. Entre os plugins que o Opsview
destaca encontram-se o check_disk para verificao de espao livre em disco e o check_http
que verifica as respostas de um URL.
A partir da interface Web, tal como mostrado na Figura 3.11 e descrito em [13],
possvel um conjunto de aces que passam pela visualizao de hosts e servios, de forma
organizada e hierrquica, resultados de service checks, grficos de desempenho de servios,
visualizao de alertas, configurao de hosts, service checks, associao de service checks
com hosts, adio de host templates, adio de utilizadores e mapa da estrutura da rede, tal
como mostrado na Figura 3.12.

20

Estado da Arte

Figura 3.11 - Opsview: Estado de host e servios, em [13]

Figura 3.12 Opsview: Mapa da rede, em [14]

Estado da Arte

21

O Opsview j vem com service checks pr-definidos e agrupados em templates. A partir

destes pode fazer monitorizao de aplicaes, bases de dados, rede, servios de rede,
sistemas operativos e SNMP. Alguns dos templates encontram-se em [15] destacando-se a
monitorizao de:

Aplicaes
o Alfresco;
o Servidor Web Apache;
o Atlassian;
o Servidor aplicaes Jboss;
o Servios OpenSimulator.

Negcio
o Monitores SLA que fornecem estatsticas sobre disponibilidade.

Servidores de Bases de dados

o MySQL;
o Oracle;
o PostgreSQL.

Rede
o
o

Conectividade de rede
Equipamentos de rede Cisco

Servios de rede
o Servidores DNS;
o Protocolos Email;
o Servidores LDAP.

Sistemas Operativos
o Sistemas Unix e Linux;
o Servidores VMware ESX;
o Servidores Microsoft Windows.

SNMP
o
o
o

Processamento de SNMP traps;

Routers, firewalls e switches Cisco;
MIB-II.

22

3.4

Estado da Arte

OpenNMS

O OpenNMS (Network Management System), [16], uma plataforma open source de

gesto e monitorizao de redes empresariais. Desenvolvida sob o modelo de gesto de redes
FCAPS (Fault, Configuration, Accounting, Performance, Security) distribuda sobre a licena
GPL.
O OpenNMS escrito em Java, para alm de utilizar para base de dados o PostgreSQL e o
RRDTool, mais concretamente o JRobin (porta Java para o RRDTool), para ferramenta grfica
e suporta os sistemas operativos Red Hat, Debian, Fedora, Mandriva, SuSE, Solaris, Mac OS X e
Microsoft Windows.
As suas funcionalidades passam pela determinao de disponibilidade e latncia de
servios, recolha, armazenamento e apresentao de dados recolhidos, gesto de eventos
(como por exemplo SNMP traps), alarmes e notificaes.

Figura 3.13 OpenNMS: Interface Grfica, em [17]

Tal como indicado em [18], o OpenNMS est focalizado nos recursos dos servios da rede
como, acessos a pginas Web e bases de dados, DNS e DHCP (Dynamic Host Configuration
Protocol), apesar de providenciar informao mais tradicional noutras ferramentas de gesto
e monitorizao de redes, como informao sobre switches, routers entre outros.
Utiliza dois meios para recolha de dados. O primeiro atravs dos chamados monitors que
se conectam a um recurso da rede e realizam um teste para verificar se ele responde
correctamente. Se tal no acontecer um evento gerado. O segundo meio atravs da
utilizao dos denominados collectors, que recolhem dados SNMP. Os dados podem ser
recolhidos por SNMP, JMX (Java Management Extensions) e HTTP.

Estado da Arte

23

Para recolher dados o OpenNMS, tal como descrito em [19] primeiro tem de descobrir os
elementos que tem de monitorizar. A esses elementos d-lhe o nome de interface, sendo que
uma interface identificada por um endereo IP e os servios so mapeados em interfaces.
Se mais do que uma interface estiver num mesmo equipamento ento elas so agrupados em
um n. A descoberta faz-se primeiro detectando o endereo IP a monitorizar e depois
descobrindo quais os servios que so suportados por esse endereo IP.
Os eventos gerados so de dois tipos, os gerados internamente pelo OpenNMS e os gerados
externamente por SNMP traps. So caracterizados por parmetros como descrio e
gravidade. Os diferentes nveis de gravidade, tal como apresentado em [20] que um evento
pode tomar so:
Critical: Numerosos equipamentos da rede so afectados pelo evento;
Major: Um equipamento encontra-se em baixo;
Minor: Parte de um equipamento, seja servio ou interface parou de funcionar;
Warning: Evento que pode requerer ateno;
Normal: Apenas informativo, no necessitando de realizao de aces;
Cleared: Indicao que um erro anterior foi corrigido e um servio ou interface foi
restaurado;
Indeterminate: Impossibilidade de associao de evento com um nvel de gravidade.
O OpenNMS tambm possui a funcionalidade de notificao. Caso ocorra um determinado
evento, uma notificao enviada para um utilizador ou grupos de utilizadores ou para a
interface grfica ou por email. A informao contida pela notificao passa por endereo IP,
servio, mensagem de erro entre outras.

Figura 3.14 - OpenNMS: Alertas e Notificaes, em [17]

Tal como nas outras ferramentas apresentadas, pode-se configurar utilizadores ou grupos
de utilizadores com diferentes permisses de acesso a elementos da rede, dados e
notificaes, sendo que uma das particularidades a possibilidade de configurar o OpenNMS
para suportar autenticao LDAP (Lightweight Directory Access Protocol), [21].

24

3.5

Estado da Arte

Zabbix

O Zabbix uma ferramenta open source, distribuda sob os termos da licena GNU GPL
verso 2, para gesto de rede, com o objectivo de monitorizar o estado de vrios servios de
rede, bem como servidores ou outro tipo de hardware. Tal como descrito em [22]
caracterizado como sendo um sistema de monitorizao semi-distribudo com gesto
centralizada. A sua organizao encontra-se dividida em 3 mdulos principais
Base de dados, para armazenamento de dados, podendo ser utilizado MySQL,
PostgreSQL, SQLite ou Oracle;
Servidor, para proceder a monitorizao directa de equipamentos e servios;
Interface Grfica, para interaco com os restantes mdulos baseada em PHP e
JavaScript.

Figura 3.15 Zabbix: Organizao

As suas funcionalidades so:

Suporte para sistemas operativos Linux, AIX, FreeBSD, OpenBSD e Solaris;
Agentes nativos para a maioria das verses de sistema operativo Unix e Microsoft
Windows para monitorizao de estatsticas como carga do processador, utilizao da
rede, espao em disco;
Monitorizao de SNMP (todas as verses), SMTP ou HTTP e equipamentos IPMI
(Intelligent Platform Management Interface);
Capacidade de visualizao grfica dos testes efectuados;
Notificaes;
Utilizao de templates.
A interface grfica permite vrias opes de visualizao que vo desde um simples
grfico at mapas de rede para alm de apresentar um conjunto de informaes que vo
desde estado do Zabbix, estado do sistema, problemas ocorridos e mais um conjunto extenso

Estado da Arte

de informaes sobre
Web. A partir dela,
utilizadores, mtodos
caso de ocorrncia de
email.

25

sistemas operativos, servios, estado de servidores, routers e pginas

tal como nas diversas ferramentas j apresentadas, pode-se gerir
de autenticao, permisses e configurar as notificaes a enviar em
problemas. No caso do Zabbix o mtodo mais comum de notificao o

Figura 3.16 Zabbix: Interface Grfica, em [23]

O Zabbix utiliza o conceito de item, entidade que guarda os dados monitorizados. Sem
items a informao no pode ser obtida. Existem dois tipos de, os chamados passive items,
em que o servidor conecta-se ao agente de cada vez que pretende testar um item, e os active
items, em que pelo contrrio o agente que se conecta ao servidor fazendo download da
lista de items a testar e informando periodicamente o servidor com os novos dados obtidos.
Possu diversos tipos de categorias que vo desde Zabbix agent (entidade a que o servidor se
conecta para recolher dados), simple check, SNMP agent (para recolha de dados SNMP), entre
outros. Host uma entidade que agrupa items, pode ser um switch, servidor, mquina virtual
ou um stio Web, identificado por nome, grupo (importante uma vez que no Zabbix as
permisses s podem ser dadas a grupos de hosts e no a hosts individuais) e endereo IP.
Para testar hosts utiliza o conceito de triggers, definindo os parmetros de teste para
verificar a ocorrncia de problemas. Para o envio de notificaes, tem-se de configurar no
Zabbix aquilo que ele define como actions, que basicamente so o conjunto de aces que o
servidor Zabbix deve tomar em caso de problemas. Define-se a mensagem a enviar, a quem se
envia a mensagem, o tipo de problema ocorrido e tipo de operaes devem ser efectuadas.

26

3.6

Estado da Arte

Zenoss

O Zenoss Core uma aplicao open source de gesto de redes e servidores lanado sobre
a licena GNU GPL verso 2 que fornece uma interface Web para administrao de sistema,
monitorizao de disponibilidade, desempenho e eventos. Possuem uma verso empresarial,
paga, baseada na verso Core, no entanto existe uma comunidade bastante activa do Zenoss
que desenvolve novas funcionalidades, documentao, manuais e fruns de discusso para a
verso gratuita o que permite que o Zenoss esteja sempre a evoluir com novas solues e
servios.
O Zenoss baseado, no s em programao prpria, mas tambm atravs da integrao
de tecnologias open source, tais como:
Python: Languagem de programao;
Zope: Servidor de aplicaes escrito em Python;
Twisted: Framework de rede open source escrita em Python para a criao de
servidores SSH, proxy, HTTP e SMTP;
Net-SNMP: Suporte SNMP para monitorizao de informaes de sistema;
RRDTool: Ferramenta para suporte grfico dos dados;
MySQL: Base de dados.
O Zenoss possui suporte para os sistemas operativos Red Hat, Fedora, Ubuntu, Debian,
SUSE, OpenSUSE, Mac OS X, VMWare, FreeBSD, Solaris e Gentoo.
Tal como indicado em [24] encontra-se dividido em 4 camadas:
User layer: Interface grfica para acesso e gesto do sistema;
Data layer: Dados recolhidos guardados em bases de dados separadas, de acordo com
a sua utilizao
o Dados de desempenho para serem processados e apresentados graficamente;
o Dados de configuraes de equipamentos, grupos e localizao;
o Dados de ocorrncia de eventos;
Process layer: Gesto das comunicaes entre a camada de obteno e a camada de
dados;
Colecction layer: Obteno de dados, atravs de SNMP, SSH e WMI (Windows
Management Instrumentation), de mquinas remotamente localizadas e transmisso
para a camada de dados;
Algumas das suas funcionalidades e capacidades so:
Monitorizao da disponibilidade de equipamentos de rede utilizando SNMP, SSH e
WMI;
Monitorizao de servios de rede como HTTP, POP3, FTP, NNTP, entre outros;
Monitorizao de recursos e desempenho de equipamentos (carga do processador,
utilizao de disco);
Gesto de utilizadores, eventos e falhas;

Estado da Arte

27

Descoberta automtica de recursos e topologia da rede, bem como a alteraes na

configurao da rede;
Sistema de notificao;
Suporte do formato de plugins do Nagios, a que do o nome de Zen Packs.

Tal como em outras ferramentas, a partir da interface grfica, Figura 3.17 e Figura 3.18
so apresentadas informaes de sistema (recursos, lista de equipamentos, servios),
utilizando um sistema semelhante ao do Nagios, por exemplo, utilizando cdigo de cores para
diferenciar os estados de equipamentos e servios (verde se estiver a funcionar
correctamente, amarelo em caso de possibilidade de ocorrncia de erros, vermelho em caso
de falha), apresentao grfica de dados, eventos (deteco de erros com informao sobre
identificao de equipamento, endereo IP, gravidade, tipo de erro ocorrido), topologia da
rede, vista geogrfica (utilizando Google Maps) da rede, informao de utilizadores, bem
como permite a gesto de equipamentos, servios, notificaes (situaes, mtodo, tipo de
mensagem a enviar) e utilizadores (informao de autenticao, permisses, associao a
grupos).

Figura 3.17 Zenoss: Interface Grfica, em [25]

28

Estado da Arte

Figura 3.18 Zenoss: Viso Geral, em [26]

Para a adio de novas funcionalidades, utiliza os chamados ZenPacks que providenciam

uma arquitectura de plugins, tal como a utilizada pelo Nagios, para permitir aos membros da
comunidade aumentar e melhorar as funcionalidades e capacidades do Zenoss, atravs da
introduo de novas classes de eventos ou servios, comandos, grficos, entre outros. Podem
ser criados a partir da interface grfica, ou atravs do desenvolvimento de scripts ou daemons
para integrao com o Zenoss. A empresa que desenvolve o Zenoss pode criar ZenPacks
exclusivos para incentivar a compra da verso paga, os chamados Commercial ZenPacks, no
entanto os utilizadores podem criar os seus prprios ZenPacks, os chamados Core ZenPacks, e
disponibiliza-los para todos os utilizadores, o que permite a evoluo tambm da verso Core.

3.7

Cisco IOS IP Service Level Agreements

Tal como indicado em [27] a Cisco tambm apresenta uma soluo para monitorizao e
gesto de SLA, a Cisco IOS IP Service Level Agreement, uma funcionalidade para
monitorizao de desempenho de rede em equipamentos Cisco. Apesar de muitos dos
protocolos utilizados pela Cisco serem standards IETF (Internet Engineering Task Force), a
soluo no um standard IETF. Permite aos utilizadores verificar garantias de servios,
aumentar a fiabilidade da rede ao validar o desempenho da rede e identificar de forma proactiva os problemas da rede. Para tal utiliza monitorizao activa para gerar trfego de forma
contnua, de forma a poder permitir a determinao da performance e sade da rede,

Estado da Arte

29

calculando mtricas de desempenho como jitter, latncia, tempos de resposta de rede e

servidores e perdas de pacotes.
Tal como indicado em [28] e [29] procura portanto permitir aos utilizadores
Implementar novas aplicaes e servios de forma mais rpida e eficiente;
Observao de desempenho e identificao de problemas para permitir um aumento
da fiabilidade da rede;
Verificao e monitorizao de QoS e nveis de servio diferenciados.
Aproveitando as caractersticas oferecidas pela Cisco IOS IP SLAs, tais como:
Estar embebido no software Cisco IOS, no necessitando de aplicaes externas nem
de custos adicionais;
Monitorizao em tempo real de estado e desempenho da rede;
Capacidade de verificao e medida de parmetros necessrios para SLAs;
Notificaes com SNMP trap em caso de deteco de problemas como perda de
pacotes, perda de conectividade e erro de verificao de dados (dados nos pacote de
origem e resposta serem diferentes);
Controlo e obteno de dados usando SNMP ou Cisco IOS Software CLI (Command Line
Interface);
Simulao de codecs e medio de qualidade VoIP;
Monitorizao de rede MPLS;
Integrado em ferramentas de gesto de outras entidades, como a Agilent, Concord
Communication ou HP Openview;
Possibilidade de configurao do protocolo de controlo com autenticao MD5.
Todos os equipamentos Cisco que correm Cisco IOS Software suportam a Cisco IOS IP SLAs
com a excepo da Cisco Catalyst 4500 Series Switch.
Resumindo, a utilizao desta soluo est orientada para:
Visualizao do desempenho de servios de VoIP, vdeo, MPLS (Multiprotocol Label
Switching) e redes VPN;
Monitorizao de SLAs;
Monitorizao de desempenho e disponibilidade da rede;
Avaliao do estado dos servios da rede;
Monitorizao do desempenho de aplicaes;
Resoluo de problemas operacionais da rede.
As principais mtricas a testar passam pelo atraso, jitter, perda de pacotes sequenciao
de pacotes, conectividade, caminho (por salto), tempo de download de servidor e stio Web e
qualidade de voz, de forma a garantir monitorizao de desempenho VoIP, de disponibilidade
e desempenho de aplicaes e equipamentos, de tempo de resposta de servidores, de
desempenho de servidor DNS, de desempenho de servidor DHCP, FTP e desempenho de stios
Web

30

Estado da Arte

Algumas das principais operaes realizadas so:

VoIP: Medio de RTT (Round-trip delay time), atraso, jitter e perda de pacotes,
simulao de codecs G.711 e G729;
DNS: Medio de tempo de DNS Lookup;
DHCP: Medio de RTT para obteno de um endereo IP;
FTP: Medio de RTT para transferncia de um ficheiro;
HTTP: Medio de RTT para abrir uma pgina Web.

Figura 3.19 Cisco IOS IP SLA funes, mtricas e operaes [29]

Estado da Arte

3.8

31

Concluses

Analisando as ferramentas apresentadas pode-se afirmar que todas elas no divergem

muito na forma como gerem e monitorizam servios e equipamentos. As principais diferenas
residem no tipo de base de dados a utilizar, se utilizam elementos externos ao programa para
proceder monitorizao (como os plugins do Nagios), se utilizam ferramentas j existentes
(como no caso do Opsview que utiliza Nagios) ou uma estrutura criada de raiz. Outro ponto de
divergncia a forma de apresentar e o prprio contedo das interfaces grficas de gesto. A
partir disto j se pode neste momento apresentar uma possvel soluo, sem grandes
especificaes, para o trabalho de Dissertao a realizar no prximo semestre, tendo em
ateno que ao longo do desenvolvimento do trabalho alteraes podem e devem ocorrer. Tal
como indicado nos objectivos do trabalho a soluo passa pela integrao de ferramentas
open source utilizando um interface Web para a monitorizao de servios e gesto de
sistemas.
Principal tecnologia open source integrada:
Apache Servidor Web;
MySQL Base de Dados;
Net-SNMP Suporte SNMP;
PHP Linguagem de programao em que se basear a interface Web;
Python Linguagem de programao principal;
RRDTool Suporte grfico dos dados;
Ubuntu 10.04 Sistema Operativo.
A estrutura da soluo passa por:

Interface Web
Funo de acesso e gesto de sistema
o Configurao de equipamentos e servios;
o Visualizao organizada de equipamentos e servios:
Simples grfico de desempenho;
rvore de grficos de desempenho;
Mapa da rede.
o Visualizao grfica de dados de estado e desempenho de equipamentos e
servios;
o Configurao e gesto de utilizadores:
Criao;
Autenticao;
Grupos;
Permisses.
o Configurao e visualizao de alertas;
o Configurao de notificaes:
Email.

32

Estado da Arte

Base de Dados
Estruturao da base de dados tendo em ateno as diferentes situaes e utilizaes
dos dados:
o Dados de sistema e servios recolhidos para apresentao;
o Dados de configuraes de sistema (equipamentos, utilizadores, servios);
o Dados de eventos, alertas e notificaes.

Servidor:
o A partir dele proceder-se monitorizao de equipamentos e servios.

As mtricas e servios a monitorizar sero:

VoIP:
o Medio de RTT;
o Atraso;
o Jitter;
o Perda de Pacotes;
o Qualidade de voz.
Servio DNS:
o Tempo de DNS lookup.
Servio DHCP:
o Medio de RTT para obteno de endereo IP.
Servio Email;
Servio FTP:
o Medio de RTT para transferncia de um ficheiro.
Servio HTTP:
o Medio de RTT para abertura de uma pgina Web.
Disponibilidade de equipamentos:
o Teste de conectividade (ping).
Trfego de dados:
o Jitter;
o Perda de pacotes;
o Latncia;
o QoS.

Captulo 4
Plano de Trabalho
Neste captulo apresentado o plano de trabalho a desenvolver, bem como a
calendarizao das diferentes fases do trabalho, tendo em ateno que ao longo do projecto
podero ocorrer alteraes.

4.1

Plano de tarefas

O plano de tarefas ficou definido da seguinte forma

Estudo, anlise e compreenso do problema;

Estudo do estado da arte relativamente a monitorizao de SLAs IP;
Identificao do conjunto de mtricas a monitorizar;
Especificao de uma soluo para a monitorizao de SLAs IP;
Especificao de cenrios de teste;
Desenvolvimento da soluo;
Teste e validao da soluo desenvolvida;
Escrita da Dissertao.

33

34

4.2

Plano de Trabalho

Calendarizao

Ao longo do trabalho desenvolvido para a Preparao da Dissertao prev-se que os 3

primeiros pontos do plano de tarefas fiquem concludos at que entrega do Relatrio Final,
a 5 de Julho de 2010. A calendarizao do restante trabalho apresentada na Tabela 4.1

Tabela 4.1 Calendarizao do Projecto

Tarefas
Especificao da soluo
Especificao de cenrios de teste
Desenvolvimento da soluo
Teste e validao da soluo desenvolvida
Escrita da dissertao

Setembro

Outubro

Novembro Dezembro

Janeiro

Referncias
1. Neves, Joo. Planeamento: Anlise de Requisitos. [Online] [Citao: 21 de Abril de
2010.] http://www.inescporto.pt/~jneves/feup/2009-2010/pgre/requirements.pdf.
2. Service Level Agreements on IP Networks. Verma, Dinesh C. 9, s.l. : Proceedings of the
IEEE, 2004, Vol. 92, pp. 1382-1388. ISSN: 0018-9219.
3. Bouman, Jacques, Trienekens, Jos e van der Zwan, Mark. Specification Of Service
Level Agreements, Clarifying On The Basis Of Practical Research. Washington DC : IEEE
Computer Society, 1999. ISBN: 0-7695-0328-4.
4. Barth, Wolfgang. Nagios: System and Network Monitoring. 1st. 2006. pp. 16-18. ISBN 159327-070-4.
5. Contributors, Nagios Core Development Team and Community. Nagios Core Version
3.x

Documentation.

[Online]

[Citao:

26

de

Junho

de

2010.]

http://nagios.sourceforge.net/docs/nagios-3.pdf.
6.

Nagios

Screenshots.

[Online]

[Citao:

26

de

Junho

de

2010.]

http://www.nagios.org/about/screenshots.
7. [Online] [Citao: 23 de Abril de 2010.] http://exchange.nagios.org/.
8. [Online] [Citao: 23 de Abril de 2010.] http://www.nagios.org/download/plugins.
9. Berry, Ian, et al. The Cacti Manual. [Online] [Citao: 26 de Junho de 2010.]
http://www.cacti.net/downloads/docs/html/.
10. Kundu, Dinangkur e Lavlu, S. M. Ibrahim. Cacti 0.8 Network Monitoring. s.l. : Packt
Publishing, 2009. ISBN 978-1-847195-96-8.

35

36

Referncias

11.

Cacti

Screenshots.

[Online]

[Citao:

26

de

Junho

de

2010.]

http://www.cacti.net/screenshots.php.
12. Opsview Community Edition 3.7. [Online] [Citao: 27 de Junho de 2010.]
http://docs.opsview.com/doku.php?id=opsview-community.
13. The Opsview Quick Start Guide. [Online] [Citao: 27 de Junho de 2010.]
http://docs.opsview.com/doku.php?id=opsview-community:quickstart.
14. Opsview Monitoring Web User Interface. [Online] [Citao: 27 de Junho de 2010.]
http://docs.opsview.com/doku.php?id=opsview-community:monitoringui.
15.

Host

Template.

[Online]

[Citao:

27

de

Junho

de

2010.]

http://docs.opsview.com/doku.php?id=opsview-community:initialconfiguration:templates.
16.

Main

Page.

[Online]

[Citao:

27

de

Junho

de

2010.]

http://www.opennms.org/wiki/Main_Page.
17.

OpenNMS

Screenshots.

[Online]

[Citao:

27

de

Junho

de

2010.]

http://sourceforge.net/project/screenshots.php?group_id=4141.
18.

Polling

Configuration

How-To. [Online]

[Citao:

27

de

Junho

de

2010.]

http://www.opennms.org/wiki/Polling_Configuration_How-To.
19.

Discovery.

[Online]

[Citao:

27

de

Junho

de

2010.]

Junho

de

2010.]

http://www.opennms.org/wiki/Discovery_Configuration_How-To.
20.

Severity.

[Online]

[Citao:

27

de

http://www.opennms.org/wiki/Severity.
21.

Spring

Security

and

LDAP.

[Online]

[Citao:

27

de

Junho

de

2010.]

http://www.opennms.org/wiki/Spring_Security_and_LDAP.
22. Olups, Rihards. Zabbix 1.8 Network Monitoring. s.l. : Packt Publishing, 2010. ISBN
978-1-847197-68-9.
23.

Zabbix

Screenshots.

[Online]

[Citao:

29

de

Junho

de

2010.]

http://www.zabbix.com/screenshots.php.
24.

Zenoss

Administration

2.5.2.

[Online]

[Citao:

30

de

Junho

de

2010.]

http://community.zenoss.org/community/documentation/official_documentation/zenossguide/2.5.2.

Referncias

25.

Zenoss

37

Screenshots.

[Online]

[Citao:

30

de

Junho

de

2010.]

http://ostatic.com/zenoss-core/screenshot/1.
26.

Zenoss

Core

Screenshots.

[Online]

[Citao:

30

de

Junho

de

2010.]

http://ostatic.com/zenoss-core/screenshot/1.
27. Cisco IOS IP Service Level Agreements Q&A. [Online] [Citao: 28 de Junho de 2010.]
http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_qas0900aecd80
17bd5a.html.
28. Cisco IOS IP Service Level Agreement Data Sheet. [Online] [Citao: 28 de Junho de
2010.]
http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09
00aecd8017531d.html.
29. Cisco IOS IP Service Level Agreements User Guide. [Online] [Citao: 28 de Junho de
2010.]
http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09
186a00802d5efe.html.