OpenTelemetry ແມ່ນຫຍັງ ແລະມັນສາມາດປັບປຸງຄຸນນະພາບ Backend ຂອງເຈົ້າໄດ້ແນວໃດ?

ໃນໄລຍະຜ່ານມາ, ເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບ backend, ພວກເຮົາມັກຈະຫມາຍເຖິງຄໍາຮ້ອງສະຫມັກຂະຫນາດໃຫຍ່ທີ່ມີຖານຂໍ້ມູນດຽວ, ຂະຫນາດໃຫຍ່, ແລະບັນທຶກແມ່ນພຽງພໍສໍາລັບການກວດສອບ. ໃນປັດຈຸບັນ, ຂໍຂອບໃຈກັບເຕັກໂນໂລຢີເຊັ່ນ , ໄດ້ກາຍເປັນມາດຕະຖານ. ແອັບພລິເຄຊັນມີຈຳນວນຫຼາຍ ແລະຖືກແຈກຢາຍ, ແລະການບັນທຶກແບບດັ້ງເດີມແມ່ນບໍ່ພຽງພໍສຳລັບ ແລະວິນິໄສບັນຫາໃນແອັບພລິເຄຊັນຂອງພວກເຮົາ. Kubernetes ການບໍລິການຈຸລະພາກ ການດີບັກ ການແກ້ໄຂທີ່ດີເລີດສໍາລັບການຈັດຕັ້ງການຕິດຕາມແມ່ນ OpenTelemetry - ເປັນຊຸດເຄື່ອງມືທີ່ທັນສະໄຫມທີ່ສາມາດຖືກນໍາໃຊ້ສໍາລັບການ debugging ແລະການວິເຄາະປະສິດທິພາບຂອງລະບົບແຈກຢາຍ. ບົດຄວາມນີ້ມີຈຸດປະສົງສໍາລັບຜູ້ຊ່ຽວຊານດ້ານໄອທີທີ່ຊອກຫາເພື່ອຂະຫຍາຍຄວາມຮູ້ຂອງເຂົາເຈົ້າໃນການເພີ່ມປະສິດທິພາບ backend. ຂ້າງລຸ່ມນີ້, ພວກເຮົາຈະລາຍລະອຽດວ່າ OpenTelemetry ແມ່ນຫຍັງ, ແນວຄວາມຄິດທີ່ສໍາຄັນຂອງມັນ, ແລະບັນຫາທີ່ມັນຊ່ວຍແກ້ໄຂ. ຖ້າທ່ານສົນໃຈໃນວິທີທີ່ OpenTelemetry ສາມາດປ່ຽນວິທີການຕິດຕາມ ແລະແກ້ໄຂລະບົບ backend, ປັບປຸງຄວາມໜ້າເຊື່ອຖື ແລະ ປະສິດທິພາບຂອງພວກມັນ — ອ່ານຕໍ່. ປະຫວັດຫຍໍ້ຂອງ OpenTelemetry ບໍລິສັດເຕັກໂນໂລຢີຂະຫນາດໃຫຍ່ທໍາອິດປະເຊີນກັບສິ່ງທ້າທາຍຂອງການຕັດໄມ້ແລະການຕິດຕາມທີ່ແຈກຢາຍໃນທ້າຍຊຸມປີ 2000. ໃນປີ 2010, Google ໄດ້ພິມເຜີຍແຜ່ເອກະສານ, , ເຊິ່ງວາງພື້ນຖານສໍາລັບເຄື່ອງມືຕິດຕາມຂອງ Twitter, Zipkin, ປ່ອຍອອກມາໃນປີ 2012. Dapper, ໂຄງສ້າງພື້ນຖານການຕິດຕາມລະບົບການແຈກຢາຍຂະໜາດໃຫຍ່ ໃນປີ 2014, Kubernetes ປະກົດຕົວຂຶ້ນ, ເຮັດໃຫ້ການພັດທະນາຂອງບໍລິການຈຸລະພາກ ແລະລະບົບການແຈກຢາຍຄລາວອື່ນໆງ່າຍຂຶ້ນ. ອັນນີ້ເຮັດໃຫ້ຫຼາຍບໍລິສັດປະສົບບັນຫາກັບການຕັດໄມ້ແຈກຢາຍ ແລະການຕິດຕາມໃນບໍລິການຈຸລະພາກ. ເພື່ອສ້າງມາດຕະຖານການຕິດຕາມແບບແຈກຢາຍ, ມາດຕະຖານ OpenTracing, ຮັບຮອງເອົາໂດຍ CNCF, ແລະໂຄງການ OpenCensus ຂອງ Google ໄດ້ຖືກສ້າງຂື້ນ. ໃນປີ 2019, ໂຄງການ OpenTracing ແລະ OpenCensus ໄດ້ປະກາດການລວມຕົວພາຍໃຕ້ຊື່ OpenTelemetry. ແພລະຕະຟອມນີ້ລວມເອົາການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ສະສົມມາຫຼາຍປີ, ຊ່ວຍໃຫ້ການເຊື່ອມໂຍງຂອງການຕິດຕາມ, ການຕັດໄມ້ແລະການວັດແທກເຂົ້າໄປໃນລະບົບໃດກໍ່ຕາມ, ໂດຍບໍ່ຄໍານຶງເຖິງຄວາມສັບສົນຂອງມັນ. ໃນມື້ນີ້, OpenTelemetry ບໍ່ພຽງແຕ່ເປັນໂຄງການ; ມັນເປັນມາດຕະຖານອຸດສາຫະກໍາສໍາລັບການເກັບກໍາແລະສົ່ງຂໍ້ມູນ telemetry. ມັນໄດ້ຖືກພັດທະນາແລະສະຫນັບສະຫນູນໂດຍຊຸມຊົນຂອງຜູ້ຊ່ຽວຊານແລະບໍລິສັດຊັ້ນນໍາຂອງຕະຫຼາດເຊັ່ນ Google ແລະ Microsoft. ໂຄງການດັ່ງກ່າວສືບຕໍ່ພັດທະນາ, ເພີ່ມທະວີຄວາມສາມາດໃຫມ່ເພື່ອເຮັດໃຫ້ຂະບວນການເຊື່ອມໂຍງແລະການນໍາໃຊ້ງ່າຍດາຍ. ພາຍໃນແມ່ນຫຍັງ? OpenTelemetry ແມ່ນຊຸດການປະຕິບັດທີ່ສົມບູນແບບແລະເຄື່ອງມືທີ່ກໍານົດສິ່ງທີ່ສັນຍານທີ່ແອັບພລິເຄຊັນສາມາດສ້າງເພື່ອພົວພັນກັບໂລກພາຍນອກ, ແລະວິທີທີ່ສັນຍານເຫຼົ່ານີ້ສາມາດເກັບກໍາແລະເບິ່ງເຫັນເພື່ອຕິດຕາມສະພາບຂອງແອັບພລິເຄຊັນແລະລະບົບທັງຫມົດ. ສາມປະເພດຂອງສັນຍານຕົ້ນຕໍແມ່ນ , ແລະ . ການຕິດຕາມ, ການບັນທຶກ ການເກັບກໍາຕົວຊີ້ວັດ ** ໃຫ້ເຮົາເບິ່ງຢ່າງໃກ້ຊິດຢູ່ໃນແຕ່ລະອົງປະກອບ: \ ບໍລິບົດ OpenTelemetry ແນະນໍາແນວຄວາມຄິດຂອງສະພາບການດໍາເນີນງານ. ບໍລິບົດຕົ້ນຕໍປະກອບມີຄຸນລັກສະນະເຊັ່ນ: (ຕົວລະບຸການດໍາເນີນການໃນປະຈຸບັນ) ແລະ (ຕົວລະບຸສໍາລັບຄໍາຮ້ອງຂໍຍ່ອຍ, ໂດຍແຕ່ລະຄໍາຮ້ອງຂໍຍ່ອຍຄືນໃຫມ່ມີ ເປັນເອກະລັກ). `trace_id` `span_id` `span_id` ນອກຈາກນັ້ນ, ບໍລິບົດສາມາດມີຂໍ້ມູນສະຖິດ, ເຊັ່ນຊື່ node ທີ່ແອັບພລິເຄຊັນຖືກນຳໃຊ້ ຫຼືຊື່ສະພາບແວດລ້ອມ (prod/qa). ຊ່ອງຂໍ້ມູນເຫຼົ່ານີ້, ເອີ້ນວ່າຊັບພະຍາກອນໃນຄໍາສັບ OpenTelemetry, ແມ່ນຕິດກັບທຸກໆບັນທຶກ, metric, ຫຼືການຕິດຕາມເພື່ອໃຫ້ສາມາດຄົ້ນຫາໄດ້ງ່າຍຂຶ້ນ. ບໍລິບົດຍັງສາມາດລວມເອົາຂໍ້ມູນແບບເຄື່ອນໄຫວ ເຊັ່ນ: ຕົວລະບຸຈຸດສິ້ນສຸດປັດຈຸບັນ ( ), ເຊິ່ງສາມາດຄັດຕິດຄັດຕິດກັບກຸ່ມບັນທຶກ, ເມຕຣິກ, ຫຼືການຕິດຕາມ. `http_path: "GET /user/:id/info"` ບໍລິບົດ OpenTelemetry ສາມາດສົ່ງຜ່ານລະຫວ່າງແອັບພລິເຄຊັນຕ່າງໆ ໂດຍໃຊ້ໂປຣໂຕຄອນການຂະຫຍາຍບໍລິບົດ. ໂປໂຕຄອນເຫຼົ່ານີ້ປະກອບດ້ວຍຊຸດສ່ວນຫົວທີ່ຖືກເພີ່ມໃສ່ທຸກຄໍາຮ້ອງຂໍ HTTP ຫຼື gRPC ຫຼືສ່ວນຫົວຂອງຂໍ້ຄວາມສໍາລັບຄິວ. ນີ້ອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນລຸ່ມສາມາດສ້າງສະພາບການເຮັດວຽກຄືນໃຫມ່ຈາກສ່ວນຫົວເຫຼົ່ານີ້. ນີ້ແມ່ນບາງຕົວຢ່າງຂອງການຂະຫຍາຍເນື້ອໃນ: ນີ້ແມ່ນຊຸດຂອງສ່ວນຫົວ ( ) ພັດທະນາໃນເບື້ອງຕົ້ນສໍາລັບລະບົບການຕິດຕາມ Zipkin. ມັນໄດ້ຖືກດັດແປງເຂົ້າໃນ OpenTracing ແລະຖືກນໍາໃຊ້ໂດຍເຄື່ອງມືແລະຫ້ອງສະຫມຸດຈໍານວນຫຼາຍ. B3-Propagation ປະຕິບັດ / ແລະທຸງຊີ້ບອກວ່າການເກັບຕົວຢ່າງແມ່ນມີຄວາມຈໍາເປັນ. B3-Propagation x-b3-* trace_id span_id ພັດທະນາໂດຍກຸ່ມການເຮັດວຽກຂອງ W3C, ມາດຕະຖານນີ້ລວມເອົາວິທີການຂະຫຍາຍພັນທຸກໍາເຂົ້າໄປໃນມາດຕະຖານດຽວແລະເປັນມາດຕະຖານໃນ OpenTelemetry. ຕົວຢ່າງທີ່ດີຂອງການນໍາໃຊ້ມາດຕະຖານເຫຼົ່ານີ້ແມ່ນການຕິດຕາມການປະຕິບັດຄໍາຮ້ອງຂໍຜ່ານ microservices ທີ່ປະຕິບັດດ້ວຍເຕັກໂນໂລຢີທີ່ແຕກຕ່າງກັນໂດຍບໍ່ມີການປະນີປະນອມໃນການກວດສອບແລະການແກ້ໄຂຄວາມຖືກຕ້ອງ. W3C Trace Context ການຕິດຕາມ Tracing ແມ່ນຂະບວນການຂອງການບັນທຶກແລະຕໍ່ມາ visualizing ໄລຍະເວລາຂອງເສັ້ນທາງການຮ້ອງຂໍຜ່ານ microservices ຫຼາຍ. ໃນການເບິ່ງເຫັນ, ແຕ່ລະແຖບແມ່ນເອີ້ນວ່າ "span" ແລະມີ ເປັນເອກະລັກ . ໄລຍະຮາກແມ່ນເອີ້ນວ່າ ແລະມີ , ເຊິ່ງເຮັດຫນ້າທີ່ເປັນຕົວລະບຸສໍາລັບຄໍາຮ້ອງຂໍທັງຫມົດ. "span_id" "trace" "trace_id" ປະເພດຂອງການເບິ່ງເຫັນນີ້ອະນຸຍາດໃຫ້ທ່ານ: ວິເຄາະເວລາປະຕິບັດການຮ້ອງຂໍໃນທົ່ວລະບົບແລະຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນເພື່ອກໍານົດຂໍ້ບົກພ່ອງທີ່ຕ້ອງການການເພີ່ມປະສິດທິພາບ. ກວດພົບການຂຶ້ນກັບຮອບວຽນລະຫວ່າງການບໍລິການ. ຊອກຫາການຮ້ອງຂໍຊ້ໍາກັນ. ການນໍາໃຊ້ຂໍ້ມູນການຕິດຕາມ, ທ່ານຍັງສາມາດສ້າງການວິເຄາະເພີ່ມເຕີມ, ເຊັ່ນການສ້າງແຜນທີ່ microservices ຫຼືການແຈກຢາຍເວລາໃນທົ່ວລະບົບຕ່າງໆໃນລະຫວ່າງການດໍາເນີນການປະຕິບັດງານ. ເຖິງແມ່ນວ່າທ່ານຈະບໍ່ໃຊ້ຂໍ້ມູນການຕິດຕາມເພື່ອສະແດງພາບເວລາ, OpenTelemetry ຍັງສ້າງ ແລະ ເພື່ອໃຊ້ໃນສັນຍານອື່ນໆ. trace_id span_id ບັນທຶກ ເຖິງວ່າຈະມີຄວາມງ່າຍດາຍທີ່ປາກົດຂື້ນ, ການຕັດໄມ້ຍັງຄົງເປັນເຄື່ອງມືທີ່ມີປະສິດທິພາບທີ່ສຸດສໍາລັບການວິນິດໄສບັນຫາ. OpenTelemetry ປັບປຸງການບັນທຶກແບບດັ້ງເດີມໂດຍການເພີ່ມຂໍ້ມູນບໍລິບົດ. ໂດຍສະເພາະ, ຖ້າມີການຕິດຕາມທີ່ເຄື່ອນໄຫວຢູ່, ຄຸນສົມບັດ `trace_id` ແລະ `span_id` ຈະຖືກເພີ່ມໃສ່ບັນທຶກໂດຍອັດຕະໂນມັດ, ເຊື່ອມຕໍ່ພວກມັນກັບເສັ້ນເວລາຕິດຕາມ. ຍິ່ງໄປກວ່ານັ້ນ, ຄຸນລັກສະນະຂອງບັນທຶກສາມາດປະກອບມີຂໍ້ມູນສະຖິດຈາກບໍລິບົດ OpenTelemetry, ເຊັ່ນ: ຕົວລະບຸ node, ເຊັ່ນດຽວກັນກັບຂໍ້ມູນແບບເຄື່ອນໄຫວ, ເຊັ່ນ: ຕົວລະບຸຈຸດສິ້ນສຸດ HTTP (`http_path: "GET /user/:id"`). ການນໍາໃຊ້ `trace_id`, ທ່ານສາມາດຊອກຫາບັນທຶກຈາກ microservices ທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບຄໍາຮ້ອງຂໍໃນປະຈຸບັນ, ໃນຂະນະທີ່ `span_id` ຊ່ວຍໃຫ້ທ່ານສາມາດແຍກຄວາມແຕກຕ່າງລະຫວ່າງຄໍາຮ້ອງຂໍຍ່ອຍ. ຕົວຢ່າງ, ໃນກໍລະນີຂອງການພະຍາຍາມໃຫມ່, ບັນທຶກຈາກຄວາມພະຍາຍາມທີ່ແຕກຕ່າງກັນຈະມີ `span_id` ທີ່ແຕກຕ່າງກັນ. ການນໍາໃຊ້ຕົວລະບຸເຫຼົ່ານີ້ເຮັດໃຫ້ການວິເຄາະໄວຂອງພຶດຕິກໍາຂອງລະບົບທັງຫມົດໃນເວລາທີ່ແທ້ຈິງ, ເລັ່ງການວິນິດໄສບັນຫາແລະເພີ່ມຄວາມຫມັ້ນຄົງແລະຄວາມຫນ້າເຊື່ອຖື. ເມຕຣິກ ການເກັບກໍາການວັດແທກໃຫ້ຂໍ້ມູນປະລິມານການປະຕິບັດຂອງລະບົບ, ເຊັ່ນ: latency, ອັດຕາຄວາມຜິດພາດ, ການນໍາໃຊ້ຊັບພະຍາກອນ, ແລະອື່ນໆອີກ. ການກວດສອບການວັດແທກແບບສົດໆຊ່ວຍໃຫ້ທ່ານສາມາດຕອບສະຫນອງຕໍ່ການປ່ຽນແປງການປະຕິບັດໄດ້ທັນທີ, ປ້ອງກັນຄວາມລົ້ມເຫລວແລະຄວາມຫມົດຂອງຊັບພະຍາກອນ, ແລະຮັບປະກັນຄວາມພ້ອມແລະຄວາມຫນ້າເຊື່ອຖືສູງຂອງແອັບພລິເຄຊັນສໍາລັບຜູ້ໃຊ້. ການປະສົມປະສານກັບລະບົບການເກັບຮັກສາ metric ແລະການສະແດງພາບເຊັ່ນ Prometheus ແລະ Grafana ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການເບິ່ງເຫັນຂໍ້ມູນນີ້, ເຮັດໃຫ້ການຕິດຕາມງ່າຍຂຶ້ນຫຼາຍ. ຕົວເກັບຄ່າ Metric ຕົວເກັບຄ່າ OpenTelemetry ແມ່ນເຂົ້າກັນໄດ້ກັບມາດຕະຖານ Prometheus ແລະ OpenMetrics, ເຊິ່ງເຮັດໃຫ້ການຫັນປ່ຽນໄປສູ່ການແກ້ໄຂ OpenTelemetry ໄດ້ງ່າຍໂດຍບໍ່ມີການປ່ຽນແປງທີ່ສໍາຄັນ. OpenTelemetry SDK ອະນຸຍາດໃຫ້ຕົວຢ່າງ trace_id ຖືກສົ່ງອອກພ້ອມກັບ metrics, ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເຊື່ອມໂຍງ metrics ກັບຕົວຢ່າງບັນທຶກແລະການຕິດຕາມ. ຄວາມສຳພັນຂອງສັນຍານ ຮ່ວມກັນ, ບັນທຶກ, metrics, ແລະ tracing ສ້າງມຸມເບິ່ງທີ່ສົມບູນແບບຂອງສະຖານະຂອງລະບົບ: ບັນທຶກໃຫ້ຂໍ້ມູນກ່ຽວກັບເຫດການຂອງລະບົບ, ຊ່ວຍໃຫ້ການກໍານົດໄວແລະການແກ້ໄຂຄວາມຜິດພາດ. Metrics ສະທ້ອນເຖິງຕົວຊີ້ບອກປະສິດທິພາບດ້ານຄຸນນະພາບ ແລະປະລິມານຂອງລະບົບ, ເຊັ່ນ: ເວລາຕອບສະໜອງ ຫຼືອັດຕາຄວາມຜິດພາດ. Tracing ຕື່ມຂໍ້ມູນໃສ່ທັດສະນະນີ້ໂດຍການສະແດງເສັ້ນທາງຂອງການປະຕິບັດການຮ້ອງຂໍຜ່ານອົງປະກອບຂອງລະບົບຕ່າງໆ, ຊ່ວຍໃຫ້ເຂົ້າໃຈການພົວພັນລະຫວ່າງກັນ. ຄວາມສໍາພັນທີ່ຊັດເຈນລະຫວ່າງບັນທຶກ, ຮ່ອງຮອຍ, ແລະການວັດແທກແມ່ນລັກສະນະທີ່ໂດດເດັ່ນຂອງ OpenTelemetry. ສໍາລັບຕົວຢ່າງ, Grafana ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດເຫັນການຕິດຕາມທີ່ສອດຄ້ອງກັນແລະຮ້ອງຂໍ metrics ໃນເວລາເບິ່ງບັນທຶກ, ເສີມຂະຫຍາຍການນໍາໃຊ້ແລະປະສິດທິພາບຂອງເວທີຢ່າງຫຼວງຫຼາຍ. ນອກເຫນືອໄປຈາກສາມອົງປະກອບຫຼັກ, OpenTelemetry ປະກອບມີແນວຄວາມຄິດຂອງການເກັບຕົວຢ່າງ, ກະເປົ໋າ, ແລະການຈັດການບໍລິບົດການດໍາເນີນງານ. ການເກັບຕົວຢ່າງ ໃນລະບົບການໂຫຼດສູງ, ປະລິມານຂອງບັນທຶກແລະຮ່ອງຮອຍກາຍເປັນອັນໃຫຍ່ຫຼວງ, ຮຽກຮ້ອງໃຫ້ມີຊັບພະຍາກອນຢ່າງຫຼວງຫຼາຍສໍາລັບໂຄງສ້າງພື້ນຖານແລະການເກັບຮັກສາຂໍ້ມູນ. ເພື່ອແກ້ໄຂບັນຫານີ້, ມາດຕະຖານ OpenTelemetry ປະກອບມີການເກັບຕົວຢ່າງສັນຍານ - ຄວາມສາມາດໃນການສົ່ງອອກພຽງແຕ່ບາງສ່ວນຂອງການຕິດຕາມແລະບັນທຶກ. ຕົວຢ່າງ, ທ່ານສາມາດສົ່ງອອກສັນຍານລາຍລະອຽດຈາກເປີເຊັນຂອງຄໍາຮ້ອງຂໍ, ການຮ້ອງຂໍທີ່ຍາວນານ, ຫຼືຄໍາຮ້ອງຂໍຄວາມຜິດພາດ. ວິທີການນີ້ອະນຸຍາດໃຫ້ມີການເກັບຕົວຢ່າງພຽງພໍເພື່ອສ້າງສະຖິຕິໃນຂະນະທີ່ປະຫຍັດຊັບພະຍາກອນທີ່ສໍາຄັນ. ຢ່າງໃດກໍຕາມ, ຖ້າແຕ່ລະລະບົບຕັດສິນໃຈຢ່າງເປັນເອກະລາດວ່າຄໍາຮ້ອງຂໍທີ່ຈະຕິດຕາມລາຍລະອຽດ, ພວກເຮົາສິ້ນສຸດດ້ວຍທັດສະນະທີ່ແຕກແຍກຂອງແຕ່ລະຄໍາຮ້ອງຂໍ. ບາງລະບົບອາດຈະສົ່ງອອກຂໍ້ມູນລະອຽດ ໃນຂະນະທີ່ບາງລະບົບອາດຈະສົ່ງອອກບາງສ່ວນ ຫຼືບໍ່ໄດ້ສົ່ງອອກທັງໝົດ. ເພື່ອແກ້ໄຂບັນຫານີ້, ກົນໄກການຂະຫຍາຍບໍລິບົດຂອງ OpenTelemetry ສົ່ງທຸງຕົວຢ່າງພ້ອມກັບ `trace_id`/`span_id`. ນີ້ຮັບປະກັນວ່າຖ້າການບໍລິການເບື້ອງຕົ້ນທີ່ໄດ້ຮັບຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ຕັດສິນໃຈວ່າການຮ້ອງຂໍຄວນໄດ້ຮັບການຕິດຕາມຢ່າງລະອຽດ, ລະບົບອື່ນໆທັງຫມົດຈະປະຕິບັດຕາມ. ຖ້າບໍ່ດັ່ງນັ້ນ, ລະບົບທັງໝົດຄວນສົ່ງສັນຍານບາງສ່ວນ ຫຼື ບໍ່ສົ່ງອອກເພື່ອອະນຸລັກຊັບພະຍາກອນ. ວິທີການນີ້ເອີ້ນວ່າ "ການເກັບຕົວຢ່າງຫົວ" — ການຕັດສິນໃຈທີ່ເຮັດໃນຕອນເລີ່ມຕົ້ນຂອງການດໍາເນີນການຮ້ອງຂໍ, ບໍ່ວ່າຈະເປັນແບບສຸ່ມຫຼືອີງໃສ່ຄຸນລັກສະນະການປ້ອນຂໍ້ມູນບາງຢ່າງ. ນອກຈາກນັ້ນ, OpenTelemetry ສະຫນັບສະຫນູນ "Tail Sampling," ບ່ອນທີ່ທຸກຄໍາຮ້ອງສະຫມັກສະເຫມີສົ່ງອອກສັນຍານທັງຫມົດໃນລາຍລະອຽດ, ແຕ່ວ່າມີ buffer ລະດັບກາງ. ຫຼັງຈາກເກັບກໍາຂໍ້ມູນທັງຫມົດ, buffer ນີ້ຕັດສິນໃຈວ່າຈະເກັບຂໍ້ມູນເຕັມຫຼືເກັບຕົວຢ່າງບາງສ່ວນເທົ່ານັ້ນ. ວິທີການນີ້ອະນຸຍາດໃຫ້ມີຕົວຢ່າງຕົວແທນເພີ່ມເຕີມຂອງແຕ່ລະປະເພດຄໍາຮ້ອງຂໍ (ສໍາເລັດ / ຍາວ / ຄວາມຜິດພາດ) ແຕ່ຕ້ອງການການຕິດຕັ້ງໂຄງສ້າງພື້ນຖານເພີ່ມເຕີມ. ກະເປົາ ກົນໄກການກະເປົ໋າອະນຸຍາດໃຫ້ສົ່ງຄູ່ຄີ-ມູນຄ່າຕາມຕົນຕົວພ້ອມກັບ / , ຖ່າຍທອດອັດຕະໂນມັດລະຫວ່າງ microservices ທັງໝົດໃນລະຫວ່າງການປະມວນຜົນການຮ້ອງຂໍ. ອັນນີ້ເປັນປະໂຫຍດສໍາລັບການສົ່ງຂໍ້ມູນເພີ່ມເຕີມທີ່ຈໍາເປັນໃນທົ່ວເສັ້ນທາງການຮ້ອງຂໍ - ເຊັ່ນ: ຂໍ້ມູນຜູ້ໃຊ້ຫຼືການຕັ້ງຄ່າສະພາບແວດລ້ອມເວລາແລ່ນ. trace_id span_id ຕົວຢ່າງຂອງສ່ວນຫົວສຳລັບການສົ່ງກະເປົ໋າຕາມມາດຕະຖານ W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5 ນີ້ແມ່ນບາງຕົວຢ່າງຂອງການໃຊ້ກະເປົາ: ເຊັ່ນ , , ຫຼື ສາມາດຜ່ານ microservices ທັງໝົດໄດ້. ແອັບພລິເຄຊັນສາມາດບັນທຶກຂໍ້ມູນນີ້ໂດຍອັດຕະໂນມັດ, ອະນຸຍາດໃຫ້ຊອກຫາບັນທຶກໂດຍບໍລິບົດຂອງຜູ້ໃຊ້ສໍາລັບການຮ້ອງຂໍຕົ້ນສະບັບ. ການຖ່າຍທອດຂໍ້ມູນບໍລິບົດທາງທຸລະກິດ userId productId deviceId ການຕັ້ງຄ່າ ສໍາລັບ SDKs ຫຼືໂຄງສ້າງພື້ນຖານ. ຕົວກໍານົດການສະເພາະ ທຸງທີ່ຊ່ວຍໃຫ້ຜູ້ດຸ່ນດ່ຽງການໂຫຼດເຮັດການຕັດສິນໃຈກໍານົດເສັ້ນທາງ. ໃນລະຫວ່າງການທົດສອບ, ບາງຄໍາຮ້ອງສະຫມັກອາດຈະຈໍາເປັນຕ້ອງໄດ້ຮັບການນໍາທາງເພື່ອຈໍາລອງ backends. ເນື່ອງຈາກກະເປົ໋າຖືກສົ່ງໂດຍອັດຕະໂນມັດຜ່ານການບໍລິການທັງຫມົດ, ບໍ່ຈໍາເປັນຕ້ອງສ້າງໂປໂຕຄອນເພີ່ມເຕີມ - ພຽງແຕ່ຕັ້ງກົດລະບຽບກ່ຽວກັບການດຸ່ນດ່ຽງການໂຫຼດ. Routing Flags ໃຫ້ສັງເກດວ່າໃນຂະນະທີ່ຜົນກະທົບການປະຕິບັດຂອງກະເປົ໋າມີຫນ້ອຍ, ການນໍາໃຊ້ຫຼາຍເກີນໄປສາມາດເພີ່ມການໂຫຼດເຄືອຂ່າຍແລະການບໍລິການຢ່າງຫຼວງຫຼາຍ. ລະມັດລະວັງເລືອກຂໍ້ມູນໃດນຶ່ງທີ່ເຈົ້າຕ້ອງການຈະຜ່ານກະເປົ໋າເພື່ອຫຼີກເວັ້ນບັນຫາປະສິດທິພາບ. ການຈັດຕັ້ງປະຕິບັດໂຄງສ້າງພື້ນຖານ ການປະຕິບັດ OpenTelemetry ໃນລະດັບພື້ນຖານໂຄງລ່າງກ່ຽວຂ້ອງກັບການລວມເອົາ OpenTelemetry backends ເຂົ້າໄປໃນສະຖາປັດຕະຍະກໍາຂອງແອັບພລິເຄຊັນແລະການຕັ້ງຄ່າໂຄງສ້າງພື້ນຖານສໍາລັບການລວບລວມຂໍ້ມູນ. ຂະບວນການປະກອບດ້ວຍສີ່ຂັ້ນຕອນ: ໃນຂັ້ນຕອນທໍາອິດ, OpenTelemetry SDKs ຖືກປະສົມປະສານໂດຍກົງເຂົ້າໃນແອັບພລິເຄຊັນເພື່ອເກັບກໍາຂໍ້ມູນ metrics, ບັນທຶກແລະການຕິດຕາມ, ຮັບປະກັນການໄຫຼເຂົ້າຢ່າງຕໍ່ເນື່ອງຂອງຂໍ້ມູນກ່ຽວກັບການປະຕິບັດຂອງແຕ່ລະອົງປະກອບຂອງລະບົບ. ການເຊື່ອມໂຍງແອັບພລິເຄຊັນ ເກັບກໍາຂໍ້ມູນຖືກສົ່ງຈາກແອັບພລິເຄຊັນຜ່ານຜູ້ສົ່ງອອກໄປຫາລະບົບພາຍນອກເພື່ອດໍາເນີນການຕໍ່ໄປ, ເຊັ່ນ: ການບັນທຶກ, ການຕິດຕາມ, ການຕິດຕາມ, ຫຼືລະບົບການວິເຄາະ, ຂຶ້ນກັບຄວາມຕ້ອງການຂອງທ່ານ. ການຕັ້ງຄ່າຜູ້ສົ່ງອອກທີ່ ຂັ້ນຕອນນີ້ອາດຈະກ່ຽວຂ້ອງກັບການເຮັດໃຫ້ຂໍ້ມູນປົກກະຕິ, ເຮັດໃຫ້ຂໍ້ມູນດັ່ງກ່າວມີຂໍ້ມູນເພີ່ມ, ແລະການລວມຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆເພື່ອສ້າງມຸມເບິ່ງລວມຂອງສະຖານະຂອງລະບົບ. ການຮວບຮວມແລະການເກັບຮັກສາ ສຸດທ້າຍ, ຂໍ້ມູນທີ່ຖືກປຸງແຕ່ງຖືກນໍາສະເຫນີເປັນ dashboards ໃນລະບົບເຊັ່ນ Grafana (ສໍາລັບ metrics ແລະ traces) ຫຼື Kibana (ສໍາລັບບັນທຶກ). ນີ້ເຮັດໃຫ້ທີມງານສາມາດປະເມີນສຸຂະພາບຂອງລະບົບໄດ້ໄວ, ກໍານົດບັນຫາແລະແນວໂນ້ມ, ແລະຕັ້ງການແຈ້ງເຕືອນໂດຍອີງໃສ່ສັນຍານທີ່ສ້າງຂຶ້ນ. Data Visualization ການປະຕິບັດຄໍາຮ້ອງສະຫມັກ ເພື່ອປະສົມປະສານກັບແອັບພລິເຄຊັນ, ທ່ານຈໍາເປັນຕ້ອງເຊື່ອມຕໍ່ OpenTelemetry SDK ທີ່ເຫມາະສົມສໍາລັບພາສາການຂຽນໂປລແກລມທີ່ໃຊ້ຫຼືຈ້າງຫ້ອງສະຫມຸດແລະກອບທີ່ສະຫນັບສະຫນູນ OpenTelemetry ໂດຍກົງ. OpenTelemetry ມັກຈະປະຕິບັດການໂຕ້ຕອບທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງຈາກຫ້ອງສະຫມຸດທີ່ຮູ້ຈັກ, ອະນຸຍາດໃຫ້ຫຼຸດລົງການທົດແທນ. ຕົວຢ່າງ, ຫ້ອງສະຫມຸດ Micrometer ແມ່ນຖືກນໍາໃຊ້ທົ່ວໄປສໍາລັບການລວບລວມ metrics ໃນລະບົບນິເວດ Java. OpenTelemetry SDK ສະຫນອງການປະຕິບັດຂອງຕົນຂອງການໂຕ້ຕອບໄມໂຄມິເຕີ, ເຮັດໃຫ້ການສົ່ງອອກ metric ໂດຍບໍ່ມີການປ່ຽນລະຫັດຄໍາຮ້ອງສະຫມັກຕົ້ນຕໍ. ຍິ່ງໄປກວ່ານັ້ນ, OpenTelemetry ສະຫນອງການປະຕິບັດຂອງ OpenTracing ແລະການໂຕ້ຕອບ OpenCensus ເກົ່າ, ອໍານວຍຄວາມສະດວກໃນການເຄື່ອນຍ້າຍໄປສູ່ OpenTelemetry. ສະຫຼຸບ ໃນລະບົບ IT, OpenTelemetry ສາມາດກາຍເປັນກຸນແຈສໍາລັບອະນາຄົດຂອງ backends ທີ່ເຊື່ອຖືໄດ້ແລະປະສິດທິພາບ. ເຄື່ອງມືນີ້ເຮັດໃຫ້ການດີບັກ ແລະການຕິດຕາມງ່າຍຂຶ້ນ ແລະຍັງເປີດໂອກາດໃຫ້ຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງກ່ຽວກັບປະສິດທິພາບຂອງແອັບພລິເຄຊັນ ແລະການເພີ່ມປະສິດທິພາບໃນລະດັບໃໝ່. ເຂົ້າຮ່ວມຊຸມຊົນ OpenTelemetry ເພື່ອຊ່ວຍສ້າງອະນາຄົດທີ່ການພັດທະນາ backend ແມ່ນງ່າຍດາຍແລະມີປະສິດທິພາບຫຼາຍຂຶ້ນ!