Zabbix - ընդլայնելով մակրո սահմանները

Հաճախորդի համար լուծում պատրաստելիս առաջացավ 2 խնդիր, որոնք ես ուզում էի լուծել գեղեցիկ և սովորական Zabbix ֆունկցիոնալությամբ։

Առաջադրանք 1. Միկրոտիկ երթուղիչների վրա որոնվածի ընթացիկ տարբերակին հետևելը:

Խնդիրը լուծվում է հեշտությամբ՝ HTTP ձևանմուշին գործակալ ավելացնելով: Գործակալը ստանում է ընթացիկ տարբերակը Mikrotik կայքից, իսկ գործարկիչը համեմատում է ընթացիկ տարբերակը գործողի հետ և անհամապատասխանության դեպքում ահազանգում է:

Երբ ունես 10 երթուղիչ, նման ալգորիթմը կարևոր չէ, բայց ի՞նչ անել 3000 երթուղիչի հետ: Ուղարկե՞լ 3000 հարցում սերվերին: Իհարկե, նման սխեման կաշխատի, բայց 3000 հարցումների գաղափարն ինձ չէր համապատասխանում, ես ուզում էի այլ լուծում գտնել։ Բացի այդ, նման ալգորիթմի մեջ դեռ կար մի թերություն՝ մյուս կողմը կարող է մի IP-ից նման քանակի հարցումներ հաշվել DoS հարձակման համար, կարող են ուղղակի արգելել։

Առաջադրանք 2. Օգտագործելով թույլտվության սեսիա տարբեր HTTP գործակալներում:

Երբ գործակալին անհրաժեշտ է տեղեկատվություն ստանալ «փակ» էջերից HTTP-ի միջոցով, անհրաժեշտ է թույլտվության թխուկ: Դա անելու համար սովորաբար կա ստանդարտ թույլտվության ձև՝ «մուտք / գաղտնաբառ» զույգով և թխուկի մեջ սահմանելով նիստի ID-ն:

Բայց խնդիր կա, անհնար է մուտք գործել մեկ այլ նյութի տվյալներ մեկ HTTP գործակալի տարրից՝ այս արժեքը վերնագրում փոխարինելու համար:

Կա նաև «Վեբ սկրիպտ», այն ունի ևս մեկ սահմանափակում, թույլ չի տալիս բովանդակություն ստանալ վերլուծության և հետագա պահպանման համար։ Դուք կարող եք ստուգել միայն անհրաժեշտ փոփոխականների առկայությունը էջերում կամ փոխանցել նախկինում ստացված փոփոխականները վեբ սկրիպտի քայլերի միջև:

Այս առաջադրանքների մասին մի փոքր մտածելուց հետո ես որոշեցի օգտագործել մակրոներ, որոնք հիանալի տեսանելի են մոնիտորինգի համակարգի ցանկացած մասում՝ կաղապարներում, հոսթինգներում, գործարկիչներում կամ տարրերում: Եվ դուք կարող եք թարմացնել մակրոները վեբ ինտերֆեյսի API-ի միջոցով:

Zabbix-ն ունի լավ և մանրամասն API փաստաթղթեր: Api-ի միջոցով տվյալների փոխանակման համար օգտագործվում է Json տվյալների ձևաչափը: Մանրամասները կարելի է գտնել պաշտոնական փաստաթղթեր.

Մեզ անհրաժեշտ տվյալները ստանալու և դրանք մակրոյում գրանցելու գործողությունների հաջորդականությունը ներկայացված է ստորև ներկայացված դիագրամում:

Քայլ 1

Առաջին քայլը կարող է բաղկացած լինել մեկ գործողությունից կամ մի քանի գործողություններից: Ամբողջ հիմնական տրամաբանությունը դրված է առաջին քայլերում, իսկ վերջին 3 քայլերը հիմնականն են։

Իմ օրինակում առաջին քայլը PBX-ում թույլտվության թխուկներ ստանալն էր առաջին առաջադրանքի համար: Երկրորդ առաջադրանքի համար ես ստացա Mikrotik որոնվածի ընթացիկ տարբերակի համարը:

Mikrotik որոնվածի ընթացիկ տարբերակների URL

• upgrade.mikrotik.com/routeros/LATEST.6 - Ընթացիկ կայուն տարբերակի URL հասցեն
• upgrade.mikrotik.com/routeros/LATEST.6fix — Ներկայիս LTS տարբերակի URL հասցեն

Այս հասցեները հասանելի են հենց Mikrotik սարքավորման կողմից, երբ ստացվում է որոնվածի վերջին հասանելի տարբերակը:

Առաջին քայլը բոլորովին անհատական ​​է յուրաքանչյուր դեպքի համար, և դրա աշխատանքի տրամաբանությունը կարող է տարբեր լինել։ Ամեն ինչ կախված է ձեր առաջադրանքից:

Վեբ սկրիպտավորման հետ աշխատելիս հետևեք, թե պատասխանի որ մեթոդն է ձեզ անհրաժեշտ: Վերնագրեր HTTP պատասխան կամ ինքն իրեն тело պատասխան առանց վերնագրերի
Եթե ​​թույլտվության թխուկներ են անհրաժեշտ, ապա սահմանեք պատասխանի մեթոդը Վերնագրեր ինչպես Asterisk-ի դեպքում:

Եթե ​​տվյալների կարիք ունեք, ինչպես միկրոտիկ սերվերի պատասխանի դեպքում, դրեք Մարմինը պատասխան առանց վերնագրերի:

Քայլ 2

Անցնենք երկրորդ քայլին։ Թույլտվության նիստ ստանալը.

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-ը JSON-RPC արձանագրության տարբերակն է, որն օգտագործվում է.
Zabbix-ն իրականացնում է JSON-RPC տարբերակը 2.0;

• մեթոդ - մեթոդ, որը կոչվում է;
• պարամետրեր - պարամետրեր, որոնք փոխանցվում են մեթոդով.
• id-ը կամայական հարցման նույնացուցիչ է.
• վավերացում - օգտագործողի նույնականացման բանալի; քանի որ մենք դեռ չունենք, եկեք սահմանենք այն null:

API-ի հետ աշխատելու համար ես ստեղծեցի առանձին հաշիվ՝ սահմանափակ իրավունքներով: Նախ, ձեզ հարկավոր չէ մուտք գործել այնտեղ, որտեղ ձեզ հարկավոր չէ: Եվ երկրորդը, մինչև 5.0 տարբերակը, մակրոյի միջոցով սահմանված գաղտնաբառը կարելի էր կարդալ: Համապատասխանաբար, եթե դուք օգտագործում եք Zabbix ադմինիստրատորի գաղտնաբառը, ադմինիստրատորի հաշիվը հեշտ է գողանալ:

Սա հատկապես ճիշտ կլինի, երբ աշխատում եք API-ի հետ երրորդ կողմի սկրիպտների միջոցով և հավատարմագրերը կողքին պահելու դեպքում:

5.0 տարբերակից ի վեր կա մակրոյում պահպանված գաղտնաբառը թաքցնելու տարբերակ:

API-ի միջոցով տվյալների թարմացման համար առանձին հաշիվ ստեղծելիս համոզվեք, որ ստուգեք՝ արդյոք Ձեզ անհրաժեշտ տվյալները հասանելի են վեբ ինտերֆեյսի միջոցով և արդյոք հնարավոր է դրանք թարմացնել: Ես չէի ստուգում, և հետո երկար ժամանակ չէի կարողանում հասկանալ, թե ինչու ինձ անհրաժեշտ մակրոն տեսանելի չէր API-ում:

API-ում թույլտվություն ստանալուց հետո մենք սկսում ենք ստանալ մակրոների ցանկ:

Քայլ 3

API-ն թույլ չի տալիս թարմացնել հյուրընկալող մակրո անունով, նախ պետք է ստանաք մակրո ID-ն: Ավելին, կոնկրետ հոսթի համար մակրոների ցուցակ ստանալու համար անհրաժեշտ է իմանալ այս հոսթի ID-ն, և սա լրացուցիչ հարցում է։ Օգտագործեք լռելյայն մակրո {HOST ID} հարցումում չի թույլատրվում։ Ես որոշեցի շրջանցել սահմանափակումն այսպես.

Ես ստեղծեցի տեղական մակրո այս հաղորդավարի ID-ով: Հյուրընկալողի ID-ն պարզելը շատ հեշտ է վեբ ինտերֆեյսից:

Տվյալ հոսթի վրա բոլոր մակրոների ցանկով պատասխանը կարող է զտվել օրինաչափությամբ.

regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"

Այսպիսով, մենք ստանում ենք մեզ անհրաժեշտ մակրոյի ID-ն, որտեղ MIKROTIK_VERSION այն մակրոյի անունն է, որը մենք փնտրում ենք: Իմ դեպքում մակրոն որոնված է MIKROTIK_VERSIONԱյն, որը հանձնարարվել է հաղորդավարին:

Հարցումն ինքնին այսպիսի տեսք ունի.

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} ձեռք է բերվել երկրորդ քայլում և կօգտագործվի անընդհատ, որտեղ դուք պետք է աշխատեք API ինտերֆեյսի հետ:

Վերջնական 4 ՔԱՅԼ - մակրոյի թարմացում

Այժմ մենք գիտենք մակրո ID-ն, որը պետք է թարմացվի, թույլտվության քուքի կամ երթուղիչի որոնվածի տարբերակը: Դուք կարող եք թարմացնել մակրո ինքնին:

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} առաջին քայլում ստացված արժեքն է: Իմ օրինակում ներկայիս mikrotik որոնվածի տարբերակը
{hostmacroid} - արժեքը ստացվել է երրորդ քայլում՝ մակրոյի ID-ն, որը մենք թարմացնում ենք:

Արդյունքները

Ստանդարտ ֆունկցիոնալությամբ խնդիրը լուծելու մոտեցումը շատ ավելի բարդ է և ավելի երկար: Հատկապես եթե գիտեք ծրագրավորում և կարող եք արագ ավելացնել անհրաժեշտ տրամաբանությունը սցենարում։

Այս մոտեցման ակնհայտ առավելությունը տարբեր սերվերների միջև լուծման «շարժունակությունն» է։

Անձամբ ինձ համար տարօրինակ է, որ HTTP գործակալը չի ​​կարող մուտք գործել մեկ այլ նյութի տվյալներ և փոխարինել դրանք հարցման մարմնում կամ վերնագրերում [ ZBXNEXT-5993].

Ավարտված ձևանմուշը կարող է ներբեռնել GitHub-ում.

Source: www.habr.com