VictoriaMetrics ແລະການຕິດຕາມການຟັງເອກະຊົນ. Pavel Kolobaev

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

ຂ້ອຍຊື່ Kolobaev Pavel. DevOps, SRE, LeroyMerlin, ທຸກສິ່ງທຸກຢ່າງແມ່ນຄ້າຍຄືລະຫັດ - ມັນທັງຫມົດກ່ຽວກັບພວກເຮົາ: ກ່ຽວກັບຂ້ອຍແລະພະນັກງານ LeroyMerlin ອື່ນໆ.

https://bit.ly/3jf1fIK

ມີເມຄທີ່ອີງໃສ່ OpenStack. ມີການເຊື່ອມຕໍ່ຂະຫນາດນ້ອຍກັບ radar ດ້ານວິຊາການ.

ມັນຖືກສ້າງຂຶ້ນໃນຮາດແວ Kubernetes, ເຊັ່ນດຽວກັນກັບການບໍລິການທີ່ກ່ຽວຂ້ອງທັງຫມົດສໍາລັບ OpenStack ແລະການບັນທຶກ.

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

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

ການແກ້ໄຂທໍາອິດແມ່ນວ່າພວກເຮົາໃຊ້ສະຫະພັນໃນເວລາທີ່ພວກເຮົາມີພາກສ່ວນທີສາມ Prometheus, ເມື່ອພວກເຮົາໄປຫາກຸ່ມ Kubernetes ຜ່ານກົນໄກສະຫະພັນ.

ແຕ່ມີບາງບັນຫານ້ອຍໆຢູ່ທີ່ນີ້. ໃນກໍລະນີຂອງພວກເຮົາ, ບັນຫາເລີ່ມຕົ້ນເມື່ອພວກເຮົາມີ 250 metrics, ແລະເມື່ອມີ 000 metrics, ພວກເຮົາຮູ້ວ່າພວກເຮົາບໍ່ສາມາດເຮັດວຽກແບບນັ້ນໄດ້. ພວກເຮົາເພີ່ມຂຶ້ນ scrape_timeout ເປັນ 400 ວິນາທີ.

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

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

ທາງເລືອກຕໍ່ໄປແມ່ນ sharding ໂດຍອີງໃສ່ສອງ Prometheus ທີ່ແຕກຕ່າງກັນໂດຍຜ່ານກົນໄກສະຫະພັນດຽວກັນ.

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

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

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

ນັກພັດທະນາ Prometheus ເວົ້າຢ່າງຊັດເຈນວ່າ, "ຜູ້ຊາຍ, ໃຊ້ TimescaleDB ທີ່ແຕກຕ່າງກັນເພາະວ່າພວກເຮົາຈະບໍ່ສະຫນັບສະຫນູນການເກັບຮັກສາໃນໄລຍະຍາວຂອງ metrics." ນີ້ບໍ່ແມ່ນວຽກງານຂອງພວກເຂົາ.

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

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

ໃນປັດຈຸບັນພວກເຮົາມີສະພາບແວດລ້ອມ dev ແລະຜະລິດຕະພັນ. ໃນ dev ມັນແມ່ນປະມານ 9 gigabyte ສໍາລັບ 350 metrics. ໃນຜະລິດຕະພັນມັນແມ່ນ 000 gigabyte ແລະເລັກນ້ອຍກວ່າ 14 metrics. ໃນເວລາດຽວກັນ, ເວລາເກັບຮັກສາຂອງພວກເຮົາແມ່ນພຽງແຕ່ 780 ນາທີ. ນີ້ແມ່ນບໍ່ດີ. ແລະຕອນນີ້ຂ້ອຍຈະອະທິບາຍວ່າເປັນຫຍັງ.

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

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

ດ້ວຍພື້ນທີ່ດິດ, ບໍ່ແມ່ນທຸກຢ່າງທີ່ບໍ່ດີຢູ່ທີ່ນີ້, ແຕ່ຂ້ອຍຢາກປັບປຸງມັນ. ພວກເຮົາໄດ້ຮັບຈໍານວນທັງຫມົດ 15 gigabyte ໃນ 120 ມື້, ເຊິ່ງ 100 ແມ່ນຂໍ້ມູນທີ່ຖືກບີບອັດ, 20 ແມ່ນຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດ, ແຕ່ພວກເຮົາສະເຫມີຕ້ອງການຫນ້ອຍລົງ.

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

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

ນີ້ແມ່ນເຫດຜົນອີກອັນຫນຶ່ງທີ່ Prometheus ບໍ່ເຫມາະສົມກັບພວກເຮົາ, ເຊັ່ນ: ພວກເຮົາບໍ່ສາມາດຈໍາກັດການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ.

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

ໂຄງ​ການ​ນີ້​ເວົ້າ​ວ່າ​ພວກ​ເຮົາ​ຈະ​ມີ​ການ​ຊ​້​ໍາ​ກັນ​ຂອງ shards​, ແລະ​, ດັ່ງ​ນັ້ນ​, ການ​ຊໍ້າ​ຊ້ອນ​ຂອງ​ຄ່າ​ໃຊ້​ຈ່າຍ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​ການ​ບໍ​ລິ​ໂພກ​. ມັນສາມາດປັບຂະ ໜາດ ເກືອບຕາມແນວນອນ, ແຕ່ຢ່າງໃດກໍ່ຕາມ, ການບໍລິໂພກຊັບພະຍາກອນຈະເປັນ hellish.

ຂໍ້ເສຍໃນຄໍາສັ່ງໃນຮູບແບບທີ່ພວກເຮົາຂຽນໃຫ້ເຂົາເຈົ້າສໍາລັບຕົວເຮົາເອງ:

• ຮຽກຮ້ອງໃຫ້ມີການອັບໂຫລດເມຕຣິກພາຍນອກ.
• ການບໍລິໂພກຊັບພະຍາກອນສູງ.
• ບໍ່ມີວິທີການຈໍາກັດການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ.
• ການຈັດຕັ້ງປະຕິບັດ HA ທີ່ຊັບຊ້ອນ ແລະ ເຂັ້ມງວດຫຼາຍ.

ສໍາລັບຕົວເຮົາເອງ, ພວກເຮົາໄດ້ຕັດສິນໃຈວ່າພວກເຮົາຍ້າຍອອກໄປຈາກ Prometheus ເພື່ອເປັນບ່ອນເກັບຮັກສາ.

ພວກເຮົາໄດ້ກໍານົດຄວາມຕ້ອງການເພີ່ມເຕີມສໍາລັບຕົວເຮົາເອງທີ່ພວກເຮົາຕ້ອງການ. ນີ້:

• ນີ້ແມ່ນການສະຫນັບສະຫນູນ promql, ເພາະວ່າຫຼາຍໆຢ່າງໄດ້ຖືກຂຽນແລ້ວສໍາລັບ Prometheus: ຄໍາຖາມ, ການແຈ້ງເຕືອນ.
• ແລະຫຼັງຈາກນັ້ນພວກເຮົາມີ Grafana, ເຊິ່ງຂຽນແລ້ວໃນລັກສະນະດຽວກັນກັບ Prometheus ເປັນ backend. ຂ້ອຍບໍ່ຕ້ອງການຂຽນ dashboards ຄືນໃໝ່.
• ພວກເຮົາຕ້ອງການສ້າງສະຖາປັດຕະຍະກໍາ HA ປົກກະຕິ.
• ພວກເຮົາຕ້ອງການຫຼຸດຜ່ອນການບໍລິໂພກຊັບພະຍາກອນໃດໆ.
• ມີ nuance ຂະຫນາດນ້ອຍອີກ. ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ປະ​ເພດ​ຕ່າງໆ​ຂອງ​ລະ​ບົບ​ການ​ເກັບ​ກໍາ​ການ​ວັດ​ແທກ​ຟັງ​ໄດ້​. ພວກເຮົາບໍ່ຮູ້ວ່າອັນໃດຈະຕົກຢູ່ໃນຕົວວັດແທກເຫຼົ່ານີ້ເທື່ອ. ແລະນັບຕັ້ງແຕ່ສິ່ງໃດສາມາດບິນຢູ່ທີ່ນັ້ນ, ພວກເຮົາຕ້ອງຈໍາກັດຕົວເຮົາເອງໃນການບັນຈຸເຂົ້າຮຽນໃນທ້ອງຖິ່ນ.

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

ເປັນຫຍັງ? ເນື່ອງຈາກວ່າ:

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

ໃຫ້ພວກເຮົາເຮັດການປຽບທຽບທໍາອິດ. ພວກເຮົາເອົາ Prometheus ດຽວກັນພາຍໃນກຸ່ມ, Prometheus ພາຍນອກໄປຫາມັນ. ເພີ່ມຜ່ານ remoteWrite VictoriaMetrics.

ຂ້ອຍຈະຈອງທັນທີວ່າໃນທີ່ນີ້ພວກເຮົາຈັບການບໍລິໂພກ CPU ເພີ່ມຂຶ້ນເລັກນ້ອຍຈາກ VictoriaMetrics. VictoriaMetrics wiki ບອກທ່ານວ່າຕົວກໍານົດການໃດທີ່ດີທີ່ສຸດ. ພວກເຮົາໄດ້ກວດເບິ່ງພວກມັນ. ພວກເຂົາເຈົ້າໄດ້ຫຼຸດຜ່ອນການບໍລິໂພກ CPU ໄດ້ດີຫຼາຍ.

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

ພວກເຮົາປຽບທຽບສອງແຫຼ່ງຂໍ້ມູນຂອງຂໍ້ມູນດຽວກັນ. ໃນ Prometheus ພວກເຮົາເຫັນຂໍ້ມູນທີ່ຂາດຫາຍໄປຄືກັນ. ທຸກຢ່າງແມ່ນດີຢູ່ VictoriaMetrics.

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

ພວກເຮົາຍັງປະຫຍັດການບໍລິໂພກຊັບພະຍາກອນຫນ່ວຍຄວາມຈໍາ. ໃນເວລາທີ່ການທົດສອບ, ພວກເຮົາມີ Prometheus ນໍາໃຊ້ໃນເຄື່ອງ virtual - 8 cores, 24 gigabytes. Prometheus ກິນເກືອບທຸກຢ່າງ. ລາວຕົກໃສ່ OOM Killer. ໃນເວລາດຽວກັນ, ພຽງແຕ່ 900 metrics ທີ່ມີການເຄື່ອນໄຫວໄດ້ຖືກ poured ເຂົ້າໄປໃນມັນ. ນີ້ແມ່ນປະມານ 000-25 ແມັດຕໍ່ວິນາທີ.

ພວກເຮົາແລ່ນ VictoriaMetrics ໃນເຄື່ອງ virtual dual-core ທີ່ມີ RAM 8 gigabyte. ພວກ​ເຮົາ​ໄດ້​ຈັດ​ການ​ໃຫ້ VictoriaMetrics ເຮັດ​ວຽກ​ໄດ້​ດີ​ໂດຍ​ການ fiddling ກັບ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ໃນ​ເຄື່ອງ 8GB. ໃນທີ່ສຸດ, ພວກເຮົາເກັບຮັກສາມັນໄວ້ 7 gigabyte. ໃນເວລາດຽວກັນ, ຄວາມໄວຂອງການຈັດສົ່ງເນື້ອຫາ, i.e. metrics, ແມ່ນສູງກວ່າ Prometheus.

CPU ໄດ້ກາຍເປັນທີ່ດີກວ່າເມື່ອທຽບກັບ Prometheus. ທີ່ນີ້ Prometheus ບໍລິໂພກ 2,5 cores, ແລະ VictoriaMetrics ບໍລິໂພກພຽງແຕ່ 0,25 cores. ໃນຕອນເລີ່ມຕົ້ນ - 0,5 ແກນ. ເມື່ອມັນລວມເຂົ້າກັນ, ມັນໄປຮອດໜຶ່ງຫຼັກ, ແຕ່ອັນນີ້ແມ່ນຫາຍາກທີ່ສຸດ.

ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ພວກ​ເຮົາ, ທາງ​ເລືອກ​ໄດ້​ຫຼຸດ​ລົງ​ກ່ຽວ​ກັບ VictoriaMetrics ສໍາ​ລັບ​ເຫດ​ຜົນ​ທີ່​ຈະ​ແຈ້ງ; ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ປະ​ຢັດ​ເງິນ​ແລະ​ພວກ​ເຮົາ​ໄດ້​ເຮັດ.

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

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

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

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

ລົບອີກຈຸດຫນຶ່ງ, i.e. ຂ້າມຈຸດອອກ - ທ່ານບໍ່ສາມາດຈໍາກັດການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ.

ໃນ iterations ທໍາອິດ, ພວກເຮົາໄດ້ທົດສອບ VictoriaMetrics Single Node. ຕໍ່ໄປ, ພວກເຮົາຍ້າຍໄປ VictoriaMetrics Cluster Version.

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

ອົງປະກອບຫຼັກຂອງ VictoriaMetrics Cluster Version ແມ່ນ vmstsorage. ສາມາດມີຈໍານວນ N. ໃນກໍລະນີຂອງພວກເຮົາມີ 2 ຂອງພວກເຂົາມາເຖິງຕອນນັ້ນ.

ແລະມີ vminsert. ນີ້ແມ່ນເຊີບເວີພຣັອກຊີທີ່ອະນຸຍາດໃຫ້ພວກເຮົາ: ຈັດແຈງ sharding ລະຫວ່າງການເກັບຮັກສາທັງຫມົດທີ່ພວກເຮົາໄດ້ບອກມັນກ່ຽວກັບ, ແລະມັນຍັງອະນຸຍາດໃຫ້ replica, i.e. ທ່ານຈະມີທັງ sharding ແລະ replica.

Vminsert ຮອງຮັບ OpenTSDB, Graphite, InfluxDB ແລະ remoteWrite protocols ຈາກ Prometheus.

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

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

ການບໍລິການທີ່ດີອີກອັນຫນຶ່ງແມ່ນ vmalert, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານໃຊ້ VictoriaMetrics ເປັນ backend, ຮັບຂໍ້ມູນການປຸງແຕ່ງຈາກ vminsert ແລະສົ່ງໄປທີ່ vmselect. ມັນປະມວນຜົນການແຈ້ງເຕືອນດ້ວຍຕົນເອງ, ເຊັ່ນດຽວກັນກັບກົດລະບຽບ. ໃນກໍລະນີຂອງການແຈ້ງເຕືອນ, ພວກເຮົາໄດ້ຮັບການແຈ້ງເຕືອນໂດຍຜ່ານ alertmanager.

ມີອົງປະກອບ wmauth. ພວກເຮົາອາດຈະ ຫຼື ອາດຈະບໍ່ (ພວກເຮົາຍັງບໍ່ໄດ້ຕັດສິນໃຈກ່ຽວກັບເລື່ອງນີ້ເທື່ອ) ໃຊ້ມັນເປັນລະບົບການອະນຸຍາດສໍາລັບການສະບັບ multitenancy ຂອງ clusters. ມັນສະຫນັບສະຫນູນ remoteWrite ສໍາລັບ Prometheus ແລະສາມາດອະນຸຍາດໂດຍອີງໃສ່ url, ຫຼືແທນທີ່ຈະເປັນສ່ວນທີສອງຂອງມັນ, ບ່ອນທີ່ທ່ານສາມາດຫຼືບໍ່ສາມາດຂຽນໄດ້.

ນອກຈາກນີ້ຍັງມີ vmbackup, vmrestore. ນີ້ແມ່ນ, ໂດຍເນື້ອແທ້ແລ້ວ, ການຟື້ນຟູແລະການສໍາຮອງຂໍ້ມູນຂອງຂໍ້ມູນທັງຫມົດ. ສາມາດເຮັດໄດ້ S3, GCS, ໄຟລ໌.

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

ທີ່ນີ້ຂ້ອຍຈະຈອງວ່າເມື່ອພວກເຮົາປ່ຽນຈາກ VictoriaMetrics Single Node ໄປ VictoriaMetrics Cluster Version, ພວກເຮົາຍັງຄົງຢູ່ກັບຊັບພະຍາກອນທີ່ບໍລິໂພກຄືກັນ, ເຊັ່ນ: ຕົ້ນຕໍແມ່ນຫນ່ວຍຄວາມຈໍາ. ນີ້ແມ່ນປະມານວິທີທີ່ຂໍ້ມູນຂອງພວກເຮົາ, i.e. ການບໍລິໂພກຊັບພະຍາກອນ, ຖືກແຈກຢາຍ.

ການຈຳລອງໄດ້ຖືກເພີ່ມໃສ່ບ່ອນນີ້ແລ້ວ. ພວກເຮົາລວມທັງຫມົດນີ້ເຂົ້າໄປໃນກຸ່ມຫນຶ່ງທີ່ຂ້ອນຂ້າງໃຫຍ່. ຂໍ້​ມູນ​ທັງ​ຫມົດ​ຂອງ​ພວກ​ເຮົາ​ແມ່ນ​ທັງ sharded ແລະ replicated​.

ກຸ່ມທັງຫມົດມີຈຸດເຂົ້າ N, ຊຶ່ງຫມາຍຄວາມວ່າ Prometheus ສາມາດເພີ່ມຂໍ້ມູນຜ່ານ HAPROXY. ທີ່ນີ້ພວກເຮົາມີຈຸດເຂົ້ານີ້. ແລະໂດຍຜ່ານຈຸດເຂົ້ານີ້ທ່ານສາມາດເຂົ້າສູ່ລະບົບຈາກ Grafana.

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

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

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

ພວກເຮົາສິ້ນສຸດບັນຊີລາຍຊື່ຂອງພວກເຮົາດ້ວຍການຈັດຕັ້ງປະຕິບັດ HA.

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

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

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

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

ມີຂໍ້ສະເໜີເພື່ອປັບປຸງການຈັດຕັ້ງປະຕິບັດກຸ່ມ. ຂ້າພະເຈົ້າໄດ້ອະທິບາຍໃຫ້ເຂົາເຈົ້າຂ້າງເທິງ.

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

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

ພວກເຮົາຈະໃຊ້ VictoriaMetrics ຢູ່ເຮືອນເພາະວ່າພວກເຮົາມັກມັນ. ນີ້ແມ່ນສິ່ງທີ່ເປັນແລະສິ່ງທີ່ໄດ້ກາຍເປັນ.

https://t.me/VictoriaMetrics_ru1

ສອງສາມລະຫັດ QR ສໍາລັບການສົນທະນາ VictoriaMetrics, ຕິດຕໍ່ພົວພັນຂອງຂ້ອຍ, LeroyMerlin radar ດ້ານວິຊາການ.

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