Thanos - Prometheus ທີ່ສາມາດຂະຫຍາຍໄດ້

ການແປພາສາຂອງບົດຄວາມໄດ້ຖືກກະກຽມໂດຍສະເພາະສໍາລັບນັກສຶກສາຂອງຫຼັກສູດ "ການປະຕິບັດແລະເຄື່ອງມື DevOps".

Fabian Reinartz ເປັນຜູ້ພັດທະນາຊອບແວ, Go fanatic, ແລະແກ້ໄຂບັນຫາ. ລາວຍັງເປັນຜູ້ຮັກສາ Prometheus ແລະຜູ້ຮ່ວມກໍ່ຕັ້ງຂອງເຄື່ອງມື Kubernetes SIG. ໃນໄລຍະຜ່ານມາ, ລາວເປັນວິສະວະກອນການຜະລິດຢູ່ SoundCloud ແລະນໍາພາທີມງານຕິດຕາມກວດກາຢູ່ CoreOS. ປະຈຸບັນເຮັດວຽກຢູ່ Google.

Bartek Plotka - ວິສະວະກອນໂຄງສ້າງພື້ນຖານທີ່ Improbable. ລາວມີຄວາມສົນໃຈໃນເຕັກໂນໂລຢີໃຫມ່ແລະບັນຫາຂອງລະບົບແຈກຢາຍ. ລາວມີປະສົບການການຂຽນໂປລແກລມລະດັບຕໍ່າຢູ່ Intel, ປະສົບການຜູ້ປະກອບສ່ວນຢູ່ Mesos, ແລະປະສົບການການຜະລິດ SRE ລະດັບໂລກທີ່ Improbable. ອຸທິດຕົນເພື່ອການປັບປຸງໂລກຂອງບໍລິການຈຸລະພາກ. ສາມຮັກຂອງລາວ: Golang, open source ແລະ volleyball.

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

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

ຕິດຕາມຂ່າວສານຫຼ້າສຸດຈາກ Improbable.

ເປົ້າໝາຍຂອງພວກເຮົາກັບ Thanos

ໃນລະດັບໃດຫນຶ່ງ, ບັນຫາເກີດຂື້ນທີ່ເກີນຄວາມສາມາດຂອງ vanilla Prometheus. ວິທີການເກັບຮັກສາຂໍ້ມູນປະຫວັດສາດ petabytes ທີ່ເຊື່ອຖືໄດ້ແລະປະຫຍັດ? ນີ້ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີການປະນີປະນອມເວລາຕອບສະຫນອງ? ມັນເປັນໄປໄດ້ທີ່ຈະເຂົ້າເຖິງ metrics ທັງຫມົດທີ່ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ Prometheus ທີ່ແຕກຕ່າງກັນດ້ວຍການຮ້ອງຂໍ API ດຽວ? ມີວິທີໃດແດ່ທີ່ຈະສົມທົບຂໍ້ມູນຈໍາລອງທີ່ເກັບກໍາໂດຍໃຊ້ Prometheus HA?

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

ການສອບຖາມຂໍ້ມູນຈາກຫຼາຍຕົວຢ່າງ Prometheus (ການສອບຖາມທົ່ວໂລກ)

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

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

ກ່ອນຫນ້ານີ້, ເພື່ອໃຫ້ໄດ້ຮັບທັດສະນະທົ່ວໂລກໃນ Improbable, ພວກເຮົາໄດ້ຈັດຕັ້ງຕົວຢ່າງ Prometheus ຂອງພວກເຮົາເຂົ້າໄປໃນຫຼາຍລະດັບ. ສະຫະພັນກຳມະບານ. ນີ້ຫມາຍຄວາມວ່າການສ້າງເຄື່ອງແມ່ຂ່າຍ meta Prometheus ຫນຶ່ງທີ່ເກັບກໍາບາງ metrics ຈາກແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃບ.

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

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

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

ການເກັບຮັກສາຂໍ້ມູນປະຫວັດສາດທີ່ເຊື່ອຖືໄດ້

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

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

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

ການລົງຕົວຢ່າງ

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

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

ການລົງຕົວຢ່າງຂໍ້ມູນເກົ່າແມ່ນຄວາມຕ້ອງການທີ່ຫຼີກລ່ຽງບໍ່ໄດ້ຂອງການແກ້ໄຂການເກັບຮັກສາໃນໄລຍະຍາວແລະເກີນຂອບເຂດຂອງ vanilla Prometheus.

ເປົ້າໝາຍເພີ່ມເຕີມ

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

ສະຖາປັດຕະຍະກໍາ Thanos

ຫຼັງຈາກລາຍຊື່ເປົ້າຫມາຍຂອງພວກເຮົາໃນພາກກ່ອນ, ໃຫ້ເຮັດວຽກຜ່ານພວກມັນແລະເບິ່ງວ່າ Thanos ແກ້ໄຂບັນຫາເຫຼົ່ານີ້ໄດ້ແນວໃດ.

ທັດສະນະທົ່ວໂລກ

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

ອີກດ້ານຫນຶ່ງແມ່ນອົງປະກອບ Querier ທີ່ບໍ່ມີລັດ, ເຊິ່ງເຮັດຫຼາຍກ່ວາພຽງແຕ່ຕອບຄໍາຖາມ PromQL ຜ່ານ Prometheus HTTP API ມາດຕະຖານ. Querier, Sidecar ແລະອົງປະກອບ Thanos ອື່ນໆຕິດຕໍ່ສື່ສານຜ່ານ ພິທີການນິນທາ.

1. Querier, ເມື່ອໄດ້ຮັບການຮ້ອງຂໍ, ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍຂອງ Store API ທີ່ສອດຄ້ອງກັນ, ນັ້ນແມ່ນ, ກັບ Sidecars ຂອງພວກເຮົາແລະໄດ້ຮັບຂໍ້ມູນຊຸດເວລາຈາກເຄື່ອງແມ່ຂ່າຍຂອງ Prometheus ທີ່ສອດຄ້ອງກັນ.
2. ຫຼັງຈາກນັ້ນ, ມັນປະສົມປະສານຄໍາຕອບແລະປະຕິບັດການສອບຖາມ PromQL ກ່ຽວກັບພວກມັນ. Querier ສາມາດຮວມທັງຂໍ້ມູນທີ່ບໍ່ເຂົ້າກັນ ແລະຂໍ້ມູນຊໍ້າກັນຈາກເຊີບເວີ Prometheus HA.

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

ອາຍຸການເກັບຮັກສາບໍ່ຈໍາກັດ!

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

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

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

ຂະນະທີ່ທ່ານສາມາດເບິ່ງ, ການສໍາຮອງຂໍ້ມູນຂໍ້ມູນແມ່ນງ່າຍດາຍຫຼາຍ. ແຕ່ສິ່ງທີ່ກ່ຽວກັບການສອບຖາມຂໍ້ມູນໃນການເກັບຮັກສາວັດຖຸ?

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

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

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

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

ການບີບອັດແລະການລົງຕົວຢ່າງ

ເມື່ອຂໍ້ມູນຊຸດເວລາອັນໃໝ່ຖືກໂຫລດເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນວັດຖຸຢ່າງສຳເລັດຜົນ, ພວກເຮົາຖືວ່າມັນເປັນຂໍ້ມູນ “ປະຫວັດສາດ”, ເຊິ່ງສາມາດໃຊ້ໄດ້ທັນທີຜ່ານ Store Gateway.

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

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

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

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

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

ກົດລະບຽບການບັນທຶກ

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

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

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

ພະລັງຂອງ Thanos

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

1. ເພີ່ມ Thanos Sidecar ໃສ່ເຊີບເວີ Prometheus ຂອງທ່ານ - ຕົວຢ່າງເຊັ່ນຕູ້ຄອນເທນເນີ sidecar ໃນຝັກ Kubernetes.
2. ນຳໃຊ້ Thanos Querier replicas ຫຼາຍອັນເພື່ອໃຫ້ສາມາດເບິ່ງຂໍ້ມູນໄດ້. ໃນຂັ້ນຕອນນີ້ມັນງ່າຍທີ່ຈະຕັ້ງການນິນທາລະຫວ່າງ Scraper ແລະ Querier. ເພື່ອກວດສອບການໂຕ້ຕອບຂອງອົງປະກອບ, ໃຫ້ໃຊ້ 'thanos_cluster_members' metric.

ພຽງແຕ່ສອງຂັ້ນຕອນນີ້ແມ່ນພຽງພໍທີ່ຈະສະຫນອງການເບິ່ງທົ່ວໂລກແລະການຖອດຖອນຂໍ້ມູນທີ່ຊ້ໍາກັນຈາກການຈໍາລອງ Prometheus HA ທີ່ມີທ່າແຮງ! ພຽງແຕ່ເຊື່ອມຕໍ່ dashboards ຂອງທ່ານກັບຈຸດສິ້ນສຸດ Querier HTTP ຫຼືໃຊ້ Thanos UI ໂດຍກົງ.

ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານຕ້ອງການການສໍາຮອງຂໍ້ມູນ metrics ແລະການເກັບຮັກສາໃນໄລຍະຍາວ, ທ່ານຈະຕ້ອງເຮັດສາມຂັ້ນຕອນເພີ່ມເຕີມ:

1. ສ້າງ bucket AWS S3 ຫຼື GCS. ຕັ້ງຄ່າ Sidecar ເພື່ອສຳເນົາຂໍ້ມູນໃສ່ຖັງເຫຼົ່ານີ້. ການເກັບຮັກສາຂໍ້ມູນທ້ອງຖິ່ນໃນປັດຈຸບັນສາມາດຖືກຫຼຸດລົງ.
2. ນຳໃຊ້ Store Gateway ແລະເຊື່ອມຕໍ່ມັນກັບກຸ່ມການນິນທາທີ່ມີຢູ່ຂອງທ່ານ. ດຽວນີ້ທ່ານສາມາດສອບຖາມຂໍ້ມູນສຳຮອງໄດ້!
3. ນຳໃຊ້ Compactor ເພື່ອປັບປຸງປະສິດທິພາບການສອບຖາມໃນໄລຍະຍາວໂດຍການນຳໃຊ້ການບີບອັດ ແລະ ການຫຼຸດຕົວຢ່າງ.

ຖ້າທ່ານຕ້ອງການຮູ້ເພີ່ມເຕີມ, ຢ່າລັງເລທີ່ຈະເບິ່ງຂອງພວກເຮົາ kubernetes manifest ຕົວຢ່າງ и ເລີ່ມຕົ້ນ!

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

ການຮ້ອງຂໍດຶງ: ພວກເຮົາຕ້ອງການເຈົ້າ!

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

ພວກເຮົາຍິນດີຕ້ອນຮັບ GitHub Pull ການຮ້ອງຂໍແລະບັນຫາຕ່າງໆ. ໃນລະຫວ່າງນີ້, ກະລຸນາຕິດຕໍ່ຫາພວກເຮົາຜ່ານ Github Issues ຫຼື slack Improbable-eng #thanosຖ້າ​ຫາກ​ທ່ານ​ມີ​ຄໍາ​ຖາມ​ຫຼື​ຄໍາ​ຄຶດ​ຄໍາ​ເຫັນ​, ຫຼື​ຕ້ອງ​ການ​ທີ່​ຈະ​ແບ່ງ​ປັນ​ປະ​ສົບ​ການ​ຂອງ​ທ່ານ​ນໍາ​ໃຊ້​ມັນ​! ຖ້າທ່ານມັກສິ່ງທີ່ພວກເຮົາເຮັດຢູ່ Improbable, ຢ່າລັງເລທີ່ຈະຕິດຕໍ່ຫາພວກເຮົາ - ພວກເຮົາມີບ່ອນຫວ່າງຢູ່ສະເໝີ!

ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຫຼັກສູດ.

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