Arquivo da categoria: Linux

Assuntos relacionados ao sistema Linux propriamente dito.

Failover automático com Keepalived

Alta disponibilidade é um assunto sempre discutido entre as rodas de nerds e pela alta cúpula das corporações. Afinal, garantir que sua aplicação esteja disponível mesmo em caso de uma presente falha, é algo que chama muito a atenção, e claro, isso faz com que o pessoal da área estratégica e negócio das corporações fiquem fascinados e motivados a implementar essas soluções em seu ambiente de tecnologia.

Porém quando esse assunto é discutido, são envolvidas muitas teorias que fazem desse tipo de solução algo extremamente complexo ou mesmo místico, chegando beirar o nebuloso entre alguns profissionais da área.

Antes de iniciarmos a parte prática é importante entendermos que alta disponibilidade é um conceito, não um serviço, então logicamente existem dezenas de ferramentas que oferecem essa solução.

Resumindo, de forma breve, a alta disponibilidade é garantir que minha aplicação ou serviço fique no ar mesmo em caso de falha. E esse serviço ou aplicação tem um IP que é popularmente conhecido como VIP (Virtual IP), esse VIP é um endereço IP flutuante, que fica no servidor ativo, ou seja, o mestre do cluster, isso quando estamos trabalhando com o modelo failover (passivo/ativo), onde você tem um mestre e um escravo. Quando você trabalha com o modelo de balanceamento de carga, o endereço VIP, é o IP flutuante do seu servidor e/ou balanceador de carga, que tem o papel de distribuir as requisições para o pool de servidores que esta atrás dele. Caso você queira saber mais sobre alta disponibilidade, segue o link onde esse assunto foi abordado em seu conceito de forma mais extensa: Link de HA

No post de hoje não só vamos esclarecer como funciona o faliover como vamos implementá-lo na prática. Importante salientar que o keepalived também pode trabalhar em balanceamento de carga em conjunto com ipvsadm, que usa o recurso de IPVS do kernel Linux, que nada mais é que um balanceador de carga sob camada 4 do modelo OSI (Camada de transporte).

A solução open source que vamos adotar neste post como já esclarecido acima é o keepalived, uma solução extremamente eficiente e digna de respeito, apresentando-se uma alternativa a altura do “falecido” projeto heartbeat, antiga solução de failover que foi muito adotada pela comunidade open source no passado.

Obviamente existem outras soluções que atendem esse propósito e que são até mais populares que o próprio keepalived, como o Pacemaker por exemplo, porém aqui no post foquei no objetivo de exemplificar e praticar o assunto de alta disponibilidade passivo/ativo de forma simples. Obviamente uma solução como o pacemaker é excelente, e atende diversos requisitos que provavelmente o keepalived não atenda, enquanto o pacemaker é uma ferramenta completa de alta disponibilidade, focada totalmente em prover tolerância a falha e gerenciamento de cluster.

Já deu né? Agora bora por a mão na massa! Como de praxe, faremos nas duas principais famílias de distribuições Linux do mercado: Debian (8) e CentOS (7).

Primeiramente vamos definir nosso ambiente. Para esse laboratório você precisa de 2 servidores no mínimo, sendo um mestre e um escravo (independente da distro que você escolher).

Então vamos para provavelmente o passo mais importante, instalar o keepalived. O keepalived esta disponível através do repositório da distribuição, com exceção da família Red Hat, onde o mesmo esta disponível via repositório EPEL (Extras Packages Enterprise Linux), caso você use o Red Hat puro, acionar o suporte da Red Hat para habilitar o repositório correto conforme orientação do suporte da mesma.

O failover que faremos aqui será em cima do serviço nginx, apenas porque optei por fazê-lo com esse serviço, por mera conveniência, caso você opte por outro serviço em seu laboratório, não vejo problema algum.

A instalação abaixo se aplica nos dois nós do cluster, ok?

# yum install epel-release -y
# yum install keepalived nginx -y

# apt-get update
# apt-get install keepalived nginx -y

Feita a instalação precisamos ajustar o arquivo de configuração do keepalived para que o serviço tenha declarado qual o endereço IP flutuante (VIP, lembre-se desse cara!) e para saber qual seu papel dentro do cluster, além disso, nele também consta qual o serviço que ele vai monitorar, no nosso laboratório, será o nginx.

No seu servidor mestre, você irá adicionar o arquivo de configuração abaixo. Nesse arquivo consta o nome do seu script de checagem, que pode ser qualquer nome, o script propriamente dito define qual serviço ele ira verificar se esta no ar ou não, o pidof como a maioria já sabe verifica se existem processos daquele serviço pesquisado, caso exista o retorno será sempre 0, caso não encontre, o retorno é diferente de 0 e portanto o cluster promove o escravo, nomeando como mestre e adicionando o IP flutuante nele.

O failover do keepalived trabalha com o protocolo VRRP, um protocolo que trabalha em multicast, onde não é necessário informar quem é mestre e quem é escravo, porque ele vai se basear no estado (estate) que foi definido e no nome que você determinou pra instância VRRP na configuração, aqui no Lab coloquei o nome de VRRP1, porque eu quis, simples.

Outro fator importante, a interface de rede onde será configurado o IP flutuante, esse IP flutuante fica como um IP secundário, então se preocupe que ele não vai remover o IP setado nesta interface de rede. No caso do Red Hat e CentOS em suas versões recentes ele segue padrões parecidos com os BSD’s, adotando esse nome feio pras interfaces de rede, enquanto para o Debian permanece com o padrão antigo (ethX).

Na cláusula virtual_ipaddress é onde é declarado o endereço VIP (Flutuante), o IP a qual será o ponto único de acesso do cliente. E por fim temos a cláusula track_script onde você precisa chamar o vrrp_script que você definiu, onde foi passado os passos que o keepalived ira conferir se o serviço nginx esta no ar.

Por razões de segurança você pode definir critérios de segurança para o protocolo VRRP baseado em autenticação. Nesse modelo adotado estamos seguindo o modelo PASS, que basicamente transita em texto puro a senha, em produção não é recomendável, caso você queira um tipo de autenticação mais eficiente, recomendo a leitura a seguir: http://louwrentius.com/configuring-attacking-and-securing-vrrp-on-linux.html

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state MASTER
    interface enp0s3
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state MASTER
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

No escravo configure como no modelo abaixo, basicamente idêntico ao modelo do mestre, com exceção de que o estado aqui ficado definido como BACKUP, ao invés de MASTER.

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state BACKUP
    interface enp0s3
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

# vim /etc/keepalived/keepalived.conf
vrrp_script linuxsysadmin {
        script "pidof nginx"
        interval 2
        weight 2
}
 
vrrp_instance VRRP1 {
    state BACKUP
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 9999
    }
    virtual_ipaddress {
        10.100.0.135/24
    }
    track_script {
        linuxsysadmin
    }
 
}

Antes de testar o failover, não se esqueça de incluir os serviços que serão monitorados para subirem durante o boot do sistema operacional.

# systemctl enable keepalived
# systemctl enable nginx
# systemctl start nginx

Nos servidor mestre inicie o serviço do keepalived. Aguarde alguns instantes e confira se o VIP subiu.

# systemctl start keepalived
# echo MASTER > /var/www/html/index.html
# ip addr show
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:ae:d6:54 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.68/8 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.100.0.135/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feae:d654/64 scope link 
       valid_lft forever preferred_lft forever

# /etc/init.d/keepalived start
# echo MASTER > /var/www/html/index.html
# ip addr show
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:ae:d6:54 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.68/8 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.100.0.135/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feae:d654/64 scope link 
       valid_lft forever preferred_lft forever

Com o mestre no ar, podemos iniciar o slave e efetuar os testes para validar a nossa alta disponibilidade.

# systemctl start keepalived
# echo SLAVE > /var/www/html/index.html

# /etc/init.d/keepalived restart
# echo SLAVE > /var/www/html/index.html

Em seguida abra seu navegador e acesse o VIP pelo seu navegador, a janela será semelhante a imagem abaixo. Você ra notar que ele esta apontando pro servidor mestre.

Agora faremos o teste propriamente dito, forçaremos o encerramento do processo do serviço nginx. Feito esse procedimento, o keepalived vai entrar no processo de eleição, onde ele precisa promover o servidor escravo (BACKUP) para mestre.

# pkill nginx

Pelos logs do keepalived também é possível acompanhar essa mudança. No serviço mestre execute o tail em messages e será possível verificar que houve falhe, e que ele passa se declarar como backup (escravo).

# tail -f /var/log/messages
Mar  9 14:59:43 master Keepalived_vrrp[5769]: VRRP_Script(linuxsysadmin) failed
Mar  9 14:59:44 master Keepalived_vrrp[5769]: VRRP_Instance(VRRP1) Received higher prio advert
Mar  9 14:59:44 master Keepalived_vrrp[5769]: VRRP_Instance(VRRP1) Entering BACKUP STATE

No servidor escravo também fica evidência de que o servidor corrente foi eleito (promovido) a mestre, devido a indisponibilidade do mestre primário.

# tail -f /var/log/messages
Mar  9 14:59:44 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) forcing a new MASTER election
Mar  9 14:59:45 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) Transition to MASTER STATE
Mar  9 14:59:46 slave Keepalived_vrrp[5238]: VRRP_Instance(VRRP1) Entering MASTER STATE

Essa eleição é feita, porque no keepalived é possível ter mais de um escravo, por isso o keepalived suporta trabalhar com níveis de prioridade, onde ele pode eleger o servidor escravo com maior prioridade.

Bem, acho que de failover é isso, e não tem muito o que falar sobre o assunto. Quem se interessou sobre o assunto, já escrevi um artigo sobre Alta Disponibilidade (Failover) com Heartbeat, dando como exemplo o Zabbix, caso tenha interesse no assunto, recomendo a leitura: http://www.linuxsysadmin.com.br/index.php/2015/08/05/zabbix-em-alta-disponibilidade-com-heartbeat/

Fico por aqui caros amigos e colegas, forte abraço e sucesso nessa empreitada!

See ya!

Bora entender o que é Piwik! Piwioque?!?

Não, o Piwik não é uma fruta derivada do Kiwi e nem o aplicativo de perguntas e respostas! Brincadeiras a parte, no post de hoje falaremos sobre o Piwik, uma solução de web analytics open source disponível sob a licença GPL versão 3. Mas oras, o que tem de interessante nesse Piwik? Piwik é uma ferramenta madura e eficiente para medir a audiência em sites e blogs. Com o Piwik é possível monitorar desde a navegação de seus visitantes e clientes, qual os dispositivos que eles usaram para acessar seu site ou qual o navegador que eles utilizaram, até mesmo saber de qual região do mundo ou do país esse visitante esta através de geolocalização,, ajudando sua equipe de marketing ter uma visão mais abrangente sobre o perfil do seu público-alvo. Mas ele se limita a isso? Não!

Atualmente ainda muitas pessoas fazem uso do Google Analytics para análise de tráfego em seus web sites, no entanto o Piwik vem gradativamente ganhando seu merecido espaço e tendo se mostrado um concorrente a altura da ferramenta da gigante Google. Atualmente a ferramenta já possui mais de 3 milhões de downloads, isso quer dizer que cada vez mais profissionais vem adotando o Piwik e tendo um ótimo feedback sobre ele, além disso, empresas como a Forbes por exemplo, já a utilizam em seu ambiente, o que fica evidente o quanto a solução pode atender diversos nichos de mercado e empresas de diversos tamanhos.

Chega de ladainha! Vamos agora para a tela preta e por a mão na massa, entender de uma vez por todas como implementá-la em seu ambiente. Aqui neste post procuro explicar como implantar a solução nas duas famílias de distribuições Linux mais populares do mercado no segmento de servidores, ou seja, Debian e CentOS, atendendo tanto a “galera” Debian e a “Galera” Red Hat Enterprise Linux, sem deixar ninguém de fora dessa, afinal, existe um vasto público para as ambas as distribuições. Além disso, eu sei o quanto é sofrer para tirar aquela dúvida sobre uma determinada solução e durante a instalação dela, tem aquele pacote danado que muda de nome para cada distribuição, o que atrapalha e dificulta padronizar a instalação da maioria das soluções em todo o ecossistema Linux. rs

A instalação que faremos é em single-server, ou seja, faremos uma instalação do servidor web, aplicação piwik e a base de dados em um único servidor. Porque o intuito é esclarecer como funciona a instalação. No dia a dia você tem a liberdade de segmentar esse ambiente entre camada de aplicação e dados, até porque as boa prática recomendam esse tipo de implementação em um ambiente de produção.

Let’s go!

Primeiramente precisamos preparar o ambiente, no caso do CentOS por exemplo, precisamos instalar o repositório webtatic, porque ele possui o pacote php 5.5.38, compatível com a versão requerida pelo Piwik. Atualmente o Piwik exige a versão superior ao php 5.5.9 para seu perfeito funcionamento.

# yum install epel-release wget unzip -y
# wget https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
# rpm -ivh webtatic-release.rpm

Enquanto no Debian precisamos fazer o update para que o apt faça a ressincronização dos índices dos pacotes do repositório remoto e minimizar a possibilidade de ter algum erro no momento que o apt procurar pelo pacote no repositório.


No Debian, execute os passos:

# apt-get update
# apt-get install wget unzip -y

Com a preparação do ambiente iniciada, já podemos preparar o backend da nossa infraestrutura, ou seja, vamos instalar e configurar a nossa base de dados, onde será armazenados os dados dos visitantes e toda as funcionalidades necessárias para sustentar a aplicação piwik.

No CentOS faremos a instalação do mariadb, que nada mais é do que um fork do mysql criado pelo próprio fundador do projeto após sua aquisição pela Oracle. Apesar da mudança de nome, o mariadb é 100% compatível com as funcionalidades do mysql.

# yum install mariadb-server -y
# systemctl enable mariadb
# systemctl start mariadb
# mysql
mariadb> CREATE DATABASE piwikdb;
mariadb> GRANT ALL PRIVILEGES ON piwikdb.* To 'piwik'@'localhost' IDENTIFIED BY '4linux';

No Debian é necessário ficar atento após a instalação, porque o debconf vai questionar qual a senha você deseja configurar para o root (administrador da base de dados), sinta-se livre para escolher a senha.

Instalado o mysql com sucesso, precisamos iniciá-lo e incluí-lo na inicialização do sistema operacional em caso de reboot. E obviamente precisamos criar a base de dados e as credenciais de acesso do usuário da aplicação piwik.

# apt-get install mysql-server -y # Forneça a senha de root do mysql
# systemctl enable mysql
# systemctl start mysql
# mysql
mysql> CREATE DATABASE piwikdb;
mysql> GRANT ALL PRIVILEGES ON piwikdb.* To 'piwik'@'localhost' IDENTIFIED BY '4linux';

Com a nossa infraestrutura de backend configurada e pronta para uso, agora precisamos configurar o servidor http que irá sustentar a aplicação web Piwik atuando dentro da camada de apresentação, no caso iremos instalar o mito, a lenda, o clássico… O bom e velho apache. Uma solução de servidor http que ganhou seu reconhecimento e se mantém até os dias atuais no topo da cadeia alimentar dos servidores http mais populares e estáveis do mundo.

Em conjunto precisamos instalar também o pacote php, afinal, é a linguagem nativa da aplicação piwik, e obviamente também precisamos instalar todos as bibliotecas e extensões para que a aplicação piwik funcione corretamente.

# yum install httpd php55w php55w-cli php55w-common php55w-gd php55w-mysql php55w-xml php55w-mbstring -y

# apt-get install apache2 libapache2-mod-php5 php5 php5-curl php5-gd php5-cli php5-mysql php-xml php-mbstring -y

Agora precisamos fazer o download da versão mais recente do piwik através do site oficial da solução. Após a conclusão do download extraia o arquivo dentro do diretório raiz web do servidor web,, conforme o comando abaixo, este mesmo comando e aplica a ambas as distribuições.

# wget https://builds.piwik.org/piwik.zip
# unzip piwik.zip -d /var/www/html/

Agora que a aplicação piwik já esta disponível para o servidor web, precisamos configurar o Virtual Host para o piwik , mas pera lá, o que é Virtual Host? Virtual Host é um recurso padrão dos servidores web que fornece a possibilidade de hospedar mais do que um web site ou aplicação num único servidor, com um endereço IP ou mais. Mas poxa, por que fazer Virtual Host sendo que este servidor não terá nenhum outro site ou aplicação, além do próprio Piwik? Porque é uma boa prática, simples assim.

# vim /etc/httpd/conf.d/piwik.conf
<VirtualHost *:80>
ServerAdmin admin@linuxsysadmin.com.br
DocumentRoot "/var/www/html/piwik"
ServerName piwik.linuxsysadmin.com.br
ErrorLog "/var/log/httpd/piwik.linuxsysadmin.com-error_log"
CustomLog "/var/log/httpd/piwik.linuxsysadmin.com-access_log" common
</VirtualHost>

Note que existe uma diferença sútil em relação aos diretórios do apache nas duas distribuição, mas em suma, o serviço é o mesmo, então faça com confiança, sem medo de ser feliz!

# vim /etc/apache2/sites-available/piwik.conf
<VirtualHost *:80>
ServerAdmin admin@linuxsysadmin.com.br
DocumentRoot "/var/www/html/piwik"
ServerName piwik.linuxsysadmin.com.br
ErrorLog "/var/log/apache2/piwik.linuxsysadmin.com-error_log"
CustomLog "/var/log/apache2/piwik.linuxsysadmin.com-access_log" common
</VirtualHost>

Neste ponto a aplicação já estaria disponível para acessarmos e terminarmos a instalação. Mas existem alguns pontos cruciais, a permissão do diretório piwik, é necessário que o usuário do serviço apache seja proprietário deste diretório, afinal durante a instalação o piwik precisa escrever suas configurações em um arquivo dentro deste diretório, e sem elas, não seria possível prosseguir com a instalação.

# chown -R apache:apache /var/www/html/piwik

No Debian temos dois diferenciais, um que o Virtual Host precisa ser habilitado através do comando a2ensite, caso contrário nosso piwik ainda não estara disponível para uso. Além disso, o arquivo php.ini precisa ser editado, alterando o parâmetro always_populate_raw_post_data, este parâmetro já esta obsoleto no php, por essa razão precisamos passar o valor -1, assim o php mantém este recurso funcionando mas sem as implementações novas feitas nele a partir das novas versões do php.

# chown -R www-data:www-data /var/www/html/piwik
# a2ensite piwik.conf
# vim /etc/php5/apache2/php.ini
always_populate_raw_post_data = -1

E por fim, mas não menos importantes, podemos reiniciar o serviço do apache e obviamente adicionar o serviço na inicialização do sistema operacional.

# systemctl enable httpd
# systemctl restart httpd

# systemctl enable apache2
# systemctl reload apache2

Agora abra seu navegador favorito e acesse o endereço http://piwik.linuxsysadmin.com.br e vamos concluir a instalação via web. Ao acessar você será recebido com boas vindas, clique em “seguinte” para avançar na instalação.

Nessa tela será apresentada todas dependências do piwik, caso todas estejam instaladas corretamente o piwik informa um checkbox verde confirmando que aquela dependência esta ok.

 

Prosseguindo com a instalação será necessário informar as credenciais de acesso ao banco conforme fizemos na etapa de instalação e configuração do mysql/mariadb.

Ao avançar o piwik faz a carga inicial do banco e dados piwikdb, populando a base com os dados e as estruturas iniciais para seu funcionamento inicial.

Em seguida crie as credenciais do usuário administrador da ferramenta para que você possa acessa-la após a conclusão da instalação.

Nesta etapa é obrigatória a configuração do primeiro site que o piwik ira monitorar. Passe todas as informações corretamente, como nome, o endereço, localidade e a informe se é um blog, site ou e-commerce.

Após configurar o seu site o piwik gera o código Javascript que você irá adicionar dentro do cabeçalho html do seu site. Esse código javascript deve ficar dentro das tags head da sua página. Caso você tenha dificuldade, por favor contate sua equipe de desenvolvimento responsável pelo seu web site para te dar o apoio necessário. Caso você não faça esta etapa, após concluir a instalação e se autenticar na ferramenta, o piwik não vai te direcionar para o dashboard principal, já que ele não possui estatísticas de visitantes para exibir.

Abaixo, segue um exemplo de como seria em uma página html simples com a inclusão do código javascript.

		<!-- Piwik -->
		<script type="text/javascript">
  			var _paq = _paq || [];
  			// tracker methods like "setCustomDimension" should be called before "trackPageView"
			_paq.push(['trackPageView']);
			_paq.push(['enableLinkTracking']);
			(function() {
			var u="//piwik.linuxsysadmin.com.br/";
			_paq.push(['setTrackerUrl', u+'piwik.php']);
			_paq.push(['setSiteId', '1']);
			var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
			g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  			})();
		</script>
		<!-- End Piwik Code -->
 
 
		Página de teste

Editado o cabeçalho html da sua página, avance a instalação e você sera parabenizado pelo piwik por concluí-la.

Você sera direcionado para a página de autenticação do piwik, informe as credenciais e clique no botão entrar.

Parabéns, você acabou de concluir a instalação do Piwik com sucesso. Você provavelmente esta no dashboard principal da ferramenta, agora você pode desfrutar de todos os recursos que a ferramenta oferece. Sua tela de apresentação é extremamente linda e muito simples, com todos os detalhes necessários para tornar a ferramenta atrativa aos profissionais não só técnicos mas principalmente da área de negócios da sua empresa.

Pessoal, fico por aqui, agradeço pela atenção e a paciência em ler todo esse artigo em conjunto com um leve “how-to” focado para quem deseja ter o primeiro contato com a ferramente. Em breve pretendo escrever mais sobre o Piwik, e quem sabe não criamos num outro artigo, algo mais focado em uma arquitetura piwik de alto tráfego para portais web com grande volume de acessos. Enfim, forte abraço a todos e sucesso!

See ya!

Ansible: Automação e provisionamento ágil

O Ansible é uma solução open source desenvolvida inicialmente por Michael DeHaan, atualmente mantida pela comunidade e pela Red Hat. O Ansible é uma ferramenta de automação e provisionamento de fácil aprendizagem e que não exige cliente instalado na máquina remota, sendo suficiente o SSH.

1. Definindo os passos

Primeiramente vamos definir o que será feito. Precisamos saber os passos que serão executados, que no exemplo inicial será:

1. Baixar o pacote do repositório oficial do zabbix
2. Instalar o pacote do repositório (dpkg/rpm)
3. Instalar o pacote via repositório (apt/yum)
4. Substituir o arquivo de configuração (zabbix_agentd.conf)
5. Incluir o serviço na inicialização do sistema e inicia-lo.

2. Instalando o Ansible

A instalação do ansible é muito simples, podendo ser feita através do repositório da distribuição. Com exceção do CentOS, onde é necessário instalar antes o repositório EPEL.


No CentOS, execute os passos:

# yum install epel-relese; yum install ansible


No Debian, execute os passos:

# apt-get install ansible

Mais informações sobre instalação do Ansible podem ser obtidas em: http://docs.ansible.com/ansible/intro_installation.html

3. Criando a estrutura do Ansible

Após instalado o Ansible precisamos criar a estrutura do mesmo no diretório corrente, seguindo o modelo abaixo:

# tree
.
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
├── templates
│   └── zabbix_agentd.conf.j2
└── vars
    └── main.yml

Criamos inicialmente os diretórios:

No CentOS e Debian, execute os passos:

# mkdir {handlers,tasks,templates,vars}

Em seguida precisamos criar o YAML com todas ou ao menos as principais tarefas que serão executadas em etapas pelo ansible. Basicamente ele tem as instruções que vamos passar, como “instalar pacote X”, “iniciar serviço X”, etc.

Falaremos mais no decorrer deste post para que fique mais claro o entendimento.  Mas caso tenha interesse em obter a fonte direta sobre, mais informações podem ser obtidas em: http://docs.ansible.com/ansible/playbooks.html


No CentOS e Debian, execute os passos:

# vim tasks/main.yml
---
- name: Configurar e instalar agente zabbix
  hosts: all
  handlers:
  - include: "../handlers/main.yml"
  tasks:
 
  - name: Adiciona variaveis
    include_vars: "../vars/main.yml"
 
  - name: Instalar repositorio CentOS
    get_url:
      url: http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm
      dest: /tmp/zabbix-release-3.0-1.el7.noarch.rpm
      mode: 0777
 
  - name: Instalar repositorio Debian
    get_url:
      url: http://repo.zabbix.com/zabbix/3.0/debian/pool/main/z/zabbix-release/zabbix-release_3.0-1+jessie_all.deb
      dest: /tmp/zabbix-release_3.0-1+jessie_all.deb
      mode: 0777
 
  - name: Executando zabbix.rpm
    yum: name=/tmp/zabbix-release-3.0-1.el7.noarch.rpm state=present
    when: ansible_distribution == "CentOS"
 
  - name: Executando zabbix.deb
    apt: deb=/tmp/zabbix-release_3.0-1+jessie_all.deb
    when: ansible_distribution == "Debian"
 
  - name: Instalar agente zabbix CentOS
    yum: name=zabbix-agent state=latest
    when: ansible_distribution == "CentOS"
 
  - name: Instalar agente zabbix
    apt: name=zabbix-agent state=latest
    when: ansible_os_family == "Debian"
 
  - name: Preparar arquivo de configuração
    template: src=../templates/zabbix_agentd.conf.j2 dest=/etc/zabbix/zabbix_agentd.conf owner=root group=root mode=0644
    notify:
     - Iniciar agente zabbix
:x!

Criado o arquivo de tarefas, precisamos criar o arquivo de Manipulação, Handlers dentro do contexto do ansible significa a operação de serviços. Basicamente Handlers são como tarefas, a única diferença, é que geralmente eles são executados após uma notificação de uma ou mais tarefas.


No CentOS e Debian, execute os passos:

# vim handlers/main.yml
---
  - name: Iniciar agente zabbix
    service: name=zabbix-agent state=started enabled=yes
:x!

Feito o arquivo de manipulação (handlers), precisamos criar o arquivo que conterá as variáveis (no nosso exemplo, usaremos apenas uma), são onde podemos modifica-las e tornar nosso playbook dinâmico e de fácil manipulação.


No CentOS e Debian, execute os passos:

# vim vars/main.yml
  zserver: zabbix.dominio.com.br
:x!

E por fim criamos o arquivo modelo de configuração, onde pode notar que estamos usando dentro do mesmo a variável que definimos e outra variável com nome de ansible_hostname, que é uma variável interna do próprio ansible com intuito de identificar dinamicamente o hostname da máquina que esta sendo executado.

Mais informações sobre variáveis do ansible podem ser encontradas em: http://docs.ansible.com/ansible/playbooks_variables.html


No CentOS e Debian, execute os passos:

# vim templates/zabbix_agentd.conf.j2
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
Server={{ zserver }}
ServerActive={{ zserver }}
Hostname={{ ansible_hostname }}
Include=/etc/zabbix/zabbix_agentd.d/
:x!

4. Entendendo o Ansible

Entendemos que o Ansible segmento sua estrutura, mas precisamos entender o que esse amontoado de arquivos estão fazendo. Vamos lá, primeiramente vamos analisar o cabeçalho do arquivo de tarefas.
Onde a função name representa o nome da tarefa, a função hosts em qual grupo de hosts este playbook será executado, no exemplo deixei como all (todos), a função handlers basicamente indica o arquivo onde será herdado os manipuladores usados pelo playbook caso seja feita alguma notificação solicitando uma operação.

---
- name: Configurar e instalar agente zabbix
  hosts: all
  handlers:
  - include: "../handlers/main.yml"
 
A função tasks contém todos os passos que serão executados pelo nosso playbook, toda a receitinha de bolo. Em seguida temos a função include_vars, indicando o arquivo que contém as variáveis que serão usadas pelo ansible.
  tasks:
  - name: Adiciona variaveis
    include_vars: "../vars/main.yml"

Neste trecho estamos usando a função get_url onde podemos fazer download de arquivos, determinar o local onde será salvo e a permissão do arquivo. Seria similar ao executar no terminal o comando “wget http://site.com/arquivo”. Estamos usando nessa situação o módulo get_url para download de arquivos, mais informações sobre esse módulo podem ser obtidas na documentação oficial: http://docs.ansible.com/ansible/get_url_module.html

- name: Instalar repositorio CentOS
    get_url:
      url: http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm
      dest: /tmp/zabbix-release-3.0-1.el7.noarch.rpm
      mode: 0777
 
  - name: Instalar repositorio Debian
    get_url:
      url: http://repo.zabbix.com/zabbix/3.0/debian/pool/main/z/zabbix-release/zabbix-release_3.0-1+jessie_all.deb
      dest: /tmp/zabbix-release_3.0-1+jessie_all.deb
      mode: 0777
Neste trecho é onde damos a instrução ao ansible para instalar o pacote que baixamos anteriormente, e essa ação será executada de acordo com a condição da distribuição Linux utilizada. Seria similar ao executar manualmente no terminal "dpkg -i pacote.deb" ou "rpm -ivh pacote.rpm". Estamos usando o módulo apt e o módulo yum, que podem ser vistos de forma mais clara na documentação oficial: http://docs.ansible.com/ansible/apt_module.html e http://docs.ansible.com/ansible/yum_module.html

  - name: Executando zabbix.rpm
    yum: name=/tmp/zabbix-release-3.0-1.el7.noarch.rpm state=present
    when: ansible_distribution == "CentOS"
 
  - name: Executando zabbix.deb
    apt: deb=/tmp/zabbix-release_3.0-1+jessie_all.deb
    when: ansible_distribution == "Debian"

Este trecho corresponde a instalação dos pacotes via repositório, que seria o equivalente ao executar manualmente “apt-get install pacote” ou “yum install pacote”. Estamos usando o módulo apt e o módulo yum, que podem ser vistos de forma mais clara na documentação oficial: http://docs.ansible.com/ansible/apt_module.html e http://docs.ansible.com/ansible/yum_module.html

  - name: Instalar agente zabbix CentOS
    yum: name=zabbix-agent state=latest
    when: ansible_distribution == "CentOS"
 
  - name: Instalar agente zabbix
    apt: name=zabbix-agent state=latest
    when: ansible_os_family == "Debian"

E por fim, usamos a função template, onde indicamos o arquivo de configuração usando as variáveis que determinamos, e o destino onde esse modelo será copiado. O arquivo final já é inserido com os seus valores definidos. E por último é possível ver a função notify, que tem o intuito de notificar o handler (manipulador), onde faremos o start do serviço, que seria o equivalente a executar no terminal “systemctl start servico” ou “service servico start”.

  - name: Preparar arquivo de configuração
    template: src=../templates/zabbix_agentd.conf.j2 dest=/etc/zabbix/zabbix_agentd.conf owner=root group=root mode=0644
    notify:
     - Iniciar agente zabbix

5. Testando o Ansible: Provisionamento local

Feito os procedimentos anteriores, podemos testar o Ansible e valida-lo. Vamos executar este procedimento localmente, ou seja, na máquina corrente.
Por tanto, abra o seu terminal e dentro do diretório corrente do módulo criado, execute o comando a seguir, fique atento com relação a saída, devendo ser semelhante a saída abaixo:


No CentOS e Debian, execute os passos:

# ansible-playbook -i "localhost," -c local tasks/main.yml
 
PLAY [Configurar e instalar agente zabbix] ************************************ 
 
GATHERING FACTS *************************************************************** 
ok: [localhost]
 
TASK: [Adiciona variaveis] **************************************************** 
ok: [localhost]
 
TASK: [Instalar repositorio CentOS] ******************************************* 
ok: [localhost]
 
TASK: [Instalar repositorio Debian] ******************************************* 
ok: [localhost]
 
TASK: [Executando zabbix.rpm] ************************************************* 
skipping: [localhost]
 
TASK: [Executando zabbix.deb] ************************************************* 
changed: [localhost]
 
TASK: [Instalar agente zabbix CentOS] ***************************************** 
skipping: [localhost]
 
TASK: [Instalar agente zabbix] ************************************************ 
changed: [localhost]
 
TASK: [Preparar arquivo de configuração] ************************************** 
changed: [localhost]
 
NOTIFIED: [Iniciar agente zabbix] ********************************************* 
ok: [localhost]
 
PLAY RECAP ******************************************************************** 
localhost                  : ok=8    changed=3    unreachable=0    failed=0

E como podemos validar se funcionou corretamente? Simples:


No CentOS execute os passos:

# rpm -qa| grep zabbix
zabbix-release-3.0-1.el7.noarch
zabbix-agent-3.0.4-1.el7.x86_64
# systemctl status zabbix-agent
● zabbix-agent.service - Zabbix Agent
   Loaded: loaded (/usr/lib/systemd/system/zabbix-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Qua 2016-09-21 19:29:37 UTC; 29min ago
(...)
# cat /etc/zabbix/zabbix_agentd.conf
(...)
Server=zabbix.dominio.com.br
ServerActive=zabbix.dominio.com.br
Hostname=ansible01
(...)


No Debian execute os passos:

# dpkg -l| grep zabbix
ii  zabbix-agent                   1:3.0.4-1+jessie            amd64        Zabbix network monitoring solution - agent
ii  zabbix-release                 3.0-1+jessie                all          Zabbix official repository configuration
# systemctl status zabbix-agent
● zabbix-agent.service - Zabbix Agent
   Loaded: loaded (/lib/systemd/system/zabbix-agent.service; enabled)
   Active: active (running) since Wed 2016-09-21 19:56:30 GMT; 3min 53s ago
(...)
# cat /etc/zabbix/zabbix_agentd.conf
(...)
Server=zabbix.dominio.com.br
ServerActive=zabbix.dominio.com.br
Hostname=ansible02
(...)

6. Testando o Ansible: Provisionamento remoto

Anteriormente foi realizado o provisionamento do agente zabbix através do ansible em uma máquina local. Mas se quisermos provisionar este mesmo ambiente em diversos servidores remotamente via SSH? Lembre-se que o ansible não tem agente ou cliente, o único pré-requisito a existência do SSH na máquina de destino a ser executado.

Vamos-lá! Primeiro precisamos editar o arquivo hosts do Ansible, onde determinamos os nossos grupos de hosts. Edite o arquivo /etc/ansible/hosts, e inclua no final da linha os endereços e o nome do seu grupo de hosts, como no meu exemplo abaixo:


No CentOS e Debian, execute os passos:

# vim /etc/ansible/hosts
[minhasmaquinas]
192.168.150.10
192.168.150.11
:x!

Criado o nosso grupo de hosts, primeiramente devemos incluir a nossa chave pública do ssh nas máquinas remotas seguindo os passos a seguir. Primeiramente geramos a chave e em seguida incluímos as mesmas dentro dos servidores.

Gerando a chave pública e privada do SSH com o comando abaixo. Aperte enter em todas opções, deixando a chave sem passphrase:


No CentOS e Debian, execute os passos:

# ssh-keygen

Gerada a chave é preciso adicionar a chave pública nas máquinas remotas da seguinte forma, e fornece a senha correta de root:


No CentOS e Debian, execute os passos:

# ssh-copy-id root@192.168.150.11
# ssh-copy-id root@192.168.150.10

Podemos validar se a comunicação entre nossa máquina e os servidores remotos estão perfeitas executando o comando abaixo. A saída deve ser parecida com essa:


No CentOS e Debian, execute os passos:

# ansible minhasmaquinas -m ping
192.168.150.11 | success &gt;&gt; {
    "changed": false, 
    "ping": "pong"
}
 
192.168.150.10 | success &gt;&gt; {
    "changed": false, 
    "ping": "pong"
}

E finalmente podemos testar o uso do nosso módulo nas máquinas remotas, onde ele deverá instalar o agente zabbix e configura-lo corretamente. Execute o comando abaixo e confira a saída:


No CentOS e Debian, execute os passos:

# ansible-playbook -l minhasmaquinas  tasks/main.yml
PLAY [Configurar e instalar agente zabbix] ************************************ 
 
GATHERING FACTS *************************************************************** 
ok: [192.168.150.10]
ok: [192.168.150.11]
 
TASK: [Adiciona variaveis] **************************************************** 
ok: [192.168.150.10]
ok: [192.168.150.11]
 
TASK: [Instalar repositorio CentOS] ******************************************* 
ok: [192.168.150.11]
ok: [192.168.150.10]
 
TASK: [Instalar repositorio Debian] ******************************************* 
ok: [192.168.150.11]
ok: [192.168.150.10]
 
TASK: [Executando zabbix.rpm] ************************************************* 
skipping: [192.168.150.11]
changed: [192.168.150.10]
 
TASK: [Executando zabbix.deb] ************************************************* 
skipping: [192.168.150.10]
changed: [192.168.150.11]
 
TASK: [Instalar agente zabbix CentOS] ***************************************** 
skipping: [192.168.150.11]
changed: [192.168.150.10]
 
TASK: [Instalar agente zabbix] ************************************************ 
skipping: [192.168.150.10]
changed: [192.168.150.11]
 
TASK: [Preparar arquivo de configuração] ************************************** 
changed: [192.168.150.11]
changed: [192.168.150.10]
 
NOTIFIED: [Iniciar agente zabbix] ********************************************* 
ok: [192.168.150.11]
changed: [192.168.150.10]
 
PLAY RECAP ******************************************************************** 
192.168.150.10             : ok=8    changed=4    unreachable=0    failed=0   
192.168.150.11             : ok=8    changed=3    unreachable=0    failed=0

7. Conhecendo outros módulos do Ansible

O Ansible possui uma variedade enorme de módulos que já vem nativos e também disponibiliza módulos extras que podem se obtidos e ter mais informações através de sua documentação oficial: http://docs.ansible.com/ansible/modules_by_category.html

Neste exemplo vamos instalar o MySQL e criar uma base de dados chamada “mydatabase”. No caso, no Debian iremos instalar o MySQL e no CentOS o MariaDB, que é o fork versão open do MySQL. Importante se atentar também aos pré-requisitos de cada módulo ou função usada pelo ansible, por exemplo, para o uso do MySQl precisamos instalar a biblioteca MySQLdb do python para que o ansible possa se conectar ao SGBD.

Todos os módulos oficiais disponíveis do ansible estão em sua documentação oficial, assim como esta do MySQL: http://docs.ansible.com/ansible/mysql_db_module.html

Então vamos editar novamente o nosso playbook e vamos adicionar o seguinte:


No CentOS e Debian, execute os passos:

# vim tasks/main.yml
(...)
- name: Instalar MySQLdb CentOS
    yum: name=MySQL-python state=latest
    when: ansible_distribution == "CentOS"
 
  - name: Instalar MySQLdb Debian
    apt: name=python-mysqldb state=latest
    when: ansible_os_family == "Debian"
 
  - name: Instalar MariaDB
    yum: name=mariadb-server state=latest
    when: ansible_distribution == "CentOS"
    notify:
     - Iniciar mariadb CentOS
 
  - name: Instalar MySQL
    apt: name=mysql-server state=latest
    when: ansible_os_family == "Debian"
    notify:
     - Iniciar mysql Debian
(...)
:x!

Em seguida vamos editar o handlers indicando o start do serviço MySQL nos sistemas e também acionar ele para criar a base de dados:


No CentOS e Debian, execute os passos:

# vim handlers/main.yml
(...)
  - name: Iniciar mariadb CentOS
    service: name=mariadb state=started enabled=yes
    notify:
     - Criar base de dados
 
  - name: Iniciar mysql Debian
    service: name=mysql state=started enabled=yes
    notify:
     - Criar base de dados
 
  - name: Criar base de dados
    mysql_db: name=mydatabase state=present
(...)
:x!

Após a edição, precisamos executar o playbook para validar as tarefas que incluímos.


No CentOS e Debian, execute os passos:

# ansible-playbook -l minhasmaquinas  tasks/main.yml
 
PLAY [Configurar e instalar agente zabbix] ************************************ 
 
GATHERING FACTS *************************************************************** 
ok: [192.168.150.10]
ok: [192.168.150.11]
 
TASK: [Adiciona variaveis] **************************************************** 
ok: [192.168.150.10]
ok: [192.168.150.11]
 
TASK: [Instalar repositorio CentOS] ******************************************* 
ok: [192.168.150.11]
ok: [192.168.150.10]
 
TASK: [Instalar repositorio Debian] ******************************************* 
ok: [192.168.150.11]
ok: [192.168.150.10]
 
TASK: [Executando zabbix.rpm] ************************************************* 
skipping: [192.168.150.11]
changed: [192.168.150.10]
 
TASK: [Executando zabbix.deb] ************************************************* 
skipping: [192.168.150.10]
changed: [192.168.150.11]
 
TASK: [Instalar agente zabbix CentOS] ***************************************** 
skipping: [192.168.150.11]
changed: [192.168.150.10]
 
TASK: [Instalar agente zabbix] ************************************************ 
skipping: [192.168.150.10]
changed: [192.168.150.11]
 
TASK: [Instalar MySQLdb CentOS] *********************************************** 
skipping: [192.168.150.11]
ok: [192.168.150.10]
 
TASK: [Instalar MySQLdb Debian] *********************************************** 
skipping: [192.168.150.10]
ok: [192.168.150.11]
 
TASK: [Instalar MariaDB] ****************************************************** 
skipping: [192.168.150.11]
changed: [192.168.150.10]
 
TASK: [Instalar MySQL] ******************************************************** 
skipping: [192.168.150.10]
changed: [192.168.150.11]
 
TASK: [Preparar arquivo de configuração] ************************************** 
changed: [192.168.150.11]
changed: [192.168.150.10]
 
NOTIFIED: [Iniciar agente zabbix] ********************************************* 
ok: [192.168.150.11]
changed: [192.168.150.10]
 
NOTIFIED: [Iniciar mariadb CentOS] ******************************************** 
changed: [192.168.150.10]
 
NOTIFIED: [Iniciar mysql Debian] ********************************************** 
ok: [192.168.150.11]
 
NOTIFIED: [Criar base de dados] *********************************************** 
changed: [192.168.150.10]
 
PLAY RECAP ******************************************************************** 
192.168.150.10             : ok=12   changed=7    unreachable=0    failed=0   
192.168.150.11             : ok=11   changed=4    unreachable=0    failed=0

E por fim, podemos conferir se a base de dados foi criada com sucesso.


No CentOS e Debian, execute os passos:

# mysql
(...)
MariaDB [(none)]&gt; show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mydatabase         |
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)
 
MariaDB [(none)]&gt;

8. Conclusão

Como podemos ver o Ansible é uma ótima solução de provisionamento de ambientes, bastante dinâmica e eficiente. Existe alguns contras, claro, como a exigente sintaxe e indentação do seu playbook. No entanto sua lógica é bastante simples. Além de possuir vantagens em relação a sua expansão, já que a própria documentação fornece ideais e sugestões para você desenvolver seus próprios módulos para serem usados em seus playbooks. Enfim, fico por aqui, e espero que essa dica seja útil para todos aqueles empenhados em aplicar essa solução em seu dia a dia.

DevOps: É uma cultural/filosofia e não uma profissão!

devops03

Este post não tem como objetivo de modo algum criticar a cultura DevOps e tão pouco denegrir quem evangeliza essa filosofia ou mesmo de quem é praticante da mesma.

Mas sim desabafar sobre o cenário atual de ignorância ou má fé de algumas empresas que estão explorando esta nova cultura dentro da TI.

O que é DevOps? Como todos ou praticamente a maioria já sabe, é a cultura de integrar a equipe de Desenvolvimento e Infraestrutura/Operações afim de ter um time mais efetivo e dinâmico, afim de entregar deploys contínuos de aplicação e elaborar estratégias eficientes de entrega.

devops02

No entanto, o “boom” dessa filosofia tem sido vista por algumas (não todas) empresas como uma nova forma de explorar novos funcionários. Criando cargos de DevOps, sendo que DevOps não é uma profissão, não é um cargo, não é um departamento, não é um time. DevOps é simplesmente uma cultura, a questão que essa cultura visa integrar as equipes fazendo com que o know-how das equipes seja expandido, já que infra em tese deve aprender mais sobre o fluxo de desenvolvimento para apoiar e equipe de desenvolvimento em como fazer deploys contínuos e com a menor possibilidade de erros, e até mesmo apoia-los em outros pontos, assim como a equipe de desenvolvimento também deve se interagir mais com infraestrutura afim de entender melhor como funciona certas limitações em infraestrutura para validar em ambientes de homologação antes de aplicar o deploy em um cenário de produção.

Até este ponto já fica claro que um profissional de TI que compreende e sabe trabalhar em cima da cultura DevOps que ele deve ter uma visão além do seu departamento, se você é de desenvolvimento deve ter uma visão mais ampla, assim como você de infra deve ter uma visão mais ampla também do todo. Porém devido a este fenômeno que fez com que DevOps fosse um assunto cada vez mais falado (o que particularmente eu considero como algo MUITO importante e deve ser cada vez mais difundido), no entanto algumas empresas  estão se aproveitando disto para criar cargos que em que um Analista de Infraestrutura tenha que saber além do seus conhecimentos operacionais, mas também conhecimento em desenvolvimento, e não só o básico, mas sim ter experiência com linguagens de programação, conhecimento em banco de dados com capacidade para administrar um SGBD, desenhar topologia de ambientes complexos, entender diversas outras camadas que vão além do seu escopo.

devops01

Muitos justificam isso devido a crise econômica Brasileira.. Mas cá entre nós, será mesmo? Não é de hoje que existem diversas vagas na área de TI com títulos como:

  • “Analista de Infraestrutura”
  • Exigências: Conhecimento nas mais variadas linguagens de programação, banco de dados, middleware, redes, storage, gerenciamento, suporte, implantação, etc.

Com uma infinidade de exigências que no final não condizem de forma alguma com o salário oferecido. Porém em situação pré-crise, apesar de ser comum, isso sempre soava forçado e gerava críticas fortes entre profissionais da área. Entretanto com a chegada do assunto DevOps agora os títulos das vagas mudou para simplesmente “DevOps”, como se DevOps fosse uma profissão, um cargo, e não é! Parece que as empresas não estão entendendo o que de fato é essa cultura e o que ela representa, enquanto as empresas continuarem exigindo uma enfinidade de expertise e não compreender o BÁSICO, que é o conceito, a ideia, a filosofia da cultura DevOps, ela não será útil pra nada, a não ser, uma forma mais “atual”, ou dentro do “compliance”, pra buscar funcionários no mercado e explora-los.

Enfim, é importante se atentar que a ideia não surgiu pra explorar funcionários, surgiu pra facilitar a comunicação entre as equipes, unifica-las, fazer ambas trabalharem unidas em pró de uma entrega de qualidade e estável. Quebrar a barreira entre os dois departamento e melhor interagi-los para o objetivo final! E não para explorar funcionários.. Tenha isso em mente!

Nginx: Balanceamento de Carga em Aplicações Web

Como o próprio site do projeto o define:

“O Nginx (Pronuncia correta: Engine X) é um HTTP e um servidor proxy reverso, um servidor proxy de email e um servidor proxy genérico TCP/UDP, escrito originalmente por Igor Sysoev. Por um longo tempo, ele foi executado em muitos sites russos fortemente carregados, incluindo Yandex, Mail.Ru, VK, e Rambler. De acordo com a Netcraft, o nginx como servidor ou proxy esteve presente em 27,90% dos sites mais movimentados em julho de 2016. Aqui estão algumas das histórias de sucesso:

  • Netflix
  • WordPress.com
  • FastMail.FM

1. Introdução ao Nginx

A grosso modo, basicamente o Nginx é o atual concorrente do Apache, sendo um servidor web (http) com demais funcionalidades. O que fazem com que ambos sejam semelhantes, mas tendo cada um sua particularidade, além de cada um ter seu grandioso e respeito espaço no mercado.

O Nginx se tornou popular por ser fácil de configurar e ter um response time significativo. Mas é válido dizer que de forma alguma estou aqui para afirmar que ele é melhor que o Apache, já que respeito muito ambos os projetos.

Neste post iremos esclarecer como configurar o Nginx como Balanceador de Carga para aplicações HTTP, configurando o mesmo para balancear requisições HTTP entre dois nodes (nós).

Caso tenha dúvida sobre como funciona Balanceamento de Carga o conceito pode ser mais esclarecido no respectivo link: http://www.linuxsysadmin.com.br/index.php/2015/08/06/alta-disponibilidade-o-conceito/

2. Instalando o Nginx

Primeiramente vamos instalar e configurar o repositório oficial do Nginx e em seguida instalar o pacote nginx.

Lembrando que damos sempre preferência ao repositório oficial, já que o mesmo possui versões do pacote muito mais atualizada que os pacotes disponibilizados nos repositórios das distribuições.


No CentOS, execute os passos:

# vim /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
:x!
# yum install nginx


No Debian, execute os passos:

# vim /etc/apt/sources.list.d/nginx.list
deb http://nginx.org/packages/debian/ jessie nginx
deb-src http://nginx.org/packages/debian/ jessie nginx
:X!
# wget http://nginx.org/keys/nginx_signing.key -O /tmp/nginx_signing.key
# apt-key add /tmp/nginx_signing.key
# apt-get update
# apt-get install nginx

3. Configurando o Load balancer

Feita a instalação do Nginx, precisamos configurar o balanceamento de carga no ambiente da seguinte forma:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
# Pool do Load balancer
upstream pool.linuxsysadmin.com.br {
        server 192.168.50.3;
        server 192.168.50.4;
}
 
# Setando as variáveis do cabeçalho HTTP.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Queue-Start “t=${msec}000”;
 
# Proxy Pass do balanceador
server {
    listen       80;
    server_name  localhost;
 
        location / {
                proxy_pass http://pool.linuxsysadmin.com.br;
        }
}

A diretiva “upstream” aponta o Virtual Host a ser utilizado pelo Balanceador de Carga, dentro os parâmetros “server” indicam os servidores de backend, ou seja, será o nodes utilizados utilizados no cluster.

Abaixo possui os parâmetros proxy_set_header, eles tem a finalidade de trocar os campos do cabeçalho HTTP por variáveis. Mais informações sobre os campos do cabeçalho HTTP podem ser obtidas em https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

E por último a diretiva “server” faz o proxy pass, declarando que o contexto raiz “/” será direcionado para o Virtual Host do Balanceador de Carga.

Feito o procedimento acima, podemos adicionar o nginx no boot do sistema operacional e reiniciar o serviço do Nginx.


No CentOS e Debian, execute os passos:

# systemctl enable nginx
# systemctl restart nginx

Obs: É importante que as máquinas 192.168.50.3 e 192.168.50.4 já esteja no ar e configuradas. No caso eu recomendaria instalar o apache em ambas as maquinas e criar um index.html dentro de /var/www e/ou /var/www/html dependendo da distribuição utilizada. Outro ponto a considerar é que estes endereços podem ser trocados de IP para nome, como por exemplo app01.linuxsysadmin.com.br, app02.linuxysadmin.com.br, etc. Porém é importante que o balanceador de carga esteja resolvendo o nome adequadamente.

4. Validando o Balanceamento de Carga

Edite o seu /etc/hosts e adicione a entrada:

:

# echo -e "IPDOSERVIDORNGINX\tpool.linuxsysadmin.com.br" > /etc/hosts

Abra o seu navegador e acesse http://pool.linuxsysadmin.com.br:

5. Métodos de Balanceamento de Carga

O Nginx possui três métodos de balanceamento de carga suportados, sendo eles:

  1. round-robin — As requisições são distribuídas igualmente entre os servidores.
  2. least-connected — O próximo pedido é sempre atribuído ao servidor com o menor número de conexões ativas.
  3. ip-hash — A função ip_hash é usada para determinar qual servidor deve ser selecionado para o próximo pedido (com base no endereço IP do cliente), tendo uma sessão persistente.

Muitas vezes é visto administradores recomendando desenvolvedores a modificar a aplicação para fazer uso de Memcache ou Redis para manter a sessão entre os nós do cluster, entre outros modelos.
De repente estes modelos apresentados acima podem lhe atender bem, sem necessidade de modificações extras no cenário.

Estes métodos devem ser adotados de acordo com o melhor modelo para sua aplicação.

6. Round Robin

Round Robin é o modelo de balanceamento de carga padrão adotado pelo Nginx. Caso o método não seja especificado ele sempre assume o método Round Robin. No caso, o modelo que estamos usando neste cenário é o método Round Robin.

Note no navegador que conforme é feito o refresh da página ora ele acesse 192.168.50.3 ora aparece 192.168.50.4, porque ele sempre vai distribuir a requisição igualmente entre cada nó.

7. Least Connected

O Least Connected como informado acima direciona a próxima requisição sempre para o nó com o menor número de conexões.

Para configurar o seu balanceamento de carga com este método, basta adicionar o parâmetro “least_conn” dentro da diretiva upstream. Por exemplo:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
(...)
upstream pool.linuxsysadmin.com.br {
        least_conn;
        server 192.168.50.3;
        server 192.168.50.4;
}
(...)

Reinicie o serviço do Nginx para aplicar a mudança.


No CentOS e Debian, execute os passos:

# systemctl restart nginx

Para validar este método, abra seu navegador e acesse pool.linuxsysadmin.com.br e faça um refresh da página para entender de forma prática como ele aplica este modelo.

8. IP Hash

O IP Hash como dito acima direciona a requisição sempre sempre para o mesmo nó, baseado no IP de origem. Ou seja, se a estação 192.168.50.10 acessar o balanceador pelo navegador, supondo que o nginx jogou essa requisição para o primeiro nó, ele sempre vai direcionar a requisição deste cliente para o primeiro nó.
Para configurar o seu balanceamento de carga com este método, basta adicionar o parâmetro “ip_hash” dentro da diretiva upstream. Por exemplo:


No CentOS e Debian, execute os passos:

# vim /etc/nginx/conf.d/balancer.conf
(...)
upstream pool.linuxsysadmin.com.br {
        ip_hash;
        server 192.168.50.3;
        server 192.168.50.4;
}
(...)

Reinicie o serviço do Nginx para aplicar a mudança.


No CentOS e Debian, execute os passos:

# systemctl restart nginx

Para validar este método, abra seu navegador e acesse pool.linuxsysadmin.com.br e faça um refresh da página para entender de forma prática como ele aplica este modelo. Note que ele a requisição sempre é enviada para o mesmo nó.

9. Conclusão

O Balanceamento de Carga do Nginx como visto é muito simples de se configurar. Além disso, o Nginx vem crescendo cada vez mais, cada dia ganhando mais e mais espaço no mercado, sendo adotado por diversas empresas e nos mais variados ambientes.

Por isso espero que este post lhe seja útil e que te ajude a compreender de forma fácil como funciona o balanceamento de carga de aplicações web.

Mais informações sobre o Nginx podem ser obtidas diretamente em sua documentação oficial: https://nginx.org/en/docs/

Vagrant: Provisionamento ágil de Máquinas Virtuais

Como a própria HashiCorp, dona do projeto Vagrant descreve a ferramenta:

“Vagrant é uma ferramenta para a construção de ambientes de desenvolvimento completo. Com um fluxo de trabalho fácil de usar e se concentrar em automação, o Vagrant reduz o tempo de configuração do ambiente de desenvolvimento, aumenta o foco em desenvolvimento/produção, e faz com que o “preparação do ambiente de desenvolvimento” seja uma desculpa do passado.

Se você é um engenheiro de operações (Infraestrutura), Vagrant lhe da um ambiente descartável e um fluxo de trabalho consistente para desenvolver e testar scripts de gerenciamento de infra-estrutura. Você pode rapidamente testar coisas como shell scripts, cookbooks do chef, módulos do puppet, e muito mais, usando virtualização local, como o VirtualBox ou VMware. Então, com a mesma configuração, você pode testar esses scripts em nuvens remotas, como AWS ou RackSpace com o mesmo fluxo de trabalho. Vale seus scripts personalizados para reciclar instâncias EC2. Pare com o malabarismo com SSH entre várias máquinas, e comece a usar Vagrant, levando solidez à sua vida.

Se você é um Desenvolvedor, Vagrant irá isolar dependências e sua configuração dentro de um único ambiente descartável, consistente, sem sacrificar nenhuma das ferramentas que você está acostumado a trabalhar como (editores, navegadores, depuradores, etc.). Uma vez que você ou alguém crie um único Vagrantfile, você só precisa do Vagrant e tudo está instalado e configurado para você trabalhar. Outros membros de sua equipe podem criar seus ambientes de desenvolvimento a partir da mesma configuração, por isso se você estiver trabalhando em Linux, Mac OS X ou Windows, todos os membros da equipe estão executando o código no mesmo ambiente, contra as mesmas dependências, tudo configurado o mesmo caminho. Diga adeus aos erros ou “funciona na minha máquina”.”

1. Introdução ao Vagrant

Espero que você fique maravilhado com esta solução de provisionamento ágil de máquinas virtuais. Ideal para quem pratica bastante laboratórios e/ou faz uso de ambientes de desenvolvimento constantemente, e perde muito tempo instalando SO, preparando o ambiente, fazendo ajustes de configuração, etc.

O Vagrant permite que você possa automatizar tudo isso durante o provisionamento da máquina virtual, e o melhor de tudo, tudo com um único arquivo e um único comando! Além de facilitar em fazer o deploy deste mesmo ambiente para outro com Vagrant, com um pequeno arquivo com pouco mais de 4,0KBs!

Antes de começarmos a parte prática, precisamos entender que o Vagrant é apenas a solução de provisionamento de máquina virtual, e não o virtualizador, por isso precisamos do hypervisor já instalado na máquina. Dentro do conceito do Vagrant, o hypervisor é o que eles chamam de provider, o provider default (padrão) do Vagrant é o VirtualBox, no entanto o mesmo possui suporte a diversos outros fornecedores como VMware, Hyper-V, Docker, etc. Porém neste how-ho será feito com VirtualBox, a forma de instalação do VirtualBox não é coberta nesse how-to, porém garanto que é MUITO simples.

Qual o link disponível do Vagrant para Download? https://www.vagrantup.com/downloads.html

O Vagrant possui suporte a algumas plataformas, dentre elas:

  • CentOS
  • Debian
  • Windows
  • MacOS X

Neste mini how-to vamos abordar tanto em CentOS quanto em Debian. Caso deseja aprender em Windows e/ou MacOS X, segue alguns links de apoio:

  1. Usando o Vagrant como ambiente de desenvolvimento no Windows
  2. Getting Started with Vagrant on OSX 10.10 Yosemite

2. Nossa Primeira Máquina Virtual Auto Provisionada

Então chega de enrolação, e vamos lá! =D

Faça o download do pacote no link https://www.vagrantup.com/downloads.html e baixe o correspondente a sua distribuição.

O modo de instalação é básico, usando o gerenciador de pacotes de baixo nível da sua distribuição. E o melhor que o Vagrant não possui dependências.


No CentOS, execute:

# rpm -ivh vagrant_1.8.5_x86_64.rpm


No Debian, execute:

# dpkg -i vagrant_1.8.5_x86_64.deb

Feita a instalação, já podemos começar a brincar com o Vagrant.

O uso do Vagrant é feito com usuário “comum” do sistema, no meu caso, estou logado no meu notebook com o usuário “elvis”. Não precisa ser feito como root!

Crie um diretório chamado MeuAmbiente (Estes procedimentos abaixo são executados em ambas as distribuições):

$ mkdir MeuAmbiente

Entre no diretório recém criado, e crie o arquivo pilar deste projeto, o vagrantfile. Abaixo segue o conteúdo do mesmo e a explicação dele como comentário no arquivo.

$ cd MeuAmbiente
$ vim vagrantfile
Vagrant.configure(2) do |config|
        config.vm.box = "ubuntu/trusty64" # Distribuição e Versão do SO
        config.vm.hostname = "linuxsrv01" # Hostname da VM
        config.vm.network "forwarded_port", guest: 80, host: 8081 # Encaminhamento de Porta de 80 para 8081
        config.vm.network "public_network", ip: "192.168.0.18" # Configuro IP público estático.
 
        config.vm.provider "virtualbox" do |vb|
                vb.memory = "1024" # 1GB de Memória RAM
                vb.cpus = "1" # Quantidade Core de CPU
                vb.name = "linuxsrv01" # Nome da máquina Virtual no VirtualBox
        end
 
        # Provisionar um servidor web (httpd) Apache com suporte a PHP5.
        config.vm.provision "shell", inline: &lt;

O próprio arquivo é bem claro, ele tem um começo (Vagrant.configure) e um fim (end), dentro desta cláusula passamos os parâmetros de provisionamento da máquina virtual a ser criada.

  • config.vm.box: é a imagem (Box) usada na máquina virtual, por exemplo centos/7, instala a máquina virtual com CentOS 7. Essas imagens são baixadas somente no primeiro provisionamento, em outras instalações que façam uso desta mesma imagem, não será mais necessário download. Mais informações podem ser obtidas em: https://www.vagrantup.com/docs/boxes.html
  • config.vm.hostname: Hostname da máquina virtual. Mais informações podem ser obtidas em: https://www.vagrantup.com/docs/vagrantfile/machine_settings.html
  • config.vm.network: Configurações de rede, encaminhamento de portas, etc. Mais informações podem ser obtidas em: https://www.vagrantup.com/docs/networking/basic_usage.html
  • config.vm.provider: Configurações passadas para o Hypervisor provisionar a máquina com a seguintes configurações especificadas. Mais informações podem ser obtidas em: https://www.vagrantup.com/docs/providers/basic_usage.html
  • config.vm.provision: Configura os passos de provisionamento da máquina virtual durante o primeiro boot. Este aceita diversos provisionadores como: Shell Script, Ansible, Chef e Puppet. Mais informações podem ser obtidas em: https://www.vagrantup.com/docs/provisioning/basic_usage.html

Agora que já entenderam os principais parâmetros do vagrantfile, precisamos apenas criar o arquivo index.php, com a função phpinfo, para coletar as evidências de que o módulo PHP5 já está disponível no Apache para iniciar o desenvolvimento e/ou testes de aplicação (por exemplo).

$ cd MeuAmbiente
$ vim index.php

O conteúdo do arquivo PHP:

<!--?php phpinfo(); ?-->

Com esta etapa pronta, podemos provisionar nossa primeira máquina. =D
O provisionamento é muito simples, dentro do diretório com o arquivo vagrantfile, execute o milagroso comando e aguarde alguns instantes:

$ vagrant up

Observe a saída do comando “vagrant up”, e nota que cada etapa que determinamos no arquivo vagrantfile estão sendo executadas uma a uma:

==&gt; default: Preparing to unpack .../php5-readline_5.5.9+dfsg-1ubuntu4.17_amd64.deb ...
==&gt; default: Unpacking php5-readline (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Selecting previously unselected package libaprutil1-dbd-sqlite3:amd64.
==&gt; default: Preparing to unpack .../libaprutil1-dbd-sqlite3_1.5.3-1_amd64.deb ...
==&gt; default: Unpacking libaprutil1-dbd-sqlite3:amd64 (1.5.3-1) ...
==&gt; default: Selecting previously unselected package libaprutil1-ldap:amd64.
==&gt; default: Preparing to unpack .../libaprutil1-ldap_1.5.3-1_amd64.deb ...
==&gt; default: Unpacking libaprutil1-ldap:amd64 (1.5.3-1) ...
==&gt; default: Selecting previously unselected package apache2-bin.
==&gt; default: Preparing to unpack .../apache2-bin_2.4.7-1ubuntu4.13_amd64.deb ...
==&gt; default: Unpacking apache2-bin (2.4.7-1ubuntu4.13) ...
==&gt; default: Selecting previously unselected package apache2-data.
==&gt; default: Preparing to unpack .../apache2-data_2.4.7-1ubuntu4.13_all.deb ...
==&gt; default: Unpacking apache2-data (2.4.7-1ubuntu4.13) ...
==&gt; default: Selecting previously unselected package apache2.
==&gt; default: Preparing to unpack .../apache2_2.4.7-1ubuntu4.13_amd64.deb ...
==&gt; default: Unpacking apache2 (2.4.7-1ubuntu4.13) ...
==&gt; default: Selecting previously unselected package libapache2-mod-php5.
==&gt; default: Preparing to unpack .../libapache2-mod-php5_5.5.9+dfsg-1ubuntu4.17_amd64.deb ...
==&gt; default: Unpacking libapache2-mod-php5 (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Selecting previously unselected package php5.
==&gt; default: Preparing to unpack .../php5_5.5.9+dfsg-1ubuntu4.17_all.deb ...
==&gt; default: Unpacking php5 (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Selecting previously unselected package ssl-cert.
==&gt; default: Preparing to unpack .../ssl-cert_1.0.33_all.deb ...
==&gt; default: Unpacking ssl-cert (1.0.33) ...
==&gt; default: Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
==&gt; default: Processing triggers for ureadahead (0.100.0-16) ...
==&gt; default: Processing triggers for ufw (0.34~rc-0ubuntu2) ...
==&gt; default: Setting up libapr1:amd64 (1.5.0-1) ...
==&gt; default: Setting up libaprutil1:amd64 (1.5.3-1) ...
==&gt; default: Setting up libaprutil1-dbd-sqlite3:amd64 (1.5.3-1) ...
==&gt; default: Setting up libaprutil1-ldap:amd64 (1.5.3-1) ...
==&gt; default: Setting up apache2-bin (2.4.7-1ubuntu4.13) ...
==&gt; default: Setting up apache2-data (2.4.7-1ubuntu4.13) ...
==&gt; default: Setting up apache2 (2.4.7-1ubuntu4.13) ...
==&gt; default: Enabling module mpm_event.
==&gt; default: Enabling module authz_core.
==&gt; default: Enabling module authz_host.
==&gt; default: Enabling module authn_core.
==&gt; default: Enabling module auth_basic.
==&gt; default: Enabling module access_compat.
==&gt; default: Enabling module authn_file.
==&gt; default: Enabling module authz_user.
==&gt; default: Enabling module alias.
==&gt; default: Enabling module dir.
==&gt; default: Enabling module autoindex.
==&gt; default: Enabling module env.
==&gt; default: Enabling module mime.
==&gt; default: Enabling module negotiation.
==&gt; default: Enabling module setenvif.
==&gt; default: Enabling module filter.
==&gt; default: Enabling module deflate.
==&gt; default: Enabling module status.
==&gt; default: Enabling conf charset.
==&gt; default: Enabling conf localized-error-pages.
==&gt; default: Enabling conf other-vhosts-access-log.
==&gt; default: Enabling conf security.
==&gt; default: Enabling conf serve-cgi-bin.
==&gt; default: Enabling site 000-default.
==&gt; default:  * Starting web server apache2
==&gt; default: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
==&gt; default:  *
==&gt; default: Setting up ssl-cert (1.0.33) ...
==&gt; default: Setting up php5-json (1.3.2-2build1) ...
==&gt; default: php5_invoke: Enable module json for cli SAPI
==&gt; default: php5_invoke: Enable module json for apache2 SAPI
==&gt; default: Setting up php5-common (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Creating config file /etc/php5/mods-available/pdo.ini with new version
==&gt; default: php5_invoke: Enable module pdo for cli SAPI
==&gt; default: php5_invoke: Enable module pdo for apache2 SAPI
==&gt; default: Creating config file /etc/php5/mods-available/opcache.ini with new version
==&gt; default: php5_invoke: Enable module opcache for cli SAPI
==&gt; default: php5_invoke: Enable module opcache for apache2 SAPI
==&gt; default: Setting up php5-cli (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: update-alternatives:
==&gt; default: using /usr/bin/php5 to provide /usr/bin/php (php) in auto mode
==&gt; default: Creating config file /etc/php5/cli/php.ini with new version
==&gt; default: php5_invoke json: already enabled for cli SAPI
==&gt; default: php5_invoke pdo: already enabled for cli SAPI
==&gt; default: php5_invoke opcache: already enabled for cli SAPI
==&gt; default: Setting up php5-readline (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Creating config file /etc/php5/mods-available/readline.ini with new version
==&gt; default: php5_invoke: Enable module readline for cli SAPI
==&gt; default: php5_invoke: Enable module readline for apache2 SAPI
==&gt; default: Processing triggers for ureadahead (0.100.0-16) ...
==&gt; default: Processing triggers for ufw (0.34~rc-0ubuntu2) ...
==&gt; default: Setting up libapache2-mod-php5 (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Creating config file /etc/php5/apache2/php.ini with new version
==&gt; default: php5_invoke readline: already enabled for apache2 SAPI
==&gt; default: php5_invoke json: already enabled for apache2 SAPI
==&gt; default: php5_invoke pdo: already enabled for apache2 SAPI
==&gt; default: php5_invoke opcache: already enabled for apache2 SAPI
==&gt; default: Module mpm_event disabled.
==&gt; default: Enabling module mpm_prefork.
==&gt; default: apache2_switch_mpm Switch to prefork
==&gt; default:  * Restarting web server apache2
==&gt; default: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
==&gt; default:    ...done.
==&gt; default: apache2_invoke: Enable module php5
==&gt; default:  * Restarting web server apache2
==&gt; default: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
==&gt; default:    ...done.
==&gt; default: Setting up php5 (5.5.9+dfsg-1ubuntu4.17) ...
==&gt; default: Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
==&gt; default: ‘/vagrant/index.php’ -&gt; ‘/var/www/html/index.php’

Após alguns instantes, podemos testar se o Apache esta no ar com o PHP 5 habilitado na máquina Virtual, como? Simples, abra seu navegador e acesse http://127.0.0.1:8081, lembre-se que fizemos o forwarding da máquina 8081 da máquina física para 80 da máquina virtual.


Nota-se que o arquivo index.php foi criado no mesmo diretório que continha o arquivo vagrantfile, durante o provisionamento, o vagrant copia tudo que tem dentro deste diretório da máquina física para dentro do diretório /vagrant, dentro da máquina virtual. Caso seja máquina CentOS em algumas versões antigas, ele sincroniza no diretório /home/vagrant/sync.

Além disso, é possível visualizar a máquina criada, diretamente no VirtualBox:

3. Outros comandos úteis do Vagrant

É possível acessar a máquina virtual provisionada via SSH pelo próprio vagrant, através do comando vagrant ssh (dentro do diretório da vm correspondente)

$ vagrant ssh
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-92-generic x86_64)
 
 * Documentation:  https://help.ubuntu.com/
 
 System information disabled due to load higher than 1.0
 
  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud
 
vagrant@linuxsrv01:~$ sudo su
root@linuxsrv01:/home/vagrant#

Este mesmo comando pode ser usado para mais de uma máquina, quando se quer acessar um host em específico execute vagrant ssh nomedamaquina:

$ vagrant ssh linuxsrv01
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-92-generic x86_64)
 
 * Documentation:  https://help.ubuntu.com/
 
 System information disabled due to load higher than 1.0
 
  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud
 
vagrant@linuxsrv01:~$

Caso deseje desligar a máquina, é possível desligar a mesma diretamente pelo próprio Vagrant, através do comando “vagrant halt”.

$ vagrant halt
==&gt; default: Attempting graceful shutdown of VM...

Em um cenário com multiplas máquinas virtuais, é possível desligar uma única máquina em específica:

$ vagrant halt linuxsrv01
==&gt; linuxsrv01: Attempting graceful shutdown of VM...

Além disso, é possível também remover a máquina virtual:

$ vagrant destroy
    default: Are you sure you want to destroy the 'default' VM? [y/N] y
==&gt; default: Destroying VM and associated drives...

Em um cenário com multiplas máquinas virtuais, é possível remover uma única máquina em específica:

$ vagrant destroy linuxsrv01
    linuxsrv01: Are you sure you want to destroy the 'linuxsrv01' VM? [y/N] y
==&gt; linuxsrv01: Destroying VM and associated drives...

4. Adicionando novas Boxes (Imagens) no Vagrant.

Como explicado acima, quando feito o provisionamento da máquina virtual pela primeira vez, com aquela respectiva imagem da versão da distribuição ou sistema, o vagrant faz o download direto do repositório oficial (https://atlas.hashicorp.com/boxes/search), outras máquinas virtuais que forem fazer uso da mesma imagem da versão da distribuição ou sistema, não precisara fazer novamente o download, poupando esforço.

Porém existe também forma de adicionar imagens customizadas pela comunidade direto no seu Vagrant, por exemplo:

$ vagrant box add "OpenBSD 5.3 64-bit" https://dl.dropboxusercontent.com/u/12089300/VirtualBox/openbsd53_amd64.box

No link a seguir http://www.vagrantbox.es/ possui diversas Boxes (imagens) prontas para uso com Vagrant. Sinta-se a vontade para brincar com elas. \o/

5. Trabalhando como Multiplas Máquinas.

É possível construir cenários complexos, com mais de uma máquina virtual como no exemplo feito. Abaixo faremos um cenário onde teremos um balanceador de carga com Nginx e dois nós atrás com Apache (httpd) 2.4 trabalhando integrados.

O Vagrantfile multi-machine, fica configurado conforme abaixo, primeiramente crie o arquivo Vagrantfile e adicione o seguinte conteúdo:

$ vim Vagrantfile
Vagrant.configure("2") do |config|
 
        # Balanceador de Carga
        config.vm.define "nginx01" do |nginx01|
        nginx01.vm.box = "centos/7" # Distribuição e Versão do SO
        nginx01.vm.hostname = "nginx01" # Hostname da VM
        nginx01.vm.network "private_network", ip: "192.168.50.2"
        nginx01.vm.network "forwarded_port", guest: 80, host: 8080 # Encaminhamento de Porta de 8080 (Física) para 80 (VM)
 
 
        nginx01.vm.provider "virtualbox" do |vb|
                vb.memory = "512" # 512MB de Memória RAM
                vb.cpus = "1" # Quantidade Core de CPU
                vb.name = "nginx01" # Nome da máquina Virtual no VirtualBox
        end
 
                # Provisiona Nginx como Balanceador de Carga
                nginx01.vm.provision "shell", :path =&gt; "scripts/nginx.sh"
        end
 
        # Node app01
        config.vm.define "app01" do |app01|
                app01.vm.box = "centos/7" # Distribuição e Versão do SO
                app01.vm.hostname = "app01" # Hostname da VM
                app01.vm.network "private_network", ip: "192.168.50.3"
 
                app01.vm.provider "virtualbox" do |vb|
                        vb.memory = "512" # 512MB de Memória RAM
                        vb.cpus = "1" # Quantidade Core de CPU
                        vb.name = "app01" # Nome da máquina Virtual no VirtualBox
                end
 
                 # Provisiona Apache em Node 01
                app01.vm.provision "shell", :path =&gt; "scripts/apache2.sh"
        end
 
 
        # Node app02
        config.vm.define "app02" do |app02|
                app02.vm.box = "centos/7" # Distribuição e Versão do SO
                app02.vm.hostname = "app02" # Hostname da VM
                app02.vm.network "private_network", ip: "192.168.50.4"
 
                app02.vm.provider "virtualbox" do |vb|
                        vb.memory = "512" # 512MB de Memória RAM
                        vb.cpus = "1" # Quantidade Core de CPU
                        vb.name = "app02" # Nome da máquina Virtual no VirtualBox
                end
 
                 # Provisiona Apache em Node 02
                app02.vm.provision "shell", :path =&gt; "scripts/apache2.sh"
        end
 
end

Note que estamos criando tês maquinas Virtuais, uma chamada nginx01 e outras duas chamadas app01 e app02. No Nginx estamos instalando e configurando o balanceador de carga e nos apps estamos apenas instalando o apache e adicionando uma index simples.

Mas mesmo assim não fica evidente onde esta sendo executado estes procedimentos, na verdade eles estão sendo feito nos scripts, assim como a configuração também esta dentro dos scripts que estão sendo chamados pelo provisionador. Para preparar o cenário, crie dois diretórios:

  • conf
  • scripts

Execute:

$ mkdir conf
$ scripts

Adicione os dois arquivos abaixo dentro conf:

  • nginx.repo
  • balancer.conf

Execute:

$ vim conf/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
$ vim conf/balancer.conf
# Pool do Load balancer
upstream pool.linuxsysadmin.com.br {
        server 192.168.50.3;
        server 192.168.50.4;
}
 
# Informações de proxy passadas no cabeçalho HTTP
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Queue-Start “t=${msec}000;
 
# Proxy Pass do balanceador
server {
    listen       80;
    server_name  localhost;
 
        location / {
                proxy_pass http://pool.linuxsysadmin.com.br;
        }
}

Em seguida copie os dois scripts abaixo para dentro do diretório scripts.

$ vim scripts/nginx.sh
#!/bin/bash
 
if [ -e "/vagrant" ]; then
 
        VAGRANT_HOME="/vagrant"
 
elif [ -e "/home/vagrant/sync" ]; then
 
        VAGRANT_HOME="/home/vagrant/sync"
 
else
 
        echo "Not sync folder"
        exit 1
 
fi
 
# Desabilita o SELinux.
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
setenforce 0
 
# Copia o repositório oficial do Nginx para a VM.
cp -v /vagrant/conf/nginx.repo /etc/yum.repos.d
 
# Instalar Nginx.
yum -y install nginx
 
# Configura o Balanceador de Cagra.
mv -fv ${VAGRANT_HOME}/conf/balancer.conf /etc/nginx/conf.d/
 
# Subindo o serviço Nginx
systemctl restart nginx
systemctl enable nginx

$ vim scripts/apache2.sh
#!/bin/bash
 
# Determina qual o Sync Folder do Vagrant
if [ -e "/vagrant" ]; then
 
        VAGRANT_HOME="/vagrant"
 
elif [ -e "/home/vagrant/sync" ]; then
 
        VAGRANT_HOME="/home/vagrant/sync"
 
else
 
        echo "Not sync folder"
        exit 1
 
fi
 
# Desabilita o SELinux.
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
setenforce 0
 
# Instala o apache
yum -y install httpd
 
# Cria a pagina index.html
echo "$(hostname)" &gt; /var/www/html/index.html
 
# Subindo o serviço apache
systemctl restart httpd
systemctl enable httpd

Desta forma organizamos o nosso Vagrantfile, ficando menos poluído, limpo. O conceito continua sendo o mesmo, sendo a única diferença que ao invés de passarmos vários comandos para o vagrant, apenas fazemos ele chamar um único script.

Com essa estrutura montada, basta executar “vagrant up”, a saída deverá ser parecida com a tela abaixo:

$ vagrant up
Bringing machine 'nginx01' up with 'virtualbox' provider...
Bringing machine 'app01' up with 'virtualbox' provider...
Bringing machine 'app02' up with 'virtualbox' provider...
(...)

Em meu notebook este ambiente foi criado em menos 8 minutos, levando em consideração que meu notebook possui uma configuração básica de mercado, em máquinas mais “parrudas” este ambiente seria construindo muito mais rápido. Outro fator é que eu não precisei baixar a imagem do CentOS 7, já que eu havia instalado este SO, se fosse a primeira vez provavelmente seria feito mais rápido.

Após o ambiente ser criado, basta adicionar em seu /etc/hosts na última linha:

$ sudo vim /etc/hosts
(...)
127.0.0.1       pool.linuxsysadmin.com.br

E acesse seu navegador:

Pode executar F5 para atualizar a página e verificar nginx balanceia as requisições entre os dois nodes app01 e app02. =)

Para mais informações sobre como trabalhar com o modo “Multi-machines”: https://www.vagrantup.com/docs/multi-machine/

6. Conclusão.

Bem, espero que você tenha gostado do post, e principalmente que lhe seja útil em sua jornada e carreira profissional para agilizar seus ambientes, focando no que realmente interessa, sem perder tempo com aquela dor de cabeça de criar máquina virtual, instalar o sistema operacional, preparar o ambiente, instalar e configurar dependências, etc. rs

Forte abraço e sucesso!

Zabbix: Monitorando Jobs de Backups do CA ARCServe

Olá Pessoal,

Devido a dúvida de alguns da comunidade Zabbix. Venho compartilhar o monitoramento dos Jobs do ARCServe Backup, este monitoramento é feito através do comando ca_qmgr do próprio servidor de Backup, que lista a fila e o estado dos jobs.

Utilizei um script VBS para esta tarefa, chamado de check_Arcserve_jobstatus.vbs, a qual verifica os estado dos Jobs. Este script foi utilizado pela comunidade do Nagios, como havia prazo para entregar este monitoramento, foi preciso agilizar o processo de monitoramento, sem reinventar a roda, por isto optei por utilizar o mesmo, que atendeu adequadamente a necessidade.

No entanto, é importante frisar, que não tenho conhecimento em VB Script, por essa razão não tive tempo hábil de fuçar no script e modifica-lo para torna-lo dinâmico com LLD (Low Level Discovery), o que tornaria o mesmo mais atraente.

1. Preparando o cenário

Crie uma pasta chamada Scripts dentro do diretório corrente do servidor de backup (CA ARCServe). Todo o monitoramento dos Jobs é feito exatamente neste mesmo servidor. A estrutura do diretório deve ficar da seguinte forma:

c:\Zabbix\Scripts

Em seguida copie o script abaixo dentro de C:\Zabbix\Scripts\check_Arcserve_jobstatus.vbs com seu editor de texto favorito.

iCritical = 0
iWarning = 0
iSuccess = 0
 
strCmd = CMD("""C:\Program Files\CA\ARCserve Backup\ca_qmgr.exe"" -list")
 
Lines = Split(strCmd, vbCrLf)
 
for each Line in Lines
        iPos = inStr(Line, "READY")
        if (iPos) then
                select case (Trim(Mid(Line, iPos + 42, 15)))
                case "FINISHED"
                        iSuccess = iSuccess + 1
                case "FAILED", "RUN FAILED", "CRASHED"
                        iCritical = iCritical + 1
                case "INCOMPLETE", "CANCELLED"
                        iWarning = iWarning + 1
                end select
        end if
next
 
Out = ""
 
if (iCritical) then
        Out = iCritical
end if
if (iWarning) then
        Out = iWarning
end if
if (iSuccess) then
        Out = iSuccess
end if
if (iCritical = 0) and (iWarning = 0) and (iSuccess = 0) then
        Out = 3
end if
 
WScript.StdOut.WriteLine (Out)
 
function CMD(byRef cmdLine)
        set oShell = WScript.CreateObject("WScript.Shell")
    set oExec = oShell.Exec(cmdLine)
 
    ret = oExec.StdOut.Readall()
    set oExec = nothing: Set oShell = nothing
 
        CMD = ret
end function

Edite o arquivo zabbix_agentd.conf dentro de C:\Zabbix\conf (ou o diretório onde encontra o seu arquivo de configuração) e adicionado na última linha o parâmetro necessário para que funcione o monitoramento dos Jobs de Backup.

UserParameter=job.backup.status,cscript //NoLogo C:\Zabbix\Scripts\check_Arcserve_jobstatus.vbs

Devido a questões de restrições e/ou políticas de segurança, o usuário SYSTEM, mesmo usuário proprietário dos serviços do Windows, o mesmo não tinha permissão para execução de scripts, por tanto caso você passe pela mesma situação, será necessário alterar o usuário que inicia e executa o serviço para um usuário que tenha permissões adequadas para executar este script e iniciar o serviço do agente zabbix.

Acesse o services.msc do Windows Server, e clique em propriedades do serviço Zabbix Agent, e informe a conta as permissões. No print abaixo consta o Domain Admin, no entanto, não recomendo o uso do mesmo para este cenário.

Após este ajuste é necessário reiniciar o serviço do agente zabbix para aplicar as alterações.

Em seguida crie um template no zabbix da seguinte da seguinte forma: Acesse Configurações > Templates:

Após entrar em Templates, clique em “Criar Template” e preencha o mesmo como no modelo abaixo e clique em add:

Após criar o template, clique em Administração > Geral, e em seguida selecione “Mapeamento de Valores”, e preencha os mesmos da seguinte forma (Lembre-que segui o mesmo modelo do Nagios, por tanto, pra ficar mais claro o resultado do monitoramento, essa é a forma mais intuitiva):

Volte em templates, e clique no template recém criado, entre em Aplicações e cria a aplicação “Jobs Backups”.

Após criar a aplicação, clique em itens, e crie o item abaixo de monitoramento dos Jobs e Backup.

E por fim, clique em Triggers, e crie o threshold da seguinte forma:

Feito o template, pode adicionar o mesmo no Host (Servidor de Backup CA ARCServe), e após alguns instantes já é possível monitora-lo, visualizando a coleta em Monitoramento > Dados Recentes:

Em caso de alarme, a trigger será acionada no zabbix da seguinte forma:

Pessoal espero que isso lhes ajude. De qualquer forma, forte abraço e grato pela atenção!

Fonte: CA ARCserve Backup r12 Number of Job Error Check

Quero trabalhar com Linux!


Olá,

Nesse post vou dar algumas dicas para quem pretende ingressar em uma carreira como Administrador de Sistemas Linux (Linux Sysadmin).

1. Refletir.

Primeiramente eu gostaria que você refletisse o por que você pretende entrar no mercado de Linux, por exemplo:

  1. Porque Linux da muito dinheiro
  2. Porque vejo boas oportunidades em Linux
  3. Porque gosto de Linux
  4. Porque estou insatisfeito com meu trabalho

Bem, claramente os pontos do porque trabalhar com Linux, estão bem limitados, até porque não caberiam todos os motivos possíveis, mas dos listados acima, claramente o que eu vejo que se adequaria ao perfil é o 2 e principalmente o 3, pois enxergam o Linux não apenas como cédulas de dinheiro ($$$), mas sim por enxergar o Linux como oportunidade de oferecer serviço de qualidade e por apreciar o sistema operacional, o que motiva ainda mais o profissional a se desenvolver mais do que aqueles que não tem o mínimo interesse pelo lado técnico.

Sim, gostar de Linux para trabalhar com o mesmo é F-U-N-D-A-M-E-N-T-A-L.

2. “Mas Elvis, eu odeio linha de comando”

Então desculpe, você não tem possibilidade N-E-N-H-U-M-A de trabalhar com Linux e qualquer outro sistema Unix, e não, eu não estou sendo agressivo e nem maldoso, estou sendo S-I-N-C-E-RO de todo meu coração. Você que pretende trabalhar com Linux tem que ter ciência de quê:

  • Linux não é fácil!
  • Linha de comando não é fácil
  • Necessário aprender diversos conceitos que eram mascarados para você no antigo sistema operacional (Principalmente Microsoft Windows).
  • Não pode odiar programação, pois Shell e scripts seguem lógicas iguais as usadas em algoritmos.

Tendo ciência de que esses fatores listados acima são essenciais você vai precisar mais do que sorte, mas sim o principal: FORÇA DE VONTADE!

3. Como aprender Linux?

Existem enormes possibilidades de conhecer mais o Linux, como:

  1. Instalando ele.
  2. Fazendo cursos.
  3. Lendo artigos de internet.
  4. Lendo livros e/ou e-books.
  5. etc.

O aprendizado em Linux é baseado em prática, exercer a função de administrador Linux não é apenas digitar comandos, mas sim saber analisar logs e identificar incidentes para poder diagnosticar o problema e propor soluções.

E para chegar no ponto de propor uma solução para um problema precisa pensar fora da caixa, ir além do feijão com arroz, saber implementar um servidor web não é difícil, o difícil é gerir, identificar problemas, e propor as soluções para esses problemas é o que faz do seu trabalho ser visto com qualidade.

Uma vez um professor meu da época da faculdade disse:

“Decorar comandos e digita-los qualquer um tem capacidade para isso. Um profissional Linux usa 90% do tempo seu cérebro ao invés do teclado.

Prof. Francisco Pinto – UNINOVE

4. O que você recomenda?

Eu recomendo inicialmente:

  • Procurar leituras sobre o assunto
  • Instalar o Linux em uma máquina virtual, como VirtualBox ou VMware, para poder ter contato com ele.
  • Aprender instalar e configurar alguns serviços, como Apache ou PostgreSQL, por exemplo.
  • Entender os conceitos fundamentais de administração de sistema e redes.

E conforme for evoluindo com seus aprendizados, procure ser mais ousado, tentando aprender novos serviços com maior complexidade testando sua força de vontade e capacidade atual.

5. Mas eu já sei Linux, agora quero arrumar um emprego!

Minhas dicas são:

  1. Arrisque, não fique acomodado no seu emprego, caso ele não lhe seja mais proporcional a sua vontade de crescer.
  2. Não seja tolo de achar que vai ganhar 5 mil reais ou mais com um salário como Júnior.
  3. Ninguém entra no primeiro emprego como Administrador de Sistemas Sênior.
  4. Faça um currículo coerente com suas experiências e evidencie a sua vontade em ingressar no mercado de Linux/Unix.
  5. Tente formular seus conhecimentos no currículo de forma coerente, por exemplo:
  • Conhecimentos em ambiente de servidores Linux e seus serviços:
  • Apache servindo a função de servidor web ou como balanceamento de carga para aplicações críticas
  • Conhecimento em Bacula para a execução de rotinas de Backup diários e semanais, seguindo as boas práticas de TI.

E não:

  • Conhecimento em: Linux, Apache, Nginx, Varnish, Bacula,PostgreSQL, Zabbix, Nagios,Samba,Squid,Postfix,Zimbra,etc.

6. Participe da comunidade Linux

Quanto mais você participa da comunidade, maior o seu networking e maior você é destacado dentre os profissionais que participam ativamente da comunidade.

Troque experiências, divulgue suas experiências não apenas como descrição breve,, mas sim tecnicamente para ajudar outros colegas de área, que apesar de serem concorrentes, são parceiros da comunidade e o espírito de compartilhar conhecimento é não só bem visto na comunidade FOSS (Free and Open Source Solutions) como profissionalmente, o mercado de trabalho da MUITO valor para isso.

7. Faça networking

Tenha em mente que ter networking não significa puxar saco de ninguém, mas sim formar parcerias profissionais para que possam te indiciar ou mesmo te orientar melhor através de feedbacks para que você evolua como profissional e se destacar dentro do meio profissional a qual você busca, e isso não se restringe apenas a Linux.

8. Existe servidores Linux na minha empresa, mas meu chefe disse que não posso mexer…

Mostre para seus superiores que você pretende migrar para o ambiente Unix/Linux, mostre para eles não apenas o interesse mas que você tem capacidade de gerir um ambiente Linux de forma que eles possam sentir confiança. Até porque um bom profissional não é apenas aquele que sabe digitar comandos no console, mas sim aquele que sabe diagnosticar, suportar e implantar ambientes, propor solução e etc. Além disso, questões como comunicação e seguir políticas internas da TI servem igualmente para Linux assim como qualquer outro meio, seguir boas práticas também é um fator essencial, ser nerd é algo que faz se destacar muito na comunidade Linux, mas INFELIZMENTE não é bem visto nas empresas, então você tem que saber dosar sua nerdice, seja nerd, mas seja também profissional, com postura e entenda como se comportar, com essas dicas já é o suficiente para você ao menos passar a ajudar a suportar ou mesmo identificar incidentes nos poucos servidores Linux que tem dentro da sua empresa, pois as vezes sua oportunidade não esta no mercado mas sim dentro da mesma empresa a qual você se encontra hoje.

9. Quero apenas uma chance…

É o que todos queremos, meu conselho é:

  • Busque por uma vaga de Júnior e se dedica a empresa, pois seu crescimento vai ser valioso para sua carreira.
  • Não ligue para o salário, caso você não tenha filhos e/ou dívidas grandes. Pois sua capacidade profissional vai fazer automaticamente com que seu salário cresça gradativamente até chegar ao que você busca.
  • Muitas empresas no mercado buscam profissionais “crus”, sem vícios e não muito capacitados tecnicamente pois são caros e formam profissionais com esse perfil de pouca experiência, talvez essa seja a chave para você entrar no mercado de Linux.

Conclusão.

Eu sei como é isso, quando eu quis entrar na área também foi muito complicado, sofri muito preconceito por não ter o conhecimento de um sênior e também porque não tinha a vasta bagagem que o mercado buscava, fui muito subestimado pelo mercado, recebi muitos “NÃO’s”, mas não deixei que essas respostas fizessem com que eu desisti-se.

Se eu fui capaz, você também é, não desista por mais difícil que seja a primeira oportunidade e quando a encontrar agarre com unhas e dentes, pois se é Linux que você quer seguir como carreira, encare isso como a chance da sua vida, porque se você ama a tecnologia com que trabalha e faz com qualidade, é natural que você se destaque no mercado de trabalho.

Monitorando com Nagios: Instalação dos agentes, fácil e prático!

Olá pessoal,

No capítulo anterior abordamos a instalação do servidor Nagios Core, caso você não viu, recomendo a leitura.

1. Introdução

No post anterior eu publiquei a instalação do servidor, porém só o servidor não adianta muito, afinal como iremos monitorar? Temos o servidor, mas não temos uma ideia de como monitorar os nossos ativos. Agora precisamos aprender a monitorar com o Nagios. Nesse post pretendo explicar o monitoramento de servidores Linux: RHEL e Debian.
Talvez num futuro não muito distante podemos abordar sobre o monitoramento através de ativos com suporte a SNMP, entretanto iremos monitorar através do NRPE, que é o agente do Nagios.

2. Cenário

Se você seguiu o post anterior, provavelmente seu Nagios já esta funcionando bonitinho, no entanto precisamos de um novo servidor, esse novo servidor será o host a qual iremos monitorar, podendo ser: RHEL ou Debian.

3. Instalando o NRPE (Agente)

Vamos instalar inicialmente os agentes NRPE, para prosseguir com as configurações.

No Red Hat/CentOS, é necessário a instalação do repositório EPEL, pois o repositório nativo não tem disponível os pacotes do nagios. Lembram-se?


No Red Hat, execute:

CentOS/RHEL 6, 32 Bit:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
 
CentOS/RHEL 6, 64 Bit:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
 
CentOS/RHEL 5, 32 Bit:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
 
CentOS/RHEL 5, 64 Bit:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-releas5-4.noarch.rpm

Após a instalação do repositório, basta iniciar a instalação do Nagios Core.


No Red Hat, execute somente no cliente:

# yum install nrpe nagios-plugins
# chkconfig nrpe on


No Debian, execute somente no cliente:

# apt-get install nagios-nrpe-server nagios-plugins

3. Configurando o NRPE (Agente)

Edite o arquivo nrpe.conf:


No Red Hat, execute somente no cliente:

# vim /etc/nagios/nrpe.cfg
(...)
# Endereço IP do seu Nagios Core (Server)
allowed_hosts=10.100.0.111
(...)
# Descomente as linhas abaixo
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
# Altere de hda1 para sda1
command[check_sda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200


No Debian, execute somente no cliente:

# vim /etc/nagios/nrpe.cfg
(...)
# Endereço IP do seu Nagios Core (Server)
allowed_hosts=10.100.0.111
(...)
# Descomente as linhas abaixo
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
# Altere de hda1 para sda1
command[check_sda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200

  • allowed_hosts: Este parâmetro informa quais hosts tem permissão para executar os plugins que determinamos.
  • command[comando]: Este comando cria um “comando” que será usado chamando os plugins/scripts que trazem as coletas de dados para o Nagios.

Realizada as alterações, reinicie o serviço NRPE.


No Red Hat, execute somente no cliente:

# service nrpe restart


No Debian, execute somente no cliente:

# nagios-nrpe-server restart

4. Instalando o NRPE no Nagios Core (Servidor)

Agora precisamos instalar o NRPE no servidor Nagios, o NRPE deve ser instalado nas duas pontas. Instalamos no capítulo anterior no cliente, host a qual será monitorado, e neste iremos abordar a instalação no Nagios Core (Servidor de monitoramento).


No Red Hat, execute somente no Nagios Core (server):

# yum install nrpe


No Debian, execute somente no Nagios Core (server):

# apt-get install nagios-nrpe-server

Agora precisamos testar nossa configuração, já que o NRPE já esta instalado nas duas pontas e liberado o IP do servidor Nagios no cliente, o host que será monitorado, basta executar:


No Red Hat, execute somente no Nagios Core (server):

# /usr/lib&lt;64&gt;/nagios/plugins/check_nrpe -H IPDOSERVIDORQUESERAMONITORADO
NRPE v2.15


No Debian, execute somente no Nagios Core (server):

# /usr/lib/nagios/plugins/check_nrpe -H IPDOSERVIDORQUESERAMONITORADO
NRPE v2.13

5. Configurando o Nagios Core

Este procedimento deve ser executado no Nagios Core, no servidor de monitoramento, e não no host a qual será monitorado. É importante se atentar a esta questão, ok?


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/nagios.cfg
(...)
#cfg_file=/etc/nagios/objects/commands.cfg
#cfg_file=/etc/nagios/objects/contacts.cfg
#cfg_file=/etc/nagios/objects/timeperiods.cfg
#cfg_file=/etc/nagios/objects/templates.cfg
#cfg_file=/etc/nagios/objects/localhost.cfg
#cfg_file=/etc/nagios/objects/windows.cfg
#cfg_file=/etc/nagios/objects/switch.cfg
#cfg_file=/etc/nagios/objects/printer.cfg
cfg_dir=/etc/nagios/objects
cfg_dir=/etc/nagios/servers
#cfg_dir=/etc/nagios/printers
#cfg_dir=/etc/nagios/switches
#cfg_dir=/etc/nagios/routers
cfg_dir=/etc/nagios/conf.
(...)
:x!
# service nagios restart


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/nagios.cfg
(...)
#cfg_file=/etc/nagios3/objects/commands.cfg
#cfg_file=/etc/nagios3/objects/contacts.cfg
#cfg_file=/etc/nagios3/objects/timeperiods.cfg
#cfg_file=/etc/nagios3/objects/templates.cfg
#cfg_file=/etc/nagios3/objects/windows.cfg
#cfg_file=/etc/nagios3/objects/switch.cfg
#cfg_file=/etc/nagios3/objects/printer.cfg
cfg_dir=/etc/nagios3/servers
cfg_dir=/etc/nagios3/objects
#cfg_dir=/etc/nagios3/printers
#cfg_dir=/etc/nagios3/switches
#cfg_dir=/etc/nagios3/routers
(...)
# mkdir /etc/nagios3/servers
# service nagios3 restart

6. Criando o grupo de hosts

Agora precisamos criar o arquivo host_groups.cfg, a qual contém os membros que vão pertencer a esse grupo. No caso, o nosso servidor que será monitorado em nosso laboratório:


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/host_groups.cfg
define hostgroup{
        hostgroup_name  laboratorio ; Nome do grupo de hosts.
        alias           Laboratorio Linux SysAdmin ; Apelido do grupo de hosts.
        members         srvlab01     ; O nome do membro do grupo que estamos criando.
        # members         srvlab01,srvlab02,srvlab03,... caso pretenda futuramente adicionar novos servidores no grupo.
        }
:x!


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/host_groups.cfg
define hostgroup{
        hostgroup_name  laboratorio ; Nome do grupo de hosts.
        alias           Laboratorio Linux SysAdmin ; Apelido do grupo de hosts.
        members         srvlab01     ; O nome do membro do grupo que estamos criando.
        # members         srvlab01,srvlab02,srvlab03,... caso pretenda futuramente adicionar novos servidores no grupo.
        }
:x!

7. Criando um template para o nosso host e para nossos serviços.

7.1 Criando o host template.

Agora precisamos criar um modelo de Host, que servira de exemplo para uso no host que iremos monitorar e em futuros servidores que queiram utilizar. Esses templates no Nagios funcionam basicamente para definir questões básicas sobre o monitoramento desse ativo, por exemplo:

  • Habilitar notificação
  • Retenção de dados
  • Período de notificação
  • Opções de notificações
  • Entre outros detalhes


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/templates.cfg
define host{
        name                            lab-template    ; Nome do nosso template de Hosts
        notifications_enabled           1       ; Habilitar/desabilitar Notificações
        flap_detection_enabled          1
                check_command                   check-host-alive ; Comando que será utilizado para checar a disponibilidade do ativo.
                max_check_attempts              3 ; Número de tentativas antes de o Nagios notificar.
                notification_interval           0 ; Desabilita o intervalo de notificação, ou seja, será notificado apenas uma vez, ao inves de ficar re-enviando.
                notification_period             24x7x365 ; Período de notificação.
                notification_options            d,u,r ; Os tipos de notificação que será enviados: d = Down (indisponível), r = Recovery (Disponível, ou seja status OK) e por ultimo u = Unknown (Desconhecido, ou seja, o status não é reconhecido como falha e nem estabilidade)
                contact_groups                  nagios-linuxsysadmin ; Qual grupo de contatos será notificado.
        register
        }
:x!


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/templates.cfg
define host{
        name                            lab-template    ; Nome do nosso template de Hosts
        notifications_enabled           1       ; Habilitar/desabilitar Notificações
        flap_detection_enabled          1
                check_command                   check-host-alive ; Comando que será utilizado para checar a disponibilidade do ativo.
                max_check_attempts              3 ; Número de tentativas antes de o Nagios notificar.
                notification_interval           0 ; Desabilita o intervalo de notificação, ou seja, será notificado apenas uma vez, ao inves de ficar re-enviando.
                notification_period             24x7x365 ; Período de notificação.
                notification_options            d,u,r ; Os tipos de notificação que serão enviados: d = Down (indisponível), r = Recovery (Disponível, ou seja status OK) e por ultimo u = Unknown (Desconhecido, ou seja, o status não é reconhecido como falha e nem estabilidade)
                contact_groups                  nagios-linuxsysadmin ; Qual grupo de contatos será notificado.
        register
        }
:x!

7.2 Criando o service template.

Agora precisamos criar um modelo de serviço, pois o nagios segmenta o que é um ativo e o que é um item, ou seja:

  • Monitorar espaço em disco
  • Monitorar memória
  • Monitorar processos ativos
  • Monitorar tráfego de rede
  • Monitorar portas de rede: 80 (HTTP), 22 (SSH), 21 (FTP), etc.

Esses itens são serviços para o Nagios, por isso o host e serviços são tratados de formas distintas.
Bem, agora que vocês entenderam o que é um serviço, vamos criar o nosso modelo de serviço.


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/templates.cfg
(...)
define service{
        name                            service-lablinuxsysadmin ; O nome do template de serviço
        active_checks_enabled           1       ; Habilitar/desabilitar checagens ativas.
        passive_checks_enabled          1       ; Habilitar/desabilitar checagens passivas.
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Habilitar/desabilitar notificação de indisponibilidade de serviço
        event_handler_enabled           1       ; Habilitar/desabilitar notificação de manipulador de eventos.
        flap_detection_enabled          1       ; Habilitar/desabilitar detecção de falsos-positivos
        process_perf_data               1
        retain_status_information       1
        retain_nonstatus_information    1
                notification_interval           0  ; Desabilita o intervalo de notificação, ou seja, será notificado apenas uma vez, ao inves de ficar re-enviando.
                check_period                    24x7x365 ; Período de checagem dos itens (serviços)
                normal_check_interval           5       ; Intervalo de checagem é de 5 minutos. (Se o parâmetro interval_length, estiver setado como 60 segundos, conforme no modelo a seguir: 60 * 5 = 300 [5 minutos] )
                retry_check_interval            1       ;  Minutos a aguardar antes de agendar uma nova verificação quando o serviço foi alterado para qualquer estado que não seja OK.
                max_check_attempts              4       ; Número de tentativas antes de o Nagios notificar.
                notification_period             24x7x365 ; Período de notificação
                notification_options            w,u,c,r ; Todas as opção de notificações, conforme o resultado de status d
e um serviço, UP, Down, etc.
                contact_groups                  nagios-linuxsysadmin ; O Grupo que sera acionado (Notificado) pelo Nagios.
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }
(...)
:x!
# service nagios restart


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/templates.cfg
(...)
define service{
        name                            service-lablinuxsysadmin ; O nome do template de serviço
        active_checks_enabled           1       ; Habilitar/desabilitar checagens ativas.
        passive_checks_enabled          1       ; Habilitar/desabilitar checagens passivas.
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Habilitar/desabilitar notificação de indisponibilidade de serviço
        event_handler_enabled           1       ; Habilitar/desabilitar notificação de manipulador de eventos.
        flap_detection_enabled          1       ; Habilitar/desabilitar detecção de falsos-positivos
        process_perf_data               1
        retain_status_information       1
        retain_nonstatus_information    1
                notification_interval           0  ; Desabilita o intervalo de notificação, ou seja, será notificado apenas uma vez, ao inves de ficar re-enviando.
                check_period                    24x7x365 ; Período de checagem dos itens (serviços)
                normal_check_interval           5       ; Intervalo de checagem é de 5 minutos. (Se o parâmetro interval_length, estiver setado como 60 segundos, conforme no modelo a seguir: 60 * 5 = 300 [5 minutos] )
                retry_check_interval            1       ;  Minutos a aguardar antes de agendar uma nova verificação quando o serviço foi alterado para qualquer estado que não seja OK.
                max_check_attempts              4       ; Número de tentativas antes de o Nagios notificar.
                notification_period             24x7x365 ; Período de notificação
                notification_options            w,u,c,r ; Todas as opção de notificações, conforme o resultado de status d
e um serviço, UP, Down, etc.
                contact_groups                  nagios-linuxsysadmin ; O Grupo que sera acionado (Notificado) pelo Nagios.
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }
:x!
(...)
# service nagios3 restart

8. Período de notificações.

Qual é o período que o Nagios notifica em caso de falha nos meus ativos? Essa pergunta é curiosa, porque se vocês notarem que o arquivo templates.cfg, criamos nosso template definindo o parâmetro notification_period com o seguinte valor: 24x7x365

  • Mas o que é o 24x7x365? 24x7x365 é apenas um nome, nada mais do que isso.
  • Ok Elvis, mas nome do que? Do timeperiod, o nagios possui o recurso chamado timeperiod, que são a definição de períodos em que um host é monitorado. Podendo ser definidos de acordo com quem administra a ferramenta, isso torna o Nagios muito flexível.

Certo, agora entenderam o conceito de como funciona e para que serve um timeperiod, vamos fazer o nosso timeperiod, chamado 24x7x365.


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/timeperiods.cfg
define timeperiod{
        timeperiod_name 24x7x365
        alias           24x7x365 full monitoring
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
        }
:x!


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/timeperiods.cfg
define timeperiod{
        timeperiod_name 24x7x365
        alias           24x7x365 full monitoring
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
        }
:x!

9. Fatores importantes.

9.1 Check de disponibilidade

Como é feito a checagem de disponibilidade de um ativo no Nagios? Através do ping. Mas para ser preciso, através do comando check-host-alive, que na verdade é apenas um nome, pois o real comando que o executa, é um plugin do nagios, o check_ping.
Apenas para título de curiosidade, eu peço a gentileza para conferir. Mas apenas olhar, NÃO MODIFIQUE!


No Red Hat, execute somente no Nagios Core (server):

# grep check-host-alive /etc/nagios/objects/commands.cfg -A 2
# 'check-host-alive' command definition
define command {
        command_name    check-host-alive
        command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 5
        }

Enquanto no Debian, apesar de existir o check-host-alive, ele não fica no arquivo commands.cfg. Ele é definido pelo pacote de plugins do nagios, ou seja, foi alterado para o arquivo

No Debian, execute somente no Nagios Core (server):

# grep heck-host-alive /etc/nagios3/commands.cfg -A 2
# On Debian, check-host-alive is being defined from within the
# nagios-plugins-basic package
grep check-host-alive /etc/nagios-plugins/config/ping.cfg -A 2
# 'check-host-alive' command definition
define command{
	command_name	check-host-alive
	command_line	/usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w 5000,100% -c 5000,100% -p 1
	}

9.2 Contatos e Notificações

Como o Nagios sabe para quem deve ser alertado em caso de indisponibilidade de um ativo ou de um serviço? Também é uma pergunta interessante.
O Nagios possui dois recursos chamados contact e contact_group, que nada mais é do que:

  • contato
  • grupo de contato

Portanto vamos criar nosso contato e nosso grupo de contato!


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/contacts.cfg
(...)
define contact{
        contact_name                    elvis             ; Nome do contato
        use                             template-contato         ; Template usado pelo contato (Iremos cria-lo logo abaixo)
        alias                           Elvis Suffi Pompeu            ; Apelido do Usuário
 
        email                           elvis.suffipompeu@meudominio.com.br        ; Endereço do destinatário
        }
 
define contactgroup{
        contactgroup_name       nagios-linuxsysadmin
        alias                   Grupo de contatos do Linux Sysadmin
        members                 elvis ; Caso queira adicionar novos contatos, apenas colocar vírgula, e adiciona-los ao lado direito. Como no exemplo de hosts.
        }
(...)
:x!

Enquanto no Debian, o contacts.cfg esta com outro nome, porém como vamos criar um novo contato, vamos criar um arquivo do zero, como abaixo.

No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/contacts.cfg
(...)
define contact{
        contact_name                    elvis             ; Nome do contato
        use                             template-contato         ; Template usado pelo contato (Iremos cria-lo logo abaixo)
        alias                           Elvis Suffi Pompeu            ; Apelido do Usuário
 
        email                           elvis.suffipompeu@meudominio.com.br        ; Endereço do destinatário
        }
 
define contactgroup{
        contactgroup_name       nagios-linuxsysadmin
        alias                   Grupo de contatos do Linux Sysadmin
        members                 elvis ; Caso queira adicionar novos contatos, apenas colocar vírgula, e adiciona-los ao lado. Como no exemplo de hosts.
        }
(...)
:x

Agora precisamos configurar novamente o templates, para criar um template de contatos, ou seja, um modelo a ser utilizados por um ou mais contatos.


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/objects/templates.cfg
(...)
define contact{
        name                            template-contato         ; Nome do template de contato
        service_notification_period     24x7x365                        ; Período de notificação para indisponibilidade de serviços
        host_notification_period        24x7x365                        ; Período de notificação para indisponibilidade de ativos
        service_notification_options    w,u,c,r,f,s             ; Envia notificações em todas as situações e estados em serviços
        host_notification_options       d,u,r,f,s               ; Envia notificações em todas as situações e estados em ativos
        service_notification_commands   notify-service-by-email ; Envia notificação de indisponibilidade de serviços via email
        host_notification_commands      notify-host-by-email    ; Envia notificação de indisponibilidade de ativos via email
        register                        0                       
        }
(...)
:x!
# service nagios restart

Enquanto no Debian, o contacts.cfg esta com outro nome, porém como vamos criar um novo contato, vamos criar um arquivo do zero, como abaixo.

No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/objects/templates.cfg
(...)
define contact{
        name                            template-contato         ; Nome do template de contato
        service_notification_period     24x7x365                        ; Período de notificação para indisponibilidade de serviços
        host_notification_period        24x7x365                        ; Período de notificação para indisponibilidade de ativos
        service_notification_options    w,u,c,r,f,s             ; Envia notificações em todas as situações e estados em serviços
        host_notification_options       d,u,r,f,s               ; Envia notificações em todas as situações e estados em ativos
        service_notification_commands   notify-service-by-email ; Envia notificação de indisponibilidade de serviços via email
        host_notification_commands      notify-host-by-email    ; Envia notificação de indisponibilidade de ativos via email
        register                        0                       
        }
(...)
:x!
# service nagios3 restart

A título de curiosidade é bom sabermos quem envia os e-mails no Nagios. Pois bem, esses carinhas que envia os e-mail sãos os seguintes “comandos”:

  • notify-host-by-email
  • notify-service-by-email

Que na verdade não são comandos propriamente ditos, mas sim apelidos para o Nagios saber quais ou qual comando executar a nível de sistema operacional. Basicamente esses carinhas usam o comando “mail” do próprio sistema operacional.

Lembrando que é apenas para título de curiosidade, eu peço a gentileza para NÃO (N-Ã-O) alterarem, mexerem, modificarem, etc.


No Red Hat, execute somente no Nagios Core (server):

# grep notify /etc/nagios/objects/commands.cfg -A2
# 'notify-host-by-email' command definition
define command{
	command_name	notify-host-by-email
	command_line	/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
	}
--
# 'notify-service-by-email' command definition
define command{
	command_name	notify-service-by-email
	command_line	/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
	}


No Debian, execute somente no Nagios Core (server):

# grep notify /etc/nagios3/commands.cfg -A2
# 'notify-host-by-email' command definition
define command{
	command_name	notify-host-by-email
	command_line	/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
	}
--
# 'notify-service-by-email' command definition
define command{
	command_name	notify-service-by-email
	command_line	/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
	}

10. Configurando o arquivo do ativo a ser monitorado (srvlab01)

10.1 Criando o “hosts.cfg”

Agora precisamos criar o arquivo de configuração do servidor srvlab01, a qual estamos querendo monitorar em nosso ambiente de laboratório. Para isso é preciso criar o arquivo de configuração contendo o nome do host, qual template esse host utilizará como referência, quais os serviços serão monitorados neste host, etc.


No Red Hat, execute somente no Nagios Core (server):

# vim /etc/nagios/servers/srvlab01.cfg
define host{
        use                     lab-template            ; Nome do template de host que criamos.
        host_name               srvlab01                ; Nome do nosso host (ativo).
        alias                   Servidor do Laboratório ; Descrição do nosso host.
        address                 10.100.0.52             ; Endereço IP do nosso host.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo).
        service_description             Monitoramento do PING           ; Descrição do nosso serviço.
        check_command                   check_ping!100.0,20%!500.0,60%  ; Este plugin usa o comando ping no host especificado para analisar a perda de pacotes (%) (porcentagem) e média em (milissegundos)
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo).
        service_description             Monitoramento da partição sda1  ; Descrição do nosso serviço.
        check_command                   check_nrpe!check_sda1           ; Este plugin checa o espaço livre na partição sda1
        }
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                         ; Nome do nosso host (ativo)
        service_description             Usuários on-line                ; Descrição do nosso serviço.
        check_command                   check_nrpe!check_users          ; Este plugin checa a quantidade de usuários on-line no servidor.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Total de processos              ; Descrição do nosso serviço
        check_command                   check_nrpe!check_total_proc     ; Este plugin checa a quantidade de processos no servidor.
        }
 
define service{
        use                             service-lablinuxsysadmin        ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento de Load Average do Servidor Linux ; Descrição do nosso serviço
        check_command                   check_nrpe!check_load           ; Este plugin checa a carga do servidor (load average)
        }
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento SSH               ; Descrição do nosso serviço
        check_command                   check_ssh                       ; Este plugin checa a disponibilidade do servidor SSH. Por padrão, porta 22.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento HTTP              ; Descrição do nosso serviç
        check_command                   check_http                      ; Este plugin checa a disponibilidade do servidor  HTTP. Por padrão, porta 80.
        }
:x!
# service nagios restart


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios3/servers/srvlab01.cfg
define host{
        use                     lab-template            ; Nome do template de host que criamos.
        host_name               srvlab01                ; Nome do nosso host (ativo).
        alias                   Servidor do Laboratório ; Descrição do nosso host.
        address                 10.100.0.52             ; Endereço IP do nosso host.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo).
        service_description             Monitoramento do PING           ; Descrição do nosso serviço.
        check_command                   check_ping!100.0,20%!500.0,60%  ; Este plugin usa o comando ping no host especificado para analisar a perda de pacotes (%) (porcentagem) e média em (milissegundos)
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo).
        service_description             Monitoramento da partição sda1  ; Descrição do nosso serviço.
        check_command                   check_nrpe_1arg!check_sda1           ; Este plugin checa o espaço livre na partição sda1
        }
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                         ; Nome do nosso host (ativo)
        service_description             Usuários on-line                ; Descrição do nosso serviço.
        check_command                   check_nrpe_1arg!check_users          ; Este plugin checa a quantidade de usuários on-line no servidor.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Total de processos              ; Descrição do nosso serviço
        check_command                   check_nrpe_1arg!check_total_proc     ; Este plugin checa a quantidade de processos no servidor.
        }
 
define service{
        use                             service-lablinuxsysadmin        ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento de Load Average do Servidor Linux ; Descrição do nosso serviço
        check_command                   check_nrpe_1arg!check_load           ; Este plugin checa a carga do servidor (load average)
        }
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento SSH               ; Descrição do nosso serviço
        check_command                   check_ssh                       ; Este plugin checa a disponibilidade do servidor SSH. Por padrão, porta 22.
        }
 
define service{
        use                             service-lablinuxsysadmin         ; Nome do template de serviços que criamos.
        host_name                       srvlab01                        ; Nome do nosso host (ativo)
        service_description             Monitoramento HTTP              ; Descrição do nosso serviç
        check_command                   check_http                      ; Este plugin checa a disponibilidade do servidor  HTTP. Por padrão, porta 80.
        }
:x!
# service nagios3 restart


Nota: É importante notar que no Debian, o check_nrpe, esta diferente, colocamos como check_nrpe_1arg. Mas por que fizemos isso? Porque o pacote nagios-plugins quando instalado ele não cria o comando check_nrpe no arquivo commands.cfg, que deveria ser o padrão, porém no próprio commands.cfg ele indica que o comando foi criado no seguinte arquivo:

/etc/nagios-plugins/config/check_nrpe.cfg

E dentro do arquivo existem dois commands que apontam para o plugin check_nrpe.


No Debian, execute somente no Nagios Core (server):

# vim /etc/nagios-plugins/config/check_nrpe.cfg
# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}
 
# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Nota-se que o check_nrpe_1arg não pede argumento, enquanto o check_nrpe pede argumentos. Essa é a única diferença entre as distribuições, mas que na verdade não implica o seu modo de uso. Procuro abordar essa diferença para que você não fique confuso, pois muitos administradores se prendem a uma única distribuição e ficam “perdidos” quando tem que implementar um ambiente desse tipo fora da sua “zona de conforto”.

10.2 Entendendo melhor o check_command

Para entendimento é necessário que saibamos que o check_command vai chamar os comandos que nada mais são do que os plugins do nagios, por exemplo:

O plugin check_http, ele tem a finalidade de identificar se o serviço HTTP (porta 80) esta disponível ou indisponível em um determinado host.

No caso do nrpe, por exemplo, instalamos o nrpe no servidor e no ativo que será monitorado, correto? Lá no servidor que será monitorado, existe o daemon (serviço) nrpe, a qual permite a execução de plugins remotos.

A sintaxe do NRPE é seguinte:

check_commaand check_nrpe!COMANDO_QUE_SERÀ_EXECUTADO_NO_HOST_MONITORADO!ARGUMENTO1!ARGUMENTO2

Ou seja o servidor nagios vai executar o NRPE no host que estamos monitorando e chamando o “COMANDO_QUE_SERÀ_EXECUTADO_NO_HOST_MONITORADO”, quanto ao ARGUMENTO1 e ARGUMENTO2 não SÃO OBRIGADOS, DESDE QUÊ os arquivos nrpe.cfg estejam já com os thresholds.

Mas o que são os Thresholds? São as condições que definem um alerta como crítico, aviso, etc. No caso do Nagios os Thresholds são chamados de “State types”, e são enquadrados em 4 tipos, sendo:

  • OK
  • WARNING
  • CRITICAL
  • UNKNOWN

No caso do exemplo, eu passei o valor dos Thresholds diretamente no define service que criamos para o nosso host neste laboratório, mas não é obrigatório, desde que o plugin já esteja com ele definido no arquivo commands.cfg ou no nrpe.cfg, no caso de monitoramentos via NRPE, como fizemos aqui no exemplo, para confirmar, veja o arquivo nrpe.cfg.

  • command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
  • command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
  • command[check_sda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
  • command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
  • command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200

NOTE: Que não precisamos informar argumentos no check_commands, porque os thresholds já estão definidos dentro do arquivo nrpe.cfg do host a qual pretendemos monitorar. Assim podemos omiti-los. O Nagios é bem intuito, veja que os parâmetros:

  • -w: Threshold para considerar o estado como WARNING
  • -c: Threshold para considerar o estado como CRITICAL

11. Visualizando o monitoramento do nosso host.

Bem, como preparamos já todo o ambiente, podemos aguardar alguns minutos e o Nagios já vai iniciar o monitoramento em nosso host. Acesse o seu nagios:


http://SEUSERVIDORNAGIOS/nagios


http://SEUSERVIDORNAGIOS/nagios3

Click em services no canto esquerdo superior.

E visualize o estado de monitoramento do nosso host.

12. Conclusões

Seja feliz e desfrute do seu Monitoramento!
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Espero que tenham gostado!
Grato pela atenção!

Instalação do Nagios: Fácil e prático!

Olá Pessoal,

Neste artigo pretendo explicar de forma bem simples e intuitiva a instalação do Nagios Core. Para quem não conhece o Nagios, é uma ferramenta de Monitoramento de Padrão Aberto (Open Source), possuindo dois modelos:

  • Nagios Core: Versão Free Software, disponível gratuitamente para toda comunidade.
  • Nagios XI: Versão Enterprise, forma paga.

O Nagios é até hoje uma das mais populares ferramentas de monitoramento já existentes, sendo considerada por muitos religiosamente como a melhor ferramenta de monitoramento open source. Há quem discorde deste ponto de vista (Quem vós digita esse texto, por exemplo). Entretanto não venho julgar a ferramenta, pois já a usei bastante, e tenho um respeito enorme pelo Nagios.

1. Instalando o Nagios Core

A instalação do Nagios Core pode ser feita diretamente dos repositórios oficiais das distribuição. Já que o Nagios não tem distribuído um repositório Oficial para a versão Core, até então, somente o Nagios XI.
O único porém de instalar o Nagios Core através do repositório oficial da distribuição é que provavelmente o mesmo não será a versão mais atualizada. No caso até a data de hoje 31 de Agosto de 2015, estava na versão 3.X, sendo que já existe disponível a versão 4.X, porém apenas o fonte para compilação.

No Red Hat/CentOS, é necessário a instalação do repositório EPEL, pois o repositório nativo não tem disponível os pacotes do nagios.


No Red Hat, execute:

CentOS/RHEL 6, 32 Bit:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
 
CentOS/RHEL 6, 64 Bit:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
 
CentOS/RHEL 5, 32 Bit:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
 
CentOS/RHEL 5, 64 Bit:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-releas5-4.noarch.rpm

Após a instalação do repositório, basta iniciar a instalação do Nagios Core.


No Red Hat, execute:

# yum install nagios
# chkconfig httpd on
# chkconfig nagios on
# htpasswd -c /etc/nagios/passwd nagiosadmin
New password: SenhaQueVocêQuiser
Re-type new password: SenhaQueVocêQuiser 
Adding password for user nagiosadmin
# service httpd restart

Enquanto no Debian os pacotes já tem disponíveis no repositório default.


No Debian, execute:

# apt-get install nagios3

No Debian, o dbconfig solicitara a senha e a confirmação da senha para acesso ao frontend do Nagios, coloque a senha que você desejar.


Confirme a senha de acesso ao Frontend do Nagios:

 

2. Acessando o Nagios

Realizado esses procedimentos. Abra seu navegador e acesse:


No Red Hat, acesse:
http://ENDEREÇOIPDOSEUSERVIDOR/nagios


No Debian, acesse:
http://ENDEREÇOIPDOSEUSERVIDOR/nagios3

Será solicitado o login e a senha que você definiu, o login é:

  • Login: nagiosadmin
  • Password: SenhaAqualVoceDefiniu

A cara do seu Nagios:

 

 3. Arquivos de configuração do Nagios


No Red Hat, o diretório /etc/nagios, diretório dos arquivos de configuração do Nagios Core:

# ls -l /etc/nagios/
total 84
-rw-rw-r-- 1 root root   11658 Ago 30  2013 cgi.cfg
drwxr-x--- 2 root nagios  4096 Ago 30  2013 conf.d
-rw-rw-r-- 1 root root   44532 Ago 27 11:43 nagios.cfg
-rw-r--r-- 1 root root    7990 Ago 27 13:14 nrpe.cfg
drwxr-x--- 2 root nagios  4096 Ago 27 13:10 objects
-rw-r----- 1 root apache    26 Ago 25 16:42 passwd
drwxr-x--- 2 root nagios  4096 Ago 26 14:55 private
drwxr-xr-x 2 root root    4096 Ago 27 13:12 servers


No Debian, o diretório /etc/nagios3, diretório dos arquivos de configuração do Nagios Core:

# ls -l /etc/nagios3/
total 88
-rw-r--r-- 1 root root    1986 Nov  1  2013 apache2.conf
-rw-r--r-- 1 root root   12479 Nov  1  2013 cgi.cfg
-rw-r--r-- 1 root root    2442 Ago 27 13:25 commands.cfg
drwxr-xr-x 2 root root    4096 Ago 27 14:00 conf.d
-rw-r--r-- 1 root root      50 Ago 26 15:02 htpasswd.users
-rw-r--r-- 1 root root   44251 Ago 27 13:44 nagios.cfg
drwxr-xr-x 2 root root    4096 Ago 27 14:14 objects
-rw-r----- 1 root nagios  1293 Nov  1  2013 resource.cfg
drwxr-xr-x 2 root root    4096 Ago 25 16:05 stylesheets


O principal arquivo de configuração do servidor de monitoramento, Nagios Core, é o arquivo nagios.cfg. Em breve aqui no blog nos aprofundaremos mais nas configurações do Nagios para que você possa iniciar o monitoramento dos seus ativos através dele e explore melhor a ferramenta.

Dica: Sempre que realizar alterações nas configurações do nagios, recomendo antes de reiniciar o serviço, realizar o debug para validar/verificar as configurações através do comando abaixo.


No Red Hat, execute:

# nagios -v /etc/nagios/nagios.cfg


No Debian, execute:

# nagios3 -v /etc/nagios3/nagios.cfg

Caso toda sua configuração esteja OK, é esperado que o resultado seja esse:

(...)
Total Warnings: 0
Total Errors:   0
(...)

 4. Serviço do Nagios

As únicas diferenças entre as duas distribuições referente as distribuições é a questão da versão, nas distribuições padrão Red Hat/CentOS é simplesmente nagios, enquanto no Debian/Ubuntu, e derivadas, o nome do serviço é nagios, no nosso caso, nagios3.


No Red Hat, execute:

# service nagios status


No Debian, execute:

# service nagios3 status

5. Conclusão

Neste capítulo pretende apenas explicar a instalação do Nagios Core de forma ágil e prática. Em breve aqui no blog vamos abordar a configuração e o monitoramento dos servidores (agentes), monitorando serviços, disco, carga de CPU, etc.
Bem, seja feliz e desfrute do seu Nagios!
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Grato pela atenção!

Monitorando com Zabbix: Instalação dos agentes, fácil e prático!

 

Olá pessoal,

Neste artigo irei abordar como instalar o agente do zabbix de modo fácil e prático, através dos repositórios oficiais, como explicado no artigo anterior onde ensinei como criar o servidor zabbix através dos repositórios. Se você não leu, recomendo a leitura sobre neste link

Caso você não conheça o repositório oficial do Zabbix:

  • http://repo.zabbix.com/

Mas antes de instalarmos os agentes do Zabbix precisa ser esclarecido o que são os agentes: No Zabbix é possível fazer 4 tipos de monitoramentos nativos, sendo eles:

  • Zabbix Agente: Monitoramento através do software cliente da própria Zabbix SIA.
  • SNMP: Monitoramento através do protocolo de Redes
  • JMX: Monitoramento através de suporte a aplicações Java
  • IPMI: Monitoramento através de recursos de Hardware disponível por N fabricantes.

Dentre os brevemente comentados acima, o agente zabbix é o mais simples de se monitorar, como no artigo anterior aprendemos a instalar o servidor, ou seja, a aplicação que ira de fato coletar os dados e armazena-los em sua base, o gestor do ambiente de monitoramento. Temos o agente zabbix, que é o cliente, instalado no host a qual será monitorado.

1. Instalando o repositório oficial

Bem, como você já entendeu o conceito e sua finalidade, vamos instalar o mesmo.


No Red Hat, execute:

# wget http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-release-2.4-1.el6.noarch.rpm
# rpm -ivh zabbix-release-2.4-1.el6.noarch.rpm

Caso sua versão do Red Hat/CentOS seja outra, basta acessar e procurar se existe o pacote zabbix-release-VERSÂO* disponível para a versão da sua distribuição em: http://repo.zabbix.com/zabbix/VERSÂO/rhel/


No Debian, execute:

# wget http://repo.zabbix.com/zabbix/2.4/debian/pool/main/z/zabbix-release/zabbix-release_2.4-1+wheezy_all.deb
# dpkg -i zabbix-release_2.4-1+wheezy_all.deb
# apt-get update

Caso sua versão do Debian seja outra, basta acessar e procurar se existe o pacote zabbix-release-VERSÂO* disponível para a versão da sua distribuição em: http://repo.zabbix.com/zabbix/VERSÂO/debian/pool/main/z/zabbix-release/

2. Instalando os agentes do Zabbix.

Após instalado o repositório, vamos iniciar a instalação do pacote zabbix-agent e um utilitário muito importante para troubleshootings, o zabbix-get.


No Red Hat, execute:

# yum install zabbix-agent zabbix-get
# chkconfig zabbix-agent on


No Debian, execute:

# apt-get install zabbix-agent zabbix-get

3. Configurando os agentes do Zabbix.

Após instalados, precisamos configurar o arquivo de configuração do agente, zabbix_agentd.conf, para que o server possa conversar com o host a qual sera monitorado pelo Zabbix Server.


No Red Hat, execute:

# vim /etc/zabbix/zabbix_agentd.conf
PidFile=/var/run/zabbix/zabbix_agentd.pid # Caminho completo do arquivo Pid (Process Identifier)
LogFile=/var/log/zabbix/zabbix_agentd.log # Caminho completo do arquivo de log (registros) do agente zabbix.
Hostname=srvbd01 # Nome do servidor monitorado
Server=10.100.0.39,127.0.0.1 # Endereço do servidor Zabbix, ou nome, por exemplo: zabbix.linuxsysadmin.com.br. Quanto ao endereço de loopback (127.0.0.1), será explicado mais adiante sob sua utilidade.
ServerActive=10.100.0.39 # Endereço do servidor Zabbix, ou nome, por exemplo: zabbix.linuxsysadmin.com.br (Este explicarei melhor sobre mais a frente aqui no blog)
:x!


No Debian, execute:

# vim /etc/zabbix/zabbix_agentd.conf
PidFile=/var/run/zabbix/zabbix_agentd.pid # Caminho completo do arquivo Pid (Process Identifier)
LogFile=/var/log/zabbix/zabbix_agentd.log # Caminho completo do arquivo de log (registros) do agente 
Hostname=srvbd01 # Nome servidor monitorado
Server=10.100.0.39,127.0.0.1 # Endereço do servidor Zabbix, ou nome, por exemplo: zabbix.linuxsysadmin.com.br. Quanto ao endereço de loopback (127.0.0.1), será explicado mais adiante sob sua utilidade.
ServerActive=10.100.0.39 # Endereço do servidor Zabbix, ou nome, por exemplo: zabbix.linuxsysadmin.com.br (Este explicarei melhor sobre mais a frente aqui no blog)
:x!

No Red Hat/CentOS, é necessário desabilitar o SELinux para que o mesmo não impeça o funcionamento do agente Zabbix. Caso você saiba construir contextos no SELinux, não é necessário desabilita-lo, basta criar contextos com regras para o funcionamento do Agente Zabbix.


No Red Hat, execute:

# vim /etc/selinux/config
SELINUX=disabled
:x!
# setenforce 0


Execute nas duas distribuições:

# service zabbix-agent restart

Caso sua distribuição seja Red Hat/CentOS 7 ou Debian 8, executa os procedimentos abaixo:


Execute nas duas distribuições:

# systemctl restart zabbix-agent.service

Após o restart do serviço para que o mesmo releia os arquivos de configuração, é necessário analisarmos o arquivo de log para verificar se o mesmo subiu normalmente. Além disso checar se os processos e as portas estão em escuta.


Execute nas duas distribuições:

# tail /var/log/zabbix/zabbix_agentd.log -f
  2909:20150824:172823.911 Starting Zabbix Agent [Firewall Filial SP]. Zabbix 2.2.6 (revision 48483).
  2909:20150824:172823.911 using configuration file: /etc/zabbix/zabbix_agentd.conf
  2914:20150824:172823.916 agent #3 started [listener #3]
  2915:20150824:172823.916 agent #4 started [active checks #1]
  2913:20150824:172823.916 agent #2 started [listener #2]
  2912:20150824:172823.917 agent #1 started [listener #1]
  2911:20150824:172823.918 agent #0 started [collector]
(...)
# ps -ef | grep zabbix_agentd
zabbix    2909     1  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd
zabbix    2911  2909  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd: collector [idle 1 sec]
zabbix    2912  2909  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]
zabbix    2913  2909  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]
zabbix    2914  2909  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]
zabbix    2915  2909  0 17:28 ?        00:00:00 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]
# netstat -ntlp | grep :10050
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               OUÇA       2909/zabbix_agentd
tcp6       0      0 :::10050                :::*                    OUÇA       2909/zabbix_agentd

4. Ajustes de segurança (Opcional e dependendo do ambiente)

Garantindo que o serviço do agente zabbix esta no ar e a porta 10050, porta padrão do Zabbix esta em escuta. Precisamos apenas ajustar o Firewall para aceitar e estabelecer conexões através da porta 10050 no servidor.


No Red Hat, execute:

# vim /etc/sysconfig/iptables
# Adicionar esta linha antes das regras de REJECT:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 10050 -j ACCEPT
:x!
# iptables-restore /etc/sysconfig/iptables

No Debian não vem Firewall configurado por padrão, caso o seu tenha firewall configurado, adicione a regra abaixo no seu script de Firewall para ficar definitivo.


No Debian, execute:

# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 10050 -j ACCEPT

5. Testando as configurações do agente Zabbix.

Agora precisamos testar se o agente já atende as solicitações vindo server.


Execute nas duas distribuições:

# zabbix_get -s 127.0.0.1 -k agent.ping
1
#

O resultado deste comando deve ser o número 1. Que indica “UP”. Agora que você executou, execute direto no servidor Zabbix.


Execute no Zabbix SERVER, troque o endereço abaixo, pelo o endereço do servidor MONITORADO:

# zabbix_get -s 10.100.0.200 -k agent.ping
1
#

O retorno do comando zabbix_get no seu Zabbix Server deve retornar 1 também.

Ok, mas e porque raios definimos no parâmetro Server do zabbix_agentd.conf dois endereços, tanto o endereço do servidor Zabbix quanto o endereço de loopback do próprio host monitorado? Simples, para Troubleshooting. Pois podem ocorrer situações em que você consegue retornar 1, quando o zabbix_get é emitido no próprio servidor, e quando executado no zabbix server, ele da Timeout. O mais provavel seja regras de Firewall, porém é necessário sempre analisar seu ambiente.

Exemplo comum: Imagine que seu zabbix server esteja alocado em uma VLAN, e algum host que você pretende monitorar se encontra em outra VLAN, você faz um teste com zabbix_get do zabbix server até o host agente, e da timeout, porém ao fazer de um host que esta na mesma VLAN que o host que você pretende monitorar, o zabbix_get funciona. Bingo! O problema pode ser rota ou existe uma regra em algum firewall de borda que esteja no caminho.

Outros recursos de troubleshooting úteis:

  • telnet
  • netstat
  • nmap

Conceito básico de troubleshooting:

  • Verificar o log para checar o que ele informa
  • Verificar se o processo permanece ativo
  • Verificar se a porta esta em escuta através do netstat
  • Realizar um telnet na porta do agente
  • Testar o ping a partir do zabbix até o host de destino
  • Varrer as portas abertas remotamente a partir do servidor zabbix ao host de destino.

Esse tipo de malícia é desenvolvido em cada administrador de sistema com o tempo, atarda, mas dificilmente falha. Porém o modelo de investigar esse tipo de incidente, tende ser o básico sempre na grande maioria dos ambientes. E o agente do zabbix não foge a regra.

6. Configurando o Host monitorado no Frontend do Zabbix.

Bem, agora nosso agente já esta configurado e funcional, precisamos adiciona-los ao nosso monitoramento. Para isso é necessário que abra seu navegador e acesse o PHP-Frontend do seu Zabbix Server:

  • http://SEUZABBIXSERVER/zabbix

Faça o login. Após a autenticação, clique em “Configuration” (Configurações) e depois Hosts.


Clique no canto direito superior, em “Create Host” (Criar Host). E preencha os dados do servidor que será monitorado. O mesmo que acabamos de instalar o agente.

 

 

Lembre-se de preencher conforme os dados, nome, endereço IP, etc. do SEU servidor monitorado.
Observação: Grupos, são grupos de hosts, todo host deve pertencer a pelo menos um grupo. Por razões de simplicidade, e para tornar mais didático possível, adicione dentro do grupo já existente, chamado Linux Servers.

Clique na aba Template, e selecione o template OS Linux.

 

Observação: Templates no que se refere a Zabbix são modelos de monitoramento, itens, chaves e thresholds já pré-configurados e para que seja utilizado em algum host, basta adicionar esse template no host. Facilitando a necessidade de configurar cada recurso manualmente em cada host.
Seguido todos esses passos, pode clicar em “add”, para adicionar o host ao monitoramento e aguardar alguns instantes para que o monitoramento se inicie. Basta verificar os 4 ícones que ficam no canto direito do host, sendo eles:

  • Agente do Zabbix
  • SNMP
  • JMX
  • IPMI

Como o nosso monitoramento foi através de agente, esse ícone deve ficar verde em caso de que o monitoramento esta sendo realizado com sucesso. Quando o ícone estiver vermelho, o host não esta sendo monitorado, seja porque o agente não esta ativo, por regras de firewall, etc. Geralmente o próprio ícone indica uma mensagem de erro posicionando o que impede o monitoramento.

 

7. Conclusão

Seja feliz e desfrute do seu Monitoramento!
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Grato pela atenção!

O que é Alta Disponibilidade?

O conceito de Alta Disponibilidade surgiu devido a grande demanda de serviços de TI integrados ao negócio, quanto mais o serviço ou aplicação for necessária ao negócio e sua indisponibilidade impactar diretamente nos lucros da empresa, maior será a necessidade de ampliar a disponibilidade dos servidores, aplicações, etc.

A Alta Disponibilidade possui dois modelos de arquiteturas popularmente usados, sendo um deles o modo passivo/ativo. Usado quando se tem dois servidores, sendo um dos nodes o mestre o outro nó o escravo, quando o nó mestre fica indisponível o nó escravo assume o novo papel de mestre, ele é promovido a mestre. Conforme a imagem abaixo.

Tecnicamente este modelo de arquitetura consiste basicamente de três endereços IPs, sendo os dois utilizados nos dois nodes do cluster e o endereço VIP (Virtual IP), o VIP é o endereço de rede que deve ser disponibilizado para os usuários finais, pois quando o mestre ficar indisponível o escravo vai assumir o endereço VIP.

Por exemplo, imagine que um Analista esteja trabalhando durante o horário comercial, das 9hs as 18hs, e o departamento dele atua 24×7, o Analista que estiver escalonado como plantonista, passa ser o escravo (slave), caso o analista do horário comercial (master) estiver indisponível, o escravo é promovido a master e atuar nos chamados as quais o Analista do horário comercial não poder atuar.

O outro método popularmente utilizado é o modelo ativo/ativo, também conhecido como Load Balancing , onde o cluster possui diversos nodes, formando o que é conhecido como “pool”, nesse cluster todos os nodes são mestres, no entanto a carga é balanceada entre todos os nodes. Entenda que node em termos de alta disponibilidade refere-se a servidores. E cada requisição é direcionada a um nó diferente afim de aliviar a carga e distribui-la para que sua aplicação ou serviço tenha ganho de desempenho e produtividade, a grande vantagem do balanceamento de carga é o escalonamento horizontal do seu cluster, quando a aplicação crescer e a arquitetura sofrer demanda, basta adicionar novos nodes no cluster. Conforme o modelo abaixo:

Tecnicamente no Load Balancing os usuários finais da aplicação e/ou serviço não enxergam os servidores que se encontram no “Backend”, os nodes do cluster, apenas o servidor que faz o balanceamento, também conhecido como Balancer (Balanceador) ou Diretor. Inclusive o balanceador é um dos SPOF (Single Point of Failure) dessa arquitetura de alta disponibilidade, o SPOF significa que esse é o único ponto de falha, ou seja, se o balancer ficar indisponível, toda a arquitetura se torna indisponível impactando diretamente o usuário final. Nesse tipo de circunstância é possível aplicar o modelo passivo/ativo no balanceador, assim caso o balanceador mestre ficar indisponível, o balanceador escravo é promovido a mestre e a arquitetura permanece disponível e sem perda significativa para o usuário final. Porém como eu afirmei acima, é UM dos SPOFs, mas não o único, se observarem bem a arquitetura, notarão que o Banco de Dados esta isolado em outro servidor, por tanto se este ficar indisponível, toda arquitetura também falha. Sendo assim é necessário também aplicar algum modelo de alta disponibilidade. Porém se tratando de alta disponibilidade em Banco de Dados, o assunto é bastante delicado, já que se trata de dados, então a indisponibilidade do mestre e a virada do nó escravo para mestre pode ocasionar em perdas transacionais, por exemplo, e em alguns SGBDRs (Sistema de Gerenciamento de Banco de Dados Relacionais) não é possível nativamente construir bancos de dados em modelos master-to-master, onde os dois aceitam escritas e são replicados entre os nodes do cluster, se tornando os dois nodes replicas fiéis um do outro. Normalmente em se tratando de banco de dados o escravo nada mais é do que uma replica com permissão apenas de leitura, não podendo ser escrito diretamente nele, e o chaveamento se torna manual, porém é importante deixar claro que isso não é uma regra, pode sim ter o chaveamento automático dependendo da tecnologia utilizada para intermediar essa situação ou mesmo se o SGBDR tem esse suporte nativo.

Exemplo do conceito de balanceamento, quando um Gerente de TI recebe muitos chamados, a primeira coisa que ele faz é distribuir esses chamados a todos os analistas que estiverem ociosos, a fim de distribuir a carga de trabalho, fazendo uma analogia, o Gerente de TI é o Balanceador, e os analistas são os Backend, são os membros do Cluster. Quando o Gestor de TI recebe uma maior demanda de trabalho ele necessita contratar mais mão de obra, em se tratando de uma arquitetura balanceada não se difere muito, novos membros podem ser adicionados ao cluster, construindo um escalonamento horizontal, tornando uma arquitetura mais ampla.

Estes modelos devem ser aplicados de acordo com determinadas circunstâncias que sempre devem ser avaliadas pelo Arquiteto de Soluções do projeto ou pelo Administrador de Sistemas (SysAdmin), prevendo os possíveis pontos únicos de falha e as formas de contornar a situação construindo um ambiente totalmente tolerante a falhas. Construir ambientes alto disponíveis hoje já é uma realidade e vista com bons olhos dentro das empresas de diversos segmentos ou setores de tecnologias, onde os profissionais com esses conhecimentos e capacidades técnicas para desenhar a solução e aplica-las são muito bem remunerados e considerado um enorme diferencial perante aos seus colegas.

Na categoria sobre Alta Disponibilidade veremos na prática como construir arquiteturas de Alta Disponibilidades eficiente através de soluções FOSS (Free & Open Source Solution), como Heartbeat, Pacemaker, Corosync, DRBD, lvs, RHCS (Red Hat Cluster Suite), etc.

Zabbix em Alta Disponibilidade com Heartbeat

Olá pessoal,

Neste artigo pretendo explicar como construir uma infraestrutura no Zabbix compatível com Alta Disponibilidade através do pacote Heartbeat.  No final do artigo teremos uma infraestrutura altamente capacitada a suportar a alta disponibilidade do nosso ambiente de monitoramento.

1. O Cenário

Para este cenário será necessário três servidores, sendo um o servidor de banco de dados e dois para o Zabbix. As configurações podem ser as mínimas possíveis por se tratar de um ambiente de laboratório:

  • srvdbzbx01: 1 Proc, 512MB de RAM e disco de 8GB
  • srvzbxnode01: 1 Proc, 512MB de RAM e disco de 8GB
  • srvzbxnode02: 1 Proc, 512MB de RAM e disco de 8GB

Outros fatores IMPORTANTES:

  • O endereço IP do VIP, deve estar disponível na rede.
  • O endereço IP VIP não deve ser configurado nas configurações de Rede.
  • Quem vai fazer as configurações de rede do endereço VIP é o heartbeat!
  • Recomendável haver duas interfaces de rede no mínimo, por exemplo:
  • eth1: LAN, ou seja, diretamente na rede.
  • eth0: Conectada diretamente ao outro nó com cabo Crossover.

Ficando como no modelo abaixo (Lembrando que não é obrigatório o uso de cabo Crossover, mas garante comunicação direta entre os dois nós do Cluster):


Levarei em consideração que o seu zabbix já esteja instalado e configurado, totalmente funcional e com a base de dados isolada em OUTRO servidor. Se você não viu o modo de instalação do servidor Zabbix, recomendo a leitura sobre em Instalação Zabbix Fácil e Prático.

A arquitetura desse laboratório será semelhante a estrutura desenhada a baixo:

Para esta solução usaremos o pacote heartbeat, hoje já obsoleto e descontinuado, substituído pelo pacote Pacemaker, no entanto o Heartbeat não deixa a desejar, atende bem os principais requisitos de Alta Disponibilidade, o que se enquadra eficiente para o tipo de arquitetura a qual pretendemos montar. Num futuro não muito distante podemos abordar aqui no site técnicas de alta disponibilidade baseadas no Pacemaker.

Como sempre a minha ideia é sempre construir artigos baseadas em multi-distribuição, ou seja, abordar as duas principais distribuições Linux no mercado, sendo elas RHEL (Red Hat Enterprise Linux) e Debian, por serem as mais utilizadas, no entanto distribuições como CentOS, Fedoras, Ubuntu, Mint, entre outras se enquadram nesse quesito por serem baseadas nessas respectivas distribuições comentadas acima.

2. Instalando o Heartbeat.

Primeiramente precisamos baixar os pacotes que serão necessário para nossa solução de HA (High Availability):

No CentOS (Red Hat) 6, executando nos servidores mestre e escravo:

1
2
3
4
5
# yum update
# wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -ivh epel-release-6-8.noarch.rpm
# yum install heartbeat
# chkconfig heartbeat on

No Red Hat/CentOS não tem disponível por default o pacote heartbeat, apenas no repositório EPEL (Extra Packages for Enterprise Linux).
O único pacote relacionado a HA por padrão no Red Hat (CentOS) é o pacote “piranha”, que é RHCS (Red Hat Cluster Suite).
Outro fator importante: No Red Hat/CentOS 7 não esta mais disponível o pacote heartbeat nos repositórios, conforme avisado acima, o pacote heartbeat esta descontinuado, por isso não é novidade esse comportamento das versões mais recentes das distribuições.


No Debian, executando nos servidores mestre e escravo:

1
2
# apt-get upgrade
# apt-get install heartbeat

3. Preparando o ambiente do Zabbix e o Apache para o Heartbeat

Após a instalação do pacote heartbeat, vamos precisar desabilitar o serviço do zabbix-server e o serviço do apache do boot, pois quem vai gerenciar o “start” dos serviços pertencentes ao cluster é o Heartbeat e não o Sistema Operacional.  Quanto ao upgrade, é para realizar atualização de pacotes desatualizados, afim de evitar conflitos ou dependências. Não confunda com o update, que apenas atualiza a base de repositórios no Debian.


No Red Hat, executando nos servidores mestre e escravo:

1
2
# chkconfig zabbix-server off
# chkconfig httpd off


No Debian, executando nos servidores mestre e escravo:

1
2
# update-rc.d -f zabbix-server remove
# update-rc.d -f apache2 remove

Após desabilitar os serviços da inicialização do boot. Precisamos copiar os arquivos de inicialização que se encontram dentro de /etc/init.d/ para dentro de /etc/ha.d/resource.d/.


No Red Hat, executando nos servidores mestre e escravo:

1
2
# cp /etc/init.d/httpd /etc/ha.d/resource.d/
# cp /etc/init.d/zabbix-server /etc/ha.d/resource.d/


No Debian, executando nos servidores mestre e escravo:

1
2
# cp /etc/init.d/apache2 /etc/ha.d/resource.d/
# cp /etc/init.d/zabbix-server /etc/ha.d/resource.d/

 

Para o heartbeat, todos os scripts que estiverem armazenados dentro de /etc/ha.d/resource.d/ são recursos. Recursos nada mais são do que utilitários de inicialização do heartbeat para executar um serviço após o chaveamento entre os nodes do cluster.

Precisamos alterar os nomes no /etc/hosts para fazer as referências dos nomes de cada nó do cluster que serão usados pelo heartbeat para identificar.


No Red Hat e Debian, somente no Mestre:

1
2
3
4
5
# vim /etc/hosts
127.0.0.1   localhost
127.0.0.1   srvzbxnode01.linuxsysadmin.com.br srvzbxnode01
IP_DO_SLAVE srvzbxnode02.linuxsysadmin.com.br srvzbxnode02
:x!


No Red Hat e Debian, somente no Escravo:

1
2
3
4
5
# vim /etc/hosts
127.0.0.1    localhost
127.0.0.1    srvzbxnode02.linuxsysadmin.com.br srvzbxnode02
IP_DO_MASTER srvzbxnode01.linuxsysadmin.com.br srvzbxnode01
:x!

4. Configurando os recursos do Heartbeat

Como já alterarmos os nomes dos nodes do cluster e também já adicionamos os scripts de inicialização no diretório de recursos do heartbeat (/etc/ha.d/resource.d/). Precisamos editar o arquivo chamado haresources, dentro de /etc/ha.d/. No entanto pode ser que este arquivinho não venha por padrão em algumas distribuições, entretanto, isso é normal, cria-lo do zero é muito simples.


No Red Hat, somente no Mestre:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode01    IPaddr::192.168.100.15/24/eth0 zabbix-server httpd
:x!


No Debian, somente no Mestre:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode01    IPaddr::192.168.100.15/24/eth0 zabbix-server apache2
:x!


No Red Hat, somente no Escravo:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode02    IPaddr::192.168.100.15/24/eth0 zabbix-server httpd
:x!


No Debian, somente no Escravo:

1
2
3
# vim /etc/ha.d/haresources
srvzbxnode02    IPaddr::192.168.100.15/24/eth0 zabbix-server apache2
:x!

5. Ajustando o arquivo de configuração do Heartbeat

Após informarmos o nó do cluster e o recursos que devem ser usados durante o chaveamento. Precisamos configurar o arquivo ha.cf, existente dentro de /etc/ha.d/, este “carinha” é o principal arquivo de configuração do heartbeat.


No Red Hat, no Mestre e Escravo:

# vim /etc/ha.d/ha.cf
logfile	/var/log/ha-log # Log do heartbeat.
logfacility local0 # Facility que o log vai trabalhar no padrão syslog.
keepalive 2 # Tempo em segundos de verificação dos nodes.
deadtime 30 # Tempo mínimo para determinar que o nó esta indisponível.
bcast eth0 
auto_failback off # Quando ativado (on) o cluster retorna ao nó primário (mestre).
node srvzbxnode01 # São os nodes do cluster.
node srvzbxnode02 # São os nodes do cluster.
compression bz2 # Compressão de dados
compression_threshold 2
:x!


No Debian, no Mestre e Escravo:

# vim /etc/ha.d/ha.cf
logfile	/var/log/ha-log # Log do heartbeat.
logfacility local0 # Facility que o log vai trabalhar no padrão syslog.
keepalive 2 # Tempo em segundos de verificação dos nodes.
deadtime 30 # Tempo mínimo para determinar que o nó esta indisponível.
bcast eth0
auto_failback off # Quando ativado (on) o cluster retorna ao nó primário (mestre).
node srvzbxnode01 # São os nodes do cluster.
node srvzbxnode02 # São os nodes do cluster.
compression bz2 # Compressão de dados
compression_threshold 2
:x!

6. Configurando as chaves de autenticação do Cluster

Após esta etapa é necessário configurar as chaves de autenticação usadas pelo Heartbeat. Usadas para confirmar que o hosts a qual esta tentando conversar é um membro (node) oficial do cluster.


No Red Hat e Debian, no Mestre e Escravo:

1
2
3
4
5
# vim /etc/ha.d/authkeys
auth 3
3 md5 FraseUsadaComoPalavraPasseNoClusterCriptografadaEmAlgoritmoMD5
:x!
# chmod 600 /etc/ha.d/authkeys

 

Essa frase usada no /etc/ha.d/authkeys deve ser a MESMA usada nos dois nodes do cluster, ou seja, no mestre e no escravo.

Após a criação da chave de autenticação, precisamos reiniciar o serviço do heartbeat para efetuar todas as alterações realizadas nas configuração do heartbeat.
Mas antes é necessário garantir que os serviços do apache e do zabbix estejam parados em ambos os servidores. Pois assim podemos fazer o teste com maior precisão.


No Red Hat e Debian, primeiramente no Mestre e após alguns segundos execute o mesmo no Escravo:

1
# /etc/init.d/heartbeat restart

7. Preparando o Zabbix para o ambiente de Alta Disponibilidade (HA)

Antes de testarmos a alta disponibilidade do Heartbeat, precisamos garantir que o Zabbix esta configurado corretamente.


No Red Hat e Debian:

1
2
3
4
5
6
# grep ^DB /etc/zabbix/zabbix_server.conf
# Caso o seu servidor de banco seja em Alta Disponibilidade, é necessário informar o endereço VIP.
DBHost=srvdbzbx01
DBName=zabbixdb
DBUser=zbxuser
DBPassword=SenhaDozbxuser

Verificado que as configurações estão corretas. E após reiniciar o serviço do heartbeat. Execute somente no servidor mestre o comando abaixo, para confirmar que o endereço VIP foi ativado:


No Red Hat e Debian, somente no MESTRE:

1
2
3
4
5
6
7
# ip a show eth1
2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:62:52:7b brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.52/8 brd 10.255.255.255 scope global eth0
    inet VIP/8 brd 10.255.255.255 scope global secondary eth0
    inet6 fe80::a00:27ff:fe62:527b/64 scope link 
       valid_lft forever preferred_lft forever

A linha “inet VIP/8 brd 10.255.255.255 scope global secondary eth0” corresponde a configuração IP do endereço VIP. Que no caso eu omite apenas para ficar didático.

Em seguida, abra o navegador e acesse o endereço IP do seu VIP, para acessar o Frontend do Zabbix.

7. Testando o chaveamento do Cluster

Agora para chavear para o nó escravo, abra os terminais dos dois servidores, no mestre para o serviço do heartbeat:


No Red Hat e Debian, desligue somente o MESTRE:

1
# shutdown -h now

No nó escravo, observe o log se aparece informações semelhantes a essas:

No Red Hat e Debian, somente no ESCRAVO:

1
2
3
4
5
6
7
8
# tail -f /var/log/ha-log
(...)
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/IPaddr 192.168.100.15/24/eth0 start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/httpd  start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/zabbix-server  start
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: WARN: node srvzbxnode01: is dead
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Cancelling pending standby operation
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Dead node srvzbxnode01 gave up resources.

Ou


No Red Hat e Debian, somente no ESCRAVO:

1
2
3
4
5
6
7
8
# tail -f /var/log/ha-log
(...)
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/IPaddr 192.168.100.15/24/eth0 start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/apache2  start
ResourceManager(default)[3813]:	2015/08/12_13:31:41 info: Running /etc/ha.d/resource.d/zabbix-server  start
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: WARN: node srvzbxnode01: is dead
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Cancelling pending standby operation
Aug 12 13:32:35 srvzbxnode02 heartbeat: [7802]: info: Dead node srvzbxnode01 gave up resources.

Aguarde alguns instantes, abra novamente o navegador e acesse o endereço IP do seu VIP, para acessar o Frontend do Zabbix, agora disponível através do segundo nó do cluster.

8. Melhorando o nível de Alta Disponibilidade

Observação importante: O heartbeat gerencia apenas a nível da indisponibilidade do host, ou seja, se houver a parada apenas do serviço zabbix-server ou do apache, o cluster permanece no mesmo nó, para o heartbeat essa parada é irrelevante. No entanto sua alta disponibilidade já esta pronta, porém não adequada aos melhores padrões.

8.1 Instalando o pacote mon

Para essa finalidade de contornar essa fragilidade do Heartbeat, vamos instalar um pacote chamado mon, que será o responsável por monitorar os serviços do sistema e caso tenha parada dos serviços, como apache (httpd) ou zabbix_server, o mon vai parar o heartbeat, fazendo com que o escravo seja promovido a mestre.

Instale o pacote mon:

Execute no Red Hat, tanto no mestre quanto no escravo:

1
# yum install mon

Execute no Debian, tanto no mestre quanto no escravo:

1
# apt-get install mon

Após a instalação é necessário a instalação do pacote sudo, caso o seu SO esteja sem o sudo instalado, instale o mesmo através dos comandos abaixo:

Execute somente no Debian, tanto no mestre quanto no escravo:

1
# apt-get install sudo

Após a instalação do sudo, é necessário ajustarmos o arquivo de configuração do mon, o mon.cf:

8.2 Configurando o mon

 

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /etc/mon/mon.cf
# Se o seu centos não for 64, deixe como /usr/lib/mon/alert.d
alertdir                = /usr/lib64/mon/alert.d
# Se o seu centos não for 64, deixe como /usr/lib/mon/mon.d
mondir                  = /usr/lib64/mon/mon.d
maxprocs                = 20
histlength              = 100
randstart               = 60s
dtlogging               = yes
dtlogfile               = dtlog
 
hostgroup localhost
localhost
 
watch localhost
        service http
                description HTTP service
                interval 1m
                monitor http.monitor -p 80 -t 10 -o localhost
                period  wd {Mon-Mon}
                        alert heartbeat.alert
        service zabbix
                description Zabbix Server service
                interval 1m
                monitor zabbix.monitor zabbix_server 10051
                period  wd {Mon-Mon}
                        alert heartbeat.alert
:x!

Execute no Debian, tanto no mestre quanto no escravo:

# vim /etc/mon/mon.cf
alertdir		= /usr/lib/mon/alert.d
mondir			= /usr/lib/mon/mon.d
maxprocs		= 20
histlength		= 100
randstart		= 60s
dtlogging		= yes
dtlogfile		= dtlog
 
hostgroup localhost
localhost
 
watch localhost
	service http
		description HTTP service
		interval 1m
		monitor http.monitor -p 80 -t 10 -o localhost
		period  wd {Mon-Mon}
			alert heartbeat.alert
	service zabbix
		description Zabbix Server service
		interval 1m
		monitor zabbix.monitor zabbix_server 10051
		period  wd {Mon-Mon}
			alert heartbeat.alert
:x!

8.3 Entendendo o conceito do mon

Conceitos Básicos sobre o Mon
O mon tem a finalidade de monitorar serviços, protocolo entre outros recursos através de rotinas em intervalos definidos pelo administrador da ferramenta. E também tomar ações, como enviar e-mail, reiniciar o serviço, alertar o administrador do sistema, e etc. quando o determinado serviço ou protocolo estiver indisponível. O mon possui fácil integração com diversas ferramentas, principalmente com o Heartbeat, pacote que estamos utilizando neste material.

O mon possui dois diretórios que se encontram dentro de /urs/lib[64]/mon, que são fundamentais:

  • /usr/lib/mon/mon.d/ – Diretório que contém os scripts que fazem a rotina de verificação de disponibilidade do serviço monitorado.
  • /usr/lib/mon/alert.d – Diretório responsável pelos scripts de alerta, caso o monitoramento aponte a indisponibilidade de um determinado serviço.

A sintaxe básico do principal arquivo de configuração do mon, mon.cf:
Define o grupo de hosts, pois todo host monitorado, deve pertencer ao um grupo, em baixo é definido que o grupo localhost possui um host, chamado localhost. (Nada mais que o próprio loopback)

hostgroup localhost
localhost

O watch é onde iniciado o bloco de serviços as quais serão monitorados pelo respectivo host, no caso localhost, definido no grupo acima.

watch localhost

O parâmetro service, é simbólico, nada verdade ele é só a referência para um serviço, para melhor organizar o arquivo.

service zabbix
		description Zabbix Server service # Descrição sobre o serviço monitorado
		interval 1m # Intervalo de monitoramento
		monitor zabbix.monitor zabbix_server 10051 # Script de monitoramento e os parâmetros passados.
		period  wd {Mon-Mon} # Período na semana que será feito o alerta.
			alert heartbeat.alert # Script de alerta, acionado em caso de indisponibilidade do serviço

8.4 Criando o script de monitoramento.

Voltando, após o entendimento básico sobre o mon e o ajuste correto no arquivo de configuração, precisamos configurar o restante, crie o arquivo zabbix.monitor dentro de /usr/lib/mon/mon.d. A finalidade desse script é monitorar se o serviço zabbix_server esta ativo no host.

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /usr/lib64/mon/mon.d/zabbix.monitor
ou
# vim /usr/lib/mon/mon.d/zabbix.monitor
#!/bin/bash
# zabbix.monitor é um script desenvolvido para o uso do Zabbix em HA com Heartbeat e o pacote mon.
# Autor: Elvis Suffi Pompeu &lt;elvis.suffipompeu@hotmail.com&gt;
# Seg Ago 24 10:35:44 BRT 2015
COUNT_SERVICE="$(/bin/ps -ef | /bin/grep ${1} | /bin/grep -v grep | /usr/bin/wc -l)"
COUNT_PORT="$(/bin/netstat -ntl | /bin/grep "${2}" | /bin/grep -v grep | /usr/bin/wc -l)"
 
if [ ${COUNT_SERVICE} -eq 0 ]; then
 
        # Serviço DOWN
        exit 1
 
elif [ ${COUNT_PORT} -eq 0 ]; then
 
        # Serviço DOWN
        exit 2
 
else
 
        # Serviço UP (OK)
        exit 0
 
fi
:x!
# chmod +x /usr/lib64/mon/mon.d/zabbix.monitor 
ou
# chmod +x /usr/lib/mon/mon.d/zabbix.monitor

Execute no Debian, tanto no mestre quanto no escravo:

# vim /usr/lib/mon/mon.d/zabbix.monitor
#!/bin/bash
# zabbix.monitor é um script desenvolvido para o uso do Zabbix em HA com Heartbeat e o pacote mon.
# Autor: Elvis Suffi Pompeu &lt;elvis.suffipompeu@hotmail.com&gt;
# Seg Ago 24 10:35:44 BRT 2015
COUNT_SERVICE="$(/bin/ps -ef | /bin/grep ${1} | /bin/grep -v grep | /usr/bin/wc -l)"
COUNT_PORT="$(/bin/netstat -ntl | /bin/grep "${2}" | /bin/grep -v grep | /usr/bin/wc -l)"
 
if [ ${COUNT_SERVICE} -eq 0 ]; then
 
        # Serviço DOWN
        exit 1
 
elif [ ${COUNT_PORT} -eq 0 ]; then
 
        # Serviço DOWN
        exit 2
 
else
 
        # Serviço UP (OK)
        exit 0
 
fi
:x!
# chmod +x /usr/lib/mon/mon.d/zabbix.monitor

8.5 Criando o script de Alerta.

Agora precisamos configurar o script de alerta, que no caso sera acionado quando for detectado a indisponibilidade dos serviços, o mesmo tem a função de “parar” o heartbeat, já que com a indisponibilidade do heartbeat, é feito o chaveamento para o segundo nó do cluster.

Execute no Red Hat, tanto no mestre quanto no escravo:

# vim /usr/lib64/mon/alert.d/heartbeat.alert 
ou
# vim /usr/lib/mon/alert.d/heartbeat.alert 
#!/usr/bin/perl
#
# Shutdown heartbeat
# derived from Jim Trocki's alert.template
#
# Jim Trocki, trockij@transmeta.com
# Sandro Poppi, spoppi@gmx.de
#
#    Copyright (C) 1998, Jim Trocki
#                  2001, Sandro Poppi
#
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
use Getopt::Std;
getopts ("s:g:h:t:l:u");
# the first line is summary information, adequate to send to a pager
# or email subject line
#
#
# the following lines normally contain more detailed information,
# but this is monitor-dependent
#
# see the "Alert Programs" section in mon(1) for an explanation
# of the options that are passed to the monitor script.
#
$summary=;
chomp $summary;
 
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
 
print &lt;&lt;EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print &lt;&lt;EOF;
This happened on $wday $mon $day $tm
Summary information: $summary
Arguments passed to this script: @ARGV
Detailed information follows:
 
EOF
 
# shutdown heartbeat
system ("/etc/init.d/heartbeat stop");
:x!
# chmod +x /usr/lib64/mon/alert.d/heartbeat.alert
ou
# chmod +x /usr/lib/mon/alert.d/heartbeat.alert

Execute no Debian, tanto no mestre quanto no escravo:

# vim /usr/lib/mon/alert.d/heartbeat.alert 
#!/usr/bin/perl
#
# Shutdown heartbeat
# derived from Jim Trocki's alert.template
#
# Jim Trocki, trockij@transmeta.com
# Sandro Poppi, spoppi@gmx.de
#
#    Copyright (C) 1998, Jim Trocki
#                  2001, Sandro Poppi
#
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
use Getopt::Std;
getopts ("s:g:h:t:l:u");
# the first line is summary information, adequate to send to a pager
# or email subject line
#
#
# the following lines normally contain more detailed information,
# but this is monitor-dependent
#
# see the "Alert Programs" section in mon(1) for an explanation
# of the options that are passed to the monitor script.
#
$summary=;
chomp $summary;
 
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
 
print &lt;&lt;EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print &lt;&lt;EOF;
This happened on $wday $mon $day $tm
Summary information: $summary
Arguments passed to this script: @ARGV
Detailed information follows:
 
EOF
 
# shutdown heartbeat
system ("sudo /etc/init.d/heartbeat stop");
:x!
# chmod +x /usr/lib/mon/alert.d/heartbeat.alert
# chown mon. /usr/lib/mon/alert.d/heartbeat.alert

Somente no Debian havíamos instalado o sudo, porque no Red Hat/CentOS o mon roda com o usuário root, e não sob o usuário do seu daemon (serviço).
Já no Debian o mon, roda sob o usuário mon, por isso precisamos do sudo para criar as regras liberando o usuário mon de executar o stop (parada) do heartbeat, já que quem gerencia e tem permissão, é somente o root.

Execute somente no Debian, tanto no mestre quanto no escravo, adicione somente essa linha abaixo:

1
2
3
# vim /etc/sudoers
mon     ALL=NOPASSWD:/etc/init.d/heartbeat stop
:x!

8.6 Testando as configurações do mon

 

Execute no Red Hat, tanto no mestre quanto no escravo:

# service mon restart
Desligando System Monitoring daemon (mon):                 [  OK  ]
Iniciando System Monitoring daemon (mon):                  [  OK  ]
# monshow
 
       server: localhost
       time: Mon Aug 24 14:59:58 2015
       state: scheduler running
 
All systems OK

Execute no Debian, tanto no mestre quanto no escravo:

# service mon restart
[ ok ] Restarting mon daemon: mon.
# monshow
 
      server: localhost
      time: Mon Aug 24 14:59:59 2015
      state: scheduler running
 
  GROUP           SERVICE      STATUS      LAST       NEXT       ALERTS SUMMARY
R localhost       http         -           30s        30s        none
R localhost       zabbix       -           46s        14s        none
 
Nothing is disabled
:x!

Agora vamos testar, a parada dos serviços para melhor compreensão sobre o serviço mon.

Execute em ambas as distribuições os seguinte comandos, para pararmos o serviço do zabbix e verificar se o mon detectou sua parada e acionou o alerta:

1
2
3
4
5
6
7
8
 # /etc/ha.d/resource.d/zabbix-server stop
# watch -n1 monshow
(...) # Aguarde alguns instantes, até aparecer algo como a mensagem abaixo:
R localhost	  zabbix       FAIL        47s        13s        5	(NO SUMMARY)
ou
  GROUP           SERVICE      STATUS      LAST       NEXT       ALERTS SUMMARY
R localhost       http         -           51s        8s         1      localhost
R localhost       zabbix       FAIL        7s         52s        7      (NO SUMMARY)

Para realizar o teste de forma eficaz:

Execute no Red Hat, tanto no mestre quanto no escravo:

# /usr/lib64/mon/mon.d/zabbix.monitor zabbix_server 10051; echo $?
0
# ps -ef | grep heartbeat
root      1361     1 86 12:19 ?        02:32:06 heartbeat: master control process
root      1373  1361  0 12:19 ?        00:00:00 heartbeat: FIFO reader        
root      1374  1361  0 12:19 ?        00:00:14 heartbeat: write: bcast eth0  
root      1375  1361  0 12:19 ?        00:00:08 heartbeat: read: bcast eth0
(...)
# /usr/lib64/mon/alert.d/heartbeat.alert
# ps -ef | grep heartbeat
root      6104  3958  0 15:14 pts/0    00:00:00 grep heartbeat

Execute no Debian, tanto no mestre quanto no escravo:

# /usr/lib64/mon/mon.d/zabbix.monitor zabbix_server 10051; echo $?
0
# ps -ef | grep heartbeat
root      1361     1 86 12:19 ?        02:32:06 heartbeat: master control process
root      1373  1361  0 12:19 ?        00:00:00 heartbeat: FIFO reader        
root      1374  1361  0 12:19 ?        00:00:14 heartbeat: write: bcast eth0  
root      1375  1361  0 12:19 ?        00:00:08 heartbeat: read: bcast eth0
(...)
# chsh -s /bin/bash mon
# su - mon
$ sudo /usr/lib64/mon/alert.d/heartbeat.alert
$ exit
# ps -ef | grep heartbeat
root      6104  3958  0 15:14 pts/0    00:00:00 grep heartbeat

Se tudo ocorreu nos conformes, sua alta disponibilidade no Zabbix já esta funcional. Agora faça os testes parando esses serviços e verifique se o chaveamento do Heartbeat esta sendo promovido com a parada deles, conforme definido para a responsabilidade do mon gerenciar.

9. Conclusão

Bem espero de coração que este “how to” lhe seja útil. Forte abraço e sucesso! 🙂
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Grato pela atenção!

O que é Monitoramento de Redes?

Monitoramento de redes é o conceito de observar a saúde de sua rede, monitorar suas aplicações e seus serviços. É o conceito de monitorar ativos de rede como Servidores ou Dispositivos de rede como roteadores, o monitoramento hoje é de suma importância para a saúde e qualidade dos serviços em sua rede. Conforme a evolução tecnológica a necessidade de melhorar o desempenho de redes, servidores, aplicações entre muitos outros, foi se tornando uma necessidade cada vez maior e necessário para ambientes de TI de missão crítica.

Assim surgiu uma nova função na TI, o Network Operation Center (NOC), o NOC não é só responsável por monitorar o ambiente de Data Center e TI, como também pode atuar em algumas circunstâncias para que não seja necessário escalonar aos responsáveis pelas respectivas tecnologias. O papel do NOC é tão importante hoje na TI que em muitas vezes este departamento atua em escala 24x7x365, ou seja, ele nunca para!

Esse monitoramento é feito através de diversas ferramentas voltadas para esta finalidade como: Zabbix, Nagios, Cacti, entre outras. Essas ferramentas foram desenhadas para suportar o monitoramento com grandes volumes de dados em ambientes em larga escala, alguns até possuem recursos de monitoramento distribuído, permitindo monitorar redes remotas através de um concentrador de dados que encaminha a ferramenta de monitoramento principal.

Através dessa ferramenta é possível monitorar uma gama de tecnologias suportadas por diversos protocolos, podendo ser através dos clientes dessas ferramentes, também conhecidos como agentes, as quais geralmente trabalham sob o protocolo TCP/IP.

Para monitoramento de ativos de rede como Roteadores, Switchs, impressoras, no-breaks e até mesmo Storages, é popularmente usado o protocolo SNMP (Simple Network Management Protocolo), a qual é possível realizar consultas nos dispositivos e obter os valores para o monitoramento, esse protocolo tem suas particularidades de acordo com os fabricantes dos dispositivos a quais constroem as MIBs (Management Information Base) proprietárias, que são as tabelas de objetos, as quais as consultas SNMP são baseadas nesses objetos, as consultas são feitas através dos OIDs (Object Identifier), que são identificadores únicos de cada objeto, cada OID possui um valor que é retornado através da consulta SNMP, no entanto essas consultas só podem ser feitas através de uma pequena restrição de segurança, que são denominadas como “comunidades”, são semelhantes as senhas, assim os hosts que podem realizar as consultas SNMP devem informar a comunidade autorizada a receber os valores.

Quando o monitoramento é a nível de aplicações Java, ele não é monitorado através de um protocolo mas sim através de uma API do Java, conhecida como JMX (Java Management Extensions), a JMX permite consultar valores respectivos a desempenho a nível da aplicação ou a nível da JVM (Java Virtual Machine), como Garbage Collector, o consumo de memória da JVM, entre outros.

Bem como o monitoramento a nível mais profundo de hardware, é feito através do IPMI (Intelligent Platform Management Interface). O IPMI é uma especificação desenvolvidas pelos principais fabricantes de Hardware a qual gerenciam uma interface de consultas dos hardware dos seus respectivos produtos.

A função do monitoramento é realizar o acompanhamento da disponibilidade de um serviço ou uma aplicação, afim de alertar as áreas interessadas. Tornando as compatíveis com as normas das boas práticas da ITIL. Além dos alertas o monitoramento propõe a facilidade de centralizar os dados coletados do ativo monitorado, transformando aqueles dados em gráficos objetivos para que o administrador do sistema ou da rede possa acompanhar o desempenho da sua aplicação, do seu link de internet ou mesmo do seu servidor.

Graças o conceito de monitoramento de redes ter se difundido entre as grandes corporações e as empresas de tecnologia, o NOC tem melhorado a qualidade de vida de outros departamentos como Infraestrutura, Suporte e Projetos, assim os gestores podem direcionar seus outros profissionais para outras finalidades, já que o NOC pode atuar em algumas circunstância que tomariam tempos de seus subordinados tendo que parar os projetos internos, a evolução do seu ambiente, entre outras coisas. O ganho de se ter um NOC é perceptível quando seu ambiente é crítico e necessita de disponibilidade máxima.

Na categoria sobre NOC abordaremos na prática sobre algumas tecnologias FOSS (Free & Open Source Solutions) voltadas a monitoramento de redes como Zabbix, Nagios e Cacti, explicando sobre sua instalação, boas práticas de monitoramento e as dificuldades mais claras entre os usuários dessas ferramentas.

Instalação do Zabbix: Fácil e prático!

Olá Pessoal,

Antes de continuar com a leitura, recomendo ler sobre o que é Monitoramento de Redes. Nesta postagem pretendo explicar a instalação do Zabbix de forma bastante simples. Como? Através do seu repositório oficial:

  • http://repo.zabbix.com/

Para quem não conhece essa ferramenta, o Zabbix é um sistema de monitoramento FOSS (Free & Open Source Solutions) programada em C com uma interface web gerenciável escrita em PHP e suporta diversos bancos de dados. Nativamente o zabbix suporta o monitoramento através de agentes, suporte a protocolo de rede SNMP versão 1, 2 e 3, IPMI e JMX para aplicações Java. Caso queira conhecer mais sobre a ferramenta, segue o link oficial: http://www.zabbix.com/


No repositório oficial do zabbix esta disponível as versões abaixo para as principais distribuições de mercado, como Red Hat, Debian e Ubuntu:

  • 1.8
  • 2.0
  • 2.2
  • 2.4

O método de preparação do repositório pode ser feito da forma manual como já todos conhecem, editando os arquivos de repositório das principais distribuições, como:

  • Debian e Ubuntu: /etc/apt/sources.list.d/*.list
  • Red Hat e CentOS, Fedora: /etc/yum.repos.d/*.repo

Quais as vantagens de se instalar o Zabbix através do repositório oficial? Das mais diversas, por exemplo:

  • Fácil instalação
  • Instalação de dependências automaticamente
  • Fácil atualização (Quando necessário)
  • Homologado para as principais distribuições
  • etc.

Como sempre a minha ideia é sempre construir artigos baseadas em multi-distribuição, ou seja, abordar as duas principais distribuições Linux no mercado, sendo elas RHEL (Red Hat Enterprise Linux) e Debian, por serem as mais utilizadas, no entanto distribuições como CentOS, Fedoras, Ubuntu, Mint, entre outras se enquadram nesse quesito por serem baseadas nessas respectivas distribuições comentadas acima.

1. Instalação do repositório oficial

A partir deste ponto vou explicar a instalação e configuração nas duas principais distribuições (Red Hat e Debian), no entanto o Debian se aplica também ao Ubuntu, visto que o Ubuntu é uma distribuição Debian-like.


No Red Hat:

1
# wget http://repo.zabbix.com/zabbix/2.4/rhel/6/i386/zabbix-release-2.4-1.el6.noarch.rpm


No Debian:

1
# wget http://repo.zabbix.com/zabbix/2.4/debian/pool/main/z/zabbix-release/zabbix-release_2.4-1+wheezy_all.deb

Após efetuado o download é necessário instalar os pacotes abaixados:


No Red Hat:

1
# rpm -ivh zabbix-release-2.4-1.el6.noarch.rpm


No Debian:

1
# dpkg -i zabbix-release_2.4-1+wheezy_all.deb

Nas distribuições baseadas em Debian é necessário que seja feita a atualização da base de repositórios, para que o gerenciador de pacotes (apt) possa a enxergar o repositório do zabbix.


Somente no Debian:

1
# apt-get update

Após a instalação dos pacotes para preparar o uso do repositório oficial, procure pelos pacotes para validar se os mesmos estão já disponíveis.


No Red Hat:

1
# yum search zabbix


No Debian:

1
# apt-cache search zabbix

ou

1
# aptitude search zabbix

O que esses pacotes fizeram foram nada mais nada menos do que configurar o repositório para vocês. Por exemplo:


No Red Hat, após a instalação vai constar o seguinte arquivo:

# vim /etc/yum.repos.d/zabbix.repo
[zabbix]
name=Zabbix Official Repository - $basearch
baseurl=http://repo.zabbix.com/zabbix/2.4/rhel/6/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX 
[zabbix-non-supported]
name=Zabbix Official Repository non-supported - $basearch
baseurl=http://repo.zabbix.com/non-supported/rhel/6/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX
gpgcheck=1


E no Debian:

1
2
3
# vim /etc/apt/sources.list.d/zabbix.list
deb http://repo.zabbix.com/zabbix/2.4/debian wheezy main
deb-src http://repo.zabbix.com/zabbix/2.4/debian wheezy main

Agora vamos instalar o Zabbix Server propriamente dito. Como vocês devem ter reparado existem pacotes do zabbix-server, no entanto já pré-compilados para os respectivos bancos de dados, MySQL (zabbix-server-mysql), PostgreSQL (zabbix-server-pgsql), etc.


Estes pacotes já vem “atrelados” a um SGBD (Sistema de Gerenciamento de Banco de Dados) porque o Zabbix como aplicação necessita armazenar seus dados, para isso ele precisa de uma base de dados, faz parte da estrutura de camadas do Zabbix, a estrutura do banco, da aplicação Zabbix Server e a interface web, o que permite a flexibilidade de distribuir essas camadas em diversos servidores dando prioridade ao servidor atender apenas uma dessas camadas, principalmente em ambientes grandes, com diversos ativos de rede.


2. Instalando o zabbix-server e configurando o SGBD (PostgreSQL).


Neste exemplo faremos a instalação do Zabbix Server com a base de dados PostgreSQL por ser um banco de dados muito robusto, pensado para suportar ambientes tanto OLTP, quanto OLAP.

Observação: O Zabbix é um sistema OLTP (Online Transaction Processing), onde existe um grande volume de escrita em disco na Base de Dados. Principalmente em ambientes grandes, com diversos hosts e itens sendo monitorados.


No Red Hat:

1
2
# yum install zabbix-server-pgsql
# chkconfig zabbix-server on


Se for Red Hat 7 ou Debian 8:

1
# systemctl enable zabbix-server.service


No Debian:

1
# apt-get install zabbix-server-pgsql

No Debian como vocês devem ter reparado ele instala o Postgres e pergunta se você quer criar a Base de Dados, caso você queira basta seguir os passos conforme o db-config for lhe orientando.
Nessa circunstância, afim de detalhar a configuração do mesmo vamos fazer de forma igual par ambas as distribuições para que compreenda em ambos cenários, sendo assim selecione “No“.

Primeiramente, precisamos criar manualmente a base de dados a ser utilizada pelo Zabbix e o usuário administrador da base.

Como o Postgres não foi instalado no Red Hat, precisamos instalar o mesmo:


Somente no Red Hat:

1
2
3
4
# yum install postgresql-server
# chkconfig postgresql on
# service postgresql initdb
# service postgresql start


Se for Red Hat 7:

1
2
3
4
# yum install postgresql-server
# /usr/pgsql-VERSÃO/bin/postgresqlVERSÃO-setup initdb
# systemctl enable postgresql-9.4.service
# systemctl start postgresql-9.4.service

A partir desta etapa será executada em ambas as distribuições:


No Red Hat e Debian:

1
2
# su - postgres
$ psql
1
2
3
4
5
postgres=# CREATE ROLE zbxuser LOGIN;
postgres=# CREATE DATABASE zabbixdb OWNER TO zbxuser;
postgres=# \password zbxuser
(DEFINA A SENHA)
postgres=# \q
1
$ exit

Na versão 8.X do Postgres tive alguns problemas, informando no log a seguinte mensagem:

1
2
2285:20150806:112659.371 [Z3005] query failed: [0] PGRES_FATAL_ERROR:ERRO:  permissão negada para relação users
[select userid from users limit 1]

Para contornar essa situação tive que colocar o usuário da base zabbix como superuser:

1
postgres=# CREATE USER zbxuser SUPERUSER;

ou

1
postgres=# ALTER USER zbxuser SUPERUSER;

Agora sim podemos instalar o servidor zabbix.


E no Red Hat:

1
2
# yum install zabbix-server-pgsql
# chkconfig zabbix-server on


E no Debian:

1
# apt-get install zabbix-server-pgsql

Agora vamos popular a base de dados do Zabbix:


No Red Hat:

1
2
3
4
5
6
# cp /usr/share/doc/zabbix-server-pgsql-2.4.5/create/*.sql /var/lib/pgsql
# chown postgres. /var/lib/pgsql/*.sql
# su - postgres
$ cat schema.sql | psql zabbixdb
$ cat images.sql | psql zabbixdb
$ cat data.sql | psql zabbixdb


No Debian:

1
2
3
4
5
6
# cp /usr/share/zabbix­server­pgsql/*.sql /var/lib/postgresql/
# chown postgres. /var/lib/postgresql/*.sql
# su - postgres
$ cat schema.sql | psql zabbixdb
$ cat images.sql | psql zabbixdb
$ cat data.sql | psql zabbixdb

Ajustar as permissões de acesso a Base de Dados:


No Red Hat:

1
2
3
4
# vim /var/lib/pgsql/data/pg_hba.conf 
host    zabbixdb         zbxuser         127.0.0.1/32          md5
:x!
# service postgresql restart


No Debian:

1
2
3
4
# vim /etc/postgresql/VERSÃO/main/pg_hba.conf 
host    zabbixdb         zbxuser         127.0.0.1/32          md5
:x!
# service postgresql restart


No Red Hat 7 e Debian 8:

1
2
3
4
# vim /var/lib/pgsql/data/pg_hba.conf 
host    zabbixdb         zbxuser         127.0.0.1/32          md5
:x!
# systemctl restart postgresql

3. Configurando o zabbix-server.

Configure o arquivo de configuração do servidor Zabbix editando os parâmetros correspondentes a conexão com o Base de dados.

1
2
3
4
5
6
# vim /etc/zabbix/zabbix­_server.conf
DBHost=localhost
DBName=zabbixdb
DBUser=zbxuser
DBPassword=SenhaDozbxuser
:x!

No caso do Postgres versão 8.X é recomendável alterar o parâmetro DBHost de localhost para 127.0.0.1, por mais que ambos representem o endereço de loopback, ficando como:

1
2
3
4
5
6
# vim /etc/zabbix/zabbix­_server.conf
DBHost=127.0.0.1
DBName=zabbixdb
DBUser=zbxuser
DBPassword=SenhaDozbxuser
:x!

Feito estes procedimentos, podemos colocar nosso servidor Zabbix no ar:


Tanto quanto no Red Hat quanto no Debian, execute:

1
# service zabbix-server restart

3.1 Ajustes de segurança (Opcional e dependendo do ambiente)

Garantindo que o serviço do zabbix_server esta no ar e a porta 10051, porta padrão do Zabbix Server para monitoramento Zabbix Trapper (zabbix_sender), falaremos futuramente sobre este carinha aqui no Blog.

Precisamos apenas ajustar o Firewall para aceitar e estabelecer conexões através desta porta.


No Red Hat, execute:

# vim /etc/sysconfig/iptables
# Adicionar esta linha antes das regras de REJECT:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 10051 -j ACCEPT
:x!
# iptables-restore /etc/sysconfig/iptables

No Debian não vem Firewall configurado por padrão, caso o seu tenha firewall configurado, adicione a regra abaixo no seu script de Firewall para ficar definitivo.


No Debian, execute:

# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 10051 -j ACCEPT

4.  Instalando e configurando a interface web do Zabbix (PHP-Frontend)

Até este ponto tudo que fizemos foi colocar o serviço Zabbix Server no ar, no entanto não foi instalado ainda o frontend (interface web) do zabbix.


No Red Hat:

1
2
# yum install zabbix-web-pgsql
# service httpd start


No Red Hat 7:

1
2
# yum install zabbix-web-pgsql
# systemctl start httpd

Nas distribuições baseadas em Red Hat, é necessário instalar o pacote do frontend correspondente a base que será utilizada pelo mesmo, no nosso caso escolhemos pgsql (PostgreSQL).



No Debian:

1
# apt-get install zabbix-frontend-php

A partir deste ponto é necessário alguns ajustes do PHP no apache:


No Red Hat:

1
2
3
4
5
6
7
# vim /etc/httpd/conf.d/zabbix.conf
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 10M
php_value max_input_time 300
php_value date.timezone America/Sao_Paulo


No Debian:

1
2
3
4
5
6
7
# vim /etc/apache2/conf.d/zabbix
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 10M
php_value max_input_time 300
php_value date.timezone America/Sao_Paulo

No meu caso alterei para America/Sao_Paulo, visto que sou de São Paulo, caso sua situação seja diferente você pode obter o date.timezone do PHP correto da sua região em: http://php.net/manual/pt_BR/timezones.php



No Debian é importante instalar o módulo do php5-pgsql, para que o PHP tenha suporte a conexão com o PostgreSQL:

1
2
## apt-get install php5-pgsql
# service apache2 reload

Após essa alteração pode realizar um reload no apache para ele ler novamente as configurações e aplica-las:


No Red Hat:

1
# service httpd reload


No Debian 8:

1
# systemctl reload apache2


No Red Hat 7:

1
# systemctl reload httpd

A partir desse ponto a interface web já esta disponível, por tanto abra seu navegador e entre na seguinte URL:

  • http://SERVIDORZABBIX/zabbix

O contexto ‘/zabbix’ ou sub-diretório é o contexto default das instalações do zabbix, podendo ser editadas futuramente para padronizar um VirtualHost no servidor web Apache (httpd), no entanto esse não é o foco desse Post.

A tela inicial de configuração da interface web do Zabbix é:

Clique no botão “next” para avançar para próxima tela:

Verifique se todos os parâmetros estão OK, caso não volte e ajuste. Caso esteja tudo OK, pode pular para próxima tela:

Caso seu Postgres seja versão 8.X, recomendo alterar o valor de “Database host” de “localhost” para 127.0.0.1, conforme já pontuado antes. Ficando nesse formato:

Após, pode avançar para próxima tela:

O campo “Host” deve ser alterado quando você estiver segmentando o seu zabbix, ou seja, dividindo a aplicação zabbix server em um servidor dedicado e a interface web em outro servidor, por exemplo. Por tanto deixei como endereço de loopback, e pule para próxima tela:

Verifique se todas as configurações estão de acordo, caso sim, pode avançar:

Após esta etapa ele vai criar o arquivo zabbix.conf.php com os valores informados durante a configuração da interface web.

Estando OK, pode avançar:

Prontinho!

  • Login padrão: Admin (Com “A” maiúsculo)
  • Senha padrão: zabbix

5. Conclusão

Seja feliz e desfrute do seu Zabbix!
Sinta-se a vontade para responder e até mesmo corrigir possíveis erros que possam ter surgido durante a escrita do material. Grato pela atenção!