ການຕິດຕາມແບບແຈກຢາຍ: ພວກເຮົາເຮັດມັນຜິດທັງຫມົດ

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

[ຮູບປະກອບມາຈາກ ວັດສະດຸອື່ນໆ ກ່ຽວກັບການຕິດຕາມທີ່ແຈກຢາຍ.]

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

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

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

ດັ່ງກ່າວເປັນຮ່ອງຮອຍທີ່ແຕກຕ່າງກັນ

ການຕິດຕາມທີ່ແຈກຢາຍປະກອບມີອົງປະກອບທີ່ແຕກຕ່າງກັນຫຼາຍ:

• equipping applications ແລະ middleware ກັບເຄື່ອງມືຄວບຄຸມ;
• ການ​ໂອນ​ສະ​ພາບ​ການ​ແຈກ​ຢາຍ​;
• ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​;
• ການເກັບຮັກສາການຕິດຕາມ;
• ການສະກັດເອົາແລະການເບິ່ງເຫັນຂອງພວກເຂົາ.

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

ຫມາຍ​ເຫດ​. ແປ.: ເພື່ອເຮັດໃຫ້ຂໍ້ຄວາມເພີ່ມເຕີມເຂົ້າໃຈງ່າຍຂຶ້ນ, ໃຫ້ພວກເຮົາກໍານົດສອງຄໍາສັບພື້ນຖານຕາມ ເອກະສານໂຄງການ OpenTracing:

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

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

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

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

ເມື່ອມັນມາ ທັນ ໄປຮອດ script debugging, ການໂຕ້ຕອບຕົ້ນຕໍຍັງຄົງຢູ່ໃນແຜນວາດ ຕິດຕາມເບິ່ງ (ເຖິງແມ່ນວ່າບາງຄົນຍັງເອີ້ນມັນ "ຕາຕະລາງ Gantt" ຫຼື "ແຜນວາດນ້ໍາຕົກ"). ພາຍໃຕ້ ຕິດຕາມເບິ່ງ я ຂ້ອຍ​ຫມາຍ​ຄວາມ​ວ່າ spans ທັງຫມົດແລະ metadata ມາພ້ອມກັບທີ່ຮ່ວມກັນສ້າງການຕິດຕາມ. ທຸກໆລະບົບການຕິດຕາມແຫຼ່ງເປີດ, ເຊັ່ນດຽວກັນກັບທຸກໆການແກ້ໄຂການຕິດຕາມທາງການຄ້າ, ສະເຫນີ a ຕິດຕາມເບິ່ງ ການໂຕ້ຕອບຜູ້ໃຊ້ສໍາລັບການເບິ່ງເຫັນ, ລາຍລະອຽດແລະການກັ່ນຕອງຮ່ອງຮອຍ.

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

ໃນໄລຍະຜ່ານມາຂ້າພະເຈົ້າ ຈົ່ມ ວ່າ "ນະວັດຕະກໍາ" ຕິດຕາມ UI/UX ສ່ວນໃຫຍ່ເບິ່ງຄືວ່າຖືກຈໍາກັດ ເປີດ metadata ເພີ່ມເຕີມໃນການຕິດຕາມ, ການລົງທຶນໃນໃຫ້ເຂົາເຈົ້າຂໍ້ມູນຂ່າວສານທີ່ມີ cardinality ສູງ (ສຽງ​ສູງ​) ຫຼືການສະຫນອງຄວາມສາມາດໃນການເຈາະເຂົ້າໄປໃນຂອບເຂດສະເພາະຫຼືດໍາເນີນການສອບຖາມ inter- ແລະ intra-trace... ຢູ່ໃນ ຕິດຕາມເບິ່ງ ຍັງຄົງເປັນເຄື່ອງມືການເບິ່ງເຫັນຕົ້ນຕໍ. ຕາບໃດທີ່ສະຖານະການນີ້ຍັງສືບຕໍ່, ການຕິດຕາມການແຈກຢາຍຈະ (ດີທີ່ສຸດ) ເອົາອັນດັບທີ 4 ເປັນເຄື່ອງມືແກ້ໄຂ, ຫຼັງຈາກ metrics, ບັນທຶກແລະ stack traces, ແລະຮ້າຍແຮງທີ່ສຸດມັນຈະກາຍເປັນການສູນເສຍເງິນແລະເວລາ.

ບັນຫາກັບ traceview

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

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

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

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

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

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

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

ໄລຍະຫ່າງແມ່ນຢູ່ໃນລະດັບຕໍ່າເກີນໄປ

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

ຍິ່ງໄປກວ່ານັ້ນ, ຂ້າພະເຈົ້າຈະເອົາເສລີພາບໃນການຢືນຢັນຕໍ່ໄປນີ້: ໂດຍຫລັກການແລ້ວ, ພວກເຮົາບໍ່ຕ້ອງການ ຮູບເຕັມ ເກີດຂຶ້ນໃນລະຫວ່າງວົງຈອນຊີວິດການຮ້ອງຂໍ, ເຊິ່ງເປັນຕົວແທນໂດຍເຄື່ອງມືຕິດຕາມທີ່ທັນສະໄຫມ. ແທນທີ່ຈະ, ບາງຮູບແບບຂອງ abstraction ລະດັບສູງແມ່ນຕ້ອງການທີ່ມີຂໍ້ມູນກ່ຽວກັບສິ່ງທີ່ ຜິດພາດ (ຄ້າຍກັບ backtrace), ພ້ອມກັບບາງສະພາບການ. ແທນທີ່ຈະເບິ່ງຕາມຮອຍທັງໝົດ, ຂ້ອຍມັກເບິ່ງມັນ ສ່ວນຫນຶ່ງຂອງ, ບ່ອນທີ່ມີບາງສິ່ງບາງຢ່າງທີ່ຫນ້າສົນໃຈຫຼືຜິດປົກກະຕິເກີດຂຶ້ນ. ໃນປັດຈຸບັນ, ການຄົ້ນຫາແມ່ນດໍາເນີນການດ້ວຍຕົນເອງ: ວິສະວະກອນໄດ້ຮັບການຕິດຕາມແລະການວິເຄາະຢ່າງເປັນເອກະລາດ spans ໃນການຊອກຫາສິ່ງທີ່ຫນ້າສົນໃຈ. ວິທີການຂອງຄົນທີ່ເບິ່ງ spans ໃນການຕິດຕາມແຕ່ລະຄົນໃນຄວາມຫວັງທີ່ຈະກວດພົບກິດຈະກໍາທີ່ຫນ້າສົງໄສບໍ່ໄດ້ຂະຫນາດທັງຫມົດ (ໂດຍສະເພາະໃນເວລາທີ່ພວກເຂົາຕ້ອງເຮັດໃຫ້ຄວາມຮູ້ສຶກຂອງ metadata ທັງຫມົດທີ່ເຂົ້າລະຫັດໃນ spans ທີ່ແຕກຕ່າງກັນ, ເຊັ່ນ span ID, RPC, ຊື່ວິທີການ, ໄລຍະເວລາ span. 'a, ບັນທຶກ, tags, ແລະອື່ນໆ).

ທາງເລືອກໃນການ traceview

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

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

ສຸມໃສ່ການບໍລິການສະເພາະ

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

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

1. ແຜນວາດການແຈກຢາຍເວລາແພັກເກັດສຳລັບຄຳຮ້ອງຂໍທີ່ໂດດເດັ່ນເທົ່ານັ້ນ (ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ເກີນ​ກວ່າ​);
2. ແຜນວາດການແຈກຢາຍຄວາມລ່າຊ້າສໍາລັບກໍລະນີໃນເວລາທີ່ການບໍລິການ SLO ບໍ່ໄດ້ບັນລຸເປົ້າຫມາຍ;
3. ແທັກ "ທົ່ວໄປ", "ຫນ້າສົນໃຈ" ແລະ "ແປກ" ທີ່ສຸດໃນຄໍາຖາມທີ່ມັກ ແມ່ນຊ້ໍາ;
4. ການແບ່ງເວລາແພັກເກັດສໍາລັບກໍລະນີທີ່ ເພິ່ງພາອາໄສ ການບໍລິການບໍ່ບັນລຸເປົ້າຫມາຍ SLO ຂອງພວກເຂົາ;
5. ການແບ່ງເວລາແພັກເກັດສໍາລັບການບໍລິການລຸ່ມນ້ໍາຕ່າງໆ.

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

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

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

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

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

ການສ້າງ topology

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

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

ໃຫ້​ເຮົາ​ໃຊ້​ຕົວ​ຢ່າງ. ຂໍໃຫ້ຈິນຕະນາການເວັບໄຊທ໌ຂ່າວສົມມຸດຕິຖານ. ບໍລິການຫນ້າທໍາອິດ (ໜ້າ) ແລກປ່ຽນຂໍ້ມູນກັບ Redis, ມີບໍລິການແນະນໍາ, ມີບໍລິການໂຄສະນາແລະການບໍລິການວິດີໂອ. ບໍລິການວິດີໂອເອົາວິດີໂອຈາກ S3 ແລະ metadata ຈາກ DynamoDB. ບໍລິການແນະນໍາໄດ້ຮັບ metadata ຈາກ DynamoDB, ໂຫຼດຂໍ້ມູນຈາກ Redis ແລະ MySQL, ແລະຂຽນຂໍ້ຄວາມໄປຫາ Kafka. ບໍລິການໂຄສະນາໄດ້ຮັບຂໍ້ມູນຈາກ MySQL ແລະຂຽນຂໍ້ຄວາມໄປຫາ Kafka.

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

ແຜນວາດການບໍລິການຂອງເວັບໄຊຂ່າວສົມມຸດຕິຖານ

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

topology ແບບໄດນາມິກສະແດງການບໍລິການ "ທີ່ຫນ້າສົນໃຈ" ເທົ່ານັ້ນ

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

ການສະແດງຜົນປຽບທຽບ

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

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

ສະຫລຸບ

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

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

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

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

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ປັ໊ກອິນ kubectl-debug ສຳລັບການດີບັກໃນພອດ Kubernetes"
• «Microservices: ຂະຫນາດເປັນເລື່ອງສໍາຄັນ, ເຖິງແມ່ນວ່າທ່ານມີ Kubernetes"
• «ການຕິດຕາມແລະ Kubernetes (ການທົບທວນຄືນແລະບົດລາຍງານວິດີໂອ)".

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