ເຂົ້າສູ່ລະບົບ Kubernetes (ແລະບໍ່ພຽງແຕ່ເທົ່ານັ້ນ) ໃນມື້ນີ້: ຄວາມຄາດຫວັງແລະຄວາມເປັນຈິງ

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

ຢ່າງໃດກໍຕາມ, ທໍາອິດ, ຂ້າພະເຈົ້າຈະຈອງທີ່ລູກຄ້າທີ່ແຕກຕ່າງກັນເຂົ້າໃຈສິ່ງທີ່ແຕກຕ່າງກັນຫຼາຍໂດຍການເກັບບັນທຶກ:

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

ຂ້າງລຸ່ມນີ້ແມ່ນການຕັດຂ້າງລຸ່ມນີ້ກ່ຽວກັບວິທີການທີ່ພວກເຮົາປະຕິບັດ "ລາຍການຄວາມປາຖະຫນາ" ຕ່າງໆແລະສິ່ງທີ່ພວກເຮົາພົບຄວາມຫຍຸ້ງຍາກ.

ທິດສະດີ: ກ່ຽວກັບເຄື່ອງມືການຕັດໄມ້

ປະຫວັດຄວາມເປັນມາຂອງອົງປະກອບຂອງລະບົບການບັນທຶກ

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

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

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

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

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

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

ດັ່ງນັ້ນ, ໃນໄລຍະເວລາທີ່ຂ້ອນຂ້າງສັ້ນ, ການເກັບກໍາຂໍ້ມູນບັນທຶກໄດ້ພັດທະນາເຂົ້າໄປໃນລະບົບຍ່ອຍທີ່ສໍາຄັນ, ເຊິ່ງສາມາດເອີ້ນວ່າຫນຶ່ງໃນສ່ວນຍ່ອຍໃນ Big Data.

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

Kubernetes ແລະບັນທຶກ

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

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

• ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ unrolls stack ໄດ້​ EFK (Elasticsearch, Fluentd, Kibana);
• ບາງຄົນກໍາລັງພະຍາຍາມປ່ອຍອອກມາເມື່ອບໍ່ດົນມານີ້ Loki ຫຼືໃຊ້ ຜູ້ປະກອບການບັນທຶກ;
• ພວກເຮົາ (ແລະບາງທີບໍ່ພຽງແຕ່ພວກເຮົາ?..) ຂ້ອຍພໍໃຈກັບການພັດທະນາຂອງຕົນເອງ - ເຮືອນໄມ້ທ່ອນ...

ຕາມກົດລະບຽບ, ພວກເຮົາໃຊ້ຊຸດຕໍ່ໄປນີ້ຢູ່ໃນກຸ່ມ K8s (ສໍາລັບການແກ້ໄຂທີ່ໂຮດເອງ):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + loghouse.

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

ປະຕິບັດກັບບັນທຶກໃນ K8s

“ບັນທຶກປະຈຳວັນ” ເຈົ້າມີຈັກຄົນ?...

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

ມາລອງ ClickHouse

ຂໍໃຫ້ເບິ່ງການເກັບຮັກສາສູນກາງໃນໂຄງການທີ່ມີຄໍາຮ້ອງສະຫມັກທີ່ສ້າງບັນທຶກຢ່າງຫ້າວຫັນ: ຫຼາຍກ່ວາ 5000 ເສັ້ນຕໍ່ວິນາທີ. ໃຫ້ເລີ່ມຕົ້ນເຮັດວຽກກັບບັນທຶກຂອງລາວ, ເພີ່ມພວກມັນໃສ່ ClickHouse.

ທັນທີທີ່ຕ້ອງໃຊ້ realtime ສູງສຸດ, ເຊີບເວີ 4-core ທີ່ມີ ClickHouse ຈະຖືກໂຫຼດຫຼາຍເກີນໄປໃນລະບົບຍ່ອຍຂອງດິສກ໌:

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

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

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

Примечание: ອີກດ້ານຫນຶ່ງທີ່ເປັນບັນຫາຂອງການແກ້ໄຂຂອງພວກເຮົາກັບ ClickHouse ແມ່ນກ່ຽວຂ້ອງກັບຄວາມຈິງທີ່ວ່າການແບ່ງປັນໃນກໍລະນີຂອງພວກເຮົາ (loghouse) ແມ່ນຖືກປະຕິບັດຜ່ານຕາຕະລາງພາຍນອກເຊື່ອມຕໍ່. ຮວມຕາຕະລາງ. ນີ້ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າໃນເວລາທີ່ການເກັບຕົວຢ່າງໄລຍະເວລາຂະຫນາດໃຫຍ່, RAM ຫຼາຍເກີນໄປແມ່ນຈໍາເປັນ, ນັບຕັ້ງແຕ່ metatable iterates ຜ່ານພາທິຊັນທັງຫມົດ - ເຖິງແມ່ນວ່າແນ່ນອນວ່າບໍ່ມີຂໍ້ມູນທີ່ຈໍາເປັນ. ຢ່າງໃດກໍຕາມ, ໃນປັດຈຸບັນວິທີການນີ້ສາມາດຖືກປະກາດວ່າລ້າສະໄຫມຢ່າງປອດໄພສໍາລັບ ClickHouse ຮຸ່ນປະຈຸບັນ (c 18.16).

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

ແມ່ນຫຍັງກ່ຽວກັບ Elasticsearch?

Elasticsearch ແມ່ນເປັນທີ່ຮູ້ຈັກເພື່ອຈັດການກັບວຽກຫນັກ. ໃຫ້ລອງມັນຢູ່ໃນໂຄງການດຽວກັນ. ໃນປັດຈຸບັນການໂຫຼດເບິ່ງຄືວ່ານີ້:

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

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

ຫຼັງຈາກນັ້ນ, ຄໍາຖາມທໍາມະຊາດເກີດຂຶ້ນ:

ໄມ້ທ່ອນໃດທີ່ຕ້ອງການແທ້ໆ?

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

ໃຫ້ເວົ້າວ່າພວກເຮົາມີຮ້ານອອນໄລນ໌ສົບຜົນສໍາເລັດ. ບັນທຶກໃດທີ່ສໍາຄັນ? ການລວບລວມຂໍ້ມູນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, ຕົວຢ່າງ, ຈາກປະຕູການຈ່າຍເງິນ, ເປັນຄວາມຄິດທີ່ດີ. ແຕ່ບໍ່ແມ່ນບັນທຶກທັງຫມົດຈາກການບໍລິການ slicing ຮູບພາບໃນລາຍການຜະລິດຕະພັນແມ່ນສໍາຄັນຕໍ່ພວກເຮົາ: ພຽງແຕ່ຄວາມຜິດພາດແລະການກວດສອບຂັ້ນສູງແມ່ນພຽງພໍ (ຕົວຢ່າງ, ອັດຕາສ່ວນຂອງ 500 ຂໍ້ຜິດພາດທີ່ອົງປະກອບນີ້ສ້າງ).

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

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

ພາບປະກອບຈາກຊີວິດ

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

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

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

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

ເງື່ອນໄຂສໍາລັບໄມ້ທ່ອນ

ຕົວຢ່າງດັ່ງກ່າວນໍາໄປສູ່ການສະຫລຸບວ່ານອກເຫນືອຈາກການເລືອກລະບົບການເກັບບັນທຶກ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ ຍັງອອກແບບໄມ້ທ່ອນດ້ວຍຕົນເອງ! ຄວາມຕ້ອງການຢູ່ທີ່ນີ້ແມ່ນຫຍັງ?

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

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

ຄວາມຜິດພາດຫມາຍຄວາມວ່າທ່ານກໍາລັງສົ່ງພາກສະຫນາມທີ່ມີປະເພດບໍ່ຫມັ້ນຄົງກັບດັດຊະນີທີ່ມີແຜນທີ່ທີ່ກຽມພ້ອມ. ຕົວຢ່າງທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນພາກສະຫນາມໃນບັນທຶກ nginx ທີ່ມີຕົວແປ $upstream_status. ມັນສາມາດມີທັງຕົວເລກ ຫຼືສາຍ. ຍົກ​ຕົວ​ຢ່າງ:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

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

"upstream_response_time": "0.001, 0.007"

ສະຖານະການນີ້ແມ່ນເປັນເລື່ອງທໍາມະດາທີ່ມັນສົມຄວນໄດ້ຮັບການແຍກຕ່າງຫາກ ເອກະສານອ້າງອີງໃນເອກະສານ.

ຈະເປັນແນວໃດກ່ຽວກັບຄວາມຫນ້າເຊື່ອຖື?

ມີເວລາທີ່ບັນທຶກທັງຫມົດໂດຍບໍ່ມີຂໍ້ຍົກເວັ້ນແມ່ນສໍາຄັນ. ແລະດ້ວຍນີ້, ຮູບແບບການເກັບກຳບັນທຶກປົກກະຕິສຳລັບ K8s ທີ່ສະເໜີ/ສົນທະນາຂ້າງເທິງມີບັນຫາ.

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

"helm.sh/hook-delete-policy": hook-succeeded

ດ້ວຍເຫດນີ້, ບັນທຶກການປະຕິບັດການເຄື່ອນຍ້າຍບໍ່ໄດ້ລວມຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ. ການເມືອງສາມາດຊ່ວຍໃນກໍລະນີນີ້. before-hook-creation.

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

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

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

ການຄົ້ນພົບ

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

ການເກັບບັນທຶກສູນກາງໃນຕອນທໍາອິດເບິ່ງຄືວ່າເປັນວຽກທີ່ງ່າຍດາຍ, ແຕ່ວ່າມັນບໍ່ແມ່ນທັງຫມົດ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ໄວ້ວ່າ:

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

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

PS

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

• «ແນະນໍາ loghouse - ລະບົບແຫຼ່ງເປີດສໍາລັບການເຮັດວຽກກັບບັນທຶກໃນ Kubernetes"
• «ການປ່ອຍສໍາລັບລະບົບນິເວດ Kubernetes ຈາກ KubeCon'19: JFrog Container Registry, Kui ຈາກ IBM, Loki 1.0.0…"
• «ການຕິດຕາມແລະ Kubernetes (ການທົບທວນຄືນແລະບົດລາຍງານວິດີໂອ)".

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