1. Identificação
Giovane César Moreira Moura
Escola de Engenharia Elétrica e de Computação, UFG.
4º Ano de Engenharia de Computação
Matrícula: 012826
Professor Orientador: Prof. Msc. Marcelo Stehling de Castro
Local de estágio: Ponto de Presença da Rede Nacional de Ensino e
Pesquisa em Goiás (PoP-GO RNP), sediado no prédio da UFGNET no Campus
1, Escola de Engenharia.
Data do estágio: 01 de março de 2004 até 28 de fevereiro de 2005.
Total de horas semanais: 30 horas.
Total de Horas em todo o período: 1560 horas.
2. Introdução
2.1 Sobre a RNP e o PoP-GO
A RNP foi criada em setembro 1989 pelo Ministério da Ciência e
Tecnologia (MCT) com o objetivo de construir uma infra-estrutura de rede
Internet nacional de âmbito acadêmico. A Rede Nacional de Pesquisa, como
era chamada em seu início, tinha também a função de disseminar o uso de
redes no país. Em paralelo à implantação de sua estrutura, a RNP dedicouse a tarefas diversas, tais como divulgar os serviços Internet à comunidade
acadêmica através de seminários, montagem de repositórios temáticos e
treinamentos, estimulando a formação de uma consciência acerca de sua
importância estratégica para o país e tornando-se referência em aplicação
de tecnologias Internet.
Em maio de 1995, teve início a abertura da Internet comercial no país.
Neste período, a RNP passou por uma redefinição de seu papel, estendendo
seus serviços de acesso a todos os setores da sociedade. Com essa
reorientação de foco, a RNP ofereceu um importante apoio à consolidação
da Internet comercial no Brasil. Foi criado o Centro de Informações
Internet/BR para dar suporte no surgimento de provedores e usuários da
rede. Mais de 3.000 questões relativas à Internet foram respondidas em seu
primeiro ano de funcionamento. Inúmeras empresas fabricantes de bens de
informática, tais como Compaq, Equitel, IBM, Philips etc., passaram a
oferecer apoio concreto à RNP, fornecendo equipamentos, software e,
mesmo, financiando atividades diretas do projeto.
Em outubro de 1999, dez anos depois de ser criado o projeto RNP, os
ministérios da Ciência e Tecnologia e da Educação (MEC) assinaram um
1
convênio, o Programa Interministerial de Implantação e Manutenção da Rede
Nacional para Ensino e Pesquisa (PI-MEC/MCT), com o objetivo de levar a
rede acadêmica a um novo patamar. Os dois ministérios investiriam R$ 215
milhões na implantação e manutenção do backbone RNP2, uma infraestrutura de rede avançada, capaz de atender às novas necessidades de
banda e de serviços para ensino e pesquisa. A Associação Rede Nacional de
Ensino e Pesquisa (AsRNP), criada neste mesmo ano pelos funcionários da
RNP, conduziria o programa, sob orientação de um Comitê Gestor (CG-RNP)
formado por representantes do MEC e do MCT. O backbone RNP2 foi
oficialmente inaugurado em maio de 2000.
Em janeiro de 2002, a AsRNP foi qualificada pelo governo federal
como uma Organização Social. Com isso, ganhou maior autonomia
administrativa para executar suas tarefas e o poder público ganhou meios
de controle mais eficazes para avaliar e cobrar o alcance dos objetivos
traçados para a organização.
Em 26 de março de 2002, a Organização Social Rede Nacional de
Ensino e Pesquisa (RNP/OS) firmou um contrato de gestão com o MCT. Nele,
a RNP/OS se predispõe a atingir determinadas metas, visando ao fomento
das atividades de pesquisas tecnológicas em redes de desenvolvimento e à
operação de meios e serviços de redes avançadas que beneficiem a pesquisa
e o ensino nacionais.
Já o PoP-GO (Point of Presence) é o ponto de presença da RNP em
Goiás. Nada mais é que uma extensão da RNP em Goiás que assegura o
funcionamento da estrutura da RNP em Goiás, garantindo a operação de
qualidade da rede interligando as instituições participantes a internet.
2.2 Sobre este relatório
A parte técnica deste relatório foi feito nos moldes de um tutorial,
para que posso ser utilizado por um muito mais pessoas que tiverem
acesso.
3. Atividades realizadas
As atividades realizadas no PoP-GO durante o período que estagiei
podem ser divididas em três categorias:
•
Atividades rotineiras de hardware/software
•
Projeto de Monitoramento
•
Pesquisa em Multimídia sobre IP
Nas seções abaixo descreverei melhor cada uma das três categorias.
2
3.1 Atividades rotineiras de hardware/software
Essas atividades são caracterizadas por instalação/manutenção de
software no maquinário do PoP-GO, manutenção de hardware e cabeamento
estruturado.
Vale salientar que sempre utilizei exclusivamente software livre em
todas as atividades e projetos que realizei no PoP.
Dentro os softwares instalados, inclui-se o sistema operacional
Slackware/Linux, servidor web Apache httpd e softwares de produção, com
OpenOffice e softwares de usuário. Aqui não considero a instalação dos
softwares que foram usados exclusivamente no projeto de monitoramento,
pois esses serão mais detalhados na seção 3.3.
Devido a experiência que eu já possuía nesta área, instalação de
software em GNU/Linux não representou grande desafio, motivo pelo qual a
descrição dessa atividade será bem resumida neste relatório(deixando para
o projeto de monitoramento uma melhor documentação). Entre outras
atividades inclui o monitoramento do desempenho e resposta das
máquinas, verificação de logs e tentativas de acesso não autorizado. Foi
notado em logs do Slackware Linux várias tentativas de acesso via ssh onde
diversas combinações de nomes e senhas provenientes de diversos países
eram tentadas, sempre sem sucesso devido a política de senhas usada. A
RNP tem uma rede bastante visada do ponto de vista de invasores, portanto
trabalhar numa rede dessas oferece capacidade de aprender bastante com
tantas tentativas.
Em relação a hardware, foi feito algumas manutenções no maquinário
do PoP, como por exemplo abrir uma máquina com problema na bios.
No que se refere a atividades rotineiras em redes, realizei atividades
para testar switches, acompanhei configuração de linhas SLDD para
interconexão do PoP-GO com o prédio da Caixa Econômica Federal
localizado na Avenida Anhangüera. Essa conexão foi necessária para a
transmissão para internet de um evento realizado na Caixa. Mais atividades
foram realizadas no projeto de monitoramento. Também acompanhei o
Coordenador Técnico do PoP, Cláudio Garcia, na configuração de switches
IBM e NEC. Outras vezes com o bolsista Frederico Rodrigues acompanhei
tais configurações.
Também fui algumas vezes ao prédio da Brasil Telecom onde o PoPGO tem uma sala técnica onde ficam equipamentos de rede conectando a os
dois campus da UFG e a REMAV.
3.2 Projeto de Monitoramento
A origem deste projeto foi a necessidade de um relatório. Uma
experiência que mostrou que apenas um relatório pode exigir um projeto
inteiro. E a partir da entrega deste relatório, continuei o projeto estendendo
3
para um uso diversificado.
O relatório exigido surgiu a partir de um problema detectado. O PoPGO é fisicamente ligado ao PoP-DF (Ponto de Presença de RNP no DF) via
uma conexão ATM alugada de uma operadora de telefonia(contrato anual,
onde todo ano Brasil Telecom e Embratel concorrem pelo link). No ano de
2004 a empresa que fornecia o link era então a Brasil Telecom. Detectamos
que quando um usuário de dentro da rede do PoP-GO tentava acessar um
site hospedado em Goiás (exemplo: Detran-GO – www.detran.go.gov.br ) os
pacotes deste usuário saiam do PoP-GO e iam até Curitiba-PR para então
voltarem para Goiânia. Era dada uma volta muito grande dos pacotes pelo
país, ocasionando um pior desempenho para o usuário final e uma
sobrecarga desnecessária aos demais enlaces da RNP (DF,RJ e PR) para
rotear pacotes que poderiam ter ficado dentro do estado de GO mesmo.
Para solucionar este problema, foi pensado um projeto de Ponto de Troca de
Tráfego (considera-se como Ponto de Troca de Tráfego Internet - PTT, uma
rede eletrônica de alta velocidade ou estrutura equivalente, onde diversas
redes se conectam por meio de roteadores IP com o propósito de troca de
tráfego) para solucionar este problema. E este PTT seria entre o PoP-GO e a
concessionária Brasil Telecom. Como um PTT é um conceito implementado
em roteadores de borda(no nosso caso um CISCO 7500), e isso exigiria do
roteador um maior uso de memória, por nosso lado fez-se a necessidade de
saber quanto de tráfego da nossa rede (PoP-GO) se destinava a rede da
Brasil Telecom (entenda-se todos os clientes da Brasil Telecom , incluindose usuários de ADSL,empresas que contratam link da concessionária, o
governo, e etc..) e quanto do tráfego que entrava em nossa rede vinha da
rede da Brasil Telecom (precisa-se de haver uma demanda para
implementar um projeto destes).
Como obter esses dados? Para explicar melhor, é necessário mostrar
a topologia do PoP-GO na figura 1:
Figura 1: Topologia Lógica do PoP-GO
4
Esta figura representa a topologia lógica em alto nível do PoP-GO
(sem considerar a REMAV Goiânia, a qual seu tráfego fica apenas dentro da
rede do PoP-GO, não passando para a internet). Percebe-se que o PoP-GO
conecta UFG, Embrapa,CEFET,Sectec e a secretaria municipal de Educação a
internet. E para o tal, todo o tráfego destes clientes vai para um conjunto de
switches (representado pelo switch maior) e então todo tráfego passa pelo
roteador de borda Cisco 7500. Ou seja, basta apenas monitorar todo o
tráfego por um ponto da rede, o roteador de borda. Se um aluno da UFG de
dentro da UFG tenta acessar, por exemplo, o site www.detran.go.gov.br (que
pertence a rede Brasil Telecom) , esses dados passam pela rede da UFG
inteira até culminar no Cisco 7500. E lá conseguimos também monitorar o
quanto de tráfego de entrada da Brasil Telecom acessa nossa rede. Uma
analogia seria como se o Cisco 7500 fosse uma ponte que liga uma ilha
(rede do PoP-GO) a um continente(Internet).
Já detectamos onde monitorar, porém ficou em aberto a questão:
como? Daniel Chaffe Stone, responsável por toda Rede da UFG,juntamente
com o coordenador técnico do PoP-GO,Cláudio Garcia, sugeriram o uso da
tecnologia Cisco IOS Netflow.
Cisco IOS Netflow é um software que roda no roteador Cisco 7500 do
PoP-GO que provê um conjunto chave de serviços para aplicações
IP,incluindo contagem de tráfico de rede, billing baseado no uso da rede
(por exemplo, monitorar quanto de download um determinado IP realizou –
como as operadoras que provem serviço ADSL monitoram quanto casa
usuário usa), permitem um maior planejamento da rede, maior segurança,
monitoramento de DoS e monitoramento da rede em questão. Podemos
extrair diversas informações, sobre os usuários da rede e quais aplicativos
estão usando, horário de pico, roteamento.
O funcionamento do Netflow é basicamente o seguinte: o roteador
(ou switch, porém no nosso caso é o Cisco 7500 da figura 1) coleta os fluxos
de dados (que são “logs” dos pacotes que entram e saem do roteador) que
passam por suas interfaces e prepara os dados para serem exportados.
Desses fluxos ele acumula dados com características únicas,como endereço
IP, aplicação, CoS. Então esses dados condensados são exportados para um
coletor que os recebe,armazena e então analisa (no nosso caso, utilizamos
uma estação IBM Netfinity PIII 550Mhz para coleta de dados utilizando
Slackware Linux. O software de coleta chama-se flow-tools, que é um
conjunto de ferramentas livres). A título de ilustração, no PoP-GO
coletávamos cerca de 350MB/dia. É um volume expressivo de dados, que na
verdade são “brutos” e precisam ser tratados por softwares para se extrair a
informação desejada.
Como o Netflow coleta os fluxos e sumariza usando IP, poderíamos
aplicar regras na análise dos dados coletados e dizer: “queremos saber qual
a porcentagem dos dados que passam pelo nosso roteador vão para a rede
da Brasil Telecom e qual a porcentagem dos dados de entrada que vem de
lá”, apenas informando ao nossa ferramenta de análise (flow-tools) quais
faixas de endereços IPs pertenciam a rede Brasil Telecom.
5
A partir deste momento bastava apenas implementação do projeto.
Essa parte trabalhei bastante lendo documentação em sites na web e
consegui obter os resultados esperados.
Para obter o relatório em questão, deixaríamos coletando dados 37
dias (para termos uma melhor espaço amostral) e nossas estatísticas mais
realistas. O que fizemos basicamente para coletar os dados foi o seguinte:
1. Pedir para o pessoal da administração da RNP no Rio de Janeiro
configurar remotamente o Cisco 7500 para exportar os dados
coletados pelo Netflow para nossa estação coletora (IBM PIII
550Mhz).
2. Configurar a estação para coletar os dados. Para isso, utilizamos o
seguinte comando:
#flow-capture -w /netflow -E20G <ip_estação_coletora>/0/9800
Este comando diz para o flow-capture(software integrante do flowtools) para coletar os dados do netflow e os armazenar na pasta /
netflow, num total de 20G (-E20G – quando este limite é atingido, os
dados mais antigos são sobrepostos) , na porta 9800.
3. Esperar o tempo de coleta
4. Analisar e entregar o relatório.
Esse relatório foi entregue dia 23/09/2004. Ele está disponível no
Anexo 1.
Descobrimos então que a Brasil Telecom respondeu por 17,64% dos
uploads e 11,65% dos downloads. Foi encaminhado o relatório aos
responsáveis, e até o momento que eu estive na RNP não houve outra
reunião com a Brasil Telecom.
Uma vez que a máquina a qual eu administrava (a máquina coletora)
ainda continuava a receber os dados do Netflow, decidi então ampliar o uso
da ferramenta para obter outras análises, uma extensão do projeto.
Essa extensão se basearia em:
a) Analisar os dados diariamente e extrair informações: Queria ter
informações diárias sobre o volume total de upload e download diário, e
também o tráfego de entrada e saídas nas portas 80(http), 20(ftp), 25
(snmp).
b) Que essa análise fosse automática, e gerasse gráficos todos os
dias.
c) Esses gráficos fossem disponibilizados no site do PoP-GO.
6
Para executar tal projeto, precisaria deixar a máquina coletora
sempre online recebendo fluxos de netflow, 24horas por dia, 7 dias por
semana, e então analisar e armazenar. Na verdade eu precisaria de um
conjunto de ferramentas livres para realizar tal tarefa. Já havia no mesmo
estágio instalado um software de monitoramento de rede chamado JFFNMS
( Just For Fun NMS), que na verdade era um site em PHP que coletava dados
via SNMP (simple network management protocol) , gerava gráficos e os
armazenava. Este mesmo software utilizada um conjunto de ferramentas
chamadas RRDTool para armazenar os dados e então gerar os gráficos, de
acordo com suas especificações. Então eu já sabia qual software utilizar
para gerar os gráficos, mas ainda não tinha extraído do flow-tools quais
dados seriam utilizados.
O que eu utilizei pode ser resumido na figura abaixo:
Figura 2: Hardware e software envolvido no projeto
No roteador não mexi em nada; apenas pedi ao pessoal do RJ para
programar o roteador para enviar dados do Netflow para minha estação IBM.
E era nela na verdade que o trabalho todo é executado. Depois de analisar
os dados e gerar os gráficos, é tudo transmitido via ssh com chave para o
servidor web do PoP-GO.
Nas próxima seção descreverei os aspectos técnicos envolvendo a
estação coletora.
3.3.1 Configuração da estação coletora
Para configurar a estação coletora, a primeira coisa é instalar o
pacote flow-tools. O tradicional configure, make e make install instalam o
software tranquilamente.
7
Feito a instalação como manda o desenvolvedor, execute o flowcapture para fazer sua máquina armazenar os dados vindos do roteador
(como foi dito anteriormente).
#flow-capture -w /netflow -E20G <ip_estação_coletora>/0/9800
Com esta linha é criado automaticamente uma estrutura de diretórios
dentro de /netflow separados por ano, mês e dia. E dentro do dia em
questão é que os arquivos dos fluxos são propriamente armazenados.
Veja como ficou nossa árvore de diretórios:
|-|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2004
|-- 2004-10
|
|-- 2004-10-01
|
|-- 2004-10-02
|
|-- 2004-10-03
|
|-- 2004-10-04
|
|-- 2004-10-05
|
|-- 2004-10-06
|
|-- 2004-10-07
|
|-- 2004-10-08
|
|-- 2004-10-09
|
|-- 2004-10-10
|
|-- 2004-10-11
|
|-- 2004-10-12
|
|-- 2004-10-13
|
|-- 2004-10-14
|
|-- 2004-10-15
|
|-- 2004-10-16
|
|-- 2004-10-17
|
|-- 2004-10-18
|
|-- 2004-10-19
|
|-- 2004-10-20
|
|-- 2004-10-21
|
|-- 2004-10-22
|
|-- 2004-10-23
|
|-- 2004-10-24
|
|-- 2004-10-25
|
|-- 2004-10-26
|
|-- 2004-10-27
|
|-- 2004-10-28
|
|-- 2004-10-29
|
|-- 2004-10-30
|
`-- 2004-10-31
|-- 2004-11
|
|-- 2004-11-01
|
|-- 2004-11-02
Dentro de cada diretório é que ficam os arquivos de flows, que são
como abaixo:
1.3M
1.3M
1.2M
ft-v05.2005-08-09.000000-0300
ft-v05.2005-08-09.001500-0300
ft-v05.2005-08-09.003000-0300
8
1.2M
ft-v05.2005-08-09.004500-0300
Os arquivos criados começam o nome por ft. Vamos destricinhar o
primeiro arquivos pelo nome. FT de flow tools, v05 é a versão 5 do Netflow
(vide Cisco para mais informações de outras versões), 2005-08-09 é a data,
e 0000000 é a hora referente ao arquivo, que registra da 00:00 até 00:15 os
fluxos, com zona geográfica de -3 horas em relação a GMT. O tamanho do
arquivo é 1.3MB.
Flow-tools é um conjunto composto pelos seguintes softwares:
flow-capture – Coleta, comprime, armazena e gerencia o espaço em
disco para flows vindos do roteador.
flow-cat – Concatena os arquivos de flow. Tipicamente os arquivos
de flows são referentes a 5 ou 15 minutos de exports. Use flow cat para
concatená-los e aumentar suas análises para perídos de tempo maiores.
flow-report – Gera relatórios. Relatório incluem IP de origem e
destino, AS de origem e destino. Mais de 50 tipos de relatórios são
suportados.
flow-tag - Serve para marcar os flows baseados em IP ou AS. Esses
tags podem ser usadas depois com flow-report para gerar relatórios sobre
determinada faixa IP. Utilizamos para filtrar dados da AS Brasil Telecom.
flow-filter – Filtra o tráfego baseado em campos como porta. Por
exemplo, podemos querer saber quanto tráfego da AS Brasil telecom
corresponde a porta 80. Então marcamos os flows com flow-tag e passamos
para o flow-filter..
flow-import - Importa data de ASCII ou cflowd.
flow-export - Export data para ASCII ou cflowd .
flow-send – Envia dados na rede utilizando o protocolo netflow.
flow-receive – Recebe exports usando o protocolo Netflow porém
sem armazenar em disco,como o flow-capture.
flow-gen – Gera dados para teste.
flow-dscan – ferramenta simples para detectar scanners na rede e
tentativas de ataques de negação de serviços (DDoS e DoS.
flow-merge – une arquivos em ordem cronológica.
flow-xlate – faz tradução de alguns campos.
flow-expire -Expiras fluxos utilizando a mesma política do flow9
capture.
flow-header – Exibe metadados do flow.
flow-split – divide arquivos em tamanho menores.
Bom, visto agora o que flow-tools possui, para usarmos basta
encadear com pipes (“|”) os comandos para obtermos os relatórios, com os
devidos parâmetros.
Vou demonstrar um exemplo de flow-tools:
flow-cat /netflow | flow-filter -p25 |flow-stat -f0
Este código concatena os arquivos do Netflow que estão abaixo da
árvore /netflow, então passa para a flow-filter que filtra os que tém a porta
25 e o flow-stat gera relatório a partir dos dados vindos da cadeia de
comandos anteriores.
# --- ---- ---- Report Information --- --- --#
# Fields:
Total
# Symbols:
Disabled
# Sorting:
None
# Name:
Overall Summary
#
# Args:
/usr/local/netflow/bin/flow-stat -f0
#
Total Flows
: 161145
Total Octets
: 203357738
Total Packets
: 3360762
Total Time (1/1000 secs) (flows): 1288065068
Duration of data (realtime)
: 86400
Duration of data (1/1000 secs) : 86470120
Average flow time (1/1000 secs) : 7993.0000
Average packet size (octets)
: 60.0000
Average flow size (octets)
: 1261.0000
Average packets per flow
: 20.0000
Average flows / second (flow)
: 1.8636
Average flows / second (real)
: 1.8651
Average Kbits / second (flow)
: 18.8142
Average Kbits / second (real)
: 18.8294
IP packet size distribution:
1-32
64
96 128 160 192 224 256 288 320 352 384 416
448 480
.000 .419 .459 .110 .007 .002 .001 .000 .000 .000 .000 .000 .000 .
000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .001 .000 .000 .000 .000 .000 .000 .000 .000 .000
10
Packets per flow distribution:
1
2
4
8
12
16
20
24
28
32
36
40
44
48
52
.180 .042 .070 .216 .181 .132 .060 .022 .013 .008 .006 .005 .006 .
004 .003
60 100 200 300 400 500 600 700 800 900 >900
.004 .010 .024 .005 .004 .002 .001 .001 .000 .000 .001
Octets per flow distribution:
32
64 128 256 512 1280 2048 2816 3584 4352 5120 5888 6656
7424 8192
.000 .141 .066 .074 .087 .451 .106 .019 .008 .005 .007 .007 .006 .
003 .002
8960 9728 10496 11264 12032 12800 13568 14336 15104 15872 >15872
.001 .002 .001 .001 .001 .001 .001 .000 .001 .001 .011
Flow time distribution:
10
50 100 200 500 1000 2000 3000 4000 5000 6000 7000 8000
9000 10000
.205 .002 .005 .014 .030 .045 .093 .099 .062 .055 .047 .037 .030 .
043 .029
12000 14000 16000 18000 20000 22000 24000 26000 28000 30000 >30000
.040 .028 .023 .017 .013 .014 .011 .007 .006 .005 .040
Visto um exemplo básico, passamos agora ao ambiente de produção,
como realizo o monitoramento.
Todo processo é resumido em scripts agendadados no crond a
execução a partir de 00:01 horas.
#!/bin/bash
#scrip daily – a ser executado diariamente pelo crond
#Giovane Moreira [email protected]
/root/scripts/n_generate
/root/scripts/n_ripdata
/root/scripts/NGRAPHS
scp -r -i /home/grafico/.ssh/id_rsa /root/scripts/graphs/
login@servidorweb:/var/www/popgo/dir_destino/
Um fluxograma de execução da solução seria:
Figura 3: Fluxograma de execução do projeto
11
Como se pode ver, ele chama na verdade 3 scripts e realiza um scp
para o servidor web. Eis a função de cada um:
Script n_generate: gerar os relatórios do flow-tools a partir do que
foi armazenado no disco. Sempre se analisa os dados do dia anterior, por
isso date recebe 1 day ago. Como produto gera uma série de arquivos .txt,
que contém os relatórios.
#!/bin/bash
#n_generate: script para acessar os diretórios gerados pelo flowcapture e então gerar os dados necessários para gerar os gráficos via
rrdtool.
#date recebe data no formato 2005/2005-07/2005-07-08, que é a
#estrutura de diretórios do flow-capture que contem os flows.
data=`date --date '1 days ago' +%Y/%Y-%m/%Y-%m-%d`
netflow_dir=/usr/local/netflow/bin
dir=/netflow/$data/
#acessa o diretório dos fluxos do dia.
cd $dir
echo $dir
#Gera upload.txt que contém o Upload Total do roteador
$netflow_dir/flow-cat $dir |$netflow_dir/flow-stat -f18>/netflow/$
{data}/upload.txt
#Download Total
$netflow_dir/flow-cat $dir |$netflow_dir/flow-stat -f17
>/netflow/${data}/download.txt
#Upload na Porta 80
$netflow_dir/flow-cat $dir
|$netflow_dir/flow-filter -P80 |
$netflow_dir/flow-stat -f0 > /netflow/${data}/p80u.txt
#Download na Porta 80$netflow_dir/flow-cat $dir
$netflow_dir/flow-filter -p80 |$netflow_dir/flow
-stat -f0 > /netflow/${data}/p80d.txt
|
#Upload na Porta 20
$netflow_dir/flow-cat $dir
|$netflow_dir/flow-filter -P20 |
$netflow_dir/flow-stat -f0 >/netflow/${data}/p20u.txt
#Download na Porta 20
$netflow_dir/flow-cat $dir
|$netflow_dir/flow-filter -p20 |
$netflow_dir/flow-stat -f0 >/netflow/${data}/p20d.txt
#Upload na Porta 25
$netflow_dir/flow-cat $dir
|$netflow_dir/flow-filter -P25 |
$netflow_dir/flow-stat -f0 >/netflow/${data}/p25u.txt
#Download na Porta 25
$netflow_dir/flow-cat $dir
|$netflow_dir/flow-filter -p25 |
$netflow_dir/flow-stat -f0 >/netflow/${data}/p25d.txt
12
Script n_ripdata: precisamos extrair do relatório bruto (os .txt
gerados acima) os dados que serão passados ao RRDTOOL para gerarem os
gráficos. Por exemplo, queremos saber quantos bytes passaram de upload
na porta 25, e armazenar isso em um arquivo para que possa ser lido,
apenas o número total. E então esse valor é armazenado nos arquivos do
RRDTOOL.
#!/bin/bash
#n_ripdata: script para extrair dados dos relatórios do flow-tools,
para então usar no RRDTTOOL
#como converter data em timestamp: date -d040914 +%s
netflow_dir=/usr/local/netflow/bin/
data=`date --date '1 days ago' +%Y/%Y-%m/%Y-%m-%d `
datastamp=`date --date '1 days ago' +%s`
cd /netflow/${data}
#abaixo são expressões regulares que extraem os campos que serão
#armazenados em arquivos _rrd.txt para leitura do RRDTool, apenas o
#dado que interessa. É feito uma execução para cada txt.
#upload total
head -13 upload.txt|tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' > upload_rrd.txt
| awk -F"
#download total
head -13 download.txt|tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
-F" " '{print $3}' >download_rrd.txt
#download na porta 80
head -11 p80d.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' >p80d_rrd.txt
| awk
| awk -F"
#download na porta 20
head -11 p20d.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' >p20d_rrd.txt
| awk -F"
#download na porta 25
head -11 p25d.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' >p25d_rrd.txt
| awk -F"
#upload na porta 80
head -11 p80u.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' >p80u_rrd.txt
| awk -F"
#upload na porta 20
head -11 p20u.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' > p20u_rrd.txt
| awk -F"
#upload na porta 25
head -11 p25u.txt |tail -1 | sed "s/\W* \W* \(\W\)/\1/g "
" '{print $3}' >p25u_rrd.txt
| awk -F"
#esses dados são gerados em bytes, queremos convertê-los para
#gigabytes, por isso chamamos o programa a.out (feito em c) para
#executar isso. E grava no mesmo arquivo. Apenas converte de bytes
13
#para gbytes.
temp=$(cat upload_rrd.txt)
/root/scripts/a.out $temp > upload_rrd.txt
temp=$(cat download_rrd.txt)
/root/scripts/a.out $temp > download_rrd.txt
temp=$(cat p20d_rrd.txt)
/root/scripts/a.out $temp > p20d_rrd.txt
temp=$(cat p20u_rrd.txt)
/root/scripts/a.out $temp > p20u_rrd.txt
temp=$(cat p25d_rrd.txt)
/root/scripts/a.out $temp > p25d_rrd.txt
temp=$(cat p25u_rrd.txt)
/root/scripts/a.out $temp > p25u_rrd.txt
temp=$(cat p80d_rrd.txt)
/root/scripts/a.out $temp > p80d_rrd.txt
temp=$(cat p80u_rrd.txt)
/root/scripts/a.out $temp > p80u_rrd.txt
#agora é que precisamos colocar os arquivos na forma que o RRDTOOL
#consegue armazenar. A saída será algo na forma: 40:30:20:20.30
#na documentação do rrdtool será explicado o porque desta forma.
#arquivo que o netflow lê e armazena. Versão dos downloads.
temp=`cat download_rrd.txt``echo :``cat p80d_rrd.txt``echo :``cat
p20d_rrd.txt``echo :``cat p25d_rrd.txt`
echo $temp > update_d
#arquivo que o netflow lê e armazena. Versão dos uploads.
temp=`cat upload_rrd.txt``echo :``cat p80u_rrd.txt``echo :``cat
p20u_rrd.txt``echo :``cat p25u_rrd.txt`
echo $temp >update_u
#comando que faz o rrdtool atualizar sua base com os arquivos
#coletados do dia. Apenas atualiza.
/usr/bin/rrdtool update /root/scripts/download.rrd $datastamp:`cat
update_d`
/usr/bin/rrdtool update /root/scripts/upload.rrd $datastamp:`cat
update_u`
Script NGRAPHS: script responsável por gerar os gráficos e
disponibilizar automaticamente nos diretórios. Cria os gráficos, gera
diretórios de acordo com a data.
#!/bin/bash
#NGRAPHS: script de criação de gráficos, árvore de diretórios de
disponibilização no apache. por Giovane Moreira [email protected]
#primeiramente devemos testar se há realmente os diretórios para
guardar os gráficos. A estrutura de diretórios segue o padrã
#graphs/ANO/MES <DENTRO DE MES TEM AS PASTAS
#mensal,1st,2nd,3rd,last,cada qual com 6 gráficos distintos.
14
#após atualizar os rrd , é preciso gerar os gráficos novamente e
#disponibilizar.
cd /root/scripts
ano=`date +%y`
mes=`date +%m`
temp=`date +%d`
ano_mes=`echo graphs/$ano/$mes`
ano_dir=`echo graphs/$ano`
rrdtool=/usr/bin/rrdtool
#determina qual semana estamos, se é 1, 2 3 ou 4
if [ $temp -lt 8 ]; then
semana=1
elif [ $temp -ge 7 ] && [ $temp -lt 15 ]; then
semana=2
elif [ $temp -ge 15 ] && [ $temp -lt 22 ]; then
semana=3
else semana=4
fi
#testa se os diretórios existem. Os gráfico são organizados
#árvore como: <ano><mes><semana>
numa
if [ -d $ano_mes ];
then
echo "os dir estão ok"
elif [ -d $ano_dir ];
then
#cria dir do mes novo
mkdir /root/scripts/graphs/$ano/$mes
mkdir /root/scripts/graphs/$ano/$mes/mensal
mkdir /root/scripts/graphs/$ano/$mes/1st
mkdir /root/scripts/graphs/$ano/$mes/2nd
mkdir /root/scripts/graphs/$ano/$mes/3rd
mkdir /root/scripts/graphs/$ano/$mes/last
else
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
mkdir
/root/scripts/graphs/$ano
/root/scripts/graphs/$ano/$mes
/root/scripts/graphs/$ano/$mes/mensal
/root/scripts/graphs/$ano/$mes/1st
/root/scripts/graphs/$ano/$mes/2nd
/root/scripts/graphs/$ano/$mes/3rd
/root/scripts/graphs/$ano/$mes/last
fi
#funções que geram os gráficos.. serão invocadas logo
abaixo...
#Geral_updown: gera gráfico de upload e download total, sem
#dividir por portas.
Geral_updown() {
15
#gráfico down e upload total
syear=$1 #syear = start year – ano de início
smonth=$2
sday=$3
eano=$4 #eano = end ano – ano de fim
emes=$5
eday=$6
#essa variáveis valem para todas as funções de gráficos desse
#script. Delimitam o intervalo de início e fim da geração dos
#gráficos.
$rrdtool graph Geral_updown.gif --start `date -d ${syear}${smonth}
${sday} +%s` --end `date -d ${eano}${emes}${eday} +%s` --title "PoPGO: Cisco - Downloads e Uploads Volume Total - Ano:$syear
Mês:$smonth" --vertical-label "gigabytes"
DEF:download=download.rrd:download:LAST
DEF:upload=upload.rrd:upload:LAST LINE1:download#ff0000:"Downloads"
LINE2:upload#0400ff:"Uploads" 'GPRINT:download:LAST:Último
Download\:%2.1lf GB' 'GPRINT:upload:LAST:Último Upload\:%2.1lf GB'
'GPRINT:download:MAX:Download Max\:%2.1lf GB'
'GPRINT:upload:MAX:Upload Max\:%2.1lf GB' 'GPRINT:download:
MIN:Download Mín\:%2.1lf GB' 'GPRINT:upload:MIN:Upload Mín\:%2.1lf
GB' -w 509
}
#gera o gráfico de upload e download nas portas específicas.
Portas_updown() {
#gráfico down e upload nas portas específicas
syear=$1
smonth=$2
sday=$3
eano=$4
emes=$5
eday=$6
porta=$7
$rrdtool graph P${porta}_updown.gif --start `date -d ${syear}
${smonth}${sday} +%s` --end `date -d ${eano}${emes}${eday} +%s` -title "PoP-GO: Cisco - Downloads e Uploads Volume Total - Porta
$porta Ano:$syear Mês:$smonth" --vertical-label "gigabytes"
DEF:download=download.rrd:p${porta}d:LAST DEF:upload=upload.rrd:p$
{porta}u:LAST LINE1:download#ff0000:"Downloads Porta $porta"
LINE2:upload#0400ff:"Uploads Porta $porta"
'GPRINT:download:LAST:Último Download\:%2.1lf GB'
'GPRINT:upload:LAST:Último Upload\:%2.1lf GB'
'GPRINT:download:MAX:Download Max\:%2.1lf GB' 'GPRINT:up
load:MAX:Upload Max\:%2.1lf GB' 'GPRINT:download:MIN:Download Mín\:%
2.1lf GB' 'GPRINT:upload:MIN:Upload Mín\:%2.1lf GB' -w 509
}
All_down() {
#gráfico download geral e na P80,P20 e P25
syear=$1
smonth=$2
sday=$3
eano=$4
emes=$5
eday=$6
16
$rrdtool graph All_down.gif --start `date -d ${syear}${smonth}${sday}
+%s` --end `date -d ${eano}${emes}${eday} +%s` --title "PoP-GO:
Cisco - Downloads - Volume Total - Total,Portas 80,20,25 Ano:$syear
Mês:$smonth" --vertical-label "gigabytes"
DEF:download=download.rrd:download:LAST
DEF:p80d=download.rrd:p80d:LAST DEF:p20d=download.rrd:p20d:LAST
DEF:p25d=download.rrd:p25d:LAST LINE1:download#ff0000:"Download
Total" LINE2:p80d#0400:"Download Porta 80"
LINE3:p20d#00FF00:"Download Porta 20" 'GPRINT:download:LAST:Último
Download\:%2.1lf GB' 'GPRINT:p80d:LAST:Último Download
80\:%2.1lf GB' 'GPRINT:p20d:LAST:Último Download P20\:%2.1lf GB'
'GPRINT:p25d:LAST:Último Download P25\:%2.1lf GB'
'GPRINT:download:MAX:Download Max\:%2.1lf GB'
'GPRINT:p80d:MAX:Download Max P80 \:%2.1lf GB'
'GPRINT:p20d:MAX:Download Max P20 \:%2.1lf GB'
'GPRINT:p25d:MAX:Download Max P25:%2.1lf GB'
'GPRINT:download:MIN:Download Mín\:%2.1lf GB'
'GPRINT:p80d:MIN:Download Mín P80\:%2.1lf GB'
'GPRINT:p20d:MIN:Download Mín P20\:%2.1lGB'
'GPRINT:p25d:MIN:Download Mín P25\:%2.1lf GB' -w 509
}
All_up() {
#gráfic upload geral e na P80,P20 e P25
$rrdtool graph All_up.gif --start `date -d ${syear}${smonth}${sday}
+%s` --end `date -d ${eano}${emes}${eday} +%s` --title "PoP-GO:
Cisco -Uploads - Volume Total - Total,Portas 80,20,25 Ano:$syear
Mês:$smonth" --vertical-label "gigabytes"
DEF:upload=upload.rrd:upload:LAST DEF:p80u=upload
rd:p80u:LAST DEF:p20u=upload.rrd:p20u:LAST
DEF:p25u=upload.rrd:p25u:LAST LINE1:upload#ff0000:"Upload Total"
LINE2:p80u#0400ff:"Upload Porta 80"
INE3:p20u#00FF00:"Upload Porta 20" 'GPRINT:upload:LAST:Último
Upload\:%2.1lf GB' 'GPRINT:p80u:LAST:Último Upload P80\:%2.1lf GB'
'GPRINT:p20u:LAST:Último Upload P20\:%2.1lf GB'
'GPRINT:p25u:LAST:Último Upload P25\:%2.1lf GB'
'GPRINT:upload:MAX:Upload Max\:%2.1lf GB' 'GPRINT:p80u:MAX:Upload Max
P80 \:%2.1lf GB' 'GPRINT:p20u:MAX:Upload Max P20 \:%2.1lf GB'
'GPRINT:p25u:MAX:Upload Max P25 \:%2.1lf GB'
'GPRINT:upload:MIN:Upload Mín\:%1lf GB' 'GPRINT:p80u:MIN:Upload Mín
P80\:%2.1lf GB' 'GPRINT:p20u:MIN:Upload Mín P20\:%2.1lf GB'
'GPRINT:p25u:MIN:Upload Mín P25\:%2.1lf GB' -w 509
}
#funções agora que setam variáveis e então invocam as funçoes
#geradoras de gráficos...#Mensal gera gráficos para o mês inteiro,
invocando funções anteriores:
Mensal () {
#seta syear, smonth e sday, eyear,emonth e eday e invoca
syear=$ano
smonth=$mes
sday=01
eyear=$ano
emonth=$mes
eday=07
17
Geral_updown $syear $smonth $sday $eyear $emonth $eday ;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 80;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 20;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 25;
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_up $syear $smonth $sday $eyear $emonth $eday;
#move paras as devidas pastas
mv Geral_updown.gif /root/scripts/graphs/$ano/$mes/1st/
mv P80_updown.gif /root/scripts/graphs/$ano/$mes/1st/
mv P25_updown.gif /root/scripts/graphs/$ano/$mes/1st/
mv P20_updown.gif /root/scripts/graphs/$ano/$mes/1st/
mv All_down.gif /root/scripts/graphs/$ano/$mes/1st/
mv All_up.gif /root/scripts/graphs/$ano/$mes/1st/
}
#segunda no caso se for a segunda semana do mês
Segunda () {
#seta syear, smonth e sday, eyear,emonth e eday
e invoca
syear=$ano
smonth=$mes
sday=08
eyear=$ano
eday=15
emonth=$mes
Geral_updown $syear $smonth $sday $eyear $emonth $eday ;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 80;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 20;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 25;
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_up $syear $smonth $sday $eyear $emonth $eday;
#move paras as devidas pastas
mv Geral_updown.gif /root/scripts/graphs/$ano/$mes/2nd/
mv P80_updown.gif /root/scripts/graphs/$ano/$mes/2nd/
mv P25_updown.gif /root/scripts/graphs/$ano/$mes/2nd/
mv P20_updown.gif /root/scripts/graphs/$ano/$mes/2nd/
mv All_down.gif /root/scripts/graphs/$ano/$mes/2nd/
mv All_up.gif /root/scripts/graphs/$ano/$mes/2nd/
}
#para terceira semana do mês
Terceira () {
#seta syear, smonth e sday, eyear,emonth e eday
e invoca
syear=$ano
smonth=$mes
sday=16
eyear=$ano
emonth=$mes
eday=21
18
Geral_updown $syear $smonth $sday $eyear $emonth $eday ;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 80;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 20;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 25;
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_up $syear $smonth $sday $eyear $emonth $eday ;
#move as pastas pros devidos locaiss pastas
mv Geral_updown.gif /root/scripts/graphs/$ano/$mes/3rd/
mv P80_updown.gif /root/scripts/graphs/$ano/$mes/3rd/
mv P25_updown.gif /root/scripts/graphs/$ano/$mes/3rd/
mv P20_updown.gif /root/scripts/graphs/$ano/$mes/3rd/
mv All_down.gif /root/scripts/graphs/$ano/$mes/3rd/
mv All_up.gif /root/scripts/graphs/$ano/$mes/3rd/
}
#para última semana do mês
Last () {
#seta syear, smonth e sday, eyear,emonth e eday
e invoca
syear=$ano
smonth=$mes
sday=22
eyear=$ano
emonth=$mes
#informa se o mês tem 30 ou 31 ou 28 dias.
case $mes in
O1) eday=31 ;;
02) eday=28 ;;
03) eday=31 ;;
04) eday=30 ;;
05) eday=31 ;;
06) eday=30 ;;
07) eday=31 ;;
08) eday=31 ;;
09) eday=30 ;;
10) eday=31 ;;
11) eday=30 ;;
12) eday=31 ;;
esac
Geral_updown $syear $smonth $sday $eyear $emonth $eday ;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 80;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 20;
Portas_updown $syear $smonth $sday $eyear $emonth $eday 25;
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_up $syear $smonth $sday $eyear $emonth $eday;
#move paras as devidas pastas
mv Geral_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P80_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P25_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P20_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv All_down.gif /root/scripts/graphs/$ano/$mes/last/
mv All_up.gif /root/scripts/graphs/$ano/$mes/last/
}
19
All_down $syear $smonth $sday $eyear $emonth $eday ;
All_up $syear $smonth $sday $eyear $emonth $eday;
#move paras as devidas pastas
mv Geral_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P80_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P25_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv P20_updown.gif /root/scripts/graphs/$ano/$mes/last/
mv All_down.gif /root/scripts/graphs/$ano/$mes/last/
mv All_up.gif /root/scripts/graphs/$ano/$mes/last/
}
#se for a 1ª semana, não há necessidade de gerar gráfico da 2ªsemana.
if [ $semana -eq 1 ]; then
#gera graficos mensal apenas, e copias ele pra pasta 1st.. pq
#sao iguasi!
Mensal ;
Primeira ;
elif [ $semana -eq 2 ]; then
#gera grafico mensal, 1st e 2nd
Mensal ;
Primeira ;
Segunda ;
elif [ $semana -eq 3 ]; then
#gera grafico mensal, 1st, 2nd e 3rd
Mensal ;
Primeira ;
Segunda ;
Terceira ;
elif [ $semana -eq 4 ]; then
#gera todos os graficos
Mensal ;
Primeira ;
Segunda ;
Terceira ;
Last ;
fi
#copia os gráficos para o diretório correto.
cp -r /root/scripts/graphs /var/www/htdocs
chown -R nobody /var/www/htdocs/graphs
3.2.2 Resultado e produtos obtidos
O produto deste final são os gráficos que são automaticamente
colocados na árvore de diretórios,algo com a figura abaixo:
20
Figura 4: árvore de diretórios gerada pelo script n_generate
A pasta acima na figura 04 indica o ano, 10 o mês, e 1st, 2nd,3rd ,last
indicam a semana do mês. Já mensal é a pasta para o mês inteiro. Cada
pasta dessas recebe arquivos .gif que são os gráficos. Depois basta linkar
isso a um site e estará pronto na internet.
Os gráficos obtidos serão como o abaixo:
Figura 5: Gráfico all_down.gif Primeira semana de abril. Download
separado por porta
Mais gráficos gerados pelos scripts podem ser vistos na seção
monitoramento do site http://www.pop-go.rnp.br
Agora já temos o produto final, porém alguns itens ainda não foram
explicados em relação ao script n_generate.
Um deles é o programa a.out , que converte dados de bytes para
gigabytes. Eis abaixo o código dele:
// a.c – softaware de conversão de valores de byte para gigabytes.
21
#include <stdlib.h>
# include <stdio.h>
#include <math.h>
int main(int argc, char *argv[]) {
if(argc != 2) return(99);
printf("%.3f",((atof(argv[1])/1024)/1024)/1024);
return(0);
}
Outra coisa que ainda não expliquie foi o uso da ferrramenta Rdtool,
como ele opera e como gera os gráficos. Preferi deixar isso para agora para
evitar confusões.
3.2.3. Entendendo o RRDtool
RRDtool é uma ferramenta que cria arquivos na ordem round-robin e
então armazena os valores (como uma base de dados) e depois pode gerar
gráficos a partir desses valores. É uma evolução de outro projeto, o MRTG.
Enquanto MRTG é focado em aplicações SNMP, o RRDTool pode ser usado
para monitorar qualquer tipo de dado, desde dados de rede de
computadores a crescimento de bactérias. Para gerar gráficos, ele requer a
biblioteca gráfica GD.
Antes de usarmos o RRDtool no projeto, precisamos criar os arquivos
.rrd , que serão a base de dados para os dados. É nele que serão inseridos
os valores diários de upload na porta 80, upload total, download na porta
20, etc... .
No uso no PoP-GO decidi criar 2 arquivos: um para dowloads e outro
para uploads. Utilizei o comando:
#Arquivo RRD de downloads
rrdtool create download.rrd --start `date -d 040930 +%s` --step 86400
DS:download:GAUGE:86400:0:200 DS:p80d:GAUGE:86400:0:200
DS:p20d:GAUGE:86400:0:200 DS:p25d:GAUGE:864
00:0:200 RRA:LAST:0.5:1:7 RRA:LAST:0.5:1:30 RRA:LAST:0.5:1:365
#Arquivo RRD de Uploads
rrdtool create upload.rrd --start `date -d 040930 +%s` --step 86400
DS:upload:GAUGE:86400:0:200 DS:p80u:GAUGE:86400:0:200
DS:p20u:GAUGE:86400:0:200 DS:p25u:GAUGE:86400:0
:200 RRA:LAST:0.5:1:7 RRA:LAST:0.5:1:30 RRA:LAST:0.5:1:365
A sintaxe do arquivo de downloads quanto o de uploads é
basicamente a mesma, de forma que basta explicar apenas um deles. O
parâmetro create download.rrd passa ao RRDtool que criaremos um
arquivo novo do zero, com data inicial em 30/09/04 , passado pelo
parâmetro --start . O parâmetro step informa que o passo em segundos
que atualizaremos o arquivo, ou seja, o arquivo será atualizado a cada 24
horas, ou 86400 segundos. É que nossa análise é feita após o fim do dia,
onde extraímos tudo que aconteceu. Já o parâmetro DS:ds-name:DST:dst
22
arguments significa que estamos criando uma fonte de dados. DS é sigla
para Data Source (fonte de dados). Temos várias fontes no script, e pegando
como exemplo a DS:p80u:GAUGE:86400:0:200 temos que p80u é um
nome para nossa data source (na verdade, armazena os uploads da porta
80,sintaxe que eu uso, você pode usar a que quiser). GAUGE significa que
devemos armazenar nosso dado com ele chega. Outras opções no lugar de
GAUGE seriam DERIVE, que armazena a derivada da reta valor que chega
em relação ao valor anterior. Existem outros tipos de fonte de dados (DST –
data source types), consulte as páginas de manual do software para mais
informações. Como argumentos estamos usando 86400, que é o período
para atualização do arquivo. E 0:200 no caso define a faixa máxima de
valores que pode variar este dado, no caso nosso de 0 gigabytes a 200
gigabytes. Qualquer valor fora deixa faixa será interpretado com UNKNOWN.
Por exemplo, não é possível que tenhamos download abaixo de 0.
No que se refere ao comando RRA:LAST:0.5:1:7, RRA é a sigla
para Round-Robin Archive. Um RRA consiste de dados estatísticos de DS
(data sources). A sintaxe genérica para o RRA é RRA:AVERAGE | MIN | MAX
| LAST:xff:steps:rows , que na verdade é parâmetro que diz o que deve
ser feito com os dados do DS.Pode ser uma média e armazenar de hora em
hora, mas no nosso caso ele armazena o último valor recebido. É o arquivo
que determina quantos slots tem para armazenar dados, evitando o
crescimento linear da base de dados. Ele armazena amostras para
semana,mês e ano no nosso caso.
Depois destes arquivos criados, o primeiro passo o armazenar os
dados neles, feito da seguinte forma:
# esse comando diz para atualizar o arquivo dowload.rrd com a data
#atual e o conteúdo extraído de update_d. Vide NGRAPHS.
rrdtool update /root/scripts/download.rrd $datastamp:`cat update_d`
Ou seja, inserimos um valor como por exemplo 20:40:40:32, que
serão os valroes dos downloads geral, na porta 80, 20 e 25 para o dia
(representado por $datastamp, vide NGRAPHS) em questão. No outro dia,
quando rodarmos o script, o datastamp será outro e atualizará
automaticamente o valor.
Com os dados “populados”, basta agora gerarmos os gráficos. O
RRDtool fornece um parâmetro para criar gráficos. Vejamos o exemplo:
$rrdtool graph Geral_updown.gif --start `date -d ${syear}${smonth}
${sday} +%s` --end `date -d ${eano}${emes}${eday} +%s` --title "PoPGO: Cisco - Downloads e Uploads Volume Total - Ano:$syear
Mês:$smonth" --vertical-label "gigabytes"
DEF:download=download.rrd:download:LAST
DEF:upload=upload.rrd:upload:LAST LINE1:download#ff0000:"Downloads"
LINE2:upload#0400ff:"Uploads" 'GPRINT:download:LAST:Último
Download\:%2.1lf GB' 'GPRINT:upload:LAST:Último Upload\:%2.1lf GB'
'GPRINT:download:MAX:Download Max\:%2.1lf GB'
'GPRINT:upload:MAX:Upload Max\:%2.1lf GB' 'GPRINT:download:
23
MIN:Download Mín\:%2.1lf GB' 'GPRINT:upload:MIN:Upload Mín\:%2.1lf
GB' -w 509
}
O parâmetro graph diz ao rrdtool para criar um gráfico de nome
Geral_updown.gif, a partir da data depois de --start. Essa data é a do dia
anterior, visto que geramos o gráfico e análises após a meia noite.
Estabelecemos o fim do gráfico pela opção --end . O parâmetro --title
informa qual será o título que aparecerá no gráfico, no cabeçalho, como na
figura
acima
foi
PoP-GO
...
.
A
linha
DEF:download=download.rrd:download:LAST
serve para buscar dados
no arquivo rrd. Dentro de download.rrd, pegaremos o valor da DS download
com a função de consolidação LAST e armazenaremos num nome virtual
(vname) também chamado download. Esse vname é o download após DEF:.
Aí dentro deste comando quando quisermos nos refererir a este valor de
download dentro de download.rrd, usaremos o nome download apenas. O
parâmetro LINE1:download#ff0000:"Downloads" cria uma linha da cor
ff0000 que conterá o valor de download variando no no intervalo de tempo
que escolhemos acima com --start  --end . O parâmetro
'GPRINT:download:MAX:Download Max\:%2.1lf GB' imprime uma linha
que diz Downlaod Max no gráfico e joga o conteúdo de download na frente.
O parâmetro -w 509 informa a largura máxima da figura, que será 509
pixels. Foi necessário para padronizar o tamanho do gráfico para o site do
PoP-GO.
Pode parecer um pouco complicado, e recomendo leitura das páginas
de manual e tutoriais do site oficial do RRDTool. Com isso fecha-se nossas
ferramentas desenvolvidas e obtivemos o resultado desejado.
Lembre-se que Netflow possibilita vários tipos de relatórios, junto
com flow-tools. Basta usar a criatividade e extair, monitorar e gerar gráficos
de diversas situações. Uma delas seria o tráfego P2P.
Melhorias desse software seriam a integração com um banco de
dados relacional livre e integração com alguma ferramenta de
monitoramento,como o JFFNMS.
Essa seção se focou apenas em apresentar a ferramentas. As
conclusões e análise de resultados podem ser obtidas na seção 4 de
conclusão.
3.3 Pesquisa em Multimídia sobre IP
Meu projeto final de curso se relaciona a multimídia sobre IP. Na RNP
dediquei parte do tempo a pesquisa nessa área. Vários artigos eu li do site
dos Periódicos da Capes, principalmente artigos do IEEE Xplore.
Participei do 5º Fórum Internacional do Software Livre em Porto
Alegre, junho de 2005. Lá vi os trabalhos na mesma área do PoP-BA.
Estavam presentes o pessoal do VideoLan Project, projeto de um player de
24
vídeo e servidor livre. Realizei testes fazendo streaming com esta
ferramenta, e monitorei utilizando o protocolo SNMP com a ferramenta
JFFNMS.
O teste que realizei com o VLC foi fazer um streaming de arquivo de
áudio codificado com MPEG1 layer 3 (MP3) de qualidade fixa de 128kbps
para outra máquina em outra rede. Monitorando a saída da placa de rede,
obtivemos o resultado que pode ser observado relatório incluído no anexo
2.
Li muitos artigos que estão sendo de fundamental importância para
meu projeto final. Os resultados dessa pesquisa poderá ser visto no artigo.
No que se refere ao JFFNMS, criei um guia de instalação para o
Slackware/Linux que pode ser visto no anexo 3. Esse guia foi traduzido do
inglês e adaptado ao Slackware por mim.
4. Conclusão
O desafio lançado pelo PoP-GO sobre mim a fim de obter os
resultados do monitoramento foi muito empolgante. Tive a chance de
aprofundar o estudo em redes de computadores,incluindo aí a pilha TCP/IP,
monitoramento, tecnologias de ponta como Cisco Netflow, segurança,
serviços e métricas de desempenho, aprender muito sobre redes de grande
porte com suas AS,roteamento de borda, uma infinidade inesgotável de
assuntos. Desconheço em qualquer outro lugar do estado de Goiás que se
tenha a mesma estrutura disponível e que eu teria uma oportunidade
semelhante. Somente em estágio eu poderia ter aprendido tanto, foi o local
onde fixei um objetivo e fiz pesquisa,baseado no conhecimento de sala de
aula.
Outro ponto forte foi aprender bastante sobre integração de
ferramentas de software livre. Com o flow-tools se coleta os dados, e com o
rrdtool se armazena faz-se os gráficos (e por sua vez rrdtool utiliza outra
grama de aplicativos livres, como a biblioteca gráfica GD para gerar
gráficos), então automatizar este processo com scripts em Shell e código em
C e finalmente disponibilizar o conteúdo num servidor web (apache,livre) via
ssh. , e integrar uma gama de ferramentas de software livre para gerar um
produto pronto, os gráficos de monitoramento do site do PoP-GO.
Todas essas atividades exigiram muita pesquisa e dedicação. Muitos
dias na internet, falando com os colegas de trabalho (que sem eles isso não
teria sido possível),sempre focando na busca da melhor forma de fazer as
coisas.
Os resultados obtidos foram um sistema operante de monitoramento
para medição de tráfego para o PoP-GO devidamente documentado neste
relatório,utilizando apenas software livres.
Dificuldades sempre existiram durante todo o percurso. Agradeço a
25
todos os colegas de trabalho pela ajuda, a equipe do PoP-GO e da UFGNet.
Uma observação que gostaria de deixar é que este relatório foi
inteiramente feito com software livre. OpenOffice.org como editor de texto,
Dia como programa para gráficos e diagramas.
Antes desse projeto também estive usando outras ferramentas de
monitoramento SNMP,tais como JFFNMS e Cacti. Percebi que em nenhuma
delas existe o suporte de monitoramento com Netflow. Algo para continução
desse projeto seria a integração desses códigos que realizei com algum
software desse nível.
26
Anexo 1
Relatório de análise de tráfego entre redes do
PoP-GO/RNP e Brasil Telecom
Introdução
Este relatório visa estimar o tráfego trocado entre as redes do Ponto
de Presença em Goiás da Rede Nacional de Ensino e Pesquisa (PoP-GO) e
Brasil Telecom. A necessidade de obter estes valores é verificar a viabilidade
do estabelecimento de um Ponto de Troca de Tráfego (PTT) entre as duas
redes em Goías evitando assim todo o percurso até Curitiba que os pacotes
atualmente passam, mesmo se o destino for um host em Goiás.
Para obter estes valores, coletamos por um período de 37 dias (de 22
de Julho à 24 de agosto de 2004, e de 14 de setembro à 17 de setembro) os
dados vindos do roteador Cisco do PoP-GO. (lembramos que julho é o
período de férias acadêmicas da UFG, maior cliente do PoP-GO, e há
redução substancial do tráfego). Os dados obtidos via Netflow foram então
depois analisados com as ferramentas flow-tools, e assim conseguimos as
estatísticas desejadas.
Análise dos dados e resultados
Além da meta primária de obter os valores trocados entre as duas
redes (PoP-GO/RNP e Brasil Telecom), outra meta seria estabelecer quanto
representa a troca de dados com a Brasil Telecom em relação a todo tráfego
gerado. Obtivemos estes valores facilmente com flow-tools.
Começaremos primeiramente analisando toda saída do roteador.
Segue abaixo o resultado:
#RELATÓRIO DE TODA ENTRADA (DOWNLOAD) DO CISCO ROUTER POP-GO/RNP.
#Gerado em: 22/09/04 às 11:37 AM
#Intervalo de coleta: 22/07-24/08 e 14/09-17/09
#
#Sintaxe do comando(usando flow-tools para análise):
#./flow-cat /flows/ /netflow |./flow-stat -f18 >SaidaTOTAL2.txt &
#onde /flows e /netflow são diretórios dos flows capturados
#
# --- ---- ---- Report Information --- --- --#
# Fields:
Total
# Symbols:
Disabled
# Sorting:
None
# Name:
Output interface
#
27
# Args:
#
#
# interface
#
7
2
1
0
./flow-stat -f18
flows
octets
packets
215736716
179471776
75559134
50075433
1812267314100
1291693851690
360257865825
29774437080
3191349487
2948007981
925654315
137316230
Dentre as três interfaces do roteador em questão, a número 7 é a que
representa o link Goiânia-Rio de Janeiro (ATM, 12Mbps upload, 16Mbps
download). Estamos basicamente interessados nesta interface, visto que as
outras são de uso interno do PoP-GO. O output desta interface representa
todo os dados que chegaram até o PoP-GO vindos de redes de fora, ou
seja,downloads. O total de octetos roteados pela interface 7 é de
1812267314100 , que dá um total de 1,648 Terabytes roteados pra dentro
do PoP- GO nesses 37dias.
O outro relatório é o que marca todas as entradas no roteador do
PoP-GO (e devido ao sentido, representam os dados que saem da rede do
PoP-GO para as demais redes, ou seja, upload). Segue ele abaixo:
#RELATÓRIO DE TODA SAÍDA (UPLOAD) DO CISCO ROUTER POP-GO/RNP.
#Gerado em: 22/09/04 às 11:39 AM
#Intervalo de coleta: 22/07-24/08 e 14/09-17/09
#
#sintaxe do comando:
#./flow-cat /flows/ /netflow |./flow-stat -f17 >EntradaTOTAL2.txt &
#onde /flows e /netflow são diretórios dos flows capturados
#
# --- ---- ---- Report Information --- --- --#
# Fields:
Total
# Symbols:
Disabled
# Sorting:
None
# Name:
Input interface
#
# Args:
./flow-stat -f17
#
#
# interface flows
octets
packets
#
7
244924205
1623219546750
3082972241
2
187627046
1558709347852
3151603403
1
88291808
312064574093
967752369
Como o que nos interessa é a interface 7, notamos que ela roteou
1623219546750 octetos. Isso nos dá um valor total de 1,476 Terabytes nos
mesmos 37 dias.
Agora que temos um valor total da saída e entrada na rede do PoPGO. Analisaremos o quanto disso vem da rede da Brasil Telecom. Geramos
dois relatório filtrando as faixas de endereço IP da Brasil Telecom (AS 8167)
28
O primeiro relatório abaixo lista todos os dados vindos da rede Brasil
Telecom.
#RELATÓRIO DE ENTRADA DE DADOS NO POP-GO VINDOS DA BRT
#Gerado em: 22/09/04 às 17:09
#Intervalo de coleta: 22/07-24/08 e 14/09-17/09
#
#Sintaxe do comando:
# ./flow-cat /flows/ /netflow/ | ./flow-filter -f acl_new -SBrT | ./
flow-stat
#-f0 > OrigemBRT2.txt &
#onde /flows e /netflow são diretórios dos flows capturados
#
# --- ---- ---- Report Information --- --- --#
# Fields:
Total
# Symbols:
Disabled
# Sorting:
None
# Name:
Overall Summary
#
# Args:
./flow-stat -f0
#
Total Flows
: 18938016
Total Octets
: 211142339124
Total Packets
: 394304150
Total Time (1/1000 secs) (flows): 136671796704
Duration of data (realtime)
: 4991368
Duration of data (1/1000 secs) : 4294967076
Average flow time (1/1000 secs) : 7216.0000
Average packet size (octets)
: 535.0000
Average flow size (octets)
: 11149.0000
Average packets per flow
: 20.0000
Average flows / second (flow)
: 4.4094
Average flows / second (real)
: 3.7942
Average Kbits / second (flow)
: 393.2833
Average Kbits / second (real)
: 338.4120
Analisando este relatório, temos que entraram no nosso roteador
211142339124 octetos oriundo das Brasil Telecom, o que significa
aproximadamente 196,64 Gigabytes nos 37 dias de coleta. Em relação aos
downloads de todo o PoP-GO, a Brasil Telecom responde sozinha por
11,65%.
Figura 1: Porcentagem dos downloads no roteador
29
Outro relatório é o que marca os dados saem do PoP-GO para a
rede da Brasil Telecom:
#RELATÓRIO DE SAÍDA DE DADOS NO POP-GO COM DESTINO BRT
#Gerado em: 22/09/04 às 17:10
#Intervalo de coleta: 22/07-24/08 e 14/09-17/09
#
#Sintaxe do comando:
#./flow-cat /flows/ /netflow/ | ./flow-filter -f acl_new -DBrT
| ./flow-stat
#-f0 > SaidaBRT2.txt & exit
#onde /flows e /netflow são diretórios dos flows capturados
#
# --- ---- ---- Report Information --- --- --#
# Fields:
Total
# Symbols:
Disabled
# Sorting:
None
# Name:
Overall Summary
#
# Args:
./flow-stat -f0
#
Total Flows
: 17499828
Total Octets
: 286351956238
Total Packets
: 398041084
Total Time (1/1000 secs) (flows): 132781952608
Duration of data (realtime)
: 4991370
Duration of data (1/1000 secs) : 4294966948
Average flow time (1/1000 secs) : 7587.0000
30
Figura 2: Porcentagem dos uploads no roteador
Analisando este relatório, notamos que sairam do roteador do PoPGO 286351956238 octetos para a rede da Brasil Telecom, o que significa
aproximadamente 266,68 Gigabytes nos 37 dias de coleta. Em relação aos
uploads todos do PoP-GO, a Brasil Telecom responde sozinha por 17,64%.
Conclusões
Agora com estes valores obtidos, poderemos decidir a viabilidade
do Ponto de Troca de Tráfego. Os dados foram obtidos como desejado.
Quaisquer dúvidas técnicas e/ou comentários favor entrar em contato no
endereço abaixo.
Giovane Moreira
PoP-GO/RNP
[email protected]
[email protected]
Goiânia, 23 de setembro de 2004.
31
Anexo 2: Streaming com VideoLan Client
Relatório de consumo de largura de banda em transmissão de
conteúdo multimídia utilizando VideoLan Client (VLC)
Giovane Moreira ([email protected])
PoP-GO RNP
6 de Julho de 2004
1. Introdução
Este relatório mostra a experiência do PoP-GO no streaming de
arquivos de áudio e vídeo respectivo consumo de largura de banda (e ter
uma idéia do overhead gerado na transmissão).
O enfoque do artigo é o uso da rede na atividade, e não como realizar
o streaming (visto que a documentação no site do VLC é bastante completa
e simples).
2. Equipamentos,software e rede
Servidor: A máquina utilizada como servidor de streaming foi um IBM
Netvista 6349-KCP. Sistema operacional: Slackware GNU/Linux 9.1 (kernel
2.6.6). VideoLan versão 0.7.1 Bond. Rede: Pertencente a rede A.
Cliente: PC com processador Pentium 4 e 256MB de Memória DDR.
Sistema operacional: Slackware GNU/Linux 9.1 (kernel 2.4.22). VideoLan
versão 0.7.1 Bond.Pertencente a rede B.
No que se refere ao monitoramento, o software JFFNMS(Just For Fun
NMS) foi instalado na máquina servidora e o monitoramento foi feito
observando a saída da sua placa de rede.
As redes A e B redes ethernet de 10Mbps, distantes 2 hops. Ambas
estão nas dependências da Universidade Federal de Goiás.
3. Transmissão e resultados
Seguindo as instruções simples de streaming do VLC, conseguimos
realizar uma transmissão tranqüila com qualidade total (visto que tínhamos
largura de banda a vontade – 10Mbps).
Cenário : Transmissão de arquivo Mpeg 1 Layer 3 (MP3) de 128kpbs
de qualidade fixa. redes distitas.
Hardware: Servidor e Cliente (especificado acima)
32
Rede: Servidor e Cliente em redes diferentes, distantes de 2 hops
entre si.
Arquivos: Lista de MP3s 128Kbits/s.
Duração: 30 minutos
Transmissão: Unicast
Para este caso, segue abaixo o gráfico gerado pelo JFFNMS.
Percebe-se que neste intervalo tivemos uma saída média de
186,31kbps (para MP3s de 128Kbps). Deste modo, temos um overhead
aproximado de 58,31kbps, ou seja, 45,5 % dos 186,31kbps. Este primeiro
relatório mostra a experiência com VideoLan client numa rede interna, com
o cenário descrito acima. Outros cenários serão descritos e testados para o
projeto final de curso de Engenharia de Computação.
33
Anexo 3: Guia de instalação do JFFNMS no Slackware Linux
Guia de Instalação do JFFNMS para Slackware GNU/Linux (testado em
versões 10.0 e 9.1)
Giovane Moreira- [email protected]
PoP-GO - RNP
Este guia é uma versão baseada no guia de instalação oficial do JFFNMS
disponível em http://www.jffnms.org. Esta versão é adaptada ao Slackware
(evita passos desnecessários e alguns bugs! ). Se você estiver fazendo upgrade
de uma versão anterior do JFFNMS, leia o arquivo UPGRADE. Agradecimentos a
Javier Szyszlican pela esta excelente ferramenta e pela documentação, além de
todo suporte.
Requerimentos:
-Sistema Operacional: Slackware GNU/Linux (testado com versões 9.1 e 10.0) JFFNMS roda em Solaris,*BSD e Window$ também.
-Apache - servidor web - o da instalação default serve
-Mysql - o da instalação default serve
-RRDTool - os fontes - Disponível em www.rrdtool.org para gerar os gráficos.
-PHP (>=4.1.2)
-NET-SNMP (4.2.5 ou 4.2.6) - Não incluso no Slackware - disponível em www.netsnmp.org
-GD - incluso na instalação full do Slackware
-GNU Diff - incluso na instalação full do Slackware
-TFTP Server (opicional)
-JFF NMS Integration Packages (TACACS+ & Syslog) (opcional, útil em roteadores)
-Graphviz & WebFonts (http://www.graphviz.org) (opcional)
-NMAP PortScanner > 2.54B (http://www.insecure.org/nmap/) para busca de portas
TCP (opcional)
-Fping (http://www.fping.com)
Instalando:
-Caso o seu Slackware não tenha o MySQL,compile e/ou instale ele. (tive problemas
com o da versão 9.1 - ele não estava startando threads * e matava a máquina -veja
mais sobre isto no final, porém o da 10.0 está normal).
-Caso o seu Slackware não tenha o Apache,compile e/ou instale ele. O .tgz default
do Slackware funciona muito bem :)
-Compile e/ou instale Graphviz and WebFonts (optional)
- Caso o seu Slackware não tenha o Nmap, compile-o e instale. (o default funciona
100%). O Nmap precisa ser set-uid root se você quiser monitoramento de portas UDP
e discovery funcionando Execute:
# chmod +s /usr/bin/nmap
# chmod a+x /usr/bin/nmap
34
-Compile e/ou instale o Fping.
-Verifique se o Cron está rodando (#ps aux |grep crond)
Execute:
# chmod +s /usr/local/sbin/fping
# chmod a+x /usr/local/sbin/fping
-Compile e instale RRDTool (com o ./configure --enable-shared -prefix=/usr) . JFFNMS irá usar estes binários.
-Compile e/ou instale o PHP (ATENÇÃO: O DEFAULT NÃO SERVE!). Voce terá duas
opções: puxar os sources e compilar com os parâmetros abaixo.
Os parâmetros são:
./configure --prefix=/usr --disable-static
--with-apxs=/usr/sbin/apxs --sysconfdir=/etc --enable-discard-path -with-config-file-path=/etc/apache --enable-safe-mode --with-openssl
--enable-bcmath --with-bz2 --with-pic --enable-calendar --enablectype --with-gdbm --with-db3 --enable-dbase --enable-ftp --with-iconv
--with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png -with-gmp --with-mysql=shared,/usr --with-xml=shared,/usr --withgettext=shared,/usr --with-mm=/usr --enable-trans-sid --enable-shmop
--enable-sockets --with-regex=php --enable-sysvsem --enable-sysvshm
--enable-yp --enable-memory-limit --with-tsrm-pthreads --enableshared --disable-debug --with-zlib=/usr --with-snmp --with-gd -enable-wddx
IMPORTANTE!
Módulos do PHP necessários: sockets, snmp,gd (pgslq e/ou mysql), wddx
(para satélites), pcre(syslog parsing).
Lembre-se de verifcar se seus módulos estão carregados da tela de
setup do JFFNMS (mais adiante mostra como)
Descomente a seguinte linha no /etc/apache/httpd.conf
Include /etc/apache/mod_php.conf
-Mude as seguintes opções no arquivo /etc/apache/php.ini
Register_Globals = On
error_reporting = E_ALL & ~E_NOTICE
allow_url_fopen = On
include_path = .:/usr/share/pear
- Reinicie o apache (qualquer mudança no php.ini requer reiniciar o
apache)
- Opcional: instale os pacotes de integração tac_plus e msyslog (leia
o README e o INSTALL de cada um deles) - particularmente quando
instalei não funcionou e deixei de lado.
- Descompacte a versão do JFFNMS
tar xvzf jffnms-0.7.x.tar.gz
Você então terá um diretório de nome jffnms-0.7.x.
35
-Mova-o para /opt/jffnms (mv jffnms-0.7.x. /opt/jffnms )
-Mude as permissões para o usuário nobody (do apache) poder acessar:
chown -R nobody.nogroup /opt/jffnms/
-Agora vamos adicionar ao cron os jobs a serem executados
su nobody
crontab -e
#adicione tudo abaixo
*/1 * * * * cd /opt/jffnms/engine && php -q consolidate.php >/dev/null 2>&1
*/5 * * * * cd /opt/jffnms/engine && php -q poller.php >/dev/null 2>&1
*/30 * * * * cd /opt/jffnms/engine && php -q rrd_analizer.php >/dev/null 2>&1
*/30 * * * * cd /opt/jffnms/engine && php -q autodiscovery_interfaces.php > /dev/null 2>&1
02 4 * * * cd /opt/jffnms/engine && php -q tftp_get_host_config.php >/dev/null 2>&1
02 5 * * * cd /opt/jffnms/engine && php -q cleanup_raw_tables.php >/dev/null 2>&1
20 5 * * * cd /opt/jffnms/engine && sh tmpwatch.sh /opt/jffnms/engine >/dev/null 2>&1
- Se você quiser saber o que significa cada linha, leia o guia oficial do site :)
- Criando a base de dados: (usei o MySql, porém pode ser o postgree. Se você
instalou o Slackware do zero, você deve executar mysql_install_db como root e
mudar as permissões do /var/lib/mysql para mysql.mysql) .
MySQL:
======
# mysql -u <mysql admin username> -p<password>
mysql> CREATE DATABASE jffnms;
mysql> GRANT ALL PRIVILEGES ON jffnms.* TO jffnms@localhost
IDENTIFIED BY 'jffnms';
mysql> FLUSH PRIVILEGES;
mysql> quit
# mysql -u jffnms -pjffnms jffnms < docs/jffnms-0.7.x.mysql
PostgreSQL:
===========
# psql template1 postgres
template1=# create user jffnms password 'jffnms' createdb;
template1=# \connect template1 jffnms
template1=# create database jffnms;
template1=# \q
# psql jffnms jffnms < docs/jffnms-0.7.x.pgsql
-Configurando o Apache.
Você tem dois modos de configurar:
1. Como um Virtual Host (se você controla um servidor DNS)
<VirtualHost *>
ServerAdmin [email protected]
DocumentRoot /opt/jffnms/htdocs
36
ServerName nms.yournet.com
</VirtualHost>
2. Com um link simbólico
ln -s /opt/jffnms/htdocs /var/www/htdocs/jffnms
(ou o diretório de páginas do seu apache)
O JFFNMS precisa estar ou em um desses modos ou também no main
Document Root (O Javier viu funcionado com ScriptAlias)
- Quase acabando.. restarte o apache, MySQL ou PgSQL, inetd.
- Abra o navegador em http://www.yourserver.com/jffnms/admin/setup.php (ou seu
domínio) ou http://localhost/jffnms/admin/setup.php
Este script mostrará se está tudo ok suas configurações, verifique todas as opções
antes de prosseguir.
- Depois de checar as opções, você está apto a acessar o JFFNMS .
Acesse http://www.yourserver.com/jffnms/ ou http://localhost/jffnms/
login: admin
password: admin
Agora você está no sistema. Agora vem a parte de configuração
- Esta é a ordem de criação dos registros:
Necessários:
Zones (vá em Admin/Hosts/Zones) - descreve as zonas geográficas
Customers(vá em Admin/Users/Customers) controlam diferentes interfaces
Hosts (vá em Admin/Hosts/Hosts) residem em Zonas
Interfaces (vá em Admin/Hosts/Interfaces) correspodem a um Host e um Customer
Opcional:
Users (vá em Admin/Users/Users) podem acessar o NMS.
Você pode definir seu submapa em Admin/Hosts/Submap)
E Fazer uma relação entre Interface e submap em View.
Tente não usar registros UNKNOWN (Uknown Host, Unknown Zone, Unknown
Customer,etc).
Créditos do Desenvolvedor:
====================================================
=====================
Se você precisar de algo, nos contate via: [email protected]
Obrigado por usar o 'Just For Fun' Network Management System
Não se esqueça do doar ao projeto se você o achar útil para seu trablalho.
====================================================
=====================
Javier Szyszlican aka SzYsZ
Buenos Aires, Argentina
[email protected] (please try the mailing list first)
37
ICQ #397319
Tradução e adaptação ao Slackware:
Giovane Moreira
Goiânia,Goiás, Brasil.
PoP-GO-RNP
[email protected]
[email protected]
38
Bibliografia resumida
Andrew S. Tanembaum, Redes de Computadores, Editora Campus,
2003.
Daniel A. Menascé e Virgílio A. F. Almeida, Planejamento de
Capacidade para Serviços na Web , Editora Campus, 2002.
Adolfo Rodriguez, John Gatrell, John Karas e Roland Peschke, TCP/IP
Tutorial and Techincal Overview, IBM Corporation, 2001.
JFFNMS - Just For Fun Network Management System, www.jffnms.org
Flow-tools, http://www.splintered.net/sw/flow-tools/
Cisco IOS Software Netflow,
http://www.cisco.com/warp/ public/732/Tech/nmp/netflow/index.shtml
Net-SNMP, http://net-snmp.sourceforge.net/
The Slackware Linux Project, http://www.slackware.com/
Progamando
em
http://www.devin.com.br/eitch/shell_script/
Shell
Script,
Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel,
O'Reilly, 2002.
RRDTool, http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
39