ການເລືອກບ່ອນເກັບຂໍ້ມູນສໍາລັບ Prometheus: Thanos vs VictoriaMetrics

ສະບາຍດີທຸກຄົນ. ຂ້າງລຸ່ມນີ້ແມ່ນຂໍ້ຄວາມຖອດຈາກສຽງ ບົດ​ລາຍ​ງານ​ຈາກ​ກອງ​ປະຊຸມ​ໃຫຍ່​ຕິດຕາມ​ກວດກາ 4.

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

ບົດລາຍງານຈະປະກອບມີການປຽບທຽບ Thanos и VictoriaMetrics — ໂຄງ​ການ​ສໍາ​ລັບ​ການ​ເກັບ​ຮັກ​ສາ​ໃນ​ໄລ​ຍະ​ຍາວ​ຂອງ Prometheus metrics​.

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

ຂໍ້​ຈໍາ​ກັດ Prometheus​:

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

ການແກ້ໄຂບັນຫາ/ສິ່ງທ້າທາຍເຫຼົ່ານີ້ບໍ?

ວິທີແກ້ໄຂແມ່ນ:

• Thanos
• VictoriaMetrics
• Uber M3
• Cortex

ການແກ້ໄຂທັງຫມົດເຫຼົ່ານີ້ແມ່ນສໍາລັບການເກັບຮັກສາຫ່າງໄກສອກຫຼີກຂອງຂໍ້ມູນທີ່ເກັບກໍາໂດຍ Prometheus. ພວກເຂົາເຈົ້າແກ້ໄຂບັນຫາການເກັບຮັກສາຫ່າງໄກສອກຫຼີກຈາກສະໄລ້ທີ່ຜ່ານມາໃນວິທີທີ່ແຕກຕ່າງກັນ. ໃນການນໍາສະເຫນີນີ້ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບສອງວິທີແກ້ໄຂທໍາອິດ: Thanos и VictoriaMetrics.

ສໍາລັບຄັ້ງທໍາອິດຂໍ້ມູນຂ່າວສານກ່ຽວກັບ Thanos ປະກົດໂດຍ ການເຊື່ອມຕໍ່ນີ້. ສະຖາປັດຕະຍະກໍາໄດ້ຖືກອະທິບາຍຢູ່ທີ່ນັ້ນ Thanos ແລະວິທີການເຮັດວຽກ.

Thanos ເອົາຂໍ້ມູນທີ່ Prometheus ບັນທຶກໄວ້ໃນແຜ່ນທ້ອງຖິ່ນແລະຄັດລອກມັນໄປທີ່ S3 ກຊສ ຫຼືບ່ອນເກັບມ້ຽນວັດຖຸອື່ນ.

ດັ່ງນັ້ນ Thanos ໃຫ້ທັດສະນະການສອບຖາມທົ່ວໂລກ. ທ່ານສາມາດສອບຖາມຂໍ້ມູນທີ່ເກັບໄວ້ໃນການເກັບຮັກສາວັດຖຸຈາກຫຼາຍຕົວຢ່າງ Prometheus.

Thanos ສະຫນັບສະຫນູນ PromQL ແລະ Prometheus querying API.

Thanos ໃຊ້ລະຫັດ Prometheus ເພື່ອເກັບຂໍ້ມູນ.

Thanos ຖືກພັດທະນາໂດຍນັກພັດທະນາດຽວກັນກັບ Prometheus.

ກ່ຽວກັບ VictoriaMetrics. ທີ່ນີ້ ຫນ້າທໍາອິດ, ບ່ອນທີ່ພວກເຮົາສົນທະນາຄັ້ງທໍາອິດ VictoriaMetrics.

VictoriaMetrics ໄດ້ຮັບຂໍ້ມູນຈາກ prometheus ຫຼາຍ API ຂຽນທາງໄກ ອະນຸສັນຍາທີ່ສະຫນັບສະຫນູນໂດຍ Prometheus.

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

VictoriaMetrics ຍັງສະຫນັບສະຫນູນເຊັ່ນ Thanos, PromQL ແລະ Prometheus querying API.

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

VictoriaMetrics, ບໍ່ເຫມືອນກັບ Thanos, ຂະຫນາດທັງຕັ້ງແລະແນວນອນ. ກິນ ລຸ້ນດຽວ, ເຊິ່ງມີຂະຫນາດໃນແນວຕັ້ງ. ທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍໂປເຊດເຊີຫນຶ່ງແລະຫນ່ວຍຄວາມຈໍາ 1 GB ແລະຄ່ອຍໆເຕີບໂຕເປັນຮ້ອຍຂອງໂປເຊດເຊີແລະ 1 TB ຂອງຫນ່ວຍຄວາມຈໍາ. VictoriaMetrics ສາມາດນໍາໃຊ້ຊັບພະຍາກອນທັງຫມົດເຫຼົ່ານີ້. ປະສິດທິພາບຂອງມັນຈະເພີ່ມຂຶ້ນປະມານ 100 ເທົ່າເມື່ອທຽບກັບລະບົບ 1-core.

ປະຫວັດສາດຂອງ Thanos ໄດ້ເລີ່ມຕົ້ນໃນເດືອນພະຈິກ 2017, ເມື່ອຄໍາຫມັ້ນສັນຍາສາທາລະນະຄັ້ງທໍາອິດປາກົດ. ກ່ອນນີ້, Thanos ໄດ້ຖືກພັດທະນາພາຍໃນ improbable.io.

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

ໃນເດືອນມິຖຸນາ 2019 ດຽວກັນ, ພວກເຂົາເຈົ້າໄດ້ສົ່ງເລກສະຫມັກ 256 в ມູນນິທິຄອມພິວເຕີ້ Cloud Native.

ແລະຫຼັງຈາກສອງສາມເດືອນ Thanos ໄດ້ຖືກຍອມຮັບເຂົ້າໃນ ມູນນິທິຄອມພິວເຕີ້ Cloud Native, ເຊິ່ງລວມມີ Prometheus, Kubernetes ແລະໂຄງການທີ່ນິຍົມອື່ນໆ.

ໃນເດືອນມັງກອນ 2018, ການພັດທະນາ VictoriaMetrics ໄດ້ເລີ່ມຕົ້ນ.

ໃນເດືອນກັນຍາ 2018, ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງ VictoriaMetrics ຢ່າງເປີດເຜີຍເປັນຄັ້ງທໍາອິດ.

ໃນເດືອນທັນວາ 2018, ສະບັບ Single-node ໄດ້ຖືກຈັດພີມມາ.

ໃນເດືອນພຶດສະພາ 2019 ໄດ້ຖືກຈັດພີມມາ ແຫຼ່ງທີ່ມາຂອງທັງ Single-node ແລະ cluster versions.

ໃນເດືອນມິຖຸນາ 2019, ຄືກັນກັບ Thanos, ພວກເຮົາໄດ້ສົ່ງໃບສະໝັກໄປຫາພື້ນຖານ CNCF ພາຍໃຕ້ຕົວເລກ 255. ພວກເຮົາສະຫມັກມື້ຫນຶ່ງກ່ອນທີ່ Thanos ສະຫມັກ.

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

ຂໍໃຫ້ເບິ່ງສະໄລ້ທີ່ສໍາຄັນທີ່ສຸດທີ່ສະແດງສະຖາປັດຕະຍະກໍາຂອງ Thanos ແລະ VictoriaMetrics.

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

ຍັງມີອົງປະກອບທີ່ເອີ້ນວ່າ Thanos Store Gateway, ເຊິ່ງສາມາດອ່ານຂໍ້ມູນນີ້ຈາກ Object Storage ຕາມຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາຈາກ Thanos Query. Thanos Query ປະຕິບັດ PromQL ແລະ Prometheus API. ນັ້ນແມ່ນ, ຈາກພາຍນອກມັນຄ້າຍຄື Prometheus. ໄດ້ຮັບການສອບຖາມ PromQL, ສົ່ງພວກມັນໄປທີ່ Thanos Store Gateway, Thanos Store Gateway ດຶງຂໍ້ມູນທີ່ຈໍາເປັນຈາກ Object Storage, ສົ່ງຄືນ.

ແຕ່ພວກເຮົາເກັບຂໍ້ມູນຢູ່ໃນ Object Storage ໂດຍບໍ່ມີສອງຊົ່ວໂມງສຸດທ້າຍເນື່ອງຈາກຄຸນນະສົມບັດຂອງການປະຕິບັດ Thanos Sidecar, ເຊິ່ງບໍ່ສາມາດອັບໂຫລດສອງຊົ່ວໂມງທີ່ຜ່ານມາໃສ່ Object Storage S3, ເພາະວ່າ Prometheus ຍັງບໍ່ທັນສ້າງໄຟລ໌ສໍາລັບສອງຊົ່ວໂມງນີ້ຢູ່ໃນບ່ອນເກັບຂໍ້ມູນທ້ອງຖິ່ນ.

ເຈົ້າຕັດສິນໃຈແນວໃດເພື່ອເຂົ້າຫາເລື່ອງນີ້? Thanos Query, ນອກເຫນືອຈາກການຮ້ອງຂໍໄປທີ່ Thanos Store Gateway, ສົ່ງຄໍາຮ້ອງຂໍຂະຫນານກັບ Thanos Sidecar ແຕ່ລະຄົນ, ເຊິ່ງຕັ້ງຢູ່ຂ້າງ Prometheus.

ແລະ Thanos Sidecar, ໃນທາງກັບກັນ, proxies ຮ້ອງຂໍເພີ່ມເຕີມຕໍ່ກັບ Prometheus, ແລະດຶງຂໍ້ມູນສໍາລັບສອງຊົ່ວໂມງທີ່ຜ່ານມາ.

ນອກເຫນືອໄປຈາກອົງປະກອບເຫຼົ່ານີ້, ຍັງມີອົງປະກອບທາງເລືອກທີ່ບໍ່ມີ Thanos ຈະບໍ່ປະຕິບັດໄດ້ດີ. ນີ້ແມ່ນ Thanos Compact, ເຊິ່ງຮັບຜິດຊອບສໍາລັບການລວມໄຟລ໌ຂະຫນາດນ້ອຍໃນ Object Storage ເຂົ້າໄປໃນໄຟລ໌ຂະຫນາດໃຫຍ່ທີ່ຖືກອັບໂຫລດຢູ່ທີ່ນີ້ໂດຍ Thanos Sidecars. Thanos Sidecar ອັບໂຫຼດໄຟລ໌ຂໍ້ມູນຢູ່ທີ່ນັ້ນພາຍໃນສອງຊົ່ວໂມງ. ໄຟລ໌ເຫຼົ່ານີ້, ຖ້າພວກເຂົາບໍ່ຖືກລວມເຂົ້າໃນໄຟລ໌ຂະຫນາດໃຫຍ່, ຫຼັງຈາກນັ້ນ, ຈໍານວນຂອງພວກເຂົາສາມາດເຕີບໂຕຢ່າງຫຼວງຫຼາຍ. ໄຟລ໌ດັ່ງກ່າວຫຼາຍ, ຄວາມຈໍາຫຼາຍແມ່ນຕ້ອງການສໍາລັບ Thanos Store Gateway, ຊັບພະຍາກອນຫຼາຍແມ່ນຈໍາເປັນໃນການໂອນຂໍ້ມູນຜ່ານເຄືອຂ່າຍແລະ metadata. Thanos Store Gateway ກາຍເປັນບໍ່ມີປະສິດທິພາບ. ດັ່ງນັ້ນ, ມັນຈໍາເປັນຕ້ອງດໍາເນີນການ Thanos Compact, ເຊິ່ງລວມໄຟລ໌ຂະຫນາດນ້ອຍເຂົ້າໄປໃນຂະຫນາດໃຫຍ່, ເພື່ອໃຫ້ມີໄຟລ໌ດັ່ງກ່າວຫນ້ອຍລົງແລະຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນ Thanos Store Gateway.

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

ນີ້ແມ່ນໂຄງການທີ່ງ່າຍດາຍຂອງ Thanos.

ຕອນນີ້ໃຫ້ປຽບທຽບມັນກັບໂຄງການ VictoriaMetrics.

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

ສະບັບກຸ່ມແມ່ນສັບສົນຫຼາຍ. ພາຍໃນມັນມີສາມອົງປະກອບທີ່ແຕກຕ່າງກັນ: vmselect, vminsert ແລະ vmstorage. ຈາກຊື່ຂອງພວກເຂົາມັນຄວນຈະເປັນທີ່ຊັດເຈນວ່າພວກເຂົາແຕ່ລະຄົນເຮັດຫຍັງ. ອົງປະກອບ Insert ຮັບຂໍ້ມູນໃນຮູບແບບຕ່າງໆ: ຈາກ Prometheus remote write API, Influx line protocol, Graphite protocol ແລະ OpenTSDB protocol. ອົງປະກອບ Insert ຍອມຮັບພວກມັນ, ແຍກພວກມັນແລະແຈກຢາຍພວກມັນລະຫວ່າງອົງປະກອບການເກັບຮັກສາທີ່ມີຢູ່, ບ່ອນທີ່ຂໍ້ມູນຖືກເກັບໄວ້ແລ້ວ. ອົງປະກອບ Select, ໃນທາງກັບກັນ, ຍອມຮັບການສອບຖາມ PromQL. ລາວປະຕິບັດ PromQL, ເຊັ່ນດຽວກັນກັບ Prometheus querying API, ແລະມັນສາມາດຖືກນໍາໃຊ້ເປັນການທົດແທນ Prometheus ໃນ Grafana ຫຼືລູກຄ້າ Prometheus API ອື່ນໆ. ເລືອກຍອມຮັບຄໍາຮ້ອງຂໍ promql, ວິເຄາະມັນ, ອ່ານຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການປະຕິບັດການຮ້ອງຂໍນີ້ຈາກ nodes ການເກັບຮັກສາ, ປະມວນຜົນຂໍ້ມູນນີ້ແລະສົ່ງຄືນຄໍາຕອບ.

ໃຫ້ປຽບທຽບຄວາມສັບສົນຂອງການຕິດຕັ້ງ Thanos ແລະ VictoriaMetrics.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍ Thanos. ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນເຮັດວຽກກັບ Thanos, ທ່ານຈໍາເປັນຕ້ອງສ້າງ bucket ໃນ Object Storage, ເຊັ່ນ S3 ຫຼື GCS, ເພື່ອໃຫ້ Thanos Sidecar ສາມາດຂຽນຂໍ້ມູນໃສ່ມັນ.

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

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

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

ເມື່ອທ່ານຕິດຕັ້ງ Thanos Sidecar, ທ່ານຕ້ອງຕິດຕັ້ງສອງອົງປະກອບສໍາລັບແຕ່ລະ Object Storage Bucket. ເຫຼົ່ານີ້ແມ່ນ Thanos Compactor ແລະ Thanos Store Gateway.

ຫຼັງຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງ Thanos Query ແລະ configure ມັນເພື່ອໃຫ້ມັນສາມາດເຊື່ອມຕໍ່ກັບ Thanos Store Gateways ທັງຫມົດທີ່ທ່ານມີ, ແລະຍັງສາມາດເຊື່ອມຕໍ່ກັບ Thanos Sidecars ທັງຫມົດ.

ອາດຈະມີບັນຫາເລັກນ້ອຍຢູ່ທີ່ນີ້.

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

ຖ້າທ່ານມີສູນຂໍ້ມູນດັ່ງກ່າວຫຼາຍ, ດັ່ງນັ້ນ, ຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບທັງຫມົດຫຼຸດລົງ. ເນື່ອງຈາກ Thanos Query ຕ້ອງຮັກສາການເຊື່ອມຕໍ່ກັບ Thanos Sidecars ທັງໝົດທີ່ຕັ້ງຢູ່ໃນສູນຂໍ້ມູນຕ່າງໆຢູ່ສະເໝີ. ສໍາລັບທຸກໆຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ, ມັນຈະສົ່ງຄໍາຮ້ອງຂໍໄປຫາ Thanos Sidecars ທັງຫມົດ. ຖ້າການເຊື່ອມຕໍ່ຖືກຂັດຈັງຫວະ, ທ່ານຈະໄດ້ຮັບຊຸດຂໍ້ມູນທີ່ບໍ່ຄົບຖ້ວນ, ຫຼືທ່ານຈະໄດ້ຮັບການຕອບໂຕ້ "cluster is down".

ໃນ VictoriaMetrics ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍເລັກນ້ອຍ. ສໍາລັບສະບັບ Single-node, ທ່ານພຽງແຕ່ຕ້ອງການດໍາເນີນການ binary ຫນຶ່ງແລະທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ.

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

ຫຼັງຈາກທີ່ທ່ານໄດ້ເປີດຕົວຄູ່ຫນຶ່ງຫຼືສະບັບ clustered, ທ່ານພຽງແຕ່ຕ້ອງການເພີ່ມ Prometheus ກັບ config. ການຕັ້ງຄ່າສໍາລັບ url ຂຽນໄລຍະໄກດັ່ງນັ້ນມັນເລີ່ມຕົ້ນຂຽນຂໍ້ມູນໃນຂະຫນານກັບການເກັບຮັກສາທ້ອງຖິ່ນແລະການເກັບຮັກສາຫ່າງໄກສອກຫຼີກ. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ການຕັ້ງຄ່ານີ້ຄວນຈະປະຕິບັດໄດ້ຫຼາຍທີ່ເຊື່ອຖືໄດ້ເມື່ອທຽບກັບການຕັ້ງຄ່າ Thanos. ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງຮັກສາການເຊື່ອມຕໍ່ຈາກ VictoriaMetrics ກັບ Prometheus ທັງຫມົດ, ເພາະວ່າ Prometheus ຕົວເອງເຊື່ອມຕໍ່ກັບ VictoriaMetrics ແລະສົ່ງຂໍ້ມູນ.

ໃຫ້ພິຈາລະນາການສະຫນັບສະຫນູນຂອງ Thanos ແລະ VictoriaMetrics.

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

Thanos compactors ອາດຈະຢຸດເຊົາເຮັດວຽກເນື່ອງຈາກ ເຊື້ອຊາດກັບ Sidecar. Compactors ເອົາຂໍ້ມູນຈາກ Object Storage ແລະລວມມັນເຂົ້າໄປໃນຕ່ອນຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນ. ເນື່ອງຈາກເຄື່ອງບີບອັດບໍ່ໄດ້ຖືກ synchronized ກັບ Sidecars, ຕໍ່ໄປນີ້ສາມາດເກີດຂຶ້ນໄດ້: Sidecar ຍັງບໍ່ທັນມີເວລາທີ່ຈະເຮັດສໍາເລັດຕັນ, Compactor ຕັດສິນໃຈວ່າຕັນນີ້ໄດ້ຖືກຂຽນຢ່າງສົມບູນ. Compactor ເລີ່ມອ່ານມັນ. ມັນບໍ່ໄດ້ອ່ານບລັອກຢ່າງເຕັມທີ່ແລະຢຸດເຮັດວຽກ. ເບິ່ງລາຍລະອຽດ ທີ່ນີ້.

Store Gateway ອາດຈະສົ່ງຄືນຂໍ້ມູນທີ່ບໍ່ສອດຄ່ອງກັນເນື່ອງຈາກການແຂ່ງຂັນລະຫວ່າງ Compactor ແລະ Sidecars. ສິ່ງດຽວກັນເກີດຂຶ້ນຢູ່ທີ່ນີ້, ເພາະວ່າ Store Gateway ບໍ່ໄດ້ຖືກ synchronized ກັບ Compactors ແລະ Sidecars ໃນທາງໃດກໍ່ຕາມ. ຕາມນັ້ນແລ້ວ, ເງື່ອນໄຂການແຂ່ງຂັນອາດຈະເກີດຂື້ນເມື່ອ Store Gateway ບໍ່ເຫັນສ່ວນຫນຶ່ງຂອງຂໍ້ມູນຫຼືເຫັນຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນ.

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

ບໍ່ຄືກັບ Thanos, VictoriaMetrics ບໍ່ຄ່ອຍຈະສູນເສຍຂໍ້ມູນ. ເຖິງແມ່ນວ່າການເຊື່ອມຕໍ່ຈາກ Prometheus ກັບ VictoriaMetrics ຖືກຂັດຂວາງ, ນີ້ບໍ່ແມ່ນບັນຫາ, ເພາະວ່າ Prometheus ຍັງສືບຕໍ່ບັນທຶກຂໍ້ມູນໃຫມ່ທີ່ເຂົ້າມາໃນບັນທຶກຂອງ Write Ahead, ຂະຫນາດຂອງ 2 ຊົ່ວໂມງ. ຖ້າທ່ານຟື້ນຟູການເຊື່ອມຕໍ່ຂອງທ່ານກັບ VictoriaMetrics ພາຍໃນສອງຊົ່ວໂມງ, ຂໍ້ມູນຂອງທ່ານຈະບໍ່ສູນເສຍ. Prometheus ສາມາດເພີ່ມຂໍ້ມູນຫຼັງຈາກການຟື້ນຟູການເຊື່ອມຕໍ່ກັບ VictoriaMetrics.

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

Kubernetes ຈັດການກຸ່ມອັດຕະໂນມັດ, ບໍ່ຄືກັບ Thanos. ມັນເປັນການຍາກທີ່ຈະວາງອົງປະກອບ Thanos ທັງຫມົດເຂົ້າໄປໃນກຸ່ມ Kubernetes ດຽວ, ບໍ່ເຫມືອນກັບອົງປະກອບຂອງກຸ່ມ VictoriaMetrics.

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

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

ກ່ຽວກັບຂຸມໃນ Thanos ແລະ VictoriaMetrics.

Thanos ມີ pitfalls ດັ່ງຕໍ່ໄປນີ້. Prometheus ຕ້ອງເກັບຮັກສາຂໍ້ມູນສໍາລັບສອງຊົ່ວໂມງທີ່ຜ່ານມາ. ຖ້າພວກເຂົາສູນເສຍ, ທ່ານຈະສູນເສຍພວກມັນຢ່າງສົມບູນເພາະວ່າພວກເຂົາຍັງບໍ່ໄດ້ຂຽນໃສ່ Object Storage ເຊັ່ນ S3.

ອົງປະກອບຂອງ Store Gateway ແລະອົງປະກອບ compactor ສາມາດຮຽກຮ້ອງໃຫ້ມີຫນ່ວຍຄວາມຈໍາຫຼາຍເພື່ອເຮັດວຽກກັບ Object Storage ຂະຫນາດໃຫຍ່ຖ້າຫາກວ່າມີໄຟລ໌ຂະຫນາດນ້ອຍຈໍານວນຫຼາຍເກັບຮັກສາໄວ້. ຈໍານວນແລະຂະຫນາດຂອງໄຟລ໌ຫຼາຍ, Store Gateway ແລະ RAM ຫນາແຫນ້ນແມ່ນຈໍາເປັນເພື່ອເກັບ metainformation. Thanos ມີບັນຫາຫຼາຍຢ່າງກ່ຽວກັບຄວາມຈິງທີ່ວ່າ Store Gateway ແລະ compactor crash ກັບປະລິມານສະເລ່ຍຂອງຂໍ້ມູນທີ່ບັນທຶກໄວ້.

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

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

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

VictoriaMetrics ຍັງມີຂຸມ. ຂຸມທໍາອິດແມ່ນທາງເລືອກທີ່ຈໍາກັດຈໍານວນ RAM ທີ່ໃຊ້ສໍາລັບແຄດ VictoriaMetrics. ໂດຍຄ່າເລີ່ມຕົ້ນ, ມັນເທົ່າກັບ 60% ຂອງ RAM ໃນເຄື່ອງທີ່ VictoriaMetrics ກໍາລັງແລ່ນຫຼື 60% ຂອງ RAM ຂອງ VictoriaMetrics pod ໃນ Kubernetes.

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

ທາງເລືອກທີສອງ. ນີ້ແມ່ນ retentionPeriod - ໄລຍະເວລາທີ່ຖືກກໍານົດເປັນ 1 ເດືອນໂດຍຄ່າເລີ່ມຕົ້ນ. ນີ້ແມ່ນໄລຍະເວລາທີ່ VictoriaMetrics ເກັບຂໍ້ມູນ. ຫຼັງຈາກໄລຍະເວລານີ້, VictoriaMetrics ຈະລຶບຂໍ້ມູນ.

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

ຂໍໃຫ້ພິຈາລະນາລັກສະນະທີ່ເປັນເອກະລັກ.

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

Thanos ມີການຊໍ້າຊ້ອນຂໍ້ມູນສໍາລັບຄູ່ Prometheus HA. ເມື່ອສອງ Prometheus ເກັບກໍາ metrics ດຽວກັນຈາກເປົ້າຫມາຍດຽວກັນແລະ Thanos ເກັບຮັກສາໄວ້ໃນ Object Storage. Thanos ສາມາດຖອດຖອນຂໍ້ມູນນີ້ໄດ້ຢ່າງຖືກຕ້ອງ, ບໍ່ຄືກັບ VictoriaMetrics.

Thanos ມີອົງປະກອບເຕືອນທີ່ຢູ່ໃນ Thanos schematic. ແຕ່ເຂົາ ບໍ່ແນະນໍາໃຫ້ໃຊ້ໃນການຜະລິດ.

Thanos ມີປະໂຫຍດທີ່ Thanos ແລະ Prometheus ແບ່ງປັນລະຫັດດຽວກັນ. Thanos ແລະ Prometheus ຖືກພັດທະນາໂດຍນັກພັດທະນາດຽວກັນ. ດ້ວຍການປັບປຸງ Thanos ຫຼື Prometheus, ອີກຝ່າຍຊະນະ.

ຄຸນສົມບັດຫຼັກຂອງ VictoriaMetrics ແມ່ນ MetricsQL. ເຫຼົ່ານີ້ແມ່ນ VictoriaMetrics extensions ສໍາລັບ PromQL, ເຊິ່ງຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບການຕິດຕາມກວດກາຂະຫນາດໃຫຍ່ທີ່ຜ່ານມາ.

VictoriaMetrics ສະຫນັບສະຫນູນການໂຫຼດຂໍ້ມູນໂດຍໃຊ້ໂປໂຕຄອນທີ່ແຕກຕ່າງກັນຫຼາຍ. VictoriaMetrics ບໍ່ພຽງແຕ່ສາມາດຍອມຮັບຂໍ້ມູນຈາກ Prometheus, ແຕ່ຍັງຜ່ານໂປໂຕຄອນ Influx, OpenTSDB ແລະ Graphite.

ຂໍ້ມູນ VictoriaMetrics ໃຊ້ພື້ນທີ່ໜ້ອຍກວ່າເມື່ອທຽບກັບ Thanos ແລະ Prometheus.

ຖ້າທ່ານບັນທຶກຂໍ້ມູນທີ່ແທ້ຈິງ, ຜູ້ໃຊ້ເວົ້າກ່ຽວກັບການຫຼຸດຜ່ອນຂະຫນາດຂອງຂໍ້ມູນໃນແຜ່ນ 2-5 ເທົ່າເມື່ອທຽບກັບ Prometheus ແລະ Thanos.

ປະໂຫຍດອີກອັນຫນຶ່ງຂອງ VictoriaMetrics ແມ່ນການເພີ່ມປະສິດທິພາບສໍາລັບຄວາມໄວ.

ໃຫ້ເບິ່ງຄ່າໃຊ້ຈ່າຍຂອງໂຄງສ້າງພື້ນຖານ.

ຫນຶ່ງໃນຂໍ້ໄດ້ປຽບຂອງ Thanos ແມ່ນວ່າມັນເກັບຮັກສາຂໍ້ມູນໃນການເກັບຮັກສາວັດຖຸ, ເຊິ່ງແມ່ນຂ້ອນຂ້າງລາຄາຖືກ.

ເມື່ອເກັບຮັກສາຂໍ້ມູນໃນການເກັບຮັກສາວັດຖຸ, ທ່ານຕ້ອງຈ່າຍສໍາລັບການດໍາເນີນງານການຂຽນແລະອ່ານຂໍ້ມູນ (10 ໂດລາຕໍ່ລ້ານການດໍາເນີນງານ). ເມື່ອທ່ານຂຽນຂໍ້ມູນໃສ່ບ່ອນເກັບມ້ຽນ, ທ່ານຈ່າຍຄ່າໂຮດຕິ້ງຂອງທ່ານສໍາລັບການອັບໂຫລດຂໍ້ມູນໃນອິນເຕີເນັດ, ຖ້າກຸ່ມຂອງທ່ານບໍ່ຢູ່ໃນ AWS, ມັນບໍ່ເສຍຄ່າຢູ່ທີ່ນັ້ນ. ເມື່ອທ່ານອ່ານຂໍ້ມູນ, ທ່ານຈະຈ່າຍລະຫວ່າງ $10 ຫາ $230 ຕໍ່ 1TB. ນີ້ສາມາດເປັນສິ່ງທີ່ສໍາຄັນຖ້າຫາກວ່າທ່ານມັກຈະສອບຖາມຂໍ້ມູນປະຫວັດສາດຈາກກຸ່ມ Thanos.

ສໍາລັບກຸ່ມ Thanos, ທ່ານຈໍາເປັນຕ້ອງຈ່າຍເງິນໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍສໍາລັບ Compact, Store Gateway, ອົງປະກອບ Query ທີ່ຕ້ອງການຫນ່ວຍຄວາມຈໍາຫຼາຍ, ແລະ CPU ສໍາລັບຂໍ້ມູນຈໍານວນຫລາຍ.

VictoriaMetrics ມີຄ່າໃຊ້ຈ່າຍຕໍ່ໄປນີ້. ຖ້າທ່ານເກັບຂໍ້ມູນໃນ GCE HDD drives, ມັນຈະອອກມາເປັນ $40 ສໍາລັບ 1TB. ສໍາລັບ VictoriaMetrics, ໄດ HDD ທໍາມະດາແມ່ນພຽງພໍ; VictoriaMetrics ຖືກປັບໃຫ້ເໝາະສົມສຳລັບ HDD.

VictoriaMetrics ຕ້ອງການເຄື່ອງແມ່ຂ່າຍສໍາລັບອົງປະກອບ: ທັງ Single-nod ຫຼືອົງປະກອບ clustered, ເຊິ່ງ, ບໍ່ເຫມືອນກັບອົງປະກອບ Thanos, ຕ້ອງການ CPU ແລະ RAM ຫນ້ອຍຫຼາຍ - ຕາມນັ້ນ, ມັນຈະມີລາຄາຖືກກວ່າ.

ຕົວຢ່າງຂອງການຈັດຕັ້ງປະຕິບັດ.

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

ເນື່ອງຈາກວ່ານີ້, ຄ່າໃຊ້ຈ່າຍໃນການແກ້ໄຂບັນຫາເຫຼົ່ານີ້ເພີ່ມຂຶ້ນ.

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

VictoriaMetrics ມີຕົວຢ່າງການປະຕິບັດສາທາລະນະ:

• ຜູ້ສ້າງເວັບໄຊທ໌ wix.com
• Adidas ກໍາລັງປະຕິບັດ VictoriaMetrics ແລະແມ້ກະທັ້ງການນໍາສະເຫນີຢູ່ໃນ PromCon 2019 ສຸດທ້າຍ
• TrafficStars - ເຄືອຂ່າຍໂຄສະນາ
• Seznam.cz ເປັນເຄື່ອງຈັກຊອກຫາພາສາເຊັກໂກທີ່ນິຍົມ.

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

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

ຂໍ້ສະຫຼຸບ.

VictoriaMetrics ແລະ Thanos ແກ້ໄຂບັນຫາທີ່ຄ້າຍຄືກັນ, ແຕ່ໃນທາງທີ່ແຕກຕ່າງກັນ:

• ມຸມມອງແບບສອບຖາມທົ່ວໂລກ
• ການ​ຂະ​ຫຍາຍ​ອອກ​ຕາມ​ລວງ​ນອນ​
• ການ​ເກັບ​ຮັກ​ສາ​ໂດຍ​ຕົນ​ເອງ​

ຂໍຂອບໃຈທ່ານ.

ພວກເຮົາລໍຖ້າທ່ານຢູ່ທີ່ຂອງພວກເຮົາ ຊ່ອງ telegram.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າໃຊ້ຫຍັງເປັນບ່ອນເກັບຮັກສາໄລຍະຍາວສໍາລັບ Prometheus?

• 35,3%Thanos6

• 0,0%Cortex0

• 0,0%M3DB0

• 41,2%VictoriaMetrics7

• 23,5%ອື່ນໆ4

17 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 16 ຜູ້ໃຊ້ງົດ.

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