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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 <elvis.suffipompeu@hotmail.com>
# 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 <elvis.suffipompeu@hotmail.com>
# 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 <<EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print <<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 <<EOF;
 
Alert for group $opt_g, service $opt_s
EOF
 
print "This alert was sent because service was restored\n"
    if ($opt_u);
 
print <<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!