"ExtendedPromQL" - ບັນທຶກບົດລາຍງານຂອງ Roman Khavronenko

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານຂອງ Roman Khavronenko "ExtendedPromQL"

ໂດຍຫຍໍ້ກ່ຽວກັບຂ້ອຍ. ຂ້ອຍຊື່ Roman. ຂ້ອຍເຮັດວຽກຢູ່ CloudFlare ແລະອາໄສຢູ່ໃນລອນດອນ. ແຕ່ຂ້ອຍຍັງເປັນຜູ້ຮັກສາ VictoriaMetrics.
ແລະຂ້ອຍເປັນຜູ້ຂຽນ ປັ໊ກອິນ ClickHouse ສໍາລັບ Grafana ແລະ ClickHouse-proxy ເປັນຕົວແທນຂະຫນາດນ້ອຍສໍາລັບ ClickHouse.

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

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

ຂໍ້ມູນຊຸດເວລາແມ່ນຫຍັງ? ໂດຍວິທີທາງການ, ເຫຼົ່ານີ້ແມ່ນສາມຕົວກໍານົດການ.

ເຫຼົ່ານີ້ແມ່ນ:

• ພວກເຮົາເບິ່ງຫຍັງ?
• ເມື່ອພວກເຮົາເບິ່ງມັນ.
• ແລະມັນສະແດງໃຫ້ເຫັນຄຸນຄ່າອັນໃດ?

ຖ້າທ່ານເບິ່ງຕາຕະລາງນີ້ (ຕາຕະລາງນີ້ແມ່ນມາຈາກໂທລະສັບຂອງຂ້ອຍທີ່ສະແດງສະຖິຕິຂັ້ນຕອນຂອງຂ້ອຍ), ມັນສາມາດຕອບຄໍາຖາມເຫຼົ່ານີ້ໄດ້ໄວ.

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

ຕອນນີ້ໃຫ້ "ແຍກ" (ປ່ຽນ) ພວກມັນເຂົ້າໄປໃນຕົວແບບຂໍ້ມູນອື່ນໃນຮູບແບບຕາຕະລາງ. ໃນທີ່ນີ້ພວກເຮົາຍັງມີສິ່ງທີ່ພວກເຮົາກໍາລັງຊອກຫາຢູ່. ໃນທີ່ນີ້ຂ້ອຍໄດ້ເພີ່ມຂໍ້ມູນເລັກນ້ອຍ, ເຊິ່ງພວກເຮົາຈະເອີ້ນວ່າ meta-data, i.e. ມັນບໍ່ແມ່ນຂ້ອຍທີ່ຜ່ານເລື່ອງນີ້, ແຕ່ສອງຄົນ, ຕົວຢ່າງ, Jay ແລະ Silent Bob. ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາກໍາລັງຊອກຫາຢູ່ໃນ; ມັນສະແດງໃຫ້ເຫັນແນວໃດ ແລະເມື່ອໃດມັນສະແດງໃຫ້ເຫັນຄຸນຄ່ານັ້ນ.

ຕອນນີ້ໃຫ້ພະຍາຍາມເກັບຂໍ້ມູນທັງໝົດນີ້ໄວ້ໃນຖານຂໍ້ມູນ. ຕົວຢ່າງ, ຂ້າພະເຈົ້າໄດ້ເອົາ syntax ClickHouse. ແລະໃນທີ່ນີ້ພວກເຮົາສ້າງຕາຕະລາງຫນຶ່ງທີ່ເອີ້ນວ່າ "ຂັ້ນຕອນ", i.e. ສິ່ງທີ່ພວກເຮົາກໍາລັງຊອກຫາຢູ່. ມີເວລາທີ່ພວກເຮົາເບິ່ງມັນ; ສິ່ງທີ່ມັນສະແດງໃຫ້ເຫັນແລະບາງຂໍ້ມູນ meta ບ່ອນທີ່ພວກເຮົາຈະເກັບຮັກສາວ່າມັນແມ່ນໃຜ: Jay ແລະ Silent Bob.

ແລະເພື່ອພະຍາຍາມຈິນຕະນາການທັງຫມົດນີ້, ພວກເຮົາຈະໃຊ້ Grafana ເພາະວ່າ, ກ່ອນອື່ນ ໝົດ, ມັນສວຍງາມ.

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

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

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

ແລະດັ່ງນັ້ນ, ພວກເຮົາຈະໄດ້ຮັບເສັ້ນສະແດງເຊັ່ນນີ້. ໃຜຮູ້ວ່າເປັນຫຍັງລາວຈຶ່ງແປກ?

ນັ້ນແມ່ນ, ພວກເຮົາຈໍາເປັນຕ້ອງຈັດຮຽງຕາມເວລາ.

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

ດັ່ງນັ້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງເລືອກບຸກຄົນສະເພາະ. ພວກເຮົາເລືອກ Jay.

ແລະໃຫ້ແຕ້ມອີກເທື່ອຫນຶ່ງ. ໃນປັດຈຸບັນກາຟເບິ່ງຄືວ່າຄວາມຈິງ. ໃນປັດຈຸບັນນີ້ແມ່ນຕາຕະລາງປົກກະຕິແລະທຸກສິ່ງທຸກຢ່າງແມ່ນເຮັດວຽກໄດ້ດີ.

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

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

ແລະມັນຈະສະແດງໃຫ້ເຫັນຄຸນຄ່າເຫຼົ່ານີ້ປະມານ, i.e. Silent Bob ຫຼື Jay ໃຊ້ເວລາປະມານ 1,8 ກ້າວຕໍ່ວິນາທີ.

ແລະໃນ Prometheus ເຈົ້າຮູ້ວິທີເຮັດສິ່ງນີ້ຄືກັນ. ງ່າຍ​ຂຶ້ນ​ກ​່​ວາ​ທີ່​ຜ່ານ​ມາ​.

ແລະເພື່ອເຮັດໃຫ້ມັນງ່າຍທີ່ຈະເຮັດໃນ Grafana, ຂ້າພະເຈົ້າໄດ້ເພີ່ມ wrapper ນີ້, ເຊິ່ງມີລັກສະນະຄ້າຍຄືກັນກັບ PromQL. ມັນຖືກເອີ້ນວ່າ Rate Macros ຫຼືອັນໃດກໍໄດ້ທີ່ທ່ານຕ້ອງການໂທຫາມັນ. ໃນ Grafana ທ່ານພຽງແຕ່ຂຽນ "ອັດຕາ", ແຕ່ບາງບ່ອນເລິກລົງມັນປ່ຽນເປັນຄໍາຮ້ອງຂໍໃຫຍ່ນີ້. ແລະທ່ານບໍ່ ຈຳ ເປັນຕ້ອງເບິ່ງມັນ, ມັນຢູ່ບ່ອນໃດບ່ອນ ໜຶ່ງ, ແຕ່ເຈົ້າປະຫຍັດເວລາຫຼາຍ, ເພາະວ່າການຂຽນ ຄຳ ຖາມ SQL ອັນໃຫຍ່ຫຼວງແມ່ນລາຄາແພງສະ ເໝີ ໄປ. ທ່ານສາມາດເຮັດຜິດພາດໄດ້ຢ່າງງ່າຍດາຍແລະຫຼັງຈາກນັ້ນບໍ່ເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນເປັນເວລາດົນນານ.

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

ແລະອີງຕາມ Prometheus ມັນຈະເປັນຜົນລວມ (ອັດຕາ). ສໍາລັບ ClickHouse, ຂ້າພະເຈົ້າໄດ້ສ້າງມະຫາພາກແຍກຕ່າງຫາກທີ່ເອີ້ນວ່າ RateColumns, ເຊິ່ງຄ້າຍຄືກັບການສອບຖາມໃນ Prometheus.

ພວກເຮົາໄດ້ເບິ່ງມັນແລະ PromQL ເບິ່ງຄືວ່າເຢັນຫຼາຍ, ແຕ່ແນ່ນອນວ່າມັນມີຂໍ້ຈໍາກັດ.

ເຫຼົ່ານີ້ແມ່ນ:

• SELECT ຈຳກັດ.
• ເຂົ້າຮ່ວມເສັ້ນຊາຍແດນ.
• ບໍ່ມີການຮອງຮັບ HAVING.

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

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

ແລະສ່ວນຕໍ່ໄປແມ່ນຂະຫຍາຍ PromQL.

ອີກເທື່ອຫນຶ່ງກ່ຽວກັບ VictoriaMetrics. VictoriaMetrics ແມ່ນຫຍັງ? ນີ້ແມ່ນຖານຂໍ້ມູນຊຸດເວລາ, ມັນແມ່ນຢູ່ໃນ OpenSource, ພວກເຮົາແຈກຢາຍສະບັບດຽວແລະກຸ່ມ. ອີງຕາມມາດຕະຖານຂອງພວກເຮົາ, ມັນໄວກວ່າສິ່ງທີ່ຢູ່ໃນຕະຫຼາດໃນປັດຈຸບັນແລະການບີບອັດແມ່ນຄ້າຍຄືກັນ, i.e. ຄົນທີ່ແທ້ຈິງລາຍງານການບີບອັດປະມານ 0,4 bytes ຕໍ່ຈຸດ, ໃນຂະນະທີ່ Prometheus's ແມ່ນ 1,2-1,4.

ພວກເຮົາສະຫນັບສະຫນູນຫຼາຍກ່ວາພຽງແຕ່ Prometheus. ພວກເຮົາສະຫນັບສະຫນູນ InfluxDB, Graphite, OpenTSDB.

ທ່ານສາມາດ "ຂຽນ" ໃຫ້ພວກເຮົາ, ນັ້ນແມ່ນ, ທ່ານສາມາດໂອນຂໍ້ມູນເກົ່າໄດ້.

ແລະພວກເຮົາຍັງເຮັດວຽກຢ່າງສົມບູນກັບ Prometheus ແລະ Grafana, i.e. ພວກເຮົາສະຫນັບສະຫນູນເຄື່ອງຈັກ PromQL. ແລະໃນ Grafana ທ່ານພຽງແຕ່ສາມາດປ່ຽນຈຸດສິ້ນສຸດຂອງ Prometheus ເປັນ VictoriaMetrics ແລະ dashboards ທັງຫມົດຂອງທ່ານຈະເຮັດວຽກຄືກັບພວກເຂົາ.

ແຕ່ທ່ານຍັງສາມາດໃຊ້ຄຸນສົມບັດເພີ່ມເຕີມທີ່ VictoriaMetrics ໃຫ້.

ພວກ​ເຮົາ​ຈະ​ໄປ​ຢ່າງ​ວ່ອງ​ໄວ​ໂດຍ​ຜ່ານ​ຄຸນ​ສົມ​ບັດ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເພີ່ມ​ຂຶ້ນ​.

Omit interval param — ທ່ານ​ສາ​ມາດ​ຍົກ​ເວັ້ນ​ຕົວ​ກໍາ​ນົດ​ການ​ໄລ​ຍະ​ໃນ Grafana​. ເມື່ອທ່ານບໍ່ຕ້ອງການທີ່ຈະໄດ້ຮັບກາຟທີ່ແປກປະຫລາດໃນເວລາຊູມເຂົ້າ / ອອກໃນກະດານ, ມັນແນະນໍາໃຫ້ໃຊ້ຕົວແປ. $__interval. ນີ້ແມ່ນການປ່ຽນແປງ Grafana ພາຍໃນແລະມັນເລືອກລະດັບຂໍ້ມູນຂອງມັນເອງ. ແລະ VictoriaMetrics ຕົວຂອງມັນເອງສາມາດເຂົ້າໃຈວ່າຂອບເຂດນີ້ຄວນຈະເປັນແນວໃດ. ແລະທ່ານບໍ່ຈໍາເປັນຕ້ອງປັບປຸງການຮ້ອງຂໍທັງຫມົດຂອງທ່ານ. ມັນຈະງ່າຍຂຶ້ນຫຼາຍ.

ຫນ້າທີ່ທີສອງແມ່ນການອ້າງອີງໄລຍະຫ່າງ. ທ່ານສາມາດນໍາໃຊ້ໄລຍະນີ້ໃນການສະແດງອອກຂອງທ່ານ. ທ່ານສາມາດຄູນ, ແບ່ງ, ໂອນ, ອ້າງເຖິງມັນ.

ຕໍ່ໄປແມ່ນຄອບຄົວຟັງຊັນມ້ວນ. ຟັງຊັນ Rollup ປ່ຽນຊຸດເວລາໃດນຶ່ງຂອງເຈົ້າເປັນສາມຊຸດເວລາແຍກຕ່າງຫາກ. ເຫຼົ່ານີ້ແມ່ນຕ່ຳສຸດ, ສູງສຸດ ແລະສະເລ່ຍ. ຂ້າພະເຈົ້າເຫັນວ່າອັນນີ້ສະດວກຫຼາຍເພາະວ່າບາງຄັ້ງມັນສາມາດສະແດງໃຫ້ເຫັນບາງ outliers ແລະຄວາມບໍ່ຖືກຕ້ອງ.

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

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

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

Scrape_interval – ສະ​ແດງ​ໃຫ້​ເຫັນ​ວ່າ Prometheus ເກັບ​ກໍາ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ການ​ວັດ​ແທກ​ຂອງ​ທ່ານ​, ແລະ​ຄວາມ​ຖີ່​ຂອງ​ການ​ໃດ​. ທີ່ນີ້ທ່ານສາມາດເບິ່ງຜ່ານ, ສໍາລັບການຍົກຕົວຢ່າງ.

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

ເພາະສະນັ້ນ, ເປັນຫຍັງຈຶ່ງບໍ່ເຮັດໃຫ້ພວກເຂົາງ່າຍດາຍ? ນັ້ນແມ່ນ, ແບ່ງມັນອອກເປັນຫນ້າທີ່ຂະຫນາດນ້ອຍທີ່ມີ syntax ທີ່ເຂົ້າໃຈໄດ້.

ແລະໃນປັດຈຸບັນສ່ວນມ່ວນ. ເປັນຫຍັງພວກເຮົາຄິດວ່ານີ້ແມ່ນ PromQL ຂະຫຍາຍ? ເນື່ອງຈາກວ່າພວກເຮົາສະຫນັບສະຫນູນການສະແດງຕາຕະລາງທົ່ວໄປ. ທ່ານສາມາດປະຕິບັດຕາມລະຫັດ QR (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), ເບິ່ງການເຊື່ອມຕໍ່ທີ່ມີຕົວຢ່າງ, ຈາກສະຫນາມເດັກຫຼິ້ນ, ບ່ອນທີ່ທ່ານສາມາດດໍາເນີນການສອບຖາມໂດຍກົງໃນ VictoriaMetrics ໂດຍບໍ່ຕ້ອງຕິດຕັ້ງມັນພຽງແຕ່ຢູ່ໃນຕົວທ່ອງເວັບ.

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

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

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

ແລະດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ສ້າງທາງເລືອກທີ່ອະນຸຍາດໃຫ້ທ່ານເຮັດສິ່ງນີ້. ແລະຖ້າທ່ານສົນໃຈຫຼືຕ້ອງການລັກສະນະດັ່ງກ່າວ, ຫຼັງຈາກນັ້ນສະຫນັບສະຫນູນມັນຫຼືບໍ່ມັກມັນຖ້າທ່ານບໍ່ມັກຄວາມຄິດນີ້. https://github.com/grafana/grafana/pull/16694

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

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

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

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

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

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

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

ອັນນີ້ບໍ່ມີແທ້ໆ. ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍເຮັດເອງ. ນີ້ແມ່ນສະຫນັບສະຫນູນຫ້ອງສະຫມຸດໃນ Grafana. ໃຫ້ເວົ້າວ່າຜູ້ຊາຍທີ່ສ້າງ NodeExporter ໄດ້ເຮັດສິ່ງທີ່ຂ້ອຍເວົ້າກ່ຽວກັບ. ແລະພວກເຂົາຍັງໄດ້ສະຫນອງຊຸດຂອງຫນ້າທີ່.

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

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

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

ຄໍາຖາມ:

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

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

ວິທີການກວດສອບ?

ກວດເບິ່ງແນວໃດ? ອາດຈະບໍ່.

ໃນຖານະເປັນການທົດສອບໃນ Grafana.

Grafana ເຮັດແນວໃດກັບມັນ? Grafana ແປຄໍາຮ້ອງຂໍນີ້ໂດຍກົງກັບ DataSource.

ເພີ່ມເລັກນ້ອຍໃສ່ຕົວກໍານົດການ.

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

ຂອບໃຈສໍາລັບບົດລາຍງານ! ຂອບໃຈສໍາລັບການບີບອັດ! ທ່ານຈື່ຈໍາກ່ຽວກັບການສ້າງແຜນທີ່ຕົວແປໃນກາຟ, ວ່າໃນ Grafana ທ່ານບໍ່ສາມາດໃຊ້ຕົວແປພາຍໃນຕົວແປໄດ້. ເຈົ້າຮູ້ວ່າຂ້ອຍຫມາຍຄວາມວ່າແນວໃດ?

ແມ່ນແລ້ວ.

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

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

ແມ່ນແລ້ວ, ຂ້ອຍໃຊ້ມັນ, ແຕ່ມັນເບິ່ງຄືວ່າງ່າຍຕໍ່ການຕັ້ງຄ່າໃນ Grafana, ແຕ່ຂອບໃຈສໍາລັບຄໍາແນະນໍາ!

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