Arquivo da categoria: NOC

Assuntos relacionamento a monitoramento de redes, servidores e data centers.

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

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<64>/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!

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!