Veja como gerar scripts em diversas linguagens, detectar os serviços instalados que se deseja monitorar e criar o monitoramento automático com Zabbix.
Para conseguir criar e destruir novas instâncias na Amazon AWS de acordo com o crescimento de demanda na Oobj, depara-se com uma necessidade importante: incluir tais instâncias nos monitoramentos do Zabbix.
A Oobj utiliza alguns recursos de Monitoramento da própria AWS, como o CloudWatching, mas o Zabbix já é usado para monitoramentos específicos.
Porém, o problema é a necessidade de inclusão feita de forma manual no Zabbix de todas as novas instâncias criadas. Isso inviabiliza a automação na criação de dezenas ou até centenas de instâncias sem abrir mão do Zabbix.
Sendo que esse “auto-scalling” é essencial para a Oobj conseguir otimizar a utilização dos recursos na Amazon. E sempre garantir a alta performance na emissão de documentos fiscais. Diante desse cenário, surgiu a necessidade de automatizar a atual configuração manual.
Para resolver esse problema, a Oobj usou os seguintes recursos disponibilizados pelo Zabbix:
- Auto Registro (Auto Registration) – o Zabbix-agent instalado na máquina se registra no servidor, criando um novo monitoramento, já adicionando todos os templates necessários;
- Descoberta (Discovery) – permite-se criar scripts em diversas linguagens, inclusive shell, e o Zabbix-server detectar os serviços instalados que se deseja monitorar e criar o monitoramento automático;
- Cancelamento do Registro (DeRegistration) – utilizando diversas linguagens, o API do zabbix, remove configurações de monitoramento que não existem mais.
Nesse case, trataremos apenas dos dois primeiros procedimentos: Auto Registration e Discovery.
+ Leia mais: Tecnologia da Netflix para reduzir custo computacional
Vamos a ação!
Aplicação de Auto Registration no Zabbix
Esse procedimento é bem simples, o primeiro passo é criar um action no zabbix-server e poucas configurações no zabbix-client, para isso basta:
- No painel zabbix-server, ir em:
Configuration > Actions > Event Source: Auto Registration > Create Action
- Na aba “Action”, digitar o nome da action, e adicionar uma condição usando “host metadata”;
Exemplo:
- Name: motor-processamento
- Condition: host metadata like motor
- Na aba Operations configure os dados da mensagem que serão enviados por email informando a criação do novo monitoramento de servidor;
- Adicione as operações do novo monitoramento;
No exemplo abaixo configuramos para a nova máquina ser adicionada a um grupo e vir configurada com 2 templates: um para Linux e outro para nossos serviços (Oobj Services, discovery personalizado), que será detalhado mais a frente.
- Ir até o zabbix-agent e configurar o Server, ServerActive e HostMetadata;
O HostMetadata deve ser igual ao configurado na “action” no servidor, mostrado anteriormente. No servidor se utiliza a condição “like”, então se seus serviços tiverem nomes parecidos, e quiser criar um Auto Registration personalizado por serviço, deve montar um nome de modo que uma action não influencie outra.
- Comentar a linha do “Hostname”:
- Feitas as configurações, basta reiniciar o zabbix-agent;
Veja o exemplo:
#############################################
Server=zabbix_oobj.com.br
ServerActive=zabbix_oobj.com.br
#Hostname=Zabbix server
HostMetadata=motor
#############################################
Com isso, conclui-se a parte do Auto Registration de servidores.
Discovery de serviços no Zabbix
Para o monitoramento dos serviços ser automatizado, é necessário que o Zabbix descubra de forma independente os serviços instalados e inicie o acompanhamento. Para isso, foi criado um template no servidor específico para os monitoramentos dos serviços:
No template também foi elaborado um Application e Discovery:
Na configuração do Discovery foi inserido um Name, type “zabbix agente”, e uma key (a qual será criada no zabbix cliente, denominada de: custom.oobj.discovery.
Essa configuração tem a verificação dos serviços do servidor a cada 1h. Esse tempo é visto como ideal, porque normalmente os serviços não são instalados com tanta frequência. Porém, na primeira vez é possível agendar um intervalo de tempo menor.
Além disso, mais a frente, essa mesma key também é criada no zabbix-client:
Acompanhe a seguir, os passos realizados após a configuração de tempo:
- Criação de um “item prototypes”;
- Configuração de um name, utilizando a chave “{#SERVICE_NOME}” que serve para mapear os nomes dos serviços instalados no servidor;
- Preferência por utilizar uma key diferente da utilizada na do Discovery. Essa key funciona para buscar o nome do serviço, criada no cliente, chamada de: custom.oobj.service;
Na key passamos um parâmetro fixo, que é o status, ele indica para o script do client que eu quero o status daquele serviço.
Essa key: [status,{#SERVICE_NOME}]
Vai ser traduzida como: [status, oobj-recebe].
- Configuração do tempo de validação de status do serviço, no caso de 120 segundos:
O serviço é capaz de utilizar esse Discovery automaticamente porque já foi configurado e estruturado para Auto Registration adicionar o template de serviços (oobj services).
Veja o exemplo:
Zabbix-agent
O case aqui apresentado se sucedeu em uma máquina Ubuntu 14.04. No servidor local fica o agente, o qual pode ser instalado automaticamente por alguma rotina ou trabalhando com imagens de máquinas da AWS que são utilizadas no Auto Scaling.
Veja o exemplo de instalação do agente:
- Na pasta: “/etc/zabbix/zabbix_agentd.d”, deve-se configurar um userparameter e o script do Discovery e itens do Discovery;
- Primeiro configura-se o arquivo userparameter:
- Nome: conf
- Configuração de 2 parâmetros:
1º) custom.oobj.discovery – apenas é executado o script que lista para o zabbix quais serviços existem (essa é a key do discovery);
2º) custom.oobj.service[*] – passados dois princípios:
– Solicitação de status e o nome do serviço, o qual retorna 1 para ok e 0 para serviço parado;
– Utilizado na configuração do “item prototype”.
Veja como ficam esses dois parâmetros no arquivo userparameter_services_oobj.conf;
Observação: Apenas as duas linhas em vermelho são os parâmetros, as demais linhas são comentários.
No userparameter, um arquivo nomeado de script é chamado: “valida_services_oobj.sh”, que será criado a seguir.
- Cria-se então o arquivo “sh” na pasta “/etc/zabbix/zabbix_agentd.d”, pois o userparameter vai buscar esse script nessa pasta.
- Após isso é preciso listar todos os serviços em uma única variável, em linha, um abaixo do outro.
Os apresentados aqui ficam instalados na “/etc/init.d”, sob o comando “ls” para criar a lista. Utiliza-se o grep para filtrar nossos serviços, portanto, é possível utilizar uma condição de “OR” no grep.
Veja o script completo:
- É preciso então executar o comando grep pelo retorno do status que indica se o serviço está rodando.
No caso da Oobj, há a possibilidade de ocorrer 3 tipos de retorno distintos. Portanto, foi utilizado novamente um “OR” no grep.
- Deve-se executar o comando wc –l para sempre retornar “0” (serviço parado) ou “1” (serviço rodando).
O Zabbix está configurado para interpretar somente esses 2 retornos:
- É necessário ainda a definição das permissões e instalação do “jq” que é um interpretador de json para o Linux:
O que acontece aqui é uma criação, feita pelo script, de um arquivo com um json na pasta “/tmp” que o zabbix-server precisa para o Discovery. Além disso, a chamada é interpretada para validar se o serviço está ativo.
- Por fim, é necessário reiniciar o zabbix-agent;
Assim, a partir disso, qualquer host do Zabbix que configure o template de serviço vai executar estas verificações nos servidores. Ocorrerá também o relato de existência ou instalações de serviço, iniciando automaticamente o monitoramento do mesmo.
Script Json Discovery
Confira abaixo o script que gera o json para o Discovery e permite a consulta pelo status do serviço:
Observação: Em vermelho, estão os trechos alterados (descritos acima).
Se você deseja ler mais cases como esse, clique aqui.
Sobre o autor:
Joânio Trade é Analista de banco de dados PostgreSQL, rabiscador de Oracle e SQL Server, aventureiro de shell script e pl/sql, curioso de ambientes AWS e atuante em monitoramento ativo e reativo de ambientes e serviços.
Fontes
- Moshe Nadler: Zabbix, AWS and Auto Registration;
- André Deo: LLD no Zabbix com Shell Script – Entendendo e utilizando esse recurso
Deixe um comentário