ບູລິມະສິດ pod ໃນ Kubernetes ເຮັດໃຫ້ເກີດການຢຸດເຮັດວຽກຢູ່ Grafana Labs ແນວໃດ

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

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

ປະວັດສາດ

ບໍລິການ Grafana Cloud Hosted Prometheus ແມ່ນອີງໃສ່ Cortex — ໂຄງການ CNCF ເພື່ອສ້າງບໍລິການ Prometheus ທີ່ສາມາດປັບຂະ ໜາດ ໄດ້ຕາມແນວນອນ, ມີໃຫ້ເຊົ່າຫຼາຍ. ສະຖາປັດຕະຍະກໍາ Cortex ປະກອບດ້ວຍຊຸດຂອງ microservices ສ່ວນບຸກຄົນ, ແຕ່ລະຄົນປະຕິບັດຫນ້າທີ່ຂອງຕົນເອງ: ການຈໍາລອງ, ການເກັບຮັກສາ, ການສອບຖາມ, ແລະອື່ນໆ. Cortex ແມ່ນຢູ່ພາຍໃຕ້ການພັດທະນາຢ່າງຫ້າວຫັນແລະກໍາລັງເພີ່ມຄຸນສົມບັດໃຫມ່ແລະປັບປຸງການປະຕິບັດຢ່າງຕໍ່ເນື່ອງ. ພວກເຮົານຳໃຊ້ Cortex ໃໝ່ໆອອກສູ່ກຸ່ມເປັນປະຈຳ ເພື່ອໃຫ້ລູກຄ້າສາມາດນຳໃຊ້ປະໂຫຍດຈາກຄຸນສົມບັດເຫຼົ່ານີ້ໄດ້ - ໂຊກດີ, Cortex ສາມາດອັບເດດໄດ້ໂດຍບໍ່ຕ້ອງເສຍເວລາ.

ສໍາລັບການອັບເດດທີ່ບໍ່ມີຮອຍຕໍ່, ການບໍລິການ Ingester Cortex ຕ້ອງການການຈໍາລອງ Ingester ເພີ່ມເຕີມໃນລະຫວ່າງຂະບວນການປັບປຸງ. (ຫມາຍ​ເຫດ​. ແປ.: ອິນສະເຕີ - ອົງປະກອບພື້ນຖານຂອງ Cortex. ວຽກງານຂອງມັນແມ່ນການເກັບກໍາຕົວຢ່າງຄົງທີ່, ຈັດກຸ່ມເຂົ້າໄປໃນຕ່ອນ Prometheus ແລະເກັບຮັກສາໄວ້ໃນຖານຂໍ້ມູນເຊັ່ນ DynamoDB, BigTable ຫຼື Cassandra.) ນີ້ອະນຸຍາດໃຫ້ Ingesters ເກົ່າສາມາດສົ່ງຕໍ່ຂໍ້ມູນປະຈຸບັນໄປຫາ Ingesters ໃຫມ່. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ Ingesters ແມ່ນຄວາມຕ້ອງການຊັບພະຍາກອນ. ເພື່ອໃຫ້ພວກມັນເຮັດວຽກ, ທ່ານຈໍາເປັນຕ້ອງມີ 4 cores ແລະ 15 GB ຂອງຫນ່ວຍຄວາມຈໍາຕໍ່ຝັກ, i.e. 25% ຂອງພະລັງງານປະມວນຜົນແລະຄວາມຊົງຈໍາຂອງເຄື່ອງຈັກພື້ນຖານໃນກໍລະນີຂອງກຸ່ມ Kubernetes ຂອງພວກເຮົາ. ໂດຍທົ່ວໄປແລ້ວ, ພວກເຮົາປົກກະຕິແລ້ວມີຊັບພະຍາກອນທີ່ບໍ່ໄດ້ໃຊ້ຫຼາຍຢູ່ໃນກຸ່ມຫຼາຍກ່ວາ 4 cores ແລະ 15 GB ຂອງຫນ່ວຍຄວາມຈໍາ, ດັ່ງນັ້ນພວກເຮົາສາມາດຫມຸນເພີ່ມ ingesters ເຫຼົ່ານີ້ໄດ້ຢ່າງງ່າຍດາຍໃນລະຫວ່າງການຍົກລະດັບ.

ຢ່າງໃດກໍ່ຕາມ, ມັນມັກຈະເກີດຂື້ນວ່າໃນລະຫວ່າງການປະຕິບັດງານປົກກະຕິບໍ່ມີເຄື່ອງຈັກໃດມີ 25% ຂອງຊັບພະຍາກອນທີ່ບໍ່ໄດ້ໃຊ້. ແມ່ນແລ້ວ, ພວກເຮົາບໍ່ພະຍາຍາມ: CPU ແລະຫນ່ວຍຄວາມຈໍາຈະເປັນປະໂຫຍດສໍາລັບຂະບວນການອື່ນໆ. ເພື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາຕັດສິນໃຈໃຊ້ Kubernetes Pod ບູລິມະສິດ. ແນວຄວາມຄິດແມ່ນໃຫ້ Ingesters ບູລິມະສິດສູງກວ່າການບໍລິການຈຸນລະພາກ (ລັດ) ອື່ນໆ. ເມື່ອພວກເຮົາຕ້ອງການໃຊ້ Ingester ເພີ່ມເຕີມ (N+1), ພວກເຮົາປ່ຽນຝັກອື່ນທີ່ມີຂະຫນາດນ້ອຍກວ່າຊົ່ວຄາວ. ຝັກເຫຼົ່ານີ້ຖືກໂອນໄປຫາຊັບພະຍາກອນທີ່ບໍ່ເສຍຄ່າໃນເຄື່ອງອື່ນໆ, ເຊິ່ງເຮັດໃຫ້ "ຂຸມ" ຂະຫນາດໃຫຍ່ພຽງພໍທີ່ຈະດໍາເນີນການ Ingester ເພີ່ມເຕີມ.

ໃນວັນພະຫັດ, ວັນທີ 18 ກໍລະກົດ, ພວກເຮົາໄດ້ເຜີຍແຜ່ສີ່ລະດັບບູລິມະສິດໃໝ່ໃຫ້ແກ່ກຸ່ມຂອງພວກເຮົາ: ທີ່ ສຳ ຄັນ, ສູງ, ໂດຍສະເລ່ຍ и ຕ່ໍາ. ພວກເຂົາເຈົ້າໄດ້ຖືກທົດສອບຢູ່ໃນກຸ່ມພາຍໃນທີ່ບໍ່ມີການເຂົ້າຊົມລູກຄ້າປະມານຫນຶ່ງອາທິດ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຝັກທີ່ບໍ່ມີບຸລິມະສິດທີ່ລະບຸໄດ້ຮັບ ໂດຍສະເລ່ຍ ບູລິມະສິດ, ຫ້ອງຮຽນໄດ້ຖືກກໍານົດສໍາລັບ Ingesters ກັບ ສູງ ບູລິມະສິດ. ສຳຄັນ ໄດ້ຖືກສະຫງວນໄວ້ສໍາລັບການຕິດຕາມກວດກາ (Prometheus, Alertmanager, node-exporter, kube-state-metrics, ແລະອື່ນໆ). config ຂອງພວກເຮົາແມ່ນເປີດ, ແລະທ່ານສາມາດເບິ່ງ PR ໄດ້ ທີ່ນີ້.

ອຸປະຕິເຫດ

ໃນວັນສຸກ, ກໍລະກົດ 19, ຫນຶ່ງໃນວິສະວະກອນໄດ້ເປີດຕົວກຸ່ມ Cortex ທີ່ອຸທິດຕົນໃຫມ່ສໍາລັບລູກຄ້າຂະຫນາດໃຫຍ່. ການຕັ້ງຄ່າສຳລັບກຸ່ມນີ້ບໍ່ໄດ້ລວມເອົາບຸລິມະສິດຂອງຝັກໃໝ່, ສະນັ້ນ ຝັກໃໝ່ທັງໝົດໄດ້ຖືກມອບໝາຍບຸລິມະສິດເລີ່ມຕົ້ນ - ໂດຍສະເລ່ຍ.

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

ReplicaSet ສໍາລັບ Ingester ທີ່ຖືກຂັບໄລ່ໃນກຸ່ມການຜະລິດໄດ້ກວດພົບຝັກທີ່ຖືກຂັບໄລ່ແລະສ້າງໃຫມ່ເພື່ອຮັກສາຈໍານວນທີ່ກໍານົດໄວ້ຂອງສໍາເນົາ. ພອດໃໝ່ຖືກມອບໝາຍຕາມຄ່າເລີ່ມຕົ້ນ ໂດຍສະເລ່ຍ ບູລິມະສິດ, ແລະອີກອັນຫນຶ່ງ "ເກົ່າ" Ingester ໃນການຜະລິດໄດ້ສູນເສຍຊັບພະຍາກອນຂອງຕົນ. ຜົນໄດ້ຮັບແມ່ນ ຂະ​ບວນ​ການ avalanche​, ເຊິ່ງນໍາໄປສູ່ການຍົກຍ້າຍຂອງຝັກທັງຫມົດຈາກ Ingester ສໍາລັບກຸ່ມການຜະລິດ Cortex.

Ingesters ແມ່ນ stateful ແລະເກັບຮັກສາຂໍ້ມູນສໍາລັບ 12 ຊົ່ວໂມງທີ່ຜ່ານມາ. ນີ້ຊ່ວຍໃຫ້ພວກເຮົາສາມາດບີບອັດພວກມັນໄດ້ມີປະສິດທິພາບຫຼາຍຂຶ້ນກ່ອນທີ່ຈະຂຽນພວກມັນໄວ້ໃນການເກັບຮັກສາໃນໄລຍະຍາວ. ເພື່ອບັນລຸສິ່ງດັ່ງກ່າວ, Cortex shards ຂໍ້ມູນໃນທົ່ວ series ໂດຍໃຊ້ Distributed Hash Table (DHT) ແລະ replicates ແຕ່ລະຊຸດໃນທົ່ວສາມ Ingesters ໂດຍໃຊ້ Dynamo-style qurum ສອດຄ່ອງ. Cortex ບໍ່ຂຽນຂໍ້ມູນໃສ່ Ingesters ທີ່ຖືກປິດໃຊ້ງານ. ດັ່ງນັ້ນ, ເມື່ອຈໍານວນ Ingesters ຈໍານວນຫຼວງຫຼາຍອອກຈາກ DHT, Cortex ບໍ່ສາມາດສະຫນອງການຈໍາລອງຢ່າງພຽງພໍຂອງລາຍການ, ແລະພວກມັນລົ້ມລົງ.

ການກວດຫາ ແລະແກ້ໄຂ

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

ຫຼັງຈາກນັ້ນອີກຫ້ານາທີ, Ingesters ເກົ່າໄດ້ຂຽນຂໍ້ມູນຂອງພວກເຂົາຢ່າງສໍາເລັດຜົນ, ຂໍ້ມູນໃຫມ່ກໍ່ເລີ່ມຂຶ້ນ, ແລະກຸ່ມ Cortex ໄດ້ກາຍເປັນອີກເທື່ອຫນຶ່ງ.

ອີກ 10 ນາທີໄດ້ໃຊ້ເວລາໃນການວິນິດໄສ ແລະແກ້ໄຂຂໍ້ຜິດພາດນອກໜ່ວຍຄວາມຈຳ (OOM) ຈາກການພິສູດຢືນຢັນຕົວແທນທີ່ກົງກັນຂ້າມຢູ່ຕໍ່ໜ້າ Cortex. ຄວາມຜິດພາດ OOM ແມ່ນເກີດມາຈາກ QPS ເພີ່ມຂຶ້ນສິບເທົ່າ (ພວກເຮົາເຊື່ອວ່າຍ້ອນການຮ້ອງຂໍທີ່ຮຸກຮານຫຼາຍເກີນໄປຈາກເຄື່ອງແມ່ຂ່າຍຂອງ Prometheus ຂອງລູກຄ້າ).

ຜົນກະທົບ

ເວລາຢຸດທັງໝົດແມ່ນ 26 ນາທີ. ບໍ່ມີຂໍ້ມູນສູນເສຍ. Ingesters ໄດ້ສຳເລັດການໂຫຼດຂໍ້ມູນໃນໜ່ວຍຄວາມຈຳທັງໝົດເຂົ້າໄປໃນບ່ອນເກັບຂໍ້ມູນໄລຍະຍາວ. ໃນລະຫວ່າງການປິດເຄື່ອງ, ເຊີບເວີ Prometheus ຂອງລູກຄ້າໄດ້ buffed ຖືກລົບ (ໄລຍະໄກ) ການ​ບັນ​ທຶກ​ການ​ນໍາ​ໃຊ້​ API remote_write ໃໝ່ ອີງໃສ່ WAL (ຂຽນໂດຍ Callum Styan ຈາກ Grafana Labs) ແລະເຮັດຊ້ໍາການຂຽນທີ່ລົ້ມເຫລວຫຼັງຈາກອຸປະຕິເຫດ.

ການດໍາເນີນງານການຂຽນກຸ່ມການຜະລິດ

ການຄົ້ນພົບ

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮຽນຮູ້ຈາກເຫດການນີ້ແລະດໍາເນີນຂັ້ນຕອນທີ່ຈໍາເປັນເພື່ອຫຼີກເວັ້ນການເກີດຂຶ້ນອີກ.

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

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

ສຸດທ້າຍ, ພວກເຮົາຈະປັບຂະໜາດອັດຕະໂນມັດຂອງ proxy reverse authentication ເພື່ອປ້ອງກັນການ overload OOM ທີ່ພວກເຮົາເຫັນ, ແລະຈະກວດສອບການຕັ້ງຄ່າເລີ່ມຕົ້ນ Prometheus ທີ່ກ່ຽວຂ້ອງກັບ fallback ແລະ scaling ເພື່ອປ້ອງກັນບັນຫາທີ່ຄ້າຍຄືກັນໃນອະນາຄົດ.

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

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການ​ຂະ​ຫຍາຍ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ການ​ຄຸ້ມ​ຄອງ​ຊັບ​ພະ​ຍາ​ກອນ​ໃນ Kubernetes (ພາບ​ລວມ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)"
• «Kubernetes ຜະຈົນໄພ Dailymotion: ການສ້າງໂຄງສ້າງພື້ນຖານໃນເມຄ + ໃນສະຖານທີ່"
• «ການປ່ຽນແປງ Tinder ໄປ Kubernetes"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 10: Reddit".

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