Ao fazer uma solução para um cliente, surgiram 2 tarefas que eu queria resolver lindamente e com funcionalidade normal do Zabbix.
Desafio 1. Rastreando a versão atual do firmware nos roteadores Mikrotik.
A tarefa é resolvida facilmente - adicionando um agente ao modelo HTTP. O agente recebe a versão atual do site do Mikrotik, e a trigger compara a versão atual com a atual e emite 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? É claro que esse esquema funcionará, mas a própria ideia de 3000 solicitações não me agradou, queria encontrar outra solução. Além disso, ainda havia uma desvantagem em tal algoritmo: o outro lado pode contar tantas solicitações de um IP para um ataque DoS que pode simplesmente bani-lo.
Desafio 2. Usando uma sessão de autorização em diferentes agentes HTTP.
Quando um agente precisa receber informações de páginas "fechadas" via HTTP, é necessário um cookie de autorização. Para fazer isso, geralmente existe um formulário de autorização padrão com um par "login / senha" e definindo o ID da sessão no cookie.
Mas há um problema, é impossível acessar os dados de outro item de um item do agente HTTP para substituir este valor no Cabeçalho.
Existe também um "Web script", tem outra limitação, não permite obter conteúdo para análise e posterior salvamento. Você pode apenas verificar a presença das variáveis necessárias nas páginas ou passar variáveis recebidas anteriormente entre as etapas do script da web.
Depois de pensar um pouco sobre essas tarefas, resolvi usar macros perfeitamente visíveis em qualquer parte do sistema de monitoramento: em templates, hosts, triggers ou itens. E você pode atualizar as macros por meio da API da interface da web.
O Zabbix possui uma boa e detalhada documentação de API. Para troca de dados via API, o formato de dados Json é usado. Os detalhes podem ser encontrados em .
A sequência de ações para obter os dados de que precisamos e gravá-los em uma macro é mostrada no diagrama abaixo.
Passo 1
A primeira etapa pode consistir em uma única ação ou em várias ações. Toda a lógica principal é colocada nas primeiras etapas, e as últimas 3 etapas são as principais.
No meu exemplo, a primeira etapa foi obter cookies de autorização no PBX para a primeira tarefa. Para a segunda tarefa, obtive o número da versão atual do firmware do Mikrotik.
URL das versões atuais do firmware do Mikrotik
- - Endereço URL da versão estável atual
- — Endereço URL da versão LTS atual
Esses endereços são acessados pelo próprio equipamento Mikrotik quando a última versão de firmware disponível é recebida.
A primeira etapa é totalmente individual para cada caso e a lógica de seu funcionamento pode ser diferente. Tudo depende da sua tarefa.
Ao trabalhar com scripts da Web, controle qual método de resposta você precisa. Р - РіРѕ РиРРРєРё Resposta HTTP ou auto тело resposta sem cabeçalhos?
Se forem necessários cookies de autorização, defina o método de resposta Р - РіРѕ РиРРРєРё como no caso do Asterisk.Se precisar de dados, como no caso da resposta do servidor mikrotik, coloque Corpo resposta sem cabeçalhos.
Passo 2
Vamos para a segunda etapa. Obtendo uma 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 é a versão do protocolo JSON-RPC que está sendo usado;
Zabbix implementa JSON-RPC versão 2.0;
- method - o método que é chamado;
- params - parâmetros que são passados pelo método;
- id é um identificador de solicitação arbitrária;
- auth - chave de autenticação do usuário; como ainda não o temos, vamos defini-lo como nulo.
Para trabalhar com a API, criei uma conta separada com direitos limitados. Em primeiro lugar, você não precisa dar acesso a onde não precisa. E em segundo lugar, antes da versão 5.0, a senha definida por meio da macro podia ser lida. Assim, se você usar a senha de administrador do Zabbix, a conta de administrador é fácil de roubar.
Isso será especialmente verdadeiro ao trabalhar com API por meio de scripts de terceiros e armazenar credenciais paralelamente.
Desde a versão 5.0 existe a opção de ocultar a senha salva na macro.
Ao criar uma conta separada para atualização de dados por meio da API, certifique-se de verificar se os dados necessários estão disponíveis por meio da interface da web e se é possível atualizá-los. Não verifiquei e, por muito tempo, não consegui entender por que a macro de que precisava não estava visível na API.
Depois de recebermos a autorização na API, passamos a obter uma lista de macros.
Passo 3
A API não permite que você atualize uma macro de host pelo nome, você deve primeiro obter o ID da macro. Além disso, para obter uma lista de macros para um host específico, você precisa saber o ID desse host, e essa é uma solicitação extra. Usar macro padrão {ID DO HOST} no pedido não é permitido. Eu decidi contornar a restrição assim:
Criei uma macro local com o ID deste host. Descobrir o ID do host é muito fácil na interface da web.
Uma resposta com uma lista de todas as macros em um determinado host pode ser filtrada por um padrão:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Assim, obtemos o ID da macro que precisamos, onde MIKROTIK_VERSION é o nome da macro que estamos procurando. No meu caso, a macro é pesquisada MIKROTIK_VERSIONO que foi atribuído ao host.
A solicitação em si é 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 você precisa trabalhar com a interface da API.
Final 4 STEP - atualizando a macro
Agora sabemos o ID da macro que precisa ser atualizado, o cookie de autorização ou a versão do firmware do roteador. Você pode atualizar a própria 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_versão} é o valor obtido na primeira etapa. No meu exemplo, a versão do firmware atual do mikrotik
{hostmacroid} - o valor foi obtido na terceira etapa - o id da macro que estamos atualizando.
Descobertas
A abordagem para resolver o problema com a funcionalidade padrão é muito mais complicada e mais longa. Especialmente se você conhece programação e pode adicionar rapidamente a lógica necessária no script.
A vantagem óbvia dessa abordagem é a "portabilidade" da solução entre diferentes servidores.
Para mim, pessoalmente, é estranho que o agente HTTP não possa acessar os dados de outro item e substituí-los no corpo da solicitação ou nos cabeçalhos [ ].
O modelo finalizado pode .
Fonte: habr.com