Zabbix - ຂະຫຍາຍຂອບເຂດມະຫາພາກ

ໃນເວລາທີ່ເຮັດໃຫ້ການແກ້ໄຂສໍາລັບລູກຄ້າ, 2 ວຽກງານເກີດຂຶ້ນທີ່ຂ້ອຍຕ້ອງການແກ້ໄຂທີ່ສວຍງາມແລະມີຫນ້າທີ່ Zabbix ປົກກະຕິ.

ວຽກ 1 ຕິດຕາມລຸ້ນເຟີມແວໃນເຣົາເຕີ Mikrotik.

ວຽກງານຖືກແກ້ໄຂໄດ້ງ່າຍ - ໂດຍການເພີ່ມຕົວແທນໃສ່ແມ່ແບບ HTTP. ຕົວແທນໄດ້ຮັບສະບັບປະຈຸບັນຈາກເວັບໄຊທ໌ Mikrotik, ແລະຜົນກະທົບຕໍ່ການປຽບທຽບສະບັບປະຈຸບັນກັບສະບັບປະຈຸບັນແລະອອກການແຈ້ງເຕືອນໃນກໍລະນີທີ່ມີຄວາມແຕກຕ່າງ.

ເມື່ອທ່ານມີ 10 routers, algorithm ດັ່ງກ່າວບໍ່ສໍາຄັນ, ແຕ່ຈະເຮັດແນວໃດກັບ 3000 routers? ສົ່ງ 3000 ຄໍາຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍບໍ? ແນ່ນອນ, ໂຄງການດັ່ງກ່າວຈະເຮັດວຽກ, ແຕ່ຄວາມຄິດຂອງ 3000 ຄໍາຮ້ອງຂໍບໍ່ເຫມາະສົມກັບຂ້ອຍ, ຂ້ອຍຢາກຊອກຫາວິທີແກ້ໄຂອື່ນ. ນອກຈາກນັ້ນ, ຍັງມີຂໍ້ບົກຜ່ອງໃນ algorithm ດັ່ງກ່າວ: ອີກດ້ານຫນຶ່ງສາມາດນັບຈໍານວນການຮ້ອງຂໍດັ່ງກ່າວຈາກ IP ຫນຶ່ງສໍາລັບການໂຈມຕີ DoS, ພວກເຂົາພຽງແຕ່ສາມາດຫ້າມມັນ.

ວຽກ 2 ການນໍາໃຊ້ເຊດຊັນການອະນຸຍາດໃນຕົວແທນ HTTP ທີ່ແຕກຕ່າງກັນ.

ເມື່ອຕົວແທນຕ້ອງການໄດ້ຮັບຂໍ້ມູນຈາກຫນ້າ "ປິດ" ຜ່ານ HTTP, ຄຸກກີການອະນຸຍາດແມ່ນຈໍາເປັນ. ເພື່ອເຮັດສິ່ງນີ້, ປົກກະຕິແລ້ວມີແບບຟອມການອະນຸຍາດມາດຕະຖານທີ່ມີຄູ່ "ເຂົ້າສູ່ລະບົບ / ລະຫັດຜ່ານ" ແລະກໍານົດ ID ເຊດຊັນໃນຄຸກກີ.

ແຕ່ມີບັນຫາ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າເຖິງຂໍ້ມູນຂອງລາຍການອື່ນຈາກລາຍການຕົວແທນ HTTP ຫນຶ່ງເພື່ອທົດແທນຄ່ານີ້ໃນ Header.

ຍັງມີ "ສະຄິບເວັບ", ມັນມີຂໍ້ຈໍາກັດອີກ, ມັນບໍ່ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບເນື້ອຫາສໍາລັບການວິເຄາະແລະປະຫຍັດຕື່ມອີກ. ທ່ານພຽງແຕ່ສາມາດກວດສອບການມີຕົວແປທີ່ຈໍາເປັນຢູ່ໃນຫນ້າເວັບຕ່າງໆຫຼືຜ່ານຕົວແປທີ່ໄດ້ຮັບກ່ອນຫນ້ານີ້ລະຫວ່າງຂັ້ນຕອນຂອງສະຄິບເວັບ.

ຫຼັງຈາກຄິດເລັກນ້ອຍກ່ຽວກັບວຽກງານເຫຼົ່ານີ້, ຂ້ອຍໄດ້ຕັດສິນໃຈໃຊ້ macros ທີ່ເຫັນໄດ້ຢ່າງສົມບູນໃນທຸກສ່ວນຂອງລະບົບການຕິດຕາມ: ໃນແມ່ແບບ, hosts, triggers ຫຼືລາຍການ. ແລະທ່ານສາມາດອັບເດດ macro ຜ່ານ web interface API.

Zabbix ມີເອກະສານ API ທີ່ດີແລະລະອຽດ. ສໍາລັບການແລກປ່ຽນຂໍ້ມູນຜ່ານ api, ຮູບແບບຂໍ້ມູນ Json ຖືກນໍາໃຊ້. ລາຍລະອຽດສາມາດພົບໄດ້ໃນ ເອກະສານທາງການ.

ລໍາດັບຂອງການປະຕິບັດສໍາລັບການໄດ້ຮັບຂໍ້ມູນທີ່ພວກເຮົາຕ້ອງການແລະບັນທຶກພວກມັນຢູ່ໃນມະຫາພາກແມ່ນສະແດງຢູ່ໃນແຜນວາດຂ້າງລຸ່ມນີ້.

ຂັ້ນຕອນ 1

ຂັ້ນຕອນທໍາອິດສາມາດປະກອບດ້ວຍການກະທໍາດຽວຫຼືຫຼາຍການກະທໍາ. ເຫດຜົນຕົ້ນຕໍທັງຫມົດແມ່ນວາງໄວ້ໃນຂັ້ນຕອນທໍາອິດ, ແລະ 3 ຂັ້ນຕອນສຸດທ້າຍແມ່ນຕົ້ນຕໍ.

ໃນຕົວຢ່າງຂອງຂ້ອຍ, ຂັ້ນຕອນທໍາອິດແມ່ນໄດ້ຮັບການອະນຸຍາດ cookies ໃນ PBX ສໍາລັບວຽກງານທໍາອິດ. ສໍາລັບວຽກງານທີສອງ, ຂ້ອຍໄດ້ຮັບຈໍານວນ firmware Mikrotik ຮຸ່ນປະຈຸບັນ.

URL ຂອງເຟີມແວ Mikrotik ເວີຊັນປັດຈຸບັນ

• upgrade.mikrotik.com/routeros/LATEST.6 - ທີ່ຢູ່ URL ຂອງເວີຊັນຄົງທີ່ໃນປະຈຸບັນ
• upgrade.mikrotik.com/routeros/LATEST.6fix — ທີ່​ຢູ່ URL ຂອງ​ສະ​ບັບ LTS ໃນ​ປະ​ຈຸ​ບັນ​

ທີ່ຢູ່ເຫຼົ່ານີ້ແມ່ນເຂົ້າເຖິງໄດ້ໂດຍອຸປະກອນ Mikrotik ຕົວມັນເອງເມື່ອໄດ້ຮັບເວີຊັນເຟີມແວຫຼ້າສຸດ.

ຂັ້ນຕອນທໍາອິດແມ່ນບຸກຄົນຢ່າງສົມບູນສໍາລັບແຕ່ລະກໍລະນີແລະເຫດຜົນຂອງການເຮັດວຽກຂອງມັນອາດຈະແຕກຕ່າງກັນ. ມັນທັງຫມົດແມ່ນຂຶ້ນກັບວຽກງານຂອງທ່ານ.

ເມື່ອເຮັດວຽກກັບການຂຽນເວັບ, ຕິດຕາມວິທີການຕອບສະຫນອງທີ່ທ່ານຕ້ອງການ. ຫົວຂໍ້ ການຕອບໂຕ້ HTTP ຫຼືຕົນເອງ ຮ່າງກາຍ ຕອບ​ສະ​ຫນອງ​ໂດຍ​ບໍ່​ມີ​ຫົວ​ຂໍ້​?
ຖ້າຕ້ອງການການອະນຸຍາດ cookies, ຫຼັງຈາກນັ້ນກໍານົດວິທີການຕອບສະຫນອງ ຫົວຂໍ້ ເຊັ່ນດຽວກັບກໍລະນີຂອງດາວ.

ຖ້າທ່ານຕ້ອງການຂໍ້ມູນ, ເຊັ່ນດຽວກັບໃນກໍລະນີຂອງການຕອບສະຫນອງຂອງເຄື່ອງແມ່ຂ່າຍ mikrotik, ໃສ່ ຮ່າງກາຍ ການ​ຕອບ​ສະ​ຫນອງ​ໂດຍ​ບໍ່​ມີ​ຫົວ​ຂໍ້​.

ຂັ້ນຕອນ 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;

• method — ວິ​ທີ​ການ​ທີ່​ເອີ້ນ​ວ່າ​;
• params - ຕົວກໍານົດການທີ່ຜ່ານໂດຍວິທີການ;
• id ແມ່ນຕົວລະບຸການຮ້ອງຂໍໂດຍຕົນເອງ;
• auth - ລະຫັດຢືນຢັນຜູ້ໃຊ້; ເນື່ອງຈາກພວກເຮົາບໍ່ມີມັນເທື່ອ, ໃຫ້ຕັ້ງມັນເປັນ null.

ເພື່ອເຮັດວຽກກັບ API, ຂ້ອຍສ້າງບັນຊີແຍກຕ່າງຫາກທີ່ມີສິດທິຈໍາກັດ. ປະການທໍາອິດ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງໃຫ້ການເຂົ້າເຖິງບ່ອນທີ່ທ່ານບໍ່ຈໍາເປັນຕ້ອງ. ແລະອັນທີສອງ, ກ່ອນເວີຊັນ 5.0, ລະຫັດຜ່ານທີ່ຕັ້ງຜ່ານມະຫາພາກສາມາດອ່ານໄດ້. ດັ່ງນັ້ນ, ຖ້າທ່ານໃຊ້ລະຫັດຜ່ານຂອງຜູ້ເບິ່ງແຍງລະບົບ Zabbix, ບັນຊີ admin ແມ່ນງ່າຍທີ່ຈະລັກ.

ນີ້ຈະເປັນຄວາມຈິງໂດຍສະເພາະໃນເວລາທີ່ເຮັດວຽກກັບ API ຜ່ານສະຄິບພາກສ່ວນທີສາມແລະເກັບຮັກສາຂໍ້ມູນປະຈໍາຕົວຢູ່ຂ້າງ.

ນັບຕັ້ງແຕ່ສະບັບ 5.0 ມີທາງເລືອກທີ່ຈະຊ່ອນລະຫັດຜ່ານທີ່ບັນທຶກໄວ້ໃນມະຫາພາກ.

ເມື່ອສ້າງບັນຊີແຍກຕ່າງຫາກສໍາລັບການປັບປຸງຂໍ້ມູນຜ່ານ API, ໃຫ້ແນ່ໃຈວ່າຈະກວດເບິ່ງວ່າຂໍ້ມູນທີ່ທ່ານຕ້ອງການມີຢູ່ໂດຍຜ່ານການໂຕ້ຕອບເວັບແລະວ່າມັນເປັນໄປໄດ້ທີ່ຈະປັບປຸງມັນ. ຂ້າພະເຈົ້າບໍ່ໄດ້ກວດເບິ່ງ, ແລະຫຼັງຈາກນັ້ນເປັນເວລາດົນຂ້າພະເຈົ້າບໍ່ສາມາດເຂົ້າໃຈວ່າເປັນຫຍັງມະຫາພາກທີ່ຂ້ອຍຕ້ອງການຈຶ່ງບໍ່ປາກົດຢູ່ໃນ API.

ຫຼັງຈາກທີ່ພວກເຮົາໄດ້ຮັບການອະນຸຍາດໃນ API, ພວກເຮົາດໍາເນີນການເພື່ອໃຫ້ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງ macros.

ຂັ້ນຕອນ 3

API ບໍ່ອະນຸຍາດໃຫ້ທ່ານປັບປຸງ host macro ຕາມຊື່, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງໄດ້ຮັບ macro ID. ຍິ່ງໄປກວ່ານັ້ນ, ເພື່ອໃຫ້ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງ macro ສໍາລັບເຈົ້າພາບສະເພາະ, ທ່ານຈໍາເປັນຕ້ອງຮູ້ ID ຂອງເຈົ້າພາບນີ້, ແລະນີ້ແມ່ນຄໍາຮ້ອງຂໍເພີ່ມເຕີມ. ໃຊ້ Macro ເລີ່ມຕົ້ນ {HOST ID} ໃນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແມ່ນ​ບໍ່​ໄດ້​ອະ​ນຸ​ຍາດ​ໃຫ້​. ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈຂ້າມຂໍ້ຈໍາກັດເຊັ່ນນີ້:

ຂ້ອຍສ້າງ macro ທ້ອງຖິ່ນດ້ວຍ ID ຂອງເຈົ້າພາບນີ້. ຊອກຫາ ID ເຈົ້າພາບແມ່ນງ່າຍຫຼາຍຈາກການໂຕ້ຕອບຂອງເວັບ.

ຄໍາຕອບທີ່ມີບັນຊີລາຍຊື່ຂອງ macro ທັງຫມົດໃນ host ໃດຫນຶ່ງສາມາດຖືກກັ່ນຕອງໂດຍຮູບແບບ:

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບ ID ຂອງມະຫາພາກທີ່ພວກເຮົາຕ້ອງການ, ບ່ອນທີ່ 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
}

ຕົວປ່ຽນແປງ {ຂ້າງ} ໄດ້ຮັບໃນຂັ້ນຕອນທີສອງແລະຈະຖືກນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງ, ບ່ອນທີ່ທ່ານຈໍາເປັນຕ້ອງເຮັດວຽກກັບການໂຕ້ຕອບ API.

4 ຂັ້ນຕອນສຸດທ້າຍ - ການປັບປຸງມະຫາພາກ

ຕອນນີ້ພວກເຮົາຮູ້ວ່າ macro ID ທີ່ຕ້ອງການປັບປຸງ, ຄຸກກີການອະນຸຍາດຫຼືສະບັບເຟີມແວຂອງ router. ທ່ານສາມາດປັບປຸງ macro ຕົວຂອງມັນເອງ.

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 ຂອງມະຫາພາກທີ່ພວກເຮົາກໍາລັງປັບປຸງ.

ການຄົ້ນພົບ

ວິທີການແກ້ໄຂບັນຫາທີ່ມີການທໍາງານມາດຕະຖານແມ່ນສັບສົນຫຼາຍແລະຍາວກວ່າ. ໂດຍສະເພາະຖ້າທ່ານຮູ້ຈັກການຂຽນໂປລແກລມແລະສາມາດເພີ່ມເຫດຜົນທີ່ຈໍາເປັນໃນ script ໄດ້ໄວ.

ປະໂຫຍດທີ່ຊັດເຈນຂອງວິທີການນີ້ແມ່ນ "ການພົກພາ" ຂອງການແກ້ໄຂລະຫວ່າງເຄື່ອງແມ່ຂ່າຍທີ່ແຕກຕ່າງກັນ.

ສໍາລັບຂ້າພະເຈົ້າສ່ວນບຸກຄົນ, ມັນເປັນເລື່ອງແປກທີ່ຕົວແທນ HTTP ບໍ່ສາມາດເຂົ້າເຖິງຂໍ້ມູນຂອງລາຍການອື່ນແລະທົດແທນພວກມັນຢູ່ໃນສ່ວນຄໍາຮ້ອງຂໍຫຼືສ່ວນຫົວ [ ZBXNEXT-5993].

ແມ່ແບບສໍາເລັດຮູບສາມາດ ດາວໂຫລດໃນ GitHub.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com