ການຕິດຕາມເປັນການບໍລິການ: ລະບົບໂມດູນສໍາລັບສະຖາປັດຕະຍະກໍາຈຸລະພາກ

ໃນມື້ນີ້, ນອກເຫນືອຈາກລະຫັດ monolithic, ໂຄງການຂອງພວກເຮົາປະກອບມີການບໍລິການຈຸນລະພາກຫຼາຍສິບແຫ່ງ. ພວກເຂົາແຕ່ລະຄົນຮຽກຮ້ອງໃຫ້ມີການຕິດຕາມ. ການດໍາເນີນການນີ້ໃນລະດັບດັ່ງກ່າວໂດຍໃຊ້ວິສະວະກອນ DevOps ແມ່ນມີບັນຫາ. ພວກເຮົາໄດ້ພັດທະນາລະບົບການຕິດຕາມທີ່ເຮັດວຽກເປັນການບໍລິການສໍາລັບນັກພັດທະນາ. ພວກເຂົາສາມາດຂຽນ metrics ເຂົ້າໄປໃນລະບົບການຕິດຕາມຢ່າງເປັນອິດສະຫຼະ, ນໍາໃຊ້ພວກມັນ, ສ້າງ dashboards ໂດຍອີງໃສ່ພວກມັນ, ແລະຄັດຕິດການແຈ້ງເຕືອນກັບພວກມັນທີ່ຈະຖືກກະຕຸ້ນເມື່ອຄ່າເກນຖືກບັນລຸ. ສໍາລັບວິສະວະກອນ DevOps, ພຽງແຕ່ໂຄງສ້າງພື້ນຖານແລະເອກະສານ.

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

ທີ່ຜ່ານມາ: ແຜນການແລະແຜນການ

ພວກເຮົາມາຮອດລະບົບການຕິດຕາມໃນປະຈຸບັນໄດ້ແນວໃດ? ເພື່ອຕອບຄໍາຖາມນີ້, ທ່ານຈໍາເປັນຕ້ອງໄປຫາປີ 2015. ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າຫຼັງຈາກນັ້ນ:

ພວກເຮົາມີປະມານ 24 nodes ທີ່ຮັບຜິດຊອບໃນການຕິດຕາມ. ມີຊຸດທັງຫມົດຂອງເຮືອນຍອດທີ່ແຕກຕ່າງກັນ, scripts, daemon ທີ່ somehow ຕິດຕາມກວດກາບາງສິ່ງບາງຢ່າງ, ສົ່ງຂໍ້ຄວາມ, ແລະປະຕິບັດຫນ້າ. ພວກ​ເຮົາ​ຄິດ​ວ່າ​ພວກ​ເຮົາ​ຕໍ່​ໄປ​ນີ້​, ລະ​ບົບ​ດັ່ງ​ກ່າວ​ຈະ​ເປັນ​ໄປ​ໄດ້​ຫນ້ອຍ​. ມັນບໍ່ມີຈຸດໃດໃນການພັດທະນາມັນ: ມັນຫຍຸ້ງຍາກເກີນໄປ.
ພວກເຮົາໄດ້ຕັດສິນໃຈເລືອກອົງປະກອບການຕິດຕາມເຫຼົ່ານັ້ນທີ່ພວກເຮົາຈະຮັກສາແລະພັດທະນາ, ແລະສິ່ງທີ່ພວກເຮົາຈະປະຖິ້ມ. ມີ 19 ອັນ. ມີພຽງແຕ່ graphites, ລວບລວມແລະ Grafana ເປັນ dashboard ຍັງຄົງ. ແຕ່ລະບົບໃຫມ່ຈະມີລັກສະນະແນວໃດ? ແບບນີ້:

ພວກ​ເຮົາ​ມີ​ການ​ເກັບ​ຮັກ​ສາ metrics​: ເຫຼົ່າ​ນີ້​ແມ່ນ graphites​, ເຊິ່ງ​ຈະ​ອີງ​ໃສ່​ການ​ຂັບ SSD ໄວ​, ເຫຼົ່າ​ນີ້​ແມ່ນ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​ລວມ​ສໍາ​ລັບ​ການ​ວັດ​ແທກ​. ຕໍ່ໄປ - Grafana ສໍາລັບການສະແດງ dashboards ແລະ Moira ສໍາລັບການແຈ້ງເຕືອນ. ພວກເຮົາຍັງຕ້ອງການຢາກພັດທະນາລະບົບສໍາລັບການຊອກຫາຄວາມຜິດປົກກະຕິ.

ມາດຕະຖານ: ການຕິດຕາມ 2.0

ນີ້ແມ່ນສິ່ງທີ່ແຜນການເບິ່ງຄືວ່າໃນປີ 2015. ແຕ່ພວກເຮົາຕ້ອງກະກຽມບໍ່ພຽງແຕ່ໂຄງສ້າງພື້ນຖານແລະການບໍລິການເທົ່ານັ້ນ, ແຕ່ຍັງເປັນເອກະສານສໍາລັບມັນ. ພວກເຮົາໄດ້ພັດທະນາມາດຕະຖານຂອງບໍລິສັດສໍາລັບຕົວເຮົາເອງ, ເຊິ່ງພວກເຮົາເອີ້ນວ່າການຕິດຕາມ 2.0. ຂໍ້ກໍານົດສໍາລັບລະບົບແມ່ນຫຍັງ?

• ມີຄົງທີ່;
• metrics storage interval = 10 ວິນາທີ;
• ການເກັບຮັກສາໂຄງສ້າງຂອງ metrics ແລະ dashboards;
• SLA > 99,99%
• ການເກັບກໍາຕົວຊີ້ບອກເຫດການຜ່ານ UDP (!).

ພວກເຮົາຕ້ອງການ UDP ເພາະວ່າພວກເຮົາມີການຈະລາຈອນຂະຫນາດໃຫຍ່ແລະເຫດການທີ່ສ້າງ metrics. ຖ້າທ່ານຂຽນພວກມັນທັງຫມົດເຂົ້າໄປໃນ graphite ໃນເວລາດຽວກັນ, ການເກັບຮັກສາຈະຍຸບລົງ. ພວກເຮົາຍັງໄດ້ເລືອກຄໍານໍາຫນ້າລະດັບທໍາອິດສໍາລັບທຸກ metrics.

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

ປະຈຸບັນ: ແຜນວາດການໂຕ້ຕອບຂອງອົງປະກອບການຕິດຕາມ

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາຕິດຕາມແອັບພລິເຄຊັນ: ລະຫັດ PHP, ແອັບພລິເຄຊັນແລະບໍລິການຈຸລະພາກຂອງພວກເຮົາ - ໃນສັ້ນ, ທຸກສິ່ງທຸກຢ່າງທີ່ນັກພັດທະນາຂອງພວກເຮົາຂຽນ. ຄໍາຮ້ອງສະຫມັກທັງຫມົດສົ່ງ metrics ຜ່ານ UDP ໄປຫາ Brubeck aggregator (statsd, rewritten in C). ມັນໄດ້ກາຍມາເປັນໄວທີ່ສຸດໃນການທົດສອບສັງເຄາະ. ແລະມັນສົ່ງ metrics ລວມແລ້ວໄປຫາ Graphite ຜ່ານ TCP.

ມັນມີປະເພດຂອງການວັດແທກທີ່ເອີ້ນວ່າ timers. ນີ້ແມ່ນສິ່ງທີ່ສະດວກຫຼາຍ. ຕົວຢ່າງ, ສໍາລັບການເຊື່ອມຕໍ່ຜູ້ໃຊ້ແຕ່ລະຄົນກັບການບໍລິການ, ທ່ານສົ່ງ metric ທີ່ມີເວລາຕອບສະຫນອງກັບ Brubeck. 10 ລ້ານຄໍາຕອບເຂົ້າມາ, ແຕ່ຜູ້ລວບລວມຂໍ້ມູນກັບຄືນມາພຽງແຕ່ 4 metrics. ທ່ານມີຈໍານວນຄົນທີ່ເຂົ້າມາ, ສູງສຸດ, ຕໍາ່ສຸດທີ່ແລະເວລາຕອບສະຫນອງສະເລ່ຍ, ປານກາງແລະ XNUMX ເປີເຊັນ. ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນຈະຖືກໂອນໄປ Graphite ແລະພວກເຮົາເຫັນວ່າມັນມີຊີວິດຢູ່ທັງຫມົດ.

ພວກເຮົາຍັງມີການລວບລວມສໍາລັບ metrics ກ່ຽວກັບຮາດແວ, ຊອບແວ, metrics ລະບົບແລະລະບົບການຕິດຕາມ Munin ເກົ່າຂອງພວກເຮົາ (ມັນເຮັດວຽກສໍາລັບພວກເຮົາຈົນກ່ວາ 2015). ພວກເຮົາເກັບກໍາທັງຫມົດນີ້ໂດຍຜ່ານ daemon C's CollectD (ມັນມີຊໍ່ທັງຫມົດຂອງ plugins ທີ່ແຕກຕ່າງກັນທີ່ສ້າງຂຶ້ນໃນມັນ, ມັນສາມາດສໍາຫຼວດຊັບພະຍາກອນທັງຫມົດຂອງລະບົບເຈົ້າພາບທີ່ມັນຖືກຕິດຕັ້ງ, ພຽງແຕ່ລະບຸໃນການຕັ້ງຄ່າບ່ອນທີ່ຈະຂຽນຂໍ້ມູນ) ແລະ ຂຽນຂໍ້ມູນໃສ່ Graphite ຜ່ານມັນ. ມັນຍັງສະຫນັບສະຫນູນ plugins python ແລະ shell scripts, ດັ່ງນັ້ນທ່ານສາມາດຂຽນການແກ້ໄຂທີ່ກໍາຫນົດເອງຂອງທ່ານເອງ: CollectD ຈະເກັບກໍາຂໍ້ມູນນີ້ຈາກເຈົ້າພາບທ້ອງຖິ່ນຫຼືຫ່າງໄກສອກຫຼີກ (ສົມມຸດວ່າ Curl) ແລະສົ່ງໄປທີ່ Graphite.

ຫຼັງຈາກນັ້ນ, ພວກເຮົາສົ່ງ metrics ທັງຫມົດທີ່ພວກເຮົາເກັບກໍາໄປຫາ Carbon-c-relay. ນີ້ແມ່ນການແກ້ໄຂ Carbon Relay ຈາກ Graphite, ດັດແກ້ໃນ C. ນີ້ແມ່ນ router ທີ່ລວບລວມທຸກ metrics ທີ່ພວກເຮົາສົ່ງຈາກຕົວລວບລວມຂອງພວກເຮົາແລະນໍາທາງໄປຫາ nodes. ນອກຈາກນີ້ຢູ່ໃນຂັ້ນຕອນຂອງເສັ້ນທາງ, ມັນກວດເບິ່ງຄວາມຖືກຕ້ອງຂອງ metrics. ກ່ອນອື່ນ ໝົດ, ພວກເຂົາຕ້ອງສອດຄ່ອງກັບໂຄງການ ຄຳ ນຳ ໜ້າ ທີ່ຂ້າພະເຈົ້າໄດ້ສະແດງກ່ອນ ໜ້າ ນີ້ແລະອັນທີສອງ, ພວກມັນຖືກຕ້ອງ ສຳ ລັບ graphite. ຖ້າບໍ່ດັ່ງນັ້ນພວກເຂົາຈະລຸດລົງ.

ຫຼັງຈາກນັ້ນ, Carbon-c-relay ຈະສົ່ງ metrics ໄປຫາກຸ່ມ Graphite. ພວກເຮົາໃຊ້ Carbon-cache, ຂຽນຄືນໃນ Go, ເປັນການເກັບຮັກສາຫຼັກຂອງ metrics. Go-carbon, ເນື່ອງຈາກ multithreading ຂອງມັນ, ມີປະສິດທິພາບດີກວ່າ Carbon-cache. ມັນໄດ້ຮັບຂໍ້ມູນແລະຂຽນມັນໃສ່ແຜ່ນໂດຍໃຊ້ຊຸດກະຊິບ (ມາດຕະຖານ, ຂຽນໃນ python). ເພື່ອອ່ານຂໍ້ມູນຈາກການເກັບຮັກສາຂອງພວກເຮົາ, ພວກເຮົາໃຊ້ Graphite API. ມັນໄວກວ່າເວັບ Graphite ມາດຕະຖານຫຼາຍ. ຈະເກີດຫຍັງຂຶ້ນກັບຂໍ້ມູນຕໍ່ໄປ?

ພວກເຂົາໄປ Grafana. ພວກເຮົາໃຊ້ກຸ່ມ graphite ຂອງພວກເຮົາເປັນແຫລ່ງຂໍ້ມູນຕົ້ນຕໍ, ບວກກັບພວກເຮົາມີ Grafana ເປັນຕົວເຊື່ອມຕໍ່ເວັບສໍາລັບການສະແດງ metrics ແລະ dashboards ການກໍ່ສ້າງ. ສໍາລັບແຕ່ລະບໍລິການຂອງພວກເຂົາ, ນັກພັດທະນາສ້າງ dashboard ຂອງຕົນເອງ. ຫຼັງຈາກນັ້ນ, ພວກເຂົາສ້າງກາຟໂດຍອີງໃສ່ພວກມັນ, ເຊິ່ງສະແດງຕົວຊີ້ວັດທີ່ພວກເຂົາຂຽນຈາກຄໍາຮ້ອງສະຫມັກຂອງພວກເຂົາ. ນອກເຫນືອໄປຈາກ Grafana, ພວກເຮົາຍັງມີ SLAM. ນີ້ແມ່ນ python demon ທີ່ຄິດໄລ່ SLA ໂດຍອີງໃສ່ຂໍ້ມູນຈາກ graphite. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາແລ້ວ, ພວກເຮົາມີບໍລິການຈຸລະພາກຫຼາຍສິບ, ແຕ່ລະອັນມີຄວາມຕ້ອງການຂອງຕົນເອງ. ການນໍາໃຊ້ SLAM, ພວກເຮົາໄປຫາເອກະສານແລະປຽບທຽບກັບສິ່ງທີ່ຢູ່ໃນ Graphite ແລະປຽບທຽບວ່າຂໍ້ກໍານົດທີ່ກົງກັບຄວາມພ້ອມຂອງການບໍລິການຂອງພວກເຮົາ.

ໃຫ້ໄປຕື່ມອີກ: ເຕືອນ. ມັນໄດ້ຖືກຈັດຕັ້ງໂດຍໃຊ້ລະບົບທີ່ເຂັ້ມແຂງ - Moira. ມັນເປັນເອກະລາດເນື່ອງຈາກວ່າມັນມີ Graphite ຂອງຕົນເອງພາຍໃຕ້ hood ໄດ້. ພັດທະນາໂດຍ guys ຈາກ SKB "Kontur", ຂຽນໃນ python ແລະ Go, ແຫຼ່ງເປີດຢ່າງສົມບູນ. Moira ໄດ້ຮັບການໄຫຼດຽວກັນທີ່ເຂົ້າໄປໃນ graphites. ຖ້າບາງເຫດຜົນບ່ອນເກັບຂໍ້ມູນຂອງທ່ານຕາຍ, ການແຈ້ງເຕືອນຂອງທ່ານຈະຍັງເຮັດວຽກຢູ່.

ພວກເຮົາໄດ້ນຳໃຊ້ Moira ໃນ Kubernetes; ມັນໃຊ້ກຸ່ມເຊີບເວີ Redis ເປັນຖານຂໍ້ມູນຫຼັກ. ຜົນໄດ້ຮັບແມ່ນລະບົບທີ່ທົນທານຕໍ່ຄວາມຜິດ. ມັນປຽບທຽບກະແສຂອງ metrics ກັບບັນຊີລາຍຊື່ຂອງ triggers: ຖ້າບໍ່ມີການກ່າວເຖິງໃນມັນ, ຫຼັງຈາກນັ້ນມັນຈະຫຼຸດລົງ metric. ສະນັ້ນມັນສາມາດຍ່ອຍ gigabytes ຂອງ metrics ຕໍ່ນາທີ.

ພວກເຮົາຍັງໄດ້ຄັດຕິດ LDAP ຂອງບໍລິສັດກັບມັນ, ດ້ວຍການຊ່ວຍເຫຼືອຂອງແຕ່ລະຜູ້ໃຊ້ຂອງລະບົບບໍລິສັດສາມາດສ້າງການແຈ້ງເຕືອນສໍາລັບຕົນເອງໂດຍອີງໃສ່ຜົນກະທົບຕໍ່ທີ່ມີຢູ່ແລ້ວ (ຫຼືສ້າງໃຫມ່). ເນື່ອງຈາກ Moira ປະກອບດ້ວຍ Graphite, ມັນສະຫນັບສະຫນູນຄຸນນະສົມບັດທັງຫມົດ. ດັ່ງນັ້ນທໍາອິດທ່ານເອົາເສັ້ນແລະຄັດລອກມັນເຂົ້າໄປໃນ Grafana. ເບິ່ງວິທີການສະແດງຂໍ້ມູນໃນກາຟ. ແລະຫຼັງຈາກນັ້ນທ່ານເອົາເສັ້ນດຽວກັນແລະຄັດລອກມັນເຂົ້າໄປໃນ Moira. ທ່ານວາງມັນດ້ວຍຂອບເຂດຈໍາກັດແລະໄດ້ຮັບການເຕືອນຢູ່ທີ່ຜົນຜະລິດ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານບໍ່ຈໍາເປັນຕ້ອງມີຄວາມຮູ້ສະເພາະ. Moira ສາມາດແຈ້ງເຕືອນຜ່ານ SMS, ອີເມລ໌, Jira, Slack... ມັນຍັງສະຫນັບສະຫນູນການປະຕິບັດຂອງສະຄິບທີ່ກໍາຫນົດເອງ. ເມື່ອ trigger ເກີດຂຶ້ນກັບນາງ, ແລະນາງຖືກສະຫມັກເປັນສະຄິບທີ່ກໍາຫນົດເອງຫຼືຖານສອງ, ນາງແລ່ນມັນແລະສົ່ງ JSON ໄປ stdin ສໍາລັບສອງນີ້. ຕາມນັ້ນແລ້ວ, ໂຄງການຂອງເຈົ້າຕ້ອງແຍກມັນ. ສິ່ງທີ່ທ່ານຈະເຮັດກັບ JSON ນີ້ແມ່ນຂຶ້ນກັບທ່ານ. ຖ້າທ່ານຕ້ອງການ, ສົ່ງໄປທີ່ Telegram, ຖ້າທ່ານຕ້ອງການ, ເປີດວຽກໃນ Jira, ເຮັດໃດກໍ່ຕາມ.

ພວກເຮົາຍັງໃຊ້ການພັດທະນາຂອງຕົນເອງສໍາລັບການແຈ້ງເຕືອນ - Imagotag. ພວກເຮົາດັດແປງກະດານ, ເຊິ່ງປົກກະຕິແລ້ວແມ່ນໃຊ້ສໍາລັບປ້າຍລາຄາເອເລັກໂຕຣນິກໃນຮ້ານ, ໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງພວກເຮົາ. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ເອົາ​ຜົນ​ກະ​ທົບ​ຈາກ Moira ກັບ​ມັນ​. ມັນຊີ້ບອກວ່າພວກເຂົາຢູ່ໃນລັດໃດແລະເວລາໃດທີ່ພວກເຂົາເກີດຂື້ນ. ຜູ້ພັດທະນາບາງຄົນປະຖິ້ມການແຈ້ງເຕືອນໃນ Slack ແລະອີເມລ໌ເພື່ອສະຫນັບສະຫນູນກະດານນີ້.

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

ອົງປະກອບການຕິດຕາມ

ນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງການເຊື່ອມຕໍ່ກັບອົງປະກອບທີ່ພວກເຮົາໃຊ້ສໍາລັບວຽກງານນີ້. ທັງຫມົດຂອງພວກເຂົາແມ່ນແຫຼ່ງເປີດ.

Graphite:

• go-carbon: github.com/lomik/go-carbon
• ກະຊິບ: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

Carbon-c-Relay:

github.com/grobian/carbon-c-relay

Brubeck:

github.com/github/brubeck

ເກັບກໍາ:

collection.org

Moira:

github.com/moira-alert

Grafana:

grafana.com

Heapster:

github.com/kubernetes/heapster

ສະຖິຕິ

ແລະນີ້ແມ່ນຕົວເລກບາງຢ່າງກ່ຽວກັບວິທີການເຮັດວຽກສໍາລັບພວກເຮົາ.

ຕົວລວບລວມ (brubeck)

ຈໍານວນການວັດແທກ: ~300/ວິນາທີ
ໄລຍະຫ່າງສໍາລັບການສົ່ງ metrics ກັບ Graphite: 30 ວິນາທີ
ການນໍາໃຊ້ຊັບພະຍາກອນຂອງເຄື່ອງແມ່ຂ່າຍ: ~ 6% CPU (ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍທີ່ເຕັມໄປດ້ວຍຄວາມສາມາດ); ~ 1Gb RAM; ~ 3 Mbps LAN

Graphite (ໄປ-ຄາບອນ)

ຈໍານວນ metrics: ~ 1 / min
ໄລຍະການອັບເດດເມຕຣິກ: 30 ວິນາທີ
ຮູບແບບການເກັບຮັກສາເມຕຣິກ: 30sec 35d, 5min 90d, 10min 365d (ໃຫ້ທ່ານເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນກັບການບໍລິການໃນໄລຍະເວລາດົນນານ)
ການນໍາໃຊ້ຊັບພະຍາກອນຂອງເຄື່ອງແມ່ຂ່າຍ: CPU ~10%; ~ 20Gb RAM; ~30 Mbps LAN

ຢືດຢຸ່ນ

ພວກເຮົາຢູ່ Avito ກໍ່ໃຫ້ຄຸນຄ່າຄວາມຍືດຫຍຸ່ນໃນການບໍລິການຕິດຕາມຂອງພວກເຮົາ. ເປັນຫຍັງລາວຈຶ່ງກາຍເປັນແບບນີ້? ປະການທໍາອິດ, ອົງປະກອບຂອງມັນແມ່ນສາມາດແລກປ່ຽນກັນໄດ້: ທັງອົງປະກອບຂອງຕົນເອງແລະສະບັບຂອງເຂົາເຈົ້າ. ອັນທີສອງ, ການສະຫນັບສະຫນູນ. ເນື່ອງຈາກໂຄງການທັງຫມົດແມ່ນແຫຼ່ງເປີດ, ທ່ານສາມາດແກ້ໄຂລະຫັດຕົວທ່ານເອງ, ປ່ຽນແປງແລະປະຕິບັດຫນ້າທີ່ທີ່ບໍ່ມີຢູ່ໃນກ່ອງ. stacks ທົ່ວໄປຂ້ອນຂ້າງຖືກນໍາໃຊ້, ສ່ວນໃຫຍ່ແມ່ນ Go ແລະ Python, ສະນັ້ນນີ້ແມ່ນເຮັດໄດ້ຂ້ອນຂ້າງງ່າຍດາຍ.

ນີ້ແມ່ນຕົວຢ່າງຂອງບັນຫາທີ່ແທ້ຈິງ. metric ໃນ Graphite ແມ່ນໄຟລ໌. ມັນມີຊື່. ຊື່ໄຟລ໌ = ຊື່ metric. ແລະ​ມີ​ທາງ​ທີ່​ຈະ​ໄປ​ເຖິງ​ທີ່​ນັ້ນ​. ຊື່ໄຟລ໌ໃນ Linux ແມ່ນຈໍາກັດ 255 ຕົວອັກສອນ. ແລະພວກເຮົາມີ (ເປັນ "ລູກຄ້າພາຍໃນ") guys ຈາກພະແນກຖານຂໍ້ມູນ. ພວກເຂົາບອກພວກເຮົາວ່າ: "ພວກເຮົາຕ້ອງການຕິດຕາມການສອບຖາມ SQL ຂອງພວກເຮົາ. ແລະພວກມັນບໍ່ແມ່ນ 255 ຕົວອັກສອນ, ແຕ່ 8 MB ແຕ່ລະຄົນ. ພວກເຮົາຕ້ອງການສະແດງໃຫ້ພວກເຂົາຢູ່ໃນ Grafana, ເບິ່ງຕົວກໍານົດການສໍາລັບການຮ້ອງຂໍນີ້, ແລະດີກວ່າ, ພວກເຮົາຕ້ອງການເບິ່ງດ້ານເທິງຂອງຄໍາຮ້ອງຂໍດັ່ງກ່າວ. ມັນຈະດີຖ້າມັນຖືກສະແດງໃນເວລາຈິງ. ມັນຈະເປັນການດີແທ້ໆທີ່ຈະໃຫ້ພວກເຂົາຢູ່ໃນການແຈ້ງເຕືອນ.”

ຕົວຢ່າງ SQL query ແມ່ນເອົາເປັນຕົວຢ່າງຈາກ ເວັບໄຊທ໌ postgrespro.ru

ພວກເຮົາຕັ້ງເຄື່ອງແມ່ຂ່າຍ Redis ແລະໃຊ້ plugins ຂອງພວກເຮົາທີ່ລວບລວມ, ເຊິ່ງໄປຫາ Postgres ແລະເອົາຂໍ້ມູນທັງຫມົດຈາກບ່ອນນັ້ນ, ສົ່ງ metrics ກັບ Graphite. ແຕ່ພວກເຮົາປ່ຽນຊື່ metric ດ້ວຍ hashes. ພວກເຮົາພ້ອມໆກັນສົ່ງ hash ດຽວກັນກັບ Redis ເປັນຄີ, ແລະການສອບຖາມ SQL ທັງຫມົດເປັນມູນຄ່າ. ສິ່ງທີ່ພວກເຮົາຕ້ອງເຮັດແມ່ນໃຫ້ແນ່ໃຈວ່າ Grafana ສາມາດໄປຫາ Redis ແລະເອົາຂໍ້ມູນນີ້. ພວກເຮົາກຳລັງເປີດ Graphite API ເພາະວ່າ... ນີ້ແມ່ນການໂຕ້ຕອບຕົ້ນຕໍສໍາລັບການປະຕິສໍາພັນຂອງອົງປະກອບການຕິດຕາມທັງຫມົດກັບ graphite, ແລະພວກເຮົາເຂົ້າໄປໃນຫນ້າທີ່ໃຫມ່ທີ່ມີຊື່ວ່າ aliasByHash() - ຈາກ Grafana ພວກເຮົາໄດ້ຮັບຊື່ຂອງ metric, ແລະໃຊ້ມັນຢູ່ໃນຄໍາຮ້ອງຂໍ Redis ເປັນກຸນແຈ, ໃນ ການຕອບສະ ໜອງ ພວກເຮົາໄດ້ຮັບມູນຄ່າຂອງລະຫັດ, ເຊິ່ງແມ່ນ "SQL query" ຂອງພວກເຮົາ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ສະແດງຢູ່ໃນ Grafana ການສະແດງການສອບຖາມ SQL, ເຊິ່ງໃນທາງທິດສະດີບໍ່ສາມາດສະແດງຢູ່ທີ່ນັ້ນ, ພ້ອມກັບສະຖິຕິກ່ຽວກັບມັນ (ໂທ, ແຖວ, Total_time, ... ).

ຜົນໄດ້ຮັບ

ຄວາມພ້ອມ ການບໍລິການຕິດຕາມຂອງພວກເຮົາແມ່ນມີຢູ່ 24/7 ຈາກທຸກແອັບພລິເຄຊັນ ແລະລະຫັດໃດໆ. ຖ້າທ່ານມີການເຂົ້າເຖິງສະຖານທີ່ເກັບຮັກສາ, ທ່ານສາມາດຂຽນຂໍ້ມູນໃສ່ບໍລິການ. ພາສາບໍ່ສໍາຄັນ, ການຕັດສິນໃຈບໍ່ສໍາຄັນ. ທ່ານພຽງແຕ່ຕ້ອງການຮູ້ວິທີການເປີດເຕົ້າຮັບ, ເອົາ metric ຢູ່ທີ່ນັ້ນແລະປິດເຕົ້າຮັບ.

ຄວາມຫນ້າເຊື່ອຖື ອົງປະກອບທັງຫມົດແມ່ນມີຄວາມທົນທານຕໍ່ຄວາມຜິດແລະຈັດການກັບການໂຫຼດຂອງພວກເຮົາໄດ້ດີ.

ອຸປະສັກຕໍ່າຕໍ່ການເຂົ້າ. ເພື່ອໃຊ້ລະບົບນີ້, ທ່ານບໍ່ຈໍາເປັນຕ້ອງຮຽນຮູ້ພາສາການຂຽນໂປລແກລມແລະການສອບຖາມໃນ Grafana. ພຽງ​ແຕ່​ເປີດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​, ໃສ່​ເຕົ້າ​ຮັບ​ເຂົ້າ​ໄປ​ໃນ​ມັນ​ທີ່​ຈະ​ສົ່ງ metrics ກັບ Graphite​, ປິດ​ມັນ​, ເປີດ Grafana​, ສ້າງ dashboards ມີ​ແລະ​ເບິ່ງ​ພຶດ​ຕິ​ກໍາ​ຂອງ metrics ຂອງ​ທ່ານ​, ໄດ້​ຮັບ​ການ​ແຈ້ງ​ການ​ຜ່ານ Moira​.

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

ພວກເຮົາມີຈຸດປະສົງຫຍັງ?

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

1. ເຄື່ອງກວດຈັບຜິດປົກກະຕິ. ພວກເຮົາຕ້ອງການສ້າງການບໍລິການທີ່ຈະໄປຫາບ່ອນເກັບມ້ຽນ Graphite ຂອງພວກເຮົາແລະກວດເບິ່ງແຕ່ລະ metric ໂດຍໃຊ້ algorithms ຕ່າງໆ. ມີ algorithms ແລ້ວທີ່ພວກເຮົາຕ້ອງການເບິ່ງ, ມີຂໍ້ມູນ, ພວກເຮົາຮູ້ວິທີການເຮັດວຽກກັບມັນ.
2. ເມຕາເດຕາ. ພວກເຮົາມີຫຼາຍບໍລິການ, ເຂົາເຈົ້າປ່ຽນແປງຕາມເວລາ, ຄືກັນກັບຄົນທີ່ເຮັດວຽກກັບເຂົາເຈົ້າ. ການຮັກສາເອກະສານດ້ວຍຕົນເອງຢ່າງຕໍ່ເນື່ອງບໍ່ແມ່ນທາງເລືອກ. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາໃນປັດຈຸບັນຝັງ metadata ເຂົ້າໄປໃນ microservices ຂອງພວກເຮົາ. ມັນບອກວ່າຜູ້ທີ່ພັດທະນາມັນ, ພາສາທີ່ມັນພົວພັນກັບ, ຄວາມຕ້ອງການ SLA, ການແຈ້ງເຕືອນຄວນຖືກສົ່ງໄປໃສແລະໃຜ. ເມື່ອນຳໃຊ້ການບໍລິການ, ຂໍ້ມູນທັງໝົດແມ່ນສ້າງເປັນເອກະລາດ. ດັ່ງນັ້ນ, ທ່ານໄດ້ຮັບສອງເຊື່ອມຕໍ່ - ຫນຶ່ງເພື່ອກະຕຸ້ນ, ອີກອັນຫນຶ່ງໄປຫາ dashboards ໃນ Grafana.
3. ຕິດ​ຕາມ​ກວດ​ກາ​ໃນ​ທຸກ​ບ້ານ​. ພວກເຮົາເຊື່ອວ່ານັກພັດທະນາທຸກຄົນຄວນໃຊ້ລະບົບດັ່ງກ່າວ. ໃນກໍລະນີນີ້, ທ່ານສະເຫມີເຂົ້າໃຈບ່ອນທີ່ການຈະລາຈອນຂອງເຈົ້າຢູ່, ສິ່ງທີ່ເກີດຂື້ນກັບມັນ, ບ່ອນທີ່ມັນຕົກ, ບ່ອນທີ່ຈຸດອ່ອນຂອງມັນຢູ່. ສໍາລັບຕົວຢ່າງ, ບາງສິ່ງບາງຢ່າງມາແລະ crash ການບໍລິການຂອງທ່ານ, ຫຼັງຈາກນັ້ນທ່ານຈະຮຽນຮູ້ກ່ຽວກັບມັນບໍ່ແມ່ນໃນລະຫວ່າງການໂທຫາຈາກຜູ້ຈັດການ, ແຕ່ຈາກການແຈ້ງເຕືອນ, ແລະທ່ານສາມາດເປີດບັນທຶກຫລ້າສຸດແລະເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນຢູ່ທີ່ນັ້ນ.
4. ປະສິດທິພາບສູງ. ໂຄງການຂອງພວກເຮົາແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ, ແລະໃນມື້ນີ້ມັນດໍາເນີນການປະມານ 2 ມູນຄ່າ metric ຕໍ່ນາທີ. ປີກ່ອນຫນ້ານີ້, ຕົວເລກນີ້ແມ່ນ 000. ແລະການຂະຫຍາຍຕົວຍັງສືບຕໍ່, ແລະນີ້ຫມາຍຄວາມວ່າຫຼັງຈາກເວລາໃດຫນຶ່ງ Graphite (whisper) ຈະເລີ່ມໂຫຼດຫຼາຍລະບົບຍ່ອຍຂອງແຜ່ນ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາແລ້ວ, ລະບົບການຕິດຕາມນີ້ແມ່ນຂ້ອນຂ້າງທົ່ວໄປເນື່ອງຈາກການປ່ຽນແປງຂອງອົງປະກອບ. ບາງຄົນຮັກສາແລະຂະຫຍາຍໂຄງສ້າງພື້ນຖານຢ່າງຕໍ່ເນື່ອງໂດຍສະເພາະສໍາລັບ Graphite, ແຕ່ພວກເຮົາໄດ້ຕັດສິນໃຈໄປເສັ້ນທາງທີ່ແຕກຕ່າງກັນ: ໃຊ້ ກົດປຸ່ມ ເປັນບ່ອນເກັບມ້ຽນສໍາລັບ metrics ຂອງພວກເຮົາ. ການຫັນປ່ຽນນີ້ແມ່ນເກືອບສໍາເລັດ, ແລະໃນໄວໆນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານໃນລາຍລະອຽດເພີ່ມເຕີມວິທີການນີ້ໄດ້ເຮັດ: ຄວາມຫຍຸ້ງຍາກອັນໃດແລະວິທີການທີ່ເຂົາເຈົ້າໄດ້ຮັບການແກ້ໄຂ, ຂະບວນການການເຄື່ອນຍ້າຍໄປ, ຂ້າພະເຈົ້າຈະອະທິບາຍອົງປະກອບທີ່ຖືກເລືອກເປັນການຜູກມັດແລະການຕັ້ງຄ່າຂອງພວກເຂົາ.

ຂອບໃຈສໍາລັບຄວາມສົນໃຈຂອງທ່ານ! ຖາມຄໍາຖາມຂອງເຈົ້າກ່ຽວກັບຫົວຂໍ້, ຂ້ອຍຈະພະຍາຍາມຕອບທີ່ນີ້ຫຼືໃນຂໍ້ຄວາມຕໍ່ໄປນີ້. ບາງທີບາງຄົນມີປະສົບການສ້າງລະບົບການຕິດຕາມທີ່ຄ້າຍຄືກັນຫຼືປ່ຽນໄປ Clickhouse ໃນສະຖານະການທີ່ຄ້າຍຄືກັນ - ແບ່ງປັນມັນໃນຄໍາເຫັນ.

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