Við gerð lausnar fyrir viðskiptavin komu upp 2 verkefni sem ég vildi leysa fallega og með venjulegri Zabbix virkni.
Verkefni 1 Rekja núverandi vélbúnaðarútgáfu á Mikrotik beinum.
Verkefnið er leyst auðveldlega - með því að bæta umboðsmanni við HTTP sniðmátið. Umboðsmaðurinn fær núverandi útgáfu frá Mikrotik vefsíðunni og kveikjan ber saman núverandi útgáfu við núverandi og gefur út viðvörun ef ósamræmi er.
Þegar þú ert með 10 beina er slíkt reiknirit ekki mikilvægt, en hvað á að gera við 3000 beina? Senda 3000 beiðnir á netþjóninn? Auðvitað mun slíkt kerfi virka, en hugmyndin um 3000 beiðnir hentaði mér ekki, ég vildi finna aðra lausn. Að auki var enn galli á slíku reikniriti: hin hliðin getur talið svo fjölda beiðna frá einum IP fyrir DoS árás, þeir geta einfaldlega bannað það.
Verkefni 2 Notkun heimildarlotu í mismunandi HTTP umboðsmönnum.
Þegar umboðsmaður þarf að fá upplýsingar frá „lokuðum“ síðum í gegnum HTTP, þarf heimildarköku. Til að gera þetta er venjulega staðlað heimildareyðublað með „innskráningu / lykilorði“ pari og stillingu setuauðkennis í vafrakökunni.
En það er vandamál, það er ómögulegt að fá aðgang að gögnum annars atriðis frá einum HTTP umboðsmanni til að skipta út þessu gildi í hausnum.
Það er líka "vefskrift", það hefur aðra takmörkun, það leyfir þér ekki að fá efni til greiningar og frekari vistunar. Þú getur aðeins athugað hvort nauðsynlegar breytur séu til staðar á síðunum eða sent áður mótteknar breytur á milli vefskriftarþrepa.
Eftir að hafa hugsað aðeins um þessi verkefni ákvað ég að nota fjölvi sem eru fullkomlega sýnileg í hvaða hluta eftirlitskerfisins sem er: í sniðmátum, vélum, kveikjum eða hlutum. Og þú getur uppfært fjölva í gegnum API vefviðmótsins.
Zabbix er með góð og ítarleg API skjöl. Fyrir gagnaskipti í gegnum API er Json gagnasniðið notað. Upplýsingar má finna í .
Röð aðgerða til að fá gögnin sem við þurfum og skrá þau í fjölvi er sýnd á skýringarmyndinni hér að neðan.
Skref 1
Fyrsta skrefið getur falist í einni aðgerð eða mörgum aðgerðum. Öll helstu rökfræði er lögð í fyrstu skrefin og síðustu 3 skrefin eru þau helstu.
Í dæminu mínu var fyrsta skrefið að fá heimildakökur á PBX fyrir fyrsta verkefnið. Fyrir annað verkefnið fékk ég númer núverandi útgáfu af Mikrotik vélbúnaðar.
Vefslóð núverandi útgáfur af Mikrotik vélbúnaðar
- - Vefslóð núverandi stöðugrar útgáfu
- — Veffang núverandi LTS útgáfu
Þessi heimilisföng eru opnuð af Mikrotik búnaðinum sjálfum þegar nýjasta tiltæka fastbúnaðarútgáfan er móttekin.
Fyrsta skrefið er algjörlega einstaklingsbundið fyrir hvert tilvik og rökfræði vinnu þess getur verið mismunandi. Það veltur allt á verkefni þínu.
Þegar þú vinnur með vefforskriftir skaltu fylgjast með hvaða viðbragðsaðferð þú þarft. Fyrirsagnir HTTP svar eða sjálf тело svar án hausa?
Ef þörf er á heimildakökum, stilltu þá svaraðferðina Fyrirsagnir eins og í tilfelli Asterisk.Ef þú þarft gögn, eins og í tilviki mikrotik miðlara svar, setja Líkaminn svar án hausa.
Skref 2
Við skulum halda áfram í annað skrefið. Að fá heimildarlotu:
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 er útgáfan af JSON-RPC samskiptareglunum sem verið er að nota;
Zabbix útfærir JSON-RPC útgáfu 2.0;
- aðferð - aðferðin sem er kölluð;
- params - færibreytur sem eru sendar af aðferðinni;
- auðkenni er handahófskennt auðkenni beiðni;
- auth - auðkenningarlykill notanda; þar sem við höfum það ekki enn þá skulum við setja það á núll.
Til að vinna með API bjó ég til sérstakan reikning með takmörkuðum réttindum. Í fyrsta lagi þarftu ekki að veita aðgang að þar sem þú þarft ekki. Og í öðru lagi, fyrir útgáfu 5.0, var hægt að lesa lykilorðið sem sett var í gegnum fjölvi. Samkvæmt því, ef þú notar Zabbix stjórnanda lykilorðið, er auðvelt að stela stjórnandareikningnum.
Þetta á sérstaklega við þegar unnið er með API í gegnum þriðju aðila forskriftir og geymt skilríki til hliðar.
Frá útgáfu 5.0 er möguleiki á að fela lykilorðið sem er vistað í fjölvi.
Þegar þú býrð til sérstakan aðgang til að uppfæra gögn í gegnum API, vertu viss um að athuga hvort gögnin sem þú þarft séu tiltæk í gegnum vefviðmótið og hvort hægt sé að uppfæra þau. Ég athugaði það ekki og í langan tíma gat ég ekki skilið hvers vegna makróið sem ég þurfti var ekki sýnilegt í API.
Eftir að við höfum fengið heimild í API, höldum við áfram að fá lista yfir fjölvi.
Skref 3
API leyfir þér ekki að uppfæra fjölvi gestgjafa með nafni, þú verður fyrst að fá auðkenni fjölva. Þar að auki, til að fá lista yfir fjölvi fyrir tiltekinn gestgjafa, þarftu að vita auðkenni þessa gestgjafa og þetta er aukabeiðni. Notaðu sjálfgefið fjölvi {HOST ID} í beiðni er ekki heimilt. Ég ákvað að fara framhjá takmörkunum svona:
Ég bjó til staðbundið fjölvi með auðkenni þessa gestgjafa. Það er mjög auðvelt að finna út hýsilauðkennið frá vefviðmótinu.
Hægt er að sía svar með lista yfir öll fjölvi á tilteknum hýsli eftir mynstri:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Þannig fáum við auðkenni fjölvi sem við þurfum, hvar MIKROTIK_VERSION er nafnið á makróinu sem við erum að leita að. Í mínu tilfelli er leitað í macro MIKROTIK_VERSIONÞað sem var úthlutað til gestgjafans.
Beiðnin sjálf lítur svona út:
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
}
Breytilegt {sid} fæst í öðru skrefi og verður notað stöðugt, þar sem þú þarft að vinna með API viðmótið.
Síðasta 4 SKREF - uppfærsla á fjölvi
Nú vitum við auðkennið fjölva sem þarf að uppfæra, heimildakökuna eða fastbúnaðarútgáfu beinisins. Þú getur uppfært makróið sjálft.
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} er gildið sem fæst í fyrsta skrefi. Í dæminu mínu, útgáfan af núverandi mikrotik vélbúnaðar
{hostmacroid} - gildið var fengið í þriðja skrefi - auðkenni fjölvisins sem við erum að uppfæra.
Niðurstöður
Aðferðin við að leysa vandamálið með stöðluðum virkni er miklu flóknari og lengri. Sérstaklega ef þú kannt forritun og getur fljótt bætt nauðsynlegri rökfræði í handritið.
Augljósi kosturinn við þessa nálgun er „flutningsfærni“ lausnarinnar á milli mismunandi netþjóna.
Fyrir mig persónulega er það undarlegt að HTTP umboðsmaðurinn geti ekki fengið aðgang að gögnum annars atriðis og komið í staðinn fyrir þau í meginmáli beiðninnar eða hausum [ ].
Fullbúið sniðmát getur .
Heimild: www.habr.com