Yury Bushmelev "ແຜນທີ່ຂອງ rake ໃນພາກສະຫນາມຂອງການເກັບກໍາແລະສົ່ງໄມ້ທ່ອນ" - ຖອດຈາກບົດລາຍງານ

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

• ວິທີການຂຽນບັນທຶກຈາກແອັບພລິເຄຊັນ;
• ບ່ອນທີ່ຈະຂຽນບັນທຶກ;
• ວິທີການສົ່ງບັນທຶກສໍາລັບການເກັບຮັກສາແລະການປຸງແຕ່ງ;
• ວິທີການປຸງແຕ່ງແລະເກັບຮັກສາບັນທຶກ.

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

ພຽງແຕ່ກ່ຽວກັບເລື່ອງນີ້ແມ່ນບົດບັນທຶກຂອງບົດລາຍງານໂດຍ Yuri Bushmelev "ແຜນທີ່ຂອງ rake ໃນພາກສະຫນາມຂອງການເກັບກໍາແລະສົ່ງໄມ້ທ່ອນ"

ໃຜສົນໃຈ, ກະລຸນາພາຍໃຕ້ແມວ.

ຂ້ອຍຊື່ Yuri Bushmelev. ຂ້ອຍເຮັດວຽກໃຫ້ Lazada. ມື້​ນີ້​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ເວົ້າ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ທີ່​ພວກ​ເຮົາ​ເຮັດ​ບັນ​ທຶກ​ຂອງ​ພວກ​ເຮົາ, ວິ​ທີ​ການ​ທີ່​ພວກ​ເຮົາ​ເກັບ​ກໍາ​ມັນ, ແລະ​ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ຂຽນ​ໃນ​ທີ່​ນັ້ນ.

ພວກເຮົາມາຈາກໃສ? ພວກເຮົາແມ່ນໃຜ? Lazada ເປັນຮ້ານຂາຍຍ່ອຍອອນໄລນ໌ອັນດັບ 1 ໃນຫົກປະເທດໃນອາຊີຕາເວັນອອກສຽງໃຕ້. ປະເທດເຫຼົ່ານີ້ທັງຫມົດແມ່ນແຈກຢາຍລະຫວ່າງສູນຂໍ້ມູນ. ໃນປັດຈຸບັນມີສູນຂໍ້ມູນທັງໝົດ 4 ແຫ່ງ, ເປັນຫຍັງອັນນີ້ຈຶ່ງສຳຄັນ? ເນື່ອງຈາກວ່າບາງການຕັດສິນໃຈແມ່ນຍ້ອນຄວາມຈິງທີ່ວ່າມີການເຊື່ອມໂຍງທີ່ອ່ອນແອຫຼາຍລະຫວ່າງສູນກາງ. ພວກເຮົາມີສະຖາປັດຕະຍະກໍາ microservice. ຂ້ອຍແປກໃຈທີ່ພົບວ່າພວກເຮົາມີ 80 microservices ແລ້ວ. ໃນເວລາທີ່ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນວຽກງານທີ່ມີບັນທຶກ, ມີພຽງແຕ່ 20 ຂອງພວກເຂົາ. ນອກຈາກນັ້ນ, ມີມໍລະດົກຂອງ PHP ຫຼາຍ, ເຊິ່ງຂ້າພະເຈົ້າຍັງຕ້ອງດໍາລົງຊີວິດແລະເອົາໃຈໃສ່ກັບ. ທັງຫມົດນີ້ສ້າງສໍາລັບພວກເຮົາໃນປັດຈຸບັນຫຼາຍກ່ວາ 6 ລ້ານຂໍ້ຄວາມຕໍ່ນາທີສໍາລັບລະບົບທັງຫມົດ. ນອກຈາກນັ້ນ, ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ເຫັນວິທີການທີ່ພວກເຮົາກໍາລັງພະຍາຍາມດໍາລົງຊີວິດກັບສິ່ງນີ້, ແລະເປັນຫຍັງມັນເປັນດັ່ງນັ້ນ.

ທ່ານຕ້ອງອາໄສຢູ່ກັບ 6 ລ້ານຂໍ້ຄວາມເຫຼົ່ານີ້. ພວກເຮົາຄວນເຮັດແນວໃດກັບພວກເຂົາ? 6 ລ້ານຂໍ້ຄວາມທີ່ຕ້ອງການ:

• ສົ່ງ​ຈາກ app​
• ຍອມຮັບສໍາລັບການຈັດສົ່ງ
• ສົ່ງສໍາລັບການວິເຄາະແລະການເກັບຮັກສາ.
• ວິເຄາະ
• ເກັບຮັກສາ somehow.

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

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

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

ດ້ວຍ​ການ​ເກັບ​ກໍາ​ໄມ້​ທ່ອນ​, ສະ​ຖາ​ນະ​ການ​ແມ່ນ​ປະ​ມານ​ດຽວ​ກັນ​. ບໍ່ມີທາງເລືອກຫຼາຍສໍາລັບການແກ້ໄຂບັນຫານີ້ໂດຍສະເພາະ. ມີຫຼາຍກວ່ານັ້ນ, ແຕ່ບໍ່ມີຫຼາຍເທື່ອ.

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

ຂ້ອຍຈະສະແດງໃຫ້ເຈົ້າຮູ້ວ່າພວກເຮົາໄດ້ເຮັດມັນຢູ່ Lazada ແນວໃດ ແລະມັນເລີ່ມຕົ້ນແນວໃດ.

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

ໃຫ້ເບິ່ງຕື່ມອີກເລັກນ້ອຍ. ພວກເຮົາສົ່ງບັນທຶກເຫຼົ່ານີ້ແນວໃດ. ມີຄົນເລືອກຕົວແທນ td, ເຊິ່ງຕົວຈິງແລ້ວແມ່ນຄ່ອງແຄ້ວແຕ່ບໍ່ຄ່ອງແຄ້ວ. ຂ້າພະເຈົ້າຍັງບໍ່ເຂົ້າໃຈຄວາມສໍາພັນຂອງທັງສອງໂຄງການນີ້, ແຕ່ເບິ່ງຄືວ່າມັນເປັນເລື່ອງດຽວກັນ. ແລະນີ້ fluentd, ລາຍລັກອັກສອນໃນ Ruby, ອ່ານໄຟລ໌ບັນທຶກ, parsed ໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນ JSON ໂດຍໃຊ້ບາງສະແດງອອກປົກກະຕິ. ຫຼັງຈາກນັ້ນ, ພວກເຂົາຖືກສົ່ງໄປຫາ Kafka. ຍິ່ງໄປກວ່ານັ້ນ, ໃນ Kafka, ພວກເຮົາມີ 4 ຫົວຂໍ້ແຍກຕ່າງຫາກສໍາລັບແຕ່ລະ API. ເປັນຫຍັງ 4? ເນື່ອງຈາກວ່າມີການດໍາລົງຊີວິດ, ມີ staging, ແລະເນື່ອງຈາກວ່າມີ stdout ແລະ stderr. ນັກພັດທະນາຜະລິດພວກມັນ, ແລະພະນັກງານກໍ່ສ້າງພື້ນຖານໂຄງລ່າງຕ້ອງສ້າງພວກມັນຢູ່ໃນ Kafka. ຍິ່ງໄປກວ່ານັ້ນ, Kafka ໄດ້ຖືກຄວບຄຸມໂດຍພະແນກອື່ນ. ດັ່ງນັ້ນ, ມັນຈໍາເປັນຕ້ອງສ້າງປີ້ເພື່ອໃຫ້ພວກເຂົາສ້າງ 4 ຫົວຂໍ້ຢູ່ທີ່ນັ້ນສໍາລັບແຕ່ລະ api. ທຸກຄົນລືມກ່ຽວກັບມັນ. ໂດຍທົ່ວໄປ, ມັນແມ່ນຂີ້ເຫຍື້ອແລະສິ່ງເສດເຫຼືອ.

ພວກເຮົາໄດ້ເຮັດຫຍັງຕໍ່ໄປກັບມັນ? ພວກເຮົາສົ່ງມັນໄປ kafka. ຕໍ່ໄປຈາກ Kafka, ເຄິ່ງຫນຶ່ງຂອງໄມ້ທ່ອນໄດ້ບິນໄປ Logstash. ອີກເຄິ່ງຫນຶ່ງຂອງໄມ້ທ່ອນໄດ້ຖືກແບ່ງປັນ. ບາງຄົນບິນໄປຫາ Greylog ອື່ນ, ບາງຄົນໄປ Greylog ອື່ນ. ດັ່ງນັ້ນ, ທັງຫມົດນີ້ໄດ້ບິນເຂົ້າໄປໃນກຸ່ມ Elasticsearch ດຽວ. ນັ້ນແມ່ນ, ຄວາມສັບສົນທັງຫມົດນີ້ໄດ້ຫຼຸດລົງໃນທີ່ສຸດ. ເຈົ້າບໍ່ຕ້ອງເຮັດແນວນັ້ນ!

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

ທີ່ນີ້ (1,2,3) ພວກເຮົາຂຽນໄຟລ໌ແລະ, ຕາມຄວາມເຫມາະສົມ, ມີສາມ rakes ທີ່ນີ້ໃນເວລາດຽວກັນ.

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

ຈຸດທີສອງ (2,3) ແມ່ນວ່າພວກເຮົາມີຄໍາຮ້ອງຂໍຫຼາຍທີ່ເຂົ້າມາ API. API ຂຽນຂໍ້ມູນຈໍານວນຫລາຍໃສ່ໄຟລ໌. ໄຟລ໌ກໍາລັງເຕີບໂຕ. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຫມຸນພວກມັນ. ເນື່ອງຈາກວ່າຖ້າບໍ່ດັ່ງນັ້ນທ່ານຈະບໍ່ສາມາດບັນທຶກແຜ່ນໃດໆຢູ່ທີ່ນັ້ນ. ການຫມຸນພວກມັນບໍ່ດີເພາະວ່າພວກມັນຖືກໂອນຜ່ານແກະໄປຫາໄດເລກະທໍລີ. ບໍ່ມີວິທີທີ່ພວກເຮົາສາມາດຫມຸນມັນ. ທ່ານບໍ່ສາມາດບອກແອັບພລິເຄຊັນໃຫ້ເປີດໂຕຈັບຄືນໄດ້. ເພາະວ່ານັກພັດທະນາຈະເບິ່ງເຈົ້າຄືກັບຄົນໂງ່: "ສິ່ງທີ່ອະທິບາຍ? ໂດຍທົ່ວໄປແລ້ວພວກເຮົາຂຽນເຖິງ stdout. ກອບການເຮັດໃຫ້ copytruncate ເຂົ້າໄປໃນ logrotate, ເຊິ່ງພຽງແຕ່ເຮັດໃຫ້ສໍາເນົາຂອງໄຟລ໌ແລະ trunks ຕົ້ນສະບັບ. ຕາມນັ້ນແລ້ວ, ລະຫວ່າງຂະບວນການຄັດລອກເຫຼົ່ານີ້, ພື້ນທີ່ດິດມັກຈະຫມົດໄປ.

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

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

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

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

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

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

ພວກເຮົາເລີ່ມຕົ້ນແກ້ໄຂບັນຫາແນວໃດ? rake ຕົ້ນຕໍແມ່ນກັບ td-agent. ມັນບໍ່ຈະແຈ້ງວ່າໄມ້ທ່ອນຂອງພວກເຮົາໄປໃສ. ເຂົາເຈົ້າຈັດສົ່ງບໍ? ເຂົາເຈົ້າໄປບໍ? ແລ້ວພວກເຂົາຢູ່ໃສ? ດັ່ງນັ້ນ, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະທົດແທນ td-agent ດ້ວຍລາຍການທໍາອິດ. ທາງເລືອກສໍາລັບສິ່ງທີ່ຈະທົດແທນມັນ, ຂ້າພະເຈົ້າໄດ້ອະທິບາຍສັ້ນໆຢູ່ທີ່ນີ້.

ຄ່ອງແຄ້ວ. ກ່ອນອື່ນ ໝົດ, ຂ້ອຍພົບລາວຢູ່ບ່ອນເຮັດວຽກກ່ອນ ໜ້າ ນີ້, ແລະລາວກໍ່ລົ້ມລົງເປັນໄລຍະ. ອັນທີສອງ, ນີ້ແມ່ນຄືກັນ, ພຽງແຕ່ຢູ່ໃນໂປຣໄຟລ໌.

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

ການແກ້ໄຂທີ່ຊັດເຈນສໍາລັບ sysadmin ແມ່ນທຸກປະເພດຂອງ syslogs ໃນປະລິມານນີ້ (syslog-ng / rsyslog / nxlog).

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

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

ແລະເລັກນ້ອຍກ່ຽວກັບ rsyslog. ຫນ້າທໍາອິດ, ມັນເຢັນເນື່ອງຈາກວ່າມັນມີໂມດູນຫຼາຍ. ມັນມີ RainerScript ທີ່ມະນຸດສາມາດອ່ານໄດ້ (ພາສາການຕັ້ງຄ່າທີ່ທັນສະໄຫມ). ໂບນັດທີ່ຫນ້າຫວາດສຽວແມ່ນວ່າພວກເຮົາສາມາດເຮັດຕາມພຶດຕິກໍາຂອງ td-agent ດ້ວຍເຄື່ອງມືມາດຕະຖານຂອງມັນ, ແລະບໍ່ມີຫຍັງປ່ຽນແປງສໍາລັບຄໍາຮ້ອງສະຫມັກ. ນັ້ນແມ່ນ, ພວກເຮົາປ່ຽນ td-agent ເປັນ rsyslog, ແລະບໍ່ແຕະທຸກຢ່າງອື່ນ. ແລະທັນທີພວກເຮົາໄດ້ຮັບການຈັດສົ່ງທີ່ເຮັດວຽກ. ຕໍ່ໄປ, mmnormalize ແມ່ນສິ່ງທີ່ເຢັນກ່ຽວກັບ rsyslog. ມັນອະນຸຍາດໃຫ້ທ່ານສາມາດວິເຄາະບັນທຶກ, ແຕ່ບໍ່ແມ່ນກັບ Grok ແລະ regexp. ມັນເຮັດໃຫ້ຕົ້ນໄມ້ syntax ທີ່ບໍ່ມີຕົວຕົນ. ມັນ parses ບັນທຶກໃນຫຼາຍວິທີດຽວກັນທີ່ compiler parses ລະຫັດແຫຼ່ງ. ນີ້ອະນຸຍາດໃຫ້ທ່ານເຮັດວຽກໄວຫຼາຍ, ກິນ CPU ພຽງເລັກນ້ອຍ, ແລະໂດຍທົ່ວໄປ, ມັນເປັນພຽງແຕ່ສິ່ງທີ່ເຢັນຫຼາຍ. ມີໂບນັດອື່ນໆຈຳນວນໜຶ່ງ. ຂ້າພະເຈົ້າຈະບໍ່ອາໄສຢູ່ກັບພວກເຂົາ.

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

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

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

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

ແຕ່ມີ nuances ກັບວິທີການ stuff ໃຫ້ເຂົາເຈົ້າຕໍ່ມາເຂົ້າໄປໃນພາກສ່ວນນີ້ (Logstash / Graylog / ES). ສ່ວນນີ້ (rsyslog-rsyslog) ແມ່ນໃຊ້ລະຫວ່າງສູນຂໍ້ມູນ. ນີ້ແມ່ນການເຊື່ອມຕໍ່ tcp ທີ່ຖືກບີບອັດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານປະຫຍັດແບນວິດແລະ, ຕາມຄວາມເຫມາະສົມ, somehow ເພີ່ມຄວາມເປັນໄປໄດ້ທີ່ພວກເຮົາຈະໄດ້ຮັບບັນທຶກຈາກສູນຂໍ້ມູນອື່ນເມື່ອຊ່ອງທາງເຕັມ. ເນື່ອງຈາກວ່າພວກເຮົາມີອິນໂດເນເຊຍ, ບ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງແມ່ນບໍ່ດີ. ນັ້ນແມ່ນບ່ອນທີ່ບັນຫາຄົງທີ່ຢູ່.

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

ມີບັນຫາຫຍັງແດ່? ບັນຫາເກີດຂື້ນກັບຄວາມຈິງທີ່ວ່າພວກເຮົາພົບເຫັນ (ຢ່າງກະທັນຫັນ!) ວ່າ Live APIs ຂອງພວກເຮົາຂຽນ 50k ຂໍ້ຄວາມຕໍ່ວິນາທີ. ນີ້ແມ່ນພຽງແຕ່ Live API ທີ່ບໍ່ມີຂັ້ນຕອນ. ແລະ Graylog ພຽງແຕ່ສະແດງໃຫ້ພວກເຮົາ 12 ພັນຂໍ້ຄວາມຕໍ່ວິນາທີ. ແລະຄໍາຖາມທີ່ສົມເຫດສົມຜົນໄດ້ເກີດຂຶ້ນ, ທີ່ເຫຼືອຢູ່ໃສ? ຈາກທີ່ພວກເຮົາສະຫຼຸບວ່າ Graylog ພຽງແຕ່ບໍ່ສາມາດຮັບມືກັບ. ພວກເຮົາເບິ່ງ, ແລະ, ແທ້ຈິງແລ້ວ, Graylog ກັບ Elasticsearch ບໍ່ໄດ້ຊໍານິຊໍານານການໄຫຼເຂົ້ານີ້.

ຕໍ່ໄປ, ການຄົ້ນພົບອື່ນໆທີ່ພວກເຮົາໄດ້ເຮັດຕາມທາງ.

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

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

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

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

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

ສ່ວນນີ້ກັບ Logstash ແລະ Greylog, ມັນກໍ່ເພີ່ມຂຶ້ນ. ເພາະສະນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍາຈັດມັນ. ທ່ານຕ້ອງເລືອກຫນຶ່ງ.

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

ສິ່ງທີ່ແນ່ນອນແມ່ນລວມຢູ່ໃນ Graylog ໃຫມ່. ພວກເຮົາພຽງແຕ່ຂຽນທຸກສິ່ງທຸກຢ່າງຢູ່ໃນ docker. ພວກເຮົາໄດ້ເອົາເຄື່ອງແມ່ຂ່າຍຈໍານວນຫລາຍ, rolled ອອກສາມຕົວຢ່າງ Kafka, 7 ເຄື່ອງແມ່ຂ່າຍ Graylog ຮຸ່ນ 2.3 (ເພາະວ່າຂ້ອຍຕ້ອງການ Elasticsearch ຮຸ່ນ 5). ທັງຫມົດນີ້ໄດ້ຖືກຍົກຂຶ້ນມາໃນການໂຈມຕີຈາກ HDD. ພວກເຮົາໄດ້ເຫັນອັດຕາການດັດສະນີສູງເຖິງ 100 ພັນຂໍ້ຄວາມຕໍ່ວິນາທີ. ພວກເຮົາໄດ້ເຫັນຕົວເລກທີ່ 140 terabytes ຂອງຂໍ້ມູນຕໍ່ອາທິດ.

ແລະອີກເທື່ອຫນຶ່ງ rake ເປັນ! ພວກເຮົາມີການຂາຍສອງອັນທີ່ຈະມາເຖິງ. ພວກເຮົາໄດ້ຍ້າຍອອກເກີນ 6 ລ້ານໂພສແລ້ວ. ພວກເຮົາ Graylog ບໍ່ມີເວລາທີ່ຈະ chew. somehow ທ່ານ​ມີ​ເພື່ອ​ຄວາມ​ຢູ່​ລອດ​ອີກ​ເທື່ອ​ຫນຶ່ງ​.

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

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

ເກັບກໍາການວັດແທກຈາກ Graylog.

ສ້າງຂອບເຂດຈໍາກັດອັດຕາເພື່ອໃຫ້ພວກເຮົາມີ API ບ້າອັນຫນຶ່ງທີ່ບໍ່ຂ້າແບນວິດຂອງພວກເຮົາແລະສິ່ງອື່ນໆ.

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

ແລະຂຽນເອກະສານ.

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

ຄໍາຖາມຂອງທ່ານ.

ຄໍາຖາມ: ເປັນຫຍັງເຂົາເຈົ້າຈຶ່ງຕັດສິນໃຈບໍ່ເອົາ... (filebeat?)

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

ຄໍາຖາມ: ເປັນຫຍັງເຈົ້າຈຶ່ງບໍ່ຂຽນບັນທຶກໃສ່ HDFS?

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

ຄໍາຖາມ: ຮູບແບບຖັນຈະເໝາະສົມກວ່າ.

Reply: ຂ້ອຍ​ເຂົ້າ​ໃຈ. ພວກເຮົາແມ່ນ "ສໍາລັບ" ດ້ວຍມືທັງສອງ.

ຄໍາຖາມ: ທ່ານຂຽນໄປທີ່ rsyslog. ທັງ TCP ແລະ UDP ແມ່ນມີຢູ່. ແຕ່ຖ້າ UDP, ແລ້ວເຈົ້າຮັບປະກັນການຈັດສົ່ງແນວໃດ?

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

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

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

ຄໍາຖາມ: Timestamp ອາດຈະແຕກຕ່າງກັນໂດຍ milliseconds.

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

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

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

ຄໍາຖາມ: ທ່ານໄດ້ຮັບບັນທຶກຈາກບ່ອນນັ້ນໃນລະຫວ່າງສະຖານະການຜິດປົກກະຕິບໍ?

Reply: ທ່ານສາມາດໄປທີ່ນັ້ນ (ໄປຫາບ່ອນເກັບໄຟລ໌) ແລະເບິ່ງ.

ຄໍາຖາມ: ທ່ານຕິດຕາມແນວໃດວ່າທ່ານບໍ່ສູນເສຍໄມ້ທ່ອນ?

Reply: ພວກເຮົາກໍາລັງສູນເສຍພວກມັນຢ່າງແທ້ຈິງ, ແລະພວກເຮົາກໍາລັງຕິດຕາມມັນ. ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ຫນຶ່ງ​ເດືອນ​ກ່ອນ​ຫນ້າ​ນີ້​. ຫ້ອງສະໝຸດທີ່ Go APIs ໃຊ້ມີ metrics. ນາງສາມາດນັບຈໍານວນຄັ້ງທີ່ນາງລົ້ມເຫລວໃນການຂຽນໃສ່ເຕົ້າຮັບ. ຢູ່ທີ່ນັ້ນໃນເວລານີ້ມີ heuristic tricky. ມີ buffer ຢູ່ທີ່ນັ້ນ. ມັນພະຍາຍາມຂຽນຂໍ້ຄວາມຈາກມັນໄປຫາເຕົ້າຮັບ. ຖ້າ buffer overflows, ມັນຈະເລີ່ມຫຼຸດລົງໃຫ້ເຂົາເຈົ້າ. ແລະລາວນັບຈໍານວນທີ່ລາວໄດ້ຖິ້ມພວກມັນ. ຖ້າເຄົາເຕີເລີ່ມລົ້ນຢູ່ທີ່ນັ້ນ, ພວກເຮົາຈະຮູ້ກ່ຽວກັບມັນ. ດຽວນີ້ພວກເຂົາຍັງມາຮອດ prometheus, ແລະທ່ານສາມາດເບິ່ງເສັ້ນສະແດງໃນ Grafana. ທ່ານສາມາດຕັ້ງຄ່າການແຈ້ງເຕືອນ. ​ແຕ່​ຍັງ​ບໍ່​ທັນ​ເປັນ​ທີ່​ຈະ​ແຈ້ງ​ເທື່ອ​ວ່າ​ຈະ​ສົ່ງ​ໃຫ້​ໃຜ.

ຄໍາຖາມ: ໃນ elasticsearch, ທ່ານເກັບຮັກສາບັນທຶກທີ່ມີຊ້ໍາຊ້ອນ. ທ່ານມີ replicas ຫຼາຍປານໃດ?

Reply: ຫນຶ່ງໃນ replica.

ຄໍາຖາມ: ມັນເປັນພຽງເສັ້ນດຽວບໍ?

Reply: ນີ້ແມ່ນຕົ້ນສະບັບແລະ replica. ຂໍ້ມູນຖືກເກັບໄວ້ໃນຊໍ້າກັນ.

ຄໍາຖາມ: ທ່ານໄດ້ປັບຂະຫນາດຂອງ rsyslog buffer ແນວໃດ?

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

ຄຳຖາມ: ເຈົ້າຂຽນ JSON ທີ່ແຕກຫັກບໍ?

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

ຄຳຖາມ: ເປັນຫຍັງ Kafka? ທ່ານໄດ້ພະຍາຍາມ RabbitMQ ບໍ? Greylog ບໍ່ໄດ້ເພີ່ມພາຍໃຕ້ການໂຫຼດດັ່ງກ່າວບໍ?

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

ກ່ຽວກັບ Kafka. ນັ້ນແມ່ນວິທີທີ່ມັນເກີດຂຶ້ນໃນປະຫວັດສາດ. ເມື່ອຂ້ອຍມາຮອດ, ມັນແມ່ນຢູ່ແລ້ວ, ແລະບັນທຶກໄດ້ຖືກຂຽນໃສ່ມັນ. ພວກເຮົາພຽງແຕ່ຍົກກຸ່ມຂອງພວກເຮົາ ແລະຍ້າຍບັນທຶກເຂົ້າໄປໃນມັນ. ພວກເຮົາຄຸ້ມຄອງລາວ, ພວກເຮົາຮູ້ວ່າລາວຮູ້ສຶກແນວໃດ. ສໍາລັບ RabbitMQ ... ພວກເຮົາກໍາລັງມີບັນຫາກັບ RabbitMQ. ແລະ RabbitMQ ກໍາລັງພັດທະນາສໍາລັບພວກເຮົາ. ພວກເຮົາມີມັນຢູ່ໃນການຜະລິດ, ແລະມີບັນຫາກັບມັນ. ໃນປັດຈຸບັນ, ກ່ອນທີ່ຈະຂາຍ, ລາວຈະຖືກ shamanized, ແລະລາວຈະເລີ່ມເຮັດວຽກຕາມປົກກະຕິ. ແຕ່ກ່ອນນັ້ນ, ຂ້າພະເຈົ້າບໍ່ພ້ອມທີ່ຈະປ່ອຍມັນເຂົ້າໄປໃນການຜະລິດ. ມີອີກອັນຫນຶ່ງ. Graylog ສາມາດອ່ານ AMQP 0.9 ຮຸ່ນແລະ rsyslog ສາມາດຂຽນ AMQP 1.0 ຮຸ່ນ. ແລະບໍ່ມີທາງອອກດຽວທີ່ສາມາດເຮັດໄດ້ທັງສອງໃນກາງ. ມີທັງຫນຶ່ງຫຼືອື່ນໆ. ດັ່ງນັ້ນສໍາລັບໃນປັດຈຸບັນພຽງແຕ່ Kafka. ແຕ່ຍັງມີ nuances. ເນື່ອງຈາກວ່າ omkafka ຂອງສະບັບຂອງ rsyslog ທີ່ພວກເຮົາໃຊ້ສາມາດສູນເສຍຂໍ້ຄວາມທັງຫມົດທີ່ມັນ scooped ຂຶ້ນຈາກ rsyslog. ຕາບໃດທີ່ພວກເຮົາເອົາໃຈໃສ່ກັບມັນ.

ຄຳຖາມ: ເຈົ້າໃຊ້ Kafka ເພາະວ່າເຈົ້າມີມັນບໍ? ບໍ່ໄດ້ໃຊ້ເພື່ອຈຸດປະສົງອື່ນບໍ?

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

ຄຳຖາມ: ເປັນຫຍັງພວກເຮົາຕ້ອງການ shamanism ນີ້ກັບເຕົ້າຮັບ? ທ່ານໄດ້ພະຍາຍາມໃຊ້ໄດເວີບັນທຶກ syslog ສໍາລັບບັນຈຸ.

Reply: ໃນເວລາທີ່ພວກເຮົາຖາມຄໍາຖາມນີ້, ພວກເຮົາມີຄວາມເຄັ່ງຕຶງກັບ docker. ມັນແມ່ນ docker 1.0 ຫຼື 0.9. Docker ຕົວຂອງມັນເອງແມ່ນແປກ. ອັນທີສອງ, ຖ້າທ່ານຍັງ shove ບັນທຶກເຂົ້າໄປໃນມັນ ... ຂ້າພະເຈົ້າມີຄວາມສົງໃສທີ່ບໍ່ໄດ້ຮັບການຢັ້ງຢືນວ່າມັນຜ່ານໄມ້ທ່ອນທັງຫມົດໂດຍຜ່ານຕົວມັນເອງ, ຜ່ານ daemon docker. ຖ້າພວກເຮົາມີ API ຫນຶ່ງຈະບ້າ, ຫຼັງຈາກນັ້ນສ່ວນທີ່ເຫຼືອຂອງ APIs ຈະດໍາເນີນການກັບຄວາມຈິງທີ່ວ່າພວກເຂົາບໍ່ສາມາດສົ່ງ stdout ແລະ stderr. ຂ້ອຍບໍ່ຮູ້ວ່າອັນນີ້ຈະໄປໃສ. ຂ້ອຍມີຄວາມສົງໃສໃນລະດັບຄວາມຮູ້ສຶກວ່າມັນບໍ່ຈໍາເປັນຕ້ອງໃຊ້ໄດເວີ docker syslog ຢູ່ໃນສະຖານທີ່ນີ້. ພະແນກການທົດສອບທີ່ເປັນປະໂຫຍດຂອງພວກເຮົາມີກຸ່ມ Graylog ຂອງຕົນເອງທີ່ມີບັນທຶກ. ພວກເຂົາໃຊ້ຕົວຂັບບັນທຶກ docker ແລະທຸກຢ່າງເບິ່ງຄືວ່າດີຢູ່ທີ່ນັ້ນ. ແຕ່ພວກເຂົາຂຽນ GELF ກັບ Graylog ທັນທີ. ໃນປັດຈຸບັນທີ່ພວກເຮົາເລີ່ມຕົ້ນທັງຫມົດນີ້, ພວກເຮົາຕ້ອງການມັນພຽງແຕ່ເຮັດວຽກ. ບາງທີຕໍ່ມາ, ເມື່ອມີຄົນມາແລະບອກວ່າມັນເຮັດວຽກປົກກະຕິເປັນຮ້ອຍປີ, ພວກເຮົາຈະພະຍາຍາມ.

ຄຳຖາມ: ທ່ານຈັດສົ່ງລະຫວ່າງສູນຂໍ້ມູນໂດຍໃຊ້ rsyslog. ເປັນຫຍັງບໍ່ຢູ່ໃນ Kafka?

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

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