Nel prendere una decisione per il cliente, sono emerse due sfide che volevo risolvere in modo elegante e con le funzionalità standard di Zabbix.
Compito 1. Monitoraggio della versione attuale del firmware sui router Mikrotik.
Il compito si risolve facilmente aggiungendo al template dell'agente HTTP. L'agente ottiene la versione attuale dal sito Mikrotik, e il trigger confronta la versione attuale con quella in uso e, in caso di discrepanza, genera un avviso.
Quando si dispone di 10 router, questo algoritmo non è critico, ma cosa fare con 3000 router? Inviarne 3000 richieste al server? Funzionerebbe, certamente, ma l'idea di 3000 richieste non mi piaceva, volevo trovare un'altra soluzione. Inoltre, il difetto di un simile algoritmo è comunque presente: il lato opposto potrebbe considerare un tale numero di richieste da un singolo IP come un attacco DoS e potrebbe semplicemente bloccarlo.
Compito 2. Utilizzo della sessione di autenticazione in diversi agenti HTTP.
Quando è necessario ricevere informazioni da pagine "chiuse" tramite un agente HTTP, è necessaria un cookie di autenticazione. Di solito esiste una forma standard di autenticazione con una coppia "login/password" e l'impostazione dell'ID della sessione nel cookie.
Ma c'è un problema: non è possibile accedere ai dati di un elemento di un agente HTTP da un altro elemento per inserire questo valore nell'intestazione.
Esiste anche uno "Script Web", che ha un'altra limitazione: non consente di ottenere contenuti per analisi e salvataggio successivi. Si può solo controllare la presenza delle variabili necessarie sulle pagine o trasferire le variabili precedentemente ottenute tra i passaggi dello script web.
Pensando un po' a queste sfide, ho deciso di utilizzare macros, che sono ben visibili in qualsiasi parte del sistema di monitoraggio: in template, host, trigger o elementi. E i macros possono essere aggiornati tramite l'API dell'interfaccia web.
Zabbix ha una buona e dettagliata documentazione sull'API. Per lo scambio di dati tramite API viene utilizzato il formato dati Json. Puoi leggere di più su questo in .
La sequenza di azioni per ottenere i dati necessari e registrarli nel macro è mostrata nello schema qui sotto.
Passo 1
Il primo passo può consistere in un'unica azione o molteplici azioni. Nei primi passaggi viene inserita tutta la logica principale, e gli ultimi 3 passaggi sono i più importanti.
Nel mio esempio, al primo passo veniva eseguita l'ottenimento del cookie di autenticazione nell'ATS per il primo compito. Per il secondo compito ho ottenuto il numero della versione attuale del firmware Mikrotik.
URL delle versioni attuali del firmware Mikrotik
- — URL dell'attuale versione stabile
- — URL dell'attuale versione LTS
Questi indirizzi sono utilizzati dalle apparecchiature Mikrotik per ottenere l'ultima versione disponibile del firmware.
Il primo passo è completamente individuale per ogni caso e la logica del suo funzionamento può variare. Dipende tutto dalla tua esigenza.
Quando lavori con script web, tieni traccia di quale metodo di risposta ti serve. Intestazioni da parte della risposta HTTP o dal corpo della risposta senza intestazioni?
Se hai bisogno di cookie di autorizzazione, allora imposta il metodo di risposta Intestazioni come nel caso di Asterisk.Se hai bisogno di dati, come nel caso della risposta del server mikrotik, imposta Corpo la risposta senza intestazioni.
Passo 2
Passiamo al secondo passo. Ottenimento della 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 — versione del protocollo JSON-RPC in uso;
Zabbix implementa JSON-RPC versione 2.0;
- method — metodo che viene chiamato;
- params — parametri trasmessi dal metodo;
- id — identificatore arbitrario della richiesta;
- auth — chiave di autenticazione dell'utente; poiché non ne abbiamo ancora uno, la imposteremo su null.
Per lavorare con l'API ho creato un account separato con permessi limitati. Prima di tutto, non è necessario dare accesso a ciò che non serve. In secondo luogo, fino alla versione 5.0, la password impostata tramite macro poteva essere letta. Pertanto, se si utilizza la password dell'amministratore di Zabbix, l'account dell'amministratore può essere facilmente rubato.
Questo sarà particolarmente rilevante quando si lavora con l'API tramite script di terze parti e si memorizzano le credenziali sul lato.
A partire dalla versione 5.0, è stata introdotta l'opzione per nascondere la password memorizzata nella macro.
Quando crei un account separato per aggiornare i dati tramite API, assicurati che i dati necessari siano accessibili tramite l'interfaccia web e che possa essere effettuato l'aggiornamento. Non ho controllato e poi ho impiegato del tempo a capire perché non riuscivo a visualizzare la macro necessaria tramite API.
Dopo aver ottenuto l'autorizzazione nell'API, passiamo all'ottenimento dell'elenco delle macro.
Passo 3
L'interfaccia API non consente di aggiornare il macro host per nome; è necessario prima ottenere l'ID del macro. Inoltre, per ottenere un elenco dei macro di un host specifico, è necessario conoscere l'ID di quell'host, il che comporta una richiesta aggiuntiva. Utilizzare un macro di sistema. {HOST.ID} non è possibile nella richiesta. Ho trovato un modo per aggirare questa limitazione:
Ho creato un macro locale con l'ID di questo host. Ottenere l'ID dell'host è molto semplice tramite l'interfaccia web.
La risposta con l'elenco di tutti i macro di questo host può essere filtrata in base al modello:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
In questo modo otteniamo l'ID del macro necessario, dove MIKROTIK_VERSION è il nome del macro che stiamo cercando. Nel mio caso, viene cercato il macro MIKROTIK_VERSION, che è stato assegnato all'host.
La richiesta appare così:
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
}
Variabile {sid} ottenuta nel secondo passo e sarà utilizzata continuamente, quando è necessario lavorare con l'interfaccia API.
Fase finale 4 - aggiornamento del macro
Ora conosciamo l'ID del macro che deve essere aggiornato, il cookie di autorizzazione o la versione del firmware del router. Possiamo aggiornare il macro stesso.
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} è il valore ottenuto nel primo passaggio. Nel mio esempio - la versione del firmware attuale di Mikrotik.
{hostmacroid} è il valore ottenuto nel terzo passaggio - l'ID del macro che stiamo aggiornando.
Conclusioni
L'approccio alla risoluzione del problema con le funzionalità di sistema è di gran lunga più complesso e lungo. Soprattutto se si conosce la programmazione e si può rapidamente implementare la logica necessaria in uno script.
Un chiaro vantaggio di questo approccio è la "portabilità" della soluzione tra diversi server.
Personalmente trovo strano che non ci sia la possibilità di accedere ai dati di un altro elemento nell'agente HTTP e di inserirli nel corpo della richiesta o nelle intestazioni [ ].
Il modello pronto può essere .
Fonte: habr.com
