Ao criar uma solução para o cliente, surgiram 2 tarefas que queríamos resolver de forma elegante e com a funcionalidade padrão do Zabbix.
Tarefa 1. Rastreamento da versão atual do firmware em roteadores Mikrotik.
A tarefa é resolvida facilmente — adicionando no template do agente HTTP. O agente obtém a versão atual do site da Mikrotik, e o gatilho compara a versão atual com a versão em uso, emitindo um alerta em caso de discrepância.
Quando você tem 10 roteadores, esse algoritmo não é crítico, mas o que fazer com 3000 roteadores? Enviar 3000 solicitações para o servidor? Funcionar, claro, essa abordagem funcionará, mas a ideia de 3000 solicitações não me agradava, desejava encontrar uma solução diferente. Além disso, havia uma desvantagem nesse algoritmo: o outro lado pode considerar tal quantidade de solicitações de um único IP como um ataque DoS e pode simplesmente bloquear.
Tarefa 2. Uso de sessão de autenticação em diferentes agentes HTTP.
Quando é necessário obter informações de páginas "fechadas" através do agente HTTP, é preciso um cookie de autenticação. Normalmente, existe uma forma padrão de autenticação com um par "login/senha" e a definição do ID da sessão no cookie.
Mas há um problema, não é possível que um item do agente HTTP acesse os dados de outro item para inserir esse valor no Header.
Existe ainda o "Script Web", que tem outra limitação, ele não permite obter conteúdo para análise e armazenamento posterior. É possível apenas verificar a existência das variáveis necessárias nas páginas ou transmitir variáveis obtidas anteriormente entre as etapas do script web.
Refletindo um pouco sobre essas tarefas, decidi usar macros, que são visíveis em qualquer parte do sistema de monitoramento: em templates, hosts, gatilhos ou itens. E as macros podem ser atualizadas através da API da interface web.
O Zabbix possui uma boa e detalhada documentação sobre a API. Para troca de dados via API, é utilizado o formato de dados JSON. É possível ler mais detalhadamente em .
A sequência de ações para obter os dados necessários e gravá-los na macro é apresentada no esquema abaixo.
Passo 1
O primeiro passo pode consistir em uma única ação ou em múltiplas ações. Nos primeiros passos, toda a lógica principal é estabelecida, e os últimos 3 passos são os mais importantes.
No meu exemplo, no primeiro passo foi realizada a obtenção do cookie de autenticação na PABX para a primeira tarefa. Para a segunda tarefa, obtive o número da versão atual do firmware Mikrotik.
URL das versões atuais do firmware Mikrotik
- — URL do endereço da versão Stable atual
- — URL do endereço da versão LTS atual
Esses endereços são acessados pelo próprio equipamento Mikrotik ao receber a última versão disponível do firmware.
O primeiro passo é totalmente individual para cada caso e a lógica de funcionamento pode ser diferente. Tudo depende da sua tarefa.
Ao trabalhar com scripts da web, observe qual método de obtenção de resposta você precisa. Cabeçalhos Resposta HTTP ou o próprio corpo da resposta sem cabeçalhos?
Se você precisa de cookies de autenticação, então configure o método de resposta Cabeçalhos como no caso do Asterisk.Se você precisa de dados, como no caso da resposta do servidor Mikrotik, configure Corpo a resposta sem cabeçalhos.
Passo 2
Vamos para o segundo passo. Obtenção da sessão de autorização:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin",
"password": "zabbix"
},
"id": 1,
"auth": null
}jsonrpc — versão do protocolo JSON-RPC utilizado;
Zabbix implementa a versão 2.0 do JSON-RPC;
- method — método que está sendo chamado;
- params — parâmetros que são passados pelo método;
- id — identificador arbitrário da solicitação;
- auth — chave de autenticação do usuário; como ainda não a temos, vamos defini-la como igual a null.
Para trabalhar com a API, criei uma conta separada, com direitos limitados. Em primeiro lugar, não é necessário dar acesso a áreas que não precisam. Em segundo lugar, até a versão 5.0, a senha definida através do macro podia ser lida. Consequentemente, se usar a senha do administrador do Zabbix, a conta do administrador pode ser facilmente comprometida.
Isso será especialmente relevante quando você trabalha com a API por meio de scripts de terceiros e armazena as credenciais do lado de cá.
A partir da versão 5.0, surgiu a opção de ocultar a senha armazenada no macro.
Ao criar uma conta separada para atualizar dados através da API, verifique se os dados necessários estão acessíveis através da interface web e se é possível atualizá-los. Eu não verifiquei e depois demorei a entender por que o macro que precisava não estava visível via API.
Depois de obter autorização na API, vamos para a obtenção da lista de macros.
Passo 3
A interface da API não permite atualizar os macros do host pelo nome; primeiro é necessário obter o ID do macro. Além disso, para obter uma lista de macros de um host específico, você precisa saber o ID desse host, o que resulta em uma solicitação a mais. Usar um macro padrão. {HOST.ID} não é permitido na solicitação. Consegui contornar essa limitação da seguinte forma:
Criei um macro local com o ID desse host. Descobrir o ID do host é muito fácil através da interface web.
A resposta com a lista de todos os macros deste host pode ser filtrada pelo padrão:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Dessa forma, obtemos o ID do macro que precisamos, onde MIKROTIK_VERSION é o nome do macro que estamos procurando. No meu caso, o macro está sendo buscado MIKROTIK_VERSION, que foi atribuído ao host.
A própria solicitação fica assim:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.get",
"params":{
"output":"extend",
"hostids":"{$HOST_ID}"
},
"auth":"{sid}",
"id":1
}
Variável {sid} obtido na segunda etapa e será usado constantemente onde for necessário trabalhar com a API.
A etapa final 4 — atualização do macro
Agora sabemos o ID do macro que precisamos atualizar, o cookie de autorização ou a versão do firmware do roteador. Podemos atualizar o próprio macro.
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.update",
"params":{
"hostmacroid":"{hostmacroid}",
"value":"{mikrotik_version}"
},
"auth":"{sid}",
"id":1
}
{mikrotik_version} é o valor obtido na primeira etapa. No meu exemplo, é a versão do firmware atual do Mikrotik.
{hostmacroid} é o valor obtido na terceira etapa — o ID do macro que estamos atualizando.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
A abordagem para resolver a tarefa usando a funcionalidade padrão é muito mais complicada e demorada. Especialmente se você tem conhecimento de programação e pode rapidamente desenvolver a lógica necessária em um script.
Um benefício óbvio dessa abordagem é a 'portabilidade' da solução entre diferentes servidores.
Pessoalmente, acho estranho a falta de capacidade de acessar dados de outro item no agente HTTP e inseri-los no corpo da solicitação ou nos cabeçalhos [ ].
O template pronto pode ser .
Fonte: habr.com
