ການຕິດຕາມແມ່ນຕາຍບໍ? — ຕິດ​ຕາມ​ກວດ​ກາ​ທີ່​ຍາວ​ນານ​

ນັບຕັ້ງແຕ່ປີ 2008, ບໍລິສັດຂອງພວກເຮົາໄດ້ດໍາເນີນການຕົ້ນຕໍໃນການຄຸ້ມຄອງໂຄງສ້າງພື້ນຖານແລະການສະຫນັບສະຫນູນດ້ານວິຊາການຕະຫຼອດໂມງສໍາລັບໂຄງການເວັບ: ພວກເຮົາມີລູກຄ້າຫຼາຍກວ່າ 400 ຄົນ, ເຊິ່ງປະມານ 15% ຂອງ e-commerce ລັດເຊຍ. ຕາມ​ນັ້ນ​ແລ້ວ, ສະ​ຖາ​ປັດ​ຕະ​ຍະ​ກຳ​ທີ່​ຫຼາກ​ຫຼາຍ​ໄດ້​ຮັບ​ການ​ສະ​ໜັບ​ສະ​ໜູນ. ຖ້າບາງສິ່ງບາງຢ່າງຕົກ, ພວກເຮົາຕ້ອງແກ້ໄຂມັນພາຍໃນ 15 ນາທີ. ແຕ່ເພື່ອເຂົ້າໃຈວ່າອຸປະຕິເຫດເກີດຂຶ້ນ, ທ່ານຈໍາເປັນຕ້ອງຕິດຕາມໂຄງການແລະຕອບສະຫນອງຕໍ່ເຫດການ. ເຮັດແນວໃດ?

ຂ້າພະເຈົ້າເຊື່ອວ່າມີບັນຫາໃນການຈັດຕັ້ງລະບົບການຕິດຕາມທີ່ເຫມາະສົມ. ຖ້າບໍ່ມີບັນຫາ, ຄໍາເວົ້າຂອງຂ້ອຍຈະປະກອບດ້ວຍຫນຶ່ງ thesis: "ກະລຸນາຕິດຕັ້ງ Prometheus + Grafana ແລະ plugins 1, 2, 3." ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ໄດ້ເຮັດວຽກແບບນັ້ນອີກຕໍ່ໄປ. ແລະບັນຫາຕົ້ນຕໍແມ່ນວ່າທຸກຄົນຍັງສືບຕໍ່ເຊື່ອໃນບາງສິ່ງບາງຢ່າງທີ່ມີຢູ່ໃນປີ 2008, ໃນແງ່ຂອງອົງປະກອບຂອງຊອບແວ.

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

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

ຕົກ​ລົງ. ພວກເຮົາຕິດຕາມວິທີການແບບເກົ່າ. ແລະມັນມີການປ່ຽນແປງແລ້ວ, ແລະມັນປາກົດວ່າທ່ານຕິດຕາມການບໍລິການ A, ເຊິ່ງກາຍເປັນບໍລິການ B, ເຊິ່ງພົວພັນກັບການບໍລິການ C. ແຕ່ທີມງານພັດທະນາບອກທ່ານວ່າ: "ຕິດຕັ້ງຊອບແວ, ມັນຄວນຈະຕິດຕາມທຸກຢ່າງ!"

ດັ່ງນັ້ນສິ່ງທີ່ມີການປ່ຽນແປງ? - ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ​!

2008 ທຸກຢ່າງແມ່ນດີ

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

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

2010 ການໂຫຼດກໍາລັງເຕີບໂຕ

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

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

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

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

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

ແຕ່ບໍ່ຄ່ອຍມີຄົນມາຮ່ວມໂຄງການເປັນເວລາ 10 ປີ.

ຊີວະປະຫວັດຫຍໍ້ຂອງຜູ້ຕິດຕາມ

ສົມມຸດວ່າທ່ານມາຮອດການເລີ່ມຕົ້ນໃຫມ່ທີ່ຈ້າງຜູ້ພັດທະນາທັນທີ 20 ຄົນ, ຂຽນ 15 microservices, ແລະທ່ານເປັນຜູ້ບໍລິຫານທີ່ຖືກບອກວ່າ: "ສ້າງ CI / CD. ກະລຸນາ." ທ່ານໄດ້ສ້າງ CI / CD ແລະທັນທີທັນໃດທ່ານໄດ້ຍິນ: "ມັນເປັນເລື່ອງຍາກສໍາລັບພວກເຮົາທີ່ຈະເຮັດວຽກກັບການຜະລິດໃນ "cube", ໂດຍບໍ່ມີການເຂົ້າໃຈວິທີການເຮັດວຽກໃນມັນ. ເຮັດໃຫ້ພວກເຮົາ sandbox ໃນ "cube" ດຽວກັນ.
ທ່ານເຮັດ sandbox ໃນ cube ນີ້. ພວກເຂົາບອກທ່ານທັນທີວ່າ: "ພວກເຮົາຕ້ອງການຖານຂໍ້ມູນຂັ້ນຕອນທີ່ປັບປຸງທຸກໆມື້ຈາກການຜະລິດ, ດັ່ງນັ້ນພວກເຮົາເຂົ້າໃຈວ່າມັນເຮັດວຽກຢູ່ໃນຖານຂໍ້ມູນ, ແຕ່ໃນເວລາດຽວກັນບໍ່ທໍາລາຍຖານຂໍ້ມູນການຜະລິດ."

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

ແລະເພື່ອນຮ່ວມງານຂອງຂ້ອຍເອົາແຜນການປົກກະຕິອອກຈາກຫົວຂອງພວກເຂົາແລະເວົ້າວ່າ: "ດີ, ທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງຢູ່ທີ່ນີ້! ຕິດຕັ້ງໂຄງການທີ່ຈະຕິດຕາມກວດກາທັງຫມົດນີ້." ແມ່ນແລ້ວ, ແມ່ນແລ້ວ: Prometheus + Grafana + plugins.
ແລະພວກເຂົາກ່າວຕື່ມວ່າ: "ເຈົ້າມີສອງອາທິດ, ໃຫ້ແນ່ໃຈວ່າທຸກຢ່າງປອດໄພ."

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

• ລາວຕ້ອງເຂົ້າໃຈການຕິດຕາມແລະສະເພາະຂອງການດໍາເນີນງານຂອງໂຄງສ້າງພື້ນຖານຂອງທາດເຫຼັກ.
• ລາວຕ້ອງເຂົ້າໃຈສະເພາະຂອງການຕິດຕາມ Kubernetes (ແລະທຸກຄົນຕ້ອງການໄປຫາ "cube", ເພາະວ່າທ່ານສາມາດບໍ່ມີຕົວຕົນຈາກທຸກສິ່ງທຸກຢ່າງ, ເຊື່ອງ, ເພາະວ່າ admin ຈະຈັດການກັບສ່ວນທີ່ເຫຼືອ) - ຕົວຂອງມັນເອງ, ໂຄງສ້າງພື້ນຖານຂອງມັນ, ແລະເຂົ້າໃຈວິທີການຕິດຕາມຄໍາຮ້ອງສະຫມັກ. ພາຍໃນ.
• ລາວຕ້ອງເຂົ້າໃຈວ່າການບໍລິການຕິດຕໍ່ສື່ສານກັບກັນໃນທາງພິເສດ, ແລະຮູ້ສະເພາະຂອງວິທີການບໍລິການພົວພັນກັບກັນແລະກັນ. ມັນເປັນໄປໄດ້ຂ້ອນຂ້າງທີ່ຈະເຫັນໂຄງການທີ່ບາງບໍລິການຕິດຕໍ່ສື່ສານ synchronously, ເພາະວ່າບໍ່ມີທາງອື່ນ. ຕົວຢ່າງ, backend ໄປຜ່ານ REST, ຜ່ານ gRPC ໄປຫາບໍລິການລາຍການ, ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງຜະລິດຕະພັນແລະສົ່ງຄືນ. ທ່ານບໍ່ສາມາດລໍຖ້າທີ່ນີ້. ແລະກັບການບໍລິການອື່ນໆມັນເຮັດວຽກ asynchronously. ໂອນຄໍາສັ່ງໄປຫາບໍລິການຈັດສົ່ງ, ສົ່ງຈົດຫມາຍ, ແລະອື່ນໆ.
  ເຈົ້າອາດຈະລອຍຈາກທັງໝົດນີ້ແລ້ວບໍ? ແລະຜູ້ບໍລິຫານ, ຜູ້ທີ່ຕ້ອງການຕິດຕາມກວດການີ້, ໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍ.
• ລາວຕ້ອງສາມາດວາງແຜນແລະວາງແຜນໄດ້ຢ່າງຖືກຕ້ອງ - ຍ້ອນວ່າວຽກງານຈະຫຼາຍຂຶ້ນ.
• ດັ່ງນັ້ນ, ລາວຕ້ອງສ້າງຍຸດທະສາດຈາກການບໍລິການທີ່ສ້າງຂຶ້ນເພື່ອເຂົ້າໃຈວິທີການຕິດຕາມໂດຍສະເພາະ. ລາວຕ້ອງການຄວາມເຂົ້າໃຈກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງໂຄງການແລະການພັດທະນາຂອງມັນ + ຄວາມເຂົ້າໃຈກ່ຽວກັບເຕັກໂນໂລຢີທີ່ໃຊ້ໃນການພັດທະນາ.

ຂໍໃຫ້ຈື່ຈໍາກໍລະນີປົກກະຕິຢ່າງແທ້ຈິງ: ບາງບໍລິການແມ່ນຢູ່ໃນ PHP, ບາງບໍລິການແມ່ນຢູ່ໃນ Go, ບາງບໍລິການແມ່ນຢູ່ໃນ JS. ພວກເຂົາເຈົ້າ somehow ເຮັດວຽກຮ່ວມກັບກັນແລະກັນ. ນີ້ແມ່ນບ່ອນທີ່ຄໍາວ່າ "ບໍລິການຈຸລະພາກ" ມາຈາກ: ມີຫຼາຍລະບົບສ່ວນບຸກຄົນທີ່ນັກພັດທະນາບໍ່ສາມາດເຂົ້າໃຈໂຄງການທັງຫມົດ. ສ່ວນຫນຶ່ງຂອງທີມງານຂຽນການບໍລິການໃນ JS ທີ່ເຮັດວຽກດ້ວຍຕົນເອງແລະບໍ່ຮູ້ວ່າສ່ວນທີ່ເຫຼືອຂອງລະບົບເຮັດວຽກແນວໃດ. ພາກສ່ວນອື່ນຂຽນການບໍລິການໃນ Python ແລະບໍ່ແຊກແຊງກັບວິທີການເຮັດວຽກຂອງການບໍລິການອື່ນໆ; ພວກເຂົາຖືກແຍກຢູ່ໃນພື້ນທີ່ຂອງຕົນເອງ. ອັນທີສາມແມ່ນການຂຽນການບໍລິການໃນ PHP ຫຼືສິ່ງອື່ນ.
ທັງໝົດ 20 ຄົນນີ້ ແບ່ງອອກເປັນ 15 ການບໍລິການ, ແລະມີພຽງຜູ້ບໍລິຫານຜູ້ໜຶ່ງທີ່ຕ້ອງເຂົ້າໃຈທັງໝົດນີ້. ຢຸດ! ພວກເຮົາພຽງແຕ່ແບ່ງລະບົບອອກເປັນ 15 microservices ເພາະວ່າ 20 ຄົນບໍ່ສາມາດເຂົ້າໃຈລະບົບທັງຫມົດ.

ແຕ່​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ຕິດ​ຕາມ​ບາງ​ຢ່າງ ...

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

ຂ້ອຍສາມາດເວົ້າຫຍັງໄດ້... Houston, ພວກເຮົາມີບັນຫາ.

ການຕິດຕາມໂຄງການຊອບແວທີ່ທັນສະໄຫມແມ່ນໂຄງການຊອບແວໃນຕົວຂອງມັນເອງ

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

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

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

ດັ່ງນັ້ນວິທີການຕິດຕາມໂຄງການເລີ່ມຕົ້ນຈາກຈຸດເລີ່ມຕົ້ນ, ແລະຈະເຮັດແນວໃດຖ້າທ່ານໄດ້ຮັບໂຄງການທີ່ຕ້ອງໄດ້ຮັບການຕິດຕາມ, ແຕ່ທ່ານບໍ່ຮູ້ວ່າຈະເລີ່ມຕົ້ນຢູ່ໃສ?

ທໍາອິດ, ທ່ານຈໍາເປັນຕ້ອງວາງແຜນ.

ຄວາມຫຍໍ້ທໍ້ຂອງເນື້ອເພງ: ມັກຈະເລີ່ມຕົ້ນດ້ວຍການຕິດຕາມໂຄງສ້າງພື້ນຖານ. ຕົວຢ່າງ, ພວກເຮົາມີ Kubernetes. ໃຫ້ເລີ່ມຕົ້ນດ້ວຍການຕິດຕັ້ງ Prometheus ກັບ Grafana, ການຕິດຕັ້ງ plugins ສໍາລັບການຕິດຕາມ "cube". ບໍ່ພຽງແຕ່ນັກພັດທະນາ, ແຕ່ຜູ້ບໍລິຫານຍັງມີການປະຕິບັດທີ່ໂຊກບໍ່ດີຂອງ: "ພວກເຮົາຈະຕິດຕັ້ງ plugin ນີ້, ແຕ່ plugin ອາດຈະຮູ້ວິທີການເຮັດມັນ." ປະຊາຊົນມັກເລີ່ມຕົ້ນດ້ວຍການງ່າຍດາຍແລະກົງໄປກົງມາ, ແທນທີ່ຈະເປັນການດໍາເນີນການທີ່ສໍາຄັນ. ແລະການຕິດຕາມໂຄງສ້າງພື້ນຖານແມ່ນງ່າຍ.

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

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

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

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

ທຸກຢ່າງຕາມລະດັບ

ນີ້ແມ່ນວິທີທີ່ຂ້ອຍເຫັນການຈັດຕັ້ງຂອງລະບົບການຕິດຕາມ.

1​) ລະ​ດັບ​ການ​ນໍາ​ໃຊ້​:

• ການຕິດຕາມເຫດຜົນທາງທຸລະກິດຂອງແອັບພລິເຄຊັນ;
• ການ​ຕິດ​ຕາມ​ມາດ​ຕະ​ການ​ສຸ​ຂະ​ພາບ​ຂອງ​ການ​ບໍ​ລິ​ການ​;
• ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ການ​ເຊື່ອມ​ໂຍງ​.

2) ລະດັບພື້ນຖານໂຄງລ່າງ:

• ການຕິດຕາມລະດັບ orchestration;
• ການຕິດຕາມຊອບແວລະບົບ;
• ການ​ຕິດ​ຕາມ​ລະ​ດັບ​ທາດ​ເຫຼັກ​.

3) ອີກເທື່ອຫນຶ່ງລະດັບຄໍາຮ້ອງສະຫມັກ - ແຕ່ເປັນຜະລິດຕະພັນວິສະວະກໍາ:

• ເກັບກໍາແລະຕິດຕາມກວດກາບັນທຶກຄໍາຮ້ອງສະຫມັກ;
• APM;
• ການຕິດຕາມ.

4​) ການ​ແຈ້ງ​ເຕືອນ​:

• ການຈັດຕັ້ງລະບົບເຕືອນໄພ;
• ການຈັດຕັ້ງລະບົບໜ້າທີ່;
• ການຈັດຕັ້ງຂອງ "ພື້ນຖານຄວາມຮູ້" ແລະຂະບວນການເຮັດວຽກສໍາລັບການປະມວນຜົນເຫດການ.

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

Application Layer - ການຕິດຕາມເຫດຜົນທາງທຸລະກິດ

ນີ້ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການກວດສອບຄວາມຈິງທີ່ວ່າຄໍາຮ້ອງສະຫມັກເຮັດວຽກສໍາລັບຜູ້ໃຊ້.

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

ເມື່ອຖືກຖາມເລື້ອຍໆເພື່ອຕິດຕາມຫນ້າທໍາອິດເພື່ອໃຫ້ແນ່ໃຈວ່າເວັບໄຊທ໌ເຮັດວຽກ, ນັກຂຽນໂປລແກລມໃຫ້ຕົວຈັບທີ່ສາມາດດຶງໄດ້ທຸກຄັ້ງທີ່ພວກເຂົາຕ້ອງການເພື່ອໃຫ້ແນ່ໃຈວ່າ API ເຮັດວຽກ. ແລະນັກຂຽນໂປລແກລມໃນເວລານີ້ຍັງໃຊ້ເວລາແລະຂຽນ /api/test/helloworld
ວິທີດຽວທີ່ຈະໃຫ້ແນ່ໃຈວ່າທຸກຢ່າງເຮັດວຽກ? - ບໍ່!

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

ຄໍາແນະນໍາດ້ານວິຊາການ:

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

ຊັ້ນຄໍາຮ້ອງສະຫມັກ - health metrics monitoring

ໃນປັດຈຸບັນພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການວັດແທກສຸຂະພາບພາຍນອກຂອງການບໍລິການ.

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

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

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

Application Layer - ການກວດສອບການເຊື່ອມໂຍງ

ການຕິດຕາມການເຊື່ອມໂຍງແມ່ນສຸມໃສ່ການຕິດຕາມການສື່ສານລະຫວ່າງລະບົບທຸລະກິດທີ່ສໍາຄັນ.

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

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

ສິ່ງທີ່ຂ້ອຍແນະນໍາໃຫ້ເຮັດ:

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

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

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

ລະດັບພື້ນຖານໂຄງລ່າງ

ການຕິດຕາມພື້ນຖານໂຄງລ່າງແມ່ນບາງສິ່ງບາງຢ່າງທີ່ໄດ້ພິຈາລະນາມາດົນແລ້ວການຕິດຕາມຕົວມັນເອງ.

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

ລະດັບຄໍາຮ້ອງສະຫມັກເປັນຫນ່ວຍງານທຸລະກິດ

ຈຸດ​ທີ່​ສໍາ​ຄັນ:

• ELK. ນີ້ແມ່ນມາດຕະຖານອຸດສາຫະກໍາ. ຖ້າສໍາລັບເຫດຜົນບາງຢ່າງທີ່ທ່ານບໍ່ໄດ້ລວບລວມບັນທຶກ, ເລີ່ມຕົ້ນເຮັດທັນທີ.
• APM. APMs ພາຍນອກເປັນວິທີທີ່ຈະປິດການຕິດຕາມແອັບພລິເຄຊັນໄດ້ໄວ (NewRelic, BlackFire, Datadog). ທ່ານສາມາດຕິດຕັ້ງສິ່ງນີ້ຊົ່ວຄາວເພື່ອໃຫ້ຢ່າງນ້ອຍເຂົ້າໃຈສິ່ງທີ່ເກີດຂື້ນກັບທ່ານ.
• ການຕິດຕາມ. ໃນອາຍແກັສຂອງ microservices, ທ່ານຕ້ອງຕິດຕາມທຸກສິ່ງທຸກຢ່າງ, ເພາະວ່າຄໍາຮ້ອງຂໍບໍ່ມີຊີວິດຂອງມັນເອງ. ມັນເປັນການຍາກຫຼາຍທີ່ຈະເພີ່ມໃນພາຍຫລັງ, ສະນັ້ນມັນດີກວ່າທີ່ຈະຈັດຕາຕະລາງການຕິດຕາມໃນການພັດທະນາທັນທີ - ນີ້ແມ່ນການເຮັດວຽກແລະຜົນປະໂຫຍດຂອງນັກພັດທະນາ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຍັງ​ບໍ່​ທັນ​ໄດ້​ປະ​ຕິ​ບັດ​ມັນ​, ປະ​ຕິ​ບັດ​ມັນ​! ເບິ່ງ Jaeger/Zipkin

ແຈ້ງເຕືອນ

• ການຈັດ​ຕັ້ງ​ຂອງ​ລະ​ບົບ​ການ​ແຈ້ງ​ການ​: ໃນ​ເງື່ອນ​ໄຂ​ຂອງ​ການ​ຕິດ​ຕາມ​ຊໍ່​ຂອງ​ສິ່ງ​ທີ່​, ຄວນ​ຈະ​ມີ​ລະ​ບົບ​ຄວາມ​ເປັນ​ເອ​ກະ​ພາບ​ສໍາ​ລັບ​ການ​ສົ່ງ​ແຈ້ງ​ການ​. ທ່ານສາມາດຢູ່ໃນ Grafana. ໃນພາກຕາເວັນຕົກ, ທຸກຄົນໃຊ້ PagerDuty. ການແຈ້ງເຕືອນຄວນຈະຈະແຈ້ງ (ເຊັ່ນ: ບ່ອນທີ່ພວກເຂົາມາຈາກ ... ). ແລະຄວນຄວບຄຸມວ່າໄດ້ຮັບການແຈ້ງເຕືອນທັງໝົດ
• ການຈັດລະບຽບຂອງລະບົບຫນ້າທີ່: ການແຈ້ງເຕືອນບໍ່ຄວນຖືກສົ່ງໄປຫາທຸກຄົນ (ທຸກຄົນຈະໂຕ້ຕອບໃນຝູງຊົນ, ຫຼືບໍ່ມີໃຜຈະຕິກິຣິຍາ). ນັກພັດທະນາຍັງຈໍາເປັນຕ້ອງໄດ້ໂທຫາ: ໃຫ້ແນ່ໃຈວ່າກໍານົດຂອບເຂດຄວາມຮັບຜິດຊອບ, ເຮັດຄໍາແນະນໍາທີ່ຊັດເຈນແລະຂຽນໃນມັນວ່າໃຜຈະໂທຫາໃນວັນຈັນແລະວັນພຸດ, ແລະໃຜທີ່ຈະໂທຫາໃນວັນອັງຄານແລະວັນສຸກ (ຖ້າບໍ່ດັ່ງນັ້ນພວກເຂົາຈະບໍ່ໂທຫາໃຜແມ້ແຕ່ຢູ່ໃນ. ເຫດການຂອງບັນຫາໃຫຍ່ - ພວກເຂົາຈະຢ້ານທີ່ຈະປຸກທ່ານຫຼືລົບກວນ: ຄົນທົ່ວໄປບໍ່ມັກໂທຫາແລະປຸກຄົນອື່ນ, ໂດຍສະເພາະໃນຕອນກາງຄືນ). ແລະອະທິບາຍວ່າການຂໍຄວາມຊ່ວຍເຫຼືອບໍ່ແມ່ນຕົວຊີ້ບອກຂອງຄວາມບໍ່ມີຄວາມສາມາດ (“ຂ້ອຍຂໍຄວາມຊ່ວຍເຫຼືອ, ນັ້ນໝາຍຄວາມວ່າຂ້ອຍເປັນພະນັກງານທີ່ບໍ່ດີ”), ຊຸກຍູ້ການຮ້ອງຂໍຄວາມຊ່ວຍເຫຼືອ.
• ການຈັດຕັ້ງຂອງ "ພື້ນຖານຄວາມຮູ້" ແລະຂະບວນການເຮັດວຽກສໍາລັບການປະມວນຜົນເຫດການ: ສໍາລັບແຕ່ລະເຫດການຮ້າຍແຮງ, ການເສຍຊີວິດຄວນໄດ້ຮັບການວາງແຜນ, ແລະເປັນມາດຕະການຊົ່ວຄາວ, ການກະທໍາທີ່ຈະແກ້ໄຂເຫດການຄວນໄດ້ຮັບການບັນທຶກໄວ້. ແລະ​ເຮັດ​ໃຫ້​ມັນ​ເປັນ​ການ​ປະ​ຕິ​ບັດ​ວ່າ​ການ​ແຈ້ງ​ເຕືອນ​ຊ​້​ໍາ​ເປັນ​ບາບ; ພວກເຂົາຕ້ອງໄດ້ຮັບການແກ້ໄຂໃນລະຫັດຫຼືວຽກງານພື້ນຖານໂຄງລ່າງ.

ເຕັກໂນໂລຍີ stack

ໃຫ້ຈິນຕະນາການວ່າ stack ຂອງພວກເຮົາແມ່ນດັ່ງຕໍ່ໄປນີ້:

• ການເກັບຂໍ້ມູນ - Prometheus + Grafana;
• ການວິເຄາະບັນທຶກ - ELK;
• ສໍາລັບ APM ຫຼື Tracing - Jaeger (Zipkin).

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

ບາງຈຸດທາງດ້ານວິຊາການທີ່ຂ້ອຍເຫັນຢູ່ທົ່ວທຸກແຫ່ງເມື່ອບໍ່ດົນມານີ້:

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

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

ການຄົ້ນພົບ

• ການພັດທະນາການຕິດຕາມບໍ່ແມ່ນການຕິດຕັ້ງສິ່ງອໍານວຍຄວາມສະດວກ, ແຕ່ການພັດທະນາຜະລິດຕະພັນຊອບແວ. 98% ຂອງການຕິດຕາມມື້ນີ້ແມ່ນການເຂົ້າລະຫັດ. Coding ໃນການບໍລິການ, coding ການກວດສອບພາຍນອກ, ການກວດສອບການບໍລິການພາຍນອກ, ແລະນັ້ນແມ່ນທັງຫມົດ.
• ຢ່າເສຍເວລາຂອງຜູ້ພັດທະນາຂອງທ່ານໃນການຕິດຕາມ: ມັນສາມາດໃຊ້ເວລາເຖິງ 30% ຂອງວຽກງານຂອງພວກເຂົາ, ແຕ່ມັນກໍ່ຄຸ້ມຄ່າ.
• Devops, ຢ່າກັງວົນວ່າທ່ານບໍ່ສາມາດຕິດຕາມບາງສິ່ງບາງຢ່າງ, ເພາະວ່າບາງສິ່ງແມ່ນວິທີການຄິດທີ່ແຕກຕ່າງກັນຫມົດ. ເຈົ້າບໍ່ແມ່ນນັກຂຽນໂປລແກລມ, ແລະວຽກງານການຕິດຕາມແມ່ນວຽກຂອງພວກເຂົາແທ້ໆ.
• ຖ້າໂຄງການແມ່ນແລ້ວແລະບໍ່ໄດ້ຕິດຕາມ (ແລະທ່ານເປັນຜູ້ຈັດການ), ຈັດສັນຊັບພະຍາກອນສໍາລັບການຕິດຕາມ.
• ຖ້າຜະລິດຕະພັນແມ່ນຢູ່ໃນການຜະລິດແລ້ວ, ແລະທ່ານເປັນ devops ທີ່ຖືກບອກໃຫ້ "ຕັ້ງຄ່າການຕິດຕາມ" - ພະຍາຍາມອະທິບາຍໃຫ້ການຄຸ້ມຄອງສິ່ງທີ່ຂ້ອຍຂຽນທັງຫມົດນີ້ກ່ຽວກັບ.

ນີ້ແມ່ນສະບັບຂະຫຍາຍຂອງບົດລາຍງານຢູ່ໃນກອງປະຊຸມ Saint Highload++.

ຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈໃນແນວຄວາມຄິດແລະຄວາມຄິດຂອງຂ້າພະເຈົ້າກ່ຽວກັບມັນແລະຫົວຂໍ້ທີ່ກ່ຽວຂ້ອງ, ຫຼັງຈາກນັ້ນໃນທີ່ນີ້ທ່ານສາມາດ ອ່ານຊ່ອງ 🙂

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