ການຕິດຕາມກຸ່ມ Kubernetes: ພາບລວມ ແລະ ການແນະນຳກ່ຽວກັບ Prometheus

ຂໍໃຫ້ເບິ່ງແນວຄວາມຄິດຂອງການຕິດຕາມ Kubernetes, ຮູ້ຈັກກັບເຄື່ອງມື Prometheus, ແລະສົນທະນາກ່ຽວກັບການແຈ້ງເຕືອນ.

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

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

ສິ່ງທີ່ຖືກຕິດຕາມຢູ່ໃນກຸ່ມ Kubernetes

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

ຂໍໃຫ້ກ້າວໄປສູ່ການຕິດຕາມກວດກາໃນລະດັບກຸ່ມ.

ອົງປະກອບຂອງຍົນຄວບຄຸມ: API, Scheduler ແລະອື່ນໆ. ຕໍາ່ສຸດທີ່, ທ່ານຈໍາເປັນຕ້ອງໄດ້ຕິດຕາມກວດກາວ່າ API ຂອງເຄື່ອງແມ່ຂ່າຍຫຼື etcd ແມ່ນຫຼາຍກ່ວາ 0. Etcd ສາມາດສະຫນອງຫຼາຍ metrics: ໃນແຜ່ນທີ່ມັນ spin, ກ່ຽວກັບສຸຂະພາບຂອງກຸ່ມ etcd ຂອງມັນ, ແລະອື່ນໆ.

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

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

ຂາເຂົ້າ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຄວບຄຸມການມີ ingresses (ລວມທັງ Ingress Controller) ເປັນຈຸດເຂົ້າໄປໃນໂຄງການ.

ອົງປະກອບຕົ້ນຕໍຂອງກຸ່ມໄດ້ຖືກ disassembled - ໃນປັດຈຸບັນໃຫ້ຕ່ໍາກວ່າ, ໃນລະດັບຂອງ abstractions.

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

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

Prometheus

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

ມີທາງເລືອກຄູ່ສໍາລັບການເລີ່ມຕົ້ນກັບ Prometheus: ການນໍາໃຊ້ Helm, ທ່ານສາມາດຕິດຕັ້ງ Prometheus ຫຼື Prometheus Operator ປົກກະຕິ.

1. Prometheus ປົກກະຕິ. ທຸກສິ່ງທຸກຢ່າງແມ່ນດີກັບມັນ, ແຕ່ທ່ານຈໍາເປັນຕ້ອງຕັ້ງຄ່າ ConfigMap - ສໍາຄັນ, ຂຽນໄຟລ໌ການຕັ້ງຄ່າຂໍ້ຄວາມ, ດັ່ງທີ່ພວກເຮົາເຄີຍເຮັດ, ກ່ອນທີ່ຈະມີສະຖາປັດຕະຍະກໍາ microservice.
2. Prometheus Operator ແມ່ນກວ້າງກວ່າເລັກນ້ອຍ, ສັບສົນຫຼາຍໃນເຫດຜົນພາຍໃນຂອງມັນ, ແຕ່ມັນງ່າຍຕໍ່ການເຮັດວຽກກັບ: ມີວັດຖຸແຍກຕ່າງຫາກ, abstractions ຖືກເພີ່ມເຂົ້າໃນກຸ່ມ, ດັ່ງນັ້ນພວກມັນສະດວກກວ່າທີ່ຈະຄວບຄຸມແລະຕັ້ງຄ່າ.

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

Prometheus ແມ່ນປະສົມປະສານໄດ້ດີກັບ Kubernetes: ມັນສາມາດເຂົ້າເຖິງແລະພົວພັນກັບ API Server.

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

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

ເຊີບເວີ Prometheus — ນີ້ແມ່ນພາກສ່ວນເຊີບເວີ, ສະໝອງຂອງ Prometheus. ນີ້ແມ່ນບ່ອນທີ່ metrics ຖືກເກັບຮັກສາແລະປຸງແຕ່ງ.

metrics ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນຊຸດເວລາ (TSDB). TSDB ບໍ່ແມ່ນຖານຂໍ້ມູນແຍກຕ່າງຫາກ, ແຕ່ເປັນຊຸດ Go ທີ່ສ້າງຂຶ້ນໃນ Prometheus. ເວົ້າປະມານ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນຄູ່ດຽວ.

ຢ່າເກັບຂໍ້ມູນໄວ້ໃນ TSDB ເປັນເວລາດົນ

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

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

Prometheus Server ເຮັດວຽກຕາມແບບຈໍາລອງ ດຶງ: ລາວເອງໄປສໍາລັບ metrics ກັບຈຸດສິ້ນສຸດທີ່ພວກເຮົາໄດ້ໃຫ້ເຂົາ. ພວກເຂົາເວົ້າວ່າ: "ໄປທີ່ API Server," ແລະມັນໄປບ່ອນນັ້ນທຸກໆວິນາທີແລະໃຊ້ເວລາວັດແທກ.

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

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

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

ວິທີການນີ້ເຫມາະສົມກັບໂຄງສ້າງຂອງ Kubernetes, ບ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງຍັງເລື່ອນໄດ້: ມື້ນີ້ມີ 10 ເຄື່ອງແມ່ຂ່າຍ, ມື້ອື່ນ 3. ເພື່ອບໍ່ໃຫ້ຊີ້ໃຫ້ເຫັນເຖິງທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍທຸກໆຄັ້ງ, ພວກເຮົາເຄີຍຂຽນວິທີການຊອກຫາມັນ - ແລະ Discovering ຈະເຮັດມັນ.

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

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

ການໂຕ້ຕອບເວັບ Prometheus

Prometheus ມີອິນເຕີເຟດເວັບໄຊຕ໌ຂອງຕົນເອງ, ຫນ້ອຍທີ່ສຸດ. ພຽງແຕ່ເຫມາະສົມສໍາລັບການ debugging ຫຼືສາທິດ.

ທ່ານສາມາດຂຽນຄໍາຖາມໃນ PromQL ໃນເສັ້ນສະແດງອອກ.

ແຖບການແຈ້ງເຕືອນມີກົດລະບຽບການແຈ້ງເຕືອນ, ແລະພວກມັນມີສາມສະຖານະ:

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

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

ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມຂອງການໂຕ້ຕອບ Prometheus, ເບິ່ງ ໃນການບັນຍາຍຂອງ Slurm ກ່ຽວກັບການຕິດຕາມກຸ່ມ Kubernetes.

ການປະສົມປະສານກັບ Grafana

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

ການຕັ້ງຄ່າການເຊື່ອມໂຍງຂອງ Prometheus ແລະ Grafana ແມ່ນບໍ່ຍາກເລີຍ; ຄໍາແນະນໍາສາມາດພົບໄດ້ໃນເອກະສານ: GRAFANA ສະຫນັບສະຫນູນສໍາລັບ PROMETHEUS, ດີ, ຂ້າພະເຈົ້າຈະສໍາເລັດດ້ວຍນີ້.

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

ຜູ້ຂຽນ: Marcel Ibraev, ຜູ້ບໍລິຫານ Kubernetes ທີ່ໄດ້ຮັບການຮັບຮອງ, ວິສະວະກອນປະຕິບັດຢູ່ໃນບໍລິສັດ ພາກໃຕ້, ລໍາໂພງແລະຜູ້ພັດທະນາຫຼັກສູດ Slurm.

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