ago 172018
 

INTRODUÇÃO

 

A rede Tor é o que comumente chamamos de deep web, onde é possível encontrar diversos sites que não são indexados pelo Google e algumas outras ferramentas. A rede Tor é composta por um grupo de servidores voluntários que permite que as pessoas naveguem com privacidade e segurança.

Quando um usuário usa o navegador Tor, são realizadas diversas conexões com túneis virtuais até a destino original ser alcançado. Isso permite que você navegue em redes públicas sem comprometer a sua privacidade na rede. Na rede Tor é possível que você publique seu site sem precisar revelar sua atual localização. A principal ideia do Tor Project é ajudar as pessoas em países onde existe censura e monitoramento da internet, possibilitando assim que você se conecte de forma anônima.
Continue reading »

jun 292017
 

INTRODUÇÃO GERAL – EXEMPLOS E CONSELHOS

 

Artigo sobre uma das técnicas para ter um sistema GNU/Linux inteiro utilizando a rede TOR em uma máquina cliente.

Pode ser muito útil para quem queira utilizar o TOR com wget, curl, nmap etc. Ferramentas de rede em modo texto, ou mesmo gráfico, com o TOR/rede TOR. Este não é um artigo técnico ao extremo, é suficientemente técnico para a compreensão do funcionamento geral de um sistema “Torificado” como, por exemplo, o Tails OS.

Lembro que a segurança do sistema que veremos aqui (e de qualquer outro, de forma geral) depende de muitos fatores, como criptografia das conexões, resolução de DNS, as chaves utilizadas e, principalmente, do ser humano que o opera.

Requisitos gerais:

  • Sistema GNU/Linux
  • TOR
  • POLIPO proxy HTTP
  • IPtables
  • Manipulação de arquivos de configuração
  • Noções de redes, Proxys
  • Conexão com a internet
  • Vontade de aprender, muita leitura e trabalho duro (kkkk)

Continue reading »

COMO ENCONTRAR O NETID E O BROADCAST DE UMA DETERMINADA REDE

 Clusterweb, ClusterWeb, Debian, Leitura Recomendada, Linux, Profissional de TI, Redes, Segurança, Ubuntu  Comentários desativados em COMO ENCONTRAR O NETID E O BROADCAST DE UMA DETERMINADA REDE
set 052015
 

Autor: Wandson Sandro Rebelo Ramos <wanndson at gmail.com>

INTRODUÇÃO

 

Entender como funciona uma rede muitas vezes parece ser complicado, mas na verdade só basta ter um pouco de tempo para se dedicar e entender o que realmente você quer fazer. Sou professor de Redes de Computadores, e por muito tempo vi que meus alunos sempre esbarravam na parte de dividir a rede e tentar entender como funciona as máscaras, como repartir um determinado bloco e como é esse “negócio” de subnet, como muitos deles falavam.

Quando tem um IP que tem que descobrir o NetID e o Broadcast, isso muitas vezes parece ser coisa de outro mundo. Eu não lecionava para eles nos primeiros semestres, mas sim, do terceiro em diante. Neste período a maioria não entendia os conceitos de Início de Rede e Final de Rede e nas aulas de Linux e Serviços de Rede, isso me atrapalhava um pouco para ir adiante. Sei que também não era culpa dos meus colegas, pois eles repassavam da mesma maneira que foram ensinados. Então a partir do tempo que entrei para lecionar em uma Faculdade, resolvi testar este método, funcionou muito bem, muitos até fizeram prova de concurso e foram muito bem, agora que estou no Ensino Médio Profissionalizante, vejo que posso fazer isso mais cedo com os alunos, com isso eles ganham mais conhecimento e quando entram na faculdade já verificam coisas mais avançadas.

Então resolvi testar este método que já vinha usando quando trabalhava numa ISP (Internet Service Provider) na cidade aonde estou agora e aproveitar para o restante das pessoas que ainda tem dúvida.

Este método ajudou muitos deles a entender melhor o Início da Rede e Final da Rede, o range e as subnets que compunham uma determinada classe de IPs. Venho fazendo isso desde de 2003 e sempre me ajudou, principalmente no trabalho. Acredito que em provas da CISCO como o CCNA e da LPI do Linux, isso pode ser útil para poupar tempo na hora da execução da mesma.

Continue reading »

jun 292015
 

O jnettop é uma ferramenta muito interessante desenvolvida por Jakub Skopal, trata-se de um visualizador de trafego de rede. Com ele é possível acompanhar em tempo real o trafego de entrada e saída de uma interface, saber as portas envolvidas na sessão e conhecer também a banda consumida por cada requisição.

Atualmente o jnettop é suportado por muitas distribuições com pacotes RPM e DEB, mas se sua distribuição não suporta esses pacotes isso não é nenhum empecilho, pois trata-se de um programa muito simples, e mesmo uma pessoa sem experiência em compilação poderá instala-lo.

O nome jnettop tem origem no tradicional comando top usado largamente em vários sistemas unix, este tem como objetivo mostrar em tempo real o comportamento dos processos na maquina, exibindo os recursos consumidos, o tempo de execução e outras informações. O jnet tem origem na primeira letra do nome do autor do código (Jakub) seguida de net, abreviação de network. Em português pode parecer difícil falar jnettop, mas pelo contrário é muito simples, a pronuncia correta é jei-net-top. Continue reading »

Samba 4 Configurado para reportar a diferentes redes

 Clusterweb, Leitura Recomendada, Linux, Redes, Segurança  Comentários desativados em Samba 4 Configurado para reportar a diferentes redes
out 022013
 
Introdução

Recentemente, implementei o Samba 4 para um cliente que deu um pouco de trabalho, pois a infraestrutura contava com redes com várias subnets.Analisando a documentação oficial (SambaWiki), eu verifiquei que o próprio Samba roda um DNS interno. Porém, os computadores que precisavam ingressar no AD, fazem parte de redes diferentes e a configuração com o DNS interno não permitia fazer a comunicação dos computadores com o DC.

Para resolver esse problema, foi necessário encaminhar as requisições de resolução de nomes para o DNS principal da rede.

A imagem abaixo, mostra a infraestrutura básica para implementar o Samba 4:

Linux: Samba 4 - Configurado para reportar-se a diferentes redes

Observando a figura, temos duas redes neste cenário: Continue reading »

Implementação de uma Rede Mesh de Hotspot Mikrotik

 Clusterweb, Leitura Recomendada, Linux, Redes  Comentários desativados em Implementação de uma Rede Mesh de Hotspot Mikrotik
ago 232013
 

Antes de iniciarmos nosso projeto de rede Mesh vamos ver uma imagem do que vamos produzir

De início vamos configurar o Mikrotik de Borda (MK1) que terá uma das suas interfaces ligada ao roteador CISCO 1800 series, a interface ETHER1 será renomeada para LINK e receberá um IP fixo em quanto à interface ETHER2 será renomeada para LAN e também receberá um IP fixo. Continue reading »

Wireless WDS Mesh Network

 Clusterweb, Leitura Recomendada, Linux, Redes, Wireless  Comentários desativados em Wireless WDS Mesh Network
ago 232013
 

Mesh Network Is a Topology , That Topology Has Full Bidirectional Connectivity Between His Nodes .

In This Mode Every Node In Network ( Access Point ) Haven’t Only A Way To Other Nodes , But They Can Access To Other Network With Other Nodes .

In Concept Mesh Have Some Modes Such As ( Full Mesh , Partial Mesh Or Hybird Mesh And … ) And I Want To Describe Full And Partial Mesh Modes And Its Configuration In Mikrotik .

Mesh network Have Some Advantage Such As : Roaming Ability , Full Coverage , Redundancy And Fault Tolerance Between Some Links And Etc … Continue reading »

Observium – Monitoramento de Rede

 Clusterweb, Linux, Redes  Comentários desativados em Observium – Monitoramento de Rede
fev 262013
 

Observe sua rede com o Observium

Quando se fala em “sistema de monitoramento de rede open source”, um nome vem a cabeça: Cacti. É quase uma unanimidade, pela facilidade de utilização, por estar “empacotado” para as principais distribuições GNU/Linux, bastando um apt-get/yum install cacti e o sistema já está instalado. E também pela ampla documentação.

Há algum tempo atrás, por uma indicação de um colega da lista de discussão GTER, conheci o Observium e o tenho utilizado desde então, não como um substituto ao Cacti, mas sim como um complemento.

Sei que isso não é uma métrica muito confiável, mas fazendo uma busca pelo termo “cacti network monitoring” nos principais mecanismos de busca que temos hoje, os números são consideráveis.

Busca pelo termo “cacti network monitoring”:

  • Google: Aproximadamente 154.000 resultados;
  • Bing: Aproximadamente 104.000 resultados;
  • Yahoo: Aproximadamente 102.000 resultados.

Busca pelo termo “observium network monitoring”:

  • Goggle: Aproximadamente 8.460 resultados;
  • Bing: Aproximadamente 6.300 resultados;
  • Yahoo: Aproximadamente 6.320 resultados.

Em alguns sites do Brasil:

Este guia mostra como instalar o Observium no CentOS/RHEL/Scientific Linux.

Neste exemplo usei o CentOS 6.3 64 bits, mas para outras distribuições o processo é semelhante, pois a instalação do Observium é feita por SVN.

Repositórios

Para obter todos os módulos adicionais, é ideal ter os repositórios adicionais RPM Forge e EPEL:

# rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt
# rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
# rpm -Uvh http://mirror.globo.com/epel/6/x86_64/epel-release-6-8.noarch.rpm

Pacotes:

# yum install httpd.x86_64 mysql-server.x86_64 mysql.x86_64 php-gd.x86_64 php-mcrypt php-mysql.x86_64 php-pear net-snmp.x86_64 php-pear.noarch php-snmp.x86_64 php.x86_64 fping.x86_64 graphviz.x86_64 ImageMagick.x86_64 jwhois.x86_64 net-snmp-utils.x86_64 nmap.x86_64 OpenIPMI-tools.x86_64 rrdtool.x86_64 subversion.x86_64 vixie-cron.x86_64

# pear install Net_IPv6
# pear install Net_IPv4

Instalação do Observium

Criar o diretório:

# mkdir -p /opt/observium && cd /opt

Checar a última versão no repositório do Subversion:

# svn co http://www.observium.org/svn/observer/trunk observium

Mudar para o diretório de instalação:

# cd /opt/observium

Base de Dados

Criar a base de dados e o usuário:

mysql> CREATE DATABASE observium;
mysql> GRANT ALL PRIVILEGES ON observium.* TO ‘observium’@’localhost’ IDENTIFIED BY ‘<Senhas>’;

Configuração

Copie o arquivo de configuração padrão e faça as alterações necessárias:

# cp config.php.default config.php

Adicione uma entrada para o fping:

$config[‘fping’] = “/usr/sbin/fping”;

Configure o schema da base de dados:

# php includes/sql-schema/update.php

Alguns erros devem aparecer, isso é normal. Mas se forem mais do que 6, revise sua configuração.

Crie os diretórios “graphs” e “rrd” (* Lembre-se: ainda estamos abaixo do diretório /opt/observium):

# mkdir graphs rrd
# chown apache.apache graphs rrd

Obs.: O sistema não aceita rodar como um diretório. Exemplo: http://www.dominio.com/observium

Adicionar o primeiro usuário (use o nível 10 para admin):

# cd /opt/observium
# ./adduser.php <username> <password> <level>

Adicione o primeiro dispositivo para ser monitorado:

# ./addhost.php <hostname> <community> v2c

Obs.: DEVE-SE, obrigatoriamente, ter um nome válido, seja por DNS ou pelo /etc/hosts.

Faça uma verificação inicial do novo dispositivo:
# ./discovery.php -h all
# ./poller.php -h all

Adicione na crontab (Ex.: /etc/cron.d/observium) o conteúdo abaixo:

33 */6  * * *   root    /opt/observium/discovery.php -h all >> /dev/null 2>&1
*/5 *  * * *    root   /opt/observium/discovery.php -h new >> /dev/null 2>&1
*/5 *  * * *    root   /opt/observium/poller.php -h all >> /dev/null 2>&1

Faça um reload/restart no serviço:

# /etc/init.d/crond reload/restart

O sistema já estará disponível em: http://<server ip>

Atualização

É utilizado o SVN para a atualização, bastando executar o comando abaixo:

# cd /opt/observium
# svn update
# ./discovery.php -h new

Billing e outras configurações

Billing

Uma função muito útil e interessante é o Billing, onde você pode contabilizar a utilização de uma ou mais portas.

Como podemos ver na imagem, pelo menos aqui, o Barrichello está na frente de do Schumacher e do Senna. 🙂

Para ativá-lo, altere a linha abaixo no “config.php”:

$config[‘enable_billing’] = 1;

E adicione as linhas abaixo no /etc/cron.d/observium:

*/5 *  * * *   root    /opt/observium/poll-billing.php >> /dev/null 2>&1
01 *  * * *   root    /opt/observium/billing-calculate.php >> /dev/null 2>&1

 

Desativar itens

Por padrão, quando você adiciona um dispositivo, ele traz todas as configurações de rede.

Num servidor Windows, que eu usei como exemplo para montar este tutorial, ele acaba trazendo uma série de interfaces que não precisam ser vistas, o que num primeiro momento pode deixar o visual um pouco poluído, ao contrário do Cacti, que você precisa especificar o quer que seja monitorado.

Na imagem abaixo podemos ver o Item Ports com todos os itens habilitados:

Para desativar estes itens, siga os passos abaixo ao acessar a interface WEB:

Devices → All Devices → *NomeDoServidor* → Edit (a chave que fica bem escondida bem à direita) → Ports

Nas colunas “Polling” e “Alerts”, deixe todos os itens no “No”, com exceção da placa de rede que você quer monitorar.

Na mesma tela no item “Modules”, estão todos os módulos que, por padrão, vem todos ativados:

Redirecionar todo tráfego HTTP para HTTPS

Pode parecer óbvio, mas tenho por padrão não usar HTTP para qualquer serviço WEB, somente HTTPS.

Para isso, redireciono todo o tráfego alterando os arquivos abaixo:

1. /etc/httpd/conf/httpd.conf:

NameVirtualHost *:80

<VirtualHost *:80>

RewriteEngine    on
RewriteCond      %{SERVER_PORT} ^80$
RewriteRule       ^(.*)$ https://%{SERVER_NAME}$1 [L,R]

</VirtualHost>

2. /etc/httpd/conf.d/ssl.conf (arquivo padrão do SSL):

LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog builtin

SSLSessionCache   shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
NameVirtualHost *:443

SSLMutex default

SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost *:443>

ServerName wiki.domain.net:443
ServerAlias wiki.domain.com:443

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars
</Files>
<Directory “/home/viaza132/www/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

</VirtualHost>

3. /etc/httpd/conf.d/ssl-observium.conf (este arquivo não existe, deve ser criado):

<VirtualHost *:443>

ServerName observium.domain.net:443
ServerAlias observium.domain.com:443

DocumentRoot “/opt/observium/html”

<Directory /opt/observium/html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
AuthUserFile /home/viaza132/www/.htpasswd
AuthName “Please enter your ID and password”
AuthType Basic
require valid-user
Order allow,deny
Allow from all
</Directory>

ErrorLog logs/ssl-observium_error_log
TransferLog logs/ssl-observium_access_log
LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars
</Files>
<Directory “/home/viaza132/www/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent “.*MSIE.*” \     nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

</VirtualHost>

Além de tudo, proteger o acesso com senha:

# htpasswd /home/viaza132/www/.htpasswd admin

Tela dos dispositivos configurados com algumas informações básicas:

Tela de status dos dispositivos:

Algumas outras checagens que ele faz por padrão (Memory, CPU e Disk Usage):

Hyperic HQ: monitore sua rede like a boss

 Leitura Recomendada, Redes  Comentários desativados em Hyperic HQ: monitore sua rede like a boss
nov 052012
 
Sobre o Hyperic HQ

O Hyperic HQ é uma solução de monitoramento, administração e controle de infraestrutura de Data Centers. Trata-se de um Software Livre, disponibilizado sob a licença GNU GPL v2, com o código-fonte hospedado no SourceForge.net, que conta com um versão comercial disponível com recursos adicionais de automação, administração e controle.

Foi desenvolvido pela empresa americana Hyperic, sediada em São Francisco. Em 2009, a história da empresa mudaria radicalmente. Em maio, ela seria adquirida pela SpringSource e, em Agosto, a própria SpringSource seria adquirida pela gigante VMware.

Hoje, a versão para empresas do Hyperic HQ é comercializada com o nome de VMware vFabric Hyperic.

Conheci o Hyperic em 2007, quando trabalhava na Unimed Leste Fluminense, em Niterói/RJ, e recebi a missão de configurar um sistema de monitoramento na rede da empresa.

Avaliei algumas soluções, como Nagios, Cacti e Zenoss. Embora funcionassem, me incomodava a complexidade para configurar monitoramento e alarmes em cada uma destas soluções (não era necessariamente difícil, mas, ou exigia uma quantidade incontável de passos manuais, como instalação de componentes, edição de arquivos de texto, e/ou cliques e mais cliques de mouse).

   

Então, descobri o Hyperic HQ, que caiu como uma luva: além de ser um Software Livre, com código-fonte aberto, possuía:

  • Recursos de descobrimento automático de novos recursos;
  • Gerava gráficos automaticamente;
  • Permitia criar alarmes sofisticados com suporte a escalation;
  • Notificações por SMS;
  • Análise de logs;
  • Histórico de incidentes.

E o melhor: tudo empacotado adequadamente e acompanhado de uma excelente documentação que tornava o processo de instalação e configuração da solução uma tarefa extremamente simples.

Desde então, o Hyperic HQ é minha solução de monitoramento favorita.

Arquitetura

O Hyperic HQ é constituído de dois componentes: o servidor e o agente. Que comunicam-se de acordo com o diagrama mostrado no diagrama abaixo.

O servidor é instalado em uma única máquina. Ele é responsável por receber todos os dados de monitoramento, processá-los e gerar gráficos, alertas e relatórios, mantendo histórico dos eventos.

O agente, por sua vez, é responsável por varrer a máquina onde ele está instalado, detectando os componentes que estão instalados, coletando suas métricas e enviando-as ao servidor.

Todos os dados coletados ficam armazenados localmente e enviados ao servidor em intervalos regulares. Com isso, mesmo que o servidor Hyperic fique fora do ar, nenhuma informação de monitoramento é perdida, pois fica armazenada localmente nos agentes, até que estes possam enviá-la para o servidor.

Instalação do servidor Hyperic HQ

O servidor do Hyperic HQpode ser instalado nos seguinte sistemas operacionais:

  • GNU/Linux;
  • Windows;
  • Solaris Sparc;
  • Mac OS X.

Neste artigo, mostrarei como instalar a versão 4.6.6 do servidor Hyperic HQ no CentOS 6, uma distribuição GNU/Linux criada a partir do código-fonte do Red Hat Enterprise Linux 6.

Para os passos mostrados abaixo, considero que você já possua uma instalação funcional do CentOS 6.

O primeiro passo é criar o grupo e o usuário que será utilizado para executar o Hyperic. Faça isso usando os comandos abaixo:

$ su –

# groupadd -r hyperic
# useradd -g hyperic -s /bin/bash -d /opt/hyperic -c “Hyperic HQ” -m hyperic

Em seguida, alterne para o usuário hyperic recém-criado e faça o download do instalador do Hyperic HQ para GNU/Linux, que contém o servidor e o agente no mesmo pacote. Há instaladores para arquiteturas 32 e 64 bits. Neste artigo, será usada a arquitetura 32bits (x86).

# su – hyperic
$ wget
http://sourceforge.net/projects/hyperic-hq/files/Hyperic%204.6.6/Hyperic%204.6.6-GA/hyperic-hq-installer-4.6.6-x86-linux.tar.gz
$ tar xf hyperic-hq-installer-4.6.6-x86-linux.tar.gz
$ cd hyperic-hq-installer-4.6.6
$ ./setup.sh

Serão solicitadas algumas informações que você deverá fornecer, na ordem:

  1. 1,2 (para instalar o servidor e o agente);
  2. /opt/hyperic (diretório de instalação do servidor Hyperic);
  3. remetente@seudominio.com (email que será usado como remetente dos alertas do Hyperic);
  4. 1 (para utilizar uma frase gerada automaticamente para criptografar o banco de dados);
  5. loginadministrativo (login do usuário administrador do Hyperic – o padrão é ‘hqadmin’);
  6. senhadeadministrador (senha do administrador do Hyperic);
  7. mesmasenhanovamente (repita a senha);
  8. emaildoadministrador (endereço de email do usuário administrador, para onde serão enviadas as notificações direcionadas para este usuário);
  9. /opt/hyperic (diretório de instalação do agente Hyperic);

Em determinado momento, o instalador lhe pedirá para executar um comando como root e então, pressionar Enter para continuar a instalação.

Se você estiver no modo gráfico, abra um novo terminal. Se estiver no modo texto, alterne para outro console usando as teclas Alt+FN, ou N é um número de 1 a 6 (Ex.: Alt+F2 para ir para o console 2), faça login como root e execute o comando abaixo:

# /opt/hyperic/hyperic-hq-installer-4.6.6/installer/data/hqdb/tune-os.sh

Então, retorne para o terminal/console anterior e pressione Enter para concluir a instalação. Se tudo correr bem, você deverá ver a seguinte mensagem no final do processo:

Setup completed
A copy of the output shown above has been saved to:
/opt/hyperic/hyperic-hq-installer-4.6.6/installer/logs/hq-install.log

Antes de iniciar o servidor e o agente do Hyperic, é interessante fazer alguns ajustes para facilitar o gerenciamento destes serviços, além de futuras instalações.

Primeiro, crie dois links simbólicos chamados “server” e “agent”, apontando para os diretórios: server-4.6.6 e agent-4.6.6, respectivamente.

$ cd
$ ln -sv server-4.6.6 server
$ ln -sv agent-4.6.6 agent

Depois, edite o arquivo “.bash_profile”, procure pela linha que define a variável PATH e modifique-a de modo que fique com o seguinte conteúdo:

AGENT_DIR=”/opt/hyperic/agent”
SERVER_DIR=”/opt/hyperic/server”
PATH=$PATH:$HOME/bin:$AGENT_DIR/bin:$SERVER_DIR/bin

Então, carregue o arquivo “.bash_profile” para atualizar as variáveis alteradas:

$ source .bash_profile

Retorne ao segundo terminal/console onde você logou-se como root e verifique o arquivo /etc/hosts. É preciso ter uma entrada associando o IP principal do servidor ao nome da máquina.

Antes de mais nada, verifique se o nome da máquina está corretamente definido, executando o comando hostname:

# hostname

localhost.localdomain

No exemplo acima, o hostname não está definido. Escolha um nome e então edite o arquivo /etc/sysconfig/network, alterando a variável HOSTNAME para o valor do hostname escolhido, incluindo o nome do domínio:

HOSTNAME=hyperic.davidsonpaulo.com

Então, use o comando hostname para forçar a utilização do novo nome de máquina:

# hostname hyperic.davidsonpaulo.com

Depois, edite o arquivo /etc/resolv.conf e adicione a seguinte linha no começo do arquivo, para que o servidor trate adequadamente o domínio escolhido:

search davidsonpaulo.com

Por fim, edite o arquivo /etc/hosts e adicione uma entrada para associar o hostname da sua máquina ao seu IP principal, que neste exemplo, é 192.168.1.10:

192.168.1.10    hyperic.davidsonpaulo.com    hyperic

Feito isso, retorno para o primeiro terminal/console e inicie o servidor Hyperic HQ usando o comando abaixo:

$ hq-server.sh start

Aguarde alguns segundos e verifique se existem processos escutando nas portas 9432/TCP e 7080/TCP:

$ fuser -i 9432/tcp

9432/tcp:        2046   2082   2083   2084& nbsp;  2085   2086

$ fuser -i 7080/tcp

7080/tcp        2068

Isto significa que o servidor Hyperic foi inicializado corretamente. Para confirmar, acesse a interface administrativa através da URL:

  • http://[IP do Servidor]:7080

Note que, se o firewall do CentOS estiver habilitado, a porta 7080 estará bloqueada por padrão. Se for esse o caso, libere as portas 7080 e 7443 usando os comandos abaixo:

# iptables -I INPUT -p tcp -m state –state NEW -m multiport –dports 7080,7443 -j ACCEPT
# service iptables save

As figuras abaixo, mostram a tela principal do Hyperic HQ e o painel de controle, ou Dashboard, para onde o usuário é direcionado após fazer o login:

Linux: Hyperic HQ: monitore sua rede like a boss     Linux: Hyperic HQ: monitore sua rede like a boss
Configuração do agente Hyperic HQ

Agora que o servidor está funcionando, precisamos configurar um agente do Hyperic HQ para monitorar a primeira máquina.

Quando instalamos o servidor, o agente foi instalado também, portanto, tudo o que precisamos fazer é inicializá-lo e conectá-lo ao servidor, executando o comando abaixo:

$ hq-agent.sh start

Na primeira inicialização do agente do Hyperic HQ, será necessário fornecer algumas informações para que ele consiga conectar-se ao servidor e enviar os dados de monitoramento:

  • What is the HQ server IP address: hyperic.davidsonpaulo.com
  • Should Agent communications to HQ always be secure: yes
  • What is the HQ server SSL port: 7443
  • Are you sure you want to continue connecting? Yes
  • What is your HQ login: loginadministrativo
  • What is your HQ password: senhadeadministrador
  • What IP should HQ use to contact the agent: hyperic.davidsonpaulo.com
  • What port should HQ use to contact the agent: 2144
  • Are you sure you want to continue connecting? yes

Uma vez concluída a configuração do agente, retorne à interface administrativa do Hyperic HQ e veja se a máquina é exibida no portlet Auto-Discovery.

Para começar a coletar as métricas e gerar gráficos para este servidor, clique no botão Add to Inventory. A máquina sairá do portlet Auto-Discovery e será exibida no portlet Recently Added.

Clique no link para abrir os detalhes de monitoramento da máquina, que a princípio estarão quase totalmente vazios.

Como você pode ver, muitas coisas são detectadas e começam a ser monitoradas automaticamente. Abaixo, uma listagem completa de todos os componentes e serviços que foram detectados neste exemplo:

  • Platform services
    • Free Memory;
    • Free Memory (+buffers/cache);
    • Load Average 5 Minutes;
    • Swap Used.
  • FileServer Mount
    • /dev/mapper/VolGroup00-LogVol00
    • /dev/sda1
  • NetworkServer Interface
    • Métricas
      • Bits Received per Second;
      • Bits Transmitted per Second;
      • Packets Received per Minute;
      • Packets Transmitted per Minute.
    • Interfaces
      • Linux Network Interface eth0 (ethernet);
      • Linux Network Interface eth1 (ethernet);
      • Linux Network Interface lo (loopback).
  • Linux CPU 1 (2916MHz Intel Core(TM) i7 CPU 870 @ 2.93GHz)
    • CPU Idle;
    • CPU Usage;
    • System Cpu;
    • User Cpu.
  • Linux sshd Process
    • Cpu Usage;
    • Resident Memory Size.
  • HQ ActiveMQ Embedded 5.3
    • Métricas
      • Process Cpu Usage;
      • Process Resident Memory Size.
    • Serviços
      • ActiveMQ Embedded 5.3 Topic
        • Dequeue Count per Minute;
        • Enqueue Count per Minute;
        • Queue Size.
      • Localhost Broker
        • Total Enqueue Count per Minute;
        • Total Message Count per Minute.
    • HQ Agent 4.6.6
      • JVM Free Memory;
      • JVM Total Memory;
      • Number os Metrics Collected per Minute;
      • Number of Metrics Sent to Server per Minute;
      • Server Offset;
      • Total Time Spent Fetching Metrics per Minute.
    • HQ PostgreSQL 8.2
      • Métricas
        • Backends;
        • Blocks Read per Minute;
        • Commits per Minute;
        • Data Space Used.
      • Serviços
        • Table
          • Data Space Used;
          • Index Space Used;
          • Number Of Row Inserts per Minute;
          • Sequential Scans per Minute.
    • HQ Tomcat 6.0
      • Métricas
        • Heap Memory Free;
        • Process Cpu Time per Minute;
        • UpTime.
      • Serviços
        • Global Request Processor
          • Error Count per Minute;
          • Processing Time per Minute;
          • Request Count per Minute.
        • Servlet Monitor
          • Error Count per Minute;
          • Request Count per Minute.
        • Thread Pools
          • Current Trhead Busy;
          • Current Thread Count.
        • HQ Internals
          • Metric Inserts Per Minute;
          • Metrics Collected Per Minute.
        • hq Hibernate Session Factory
          • Entity Fetch Count per Minute;
          • Entity Insert Count per Minute;
          • Query Execution Count per Minute;
          • Query Execution Max Time.
        • Cache
          • Access Count per Minute;
          • Hits Count per Minute.
        • Web Module Stats
          • Processing Time.
        • JSP Monitor
          • JSP Count per Minute;
          • JSP Reload Count per Minute.
        • tomcat.jdbc Hyperic Data Source
          • Active Connections;
          • Idle Connections.

Impressionante, não?

Imagine só quanto tempo levaria para habilitar todos estes monitoramentos, com indicadores de disponibilidade e gráficos em soluções, como Nagios, Icinga, Zabbix ou Cacti. Sentiu calafrios ao pensar em todo o trabalho que teria?

Monitoramento e visualização

Personalizando o monitoramento

Agora que o servidor já está sendo monitorado, é hora de revisar as métricas, descartando aquelas que não nos interessam e habilitando outras que necessitamos.

Vamos tomar como exemplo, as métricas básicas do servidor, as chamadas Platform Services:

  • Free Memory;
  • Free Memory (+buffers/cache);
  • Load Average 5 Minutes;
  • Swap Used.

Primeiramente, vamos desligar o monitoramento da métrica Free Memory(+buffers/cache). Para isso, clique na aba METRIC DATA, selecione a métrica e clique no botão DISABLE COLLECTION.

Depois, clique em INDICATORS e remova o gráfico da métrica excluída, clicando no botão em formato de X à direita de seu título e clicando no botão em formato de seta para à direita ao lado de “Update Default”.

Para habilitar uma métrica que não está sendo monitorada, clique em METRIC DATA e depois em Show All Metrics. Selecione a(s) métrica(s) que você deseja monitorar (Ex.: System CPU, Used Memory e User CPU) e, logo abaixo, selecione o intervalo de atualização das métricas no campo Collection Interval for Selected (Ex.: 5 minutos). Depois, confirme clicando no botão em formato de seta à direita.

Clique, então, em INDICATORS e aguarde de 2 a 5 minutos até que as novas métricas sejam exibidas na seção All Metrics e, então, clique no botão em formato de seta à direita para cada uma delas, e seus gráficos serão adicionados ao painel de visualização central.

Para tornar a alteração permanente, clique no botão em formato de seta à direita, ao lado de Update Default.

Use estes procedimentos para personalizar as métricas monitoradas, para cada serviço que tenha sido detectado pelo agente do Hyperic HQ.

Criando painéis de visualização

Como você deve ter percebido, os gráficos das métricas ficam empilhados um sobre o outro num painel central, chamado painel de visualização, ou apenas View.

Para fins de organização, você pode criar diversos painéis de visualização, colocando diferentes gráficos em cada um deles de acordo com os critérios que lhe forem mais convenientes.

Para demonstrar a funcionalidade, vamos criar um painel adicional contendo informações de estados de conexões TCP. O primeiro passo é habilitar o monitoramento dessas métricas, clicando em METRIC DATA, Show All Metrics, selecionando todas as métricas do tipo Tcp State e habilitando o Collection Interval para 5 minutos.

Depois clique em INDICATORS e aguarde de 2 a 5 minutos até que as métricas sejam exibidas na seção All Metrics. Então, remova todos os gráficos do painel central e adicione somente as métricas do tipo Tcp State.

Em seguida, ao lado da opção View, selecione a opção Create New View, digite o nome da nova visualização (TCP State) e clique no botão em forma de seta, à direita.

Você terá agora dois painéis de visualização: o Default, que já existia e que contém os gráficos de memória e CPU, e o TCP State, que foi criado e que contém os gráficos de Tcp State.

Você pode criar quantos painéis de visualização desejar, organizando os gráficos da maneira que lhe for mais conveniente.

Configurando novos monitoramentos manualmente

O sistema de detecção e monitoramento automático do Hyperic HQ é excelente, mas não detecta tudo. Existem serviços que, embora sejam suportados, simplesmente não serão detectados ou precisarão de alguns ajustes para serem monitorados totalmente.

Veremos a seguir, como habilitar manualmente o monitoramento de alguns serviços que não tenham sido detectados automaticamente pelo Hyperic HQ, para que você tenha uma ideia de como isso é feito.

Monitorando um processo genérico

Ao instalar o agente Hyperic HQ num servidor Linux ou Unix que possua o servidor SSH roddando, o processo sshd é monitorado automaticamente.

Se quisermos configurar outros processos, isso pode ser feito facilmente. Basta clicar em Tools Menu e selecionar a opção New Service e fornecer o nome, a descrição e o tipo do serviço que será monitorado (nesse caso, Process).

Na tela que se abre, vá na seção Configuration Properties e clique em EDIT. Preencha o campo “process.query” com o valor:

Pid.PidFile.eq=/var/run/crond.pid

E clique em OK. Depois, clique na aba Monitor, aguarde 5 minutos e atualize a página.

Monitorando Apache 2.2

Acesse o servidor onde o Apache está instalado e insira o conteúdo abaixo, no arquivo /etc/httpd/conf.d/hyperic.conf (no CentOS):

ExtendedStatus On
NameVirtualHost localhost:80

<VirtualHost localhost:80>
ServerName localhost:80

<Location /server-status>
SetHandler server-status
Allow From 127.0.0.1
</Location>
</VirtualHost>

Em seguida, reinicie o serviço para que as alterações entrem em vigor.

# apachectl restart

Depois, ajustes as permissões dos logs do Apache. Isto é necessário para que o usuário “hyperic” consiga acessá-los.

# chgrp -R apache /var/log/httpd
# find /var/log/httpd -type d -exec chmod 0750 {} \;
# find /var/log/httpd -type f -exec chmod 0640 {} \;

Em seguida, adicione o usuário “hyperic” ao grupo apache e reinicie o agente de monitoramento:

# gpasswd -a hyperic apache
# su – hyperic

$ hq-agent.sh restart
$ exit

Por fim, edite o arquivo /etc/sudoers e adicione a linha abaixo para permitir que o Hyperic HQ possa controlar o Apache usando o comando apachectl, através do comando sudo.

hyperic ALL=(root) NOPASSWD: /usr/sbin/apachectl

Agora, acesse a interface de gerenciamento do Hyperic e faça login. Se o Apache ainda não estava instalado, é provável que ele tenha sido detectado e seja exibido no portlet Auto-Discovery.

Se for esse o caso, clique em Add to Inventory. Se, por outro lado, o Apache já estava instalado na máquina antes de o agente do Hyperic ser configurado, é já deve ter sido detectado anteriormente, e só necessitará ser configurado adequadamente.

Clique na aba Resources, localize o servidor onde o Apache está instalado e clique sobre ele. O Apache deverá ser então listado na seção Deployed Servers Health, clique sobre ele, acesse a aba Inventory e, na seção Configuration Properties, clique em EDIT.

Preencha os campos como mostrados na lista abaixo, clique em OK e depois acesse a aba Monitor.

hostname: localhost;
port: 80;
path: /server-status
pidfile: /etc/httpd/run/httpd.pid;
program: /usr/sbin/apachectl;
prefix: sudo

Para o Apache e para outros tipos de servidores, o Hyperic HQ oferece o recurso de controle remoto, ou seja, você pode iniciar, parar, reiniciar ou consultar o status do serviço diretamente a partir da console do Hyperic. Essas funções, quando disponíveis, ficam dispostas na aba Control.

Definindo um alerta

Um dos recursos fundamentais de qualquer software de monitoramento, é a geração de alertas, que notificam o administrador quando algum serviço não está funcionando dentro das condições consideradas satisfatórias.

Para definir um novo alerta no Hyperic HQ, o primeiro passo é localizar o objeto que contem a métrica que será analisada para gerar o alarme. Como exemplo, vamos criar um alerta para quando houver pouca memória RAM livre no servidor “hyperic.davidsonpaulo.com”.

Ao abrirmos este servidor, encontramos a métrica Free Memory que indica a quantidade de memória livre. Ao clicar sobre o título da métrica, somos direcionados para seu gráfico detalhado. No canto superior direito, existe um link chamado Define New Alert.

Basta clicar nele e seremos direcionados para o formulário de definição de novo alerta.

Primeiramente, preenchemos os campos da seção Alert Properties: nome, descrição, prioridade, e o alerta deverá ficar ativo imediatamente após a sua configuração.

Depois, devemos selecionar qual será o gatilho do alarme, na subseção If Condition da seção Condition Set. Existem quatro possibilidades:

  1. Metric → Se o valor absoluto da métrica selecionada for menor, maior, igual ou diferente de um valor escolhido;
  2. Inventory Property → Se alguma propriedade fixa do servidor (ex.: arquitetura do processador, IP, gateway padrão etc) for alterada;
  3. Events/Logs Level → Se for encontrada um registro em algum arquivo de log associado que possua os caracteres escolhidos;
  4. Config changed → Se o arquivo de configuração selecionado for alterado.

Neste exemplo, nosso objetivo é disparar o alerta caso o nível da métrica Free Memory seja muito baixo. Então, selecionamos a opção Metric e a métrica Free Memory.

Abaixo, selecionamos a opção: is < (Less than)

E digitamos o limite escolhido de 64MB.

Em seguida, selecionamos o critério para disparo do alarme e sua periodicidade. Os critérios para disparo são dois, a saber:

  1. Each time conditions are met → O alarme será disparado assim que as condições de alarme ocorrerem;
  2. Once every <N> times conditions are met within a time period of <M><unidades> → O alarme só será disparado se as condições alarme ocorrerem N vezes dentro de um período de M unidades de tempo.

A periodicidade do alerta é definida pela opção Generate on alert and then disable alert definition until fixed. Se esta opção estiver desmarcada, um novo alerta será gerado a cada vez que as condições de alarme ocorrerem até que o problema seja resolvido. Se estiver marcada, um único alerta será gerado.

Em nosso exemplo, definiremos o alerta para somente ser disparado se as condições de alarme ocorrem 10 vezes, seguidas, ou seja, 10 vezes nos últimos 10 minutos. Também definiremos que ele seja gerado uma única vez.

Depois de criar o alarme, precisamos configurar a notificação externa. O Hyperic HQ suporta quatro tipos de notificações:

  1. Escalation→ Uma espécie de roteiro de notificação que permite escalar o problema automaticamente para diferentes níveis do suporte. É possível configurar, por exemplo, uma sequência similar a:
    1. Notificar o suporte nível 1 e aguardar 20 minutos;
    2. Notificar o suporte nível 2 e aguardar 20 minutos;
    3. Notificar a supervisão e aguardar 15 minutos;
    4. Notificar a gerência e aguardar 20 minutos;
    5. Notificar a diretoria, aguardar 20 minutos e então, repetir o ciclo de notificações.
  2. Notify HQ Users → É possível cadastrar usuários no Hyperic HQ e associar endereços de e-mail para facilitar a seleção dos destinatários dos alertas;
  3. Notify Other Recipients → Enviar os alertas para endereços de e-mail que não estejam associados a nenhum usuário do Hyperic HQ;
  4. OpenNMS → Notificar o alerta através do OpenNMS, caso haja algum servidor instalado na rede.

Em nosso exemplo, escolheremos a opção Notify HQ Users. Clique em ADD TO LIST, selecione o usuário administrador, clique na seta para a direita e então, em OK.

Linux: Hyperic HQ: monitore sua rede like a boss    Linux: Hyperic HQ: monitore sua rede like a boss

Feito isso, o alerta estará definido.

Quando a métrica Free Memory indicar um valor menor que 64MB 10 vezes seguidas num intervalo de 10 minutos, um alerta será gerado e enviado por e-mail para o destinatário admin@davidsonpaulo.com.

Dicas valiosas

Os exemplos mostrados nesta matéria devem permitir que o amigo leitor consiga realizar a instalação e configuração básica do Hyperic HQ em seu ambiente de testes e então, descubra mais de suas várias funcionalidades, que não tratei nesta matéria para não deixá-la demasiadamente grande.

Então, antes de encerrar, deixarei algumas dicas que serão de grande valia para você.

  • O Hyperic não monitorá corretamente uma máquina se o seu horário estiver com alguns segundos de diferença em relação à máquina do servidor Hyperic. Para evitar problemas, configure um servidor de hora na sua rede e configure todos os seus servidores para sincronizarem seus relógios com ele utilizando NTP;
  • Para criar, editar e excluir escalations, acesse a aba Administration e clique em Escalation Schemes Configuration;
  • Se tiver dúvidas, consulte a documentação oficial do Hyperic HQ, que é excelente (em inglês);
  • Em meu blog você pode encontrar tutoriais de como monitorar Oracle 9g e Squid usando o Hyperic HQ.