Ambiente de Monitoração de Sla para Redes

UNIVERSIDADE FEDERAL DE SANTA CATARINA
JOS CARLOS GONTARCZYK FARIA

AMBIENTE DE MONITORAO DE SLA PARA REDES

FLORIANPOLIS (SC)
2004

JOS CARLOS GONTARCZYK FARIA


Trabalho de Concluso de Curso apresenta-
do ao Curso de Cincia da Computao,
como requisito obteno do ttulo de Ba-
charel em Cincia da Computao, da Uni-
versidade Federal de Santa Catarina.

ORIENTADOR: EDISON TADEU LOPES MELO
COORIENTADOR: CARLOS BECKER WESTPHALL
BANCA: GUILHERME ELISEU RHODEN

FLORIANPOLIS (SC)
2004


Trabalho de Concluso de Curso apresenta-
do ao Curso de Cincia da Computao,
como requisito obteno do ttulo de Ba-
charel em Cincia da Computao, da Uni-
versidade Federal de Santa Catarina.

Florianpolis (SC), 13 de fevereiro de 2004.

Edison Tadeu Lopes Melo, Mestre _____________________________________

Prof. Carlos Becker Westphall, Doutor _____________________________________
Universidade Federal de Santa Catarina

Guilherme Eliseu Rhoden, Mestre _____________________________________

FLORIANPOLIS (SC)
2004

In theory, there is no difference between theory
and practice. But in practice, there is.
--Jan L. A. van de Snepscheut

Para meu pai, Filinto, minha me, Janette, mi-
nha irm Carolina, e para os demais parentes e
amigos.
Agradecimentos

Em especial a Edison Melo, pelo apoio intelectual e de recursos no desenvolvimento
deste trabalho durando o estgio realizado no NPD/UFSC.
Ao Mestre Guilherme Rhoden por compor a banca.
Aos professores de UFSC que auxiliaram de forma direta ou indireta na criao deste
trabalho.
Aos amigos do NPD, em especial: Augusto, Fernando e Rafael.

RESUMO

A cada dia a utilizao da Internet tem aumentado no nmero de ser-
vios oferecidos e de solues crticas que dependem de seu correto
funcionamento. Para tanto deve existir um mecanismo que permita
que um cliente de servios de rede possa garantir e aferir a qualidade
de servio recebida de um provedor. Desempenhando este papel e-
xiste o acordo de nvel de servio (Service Level Agreement SLA),
que esse define atravs de um contrato qual o nvel aceitvel espe-
rado para o cliente de um servio consumido. O presente trabalho
conceitualiza o assunto de gerenciamento de redes empregando SLA
e detalha o desenvolvimento de um ambiente de gerenciamento de
nvel de servios (Service Level Management SLM). Esse tem co-
mo objetivo permitir a definio do acordo e a criao de relatrios
relevantes ao acordo firmado, o qual so alimentados por dados co-
lhidos por um autmato especialmente desenvolvido para realizar a
tarefa de coleta de dados em redes utilizando o protocolo SNMP.

Palavras-Chaves:
Gerenciamento, redes, SLA, SLM, SNMP, autmato.

ABSTRACT

Each day the use of the Internet has grown in the number of offered
services and the critical solutions that depend of its correct operation.
For in such a way a mechanism must exist that allows a customer of
a network service can guarantee and survey the quality of service re-
ceived from a provider. Fulfilling this role the Service Level Agree-
ment (SLA) exists, which defines through a contract the level of ser-
vice expected by a customer from a consumed service. The present
work conceptualizes the matter of network management employing
SLA and details the development of a Service Level Management
(SLM) environment. This has as objective to allow the definition of
an agreement and the creation of meaningful reports to the agree-
ment contracted, which are supplied by the harvested data from an
automaton especially developed to carry through the task of collec-
tion of data in networks using the SNMP protocol.

KEY WORDS:
Management, networks, SLA, SLM, SNMP, automaton.

8
SUMRIO

LISTA DE FIGURAS ......................................................................................................................................... 10
LISTA DE TABELAS......................................................................................................................................... 11
LISTA DE SIGLAS............................................................................................................................................. 12

1. INTRODUO.......................................................................................................................................... 14
1.1 PROPOSTA DO TRABALHO............................................................................................................ 14
1.2 OBJETIVO............................................................................................................................................ 15
1.3 JUSTIFICATIVA.................................................................................................................................. 15
1.4 REAS DE CONHECIMENTO.......................................................................................................... 16
1.5 ORGANIZAO DO TRABALHO................................................................................................... 16
2. GERENCIAMENTO DE REDES............................................................................................................ 17
2.1 MODELO OSI PARA GERENCIAMENTO..................................................................................... 17
2.2 GERENCIAMENTO NA INTERNET E SNMP................................................................................ 18
2.3 CONSIDERAES FINAIS ............................................................................................................... 23
3. SLA SERVICE LEVEL AGREEMENT .............................................................................................. 24
3.1 INTRODUO..................................................................................................................................... 24
3.2 MOTIVAO....................................................................................................................................... 24
3.3 SLM........................................................................................................................................................ 26
3.4 INFORMAES CONTIDAS EM UM SLA..................................................................................... 27
3.5 RELATRIOS...................................................................................................................................... 29
4. TECNOLOGIAS UTILIZADAS.............................................................................................................. 31
4.1 MYSQL.................................................................................................................................................. 31
4.2 JAVA...................................................................................................................................................... 32
4.3 HTML E XHTML................................................................................................................................. 33
4.4 PHP......................................................................................................................................................... 35
5. AMBIENTE DE MONITORAO SLA................................................................................................ 37
5.1 MOTIVAO....................................................................................................................................... 37
5.2 OBJETIVO............................................................................................................................................ 38
5.3 PLANEJAMENTO............................................................................................................................... 38
5.4 INTERFACE WEB DA FERRAMENTA........................................................................................... 64
6. CONCLUSO............................................................................................................................................ 73
6.1 TRABALHOS FUTUROS.................................................................................................................... 73
7. REFERENCIAS BIBLIOGRFICAS..................................................................................................... 75

9
APNDICE.......................................................................................................................................................... 78
7.1 APNDICE A CDIGO FONTE DO AUTMATO..................................................................... 78
7.2 APNDICE B CDIGO FONTE DA INTERFACE WEB............................................................ 79
7.3 APNDICE C ESTRUTURA DO BANCO DE DADOS................................................................ 80

Lista de Figuras
Figura 1 Camadas no modelo OSI e da Internet respectivamente......................................... 18
Figura 2 Comparao das camadas ....................................................................................... 20
Figura 3 Composio bsica de um agente ........................................................................... 21
Figura 4 rvore OID do SNMP ............................................................................................ 21
Figura 5 PDUs do SNMP ...................................................................................................... 23
Figura 6 Importncia do SLA nos provedores de servio de rede ........................................ 25
Figura 7 Porcentagem de interesse para o desenvolvimento de SLAs .................................. 26
Figura 8 Exemplos de grficos do JpGraph........................................................................... 36
Figura 9 Balano do mercado de SLM.................................................................................. 37
Figura 10 Diagrama de Casos de Uso Administrador ........................................................ 54
Figura 11 Diagrama de Casos de Uso sobre dispositivos gerenciados.................................. 54
Figura 12 Digrama de Casos de Uso sobre o Cliente............................................................ 55
Figura 13 Diagrama de Casos de Uso sobre o Autmato...................................................... 55
Figura 14 Diagrama do modelo conceitual............................................................................ 57
Figura 15 Modelo do banco com os gerenciveis, manuteno e dados gerados ................. 58
Figura 16 Modelo do banco com os acordos......................................................................... 59
Figura 17 Diagrama de sequncia bsico do autmato ......................................................... 61
Figura 18 Diagrama de sequncia do mtodo do padro Observer....................................... 62
Figura 19 Diagrama de seqncia do DeviceFactory............................................................ 63
Figura 20 Tela inicial do ambiente de monitorao .............................................................. 64
Figura 21 Pgina inicial carregada sem estilo ....................................................................... 65
Figura 22 Primeiro passo do assistente de adio de interfaces............................................ 66
Figura 23 Barra de progresso do processo de captura de interfaces...................................... 66
Figura 24 Configurao de objetos em um acordo................................................................ 67
Figura 25 Lista de manutenes cadastradas......................................................................... 68
Figura 26 Navegador de datas para o relatrio...................................................................... 68
Figura 27 Grfico de latncia sem recursos........................................................................... 70
Figura 28 Grfico com recurso de manuteno e de limite de acordo .................................. 70
Figura 29 Grfico de erros em interface................................................................................ 71
Figura 30 Relatrio de disponibilidade de uma interface...................................................... 72

11
Lista de Tabelas
Tabela 1 Ferramentas disponveis e suas caractersticas....................................................... 15
Tabela 2 Padres bsicos para o gerenciamento na Internet ................................................. 19
Tabela 3 Componentes mnimos num SLA proposto por Muller (1999).............................. 28
Tabela 4 Ordenamento dos casos de uso............................................................................... 56

12
Lista de Siglas

ASN.1 Abstract Syntax Notation 1
CSS Cascading Style Sheets
CSV Comma Separated Values
CMIP Common Management Information Protocol
CMOT CMIP Over TCP-IP
FCAPS Fault management, Configuration, Accounting, Performance management,
Security management
GNU - GNU's Not Unix
GPL GNU General Public License
HTML Hyper Text Markup Language
IETF Internet Engineering Task Force
IP Internet Protocol
ISO International Organization for Standardization
ITU International Telecommunication Union
LAN Local Area Network
OID Object Identifier
OSI Open Systems Interconnection
PDU Protocol Data Unit
PHP PHP Hypertext Preprocessor
RDBMS - Relational Database Management Systems
SLA Service Level Agreement
SLM Service Level Management
SMI Structure of Management Information
13
SNMP Simple Network Management Protocol
SQL Structured Query Language
TCP Transmission Control Protocol
UDP User Datagram Protocol
VoIP Voice Over IP
W3C World Wide Web Consortium
WAN Wide Area Network
XHTML eXtensible Hypertext Markup Language

1. INTRODUO

Grandes companhias de telecomunicao visam atender seus usurios com um elevado
nvel de qualidade, para tanto existe a necessidade de um Gerenciamento de Nveis de Servio
(SLM Service Level Management) que so ditados por Acordos de Nvel de Servios (SLA
Service Level Agreement). Estes acordos estabelecem um compromisso do prestador de ser-
vios em entregar aos seus usurios um servio de qualidade estabelecida no contrato firmado
com o cliente ao mesmo tempo em que estabelece as obrigaes do cliente para que estes n-
veis de servio possam ser atingidos.
Para Sturm (2001, p. XI) os prestadores de servio no podem mais se concentrar em
apenas manter cada componente como rede e banco de dados em funcionamento, devem ago-
ra ter uma abordagem de gerenciamento centralizada no cliente. Isso se traduz na forma de
interpretar os dados de monitorao e como o cliente ir avaliar os dados no seu ponto de vis-
ta.
Neste trabalho apresentamos o tema Acordos de Nvel de Servios com suas defini-
es e utilizaes prticas, que serviro de base para a criao do ambiente de monitorao.
Como o enfoque do ambiente ser direcionado a rea de redes de computadores, toda a abor-
dagem de SLA ser focada nesta rea.
1.1 Proposta do Trabalho
Este trabalho tem como principal propsito criar uma ferramenta de medio baseada
em SLA, para que o administrador tenha a habilidade de atravs de um cadastro de objetos
gerenciveis, estabelecer acordos com as diferentes mtricas e gerar relatrios dos acordos
estabelecidos. Para tanto a ferramenta dever ser baseada na WEB, e possuir um autmato
que ir coletar todos os dados referentes aos objetos cadastrados, e este dever coletar dados
da forma mais rpida e segura possvel.
15

1.2 Objetivo
Objetivo Geral

Desenvolvimento de um ambiente para monitorao de SLA para redes.
Objetivos Especficos

Estabelecimento de mtricas para o gerenciamento SLA para redes;
Estabelecimento de nveis padres para as mtricas definidas;
Monitoramento tolerante a falhas dos objetos a serem gerenciados;
Criar um mecanismo para expanso de novas mtricas e novos objetos geren-
civeis.

1.3 Justificativa
No estudo de ferramentas disponveis para o gerenciamento de redes, se observa que a
grande maioria apenas coleta os dados e procura mostrar ao usurio de uma forma seleciona-
da, no h um controle de quais dados so esperados, e de criar relatrios especficos para os
acordos de nvel de servios. Para ilustrar esse fato, foi feito um estudo sobre algumas das
ferramentas disponveis que fazem monitoramento de rede. Na Tabela 1 so apontadas as
principais caractersticas de algumas das mais populares ferramentas de monitorao, e a fer-
ramenta proposta neste trabalho.
Tabela 1 Ferramentas disponveis e suas caractersticas
Ferramenta
Proposta
Whats
Up
Nagios NMIS
Ferramenta Proprietria No Sim No No
Linguagem de Progra-
mao
JAVA
PHP
C C
PERL
PERL
Base de Dados MySQL Prpria Texto Plano
(base opcional)
RRDTool
CSV
Separao da Coleta da
Interface
Sim No No No
Controle SNMP Sim Sim Sim Sim
16
Utiliza-se da RTT MIB Sim No No No
Interface WEB Sim Sim Sim Sim
Incremento de mtricas Via cdigo No Via plug-in Via Cdigo
Relatrios divididos em
perodos
Sim No Sim Sim
Relatrios baseados em
SLA
Sim No No No
Sistema Operacional Windows
Linux
Windows Linux Linux

1.4 reas de Conhecimento
Gerncia de Redes;
Acordos de Nvel de Servios e suas mtricas;
Programao Paralela;
Programao WEB.

1.5 Organizao do Trabalho
Este trabalho est dividido em captulos, no qual iremos abordar os seguintes assuntos:
Captulo 1: Faz uma apresentao do trabalho, colocando a proposta de traba-
lho e a justificativa para este;
Captulo 2: Conceitua o leitor no assunto de gerncia de redes, e em aspectos
gerais de redes;
Captulo 3: Faz uma descrio mais completa de SLA com suas caractersti-
cas, necessidades e pesquisas relacionadas ao tema;
Captulo 4: Apresenta sucintamente as tecnologias de implementao que se-
ro utilizadas;
Captulo 5: uma apresentao da ferramenta que foi criada para esse traba-
lho;
Concluso: Busca mostrar os resultados gerados por este trabalho;
Referncias: Apresenta as referncias que foram utilizadas na realizao deste
trabalho;
Apndice: Cdigo fonte utilizado para a ferramenta apresentada neste trabalho.
2. Gerenciamento de Redes
Atualmente existe um nmero exponencial de usurios que utilizam redes TCP/IP e
um contnuo crescimento de servios que necessitam de qualidade, como videoconferncia e
voz sobre IP (VoIP). Adicionalmente existem muitas empresas que possuem como principal
ramo de negcios servios de rede, fazendo com que seja imprescindvel a existncia um ge-
renciamento que consiga controlar este ambiente crtico. Para Carvalho (1997, p. 508) um
sistema de gerenciamento serve para coordenar, controlar e monitorar os componentes de rede
de forma integrada. Neste captulo buscamos apresentar o tema de gerenciamento de redes
juntamente com padres definidos para esta tarefa.
2.1 Modelo OSI para Gerenciamento
A busca de integrar objetos gerenciveis das redes heterognias que estavam sendo
implementadas, fez com que ISO (International Organization for Standardization) apresen-
tasse em 1989 o modelo de gerenciamento de redes que utilizava seu modelo de referncia
OSI (RM-OSI). Em seu modelo de gerenciamento a ISO divide as atividades de gerenciamen-
to nas seguintes reas funcionais, segundo Carvalho (1997, p. 514), so:
Gerenciamento de Falhas: tem como funo buscar e corrigir falhas do ambi-
ente OSI. Tem como funes investigar e identificar falhas, e realizar testes pa-
ra diagnstico e correo de falhas.
Gerenciamento de Configurao: faz o controle do ambiente de comunica-
o, fazendo a monitorao de mudanas e alterando as configuraes de re-
cursos fsicos e lgicos da rede.
Gerenciamento de Desempenho: faz a medio e monitoramento para avaliar
e relatar os nveis de desempenho atual da rede. Informaes que sero utiliza-
das para o planejamento e controle de qualidade dos servios de rede.
Gerenciamento de Segurana: tem como preocupao a proteo de seus ob-
jetos gerenciveis. Inclui funes que tem como objetivo assegurar a poltica
de segurana definida para a rede.
18
Gerenciamento de Contabilizao: possui funes para determinar o custo
relativo associado utilizao dos recursos de rede, se utilizando de funes
que fazem determinao de quais e quanto dos recursos esto sendo utiliza-
dos.
Estas atividades tambm so conhecidas por Strum (2001) como abordagem FCAPS
(Fault management, Configuration, Accounting, Performance management, Security mana-
gement), que define as mesmas tarefas no gerenciamento de redes do modelo ISO, mas que
neste caso serviu como um ponto de partida para esta abordagem. Como protocolo de geren-
ciamento de redes, a ISO possui o CMIP (Common Management Information service Proto-
col), que mais especificadamente realiza o processo de transporte de informao de gerncia
de redes entre agentes.
Devido ao fato que o gerenciamento de redes OSI est altamente relacionado com di-
versos servios da camada de aplicao, apresentao e sesso (Black, 1994, p. 59;72) e na
Internet estas duas ltimas camadas no so implementadas, o gerenciamento OSI no apli-
cvel para a mesma. Esta diferena de camadas foi proposta para que a arquitetura se tornasse
mais simples e com menos carga de processamento e de acesso memria se comparada com
a pilha de protocolo OSI, como ilustra a Figura 1.

Figura 1 Camadas no modelo OSI e da Internet respectivamente
Fonte: Black (1994, p. 66;78)
2.2 Gerenciamento na Internet e SNMP
O gerenciamento de redes baseado na Internet estabelecido por padres que so des-
critos em RFCs (Request For Comments). Na Tabela 2 esto listados os RFCs que fazem par-
Aplicao
Apresentao
Sesso
Transporte
Rede
Enlace
Fsica
Aplicao

Transporte
Rede
Enlace
Fsica
19
te de documentos ligados ao gerenciamento na Internet, entre os destaques est a RFC 1213
que define a Internet Management Information Base (IMIB), e a RFC 1157 que descreve o
Simple Network Management Protocol (SNMP), um protocolo de gerenciamento de redes
mais simples que o criado pelo CMOT (CMIP Over TCP-IP) definido um ano antes pela RFC
1095.
Tabela 2 Padres bsicos para o gerenciamento na Internet
Fonte: Black (1994, p. 57)
# RFC Data Ttulo
1052 Abril 1988 IAB Recommendations for the Development of the
Internet Network Management Standards
1155 Maio 1990 Structure and Identification of the Management Infor-
mation for TCP/IP-based Internets
1213 Maro 1991 Management Information Base for Network Manage-
ment of TCP/IP-based Internets: MIB II
1157 Maio 1990 A Simple Network Management Protocol (SNMP)

Outros
1095 Abril 1989 The Common Management Information Services Pro-
tocol over TCP/IP (CMOT)
1085 Dezembro 1988 ISO Presentation Services on top of TCP/IP-based
Internets
1212 Mao 1991 Concise MIB Definitions

No gerenciamento de redes na Internet possumos dois protocolos distintos para ajudar
na coleta e notificao de eventos nos agentes, o CMOT e o SNMP. O protocolo CMOT foi
projetado pela IETF (Internet Engineering Task Force), e baseado nos padres de gerenci-
amento de redes ISO e pode ser utilizado tanto com um protocolo orientados a conexo (TCP
Transmission Control Protocol) como com um no orientado a conexo (UDP User Da-
tagram Protocol). No entanto este protocolo, para Black (1994, p. 295), no tem sido utiliza-
do pela indstria e o que acontece que apenas parte dele utilizado. Entretanto o protocolo
SNMP se tornou um padro na indstria de gerenciamento de rede, isto se deve a sua podero-
20
sa simplicidade do protocolo. A Figura 2 ilustra esta simplicidade, e apresenta a relao do
CMOT com o gerenciamento de redes da ISO, e a grande simplicidade do SNMP comparado
aos dois outros.

Figura 2 Comparao das camadas
Fonte: Adaptao de Black (1994, p. 295)
Um dos mais importantes partes no gerenciamento de redes que implementado nos
softwares relacionados a MIB (Management Information Base) que est includa em agentes
remotos (Black, 1994, p. 120) (Stallings, 1999, p. 11). Esta MIB contm informaes de uso
para o gerenciamento de redes, e inclui informaes que refletem as configuraes e compor-
tamento do objeto gerenciado, e inclui parmetros que podero ser utilizados para controlar o
comportamento deste objeto. A MIB est definida na SMI (Structure of Management Infor-
mation), e esta tem como funo estabelecer uma arquitetura geral de gerenciamento de redes.
Gerenciamento de
Falhas
OSI
CMIP
ROSE
Camada de Apresenta-
o
Camada de Sesso
Camada de Transporte
Camada de Rede
Camadas Inferiores
CMISE
X.219
X.216
X.215
X. 214
X.213, X.223
Gerenciamento de
Falhas
CMOT
CMIP
ROSE
Camada de Apresenta-
o Leve (LPP)
TCP ou UDP
IP
Camadas Inferiores
CMISE
X.219
X.216
Aplicaes de Gerenci-
amento de Rede
SNMP
SNMP
TCP ou UDP
IP
Camadas Inferiores
21

Figura 3 Composio bsica de um agente
Fonte: Adaptado de Stallings, 1999, p. 13
Para identificar objetos em uma MIB SNMP, utilizado um esquema de notao
ASN.1 (Abstract Syntax Notation 1) (Perkins, 1997, p. 20). Este esquema de identificao
chamado de object identifier (ou OID) e a sua identificao de itens so determinadas por
valores OID. Estes valores so ordenados por uma seqncia positiva de inteiros, escritos da
esquerda para direita, contendo no mnimo dois elementos (Perkins, 1997, p. 21). Para organi-
zar os valores de OID utilizado um hierarquia semelhante a de sistema de arquivos, e esta
conhecida como rvore de OID, e mantida com os suas definies de topo pela ISO e a ITU
(International Telecommunication Union). Na Figura 4 apresenta-se a rvore bsica junta-
mente com as OID definidas pela IETF.

Figura 4 rvore OID do SNMP
Fonte: Adaptada de Perkins (1997, p. 24)

snmpv2(6)
enterprises(1)
experimental(1)
internet(1) dod (6)
ccitt(0)
raiz
iso(1)
join-isso-ccitt (2)
org(3)
mgmt(2)
mib(1)
private(4)
22
Como padro de tipo de dados, segundo Black (1994, p. 122), existe uma definio de
seis tipos para o SNMP:
Network Address: valor descrito no tipo CHOICE do ASN.1 que define a fam-
lia de protocolos da Internet;
IP Address: Endereos de 32-bits da Internet. Descrito com o tipo OCTECT
STRING do ASN.1;
Time Ticks: representa valores inteiros positivos, no qual usado para gravar
eventos de tempo. definido pelo tempo em milisegundos;
Gauge: Valores inteiros positivos que podem variar de 0 at 2
32
-1. Este tipo
no permite o recomeo de contador, e o valor pode aumentar ou diminuir;
Counter: Valores inteiros positivos que podem variar de 0 at 2
32
-1, mas dife-
rente do tipo Gauge, este podero recomear o contador e os valores apenas
aumentam de valor;
Opaque: Permite que o objeto gerenciado possa ser passado como OCTECT
STRING.
O protocolo SNMP ainda se limita a operao simples e limitadas em nmero de
PDUs (Protocol Data Unit) para realizar suas funes (Black 1994, p. 274). Cinco unidades
de dados de protocolo foram definidas no padro, como ilustra a Figura 5, e elas so:
Get Request: usada para acessar um agente e obter valor de sua lista. Este pos-
sui um identificador para que o agente possa diferenciar dentre as mltiplas
respostas (Black 1994, p. 274);
Get-NextRequest: similar ao Get Request, entretanto este retorna o prximo i-
dentificador lgico na rvore MIB (Black 1994, p. 274);
Get Response: a resposta para as duas PDUs anteriores. Contm o identifica-
dor usado para diferenciar, e contm um identificador para prover informaes
do tipo da resposta (cdigo de erro, estados de erros, e uma lista de informao
adicional) (Black 1994, p. 275);
Set Request: descreve uma ao que ser executada em um elemento. Normal-
mente utilizada para realizar mudana de valores dos objetos (Black 1994, p.
275).
Trap: esta PDU permite que agentes reportem um evento em seu domnio ou
de mudana de estado num elemento de rede (Black 1994, p. 275).
23

Figura 5 PDUs do SNMP
Fonte: Black (1994, p. 275)
2.3 Consideraes Finais
Neste captulo foi conceitualizado o assunto de gerncia de redes, bem como o proto-
colo padro de gerncia de redes. Com estas informaes foi possvel adquirir conhecimento
para o desenvolvimento do ambiente de monitorao.

Gerente

Agente
Get Request
Get Response
Get-Next Request
Trap
Set Request
24
3. SLA SERVICE LEVEL AGREEMENT
3.1 Introduo
Para formalizar como a prestadora de servios dever prover seus servios aos seus
clientes atualmente comum utilizao de Acordos de Nvel de Servios (SLA Service
Level Agreement), que estipula as medidas que sero gerenciadas, e qual dever ser o nvel de
servio que deve ser prestado. Este SLA tem como funo, entre outros pontos, garantir uma
qualidade mnima para o funcionamento do servio.
SLA estabelece o nvel de servio requisitado e projetado para criar uma compreen-
so comum sobre servios, prioridades e responsabilidades, entre cliente e provedor de servi-
os (Schweitzer,1999, p. 17). A responsabilidade nas duas partes certamente um dos pontos
mais importantes em um SLA, pois no apenas a prestadora de servios que estar sendo ava-
liada num acordo, mas sim ambas as partes.
3.2 Motivao
Como fatores que Sturm (2001, p. 4) v como motivadores da implantao acordos de
nveis servios est nos clientes, que esto se tornando mais inteligentes, e reduo de ora-
mentos enfrentada pelos departamentos de TI. Um fato notvel na atualidade se representa
nos clientes que esto menos ignorantes e passaram a compreender certos aspectos de tecno-
logia, o que faz com que eles exijam melhores servios por preos menores. Atualmente os
clientes no aceitam desculpas ou explicao que antes eram engolidas por eles, mas manter
servios de qualidade notvel necessita de grandes investimentos, o que no possvel com a
situao atual, onde o oramento com servios de TI est sendo constantemente enxugado.
Alm desses pontos, existe ainda o crescimento da necessidade da utilizao de siste-
mas de computao por muitas empresas, crescendo assim o grau de confiana sobre as m-
quinas. No possvel para uma empresa que s faa vendas atravs da internet, ter suas ven-
25
das interrompidas completamente por um problema que foi gerado pela provedora de acesso.
Ter um nvel de confiana crtico em servios exige a criao de acordos.
Uma pesquisa da International Data Corp. de 1999 entre 500 executivos de grandes
empresas indica que 90% destes poderiam passar a exigir SLA de fornecedores de servio at
2000, este sendo um nmero 30% maior que uma pesquisa semelhante no ano anterior (Du-
kart, 2000). Isto demonstra o quo importante est o interesse dos clientes em se utilizar ser-
vios sabendo como ser o seu aproveitamento, ou qualidade entregada pelo prestador de ser-
vios. Pois tendo um acordo estipulado, o cliente sabe o que cobrar do fornecedor quando o
servio no atinge nveis especificados no acordo.
Para provedoras de servio de rede, a pesquisa realizada por Blum (2002) demonstra
como tem crescido o interesse por acordos de nveis de servio para redes. Detalhes sobre
resultado da pesquisa realizada, bem como resultado das pesquisas anteriores a de 2002 so
apresentados na Figura 6. O crescimento tem sido to expressivo que o autor considera que
atualmente ter SLA universalmente esperado dos provedores de servios de rede.

Figura 6 Importncia do SLA nos provedores de servio de rede
Fonte: Blum (2002)
26
Pesquisa da International Network Services (INS) de 1999 (Figura 7) revela os princi-
pais objetivos de uma organizao que deseja desenvolver um SLA, em destaque est o ge-
renciamento de expectativas. Para Sturm (2001) esta funo que resulta na definio de acor-
do, uma proteo contra o fantasma da expectativa do usurio, que como ser humano tem
como natureza querer sempre mais e melhor. Assim se as expectativas estiverem documenta-
das o usurio encontrar um ponto de referncia, e no ir ficar frustrado com uma expectati-
va equivocada.
15%
25%
26%
28%
28%
36%
36%
37%
42%
48%
55%
0% 10% 20% 30% 40% 50% 60%
Detectar e gerenciar as expectativas
Definir nveis de desemprenho necessrio
Mapear os recursos para servios mais crticos
Avaliar a satisfao do cliente
Avaliar a qualidade de servio
Ajudar a justificar e atribuir prioridade ao investimento
adicional
Relacionar a tecnologia aos objetivos da empresa
Atribuir prioridade aos servios, segundo a importncia
Avaliar o impacto da TI no negcio
Avaliar a eficcia dos procedimentos operacionais
Expandir Servios

Figura 7 Porcentagem de interesse para o desenvolvimento de SLAs
Fonte: Sturm (2001)
3.3 SLM
Enquanto os SLAs apenas estabelecem o acordo por escrito, o Gerenciamento de N-
vel de Servio (SLM Service Level Management) fica com a responsabilidade de verificar
se o SLA est sendo cumprido. Uma possvel ao imediata do no cumprimento de SLAs
pr-definidos seria o aviso ao administrador ou de agentes para tentar contornar o problema,
j uma ao de final de perodo poderia ser uma penalidade para prestadora de servios que
no supriu o acordo.
27
O Gerenciamento de Nvel de Servios uma metodologia disciplinada, proativa e de
procedimentos aplicados para assegurar que nveis adequados de servios sejam prestados a
todos os usurios (Sturm, 2000, p. 9). O instrumento que usado para avaliar se o resultado
dos nveis de servios est adequado, um acordo de nvel de servios, que se trata de um
acordo que normalmente firmado entre empresas e seus clientes.
Para Sturm (2001) uma ferramenta SLM deve definir, estimar, trilhar os objetivos,
monitorar, refinar e aperfeioar. Fica claro que estas ferramentas devero ser capazes de: cap-
turar e analisar dados sobre desempenho e disponibilidade de servios, identificar problemas
atuais e corrigi-los, monitorar e aprimorar o desempenho, tratar com os acordos de nvel de
servio, e criar relatrios do desempenho atual comparado com os objetivos traados no acor-
do.
3.4 Informaes Contidas em um SLA
Este trabalho no dar destaque de como um contrato SLA escrito, pois nosso obje-
tivo a partir de um contrato j estabelecido, realizar o gerenciamento das mtricas estipula-
das. Para Sturm (2001, p. 9;19), os nveis de servios que geralmente so definidos esto rela-
cionados aos seguintes aspectos quantificveis de qualidade que podem ser percebidos pelo
cliente:
Disponibilidade;
Capacidade de resposta;
Integridade;
Segurana.
Como neste trabalho visamos trabalhar na rea de redes de computadores, segue abai-
xo alguma das variveis gerenciveis mais populares a fim de se estabelecer um SLA:
Disponibilidade: porcentual de disponibilidade da rede, segmento de rede, ca-
nal de comunicao ou servio de rede, num determinado perodo.
Taxa de Erros: quantidade de erros na linha de transmisso num determinado
perodo.
28
Atraso: a latncia ou o atraso relacionado transmisso de um datagrama por
uma rede, sendo definido tempo mdio e mximo.
Jitter: relao da variao do atraso relacionado transmisso de um datagra-
ma pela rede, sendo definido uma variao mxima.
Vazo: verificar o mximo, mdio e o mnimo de banda atingida no nvel de
servio contratado.

Segundo Muller (1999) um documento SLA deve ter no mnimo os componentes lis-
tados da Tabela 3. Dentre os componentes, temos como mais importantes para o Monitora-
mento de Nveis de Servios: Servios, Preciso, Disponibilidade, Limitaes e Medio.
Tabela 3 Componentes mnimos num SLA proposto por Muller (1999)
Componente Descrio
Pano de Fundo Deve conter informaes suficientes para informar um leitor no tc-
nico da aplicao, e permitir que a pessoa entenda os nveis de servi-
os e porque eles so importantes para o negcio.
Partes Deve identificar as partes envolvidas no acordo
Servios Deve quantificar o volume de servio que ser provido pelo departa-
mento de TI. O cliente da aplicao deve poder especificar a mdia e
os nveis de pico, e quando eles ocorrem.
Preciso Deve especificar uma mtrica qualitativa da maioria das aplicaes,
para que o usurio saiba quo rpido ele vai receber um trabalho pron-
to.
Disponibilidade Deve descrever quando o servio considerado disponvel para os
usurios finais. Provedora deve informar o tempo que se espera indis-
ponibilidade planejada e no planejada.
Limitaes Descreve limites que sero suportados durante perodos de pico de
utilizao
Reembolso Deve colocar para as partes como ser a forma de reembolso no acor-
do.
Medio Deve descrever o processo pelo qual os nveis de servios sero moni-
torados, bem como a frequncia do monitoramento. Deve ainda espe-
cificar como os usurios devem reportar problemas a provedora de
29
Componente Descrio
servios.
Renegociao Deve descrever como e em quais situaes um SLA deve ser alterado
para refletir mudanas no ambiente.

Em pesquisas realizadas por Blum (2002) mostram que entre as mtricas possveis de
gerenciamento de nvel de servio, a que possui maior destaque a Disponibilidade de Re-
de, sendo considerado pelos entrevistados de 2002 com nvel 3,9 de escala de um at quatro,
sendo um indicando no muito importante e quatro como muito importante. Outras mtricas
relacionadas a componentes que dependem da rede que apareceram na pesquisa est a De-
sempenho da Rede com 3,7 e Vazo da Rede com 3,6.
Para ilustrar como algumas empresas de telecomunicao tratam seus usurios, Muller
(1999) lista as regras do acordo juntamente com o reembolso que utilizado quando um dos
componentes do acordo quebrado.
3.5 Relatrios
Um importante componente no gerenciamento de nvel de servio o relatrio. Um re-
latrio tem como grande funo servir como um elo de comunicao entre o cliente e o pres-
tador de servio, ele que tem a funo de traduzir para o cliente coletas que foram realizadas
e apresent-las de forma clara. A caracterstica de simplicidade deve ser atingida para que o
outro lado consiga ver de forma no obscura dados, na maioria das vezes, quantitativos.
Para Sturm (2001, p. 39) necessrio saber que tipo de pblico ter o relatrio a ser
gerado, pois cada categoria de pblico exige informaes diferentes que variam de acordo
com o enfoque, detalhamento e frequncia. Na diviso proposta por Sturm (2001, p. 39) e-
xiste os seguintes tipos de relatrios:
Direo executiva: devem ser extremamente resumidos e a qualidade que foi
provida pela empresa;
30
Ramos de negcio: relatar o impacto das paralisaes ou degradaes do ser-
vio em termos ligados ao negcio;
Interno: mostra todas as paralisaes e degradao de desempenho da tecno-
logia;
Clientes Externos: devem fornecer o nvel de qualidade de servio entregue a
ele atravs da empresa.
A periodicidade em que os relatrios so gerados ir depender do pblico alvo do rela-
trio e do nvel de detalhamento. Um grfico dirio mais detalhado, e so direcionados ao
pblico que ir fazer analise de melhoria de servio. J os relatrios de freqncia menor, so
indicados quando o pblico alvo de nvel mais alto, e so mais relacionados aos aspectos
comerciais, menos tcnicos.
Sobre produtos de gerenciamento de nvel de servios Sturm (2001, p. 122) v que nos
produtos atuais existe uma grande lacuna entre monitorao e os relatrios. Sem uma entrada
correta, inevitvel que relatrios se tornem um fracasso no seu objetivo, mas fornecedores
de produtos SLM tm como principal fraqueza gerao de relatrios. Para tanto, alguns pro-
dutos de monitorao chegam a no gerar relatrios, e estes sero gerados por outros produtos
no associados com a ferramenta de coleta.
Neste captulo foi possvel apresentar de forma mais ampla acordos de nvel de servi-
o, com seus conceitos e motivaes que fazem este trabalho hbil para um gerenciamento
baseado em acordos. Ainda so apresentadas caractersticas que os acordos de SLA para redes
normalmente so caracterizados, para que o ambiente criado tenha utilidade nos casos mais
comuns de acordos estabelecidos.

4. TECNOLOGIAS UTILIZADAS
Na composio deste trabalho foram utilizadas diversas ferramentas ligadas a progra-
mao, entre elas banco de dados, linguagens de programao e bibliotecas de funes e neste
captulo apresentaremos cada ferramenta utilizada.
4.1 MySQL
O armazenamento e recuperao de dados tm sido um elemento central de muitos a-
plicativos atualmente. No passado, segundo Pachev (2003, p.1), os desenvolvedores de soft-
ware desenvolviam seus cdigos de baixo nvel para realizar esta funo, mas logo se perce-
beu que em cada aplicao o desenvolvedor teria que reinventar a roda. A evoluo deste
estgio foi criao de aplicaes isoladas chamadas de banco de dados que teriam um
motor de armazenamento e recuperao de dados atravs de uma linguagem especifica cha-
mada SQL (Structured Query Language).
Atualmente, os desenvolvedores tm a disposio diversos produtos que utilizam-se de
chamadas SQL. Um produto que apresenta essa funcionalidade tambm chamado de servi-
dor de banco de dados SQL, ou em alguns casos, banco de dados relacional (RDBMS - Rela-
tional Database Management Systems), este que so diferenciados pela funcionalidade. Um
servidor de banco de dados relacionado deve cumprir certos requisitos formais para possuir
esse nome (Pachev, 2003, p 1).
Existe um padro de consultas SQL que so implementadas pelos grandes fornecedo-
res de banco de dados, como Oracle, DB2 da IBM, Sybase, e o Microsoft SQL Server. Mas o
banco de dados MySQL se difere deste padro, entretanto possui caractersticas que o torna-
ram um banco de dados muito popular em diversos ambientes empresariais. Uma das caracte-
rsticas mais importantes destacada por Pachev (2003, p 2) est no fato de que o MySQL tem
seu cdigo aberto, sobre a licena GNU General Public Licence (GPL). Este fato faz com que
32
as pessoas possam modificar livremente o MySQL conforme suas necessidades, e melhorar o
produto de domnio pblico atravs de contribuies de experincias.
Algumas das utilizaes do MySQL que Pachev (2003, p 2-4) v como mais utilizadas
em ambientes corporativos incluem: web sites dinmicos, log de uso, Data Warehousing, ba-
ses integradas em aplicativos e em dispositivos embutidos. Mas Pachev (2003, p 4-12) cita as
vantagens e desvantagens da utilizao do MySQL, entre as principais caractersticas desta
base podemos citar: velocidade, disponibilidade, escalabilidade, pouca necessidade de recur-
sos, multi-plataforma e rapidez de instalao e configurao. Entre as desvantagens mais sig-
nificativas est o fato de que existe uma falta de certas funcionalidades presentes do SQL pa-
dro, como a falta de sub-consultas, vises, stored procedures, gatilhos e chaves estrangeiras.
Esta falta de funcionalidades faz com que as funes que normalmente so feitas por bancos
de dados dos grandes fornecedores, no so implementadas no MySQL, e toda a emulao
destas funcionalidades precisam ser feitas no nvel de aplicao.
4.2 Java
Uma das linguagens de programao que mais vm crescendo atualmente certamente
a linguagem Java, esta includa na chamada plataforma Java. Deitel (2001) relata que o Java,
criado pela Sun em 1991 comeou em cima de uma pesquisa com o codinome Green, e o re-
sultado dela foi uma linguagem de programao semelhante a C e C++, e que seu criador,
James Gosling, o chamou de Oak (carvalho em ingls) homenageando a rvore que ficava em
sua janela de escritrio. Logo, com uma visita da equipe da Sun a uma cafeteria, e o nome da
cidade em que o caf importado vinha chamou a ateno, e o nome Java acabou pegando.
Java s foi divulgado oficialmente em 1995, e ele teve um interesse imediato da co-
munidade comercial para criao de pginas interativas e dinmicas para o fenmeno em
crescimento desde 1993 chamado World Wide Web. Java ento tem crescido rapidamente para
o desenvolvimento de aplicativos baseados na Internet, principalmente por suas caractersticas
33
de portabilidade apresentadas. Flanagan (1997) apresenta o texto da Sun descrevendo a sua
linguagem, em traduo livre Java, uma linguagem: simples , orientada a objeto, distribuda,
interpretada, robusta, segura, neutra em relao arquitetura, portvel, de alta performance,
muti-tarefa, e dinmica.
Outra caracterstica que fez a linguagem ser utilizada no ambiente que foi desenvolvi-
do, est no fato do controle multi-tarefa (Multithread) que a mesma implementa em sua plata-
forma. A caracterstica de multi-tarefa faz com que aplicao possa ter mais de um fluxo de
processamento, e possa executar mais que uma tarefa de cada vez. Na implementao do Java
cada Thread (fluxo de processamento) recebe uma frao de tempo do processador (chamada
de quantum de tempo), e quando este tempo se expira, esta thread entra no modo de espera, e
outra thread tem oportunidade de utilizar o seu quantum.
SNMP
Para a execuo de tarefas referentes a chamadas SNMP aos agentes SNMP a lingua-
gem Java no possui em sua biblioteca bsica, funes para realizar tais tarefas. Para tanto foi
necessria uma busca por bibliotecas que realizassem tais funes e que fosse livre para utili-
zao, e uma que se mostrou adaptvel para a soluo a ser gerada foi a JMGMT (Drr,
1999). Mas a mesma se encontra desde 1999 sem nenhuma atualizao, e o LRG, Laboratrio
de Redes e Gerncia da Universidade Federal de Santa Catarina gerou uma verso melhorada
da mesma que realiza as primitivas do SNMP com maior confiabilidade (Assuno, 2004).
4.3 HTML e XHTML
A linguagem de hipertexto HTML (Hyper Text Markup Language) foi criada especifi-
camente para deferir web sites que so apresentados na World Wide Web. Documentos HTML
so interpretados por aplicaes chamadas navegadores web, que foram apresentadas ao mun-
do em 1991 por Tim Berners-Lee na aplicao chamada WorldWideWeb. Mas a populariza-
o da web s aconteceu com o navegador web Mosaic, que era uma aplicao grfica rodan-
34
do sobre o X Window do Unix e logo portado para os Apple Macintosh e Microsoft Win-
dows.
Em 1993 o lder da equipe que fez o Mosaic saiu da empresa e criou o seu navegador
chamado Netscape Navigator. A Microsoft observando que estava perdendo terreno no campo
da World Wide Web, decide adquirir a Spyglass, Inc, que possua uma verso prpria do Mo-
saic, e cria em 1995 seu navegador Internet Explorer. Este navegador fez com que at 1998
houvesse uma guerra de navegadores, onde cada produtora de navegador definia sua prpria
linguagem HTML que seria interpretada pelo navegador. Esta batalha foi ganha pela Micro-
soft, e entre os fatos que fizeram parte desta vitria, est no fato que seu navegador ser inclu-
do por padro em suas distribuies do sistema operacional Windows. Em pesquisas realiza-
das em todo mundo em janeiro de 2004 sobre 2 milhes de visitantes, em web sites de dife-
rentes pases revelam que 94,6% dos usurios utilizam o Microsoft Internet Explorer.
Para regulamentar o HTML existe o consrcio criado em 1994 pelo criador da lingua-
gem, o W3C (World Wide Web Consortium), que atualmente formado por diversas empresas
relacionadas com tecnologias (Herman, 2000). Este consrcio criou diversas verses da lin-
guagem HTML, e em 2000 criou o XHTML (Extensible Hypertext Markup Language), uma
verso do HTML com caractersticas de XML. Outro fator marcante no XHTML a separa-
o proposta entre contedo e visual, sendo que esta separao feita com o contedo defini-
do dentro de arquivos texto no formato XHTML, e os estilos visuais de cada elemento do con-
tedo definidos dentro de arquivos chamados folhas de estilo. Um dos formatos mais comuns
de folhas de estilos aceito pelos navegadores e proposto pela W3C descrito por Herman
(2000) o CSS (Cascading Style Sheets) publicado em 1996.
Menus em rvore
Para auxiliar na criao de uma interface mais amigvel com o usurio final, foi utili-
zada uma biblioteca de funes Javascript que gera menus em rvore para listar objetos em
35
forma de dependncia. A biblioteca escolhida foi a Treeview (Martins, 2004), que implementa
atravs de chamadas de Javascript um menu semelhante ao encontrado em visualizador de
sistemas de arquivos, onde pontos que podem ser abertos indicam pastas, e as folhas da rvore
indicam arquivos.
4.4 PHP
A linguagem PHP (PHP Hypertext Preprocessor) foi criada para facilitar a criao de
pginas da Web dinmicas, j que tanto o HTML e XHTML apenas definem contedo esttico
(Soares, 2000, p. 1). Nesta tarefa existem diversas outras linguagens, Soares (2000, p. 1) des-
taca Java, ASP, Cold Fusion e Perl. Entre as caractersticas com que Soares (2000, p. 5) cita
para o sucesso do PHP incluem: rapidez, baseada no servidor, portvel, est em contnuo a-
primoramento e possui seu cdigo aberto.
A propriedade de rodar no servidor do PHP (Server Based) uma tendncia das apli-
caes Web, esta faz com que o lado do cliente seja leve, e toda a programao feita do lado
servidor. Tal caracterstica ainda favorece o controle de segurana, pois a aplicao apenas
roda em um nodo de processamento, controle de verso, pois sempre o usurio ir executar a
verso mais atualizada da aplicao, e a baixa necessidade do lado do cliente, que apenas ne-
cessita de um navegador Web para interagir com a aplicao.
Grficos
Para a criao de relatrios mais amigvel ao usurio que os dados sejam apresenta-
dos em grficos. A linguagem PHP permite atravs de biblioteca gerar dinamicamente ima-
gens atravs da GD library (Boutel, 2004), que tem como principal caracterstica ser imple-
mentada em diversas linguagens de programao e ter seu cdigo livre. Entretanto, criar gr-
ficos utilizando apenas esta biblioteca uma tarefa manual, pois a mesma apenas define for-
mas bsicas e filtros. Para auxiliar na criao de grficos, existe uma biblioteca que faz a uti-
lizao da GD Libary, e que tem como funcionalidade criar grficos.
36
Esta ferramenta chamada de JpGraph, de uso gratuito, e permite a criao facilitada
de vrios grficos comuns. A criao feita atravs da escolha do tipo de grfico que se dese-
ja gerar, e da incluso de elementos ao mesmo atravs de chamadas definidas pelas classes da
biblioteca. Exemplos de grficos que podem ser gerados pela biblioteca podem ser vistos na
Figura 8.

Figura 8 Exemplos de grficos do JpGraph

Neste captulo foram apresentadas as tecnologias que sero utilizadas no desenvolvi-
mento do ambiente de monitorao. O destaque ficou nas linguagens e nas principais caracte-
rsticas pelo qual as mesmas foram utilizadas. A certeza de ter escolhido a linguagem certa
para a aplicao, serve como base para uma adoo ou no do produto a ser gerado neste tra-
balho.
5. AMBIENTE DE MONITORAO SLA
Neste captulo iremos apresentar o processo de criao do ambiente de monitorao
SLA, desde sua concepo, com a definio, at a implementao de cdigo.
5.1 Motivao
O mercado de softwares de monitorao SLM liderado pela IBM com sua famlia de
produtos Tivoli, possuindo quase um quarto da fatia de mercado no ano de 2002 como aponta
os dados da figura 1. Outro importante competidor presente na fatia que merece destaque a
HP, com a sua linha de produtos OpenView. Essas ferramentas tentam integrar vrios equipa-
mentos e diversas mtricas que se adaptem para o SLA firmado pela prestadora de servio.
No entanto Dubie (2003) destaca que as aplicaes existentes que trabalham com LANs no
so utilizveis em enlaces WAN.

Figura 9 Balano do mercado de SLM
Fonte: Dubie (2003)
38
Ter uma ferramenta que permita o gerenciamento de nveis de servios importante.
Este fato se d, pois segundo Sturm (2001, p. XII), o principal motivo que faz com que em-
presas no implementem Acordos de Nvel de Servios porque elas desconhecem o processo
de criao de um gerenciamento de nvel de servio.
5.2 Objetivo
Nosso objeto especfico est no desenvolvimento de um ambiente para possibilitar que
os 60% dos executivos de TI que esto utilizando SLA nos servios de provedores de acesso
possam acompanhar se o mesmo est sendo cumprido. Este ambiente deve trabalhar com pa-
dres de mercado como o protocolo SNMP, para tornar a mesma uma ferramenta que possa
trabalhar com os mais diversos equipamentos e ambientes que suportam este protocolo.
Para tanto o ambiente tentar utilizar-se de ferramentas livres, tanto no que se refere a
ferramentas de monitorao, como a interface com o usurio para o mesmo colocar servios e
estabelecer mtricas. Para esse trabalho iremos nos restringir ao fato de depois de definido um
SLA fazer o gerenciamento do mesmo atravs de um ambiente que garanta que o SLA est
sendo cumprido e retornando relatrios do comportamento da rede.
5.3 Planejamento
O desenvolvimento de aplicaes de qualidade uma rdua tarefa, pois entre boas i-
dias, requisitos e um software que funcione existe muito mais que programao. Para Lar-
man (2000) a anlise e o projeto de software definem como resolver o problema, o que pro-
gramar, capturando este projeto em maneiras mais fcies de se comunicar, de revisar, de im-
plementar, e de como evoluir. Em nosso ciclo de vida de desenvolvimento da ferramenta de
monitorao sero recriados alguns passos que Larman define na criao de um software.
Larman propem que a criao de software seja divido em duas partes separadas, a
Anlise e o Projeto. A anlise proposta se dedica na investigao dos problemas e dos requisi-
tos, e no como resolver o problema. Para o projeto a nfase est na soluo conceitual, que
39
cumpre os requisitos especificados na anlise, e no como ser a implementao. Exemplos
de tarefas no projeto est definio dos objetos
No entanto criar um sistema no necessrio qualquer processo de anlise e projeto,
conhecido este como ciclo de projeto Code-Fix, onde o cdigo gerado e caso ele no atenda
as expectativas ele arrumado. Apesar deste processo gerar resultados rpidos inicialmente,
ao longo do desenvolvimento a omisso da etapa de anlise e projeto pode resultar em um
produto final que no cumpre as expectativas descritas nos requisitos ou ainda na produo de
sistemas onde a manuteno invivel.
Para tanto utilizada a linguagem UML (Unified Modeling Language) que est se tor-
nando universalmente aceita como linguagem usada no projeto de software. A UML poder
ser empregada para a visualizao, a especificao, a construo e a documentao de artefa-
tos que faam uso de sistemas complexos de software (Booch, 2000). Na notao UML exis-
te uma srie de modelos que permitem separar em diferentes etapas a concepo do software,
e de foco de observao do problema. A diviso faz com que exista a gerao de diferentes
nveis de abstrao em cada modelo, fazendo com que os detalhes referentes a cada fase do
processo de desenvolvimento sejam abordados de forma mais especifica visando garantir a
gerao de um produto final que satisfaa os requisitos que foram elaborados na anlise.
Requisitos
Requisitos so as capacidades e condies na qual o sistema deve cumprir, e esta tare-
fa o primeiro desafio na etapa de anlise, Larman (2000) destaca o papel da definio corre-
ta dos requisitos atravs de um estudo prprio em que ele mostra que problemas nos requisitos
atingem 38% dos desafios em projetos de software. O ambiente que ser criado ter os se-
guintes requisitos:
Fornecer uma interface para a insero de objetos gerenciveis, e relacionar os
monitoramentos desejados seguido pela SLA relativa;
40
Possuir tratamento especial para servios WAN, incluindo suas particularida-
des;
Permitir a visualizao de relatrios de nveis de complexidade diferenciados,
que tero interfaces WEB que podero ser acessadas pelos navegadores popu-
lares;
Possibilidade de acrscimo de tempo de manuteno previamente especificado
por data, hora e durao, onde nesse perodo as medies seriam desconsidera-
das em relao s mtricas;
Controlar o armazenamento de dados, evitando desperdcio de espao e cres-
cimento de dados acelerado;
Ter um agente autmato que busque os dados em um intervalo pr-
estabelecido, e gere atravs dele os dados de coletas de forma multi-tarefa.
Clientes
O ambiente ter como clientes prestadores de servios que desejam verificar se o ser-
vio prestado est em conforme com um SLA. E tambm usurios contratantes de servios
que desejem saber se o servio contratados est sendo atendido adequadamente durante todo o
tempo.
Objetivos
Criar uma ambiente de monitorao confivel, onde objetos gerenciveis podem ser
adicionados e terem relacionado a ele mtricas. Mais especificadamente, os objetivos preten-
dem:
Adio de servios com mtricas a serem avaliadas;
As mtricas devem poder suportar dados variados de SLA, como desempenho
mnimo.
Casos de Uso
O ambiente ser detalhado inicialmente baseado em Casos de Uso (Use Cases) que
buscam dar a idia de funcionamento do ambiente, bem como apresentar o modelo de uma
forma descritiva apontando pontos importantes de funcionamento que serviro de base para o
desenvolvimento. Casos de Uso so documentos de texto, e no so diagramas, de acordo
41
com Larman (2000), e criar estes primordialmente escrever textos, no desenhos. No entan-
to, a notao UML define um diagrama de Casos de Uso, para demonstrar nomes de casos de
uso, atores e suas ligaes.
Os casos de uso do ambiente modelado tm como viso os casos de uso Black-Box.
Este tipo de abordagem no chega a descrever trabalhos internos do sistema, seus componen-
tes ou seu projeto. O objetivo geral desta abordagem definir as responsabilidades dos ele-
mentos de software. Para apresentar os casos de uso utilizado o formato fully dressed de
duas colunas, definido por Larman (2000).

Caso de Uso: Adicionar Dispositivo.
Atores: Administrador.
Finalidade: Possibilitar a incluso de um novo dispositivo a ser verificado
Viso Geral: O administrador informa dados bsicos do dispositivo, e um por vez
ele cadastrado. Ao trmino do cadastro o usurio poder colocar in-
terfaces ao dispositivo, ou colocar o mesmo num acordo.
Tipo: Primrio e real.

Ao do Ator Ao do Sistema
1. Administrador escolhe no menu a
opo de criar um novo dispositivo.
2. exibido um formulrio com campos
de descrio do dispositivo, IP do dispo-
sitivo, comunidade SNMP e dispositivo
verificador.
3. O Administrador informa os dados
nos campos do formulrio.
4. Sistema verifica se j existe o IP in-
formado, e verifica se os dados foram
digitados de forma correta.
5. Caso tenha encontrado algum erro no
formulrio, enviado o erro para o usu-
rio, voltando ao formulrio com os da-
dos digitados. Caso tenha sucesso na
verificao, informado ao usurio o
42
sucesso do cadastro.

Caso de Uso: Alterar Dispositivo.
Finalidade: Possibilitar a alterao de um dispositivo verificado.
Viso Geral: O administrador informa qual dispositivo deseja alterar dados bsicos
e ter acesso administrao de interfaces.

1. Administrador seleciona um dos dis-
positivos que deseja alterar.
2. exibido um formulrio onde esto
listados os dados bsicos atuais, sendo
que o usurio poder alterar todos eles:
nome, IP, comunidade e dispositivo
verificador. tambm apresentado um
enlace para o controle de interfaces.
nos campos do formulrio e confirma a
alterao.
4. Sistema verifica se os dados foram
rio voltando ao formulrio com os da-

Caso de Uso: Listar Dispositivos.
43
Finalidade: Possibilitar a que o administrador visualize os dispositivos cadastra-
dos.
Viso Geral: Faz com que o administrador tenha a viso geral de todos os disposi-
tivos cadastrados, permitindo que seja aberta a opo de alterar um
dispositivo e adicionar interfaces ao mesmo.

1. Administrador seleciona no menu que
deseja listar dispositivos.
2. exibida uma tabela com os dados
dos dispositivos cadastrados, ordenados
por IP, aparecendo alm do mesmo a
descrio dele e quantas interfaces esto
ligadas a ele. Existe a opo em cada
elemento de ir para a ao Alterar Dis-
positivo.
3. O Administrador seleciona qual dis-
positivo deseja alterar.
4. Sistema encaminha usurio para o
dispositivo relativo.

Caso de Uso: Remover Dispositivo.
Finalidade: Possibilitar que o administrador remova um dispositivo cadastrado.
Viso Geral: Caso um dispositivo no deva mais ser listado e todos os dados refe-
rentes ao mesmo possam ser removidos, o usurio poder remover o
mesmo.

1. Administrador seleciona nas opes
do dispositivo que deseja remover um
dispositivo.
2. exibido um aviso ao usurio infor-
mando que a ao que ser efetuada
envolver todos os dados relativos ao
dispositivo e a ao no pode ser desfei-
ta depois de efetuada.
3. O Administrador escolhe entre con- 4. Caso o usurio escolha em remover o
44
firmar ou cancelar a remoo. dispositivo, todos os dados referentes ao
mesmo so removidos do sistema, e o
usurio informado da ao que se su-
cedeu. Caso o usurio cancele a remo-
o, ele ser redirecionado para a pgina
que solicitou a remoo.

Caso de Uso: Assistente de Adio de Interfaces.
Finalidade: Possibilitar a adio de novas interfaces de um dispositivo atravs de
um assistente.
Viso Geral: O administrador informa que deseja inserir novas interfaces, e o sis-
tema ir fazer uma varredura no dispositivo coletando informaes
sobre as interfaces instaladas no dispositivo.

1. Administrador seleciona um dos dis-
positivos que deseja adicionar interfa-
ces.
2. exibido um formulrio com uma
lista de parmetros que sero coletados
juntamente com as interfaces.
3. O Administrador informa quais par-
metros deseja adicionar.
4. So retornadas ao Administrador,
opes da mtrica informada, bem como
o formulrio para definio do nvel de
servio que seja relacionado.
5. O ator preenche os campos do formu-
lrio e pede para o mesmo ser enviado.
6. feita uma coleta baseada no disposi-
tivo informado, e nos parmetros esco-
lhidos pelo usurio.
rio voltando ao formulrio com os pa-
rmetros selecionados. Caso tenha su-
cesso na coleta, o sistema informa todas
45
as interfaces coletadas, bem como os
parmetros que ficaram disponveis, e
permite que o usurio possa selecionar
novas interfaces que ainda no foram
cadastradas.
8. O administrador seleciona as interfa-
ces que deseja adicionar no dispositivo.
9. Sistema adiciona ao dispositivo as
interfaces selecionadas, colocando como
descrio de interface, as melhores in-
formaes coletadas sobre a interface.
Sistema retorna ao usurio o sucesso da
adio de interfaces.

Caso de Uso: Listar Interfaces.
Finalidade: Possibilitar a que o administrador liste as interfaces cadastradas em
um dispositivo.
Viso Geral: Faz com que o administrador tenha a viso das interfaces cadastradas
num dispositivo, permitindo que ele as altere ou as remova.

deseja listar interfaces de um dispositi-
vo.
2. exibido um formulrio com as in-
terfaces cadastradas com a sua descrio
e opo para remover a interface.
3. O Administrador faz as alteraes que
deseja nas interfaces dos dispositivos.
4. Sistema realiza as aes desejadas
Inclui Remover Interfaces
Inclui Alterar Interface
5. Caso ocorra algum erro nas aes
selecionadas, retornado para o usurio
a lista de erros, e o formulrio apre-
sentado novamente com os dados digi-
tados, voltando ao passo 2. No sucesso
46
das aes selecionadas, exibida uma
tela de concluso da ao.

Caso de Uso: Remover Interfaces.
Finalidade: Possibilitar que o administrador remova interfaces cadastradas.
Viso Geral: Caso uma interface no deva mais ser listada e todos os dados refe-
rentes mesma possam ser removidas, o usurio poder remover a
mesma.

de alterao de interfaces, as interfaces
que deseja remover.
2. Sistema remove conforme solicitado,
as interfaces selecionadas pelo usurio,
incluindo os dados relativos a mesma.

Caso de Uso: Alterar Interfaces.
Finalidade: Possibilitar a alterao de interfaces cadastradas num dispositivo.
Viso Geral: O administrador informa qual interface deseja alterar dados.

1. Administrador altera no campo do
formulrio de alterao de interfaces a
nova descrio que deseja para um dis-
positivo.
2. Sistema verifica se a nova descrio
vlida.
3. Caso exista algum erro numa descri-
o de uma interface, o erro ser retor-
nado para o usurio. Caso nenhum erro
ocorra, o sistema altera a descrio da
47
interface.

Caso de Uso: Agendar Manuteno.
Finalidade: Possibilitar a criao de uma janela de manuteno, onde os dados
no iro afetar as mtricas no perodo relacionado.
Viso Geral: O administrador informa quais dispositivos e interfaces que iro ser
afetados em uma janela de manuteno, e esta ser no relatrio, e no
momento agendado os dados coletados sero desconsiderados para
efeito de calculo de ndices.

1. Administrador seleciona que deseja
adicionar uma nova janela de manuten-
o.
2. exibido um formulrio com dados
de incio e final, e dados do motivo da
criao da janela de manuteno.
3. O Administrador informa dados da
janela de manuteno.
4. feita uma verificao nos campos
do formulrio, para verificar se algum
dado foi digitado incorretamente.
verificao, retornado para o usurio
que o agendamento foi realizado com
sucesso.

Caso de Uso: Listar Manutenes.
Atores: Administrador e Cliente.
Finalidade: Possibilitar que o administrador liste as manutenes agendadas.
48
Viso Geral: Faz com que o administrador tenha a viso geral de todas as manu-
tenes cadastradas, permitindo que seja aberta a opo de alterar a
mesma.

1. Usurio seleciona no menu que deseja
listar manutenes agendadas.
bsicos das manutenes cadastradas,
como data de inicio, durao e nmero
de dispositivos afetados. Existe ainda a
opo nesta de ir at uma manuteno
para realizar ao Alterar Manuteno
caso ele seja um administrador.
3. O Administrador seleciona entre uma
das manutenes.
4. Sistema encaminha usurio para a
manuteno desejada informando a ma-
nuteno relativa.

Caso de Uso: Alterar Manuteno.
Finalidade: Possibilitar a alterao de uma manuteno agendada.
Viso Geral: O administrador informa qual manuteno deseja alterar dados do
mesmo, sendo possvel alterar os dispositivos envolvidos.

1. Administrador seleciona uma interfa-
ce que deseja alterar.
listados os dados da manuteno rela-
cionada bem como um enlace para a
ao Adicionar Gerenciveis Manu-
teno e Remover Manuteno.
3. O Administrador altera os dados nos
campos do formulrio e confirma a alte-
49
rao.
verificao, o usurio informado da
alterao atravs de uma tela de confir-
mao.

Caso de Uso: Controle de Objetos na Manuteno.
Finalidade: Possibilitar que o administrador liste e adicione os objetos gerenci-
veis que estaro includos numa janela de manuteno.
Viso Geral: Faz com que o administrador tenha a viso de todos dos objetos ge-
renciveis que estaro includos numa manuteno e permite que o
usurio adicione e remova objetos estabelecidos.

administrar os objetos gerenciveis que
esto includos em uma manuteno.
2. Sistema retorna a lista de objetos ge-
renciveis que esto estabelecidos para
uma manuteno, possibilitando a adi-
o de novos objetos bem como remo-
o de objetos j estabelecidos.
3. O Administrador seleciona quais ob-
jetos deseja na manuteno.
4. Sistema atualiza o grupo de objetos
gerenciveis que o usurio escolheu.
retornando ao usurio uma tela de con-
firmao de alterao da manuteno.

Caso de Uso: Remover Manuteno.
Finalidade: Possibilitar que o administrador remova uma manuteno cadastrada.
50
Viso Geral: Caso uma manuteno seja cancelada e no ser mais realizada, o
Administrador poder remover a mesma.

da manuteno que deseja remove-la.
mando o mesmo que a ao que ser
efetuada no poder ser desfeita depois
de efetuada.
3. O Administrador escolhe entre con-
firmar ou cancelar a remoo.
4. Caso o usurio escolha em remover a
manuteno, todos os dados referentes
mesma so removidos do sistema, e o
usurio informado que a ao ocorreu
com sucesso.

Caso de Uso: Adicionar Acordo.
Finalidade: Possibilitar a incluso de um novo acordo a ser avaliado.
Viso Geral: Aps o cadastro de objetos gerenciveis, o Administrador poder co-
locar eles em acordos. Estes acordos podem ser de diversos tipos, e
para tipo existem diferentes campos a serem completados pelo usu-
rio.

1. Administrador escolhe no menu a
opo de criar um novo acordo, esco-
lhendo j o tipo de acordo.
2. exibido um formulrio com campos
de descrio do acordo e de dados rela-
tivos ao tipo de acordo a ser cadastrado.
nos campos do formulrio.
4. Sistema verifica os dados foram digi-
tados de forma correta conforme o tipo
de acordo.
51
rio, voltando ao formulrio com os da-

Caso de Uso: Alterar Acordo.
Finalidade: Possibilitar a alterao de um acordo.
Viso Geral: O administrador informa qual acordo deseja alterar e ter acesso ad-
ministrao do acordo.

1. Administrador seleciona um dos a-
cordos que deseja alterar.
listados os dados especficos do acordo
conforme o seu tipo. tambm nesta
tela onde existe opo de gerenciar os
objetos gerenciados, e Remover Acordo.
3. O Administrador informa os novos
dados nos campos do formulrio e con-
firma a alterao.
digitados de forma correta conforme o
tipo de acordo especificado.

Caso de Uso: Listar Acordos.
Finalidade: Possibilitar a que o administrador visualize os acordos cadastrados.
52
Viso Geral: Faz com que o administrador tenha a viso geral de todos os acordos
cadastrados, permitindo que seja aberta a opo de alterar um acordo
e controlar os objetos gerenciveis a ele.

deseja listar acordos.
dos acordos cadastrados, ordenados por
tipo de acordo, aparecendo alm do
mesmo a descrio dele e quantas obje-
tos esto sendo vigorados a ele. Existe a
opo em cada elemento de ir para a
ao Alterar Acordo.
3. O Administrador seleciona qual acor-
do deseja alterar.
4. Sistema encaminha usurio para o
acordo relativo.

Caso de Uso: Controle de Objetos no Acordo.
Finalidade: Possibilitar que o administrador liste e adicione os objetos gerenci-
veis que estaro includos num acordo.
Viso Geral: Faz com que o administrador tenha a viso de todos dos objetos ge-
renciveis que estaro includos num acordo e permite que se adicio-
ne e se remova objetos estabelecidos.

controlar os objetos gerenciveis que
esto includos em um acordo.
2. Sistema retorna a lista de objetos ge-
renciveis que esto estabelecidos para
um acordo, possibilitando a adio de
novos objetos como remoo de obje-
tos j estabelecidos.
3. O Administrador seleciona quais ob- 4. Sistema atualiza o grupo de objetos
53
jetos deseja no acordo. gerenciveis que o usurio escolheu.
retornando ao usurio uma tela de con-
firmao de alterao do acordo.

Caso de Uso: Remover Acordo.
Finalidade: Possibilitar a que o administrador remova um acordo cadastrado.
Viso Geral: Caso um acordo no deva mais ser listado e todos os dados referentes
ao mesmo possam ser removidos, o usurio poder remover o mes-
mo.

de alterao do acordo que deseja remo-
ver ele.
mando que a ao que ser efetuada
envolver todos os dados relativos ao
acordo e a ao no pode ser desfeita
depois de efetuada.
3. O Administrador escolhe entre con-
firmar ou cancelar a remoo.
4. Caso o usurio escolha em remover o
acordo, todos os dados referentes ao
mesmo so removidos do sistema, e o
usurio informado da ao que se su-
cedeu. Caso o usurio cancele a remo-
o, ele ser redirecionado para a pgina
que solicitou a remoo.

54

Figura 10 Diagrama de Casos de Uso Administrador

Figura 11 Diagrama de Casos de Uso sobre dispositivos gerenciados

Caso de Uso: Visualizar Relatrios de Acordos.
Atores: Cliente.
Tipo: Primrio.
Descrio: O cliente possui uma interface na qual ele poder ter dados referentes
de um acordo para os seus objetos gerenciveis, dando destaque ao
seu nvel de servio cadastrado. Os dados iro representar as infor-
maes num determinado perodo, e iro apresentar manutenes que
foram envolvidas no perodo.

55

Figura 12 Digrama de Casos de Uso sobre o Cliente

Caso de Uso: Realizar Mtricas.
Atores: Autmato.
Descrio: Varre todas as mtricas ativas de forma multi-tarefa (multithread) pe-
lo estado atual de cada objeto gerencivel cadastrado. Os dados de-
pois sero avaliados para verificar se as mtricas esto em conformi-
dade com o estipulado no cadastro.
1. Autmato ativado por uma tarefa
agendada.
2. Sistema faz uma verificao de que
tipo de dados ser necessrio coletar,
informando como ser feita a avaliao,
retornando um conjunto de trabalhos a
serem realizados.
3. O autmato pega os trabalhos neces-
srios, e os executa em modo multi-
tarefa.
4. Para cada mtrica, um trabalho dife-
rente feito, e quando ele for concludo
os dados de coletas so armazenados.

Figura 13 Diagrama de Casos de Uso sobre o Autmato
Escalonando Casos de Uso
Os casos de uso necessitam ser ordenados, e os mais altos na ordenao necessitam ser
atacados nos primeiros ciclos de desenvolvimento. A estratgia geral primeiro selecionar os
56
que influenciam significativamente a arquitetura central do sistema (Larman, 2000). Na
Tabela 4 se encontra os casos de uso ordenados conforme as qualidades encontradas em cada
caso de uso e como elas iro causar impacto em outros casos.
Tabela 4 Ordenamento dos casos de uso
Classificao Caso de Uso Justificativa
Alta Realizar Mtricas Afeta todo o sistema, tanto de interface
de entrada como de sada. Necessita de
um excessivo suporte de persistncia.
Necessidade de ser rpido.
Mdia Visualizar Relatrios de Acor-
dos
Papel fundamental na aplicao.
Adicionar Acordo Ir tratar problemas de persistncia e
base para o autmato poder fazer suas
medies.
Casos de uso sobre Dispositi-
vos e Interfaces
Dados resultantes sero utilizados .
Casos de uso sobre Acordo Ir afetar o relatrio.
Baixa Casos de uso sobre Manuten-
es
Trata apenas detalhes de aparncia e de
calculo final.

Modelo Conceitual
O passo mais essencialmente orientado a objetos na anlise ou na investigao a de-
composio do problema em conceitos e objetos individuais - as coisas nas quais estamos
interessados. Um modelo conceitual (ou Domain Model) uma representao de conceitos em
um domnio de problema (Larman, 2000). No modelo, que se assemelha muito com um dia-
grama de classes, os objetos do problema no mundo real so retratos com atributos e relaes.
A Figura 14 apresenta o diagrama do modelo conceitual, apresentando os principais aes
realizadas pelos atores, e os atributos que so necessrio no domnio do problema.
57

Figura 14 Diagrama do modelo conceitual

Modelo do Banco de Dados
O prximo passo elaborado foi a criao do modelo de banco de dados baseado no di-
agrama do modelo conceitual. A ferramenta utilizada para criar este modelo foi a DBDesigner
4, distribudo pela fabFORCE.net (2003). Esta ferramenta distribuda sobre a licena GPL,
ou seja, uma ferramenta de cdigo livre, e permite que se criem modelos atravs de digra-
mas para diversas bases de dados, incluindo bases innoDB do MySQL (2004). Na Figura 15 e
na Figura 16 so apresentados os modelos utilizados na ferramenta a ser criada.
Para a ferramenta a ser criada foi escolhida a base de dados MySQL, juntamente com
o tipo de base MyISAM, que rene um bom balano entre funcionalidade e rapidez de proces-
samento. A partir da escolha da base de dados foi possvel atravs da ferramenta DBDesigner
gerar as querys que iro criar a estrutura da base. O resultado deste processo pode ser visuali-
zado no Apndice 3.
58

Figura 15 Modelo do banco com os gerenciveis, manuteno e dados gerados

Para armazenar os dados coletados, so utilizadas tabelas no banco de dados, estes da-
dos so gravados de forma diferenciada para cada tipo de dados. No caso dos erros, apenas
uma nova linha do banco adicionada quando o valor da coleta for diferente do valor anterior,
e quando isto ocorre marcado o horrio do evento. J na tabela de disponibilidade so ar-
mazenados perodos em que houve uma queda, funcionando da seguinte maneira: se for veri-
ficado que o status mudou (estava indisponvel, agora est disponvel) armazenado que o
status mudou juntamente com o horrio da mudana. Mas este tipo de tabela s utilizado por
interfaces, para dispositivos a latncia j realiza o papel de armazenamento, pois alm do va-
lor do tempo de resposta, armazenada a alcanabilidade, logo se esta indicar que no foi
possvel contatar o dispositivo, considerado que o dispositivo est indisponvel.
59
Na Figura 16 apresentado separadamente as tabelas de acordo. Em destaque nova-
mente a abstrao de tipo na base, onde ser possvel adicionar neste caso mais acordos sem
alterar o grupo de objetos gerenciveis que estaro includos no acordo.

Figura 16 Modelo do banco com os acordos

Diagramas de Sequncia
Os diagramas de seqncia, tambm chamados de diagrama de interao, do detalhes
de ordem de como o funcionamento interno de funes chamadas por atores. Neste processo
so estabelecidas as responsabilidades dos objetos, e como eles iro se interagir. Na Figura 17
esto apresentadas as principais seqncias de interaes do autmato. Nessa figura apre-
sentado que depois de buscar os objetos gerenciveis, ele realiza a funo de estabelecer as
60
interfaces, e de buscar dados de disponibilidade, estas duas aes so chamadas de modo que
o sistema no fica aguardando a sua concluso de uma para continuar seu processando.
Como o estabelecimento de interfaces leva alguns segundos e depende dos dispositivo,
ele feito de modo paralelo entre os dispositivos, assim um dispositivo que esteja com tempo
de resposta menor no ir ser afetado por outro mais lento. Aps o processo de estabeleci-
mento de interfaces, o Autmato avisado atravs do padro de projeto Observer que um
dispositivo ficou pronto, e parte para realizar mais duas funes, como ilustra o digrama na
Figura 18. Novamente esta tarefa feita de forma que cada interface e atributo so verificados
de forma paralela.
61

Figura 17 Diagrama de sequncia bsico do autmato
62

Figura 18 Diagrama de sequncia do mtodo do padro Observer

Outra figura importante no autmato de coleta de dados o Monitor, este apresentado
na Figura 18. Esse tem a funo de receber diversos trabalhos (Work) e realizar-los de forma
que seu nmero limitado de trabalhadores (Worker) seja utilizado. Caso todos os trabalhado-
res estejam ocupados, o trabalho adicionado num fila de espera e executado assim que um
trabalhador estiver livre. Esta ordenao de fatos ocorre, pois criar trabalhadores, que so T-
hreads, e aps o seu uso jogar fora e depois criar um novo trabalhador quando necessrio cau-
sa uma grande sobre-carga no sistema de escalonamento de Threads.
A Figura 19 demonstra o comportamento bsico do DeviceFactory, classe responsvel
em buscar no banco de dados as informaes de todos os dispositivos cadastrados e transfor-
mar em objetos que sero futuramente acessados pelo autmato para fazer as verificaes. A
figura ainda destaca o comportamento do banco de dados, que apenas um para o sistema
todo, sendo utilizado o padro de projeto Singleton. Todas as aes que so realizadas apenas
63
podem ser realizadas uma por vez no banco. Assim possvel com apenas uma conexo ao
banco realizar diversas aes, uma seguida da outra.

Figura 19 Diagrama de seqncia do DeviceFactory

64
5.4 Interface WEB da ferramenta
Iremos agora apresentar as principais interfaces da ferramenta escrita usando XHTML,
CSS e PHP, sendo que em cada uma buscamos apresentar a tecnologia por trs da interface. A
Figura 20 apresenta a interface bsica para toda a ferramenta, como caracterstica marcante
est o uso extensivo de estilos em folhas de estilos (CSS), sendo que 50% dos dados que fo-
ram baixados para gerar esta pgina esto relacionados ao estilo. Na prxima pagina a ser
carregada pelo usurio o navegador ir verificar se houve mudana no estilo, e como no
houve ele no ir mais baixar o estilo, isto faz com que pginas visualmente agradveis pos-
sam ser apresentadas sem demora. Na Figura 21 a mesma interface inicial apresentada, mas
sem o estilo aplicado, ela mostra que alm de detalhes de cor e fonte as folhas de estilo ainda
esto controlando o posicionamento de elementos.

Figura 20 Tela inicial do ambiente de monitorao
65

Figura 21 Pgina inicial carregada sem estilo
Na Figura 22 est apresentado o primeiro passo no assistente de adio de interfaces
em dispositivos. Neste passo o usurio escolhe quais dados deseja capturar juntamente com a
lista de interfaces em um dispositivo. Estas opes alm de ajudar o usurio a escolher corre-
tamente a interface que deseja adicionar, iro preparar para a descrio que ser adicionada na
interface, quanto mais dados coletados melhores sero a descries das interfaces que o sis-
tema ir adicionar automaticamente.
Ao ser submetido o formulrio do assistente, uma barra de progresso ilustrada na
Figura 23, ir ajudar o usurio a verificar o andamento do processo de captura de interfaces de
dispositivos. Esta captura feita atravs de chamadas de SNMP Walk de cada atributo que o
usurio escolheu capturar, e este tipo de chamada implementado pela prpria linguagem
PHP. O tempo de espera ir depender do nmero de interfaces, e da qualidade da linha de
transmisso at o dispositivo cadastrado, um Switch de 24 portas na mesma rede que o siste-
66
ma web leva 3 segundos, j um roteador com mais de mil interfaces leva em mdia 26 segun-
dos.

Figura 22 Primeiro passo do assistente de adio de interfaces

Figura 23 Barra de progresso do processo de captura de interfaces.

Na Figura 24 apresentada a interface para o controle de objetos que sero includos
em um acordo. Esta interface permite a visualizao atravs de menu no estilo de rvore visu-
alizar os objetos gerenciveis cadastrados at o momento, sendo que as interfaces so agrupa-
das nos dispositivos a ele relacionadas. Para incluir ou remover um objeto de um acordo, o
usurio seleciona ou retira a seleo dele, e a presena ou no de uma caixa de seleo (check
box) depende do tipo de acordo. A exemplo de disponibilidade, que pode ser verificada para
67
dispositivos e interfaces, estes podero ser selecionados na rvore, j um acordo de tempo de
resposta, que s pode ser verificado em dispositivos, apenas este podero ser selecionados
como mostra a Figura 24.

Figura 24 Configurao de objetos em um acordo

Para controle das interfaces cadastradas, a Figura 25 demonstra como elas so apre-
sentadas no sistema. As manutenes so divididas em dois grupos, as futuras e as passadas, e
em cada item apresentado um sumrio da manuteno. Quando uma manuteno cadastra-
da a mesma ir afetar dados gerados no relatrio, com o objetivo de excluir dados coletados
durante o tempo de manuteno. O controle de objetos que sero ou no includos na manu-
teno feito do modo anlogo ao apresentado para o controle de objetos no acordo ilustrado
na Figura 24, mas neste caso todos os objetos podem ser selecionados.

68

Figura 25 Lista de manutenes cadastradas

Como interface de maior destaque encontra-se os relatrios referentes aos acordos ca-
dastrados. Todos possuem um navegador de datas que ser analisado, e o perodo mostrado
entre as opes depender do perodo do acordo estipulado no cadastro. A Figura 26 apresenta
o navegador dirio e semanal respectivamente. Como maiores destaques nos relatrios, alm
do sumrio do resultado obtido esto os grficos que auxiliam na interpretao de dados do
relatrio.

Figura 26 Navegador de datas para o relatrio
69
Cabe ressaltar que todas as informaes geradas para o relatrio so processadas na
requisio do mesmo, sendo que no h uma sobre carga com criao de estatsticas que no
sero acompanhadas por nenhum usurio. Estas informaes podem ser replicadas, e podem
ser coletadas independentes do perodo selecionado. Entre os processamentos dos dados cole-
tados para a gerao de relatrios, o que possui o maior destaque o relacionado disponibi-
lidade. Esta anlise gerada atravs do calculo resultante da equao apresentada na Figura
27, que inclui trs variveis de tempo:
Tinativo: Tempo de inatividade, detectado pelo autmato de coleta;
TinativoManutencao: Tempo em que foi detectado pelo autmato que o obje-
to estava inativo, mas neste perodo o mesmo se encontrada em uma manuten-
o programada na interface;
Ttotal: Tempo total de verificao de disponibilidade para o objeto.

Figura 27 Equao do clculo da porcentagem de disponibilidade

Primeiramente os relatrios de latncia que so caracterizados por dados que so co-
lhidos em intervalos regulares, e logo cada ponto no grfico que ser gerado significa uma
coleta. A Figura 28 apresenta um grfico onde os dados de tempo de resposta do dispositivo
so apresentados de forma que o eixo das abscissas representa o perodo relacionado no acor-
do, e o eixo das ordenadas representa os resultados das coletas de tempo de resposta em mili-
segundos.

)
) (
100.(1
total
utencao inativoMan inativo
idade Disponibil

=
70

Figura 28 Grfico de latncia sem recursos

Figura 29 Grfico com recurso de manuteno e de limite de acordo

Para ilustrar o funcionamento do grfico em situaes adversas, a Figura 29 demonstra
dois novos elementos para a Figura 28. O primeiro a barra vermelha horizontalmente dis-
posta no grfico, que representa o valor mximo estipulado no acordo cadastrado. Esta mostra
claramente que houve dois momentos em que os dados superaram este valor mximo. No en-
tanto, neste perodo houve uma manuteno agendada que apresentada no grfico como uma
barra vertical verde no perodo em que houve a manuteno. Pode ser observado que o valor
mximo referente ao dispositivo foi afetado por esta manuteno.
A Figura 30 ilustra um relatrio bsico de erros. Nele pode-se observar o campo de
sumrio do acordo, com o valor que foi estipulado no cadastro do acordo, e o valor que foi
coletado no perodo. Tambm se verifica uma certa similaridade com o grfico de latncia,
71
mas neste grfico cada ponto do grfico representa alguma modificao na varivel de erros
da interface. O valor de erros armazenado de forma que s acrescido mais dados na tabela
de erros quando o valor coletado for diferente do anterior, e como esta varivel de erros do
tipo Gauge do SNMP, pode ocorrer volta ao nmero zero, e quem controla este comporta-
mento a ferramenta que gera os relatrios.

Figura 30 Grfico de erros em interface

Para os relatrios de disponibilidade existe uma diferenciao na forma em que o gr-
fico representado. A Figura 31 mostra o grfico gerado de uma interface em um acordo de
disponibilidade em um perodo do acordo. Neste caso as barras vermelhas na linha do tempo
representam quedas, e o tamanho de cada representa a durao da mesma. Outro elemento a
barra verde que se sobrepem a queda indica novamente uma manuteno programada, e a
disponibilidade gerada no conta o perodo onde houve esta.
72

Figura 31 Relatrio de disponibilidade de uma interface

Neste captulo foi apresentado o ambiente de monitorao SLA criado para este traba-
lho, juntamente com detalhes de projeto que so importantes para futuras manutenes e ex-
panses do ambiente.
6. Concluso
Com o estudo de gerncia de redes e de acordos de nvel de servios, foi possvel neste
trabalho desenvolver um ambiente que seguia os requisitos necessrios para um primeiro es-
tgio do mesmo. Espera-se que com esta ferramenta administradores de rede possam facil-
mente implementar em seu ambiente um gerenciamento de nvel de servios em sua organiza-
o, j que o principal obstculo na criao deste est no encontro de uma ferramenta adequa-
da.
Foi verificado tambm que para implementar acordos de nvel de servios existe uma
certa dedicao, e que apenas uma ferramenta no poder reduzir esta tarefa a zero. Conside-
ra-se que administradores devem primeiro analisar seus servios, verificar qual o nvel de
servio que est sendo oferecido, e neste processo a ferramenta ser til. Porm a partir disso
comea o dilogo com o cliente com objetivo de estipular um acordo que ambas as partes
fiquem satisfeitas. Depois ainda existe a necessidade da efetivao do acordo com um contra-
to. S depois desta etapa a ferramenta pode ser utilizada.
Em suma, a ferramenta se limita no objetivo de coletar as informaes de forma confi-
vel e rpida, e partir disso criar relatrios teis para o administrador e para o cliente ter a
informao sobre o acordo firmado. No entanto organizaes que desejam implementar estes
acordos devem se dedicar ao estudo principalmente s armadilhas que estes podem causar.
6.1 Trabalhos Futuros
Para trabalhos futuros baseados neste ambiente se sugere certas adies e/ou melho-
ramentos:
A implementao de novos objetos gerenciveis, como servios rodando em
um servidor;
A adio de novos dados a serem coletados numa interface, como banda pas-
sante;
74
Refinamento do relatrio gerado, com nveis diferentes de dados informados
dependendo do nvel do usurio (cliente ou administrador);
Possibilidade de verificar relatrios de tempo real, onde se apresenta uma ex-
pectativa de se acordo vai ou no ser cumprido baseado nos dados atuais;
Criao de relacionamento de dispositivos a uma lista de contatos, e apresentar
aos integrantes dessa os relatrios destinados aos clientes;
A adio de envios de alertas caso seja verificado em um determinado momen-
to que baseados nos dados correntes o acordo poder ser quebrado.

7. REFERENCIAS BIBLIOGRFICAS

ASSUNO, M. D. Re: [gers] [mensagem pessoal]. Mensagem recebida por faria
inf.ufsc.br, em 4 maro 2004.
BLACK, Uyless. Network Management Standarts: SNMP, CMIP, TMN, MIBs, and object
libraries. McGraw-Hill, 1994. 351 p.
BLUM, Rick. Service Level Management and Service Level Agreements. Pesquisa reali-
zada para International Network Services. 2002. Disponvel em:
<http://www.ins.com/downloads/surveys/sv_slm_sla_0302.pdf> acesso em 15 agosto 2003.
BOOCH, Grandy; RUMBAUGH, james; JACOBSON, Ivar. UML, Guia do Usurio. Tradu-
o Fbio Freitas da Silva. Rio de Janeiro: Campus, 2000. 471 p.
BOUTELL.com, Inc. GD Graphics Library. Disponvel em: <http://www.boutell.com/gd>
acesso em 10 abril 2004.
CARVALHO, Tereza Cristina Melo de Brito. Arquitetura de redes e computadores OSI e
TCP/IP. 2 edio. So Paulo: Makron Books, 1997, 695 p.
DEITEL, H. M.;DEITEL, P. J. Java, Como Programar. Traduo de Edson Furmankiewick.
3 Edio. Porto Alegre: Bookman, 2001. 1201 p.
DRR, Sven. JMGMT : Free Java SNMP Stack with Servlet and Agent Framework.
1999. Disponvel em: <http://i31www.ira.uka.de/~sd/manager/jmgmt> acesso em 10 abril
2004.
DUBIE, Denise. What users want from SLM software. Network World, 24/03/03. Dispon-
vel em: <http://www.nwfusion.com/news/2003/0324wishlist.html> acesso em 15 agosto
2003.
76
DUKART, James R. . E-Commerce Growth Makes Service Level Agreements Critical.
PHONE+ Journal. Edio 05/2000. Disponvel em:
<http://www.phoneplusmag.com/articles/051premi.html> acesso em 10 abril 2004.
FABFORCE. Online Documentation. 2003. Disponvel em:
<http://www.fabforce.net/dbdesigner4/doc/index.html> acesso em 2 de abril 2004.
FLANAGAN, David. Java in a Nutshell. 2 Edio. OReilly: 1997. 628 p. Disponvel em:
<http://www.sniffer.net/bookshelf_do_sniffer/java/javanut> acesso em 15 agosto 2003.
HERMAN, Ivan. About the World Wide Web Consortium (W3C). Documentao eletr-
nica. 2000. Disponvel em: <http://www.w3.org/Consortium>. Acesso em 8 dezembro 2003.
JpGraph - OO Graph Library for PHP. Disponvel em: <http://www.aditus.nu/jpgraph>
acesso em 2 de abril 2004.
LARMAN, Craig. Utilizando UML e Padres. Uma Introduo Anlise e ao Projeto
Orientado a Objetos. Traduo de Luiz Augusto Meirelles Salgado. Porto Alegre: Bookman,
2000.
MARTINS, Marcelino. Treeview Javascript tree menu. Disponvel em: <http://www.
http://www.treeview.net> acesso em 1 maio 2004.
MULLER, Nathan J. Managing Service Level Agreements. International Journal of Net-
work Management, volume 9, 3 edio, p. 155-166. 1999. Disponvel em:
<http://portal.acm.org/citation.cfm?id=336747> acesso em 10 abril 2004.
MYSQL AB. MySQL Reference Manual. Documentao eletrnica, 2004 Disponvel em:
<http://dev.mysql.com/doc/> acesso em 2 de abril 2004.
NAGIOS. Disponvel em: <http://www.nagios.org> acesso em 1 maio 2004.
NMIS. Disponvel em: <http://www.sins.com.au/nmis> acesso em 1 maio 2004.
PACHEV, Alexander Sasha. MySQL Enterprise Solutions. Indianapolis: Wiley Publishing,
2003. 398p.
77
PERKINS, David; MCGINNIS, Evan. Understanding SNMP MIBs. Pratice-Hall, 1997. 509
p.
SCHWEITZER, Chiristiane Marie. Informaes de Desempenho e Acordos de Nvel de
Servio para Redes de Transporte PDH e SDH. 1999. 114f. . Dissertao (Mestrado em
Cincias) Ps-Graduao em Engenharia Eltrica e Informtica Industrial, Centro Federal
de Educao Tecnolgica do Paran, Curitiba.
SOARES, Walace. Programando em PHP: Conceitos e Aplicaes. So Paulo: rica, 2000.
386 p.
STALLINGS, William. SMNP, SNMPv2, SNMPv3, and RMON 1 and 2. 3 edio. Addi-
son Wesley Longman, 1999. 619 p.
STURM, Rick. Searching for SLM tools. Network World Network Systems Management
Newsletter, 24/09/01. Disponvel em:
<http://www.nwfusion.com/newsletters/nsm/2001/01022535.html> acesso em 15 agosto
2003.
STURM, Rick; MORRIS, Wayne; JANDER, Mary. Service Level management: fundamen-
tos do gerenciamento de nveis de servio. Traduo de Teresa Cristina Flix de Souza. Rio
de Janeiro : Campus, 2001. 272 p.
Whats Up. Disponvel em: <http://www.ipswitch.com> acesso em 1 maio 2004.
Apndice

7.1 APNDICE A Cdigo fonte do autmato

< incluir cdigo.doc >
br\ufsc\ine\nsla\Automaton.java
/*
* Criado em 29/03/2004
*
*/

79
7.2 APNDICE B Cdigo fonte da interface WEB
< incluir cdigo.doc >

80
7.3 APNDICE C Estrutura do banco de dados

# Host: localhost Database: nsla
# --------------------------------------------------------
# Server version 4.1.0-alpha-max-debug

USE nsla;

#
# Table structure for table 'acordo_aco'
#

DROP TABLE IF EXISTS acordo_aco;
CREATE TABLE acordo_aco (
cd_acordo_aco int(10) unsigned NOT NULL auto_increment,
nu_dias_aco int(10) unsigned default NULL,
dc_descricao_aco varchar(80) default NULL,
PRIMARY KEY (cd_acordo_aco)
) TYPE=MyISAM CHARSET=latin1;

#
# Table structure for table 'acordo_dpo_apd'
#

DROP TABLE IF EXISTS acordo_dpo_apd;
CREATE TABLE acordo_dpo_apd (
cd_acordo_aco int(10) unsigned NOT NULL default '0',
fl_min_apd float default NULL,
fl_critico_apd float default NULL,
PRIMARY KEY (cd_acordo_aco),
KEY acordo_dis_adi_FKIndex1 (cd_acordo_aco)

#
# Table structure for table 'acordo_err_aer'
#

DROP TABLE IF EXISTS acordo_err_aer;
CREATE TABLE acordo_err_aer (
nu_max_aer int(10) unsigned NOT NULL default '0',
nu_critico_aer int(10) unsigned default NULL,
KEY acordo_err_aer_FKIndex1 (cd_acordo_aco)

#
# Table structure for table 'acordo_lat_ala'
#

DROP TABLE IF EXISTS acordo_lat_ala;
CREATE TABLE acordo_lat_ala (
fl_maxmed_ala float default NULL,
fl_criticomed_ala float default NULL,
fl_max_ala float default NULL,
KEY acordo_lat_ala_FKIndex1 (cd_acordo_aco)
81

#
# Table structure for table 'agrupo_agr'
#

DROP TABLE IF EXISTS agrupo_agr;
CREATE TABLE agrupo_agr (
cd_gerenciado_ger int(10) unsigned NOT NULL default '0',
PRIMARY KEY (cd_acordo_aco,cd_gerenciado_ger),
KEY agrupo_agr_FKIndex1 (cd_acordo_aco),
KEY agrupo_agr_FKIndex2 (cd_gerenciado_ger)

#
# Table structure for table 'disponibilidade_dpo'
#

DROP TABLE IF EXISTS disponibilidade_dpo;
CREATE TABLE disponibilidade_dpo (
dt_data_dpo datetime NOT NULL default '0000-00-00 00:00:00',
cd_status_dpo tinyint(3) unsigned default NULL,
PRIMARY KEY (dt_data_dpo,cd_gerenciado_ger),
KEY disponibilidade_dpo_FKIndex1 (cd_gerenciado_ger)

#
# Table structure for table 'dispositivo_dis'
#

DROP TABLE IF EXISTS dispositivo_dis;
CREATE TABLE dispositivo_dis (
cd_origem_ger int(10) unsigned default NULL,
lt_host_dis varchar(15) default NULL,
lt_comuniget_dis varchar(255) default NULL,
lt_comuniset_dis varchar(255) default NULL,
PRIMARY KEY (cd_gerenciado_ger),
KEY dispositivo_dis_FKIndex1 (cd_gerenciado_ger),
KEY dispositivo_dis_FKIndex2 (cd_origem_ger)

#
# Table structure for table 'erro_ifa_err'
#

DROP TABLE IF EXISTS erro_ifa_err;
CREATE TABLE erro_ifa_err (
dt_data_err datetime NOT NULL default '0000-00-00 00:00:00',
nu_erros_err int(10) unsigned default NULL,
PRIMARY KEY (dt_data_err,cd_gerenciado_ger),
KEY erro_ifa_err_FKIndex1 (cd_gerenciado_ger)

#
# Table structure for table 'gerenciado_ger'
82
#

DROP TABLE IF EXISTS gerenciado_ger;
CREATE TABLE gerenciado_ger (
dc_descricao_ger varchar(80) default NULL,
PRIMARY KEY (cd_gerenciado_ger)

#
# Table structure for table 'interface_ifa'
#

DROP TABLE IF EXISTS interface_ifa;
CREATE TABLE interface_ifa (
cd_dispositivo_dis int(10) unsigned NOT NULL default '0',
lt_ifdescr_ifa varchar(100) default NULL,
PRIMARY KEY (cd_gerenciado_ger),
KEY interface_ifa_FKIndex1 (cd_gerenciado_ger),
KEY interface_ifa_FKIndex2 (cd_dispositivo_dis)

#
# Table structure for table 'latencia_lat'
#

DROP TABLE IF EXISTS latencia_lat;
CREATE TABLE latencia_lat (
dt_data_lat datetime NOT NULL default '0000-00-00 00:00:00',
nu_latencia_lat float NOT NULL default '0',
nu_alcanca_lat smallint(5) unsigned NOT NULL default '0',
PRIMARY KEY (dt_data_lat,cd_gerenciado_ger),
KEY latencia_lat_FKIndex1 (cd_gerenciado_ger)

#
# Table structure for table 'manutencao_man'
#

DROP TABLE IF EXISTS manutencao_man;
CREATE TABLE manutencao_man (
cd_manutencao_man int(10) unsigned NOT NULL auto_increment,
dt_inici_man datetime NOT NULL default '0000-00-00 00:00:00',
dt_final_man datetime NOT NULL default '0000-00-00 00:00:00',
dt_criacao_man datetime NOT NULL default '0000-00-00 00:00:00',
dc_motivo_man varchar(255) default NULL,
PRIMARY KEY (cd_manutencao_man)

#
# Table structure for table 'mgrupo_mgr'
#

DROP TABLE IF EXISTS mgrupo_mgr;
CREATE TABLE mgrupo_mgr (
cd_manutencao_man int(10) unsigned NOT NULL default '0',
PRIMARY KEY (cd_manutencao_man,cd_gerenciado_ger),
83
KEY mgrupo_mgr_FKIndex1 (cd_gerenciado_ger),
KEY mgrupo_mgr_FKIndex2 (cd_manutencao_man)

Ambiente de Monitoração de Sla para Redes

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ambiente de Monitoração de Sla para Redes

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE FEDERAL DE SANTA CATARINA

JOS CARLOS GONTARCZYK FARIA

S-ar putea să vă placă și