Zabbix - მაკრო საზღვრების გაფართოება

კლიენტისთვის გადაწყვეტის მიღებისას გაჩნდა 2 ამოცანა, რომელთა გადაჭრაც მინდოდა ლამაზად და რეგულარული Zabbix ფუნქციონირებით.

ამოცანა 1. Mikrotik მარშრუტიზატორებზე პროგრამული უზრუნველყოფის მიმდინარე ვერსიის თვალყურის დევნება.

ამოცანა მარტივად წყდება - HTTP შაბლონში აგენტის დამატებით. აგენტი იღებს მიმდინარე ვერსიას Mikrotik ვებსაიტიდან და ტრიგერი ადარებს მიმდინარე ვერსიას მიმდინარე ვერსიას და გასცემს გაფრთხილებას შეუსაბამობის შემთხვევაში.

როდესაც თქვენ გაქვთ 10 როუტერი, ასეთი ალგორითმი არ არის კრიტიკული, მაგრამ რა უნდა გააკეთოთ 3000 როუტერთან? 3000 მოთხოვნის გაგზავნა სერვერზე? რა თქმა უნდა, ასეთი სქემა იმუშავებს, მაგრამ 3000 მოთხოვნის იდეა არ მომეწონა, მინდოდა სხვა გამოსავალი მეპოვა. გარდა ამისა, ასეთ ალგორითმში ჯერ კიდევ იყო ნაკლი: მეორე მხარეს შეუძლია დათვალოს ასეთი რაოდენობის მოთხოვნა ერთი IP-დან DoS შეტევისთვის, მათ შეუძლიათ უბრალოდ აკრძალონ იგი.

ამოცანა 2. ავტორიზაციის სესიის გამოყენება სხვადასხვა HTTP აგენტებში.

როდესაც აგენტს სჭირდება ინფორმაციის მიღება „დახურული“ გვერდებიდან HTTP-ის საშუალებით, საჭიროა ავტორიზაციის ქუქი-ფაილი. ამისათვის, როგორც წესი, არსებობს ავტორიზაციის სტანდარტული ფორმა „შესვლა/პაროლი“ წყვილით და ქუქი-ფაილში სესიის ID-ის დაყენებით.

მაგრამ არის პრობლემა, შეუძლებელია სხვა ელემენტის მონაცემებზე წვდომა ერთი HTTP აგენტის ელემენტიდან ამ მნიშვნელობის ჩანაცვლებისთვის Header-ში.

ასევე არის "ვებ სკრიპტი", მას აქვს კიდევ ერთი შეზღუდვა, არ გაძლევთ საშუალებას მიიღოთ შინაარსი ანალიზისთვის და შემდგომი შენახვისთვის. თქვენ შეგიძლიათ შეამოწმოთ მხოლოდ საჭირო ცვლადების არსებობა გვერდებზე ან გადაიტანოთ ადრე მიღებული ცვლადები ვებ სკრიპტის ნაბიჯებს შორის.

ამ ამოცანებზე ცოტა ფიქრის შემდეგ გადავწყვიტე გამომეყენებინა მაკროები, რომლებიც შესანიშნავად ჩანს მონიტორინგის სისტემის ნებისმიერ ნაწილში: შაბლონებში, ჰოსტებში, ტრიგერებში ან ელემენტებში. და შეგიძლიათ მაკროების განახლება ვებ ინტერფეისის API-ის საშუალებით.

Zabbix-ს აქვს კარგი და დეტალური API დოკუმენტაცია. Api-ს საშუალებით მონაცემთა გაცვლისთვის გამოიყენება Json მონაცემთა ფორმატი. დეტალები შეგიძლიათ იხილოთ ოფიციალური დოკუმენტაცია.

ჩვენთვის საჭირო მონაცემების მისაღებად და მაკროში ჩაწერის მოქმედებების თანმიმდევრობა ნაჩვენებია ქვემოთ მოცემულ დიაგრამაზე.

ნაბიჯი 1

პირველივე ნაბიჯი შეიძლება შედგებოდეს ერთი ან რამდენიმე მოქმედებისგან. მთელი ძირითადი ლოგიკა პირველ საფეხურზეა ასახული, ბოლო 3 ნაბიჯი კი მთავარია.

ჩემს მაგალითში, პირველი ნაბიჯი იყო ავტორიზაციის ქუქიების მიღება PBX-ზე პირველი ამოცანისთვის. მეორე ამოცანისთვის მივიღე Mikrotik firmware-ის მიმდინარე ვერსიის ნომერი.

Mikrotik firmware-ის მიმდინარე ვერსიების URL

• upgrade.mikrotik.com/routeros/LATEST.6 - მიმდინარე სტაბილური ვერსიის URL მისამართი
• upgrade.mikrotik.com/routeros/LATEST.6fix — მიმდინარე LTS ვერსიის URL მისამართი

ამ მისამართებზე წვდომა ხდება თავად Mikrotik-ის აღჭურვილობით, როდესაც მიიღება უახლესი პროგრამული უზრუნველყოფის ვერსია.

პირველი ნაბიჯი არის სრულიად ინდივიდუალური თითოეული შემთხვევისთვის და მისი მუშაობის ლოგიკა შეიძლება განსხვავებული იყოს. ეს ყველაფერი დამოკიდებულია თქვენს ამოცანაზე.

ვებ სკრიპტირებასთან მუშაობისას თვალყური ადევნეთ პასუხის რომელი მეთოდი გჭირდებათ. სათაურები HTTP პასუხი ან საკუთარი თავი тело პასუხი სათაურების გარეშე?
თუ საჭიროა ავტორიზაციის ქუქი-ფაილები, დააყენეთ პასუხის მეთოდი სათაურები როგორც ასტერისკის შემთხვევაში.

თუ მონაცემები გჭირდებათ, როგორც მიკროტიკის სერვერის პასუხის შემთხვევაში, ჩადეთ სხეული პასუხი სათაურების გარეშე.

ნაბიჯი 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 არის თვითნებური მოთხოვნის იდენტიფიკატორი;
• auth - მომხმარებლის ავტორიზაციის გასაღები; რადგან ჯერ არ გვაქვს, მოდით დავაყენოთ ნულზე.

API-სთან მუშაობისთვის მე შევქმენი ცალკე ანგარიში შეზღუდული უფლებებით. პირველ რიგში, თქვენ არ გჭირდებათ წვდომა იქ, სადაც არ გჭირდებათ. და მეორეც, 5.0 ვერსიამდე, მაკროში მითითებული პაროლის წაკითხვა შეიძლებოდა. შესაბამისად, თუ იყენებთ Zabbix ადმინისტრატორის პაროლს, ადმინისტრატორის ანგარიშის მოპარვა ადვილია.

ეს განსაკუთრებით ეხება API-სთან მუშაობისას მესამე მხარის სკრიპტების მეშვეობით და რწმუნებათა სიგელების გვერდით შენახვისას.

5.0 ვერსიიდან არსებობს მაკროში შენახული პაროლის დამალვის ვარიანტი.

API-ს მეშვეობით მონაცემების განახლებისთვის ცალკე ანგარიშის შექმნისას აუცილებლად შეამოწმეთ არის თუ არა თქვენთვის საჭირო მონაცემები ვებ ინტერფეისის საშუალებით და შესაძლებელია თუ არა მისი განახლება. მე არ შევამოწმე და შემდეგ დიდი ხნის განმავლობაში ვერ მივხვდი, რატომ არ ჩანდა მაკრო, რომელიც მჭირდებოდა API-ში.

მას შემდეგ რაც მივიღებთ ავტორიზაციას API-ში, ვაგრძელებთ მაკროების სიის მიღებას.

ნაბიჯი 3

API არ გაძლევთ საშუალებას განაახლოთ მასპინძელი მაკრო სახელით, ჯერ უნდა მიიღოთ მაკრო ID. უფრო მეტიც, კონკრეტული ჰოსტის მაკროების სიის მისაღებად, თქვენ უნდა იცოდეთ ამ ჰოსტის ID და ეს არის დამატებითი მოთხოვნა. გამოიყენეთ ნაგულისხმევი მაკრო {მასპინძლის 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, რომელიც საჭიროებს განახლებას, ავტორიზაციის ქუქი ან როუტერის firmware ვერსია. შეგიძლიათ თავად განაახლოთ მაკრო.

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 firmware-ის ვერსია
{hostmacroid} - მნიშვნელობა იქნა მიღებული მესამე ეტაპზე - მაკროს ID, რომელსაც ვაახლებთ.

დასკვნები

სტანდარტული ფუნქციონირებით პრობლემის გადაჭრის მიდგომა ბევრად უფრო რთული და გრძელია. მით უმეტეს, თუ იცით პროგრამირება და შეგიძლიათ სწრაფად დაამატოთ საჭირო ლოგიკა სკრიპტში.

ამ მიდგომის აშკარა უპირატესობა არის გადაწყვეტის "პორტაბელურობა" სხვადასხვა სერვერებს შორის.

პირადად ჩემთვის უცნაურია, რომ HTTP აგენტს არ შეუძლია წვდომა სხვა ელემენტის მონაცემებზე და ჩაანაცვლოს ისინი მოთხოვნის სხეულში ან სათაურებში [ ZBXNEXT-5993].

მზა შაბლონს შეუძლია ჩამოტვირთეთ GitHub-ზე.

წყარო: www.habr.com