ການວິເຄາະ TSDB ໃນ Prometheus 2

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

ປະລິມານການເຮັດວຽກຂອງ Prometheus ສະເລ່ຍ

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

ໂຫຼດການທົດສອບ

ໃນລະຫວ່າງການທົດສອບ, ຂ້າພະເຈົ້າໄດ້ສຸມໃສ່ຄວາມສາມາດໃນການສະສົມຂໍ້ມູນ. ຂ້ອຍໄດ້ນຳໃຊ້ Prometheus 2.3.2 ທີ່ລວບລວມດ້ວຍ Go 1.10.1 (ເປັນສ່ວນຫນຶ່ງຂອງ PMM 1.14) ໃນການບໍລິການ Linode ໂດຍໃຊ້ສະຄຣິບນີ້: StackScript. ສໍາລັບການຜະລິດການໂຫຼດທີ່ແທ້ຈິງທີ່ສຸດ, ການນໍາໃຊ້ນີ້ StackScript ຂ້າພະເຈົ້າໄດ້ເປີດຕົວຫຼາຍຂໍ້ MySQL ດ້ວຍການໂຫຼດທີ່ແທ້ຈິງ (Sysbench TPC-C Test), ແຕ່ລະອັນທີ່ເຮັດຕາມ 10 Linux / MySQL nodes.
ການທົດສອບທັງຫມົດຕໍ່ໄປນີ້ໄດ້ຖືກປະຕິບັດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງ Linode ທີ່ມີແປດແກນ virtual ແລະ 32 GB ຂອງຫນ່ວຍຄວາມຈໍາ, ແລ່ນ 20 ໂຫຼດ simulations ຕິດຕາມກວດກາສອງຮ້ອຍຕົວຢ່າງ MySQL. ຫຼື, ໃນຄໍາສັບ Prometheus, 800 ເປົ້າຫມາຍ, 440 scrapes ຕໍ່ວິນາທີ, 380 ພັນບັນທຶກຕໍ່ວິນາທີ, ແລະ 1,7 ລ້ານໄລຍະການເຄື່ອນໄຫວ.

ການ​ອອກ​ແບບ

ວິທີການປົກກະຕິຂອງຖານຂໍ້ມູນແບບດັ້ງເດີມ, ລວມທັງການນໍາໃຊ້ໂດຍ Prometheus 1.x, ແມ່ນເພື່ອ ຈຳກັດຄວາມຈຳ. ຖ້າມັນບໍ່ພຽງພໍທີ່ຈະຈັດການກັບການໂຫຼດ, ທ່ານຈະມີປະສົບການ latencies ສູງແລະການຮ້ອງຂໍບາງຢ່າງຈະລົ້ມເຫລວ. ການນຳໃຊ້ໜ່ວຍຄວາມຈຳໃນ Prometheus 2 ແມ່ນສາມາດກຳນົດຄ່າໄດ້ຜ່ານປຸ່ມ storage.tsdb.min-block-duration, ເຊິ່ງກໍານົດໄລຍະເວລາການບັນທຶກຈະຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາກ່ອນທີ່ຈະ flushing ກັບແຜ່ນ (ຄ່າເລີ່ມຕົ້ນແມ່ນ 2 ຊົ່ວໂມງ). ຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ຕ້ອງການຈະຂຶ້ນກັບຈໍານວນຊຸດເວລາ, ປ້າຍກໍາກັບ, ແລະການຂູດທີ່ເພີ່ມໃສ່ນ້ໍາທີ່ເຂົ້າມາສຸດທິ. ໃນແງ່ຂອງພື້ນທີ່ດິດ, Prometheus ມີຈຸດປະສົງທີ່ຈະໃຊ້ 3 bytes ຕໍ່ບັນທຶກ (ຕົວຢ່າງ). ໃນທາງກົງກັນຂ້າມ, ຄວາມຕ້ອງການຄວາມຊົງຈໍາແມ່ນສູງກວ່າຫຼາຍ.

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

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກກາຟ, flushs to disk ເກີດຂຶ້ນທຸກໆສອງຊົ່ວໂມງ. ຖ້າທ່ານປ່ຽນພາລາມິເຕີໄລຍະເວລາ min-block ເປັນຫນຶ່ງຊົ່ວໂມງ, ຫຼັງຈາກນັ້ນ, ການຕັ້ງຄ່າເຫຼົ່ານີ້ຈະເກີດຂຶ້ນທຸກໆຊົ່ວໂມງ, ເລີ່ມຕົ້ນຫຼັງຈາກເຄິ່ງຊົ່ວໂມງ.
ຖ້າທ່ານຕ້ອງການໃຊ້ນີ້ແລະກາຟອື່ນໆໃນການຕິດຕັ້ງ Prometheus ຂອງທ່ານ, ທ່ານສາມາດນໍາໃຊ້ນີ້ ແຜງໜ້າປັດ. ມັນຖືກອອກແບບສໍາລັບ PMM ແຕ່, ມີການດັດແກ້ເລັກນ້ອຍ, ເຫມາະສົມກັບການຕິດຕັ້ງ Prometheus.
ພວກເຮົາມີບລັອກທີ່ມີການເຄື່ອນໄຫວທີ່ເອີ້ນວ່າ head block ເຊິ່ງຖືກເກັບໄວ້ໃນຄວາມຊົງຈໍາ; ບລັອກທີ່ມີຂໍ້ມູນເກົ່າແມ່ນມີຢູ່ຜ່ານ mmap(). ນີ້ກໍາຈັດຄວາມຈໍາເປັນໃນການຕັ້ງຄ່າ cache ແຍກຕ່າງຫາກ, ແຕ່ຍັງຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງປ່ອຍໃຫ້ພື້ນທີ່ພຽງພໍສໍາລັບ cache ຂອງລະບົບປະຕິບັດການຖ້າທ່ານຕ້ອງການສອບຖາມຂໍ້ມູນເກົ່າກວ່າສິ່ງທີ່ head block ສາມາດຮອງຮັບ.
ນີ້ຍັງຫມາຍຄວາມວ່າການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ virtual ຂອງ Prometheus ຈະເບິ່ງຂ້ອນຂ້າງສູງ, ເຊິ່ງບໍ່ແມ່ນສິ່ງທີ່ຕ້ອງກັງວົນ.

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

ການບີບອັດ

Prometheus TSDB ຖືກອອກແບບມາຄືກັບຮ້ານ LSM (Log Structured Merge): ບລັອກຫົວຖືກຖອກລົງເປັນໄລຍະໆໃສ່ແຜ່ນ, ໃນຂະນະທີ່ກົນໄກການບີບອັດຈະລວມຕົວບລັອກຫຼາຍອັນເຂົ້າກັນເພື່ອຫຼີກເວັ້ນການສະແກນຫຼາຍບລັອກໃນລະຫວ່າງການສອບຖາມ. ທີ່ນີ້ທ່ານສາມາດເບິ່ງຈໍານວນຂອງຕັນທີ່ຂ້າພະເຈົ້າສັງເກດເຫັນໃນລະບົບການທົດສອບຫຼັງຈາກມື້ຂອງການໂຫຼດ.

ຖ້າທ່ານຕ້ອງການຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຮ້ານ, ທ່ານສາມາດກວດເບິ່ງໄຟລ໌ meta.json, ເຊິ່ງມີຂໍ້ມູນກ່ຽວກັບບລັອກທີ່ມີຢູ່ແລະວິທີການທີ່ພວກມັນເປັນ.

{
       "ulid": "01CPZDPD1D9R019JS87TPV5MPE",
       "minTime": 1536472800000,
       "maxTime": 1536494400000,
       "stats": {
               "numSamples": 8292128378,
               "numSeries": 1673622,
               "numChunks": 69528220
       },
       "compaction": {
               "level": 2,
               "sources": [
                       "01CPYRY9MS465Y5ETM3SXFBV7X",
                       "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                       "01CPZ6NR4Q3PDP3E57HEH760XS"
               ],
               "parents": [
                       {
                               "ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
                               "minTime": 1536472800000,
                               "maxTime": 1536480000000
                       },
                       {
                               "ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                               "minTime": 1536480000000,
                               "maxTime": 1536487200000
                       },
                       {
                               "ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
                               "minTime": 1536487200000,
                               "maxTime": 1536494400000
                       }
               ]
       },
       "version": 1
}

ການບີບອັດໃນ Prometheus ແມ່ນຜູກມັດກັບເວລາທີ່ຫົວຕັນຖືກ flushed ກັບແຜ່ນ. ໃນຈຸດນີ້, ການປະຕິບັດງານດັ່ງກ່າວອາດຈະຖືກປະຕິບັດ.

ປະກົດວ່າການບີບອັດບໍ່ຈໍາກັດໃນທາງໃດກໍ່ຕາມ ແລະສາມາດເຮັດໃຫ້ເກີດການແຕກ I/O ຂອງແຜ່ນຂະຫນາດໃຫຍ່ໃນລະຫວ່າງການປະຕິບັດ.

ການໂຫຼດ CPU ເພີ່ມຂຶ້ນ

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

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

ການຟື້ນຟູຫຼັງຈາກຄວາມລົ້ມເຫຼວ

ການຟື້ນຕົວຈາກຄວາມລົ້ມເຫລວຕ້ອງໃຊ້ເວລາ, ແລະດ້ວຍເຫດຜົນທີ່ດີ. ສໍາລັບກະແສທີ່ເຂົ້າມາຂອງຫນຶ່ງລ້ານບັນທຶກຕໍ່ວິນາທີ, ຂ້ອຍຕ້ອງລໍຖ້າປະມານ 25 ນາທີໃນຂະນະທີ່ການຟື້ນຕົວໄດ້ຖືກປະຕິບັດໂດຍຄໍານຶງເຖິງ SSD drive.

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."

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

ອຸ່ນ​ເຄື່ອງ

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

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

ການໂຫຼດ CPU ເພີ່ມຂຶ້ນ

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

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

ນອກນັ້ນທ່ານຍັງສາມາດສັງເກດເຫັນວ່າຜູ້ສົ່ງອອກ Prometheus ປິດລົງເປັນເວລາຫນຶ່ງວິນາທີ.

ພວກເຮົາສາມາດສັງເກດເຫັນຄວາມກ່ຽວຂ້ອງກັບການເກັບຂີ້ເຫຍື້ອ (GC).

ສະຫລຸບ

TSDB ໃນ Prometheus 2 ແມ່ນໄວ, ສາມາດຈັດການກັບຊຸດເວລາຫຼາຍລ້ານແລະໃນເວລາດຽວກັນຫຼາຍພັນບັນທຶກຕໍ່ວິນາທີໂດຍໃຊ້ຮາດແວທີ່ຂ້ອນຂ້າງປານກາງ. ການນຳໃຊ້ CPU ແລະ Disk I/O ແມ່ນມີຄວາມປະທັບໃຈເຊັ່ນກັນ. ຕົວຢ່າງຂອງຂ້ອຍສະແດງໃຫ້ເຫັນເຖິງ 200 metrics ຕໍ່ວິນາທີຕໍ່ຫຼັກທີ່ໃຊ້.

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

ແນ່ນອນ, ຍັງມີຫຼາຍວຽກທີ່ຕ້ອງເຮັດເພື່ອຮັກສາ CPU ແລະ I/O spikes ຂອງແຜ່ນ, ແລະນີ້ບໍ່ແປກໃຈທີ່ຈະພິຈາລະນາວິທີການຫນຸ່ມ TSDB Prometheus 2 ປຽບທຽບກັບ InnoDB, TokuDB, RocksDB, WiredTiger, ແຕ່ພວກເຂົາທັງຫມົດມີຄວາມຄ້າຍຄືກັນ. ບັນຫາໃນຕົ້ນໆຂອງວົງຈອນຊີວິດຂອງພວກເຂົາ.

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