Bij de oplossing voor de klant ontstonden er 2 uitdagingen die mooi opgelost moesten worden met de standaardfunctionaliteit van Zabbix.
Uitdaging 1. Het bijhouden van de actuele versie van de firmware op Mikrotik-routers.
De uitdaging is eenvoudig op te lossen door toevoeging aan het sjabloon van de HTTP-agent. De agent ontvangt de actuele versie van de Mikrotik-website, en de trigger vergelijkt de actuele versie met de huidige versie en geeft bij een verschil een alert.
Wanneer je 10 routers hebt, is zo'n algoritme niet kritiek, maar wat te doen met 3000 routers? 3000 aanvragen naar de server sturen? Natuurlijk zal die opzet werken, maar het idee van 3000 aanvragen beviel me niet, ik wilde een andere oplossing vinden. Bovendien was er een tekortkoming in zo'n algoritme: de andere partij kan zoveel aanvragen vanaf één IP als een DoS-aanval beschouwen en je kunnen gewoon blokkeren.
Uitdaging 2. Gebruik van autorisatiesessies in verschillende HTTP-agents.
Wanneer je via de HTTP-agent informatie van 'gesloten' pagina's moet verkrijgen, is een autorisatiecookie nodig. Hiervoor is er meestal een standaard autorisatieformulier met een paar 'login/wachtwoord' en het instellen van de sessie-ID in de cookie.
Maar er is een probleem, je kunt vanuit één item van de HTTP-agent niet naar de gegevens van een ander item verwijzen om deze waarde in de header in te voegen.
Er is ook nog een 'Webscenario', dat heeft een andere beperking, het biedt niet de mogelijkheid om inhoud voor analyse en verdere opslag te verkrijgen. Je kunt alleen controleren of de benodigde variabelen op pagina's aanwezig zijn of eerder verkregen variabelen tussen stappen van het webscenario doorgeven.
Na wat nagedacht te hebben over deze uitdagingen, besloot ik om macro's te gebruiken, die uitstekend zichtbaar zijn in elk deel van het monitoringsysteem: in sjablonen, hosts, triggers of items. En macro's kunnen worden bijgewerkt via de API van de webinterface.
Zabbix heeft goede en gedetailleerde documentatie over de API. Voor gegevensuitwisseling via de API wordt het JSON-gegevensformaat gebruikt. Dit kan je in detail lezen in .
De volgorde van handelingen om de benodigde gegevens te verkrijgen en deze in de macro op te slaan, wordt weergegeven in het schema hieronder.
Stap 1
De eerste stap kan uit één actie of meerdere acties bestaan. In de eerste stappen wordt de hele hoofdlogica gelegd, en de belangrijkste stappen zijn de laatste 3.
In mijn voorbeeld werd in de eerste stap de autorisatie-cookie voor de telefoniecentrale verkregen voor de eerste taak. Voor de tweede taak ontving ik het nummer van de huidige versie van de Mikrotik-firmware.
URL van actuele versies van Mikrotik-firmware
- — URL van de actuele stabiele versie
- — URL van de actuele LTS-versie
Deze adressen worden door de Mikrotik-apparatuur aangesproken bij het ophalen van de laatste beschikbare firmwareversie.
De eerste stap is volledig individueel voor elk geval en de logica ervan kan variëren. Dit hangt af van uw taak.
Bij het werken met webscenario's moet je volgen welke methode voor het ontvangen van een antwoord je nodig hebt. Hoofden van het HTTP-antwoord of zelf de body van het antwoord zonder koppen?
Als autorisatie-cookies nodig zijn, stel dan de antwoordmethode in Hoofden zoals in het geval van Asterisk.Als gegevens nodig zijn, zoals in het geval van een serverantwoord van Mikrotik, stel dan de body van het antwoord zonder koppen in.
Stap 2
Laten we doorgaan naar de tweede stap. Het verkrijgen van een autorisatiesessie:
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 — de versie van het JSON-RPC-protocol dat wordt gebruikt;
Zabbix implementeert JSON-RPC versie 2.0;
- method — de methode die wordt aangeroepen;
- params — de parameters die door de methode worden doorgegeven;
- id — een willekeurige identificatie van het verzoek;
- auth — de authenticatiesleutel van de gebruiker; omdat we deze nog niet hebben, geven we deze gelijk aan null.
Voor het werken met de API heb ik een apart account aangemaakt met beperkte rechten. Ten eerste, je moet geen toegang geven tot gebieden waar dat niet nodig is. En ten tweede, tot versie 5.0 kon het via de macro ingestelde wachtwoord worden gelezen. Bijgevolg, als je het administratorwachtwoord van Zabbix gebruikt, is het adminaccount gemakkelijk te stelen.
Dit wordt vooral relevant wanneer je werkt met de API via externe scripts en je de inloggegevens aan de backend opslaat.
Met versie 5.0 is de optie toegevoegd om het wachtwoord dat in de macro is opgeslagen te verbergen.
Wanneer je een apart account aanmaakt voor het bijwerken van gegevens via de API, controleer dan altijd of de gegevens die je nodig hebt beschikbaar zijn via de webinterface en of ze kunnen worden bijgewerkt. Ik heb dit niet gecontroleerd en kon later lange tijd niet begrijpen waarom de benodigde macro niet zichtbaar was via de API.
Nadat we autorisatie in de API hebben gekregen, gaan we verder met het ophalen van de lijst van macro's.
Stap 3
De API-interface staat niet toe om de hostmacro bij naam bij te werken, daarvoor moet je eerst de ID van de macro verkrijgen. Bovendien, om de lijst met macro's van een specifieke host te krijgen, moet je de ID van die host weten, wat een extra verzoek vereist. Gebruik de standaardmacro. {HOST.ID} is niet mogelijk in het verzoek. Ik heb besloten deze beperking te omzeilen door:
Ik heb een lokale macro aangemaakt met de ID van deze host. De ID van de host is heel gemakkelijk te vinden via de webinterface.
Het antwoord met de lijst van alle macro's van deze host kan gefilterd worden op het patroon:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}" 
Op deze manier krijgen we de ID van de macro die we nodig hebben, waarbij MIKROTIK_VERSION de naam is van de macro die we zoeken. In mijn geval wordt de macro gezocht MIKROTIK_VERSION, die aan de host was toegewezen.
Het verzoek ziet er als volgt uit:
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
}
Variabele {sid} ontvangen in de tweede stap en zal constant gebruikt worden waar gewerkt moet worden met de API-interface.
Eind 4e STAP — bijwerken van de macro
Nu weten we de ID van de macro die we moeten bijwerken, de authenticatiecookie of de versie van de routerfirmware. We kunnen de macro zelf bijwerken.
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} is de waarde verkregen in de eerste stap. In mijn voorbeeld — de versie van de actuele mikrotik firmware.
{hostmacroid} is de waarde die we hebben verkregen in de derde stap — de id van de macro die we bijwerken.
Conclusies
De aanpak om de taak met de standaardfunctionaliteit op te lossen is veel complexer en tijdrovender. Vooral als je programmeervaardigheden hebt en snel de benodigde logica in een script kan opstellen.
Een duidelijk voordeel van deze aanpak is de 'overdraagbaarheid' van de oplossing tussen verschillende servers.
Persoonlijk vind ik het vreemd dat het niet mogelijk is om in de HTTP-agent gegevens van een ander item op te vragen en deze in de body van het verzoek of in de headers in te voegen [ ].
Het kant-en-klare sjabloon kan .
Bron: habr.com
