Asiakkaalle ratkaisua tehdessä nousi 2 tehtävää, jotka halusin ratkaista kauniisti ja tavallisella Zabbix-toiminnallisuudella.
1-tehtävä. Nykyisen laiteohjelmistoversion seuranta Mikrotik-reitittimissä.
Tehtävä ratkaistaan helposti - lisäämällä agentti HTTP-malliin. Agentti saa nykyisen version Mikrotikin verkkosivustolta, ja laukaisin vertaa nykyistä versiota nykyiseen ja antaa hälytyksen, jos poikkeaa.
Kun sinulla on 10 reititintä, tällainen algoritmi ei ole kriittinen, mutta mitä tehdä 3000 reitittimellä? Lähetetäänkö palvelimelle 3000 pyyntöä? Tietysti tällainen järjestelmä toimii, mutta itse ajatus 3000 pyynnöstä ei sopinut minulle, halusin löytää toisen ratkaisun. Lisäksi tällaisessa algoritmissa oli edelleen haittapuoli: toinen osapuoli voi laskea niin monta pyyntöä yhdeltä IP:ltä DoS-hyökkäykselle, he voivat yksinkertaisesti kieltää sen.
2-tehtävä. Valtuutusistunnon käyttäminen eri HTTP-agenteissa.
Kun agentin on saatava tietoja "suljetuilta" sivuilta HTTP:n kautta, tarvitaan valtuutuseväste. Tätä varten on yleensä olemassa standardi valtuutuslomake, jossa on "sisäänkirjautuminen / salasana" -pari ja istuntotunnuksen asettaminen evästeeseen.
Mutta on ongelma, on mahdotonta käyttää toisen kohteen tietoja yhdestä HTTP-agenttikohteesta tämän arvon korvaamiseksi otsikossa.
On myös "Web-skripti", sillä on toinen rajoitus, se ei salli sinun saada sisältöä analysoitavaksi ja edelleen tallennettavaksi. Voit vain tarkistaa tarvittavien muuttujien olemassaolon sivuilla tai siirtää aiemmin vastaanotetut muuttujat verkkokomentosarjan vaiheiden välillä.
Harkittuani hieman näitä tehtäviä, päätin käyttää makroja, jotka näkyvät täydellisesti missä tahansa valvontajärjestelmän osassa: malleissa, isännissä, triggereissä tai kohteissa. Ja voit päivittää makroja verkkokäyttöliittymän API:n kautta.
Zabbixilla on hyvä ja yksityiskohtainen API-dokumentaatio. Api:n kautta tapahtuvaan tiedonvaihtoon käytetään Json-datamuotoa. Yksityiskohdat löytyvät osoitteesta .
Toimintojärjestys tarvitsemamme tiedon hankkimiseksi ja niiden tallentamiseksi makroon on esitetty alla olevassa kaaviossa.
Vaihe 1
Aivan ensimmäinen vaihe voi koostua yhdestä tai useista toimista. Kaikki päälogiikka asetetaan ensimmäisissä vaiheissa, ja viimeiset 3 vaihetta ovat tärkeimmät.
Esimerkissäni ensimmäinen askel oli saada valtuutusevästeet PBX:ään ensimmäistä tehtävää varten. Toisessa tehtävässä sain Mikrotikin laiteohjelmiston nykyisen version numeron.
Mikrotik-laiteohjelmiston nykyisten versioiden URL-osoite
- - Nykyisen vakaan version URL-osoite
- — Nykyisen LTS-version URL-osoite
Mikrotik-laitteisto itse käyttää näitä osoitteita, kun uusin saatavilla oleva laiteohjelmistoversio on vastaanotettu.
Ensimmäinen vaihe on jokaisessa tapauksessa täysin yksilöllinen ja sen työn logiikka voi olla erilainen. Kaikki riippuu tehtävästäsi.
Kun työskentelet verkkokomentosarjan kanssa, pidä kirjaa, mitä vastausmenetelmää tarvitset. pääotsikot HTTP-vastaus tai itse тело vastaus ilman otsikoita?
Jos valtuutusevästeitä tarvitaan, aseta vastaustapa pääotsikot kuten Asteriskin tapauksessa.Jos tarvitset tietoja, kuten mikrotik-palvelimen vastauksen tapauksessa, laita elin vastaus ilman otsikoita.
Vaihe 2
Siirrytään toiseen vaiheeseen. Valtuutusistunnon saaminen:
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 on JSON-RPC-protokollan versio, jota käytetään;
Zabbix toteuttaa JSON-RPC-version 2.0;
- metodi - menetelmä, jota kutsutaan;
- parametrit - parametrit, jotka menetelmä välittää;
- id on mielivaltainen pyyntötunniste;
- auth - käyttäjän todennusavain; koska meillä ei ole sitä vielä, asetetaan se nollaksi.
Sovellusliittymää varten loin erillisen tilin rajoitetuilla oikeuksilla. Ensinnäkin sinun ei tarvitse antaa pääsyä sinne, missä sinun ei tarvitse. Ja toiseksi, ennen versiota 5.0 makron kautta asetettu salasana voitiin lukea. Näin ollen, jos käytät Zabbix-järjestelmänvalvojan salasanaa, järjestelmänvalvojan tili on helppo varastaa.
Tämä pätee erityisesti työskennellessäsi API:n kanssa kolmannen osapuolen komentosarjojen avulla ja tallentaessasi tunnistetietoja sivuun.
Versiosta 5.0 lähtien makroon tallennettu salasana on mahdollista piilottaa.
Kun luot erillisen tilin tietojen päivittämistä varten API:n kautta, muista tarkistaa, ovatko tarvitsemasi tiedot saatavilla verkkoliittymän kautta ja onko niitä mahdollista päivittää. En tarkistanut, ja sitten en pitkään aikaan voinut ymmärtää, miksi tarvitsemani makro ei ollut näkyvissä API:ssa.
Kun olemme saaneet valtuutuksen API:ssa, siirrymme saamaan luettelon makroista.
Vaihe 3
API ei anna sinun päivittää isäntämakroa nimellä, sinun on ensin hankittava makron tunnus. Lisäksi saadaksesi luettelon tietyn isännän makroista, sinun on tiedettävä tämän isännän tunnus, ja tämä on ylimääräinen pyyntö. Käytä oletusmakroa {HOST ID} pyynnössä ei ole sallittua. Päätin ohittaa rajoituksen näin:
Loin paikallisen makron tämän isännän tunnuksella. Isäntätunnuksen selvittäminen on erittäin helppoa verkkokäyttöliittymästä.
Vastaus, joka sisältää luettelon kaikista tietyn isännän makroista, voidaan suodattaa kaavan mukaan:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Siten saamme tarvitsemamme makron tunnuksen, missä MIKROTIK_VERSION on etsimämme makron nimi. Minun tapauksessani makroa haetaan MIKROTIK_VERSIONSe, joka oli määrätty isännälle.
Itse pyyntö näyttää tältä:
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
}
muuttuja {sid} saatu toisessa vaiheessa ja sitä käytetään jatkuvasti, missä sinun on työskenneltävä API-rajapinnan kanssa.
Viimeinen 4 VAIHE - makron päivittäminen
Nyt tiedämme päivitettävän makrotunnuksen, valtuutusevästeen tai reitittimen laiteohjelmistoversion. Voit päivittää itse makron.
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} on ensimmäisessä vaiheessa saatu arvo. Esimerkissäni nykyisen mikrotik-laiteohjelmiston versio
{isäntämacroid} - arvo saatiin kolmannessa vaiheessa - päivitettävän makron tunnus.
Tulokset
Lähestymistapa ongelman ratkaisemiseen vakiotoiminnallisuudella on paljon monimutkaisempi ja pidempi. Varsinkin jos osaat ohjelmoinnin ja pystyt nopeasti lisäämään tarvittavan logiikan skriptiin.
Tämän lähestymistavan ilmeinen etu on ratkaisun "siirrettävyys" eri palvelimien välillä.
Minulle henkilökohtaisesti on outoa, että HTTP-agentti ei pääse käsiksi toisen kohteen tietoihin ja korvaa niitä pyynnön rungossa tai otsikoissa [ ].
Valmis malli voi .
Lähde: will.com