ພວກເຮົາຕິດຕາມກວດກາ Sportmaster - ວິທີການແລະກັບສິ່ງທີ່

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

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

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

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

ເວທີທີ່ຮ້ານຄ້າອອນໄລນ໌ຂອງພວກເຮົາດໍາເນີນການເບິ່ງຄືວ່ານີ້:

• ຫນ້າ
• ຫ້ອງການກາງ
• ຫ້ອງການຫລັງ

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

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

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

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

ໂຄງສ້າງລະບົບແລະ stack

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

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

ດັ່ງນັ້ນ, ເຂົາເຈົ້າຈຶ່ງຕັດສິນໃຈກິນຊ້າງເປັນສ່ວນໆ.

ລະບົບຂອງພວກເຮົາປະກອບດ້ວຍ:

• ຮາດແວ;
• ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ;
• ຊອບແວ;
• ພາກສ່ວນ UI ໃນຄໍາຮ້ອງສະຫມັກການຕິດຕາມ;
• metrics ທຸລະກິດ;
• ຄໍາຮ້ອງສະຫມັກປະສົມປະສານ;
• ຄວາມ​ປອດ​ໄພ​ຂໍ້​ມູນ​ຂ່າວ​ສານ​;
• ເຄືອຂ່າຍ;
• ຕົວດຸ່ນດ່ຽງການຈະລາຈອນ.

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

ດັ່ງນັ້ນ, ກ່ຽວກັບ stack ໄດ້.

ພວກເຮົາໃຊ້ຊອບແວແຫຼ່ງເປີດ. ຢູ່ສູນກາງພວກເຮົາມີ Zabbix, ເຊິ່ງພວກເຮົາໃຊ້ຕົ້ນຕໍເປັນລະບົບແຈ້ງເຕືອນ. ທຸກຄົນຮູ້ວ່າມັນເຫມາະສົມສໍາລັບການຕິດຕາມໂຄງສ້າງພື້ນຖານ. ນີ້ຫມາຍຄວາມວ່າແນວໃດ? ຢ່າງແທ້ຈິງເຫຼົ່ານັ້ນ metrics ລະດັບຕ່ໍາທີ່ທຸກບໍລິສັດທີ່ຮັກສາສູນຂໍ້ມູນຂອງຕົນເອງມີ (ແລະ Sportmaster ມີສູນຂໍ້ມູນຂອງຕົນເອງ) - ອຸນຫະພູມຂອງເຄື່ອງແມ່ຂ່າຍ, ສະຖານະຫນ່ວຍຄວາມຈໍາ, ການໂຈມຕີ, metrics ອຸປະກອນເຄືອຂ່າຍ.

ພວກເຮົາໄດ້ປະສົມປະສານ Zabbix ກັບ Telegram messenger ແລະ Microsoft Teams, ເຊິ່ງຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໃນທີມ. Zabbix ກວມເອົາຊັ້ນຂອງເຄືອຂ່າຍຕົວຈິງ, ຮາດແວແລະຊອບແວບາງຢ່າງ, ແຕ່ມັນບໍ່ແມ່ນ panacea. ພວກເຮົາເສີມຂະຫຍາຍຂໍ້ມູນນີ້ຈາກບາງບໍລິການອື່ນໆ. ຕົວຢ່າງ, ໃນລະດັບຮາດແວ, ພວກເຮົາເຊື່ອມຕໍ່ໂດຍກົງຜ່ານ API ກັບລະບົບ virtualization ຂອງພວກເຮົາແລະເກັບກໍາຂໍ້ມູນ.

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

ແຫຼ່ງຂໍ້ມູນສໍາລັບຊັ້ນອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, metrics ທຸລະກິດ, ແບ່ງອອກເປັນສາມອົງປະກອບ.

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

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

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

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

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

ຄຸນລັກສະນະອື່ນທີ່ຂາດບໍ່ໄດ້ຂອງການຕິດຕາມແມ່ນການເບິ່ງເຫັນ. ຂອງພວກເຮົາແມ່ນອີງໃສ່ Grafana. ມັນໂດດເດັ່ນໃນບັນດາລະບົບການເບິ່ງເຫັນອື່ນໆທີ່ມັນຊ່ວຍໃຫ້ທ່ານສາມາດເບິ່ງເຫັນຕົວວັດແທກຈາກແຫຼ່ງຂໍ້ມູນທີ່ແຕກຕ່າງກັນໃນ dashboard. ພວກເຮົາສາມາດເກັບກໍາການວັດແທກລະດັບສູງສຸດສໍາລັບຮ້ານອອນໄລນ໌, ຕົວຢ່າງ, ຈໍານວນຄໍາສັ່ງທີ່ວາງໄວ້ໃນຊົ່ວໂມງທີ່ຜ່ານມາຈາກ DBMS, ຕົວຊີ້ວັດການປະຕິບັດສໍາລັບ OS ທີ່ຮ້ານອອນໄລນ໌ນີ້ດໍາເນີນການຈາກ Zabbix, ແລະຕົວຊີ້ບອກສໍາລັບຕົວຢ່າງຂອງແອັບພລິເຄຊັນນີ້. ຈາກ Prometheus. ແລະທັງຫມົດນີ້ຈະຢູ່ໃນ dashboard ດຽວ. ຈະແຈ້ງ ແລະເຂົ້າເຖິງໄດ້.

ໃຫ້ຂ້ອຍສັງເກດກ່ຽວກັບຄວາມປອດໄພ - ປະຈຸບັນພວກເຮົາກໍາລັງເຮັດສໍາເລັດລະບົບ, ເຊິ່ງຕໍ່ມາພວກເຮົາຈະປະສົມປະສານກັບລະບົບການຕິດຕາມທົ່ວໂລກ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ບັນຫາຕົ້ນຕໍທີ່ e-commerce ປະເຊີນຫນ້າໃນດ້ານຄວາມປອດໄພຂອງຂໍ້ມູນແມ່ນກ່ຽວຂ້ອງກັບ bots, parser ແລະ brute force. ພວກເຮົາຈໍາເປັນຕ້ອງຮັກສາຕາກ່ຽວກັບເລື່ອງນີ້, ເພາະວ່າສິ່ງທັງຫມົດນີ້ສາມາດສົ່ງຜົນກະທົບຕໍ່ການເຮັດວຽກຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແລະຊື່ສຽງຂອງພວກເຮົາຈາກທັດສະນະທາງທຸລະກິດ. ແລະດ້ວຍ stack ທີ່ເລືອກພວກເຮົາສົບຜົນສໍາເລັດກວມເອົາວຽກງານເຫຼົ່ານີ້.

ຈຸດສໍາຄັນອີກອັນຫນຶ່ງແມ່ນວ່າຊັ້ນຄໍາຮ້ອງສະຫມັກໄດ້ຖືກປະກອບໂດຍ Prometheus. ລາວເອງຍັງປະສົມປະສານກັບ Zabbix. ແລະພວກເຮົາຍັງມີ sitespeed, ການບໍລິການທີ່ອະນຸຍາດໃຫ້ພວກເຮົາເບິ່ງຕົວກໍານົດການເຊັ່ນ: ຄວາມໄວການໂຫຼດຂອງຫນ້າຂອງພວກເຮົາ, ຄໍຂວດ, ການສະແດງຫນ້າ, ການໂຫຼດສະຄິບ, ແລະອື່ນໆ, ມັນຍັງປະສົມປະສານ API. ດັ່ງນັ້ນ metrics ຂອງພວກເຮົາໄດ້ຖືກເກັບກໍາຢູ່ໃນ Zabbix, ແລະຕາມຄວາມເຫມາະສົມ, ພວກເຮົາຍັງແຈ້ງເຕືອນຈາກນັ້ນ. ການແຈ້ງເຕືອນທັງໝົດແມ່ນຖືກສົ່ງໄປຫາວິທີການສົ່ງຕົ້ນຕໍ (ສຳລັບຕອນນີ້ມັນເປັນອີເມວ ແລະໂທລະເລກ, ທີມ MS ກໍ່ໄດ້ເຊື່ອມຕໍ່ເມື່ອບໍ່ດົນມານີ້). ມີແຜນການທີ່ຈະຍົກລະດັບການເຕືອນເຖິງສະຖານະດັ່ງກ່າວທີ່ smart bots ເຮັດວຽກເປັນບໍລິການແລະໃຫ້ຂໍ້ມູນການຕິດຕາມກັບທຸກທີມຜະລິດຕະພັນທີ່ສົນໃຈ.

ສໍາລັບພວກເຮົາ, metrics ມີຄວາມສໍາຄັນບໍ່ພຽງແຕ່ສໍາລັບລະບົບຂໍ້ມູນສ່ວນບຸກຄົນ, ແຕ່ຍັງ metrics ທົ່ວໄປສໍາລັບໂຄງສ້າງພື້ນຖານທັງຫມົດທີ່ຄໍາຮ້ອງສະຫມັກນໍາໃຊ້: ກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍທີ່ເຄື່ອງ virtual ດໍາເນີນການ, ການດຸ່ນດ່ຽງການຈະລາຈອນ, Network Load Balancers, ເຄືອຂ່າຍຕົວມັນເອງ, ການນໍາໃຊ້ຊ່ອງທາງການສື່ສານ. . ບວກກັບ metrics ສໍາລັບສູນຂໍ້ມູນຂອງພວກເຮົາເອງ (ພວກເຮົາມີຫຼາຍໆອັນແລະໂຄງສ້າງພື້ນຖານແມ່ນຂ້ອນຂ້າງໃຫຍ່).

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

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

ຄວາມຄາດຫວັງ

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

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

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

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

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

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

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

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

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

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

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

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

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

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