ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ຈາກ Loki​

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

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

Loki ແມ່ນຫຍັງ

Grafana Loki ແມ່ນຊຸດຂອງອົງປະກອບສໍາລັບລະບົບທີ່ສົມບູນສໍາລັບການເຮັດວຽກກັບໄມ້ທ່ອນ. ບໍ່ເຫມືອນກັບລະບົບທີ່ຄ້າຍຄືກັນອື່ນໆ, Loki ແມ່ນອີງໃສ່ແນວຄວາມຄິດຂອງ indexing ພຽງແຕ່ log metadata - ປ້າຍຊື່ (ຄືກັນກັບໃນ Prometheus), ແລະການບີບອັດບັນທຶກດ້ວຍຕົນເອງເຂົ້າໄປໃນ chunks ແຍກຕ່າງຫາກ.

ຫນ້າທໍາອິດ, GitHub

ກ່ອນທີ່ພວກເຮົາຈະເຂົ້າໄປໃນສິ່ງທີ່ທ່ານສາມາດເຮັດໄດ້ກັບ Loki, ຂ້ອຍຕ້ອງການໃຫ້ຄວາມກະຈ່າງແຈ້ງກ່ຽວກັບສິ່ງທີ່ພວກເຮົາຫມາຍຄວາມວ່າ "ແນວຄວາມຄິດຂອງການດັດສະນີພຽງແຕ່ metadata." ໃຫ້ປຽບທຽບວິທີການ Loki ແລະວິທີການດັດສະນີໃນການແກ້ໄຂແບບດັ້ງເດີມເຊັ່ນ Elasticsearch, ໂດຍໃຊ້ຕົວຢ່າງຂອງເສັ້ນຈາກບັນທຶກ nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

ການຊື້ຂາຍນີ້ລະຫວ່າງດັດຊະນີຂະຫນາດໃຫຍ່, ໄວແລະຂະຫນາດນ້ອຍ, ຂະຫນານ brute-force ດັດຊະນີອະນຸຍາດໃຫ້ Loki ຄວບຄຸມຄ່າໃຊ້ຈ່າຍຂອງລະບົບ. ມັນ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປັບ​ຕັ້ງ​ແລະ​ຂະ​ຫຍາຍ​ຕົວ​ຕາມ​ຄວາມ​ຕ້ອງ​ການ​.

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

ຊອກຫາດ້ວຍບັນທຶກ

ທ່ານສາມາດຄົ້ນຫາບັນທຶກໃນການໂຕ້ຕອບ Grafana ພິເສດ - Explorer. ການສອບຖາມໃຊ້ພາສາ LogQL, ເຊິ່ງຄ້າຍຄືກັນກັບ PromQL ທີ່ໃຊ້ໃນ Prometheus. ໃນຫຼັກການ, ມັນສາມາດຖືກຄິດວ່າເປັນ grep ແຈກຢາຍ.

ການໂຕ້ຕອບການຊອກຫາເບິ່ງຄືວ່ານີ້:

ການຮ້ອງຂໍຕົວຂອງມັນເອງປະກອບດ້ວຍສອງພາກສ່ວນ: ຕົວເລືອກແລະຕົວກອງ. Selector ແມ່ນການຄົ້ນຫາໂດຍໃຊ້ metadata ທີ່ຖືກດັດສະນີ (ປ້າຍຊື່) ທີ່ຖືກມອບຫມາຍໃຫ້ບັນທຶກ, ແລະການກັ່ນຕອງແມ່ນສະຕຣິງຄົ້ນຫາຫຼື regexp ທີ່ກັ່ນຕອງບັນທຶກທີ່ກໍານົດໂດຍຕົວເລືອກ. ໃນຕົວຢ່າງທີ່ໄດ້ຮັບ: ໃນວົງເລັບ curly ມີຕົວເລືອກ, ທຸກສິ່ງທຸກຢ່າງຫຼັງຈາກນັ້ນແມ່ນຕົວກອງ.

{image_name="nginx.promtail.test"} |= "index"

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

ໂຕເລືອກແມ່ນຄ່າຫຼັກໃນວົງປີກກາ. ທ່ານສາມາດລວມຕົວເລືອກແລະລະບຸເງື່ອນໄຂການຊອກຫາທີ່ແຕກຕ່າງກັນໂດຍໃຊ້ຕົວປະຕິບັດການ =, != ຫຼືການສະແດງອອກປົກກະຕິ:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

ຕົວກອງແມ່ນຂໍ້ຄວາມ ຫຼື regexp ທີ່ຈະກັ່ນຕອງຂໍ້ມູນທັງໝົດທີ່ໄດ້ຮັບໂດຍຕົວເລືອກ.

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

ລາຍລະອຽດເຕັມຂອງຄວາມສາມາດສາມາດພົບໄດ້ໃນເອກະສານ LogQL.

ການວິເຄາະບັນທຶກ

ມີ​ຫຼາຍ​ວິ​ທີ​ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​:

• ການນໍາໃຊ້ Promtail, ອົງປະກອບມາດຕະຖານຂອງ stack ສໍາລັບການເກັບກໍາຂໍ້ມູນບັນທຶກ.
• ໂດຍກົງຈາກຖັງ docker ໂດຍໃຊ້ ໄດເວີບັນທຶກ Loki Docker.
• ໃຊ້ Fluentd ຫຼື Fluent Bit, ເຊິ່ງສາມາດສົ່ງຂໍ້ມູນໄປຫາ Loki. ບໍ່ເຫມືອນກັບ Promtail, ພວກເຂົາມີຕົວແຍກວິເຄາະທີ່ກຽມພ້ອມສໍາລັບເກືອບທຸກປະເພດຂອງບັນທຶກແລະຍັງສາມາດຈັດການບັນທຶກຫຼາຍແຖວ.

ປົກກະຕິແລ້ວ Promtail ແມ່ນໃຊ້ເພື່ອວິເຄາະ. ມັນເຮັດສາມຢ່າງ:

• ຊອກຫາແຫຼ່ງຂໍ້ມູນ.
• ຕິດປ້າຍກຳກັບໃສ່ພວກມັນ.
• ສົ່ງຂໍ້ມູນໄປຫາ Loki.

ໃນປັດຈຸບັນ Promtail ສາມາດອ່ານບັນທຶກຈາກໄຟລ໌ທ້ອງຖິ່ນແລະຈາກວາລະສານ systemd. ມັນຕ້ອງຖືກຕິດຕັ້ງຢູ່ໃນແຕ່ລະເຄື່ອງຈັກທີ່ເກັບກໍາຂໍ້ມູນບັນທຶກ.

ມີການເຊື່ອມໂຍງກັບ Kubernetes: Promtail ໂດຍອັດຕະໂນມັດ, ຜ່ານ Kubernetes REST API, ຮັບຮູ້ສະຖານະຂອງກຸ່ມ ແລະເກັບກໍາຂໍ້ມູນບັນທຶກຈາກ node, ບໍລິການ ຫຼື pod, ທັນທີທີ່ປະກາດປ້າຍຊື່ໂດຍອີງໃສ່ metadata ຈາກ Kubernetes (ຊື່ pod, ຊື່ໄຟລ໌, ແລະອື່ນໆ) .

ທ່ານຍັງສາມາດວາງປ້າຍໂດຍອີງໃສ່ຂໍ້ມູນຈາກບັນທຶກໂດຍໃຊ້ Pipeline. Pipeline Promtail ສາມາດປະກອບດ້ວຍສີ່ປະເພດຂອງຂັ້ນຕອນ. ລາຍລະອຽດເພີ່ມເຕີມໃນ ເອກະສານທາງການ, ຂ້ອຍຈະສັງເກດເຫັນບາງ nuances ທັນທີ.

1. ຂັ້ນຕອນການວິເຄາະ. ນີ້ແມ່ນຂັ້ນຕອນ RegEx ແລະ JSON. ໃນຂັ້ນຕອນນີ້, ພວກເຮົາສະກັດຂໍ້ມູນຈາກບັນທຶກເຂົ້າໄປໃນອັນທີ່ເອີ້ນວ່າແຜນທີ່ສະກັດ. ພວກເຮົາສາມາດສະກັດຈາກ JSON ໂດຍພຽງແຕ່ຄັດລອກທົ່ງນາທີ່ພວກເຮົາຕ້ອງການເຂົ້າໄປໃນແຜນທີ່ທີ່ສະກັດອອກ, ຫຼືໂດຍຜ່ານການສະແດງອອກປົກກະຕິ (RegEx), ບ່ອນທີ່ກຸ່ມທີ່ມີຊື່ຖືກ "ເຮັດແຜນທີ່" ເຂົ້າໄປໃນແຜນທີ່ສະກັດ. ແຜນ​ທີ່​ທີ່​ສະ​ກັດ​ອອກ​ແມ່ນ​ການ​ເກັບ​ຮັກ​ສາ​ທີ່​ມີ​ຄຸນ​ຄ່າ​ທີ່​ສໍາ​ຄັນ​, ທີ່​ສໍາ​ຄັນ​ແມ່ນ​ຊື່​ຂອງ​ພາກ​ສະ​ຫນາມ​, ແລະ​ມູນ​ຄ່າ​ແມ່ນ​ຄ່າ​ຂອງ​ຕົນ​ຈາກ​ບັນ​ທຶກ​.
2. ຂັ້ນຕອນການຫັນປ່ຽນ. ຂັ້ນຕອນນີ້ມີສອງທາງເລືອກ: ການຫັນປ່ຽນ, ບ່ອນທີ່ພວກເຮົາກໍານົດກົດລະບຽບການຫັນປ່ຽນ, ແລະແຫຼ່ງ - ແຫຼ່ງຂໍ້ມູນສໍາລັບການຫັນປ່ຽນຈາກແຜນທີ່ສະກັດ. ຖ້າບໍ່ມີພາກສະຫນາມດັ່ງກ່າວໃນແຜນທີ່ສະກັດ, ມັນຈະຖືກສ້າງຂຶ້ນ. ວິທີນີ້ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງປ້າຍທີ່ບໍ່ອີງໃສ່ແຜນທີ່ທີ່ສະກັດອອກ. ໃນ​ຂັ້ນ​ຕອນ​ນີ້​ພວກ​ເຮົາ​ສາ​ມາດ​ຈັດ​ການ​ຂໍ້​ມູນ​ໃນ​ແຜນ​ທີ່​ສະ​ກັດ​ໂດຍ​ນໍາ​ໃຊ້​ທີ່​ມີ​ອໍາ​ນາດ​ພໍ​ສົມ​ຄວນ​ ແມ່ແບບ Golang. ນອກຈາກນັ້ນ, ພວກເຮົາຕ້ອງຈື່ໄວ້ວ່າແຜນທີ່ທີ່ສະກັດອອກມາໄດ້ຖືກໂຫລດທັງຫມົດໃນລະຫວ່າງການວິເຄາະ, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້, ຕົວຢ່າງເຊັ່ນ, ເພື່ອກວດເບິ່ງຄ່າໃນມັນ: “{{ຖ້າ .tag}ຄ່າແທັກມີຢູ່{end}}”. ແມ່ແບບສະຫນັບສະຫນູນເງື່ອນໄຂ, loops, ແລະບາງຟັງຊັນ string ເຊັ່ນ Replace ແລະ Trim.
3. ຂັ້ນຕອນການປະຕິບັດ. ໃນຈຸດນີ້, ທ່ານສາມາດເຮັດບາງສິ່ງບາງຢ່າງທີ່ມີເນື້ອໃນທີ່ສະກັດອອກ:
   • ສ້າງປ້າຍຊື່ຈາກຂໍ້ມູນທີ່ສະກັດອອກ, ເຊິ່ງຈະຖືກດັດສະນີໂດຍ Loki.
   • ປ່ຽນ ຫຼືຕັ້ງເວລາເຫດການຈາກບັນທຶກ.
   • ປ່ຽນຂໍ້ມູນ (ຂໍ້ຄວາມບັນທຶກ) ທີ່ຈະໄປຫາ Loki.
   • ສ້າງເມຕຣິກ.
4. ຂັ້ນຕອນການກັ່ນຕອງ. ຂັ້ນຕອນການແຂ່ງຂັນ, ບ່ອນທີ່ພວກເຮົາສາມາດສົ່ງລາຍການທີ່ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງ /dev/null ຫຼືສົ່ງຕໍ່ໃຫ້ເຂົາເຈົ້າສໍາລັບການປຸງແຕ່ງຕໍ່ໄປ.

ການນໍາໃຊ້ຕົວຢ່າງຂອງການປຸງແຕ່ງບັນທຶກ nginx ປົກກະຕິ, ຂ້າພະເຈົ້າຈະສະແດງວິທີທີ່ທ່ານສາມາດວິເຄາະບັນທຶກໂດຍໃຊ້ Promtail.

ສໍາລັບການທົດສອບ, ໃຫ້ໃຊ້ເປັນ nginx-proxy ເປັນຮູບພາບ nginx ທີ່ຖືກດັດແປງ jwilder/nginx-proxy:alpine ແລະ daemon ຂະຫນາດນ້ອຍທີ່ສາມາດຖາມຕົວເອງຜ່ານ HTTP. daemon ມີຫຼາຍຈຸດສິ້ນສຸດ, ເຊິ່ງມັນສາມາດສະຫນອງການຕອບສະຫນອງຂອງຂະຫນາດທີ່ແຕກຕ່າງກັນ, ມີສະຖານະພາບ HTTP ທີ່ແຕກຕ່າງກັນແລະມີຄວາມລ່າຊ້າທີ່ແຕກຕ່າງກັນ.

ພວກເຮົາຈະເກັບບັນທຶກຈາກ docker containers, ເຊິ່ງສາມາດພົບໄດ້ຕາມເສັ້ນທາງ /var/lib/docker/containers/ / -json.log

ໃນ docker-compose.yml ພວກເຮົາ configure Promtail ແລະລະບຸເສັ້ນທາງໄປຫາ config:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

ເພີ່ມເສັ້ນທາງໄປຫາບັນທຶກໄປຫາ promtail.yml (ມີທາງເລືອກ "docker" ໃນ config, ເຊິ່ງເຮັດສິ່ງດຽວກັນໃນແຖວດຽວ, ແຕ່ມັນຈະບໍ່ຊັດເຈນ):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

ເມື່ອການຕັ້ງຄ່ານີ້ຖືກເປີດໃຊ້ງານ, ບັນທຶກຈາກກ່ອງບັນຈຸທັງໝົດຈະຖືກສົ່ງໄປຫາ Loki. ເພື່ອຫຼີກເວັ້ນການນີ້, ພວກເຮົາປ່ຽນການຕັ້ງຄ່າຂອງການທົດສອບ nginx ໃນ docker-compose.yml - ຕື່ມຂໍ້ມູນບັນທຶກການເຂົ້າສູ່ລະບົບ:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

ການແກ້ໄຂ promtail.yml ແລະການຕັ້ງຄ່າ Pipeline. ການປ້ອນຂໍ້ມູນປະກອບມີບັນທຶກຂອງປະເພດຕໍ່ໄປນີ້:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

ຂັ້ນຕອນຂອງທໍ່:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

ພວກເຮົາສະກັດເອົາ fields stream, attrs, attrs.tag (ຖ້າພວກມັນມີຢູ່) ຈາກ JSON ທີ່ເຂົ້າມາແລະໃຫ້ພວກເຂົາຢູ່ໃນແຜນທີ່ທີ່ສະກັດອອກ.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

ຖ້າພວກເຮົາຈັດການໃສ່ພາກສະຫນາມແທັກໃນແຜນທີ່ທີ່ສະກັດອອກ, ຫຼັງຈາກນັ້ນໂດຍໃຊ້ regexp ພວກເຮົາສະກັດຊື່ຂອງຮູບພາບແລະຖັງ.

 - labels:
     image_name:
     container_name:

ພວກເຮົາກໍານົດປ້າຍຊື່. ຖ້າພົບກະແຈ image_name ແລະ container_name ໃນຂໍ້ມູນທີ່ສະກັດອອກ, ຫຼັງຈາກນັ້ນ, ຄ່າຂອງພວກມັນຈະຖືກມອບໃຫ້ປ້າຍຊື່ທີ່ສອດຄ້ອງກັນ.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

ພວກເຮົາຍົກເລີກບັນທຶກທັງໝົດທີ່ບໍ່ໄດ້ຕິດຕັ້ງປ້າຍຊື່ image_name ແລະ container_name.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

ສຳລັບບັນທຶກທັງໝົດທີ່ມີຊື່ image_name ແມ່ນ nginx.promtail.test, ແຍກຂໍ້ມູນບັນທຶກຈາກບັນທຶກແຫຼ່ງທີ່ມາ ແລະໃສ່ໃນແຜນທີ່ທີ່ສະກັດດ້ວຍປຸ່ມແຖວ.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

ພວກເຮົາລຶບສາຍການປ້ອນຂໍ້ມູນດ້ວຍການສະແດງອອກເປັນປົກກະຕິແລະດຶງ nginx virtual host ແລະເສັ້ນບັນທຶກ nginx ອອກ.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

ວິເຄາະບັນທຶກ nginx ໂດຍໃຊ້ການສະແດງຜົນປົກກະຕິ.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

ມາວິເຄາະ request_url. ການນໍາໃຊ້ regexp ພວກເຮົາກໍານົດຈຸດປະສົງຂອງຄໍາຮ້ອງຂໍ: ເພື່ອຂໍ້ມູນສະຖິດ, ຮູບພາບ, API ແລະກໍານົດລະຫັດທີ່ສອດຄ້ອງກັນໃນແຜນທີ່ສະກັດ.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

ການນໍາໃຊ້ຕົວປະຕິບັດການເງື່ອນໄຂໃນ Template, ພວກເຮົາກວດເບິ່ງຊ່ອງຂໍ້ມູນທີ່ຕິດຕັ້ງຢູ່ໃນແຜນທີ່ທີ່ສະກັດອອກແລະກໍານົດຄ່າທີ່ຕ້ອງການສໍາລັບພາກສະຫນາມ request_type: photo, static, API. ມອບໝາຍອັນອື່ນຖ້າມັນລົ້ມເຫລວ. request_type ຕອນນີ້ມີປະເພດການຮ້ອງຂໍ.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

ພວກເຮົາຕັ້ງປ້າຍຊື່ api_request, virtual_host, request_type ແລະສະຖານະ (ສະຖານະ HTTP) ໂດຍອີງໃສ່ສິ່ງທີ່ພວກເຮົາຈັດການໃສ່ໃນແຜນທີ່ທີ່ສະກັດອອກ.

       - output:
           source: nginx_log_row

ປ່ຽນຜົນຜະລິດ. ໃນປັດຈຸບັນບັນທຶກ nginx ທີ່ຖືກອະນາໄມຈາກແຜນທີ່ທີ່ສະກັດອອກໄປຫາ Loki.

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

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

ການເບິ່ງເຫັນຂອງບັນທຶກ

Loki ສາມາດເຮັດຫນ້າທີ່ເປັນແຫລ່ງຂໍ້ມູນສໍາລັບ Grafana graphs ໂດຍໃຊ້ LogQL. ຄຸນ​ນະ​ສົມ​ບັດ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​:

• ອັດ​ຕາ - ຈໍາ​ນວນ​ຂອງ​ການ​ບັນ​ທຶກ​ຕໍ່​ວິ​ນາ​ທີ​;
• ນັບ​ເປັນ​ໄລ​ຍະ — ຈໍາ​ນວນ​ຂອງ​ການ​ບັນ​ທຶກ​ໃນ​ລະ​ດັບ​ທີ່​ກໍາ​ນົດ​ໄວ້​.

ນອກຈາກນີ້ຍັງມີຫນ້າທີ່ລວມ Sum, Avg ແລະອື່ນໆ. ທ່ານສາມາດສ້າງກາຟທີ່ຂ້ອນຂ້າງສັບສົນ, ຕົວຢ່າງເຊັ່ນກາຟຂອງຈໍານວນຂໍ້ຜິດພາດ HTTP:

ແຫຼ່ງຂໍ້ມູນມາດຕະຖານ Loki ແມ່ນຫຼຸດລົງບາງຢ່າງໃນການເຮັດວຽກເມື່ອທຽບກັບແຫຼ່ງຂໍ້ມູນ Prometheus (ຕົວຢ່າງ, ທ່ານບໍ່ສາມາດປ່ຽນຄວາມຫມາຍ), ແຕ່ Loki ສາມາດເຊື່ອມຕໍ່ເປັນແຫຼ່ງທີ່ມີປະເພດ Prometheus. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ແນ່​ໃຈວ່​າ​ວ່າ​ນີ້​ແມ່ນ​ພຶດ​ຕິ​ກໍາ​ທີ່​ບັນ​ທຶກ​ໄວ້​, ແຕ່​ການ​ຕັດ​ສິນ​ໂດຍ​ການ​ຕອບ​ສະ​ຫນອງ​ຂອງ​ຜູ້​ພັດ​ທະ​ນາ​"ວິທີການຕັ້ງຄ່າ Loki ເປັນແຫຼ່ງຂໍ້ມູນ Prometheus? · ສະບັບ #1222 · grafana/loki”, ສໍາລັບການຍົກຕົວຢ່າງ, ແມ່ນກົດຫມາຍຢ່າງສົມບູນ, ແລະ Loki ແມ່ນເຫມາະສົມກັບ PromQL ຢ່າງເຕັມສ່ວນ.

ເພີ່ມ Loki ເປັນແຫຼ່ງຂໍ້ມູນທີ່ມີປະເພດ Prometheus ແລະເພີ່ມ URL / loki:

ແລະພວກເຮົາສາມາດສ້າງກາຟ, ຄືກັບວ່າພວກເຮົາເຮັດວຽກກັບ metrics ຈາກ Prometheus:

ຂ້າພະເຈົ້າຄິດວ່າຄວາມແຕກຕ່າງໃນການເຮັດວຽກແມ່ນຊົ່ວຄາວແລະຜູ້ພັດທະນາຈະແກ້ໄຂສິ່ງນີ້ໃນອະນາຄົດ.

ເມຕຣິກ

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

ເພີ່ມພາກສ່ວນອື່ນໃສ່ promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

ທາງເລືອກອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດແລະປັບປຸງ metrics ໂດຍອີງໃສ່ຂໍ້ມູນຈາກແຜນທີ່ສະກັດ. metrics ເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກສົ່ງໄປຫາ Loki - ພວກມັນປາກົດຢູ່ໃນຈຸດສິ້ນສຸດຂອງ Promtail /metrics. Prometheus ຕ້ອງໄດ້ຮັບການຕັ້ງຄ່າເພື່ອຮັບຂໍ້ມູນທີ່ໄດ້ຮັບໃນຂັ້ນຕອນນີ້. ໃນຕົວຢ່າງຂ້າງເທິງ, ສໍາລັບ request_type=“api” ພວກເຮົາເກັບເອົາ histogram metric. ດ້ວຍປະເພດຂອງການວັດແທກນີ້ມັນສະດວກທີ່ຈະໄດ້ຮັບອັດຕາສ່ວນຮ້ອຍ. ສໍາລັບ static ແລະຮູບພາບ, ພວກເຮົາເກັບກໍາຜົນລວມຂອງ bytes ແລະຈໍານວນແຖວທີ່ພວກເຮົາໄດ້ຮັບ bytes ເພື່ອຄິດໄລ່ສະເລ່ຍ.

ອ່ານເພີ່ມເຕີມກ່ຽວກັບການວັດແທກ ທີ່ນີ້.

ເປີດພອດໃນ Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

ໃຫ້ແນ່ໃຈວ່າການວັດແທກທີ່ມີຄໍານໍາຫນ້າ promtail_custom ປາກົດ:

ການຕັ້ງຄ່າ Prometheus. ເພີ່ມວຽກ promtail:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

ແລະພວກເຮົາແຕ້ມເສັ້ນສະແດງ:

ວິທີນີ້ເຈົ້າສາມາດຊອກຫາຕົວຢ່າງ, ສີ່ຄໍາຖາມທີ່ຊ້າທີ່ສຸດ. ນອກນັ້ນທ່ານຍັງສາມາດຕັ້ງຄ່າການຕິດຕາມສໍາລັບ metrics ເຫຼົ່ານີ້.

ການປັບຂະໜາດ

Loki ສາ​ມາດ​ຢູ່​ໃນ​ຮູບ​ແບບ​ຄູ່​ດຽວ​ຫຼື​ໃນ​ຮູບ​ແບບ sharded (ຮູບ​ແບບ​ການ​ຂະ​ຫຍາຍ​ອອກ​ຕາມ​ລວງ​ນອນ​)​. ໃນກໍລະນີທີສອງ, ມັນສາມາດບັນທຶກຂໍ້ມູນໃສ່ເມຄ, ແລະຊິ້ນສ່ວນແລະດັດສະນີຖືກເກັບໄວ້ແຍກຕ່າງຫາກ. ຮຸ່ນ 1.5 ແນະນໍາຄວາມສາມາດໃນການເກັບຮັກສາຢູ່ໃນສະຖານທີ່ດຽວ, ແຕ່ມັນຍັງບໍ່ທັນແນະນໍາໃຫ້ໃຊ້ໃນການຜະລິດ.

Chunks ສາມາດຖືກເກັບໄວ້ໃນການເກັບຮັກສາທີ່ເຂົ້າກັນໄດ້ກັບ S3, ແລະຖານຂໍ້ມູນທີ່ສາມາດຂະຫຍາຍໄດ້ຕາມລວງນອນສາມາດນໍາໃຊ້ເພື່ອເກັບຮັກສາດັດສະນີ: Cassandra, BigTable ຫຼື DynamoDB. ພາກສ່ວນອື່ນໆຂອງ Loki - ຜູ້ຈັດຈໍາຫນ່າຍ (ສໍາລັບການຂຽນ) ແລະ Querier (ສໍາລັບການສອບຖາມ) - ແມ່ນບໍ່ມີລັດແລະຍັງຂະຫນາດຕາມແນວນອນ.

ໃນກອງປະຊຸມ DevOpsDays Vancouver 2019, ຫນຶ່ງໃນຜູ້ເຂົ້າຮ່ວມ Callum Styan ໄດ້ປະກາດວ່າດ້ວຍ Loki ໂຄງການຂອງລາວມີໄມ້ທ່ອນ petabytes ທີ່ມີດັດຊະນີຫນ້ອຍກວ່າ 1% ຂອງຂະຫນາດທັງຫມົດ: "Loki ເຊື່ອມໂຍງ Metrics ແລະບັນທຶກແນວໃດ - ແລະປະຫຍັດເງິນເຈົ້າ".

ການປຽບທຽບ Loki ແລະ ELK

ຂະຫນາດດັດຊະນີ

ເພື່ອທົດສອບຂະຫນາດດັດຊະນີຜົນໄດ້ຮັບ, ຂ້າພະເຈົ້າໄດ້ເອົາບັນທຶກຈາກຖັງ nginx ທີ່ທໍ່ຂ້າງເທິງໄດ້ຖືກຕັ້ງຄ່າ. ໄຟລ໌ບັນທຶກມີ 406 ແຖວທີ່ມີປະລິມານທັງໝົດ 624 MB. ບັນທຶກໄດ້ຖືກສ້າງຂຶ້ນພາຍໃນຫນຶ່ງຊົ່ວໂມງ, ປະມານ 109 ລາຍການຕໍ່ວິນາທີ.

ຕົວຢ່າງຂອງສອງແຖວຈາກບັນທຶກ:

ເມື່ອຖືກດັດສະນີໂດຍ ELK, ນີ້ເຮັດໃຫ້ຂະຫນາດດັດຊະນີ 30,3 MB:

ໃນກໍລະນີຂອງ Loki, ນີ້ເຮັດໃຫ້ດັດຊະນີປະມານ 128 KB ແລະປະມານ 3,8 MB ຂອງຂໍ້ມູນໃນ chunks. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າບັນທຶກໄດ້ຖືກສ້າງຂື້ນໂດຍປອມແລະບໍ່ມີຂໍ້ມູນຈໍານວນຫລາຍ. gzip ງ່າຍໆໃນບັນທຶກ Docker JSON ຕົ້ນສະບັບທີ່ມີຂໍ້ມູນເຮັດໃຫ້ການບີບອັດ 95,4%, ແລະຄໍານຶງເຖິງຄວາມຈິງທີ່ວ່າພຽງແຕ່ບັນທຶກ nginx ທີ່ສະອາດຖືກສົ່ງໄປຫາ Loki ເອງ, ການບີບອັດເຖິງ 4 MB ແມ່ນເຂົ້າໃຈໄດ້. ຈໍານວນທັງຫມົດຂອງມູນຄ່າທີ່ເປັນເອກະລັກສໍາລັບປ້າຍ Loki ແມ່ນ 35, ເຊິ່ງອະທິບາຍເຖິງຂະຫນາດຂະຫນາດນ້ອຍຂອງດັດຊະນີ. ສໍາລັບ ELK ບັນທຶກຍັງຖືກລຶບລ້າງ. ດັ່ງນັ້ນ, Loki ໄດ້ບີບອັດຂໍ້ມູນຕົ້ນສະບັບ 96%, ແລະ ELK 70%.

ການບໍລິໂພກຄວາມຊົງຈໍາ

ຖ້າພວກເຮົາປຽບທຽບ Prometheus ແລະ ELK stack ທັງຫມົດ, ຫຼັງຈາກນັ້ນ Loki "ກິນ" ຫຼາຍເທື່ອຫນ້ອຍ. ມັນເປັນທີ່ຊັດເຈນວ່າການບໍລິການ Go ໃຊ້ຫນ້ອຍກວ່າການບໍລິການ Java, ແລະການປຽບທຽບຂະຫນາດຂອງ JVM Heap Elasticsearch ແລະຫນ່ວຍຄວາມຈໍາທີ່ຈັດສັນສໍາລັບ Loki ແມ່ນບໍ່ຖືກຕ້ອງ, ແຕ່ຢ່າງໃດກໍ່ຕາມມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ Loki ໃຊ້ຫນ່ວຍຄວາມຈໍາຫນ້ອຍລົງ. ປະໂຫຍດຂອງ CPU ຂອງມັນບໍ່ຈະແຈ້ງ, ແຕ່ມັນຍັງມີຢູ່.

ຄວາມໄວ

Loki “devurs” ບັນທຶກໄວຂຶ້ນ. ຄວາມໄວແມ່ນຂຶ້ນກັບປັດໃຈຈໍານວນຫຼາຍ - ປະເພດຂອງບັນທຶກ, ວິທີທີ່ພວກເຮົາມີຄວາມຊັບຊ້ອນໃນການວິເຄາະພວກມັນ, ເຄືອຂ່າຍ, ແຜ່ນ, ແລະອື່ນໆ - ແຕ່ແນ່ນອນແມ່ນສູງກວ່າ ELK (ໃນການທົດສອບຂອງຂ້ອຍ - ປະມານສອງເທົ່າ). ນີ້ແມ່ນອະທິບາຍໂດຍຄວາມຈິງທີ່ວ່າ Loki ເອົາຂໍ້ມູນຫນ້ອຍລົງໃນດັດຊະນີແລະ, ຕາມນັ້ນ, ໃຊ້ເວລາຫນ້ອຍລົງໃນດັດສະນີ. ດ້ວຍຄວາມໄວໃນການຄົ້ນຫາ, ສະຖານະການແມ່ນກົງກັນຂ້າມ: Loki ຊ້າລົງຢ່າງເຫັນໄດ້ຊັດກ່ຽວກັບຂໍ້ມູນທີ່ມີຂະຫນາດໃຫຍ່ກວ່າຫຼາຍ gigabytes, ໃນຂະນະທີ່ຄວາມໄວຄົ້ນຫາຂອງ ELK ບໍ່ຂຶ້ນກັບຂະຫນາດຂອງຂໍ້ມູນ.

ຊອກຫາດ້ວຍບັນທຶກ

Loki ແມ່ນຕໍ່າກວ່າ ELK ຢ່າງຫຼວງຫຼາຍໃນແງ່ຂອງຄວາມສາມາດໃນການຊອກຫາບັນທຶກ. Grep ກັບການສະແດງອອກປົກກະຕິແມ່ນມີອໍານາດ, ແຕ່ວ່າມັນແມ່ນ inferior ກັບຖານຂໍ້ມູນ mature. ການຂາດການສອບຖາມລະດັບ, ການລວບລວມພຽງແຕ່ໂດຍປ້າຍຊື່, ຄວາມບໍ່ສາມາດຄົ້ນຫາໂດຍບໍ່ມີປ້າຍຊື່ - ທັງຫມົດນີ້ຈໍາກັດພວກເຮົາໃນການຄົ້ນຫາຂໍ້ມູນທີ່ຫນ້າສົນໃຈໃນ Loki. ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າບໍ່ມີຫຍັງສາມາດພົບເຫັນໄດ້ໂດຍໃຊ້ Loki, ແຕ່ມັນກໍານົດການໄຫຼເຂົ້າຂອງການເຮັດວຽກກັບໄມ້ທ່ອນໃນເວລາທີ່ທ່ານພົບບັນຫາທໍາອິດໃນຕາຕະລາງ Prometheus, ແລະຫຼັງຈາກນັ້ນໃຊ້ປ້າຍເຫຼົ່ານີ້ເພື່ອຊອກຫາສິ່ງທີ່ເກີດຂຶ້ນໃນບັນທຶກ.

ການໂຕ້ຕອບ

ກ່ອນອື່ນ ໝົດ, ມັນງາມ (ຂໍອະໄພ, ທົນບໍ່ໄດ້). Grafana ມີການໂຕ້ຕອບທີ່ເບິ່ງງາມ, ແຕ່ Kibana ມີຫຼາຍລັກສະນະທີ່ອຸດົມສົມບູນ.

ຂໍ້ດີແລະຂໍ້ເສຍຂອງ Loki

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

ຂໍ້ເສຍແມ່ນເອກະສານທີ່ອ່ອນແອ. ບາງສິ່ງທີ່, ສໍາລັບການຍົກຕົວຢ່າງ, ລັກສະນະແລະຄວາມສາມາດຂອງ Promtail, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບພຽງແຕ່ໃນຂະບວນການຂອງການສຶກສາລະຫັດ, ໂຊກດີມັນເປັນ open-source. ຂໍ້ເສຍອີກອັນໜຶ່ງແມ່ນຄວາມສາມາດໃນການວິເຄາະທີ່ອ່ອນແອ. ຕົວຢ່າງ, Loki ບໍ່ສາມາດວິເຄາະບັນທຶກຫຼາຍແຖວໄດ້. ຂໍ້ເສຍອີກອັນໜຶ່ງແມ່ນວ່າ Loki ເປັນເທັກໂນໂລຍີທີ່ຂ້ອນຂ້າງອ່ອນ (ການປ່ອຍ 1.0 ແມ່ນໃນເດືອນພະຈິກ 2019).

ສະຫລຸບ

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

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

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

repository ທີ່ມີລະຫັດທີ່ໃຊ້ໃນບົດຄວາມແມ່ນຕັ້ງຢູ່ ທີ່ນີ້.

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