جڏهن هڪ ڪلائنٽ لاء هڪ حل ٺاهيندي، 2 ڪم پيدا ٿيا جيڪي مون کي خوبصورت ۽ باقاعده زيبڪس ڪارڪردگي سان حل ڪرڻ چاهيندا هئا.
ڪم 1. Mikrotik routers تي موجوده firmware ورجن کي ٽريڪ ڪرڻ.
ڪم آساني سان حل ڪيو ويو آهي - HTTP ٽيمپليٽ ۾ ايجنٽ شامل ڪندي. ايجنٽ Mikrotik ويب سائيٽ تان موجوده ورزن وصول ڪري ٿو، ۽ ٽرگر موجوده ورزن کي موجوده ورزن سان ڀيٽي ٿو ۽ تفاوت جي صورت ۾ الرٽ جاري ڪري ٿو.
جڏهن توهان وٽ 10 روٽرز آهن، اهڙي الگورتھم نازڪ ناهي، پر 3000 روٽرز سان ڇا ڪجي؟ سرور ڏانهن 3000 درخواستون موڪليو؟ يقينن، اهڙي اسڪيم ڪم ڪندي، پر 3000 درخواستن جو بلڪل خيال مون کي مناسب نه هو، مون کي ٻيو حل ڳولڻ چاهيو. ان کان سواء، اڃا تائين اهڙي الورورٿم ۾ هڪ خرابي هئي: ٻئي طرف هڪ ڊي ايس حملي لاء هڪ IP کان درخواستن جو تعداد شمار ڪري سگهي ٿو، اهي صرف ان تي پابندي لڳائي سگهن ٿا.
ڪم 2. مختلف HTTP ايجنٽ ۾ اختيار ڏيڻ واري سيشن کي استعمال ڪندي.
جڏهن هڪ ايجنٽ کي HTTP ذريعي "بند" صفحن مان معلومات حاصل ڪرڻ جي ضرورت آهي، هڪ اختيار جي ڪوڪي جي ضرورت آهي. هن کي ڪرڻ لاء، عام طور تي "لاگ ان / پاسورڊ" جوڙو سان گڏ هڪ معياري اختيار فارم آهي ۽ ڪوڪيز ۾ سيشن ID سيٽنگ.
پر اتي ھڪڙو مسئلو آھي، ھيڊر ۾ ھن قدر کي متبادل ڪرڻ لاء ھڪڙو HTTP ايجنٽ آئٽم کان ٻي شيء جي ڊيٽا تائين رسائي ناممڪن آھي.
هتي هڪ "ويب اسڪرپٽ" پڻ آهي، ان جي هڪ ٻي حد آهي، اها توهان کي تجزيي ۽ وڌيڪ بچت لاء مواد حاصل ڪرڻ جي اجازت ناهي. توھان صرف صفحن تي ضروري متغيرن جي موجودگي جي جانچ ڪري سگھو ٿا يا اڳ ۾ حاصل ڪيل متغيرن کي ويب اسڪرپٽ مرحلن جي وچ ۾ پاس ڪري سگھو ٿا.
انهن ڪمن جي باري ۾ ٿورڙي سوچڻ کان پوء، مون ميڪرو استعمال ڪرڻ جو فيصلو ڪيو جيڪي مڪمل طور تي نظر اچن ٿا مانيٽرنگ سسٽم جي ڪنهن به حصي ۾: ٽيمپليٽ، ميزبان، ٽارگيٽ يا شيون. ۽ توھان ويب انٽرفيس API ذريعي ميڪروز کي اپڊيٽ ڪري سگھو ٿا.
Zabbix وٽ سٺو ۽ تفصيلي API دستاويز آهي. api ذريعي ڊيٽا مٽائڻ لاءِ، Json ڊيٽا فارميٽ استعمال ڪيو ويندو آهي. تفصيل ۾ ڳولهي سگهجن ٿا .
اسان کي گهربل ڊيٽا حاصل ڪرڻ ۽ انهن کي ميڪرو ۾ رڪارڊ ڪرڻ لاءِ عملن جو سلسلو هيٺ ڏنل ڊراگرام ۾ ڏيکاريو ويو آهي.
قدم 1
بلڪل پھريون قدم ھڪڙي عمل يا گھڻن عملن تي مشتمل ٿي سگھي ٿو. سڀ مکيه منطق پهرين مرحلن ۾ رکيل آهي، ۽ آخري 3 مرحلا بنيادي آهن.
منهنجي مثال ۾، پهريون قدم پهريون ڪم لاءِ PBX تي اختياري ڪوڪيز حاصل ڪرڻ هو. ٻئي ڪم لاء، مون کي Mikrotik firmware جي موجوده ورزن جو نمبر مليو.
Mikrotik firmware جي موجوده ورزن جو URL
- - موجوده مستحڪم ورزن جو URL پتو
- - موجوده 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 لاڳو ڪري ٿو؛
- طريقو - اهو طريقو جنهن کي سڏيو ويندو آهي؛
- params - پيٽرولر جيڪي طريقي سان گذري ويا آهن؛
- id هڪ خودمختيار درخواست جي سڃاڻپ ڪندڙ آهي؛
- auth - استعمال ڪندڙ جي تصديق جي چيڪ؛ ڇاڪاڻ ته اسان وٽ اڃا تائين اهو ناهي، اچو ته ان کي null ۾ سيٽ ڪريون.
API سان ڪم ڪرڻ لاءِ، مون محدود حقن سان الڳ اڪائونٽ ٺاهيو. پهرين، توهان کي رسائي ڏيڻ جي ضرورت ناهي جتي توهان کي ضرورت ناهي. ۽ ٻيو، نسخو 5.0 کان اڳ، ميڪرو ذريعي سيٽ ڪيل پاسورڊ پڙهي سگهجي ٿو. ان جي مطابق، جيڪڏهن توهان Zabbix منتظم پاسورڊ استعمال ڪريو ٿا، منتظم اڪائونٽ چوري ڪرڻ آسان آهي.
اهو خاص طور تي صحيح ٿيندو جڏهن API سان ٽئين پارٽي اسڪرپٽ ذريعي ڪم ڪري رهيو آهي ۽ پاسن تي سندون محفوظ ڪري رهيو آهي.
ورشن 5.0 کان وٺي، اتي ھڪڙو اختيار آھي لڪائڻ لاء پاسورڊ محفوظ ٿيل ميڪرو ۾.
جڏهن API ذريعي ڊيٽا کي اپڊيٽ ڪرڻ لاءِ هڪ الڳ اڪائونٽ ٺاهيو، پڪ ڪريو ته ڇا توهان کي گهربل ڊيٽا ويب انٽرفيس ذريعي دستياب آهي ۽ ڇا ان کي اپڊيٽ ڪرڻ ممڪن آهي. مون چيڪ نه ڪيو، ۽ پوءِ گهڻي وقت تائين مان سمجهي نه سگهيو آهيان ته مون کي گهربل ميڪرو ڇو API ۾ نظر نه آيو.
اسان کي API ۾ اختيار حاصل ڪرڻ کان پوء، اسان ميڪرو جي فهرست حاصل ڪرڻ لاء اڳتي وڌو.
قدم 3
API توهان کي نالي سان ميزبان ميڪرو کي اپڊيٽ ڪرڻ جي اجازت نٿو ڏئي، توهان کي پهريان ميڪرو ID حاصل ڪرڻ گهرجي. ان کان علاوه، هڪ مخصوص ميزبان لاء ميڪرو جي فهرست حاصل ڪرڻ لاء، توهان کي ڄاڻڻ جي ضرورت آهي هن ميزبان جي ID، ۽ هي هڪ اضافي درخواست آهي. ڊفالٽ ميڪرو استعمال ڪريو {ميزبان جي سڃاڻپ} درخواست ۾ اجازت نه آهي. مون هن طرح جي پابندي کي نظرانداز ڪرڻ جو فيصلو ڪيو:
مون هن ميزبان جي ID سان مقامي ميڪرو ٺاهيو. ويب انٽرفيس مان ميزبان ID ڳولڻ تمام آسان آهي.
ڏنل ميزبان تي سڀني ميڪرو جي فهرست سان جواب هڪ نموني سان فلٽر ڪري سگهجي ٿو:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
ان ڪري، اسان کي ميڪرو جي سڃاڻپ ملي ٿي، جتي اسان کي ضرورت آهي MIKROTIK_VERSION macro جو نالو آھي جنھن کي اسين ڳولي رھيا آھيون. منهنجي حالت ۾، ميڪرو ڳولهيو ويو آهي 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 firmware جو نسخو
{hostmacroid} - قدر حاصل ڪئي وئي ٽئين قدم ۾ - ميڪرو جي سڃاڻپ جيڪا اسان تازه ڪاري ڪري رهيا آهيون.
پهچڻ
معياري ڪارڪردگي سان مسئلو حل ڪرڻ جو طريقو گهڻو وڌيڪ پيچيده ۽ ڊگهو آهي. خاص طور تي جيڪڏهن توهان پروگرامنگ ڄاڻو ٿا ۽ جلدي اسڪرپٽ ۾ ضروري منطق شامل ڪري سگهو ٿا.
هن طريقي جو واضح فائدو مختلف سرورن جي وچ ۾ حل جي "پورٽيبلٽي" آهي.
منهنجي لاءِ ذاتي طور تي، اها عجيب ڳالهه آهي ته HTTP ايجنٽ ڪنهن ٻئي شيءِ جي ڊيٽا تائين رسائي نٿو ڪري سگهي ۽ انهن کي درخواست واري جسم يا هيڊر ۾ متبادل ڪري سگهي ٿو. ].
ختم ٿيل ٽيمپليٽ ڪري سگھي ٿو .
جو ذريعو: www.habr.com