Durante la creazione di una soluzione per un cliente, sono emerse 2 attività che volevo risolvere magnificamente e con la normale funzionalità di Zabbix.
Compito 1. Monitoraggio della versione corrente del firmware sui router Mikrotik.
L'attività viene risolta facilmente, aggiungendo un agente al modello HTTP. L'agente riceve la versione corrente dal sito Web Mikrotik e il trigger confronta la versione corrente con quella corrente ed emette un avviso in caso di discrepanza.
Quando hai 10 router, un tale algoritmo non è fondamentale, ma cosa fare con 3000 router? Invia 3000 richieste al server? Certo, un tale schema funzionerà, ma l'idea stessa di 3000 richieste non mi andava bene, volevo trovare un'altra soluzione. Inoltre, c'era ancora uno svantaggio in un simile algoritmo: l'altra parte può contare un tale numero di richieste da un IP per un attacco DoS, può semplicemente vietarlo.
Compito 2. Utilizzo di una sessione di autorizzazione in diversi agenti HTTP.
Quando un agente ha bisogno di ricevere informazioni da pagine "chiuse" tramite HTTP, è necessario un cookie di autorizzazione. Per fare ciò, di solito esiste un modulo di autorizzazione standard con una coppia "login / password" e l'impostazione dell'ID di sessione nel cookie.
Ma c'è un problema, è impossibile accedere ai dati di un altro elemento da un elemento dell'agente HTTP per sostituire questo valore nell'intestazione.
C'è anche uno "script Web", ha un'altra limitazione, non consente di ottenere contenuti per l'analisi e l'ulteriore salvataggio. Puoi solo verificare la presenza delle variabili necessarie nelle pagine o passare variabili ottenute in precedenza tra istruzioni di script web.
Dopo aver riflettuto un po' su queste attività, ho deciso di utilizzare macro perfettamente visibili in qualsiasi parte del sistema di monitoraggio: in template, host, trigger o elementi. E puoi aggiornare le macro tramite l'API dell'interfaccia web.
Zabbix ha una documentazione API buona e dettagliata. Per lo scambio di dati tramite api viene utilizzato il formato dati Json. I dettagli possono essere trovati in .
La sequenza di azioni per ottenere i dati di cui abbiamo bisogno e registrarli in una macro è mostrata nel diagramma sottostante.
Passo 1
Il primo passaggio può consistere in una singola azione o in più azioni. Tutta la logica principale è posta nei primi passaggi e gli ultimi 3 passaggi sono i principali.
Nel mio esempio, il primo passaggio è stato ottenere i cookie di autorizzazione sul PBX per la prima attività. Per il secondo compito, ho ricevuto il numero della versione corrente del firmware Mikrotik.
URL delle versioni correnti del firmware Mikrotik
- - Indirizzo URL dell'attuale versione stabile
- — Indirizzo URL della versione LTS corrente
A questi indirizzi accede l'apparecchiatura Mikrotik stessa quando viene ricevuta l'ultima versione firmware disponibile.
Il primo passo è completamente individuale per ogni caso e la logica del suo lavoro può essere diversa. Tutto dipende dal tuo compito.
Quando lavori con il web scripting, tieni traccia del metodo di risposta di cui hai bisogno. titoli Risposta HTTP o self тело risposta senza intestazioni?
Se sono necessari i cookie di autorizzazione, impostare il metodo di risposta titoli come nel caso di Asterisk.Se hai bisogno di dati, come nel caso della risposta del server mikrotik, metti corpo risposta senza intestazioni.
Passo 2
Passiamo al secondo passaggio. Ottenere una sessione di autorizzazione:
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 è la versione del protocollo JSON-RPC in uso;
Zabbix implementa JSON-RPC versione 2.0;
- metodo - il metodo che viene chiamato;
- params - parametri passati dal metodo;
- id è un identificatore di richiesta arbitrario;
- auth - chiave di autenticazione dell'utente; poiché non lo abbiamo ancora, impostiamolo su null.
Per lavorare con l'API, ho creato un account separato con diritti limitati. In primo luogo, non è necessario dare accesso a dove non è necessario. E in secondo luogo, prima della versione 5.0, era possibile leggere la password impostata tramite la macro. Di conseguenza, se utilizzi la password dell'amministratore Zabbix, l'account amministratore è facile da rubare.
Ciò sarà particolarmente vero quando si lavora con l'API tramite script di terze parti e si memorizzano le credenziali sul lato.
Dalla versione 5.0 c'è un'opzione per nascondere la password salvata nella macro.
Quando crei un account separato per l'aggiornamento dei dati tramite l'API, assicurati di controllare se i dati di cui hai bisogno sono disponibili tramite l'interfaccia web e se è possibile aggiornarli. Non ho controllato e quindi per molto tempo non sono riuscito a capire perché la macro di cui avevo bisogno non fosse visibile nell'API.
Dopo aver ricevuto l'autorizzazione nell'API, procediamo a ottenere un elenco di macro.
Passo 3
L'API non ti consente di aggiornare una macro host in base al nome, devi prima ottenere l'ID macro. Inoltre, per ottenere un elenco di macro per un host specifico, è necessario conoscere l'ID di questo host e questa è una richiesta aggiuntiva. Usa la macro predefinita {ID HOST} nella richiesta non è consentito. Ho deciso di aggirare la restrizione in questo modo:
Ho creato una macro locale con l'ID di questo host. Trovare l'ID host è molto semplice dall'interfaccia web.
Una risposta con un elenco di tutte le macro su un determinato host può essere filtrata da un modello:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Pertanto, otteniamo l'ID della macro di cui abbiamo bisogno, dove MIKROTIK_VERSIONE è il nome della macro che stiamo cercando. Nel mio caso, la macro viene cercata MIKROTIK_VERSIONEIl che è stato assegnato all'host.
La richiesta stessa è simile a questa:
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
}
Переменная {sid} ottenuto nella seconda fase e verrà utilizzato costantemente, dove è necessario lavorare con l'interfaccia API.
Fase 4 finale: aggiornamento della macro
Ora conosciamo l'ID macro che deve essere aggiornato, il cookie di autorizzazione o la versione firmware del router. Puoi aggiornare la macro stessa.
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
}
{versione_microtik} è il valore ottenuto nel primo passaggio. Nel mio esempio, la versione dell'attuale firmware mikrotik
{hostmacroid} - il valore è stato ottenuto nel terzo passaggio - l'id della macro che stiamo aggiornando.
risultati
L'approccio alla risoluzione del problema con funzionalità standard è molto più complicato e più lungo. Soprattutto se conosci la programmazione e puoi aggiungere rapidamente la logica necessaria nello script.
L'ovvio vantaggio di questo approccio è la "portabilità" della soluzione tra diversi server.
Per me personalmente, è strano che l'agente HTTP non possa accedere ai dati di un altro elemento e sostituirli nel corpo o nelle intestazioni della richiesta [ ].
Il modello finito può .
Fonte: habr.com