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

ພວກເຮົາມາຈາກບໍລິສັດ fintech Exness, ເຊິ່ງພັດທະນາການບໍລິການສໍາລັບການຊື້ຂາຍອອນໄລນ໌ແລະຜະລິດຕະພັນ fintech ສໍາລັບ B2B ແລະ B2C. R&D ຂອງພວກເຮົາມີຫຼາຍທີມງານທີ່ແຕກຕ່າງກັນ, ພະແນກພັດທະນາມີ 100+ ພະນັກງານ.

ພວກເຮົາເປັນຕົວແທນຂອງທີມງານທີ່ຮັບຜິດຊອບສໍາລັບເວທີສໍາລັບນັກພັດທະນາຂອງພວກເຮົາເພື່ອເກັບກໍາແລະດໍາເນີນການລະຫັດ. ໂດຍສະເພາະ, ພວກເຮົາຮັບຜິດຊອບໃນການເກັບກໍາ, ເກັບຮັກສາແລະລາຍງານ metrics, ບັນທຶກ, ແລະເຫດການຈາກຄໍາຮ້ອງສະຫມັກ. ໃນປັດຈຸບັນພວກເຮົາດໍາເນີນການປະມານສາມພັນ Docker containers ໃນສະພາບແວດລ້ອມການຜະລິດ, ຮັກສາການເກັບຮັກສາຂໍ້ມູນຂະຫນາດໃຫຍ່ 50 TB ຂອງພວກເຮົາ, ແລະສະຫນອງການແກ້ໄຂສະຖາປັດຕະທີ່ສ້າງຂຶ້ນອ້ອມຂ້າງພື້ນຖານໂຄງລ່າງຂອງພວກເຮົາ: Kubernetes, Rancher, ແລະຜູ້ໃຫ້ບໍລິການຟັງສາທາລະນະຕ່າງໆ. 

ແຮງຈູງໃຈຂອງພວກເຮົາ

ໄຟໄໝ້ແມ່ນຫຍັງ? ບໍ່ມີໃຜສາມາດຕອບໄດ້. ເຕົາໄຟຢູ່ໃສ? ມັນຍາກທີ່ຈະເຂົ້າໃຈ. ມັນຕິດໄຟເມື່ອໃດ? ທ່ານສາມາດຊອກຫາໄດ້, ແຕ່ບໍ່ແມ່ນທັນທີ. 

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

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

ຕົວແທນ

ເພື່ອເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນພາຍໃນ, ພວກເຮົາໄດ້ຕັດສິນໃຈຈັດວາງຕົວແທນໂດຍກົງໃສ່ຖັງ.

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

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

ຕົວແທນຍັງຫມາຍເຖິງຜົນປະໂຫຍດສໍາລັບການປະຕິບັດງານແລະການບໍາລຸງຮັກສາທີ່ສາມາດເຮັດວຽກຢູ່ໃນລະບົບ orchestration ທີ່ແຕກຕ່າງກັນທີ່ສະຫນັບສະຫນູນຮູບພາບທີ່ແຕກຕ່າງກັນ (Debian, Alpine, Centos, ແລະອື່ນໆ).

ສຸດທ້າຍ, ຕົວແທນຕ້ອງສະຫນັບສະຫນູນ CI/CD ງ່າຍໆທີ່ປະກອບມີໄຟລ໌ Docker. ຖ້າບໍ່ດັ່ງນັ້ນ, ເຮືອຈະລົ້ມລົງ, ເພາະວ່າຕູ້ຄອນເທນເນີຈະເລີ່ມຖືກຈັດສົ່ງຕາມທາງລົດໄຟ "ບິດ".

ຂະບວນການກໍ່ສ້າງແລະອຸປະກອນຮູບພາບເປົ້າຫມາຍ

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

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

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

ແມ່ນຫຍັງດີກ່ຽວກັບວິທີນີ້? 

• ຫນ້າທໍາອິດ, ການຄວບຄຸມສະບັບເຕັມຂອງເຄື່ອງມືການກໍ່ສ້າງ - build container, script and distribution versions . 
• ອັນທີສອງ, ພວກເຮົາໄດ້ບັນລຸມາດຕະຖານ: ພວກເຮົາສ້າງແມ່ແບບ, ຮູບພາບລະດັບປານກາງແລະພ້ອມທີ່ຈະໃຊ້ໃນແບບດຽວກັນ. 
• ອັນທີສາມ, ຕູ້ຄອນເທນເນີເຮັດໃຫ້ພວກເຮົາເຄື່ອນທີ່. ມື້ນີ້ພວກເຮົາໃຊ້ Gitlab, ແລະມື້ອື່ນພວກເຮົາຈະປ່ຽນເປັນ TeamCity ຫຼື Jenkins ແລະພວກເຮົາຈະສາມາດດໍາເນີນການບັນຈຸຂອງພວກເຮົາໃນແບບດຽວກັນ. 
• ສີ່, ຫຼຸດຜ່ອນຄວາມເພິ່ງພາອາໄສ. ມັນບໍ່ແມ່ນເລື່ອງບັງເອີນທີ່ພວກເຮົາເອົາຊຸດແຈກຈ່າຍໃສ່ໃນຖັງ, ເພາະວ່ານີ້ເຮັດໃຫ້ພວກເຮົາຫຼີກລ່ຽງການດາວໂຫຼດພວກມັນຈາກອິນເຕີເນັດທຸກຄັ້ງ. 
• ຫ້າ, ຄວາມໄວໃນການກໍ່ສ້າງໄດ້ເພີ່ມຂຶ້ນ - ການມີສໍາເນົາທ້ອງຖິ່ນຂອງຮູບພາບອະນຸຍາດໃຫ້ທ່ານເພື່ອຫຼີກເວັ້ນການເສຍເວລາໃນການດາວໂຫຼດ, ນັບຕັ້ງແຕ່ມີຮູບພາບທ້ອງຖິ່ນ. 

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

ວິທີການກໍ່ສ້າງຂອງພວກເຮົາເຮັດວຽກແນວໃດ

ການປະກອບໄດ້ຖືກເປີດຕົວດ້ວຍຄໍາສັ່ງຫນຶ່ງ, ຂະບວນການຖືກປະຕິບັດໃນຮູບພາບ (ເນັ້ນໃສ່ສີແດງ). ນັກພັດທະນາມີໄຟລ໌ Docker (ເນັ້ນໃສ່ສີເຫຼືອງ), ພວກເຮົາສະແດງມັນ, ແທນທີ່ຕົວແປດ້ວຍຄ່າ. ແລະຕາມວິທີທີ່ພວກເຮົາເພີ່ມ headers ແລະ footers - ເຫຼົ່ານີ້ແມ່ນຕົວແທນຂອງພວກເຮົາ. 

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

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

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

 

ສໍາລັບຖັງດຽວກັນພວກເຮົາໄດ້ຮັບຕົ້ນໄມ້ຂະບວນການທີ່ແຕກຕ່າງກັນໃນ Docker ແລະ Kubernetes:

payload ແມ່ນປະຕິບັດພາຍໃຕ້ການຊີ້ນໍາຂອງ S6. ເອົາໃຈໃສ່ກັບຜູ້ເກັບລວບລວມແລະເຫດການ - ເຫຼົ່ານີ້ແມ່ນຕົວແທນຂອງພວກເຮົາທີ່ຮັບຜິດຊອບສໍາລັບບັນທຶກແລະການວັດແທກ. Kubernetes ບໍ່ມີພວກມັນ, ແຕ່ Docker ເຮັດ. ເປັນຫຍັງ? 

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

ເມຕຣິກ ແລະບັນທຶກ

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

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

ລັກສະນະທີສາມແມ່ນວ່າມັນເປັນສິ່ງຈໍາເປັນເພື່ອສະຫນັບສະຫນູນວິທີການເກັບກໍາ metrics ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ອອກຈາກກ່ອງ. ຈາກການອ່ານໄຟລ໌ແລະການລົງຄະແນນສຽງ Prometheus-endpoint ກັບການນໍາໃຊ້ໂປໂຕຄອນສະເພາະຂອງແອັບພລິເຄຊັນ.

ແລະລັກສະນະສຸດທ້າຍແມ່ນເພື່ອຫຼຸດຜ່ອນການບໍລິໂພກຊັບພະຍາກອນ.

ພວກເຮົາໄດ້ເລືອກການແກ້ໄຂ Go ແຫຼ່ງເປີດທີ່ເອີ້ນວ່າ Telegraf. ນີ້ແມ່ນຕົວເຊື່ອມຕໍ່ທົ່ວໄປທີ່ສະຫນັບສະຫນູນຫຼາຍກ່ວາ 140 ປະເພດຂອງຊ່ອງທາງການປ້ອນຂໍ້ມູນ (ປລັກອິນປ້ອນຂໍ້ມູນ) ແລະ 30 ປະເພດຂອງຊ່ອງອອກ (ປລັກອິນອອກ). ພວກເຮົາໄດ້ສະຫຼຸບມັນແລະຕອນນີ້ພວກເຮົາຈະບອກທ່ານວ່າພວກເຮົາໃຊ້ມັນແນວໃດໂດຍໃຊ້ Kubernetes ເປັນຕົວຢ່າງ. 

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

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

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

ເມຕຣິກຖືກເກັບກຳໃນທົ່ວຕົວຢ່າງການໂຫຼດວຽກ (ຂະບວນການ) ໃນບັນຈຸ. ທຸກສິ່ງທຸກຢ່າງແມ່ນ tagged: namespace, ພາຍໃຕ້, ແລະອື່ນໆ, ແລະຫຼັງຈາກນັ້ນປ່ຽນເປັນຮູບແບບ Prometheus - ແລະກາຍເປັນທີ່ມີຢູ່ສໍາລັບການລວບລວມ (ຍົກເວັ້ນສໍາລັບບັນທຶກ). ພວກເຮົາຍັງສົ່ງບັນທຶກ, ວັດແທກແລະເຫດການໄປຫາ Kafka ແລະເພີ່ມເຕີມ:

• ບັນທຶກມີຢູ່ໃນ Graylog (ສໍາລັບການວິເຄາະສາຍຕາ);
• ບັນທຶກ, ວັດແທກ, ເຫດການຖືກສົ່ງໄປຫາ Clickhouse ສໍາລັບການເກັບຮັກສາໃນໄລຍະຍາວ.

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

ຖ້າພວກເຮົາບໍ່ມີ Kubernetes ກັບຝັກ, ໂຄງການແມ່ນສັບສົນເລັກນ້ອຍ, ແຕ່ມັນເຮັດວຽກຢູ່ໃນຫຼັກການດຽວກັນ.

ຂະບວນການດຽວກັນຖືກປະຕິບັດພາຍໃນບັນຈຸ, ພວກມັນຖືກຈັດຕັ້ງໂດຍໃຊ້ S6. ຂະບວນການດຽວກັນທັງຫມົດແມ່ນແລ່ນຢູ່ໃນຖັງດຽວກັນ.

ໃນທີ່ສຸດ

ພວກ​ເຮົາ​ໄດ້​ສ້າງ​ການ​ແກ້​ໄຂ​ຄົບ​ຖ້ວນ​ສົມ​ບູນ​ສໍາ​ລັບ​ການ​ກໍ່​ສ້າງ​ແລະ​ການ​ເປີດ​ຮູບ​ພາບ​, ມີ​ທາງ​ເລືອກ​ສໍາ​ລັບ​ການ​ເກັບ​ກໍາ​ແລະ​ການ​ສົ່ງ​ບັນ​ທຶກ​ແລະ​ມາດ​ຕະ​ຖານ​:

• ພວກ​ເຮົາ​ໄດ້​ພັດ​ທະ​ນາ​ວິ​ທີ​ການ​ມາດ​ຕະ​ຖານ​ໃນ​ການ​ປະ​ກອບ​ຮູບ​ພາບ​, ແລະ​ອີງ​ໃສ່​ມັນ​ພວກ​ເຮົາ​ໄດ້​ພັດ​ທະ​ນາ​ແມ່​ແບບ CI​;
• ຕົວແທນເກັບກໍາຂໍ້ມູນແມ່ນສ່ວນຂະຫຍາຍ Telegraf ຂອງພວກເຮົາ. ພວກເຮົາໄດ້ທົດສອບພວກມັນໄດ້ດີໃນການຜະລິດ;
• ພວກເຮົາໃຊ້ webhook mutation ເພື່ອປະຕິບັດພາຊະນະທີ່ມີຕົວແທນໃນຝັກ; 
• ປະສົມປະສານເຂົ້າໃນລະບົບນິເວດ Kubernetes/Rancher;
• ພວກເຮົາສາມາດປະຕິບັດການບັນຈຸດຽວກັນໃນລະບົບ orchestration ທີ່ແຕກຕ່າງກັນແລະໄດ້ຮັບຜົນທີ່ພວກເຮົາຄາດຫວັງ;
• ສ້າງການຕັ້ງຄ່າການຈັດການຕູ້ຄອນເທນເນີແບບເຄື່ອນໄຫວຢ່າງສົມບູນ. 

ຜູ້ຂຽນຮ່ວມ: Ilya Prudnikov

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