ສົ່ງຄືນ scooter ທີ່ຂາດຫາຍໄປ, ຫຼືເລື່ອງຂອງການຕິດຕາມ IoT ຫນຶ່ງ

ປີກ່ອນຫນ້ານີ້ພວກເຮົາໄດ້ເປີດຕົວຮຸ່ນທົດລອງຂອງໂຄງການສົ່ງເສີມການຂາຍສໍາລັບ ການ​ເຊົ່າ​ສະ​ກູດ​ເຕີ​ໄຟ​ຟ້າ​ການ​ແບ່ງ​ປັນ​ສູນ​ກາງ​.

ໃນເບື້ອງຕົ້ນ, ໂຄງການດັ່ງກ່າວໄດ້ຖືກເອີ້ນວ່າ Road-To-Barcelona, ​​​​ຕໍ່ມາມັນໄດ້ກາຍເປັນ Road-To-Berlin (ເພາະສະນັ້ນ R2B ໃນພາບຫນ້າຈໍ), ແລະໃນທີ່ສຸດມັນຖືກເອີ້ນວ່າ xRide.

ແນວຄວາມຄິດຕົ້ນຕໍຂອງໂຄງການນີ້ແມ່ນ: ແທນທີ່ຈະມີລົດກາງຫຼືບໍລິການໃຫ້ເຊົ່າ scooter (ພວກເຮົາເວົ້າກ່ຽວກັບ scooters aka ລົດຈັກໄຟຟ້າ, ບໍ່ແມ່ນ kickscooters / scooters) ພວກເຮົາຕ້ອງການສ້າງເວທີສໍາລັບການເຊົ່າແບບກະຈາຍ. ກ່ຽວກັບຄວາມຫຍຸ້ງຍາກທີ່ພວກເຮົາພົບ ຂຽນກ່ອນໜ້ານີ້.

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

ຜູ້ໃຊ້ຕິດຕັ້ງແອັບພລິເຄຊັນ iOS ຫຼື Android ໃນໂທລະສັບ, ເຂົ້າຫາ scooter ທີ່ລາວມັກ, ຫຼັງຈາກນັ້ນໂທລະສັບແລະ scooter ໄດ້ສ້າງຕັ້ງການເຊື່ອມຕໍ່ peer-to-peer, ETH ໄດ້ຖືກແລກປ່ຽນແລະຜູ້ໃຊ້ສາມາດເລີ່ມຕົ້ນການຂັບເຄື່ອນໂດຍການເປີດ scooter ຜ່ານ. ໂທລະສັບ. ໃນຕອນທ້າຍຂອງການເດີນທາງ, ມັນກໍ່ເປັນໄປໄດ້ທີ່ຈະຈ່າຍຄ່າເດີນທາງໂດຍໃຊ້ Ethereum ຈາກກະເປົາເງິນຂອງຜູ້ໃຊ້ໃນໂທລະສັບ.

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

ໂດຍທົ່ວໄປແລ້ວ, ນີ້ແມ່ນສິ່ງທີ່ນັກບິນຂອງພວກເຮົາເບິ່ງຄື, ເປີດຕົວໃນເດືອນກັນຍາປີກາຍນີ້ໃນສອງເມືອງຂອງເຢຍລະມັນ: Bonn ແລະ Berlin.

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

ວິທີການຊອກຫາມັນແລະສົ່ງຄືນ?

ໃນບົດຄວາມນີ້ຂ້ອຍຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້, ແຕ່ທໍາອິດ - ກ່ຽວກັບວິທີທີ່ພວກເຮົາສ້າງເວທີ IoT ຂອງພວກເຮົາເອງແລະວິທີການຕິດຕາມມັນ.

ແມ່ນຫຍັງ ແລະເປັນຫຍັງຕ້ອງຕິດຕາມ: ສະກູດເຕີ, ໂຄງສ້າງພື້ນຖານ, ສະຖານີສາກໄຟ?

ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງການຕິດຕາມຫຍັງແດ່ໃນໂຄງການຂອງພວກເຮົາ?

ກ່ອນອື່ນ ໝົດ, ເຫຼົ່ານີ້ແມ່ນ scooters ຕົວເອງ - scooters ໄຟຟ້າຕົວເອງມີລາຄາແພງຫຼາຍ, ທ່ານບໍ່ສາມາດເປີດຕົວໂຄງການດັ່ງກ່າວໂດຍບໍ່ມີການກະກຽມພຽງພໍ; ຖ້າເປັນໄປໄດ້, ທ່ານຕ້ອງການເກັບກໍາຂໍ້ມູນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ກ່ຽວກັບ scooters: ກ່ຽວກັບສະຖານທີ່ຂອງພວກເຂົາ, ລະດັບການຄິດຄ່າ. , ແລະອື່ນໆ.

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

ສະກູດເຕີ

ສະກູດເຕີຂອງພວກເຮົາແມ່ນຫຍັງ ແລະພວກເຮົາຢາກຮູ້ຫຍັງກ່ຽວກັບພວກມັນ?

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

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

ແນ່ນອນ, ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະກວດເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນກັບອົງປະກອບຮາດແວຂອງພວກເຮົາ:

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

ແລະສຸດທ້າຍ: ການກວດສອບຊອບແວ, ເລີ່ມຕົ້ນດ້ວຍ OS ແລະໂປເຊດເຊີ, ການໂຫຼດເຄືອຂ່າຍແລະແຜ່ນ, ສິ້ນສຸດດ້ວຍການກວດສອບໂມດູນຂອງພວກເຮົາເອງທີ່ສະເພາະກັບພວກເຮົາ (ໂຈໂລຄອມ, ກະແຈ).

ອຸປະກອນ

ສ່ວນ "ທາດເຫຼັກ" ຂອງພວກເຮົາແມ່ນຫຍັງ?

ໂດຍພິຈາລະນາເຖິງໄລຍະເວລາທີ່ສັ້ນທີ່ສຸດທີ່ເປັນໄປໄດ້ແລະຄວາມຕ້ອງການສໍາລັບການສ້າງຕົວແບບຢ່າງໄວວາ, ພວກເຮົາໄດ້ເລືອກທາງເລືອກທີ່ງ່າຍທີ່ສຸດສໍາລັບການປະຕິບັດແລະການຄັດເລືອກອົງປະກອບ - Raspberry Pi.
ນອກ ເໜືອ ໄປຈາກ Rpi ຕົວຂອງມັນເອງ, ພວກເຮົາມີກະດານທີ່ ກຳ ນົດເອງ (ເຊິ່ງຕົວເຮົາເອງພັດທະນາແລະສັ່ງຈາກປະເທດຈີນເພື່ອເລັ່ງຂະບວນການປະກອບຂອງການແກ້ໄຂສຸດທ້າຍ) ແລະຊຸດຂອງສ່ວນປະກອບ - ລີເລ (ເພື່ອເປີດ / ປິດສະກູດເຕີ), ເຄື່ອງອ່ານການສາກແບັດເຕີຣີ, ໂມເດັມ, ເສົາອາກາດ. ທັງຫມົດນີ້ໄດ້ຖືກຫຸ້ມຫໍ່ຢ່າງແຫນ້ນຫນາໃນ "ກ່ອງ xRide".

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

ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ການຕິດຕາມແລະເປີດ scooter ເຖິງແມ່ນວ່າຫຼັງຈາກສິ້ນສຸດຂອງການເດີນທາງ, ເນື່ອງຈາກວ່າຫມໍ້ໄຟຕົ້ນຕໍໄດ້ຖືກປິດທັນທີຫຼັງຈາກຫັນກະແຈຈຸດໄຟໄປຫາຕໍາແຫນ່ງ "ປິດ".

Docker? Linux ທຳມະດາ? ແລະ​ການ​ນໍາ​ໃຊ້​

ໃຫ້ກັບຄືນໄປຫາການຕິດຕາມ, ດັ່ງນັ້ນ Raspberry - ພວກເຮົາມີຫຍັງແດ່?

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

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

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

ເຫດຜົນທີສອງແມ່ນຫນຶ່ງໃນຫ້ອງສະຫມຸດຄູ່ຮ່ວມງານຂອງພວກເຮົາໃນ Node.js (sic!) - ອົງປະກອບດຽວຂອງລະບົບທີ່ບໍ່ໄດ້ຂຽນໄວ້ໃນ Go/C/C++.

ຜູ້ຂຽນຂອງຫ້ອງສະຫມຸດບໍ່ມີເວລາທີ່ຈະສະຫນອງສະບັບພາສາທີ່ເຮັດວຽກຢູ່ໃນພາສາ "ພື້ນເມືອງ".

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

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

OS

ດັ່ງນັ້ນ, ພວກເຮົາ, ອີກເທື່ອຫນຶ່ງ, ເລືອກທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດເປັນ OS ແລະໃຊ້ Raspbian (Debian build for Pi).

ພວກເຮົາຂຽນຊອບແວຂອງພວກເຮົາທັງຫມົດໃນ Go, ດັ່ງນັ້ນພວກເຮົາຍັງໄດ້ຂຽນໂມດູນຕົວແທນຮາດແວຕົ້ນຕໍໃນລະບົບຂອງພວກເຮົາໃນ Go.

ມັນແມ່ນຜູ້ທີ່ຮັບຜິດຊອບໃນການເຮັດວຽກກັບ GPS, Bluetooth, ອ່ານຄ່າ, ເປີດ scooter, ແລະອື່ນໆ.

ນຳໃຊ້

ຄໍາຖາມເກີດຂຶ້ນທັນທີກ່ຽວກັບຄວາມຕ້ອງການທີ່ຈະປະຕິບັດກົນໄກການສະຫນອງການອັບເດດອຸປະກອນ (OTA) - ທັງສອງການອັບເດດກັບຕົວແທນ / ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາເອງ, ແລະການອັບເດດກັບ OS / firmware ຕົວຂອງມັນເອງ (ເນື່ອງຈາກສະບັບໃຫມ່ຂອງຕົວແທນສາມາດຮຽກຮ້ອງໃຫ້ມີການອັບເດດກັບ kernel ໄດ້. ຫຼືອົງປະກອບຂອງລະບົບ, ຫ້ອງສະຫມຸດ, ແລະອື່ນໆ).

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

ຈາກທີ່ຂ້ອນຂ້າງງ່າຍດາຍ, ສ່ວນຫຼາຍແມ່ນປັບປຸງ / dual-boot ຮັດກຸມຜົນປະໂຫຍດເຊັ່ນ swupd / SWUpdate / OSTree ໄປສູ່ເວທີເຕັມຮູບແບບເຊັ່ນ: Mender ແລະ Balena.

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາໄດ້ຕັດສິນໃຈວ່າພວກເຮົາມີຄວາມສົນໃຈໃນການແກ້ໄຂໃນຕອນທ້າຍ, ສະນັ້ນທາງເລືອກກໍ່ຕົກຢູ່ໃນເວທີຕ່າງໆ.

ຕົນເອງ ບາເລນາ ໄດ້ຖືກຍົກເວັ້ນເນື່ອງຈາກຄວາມຈິງທີ່ວ່າມັນໃຊ້ Docker ດຽວກັນພາຍໃນ balenaEngine ຂອງມັນ.

ແຕ່ຂ້ອຍສັງເກດວ່າເຖິງວ່າຈະມີສິ່ງນີ້, ພວກເຮົາສິ້ນສຸດລົງຢ່າງຕໍ່ເນື່ອງໃນການນໍາໃຊ້ຜະລິດຕະພັນຂອງພວກເຂົາ Whale Etcher ສໍາລັບ flash firmware ໃນ SD card - ເປັນຜົນປະໂຫຍດທີ່ງ່າຍດາຍແລະສະດວກທີ່ສຸດສໍາລັບການນີ້.

ເພາະສະນັ້ນ, ໃນທີ່ສຸດທາງເລືອກໄດ້ຫຼຸດລົງ ຜູ້ຊາຍ. Mender ເປັນເວທີທີ່ສົມບູນສໍາລັບການປະກອບ, ສົ່ງແລະຕິດຕັ້ງເຟີມແວ.

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

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

ຄວາມເຂົ້າໃຈ

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

ໂດຍເນື້ອແທ້ແລ້ວຂອງພວກເຂົາແມ່ນວ່າພວກເຮົາເຊື່ອມຕໍ່ພຽງແຕ່ຈາກເຄື່ອງແມ່ຂ່າຍ (CI server) ຜ່ານ ssh ກັບ rasberries ຂອງພວກເຮົາແລະແຈກຢາຍການປັບປຸງໃຫ້ພວກເຂົາ.

ໃນຕອນເລີ່ມຕົ້ນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ - ທ່ານຕ້ອງຢູ່ໃນເຄືອຂ່າຍດຽວກັນກັບອຸປະກອນ, ການຖອກນ້ໍາແມ່ນເຮັດຜ່ານ Wi-Fi.

ຢູ່ໃນຫ້ອງການ, ມີພຽງແຕ່ຫນຶ່ງອາຍແກັສທົດສອບ raspberries ເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍດຽວກັນ, ແຕ່ລະອຸປະກອນມີທີ່ຢູ່ IP ຄົງທີ່ຍັງລະບຸໄວ້ໃນສາງ Ansible.

ມັນແມ່ນ Ansible ທີ່ສົ່ງຕົວແທນຕິດຕາມຂອງພວກເຮົາໄປຫາອຸປະກອນສຸດທ້າຍ

3G / LTE

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

ເນື່ອງຈາກວ່າສະກູດເຕີ, ຕາມທີ່ທ່ານເຂົ້າໃຈ, ບໍ່ໄດ້ນັ່ງເຊື່ອມຕໍ່ກັບ router Wi-Fi ຫນຶ່ງ, ລໍຖ້າການອັບເດດຜ່ານເຄືອຂ່າຍຢ່າງຕໍ່ເນື່ອງ.

ໃນຄວາມເປັນຈິງ, ສະກູດເຕີບໍ່ສາມາດມີການເຊື່ອມຕໍ່ໃດໆນອກເຫນືອຈາກມືຖື 3G / LTE (ແລະເຖິງແມ່ນວ່າບໍ່ແມ່ນຕະຫຼອດເວລາ).

ນີ້ທັນທີ imposes ບັນຫາແລະຂໍ້ຈໍາກັດຈໍານວນຫຼາຍ, ເຊັ່ນ: ຄວາມໄວການເຊື່ອມຕໍ່ຕ່ໍາແລະການສື່ສານບໍ່ຫມັ້ນຄົງ.

ແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນວ່າໃນເຄືອຂ່າຍ 3G / LTE ພວກເຮົາບໍ່ສາມາດພຽງແຕ່ອີງໃສ່ IP ຄົງທີ່ມອບຫມາຍໃຫ້ເຄືອຂ່າຍ.

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

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

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

VPN

ເປັນການແກ້ໄຂບັນຫານີ້, ພວກເຮົາເລືອກ VPN - ໂດຍສະເພາະ ຊ່າງເຫຼັກ.

ລູກຄ້າ (ສະກູດເຕີ) ໃນຕອນເລີ່ມຕົ້ນຂອງລະບົບທີ່ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ VPN ແລະສາມາດເຊື່ອມຕໍ່ກັບພວກເຂົາໄດ້. ອຸໂມງນີ້ຖືກໃຊ້ເພື່ອສົ່ງການອັບເດດ.

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

ຊັບພະຍາກອນຄລາວ

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

ມອບໃຫ້

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

• ການ​ແກ້​ໄຂ​ໄວ​, ເນື່ອງ​ຈາກ​ວ່າ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ແມ່ນ​ມີ​ຄວາມ​ຈໍາ​ເປັນ​ແລ້ວ​ໃນ​ຂະ​ບວນ​ການ​ພັດ​ທະ​ນາ​
• ປະລິມານ/ປະລິມານ – ຕ້ອງການຫຼາຍຕົວວັດແທກ
• ການເກັບບັນທຶກແມ່ນຕ້ອງການ
• ຄວາມຫນ້າເຊື່ອຖື - ຂໍ້ມູນແມ່ນສໍາຄັນຕໍ່ການເປີດຕົວຄວາມສໍາເລັດ
• ທ່ານບໍ່ສາມາດໃຊ້ຕົວແບບດຶງ - ທ່ານຕ້ອງການຍູ້
• ພວກ​ເຮົາ​ຕ້ອງ​ການ​ການ​ຕິດ​ຕາມ​ຄວາມ​ເປັນ​ເອ​ກະ​ພາບ​ຂອງ​ບໍ່​ພຽງ​ແຕ່​ຮາດ​ແວ​, ແຕ່​ຍັງ​ຟັງ​ໄດ້​

ຮູບພາບສຸດທ້າຍເບິ່ງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້

ການເລືອກ stack

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ປະເຊີນກັບຄໍາຖາມຂອງການເລືອກ stack ຕິດຕາມກວດກາ.

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

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

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

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

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

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

(B)ELK?

ການແກ້ໄຂທໍາອິດທີ່ໄດ້ພິຈາລະນາຕົວຈິງແມ່ນ stack ELK ທີ່ມີຊື່ສຽງ.
ໃນຄວາມເປັນຈິງ, ມັນຄວນຈະຖືກເອີ້ນວ່າ BELK, ເພາະວ່າມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍ Beats - https://www.elastic.co/what-is/elk-stack

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

ພວກເຮົາຕັ້ງໃຈວ່າ ELK ຈະຖືກໃຊ້ເພື່ອເກັບກຳບັນທຶກ ແລະ ພ້ອມທັງການເກັບຮັກສາໃນໄລຍະຍາວຂອງ metrics ທີ່ໄດ້ຮັບຈາກ Prometheus.

ສໍາລັບການເບິ່ງເຫັນ, ທ່ານສາມາດນໍາໃຊ້ Grafan.

ໃນຄວາມເປັນຈິງ, stack ELK ໃຫມ່ສາມາດເກັບກໍາ metrics ເປັນເອກະລາດ (metricbeat), ແລະ Kibana ຍັງສາມາດສະແດງໃຫ້ເຂົາເຈົ້າ.

ແຕ່ຢ່າງໃດກໍ່ຕາມ, ELK ໃນເບື້ອງຕົ້ນໄດ້ເຕີບໂຕອອກຈາກບັນທຶກແລະມາຮອດປັດຈຸບັນການເຮັດວຽກຂອງ metrics ມີຂໍ້ບົກຜ່ອງທີ່ຮ້າຍແຮງຫຼາຍ:

• ຊ້າກວ່າ Prometheus ຢ່າງຫຼວງຫຼາຍ
• ປະສົມປະສານເຂົ້າໄປໃນສະຖານທີ່ຫນ້ອຍກວ່າ Prometheus
• ມັນຍາກທີ່ຈະຕັ້ງການແຈ້ງເຕືອນໃຫ້ເຂົາເຈົ້າ
• metrics ໃຊ້ພື້ນທີ່ຫຼາຍ
• ການຕັ້ງຄ່າ dashboards ກັບ metrics ໃນ Kiban ແມ່ນສັບສົນຫຼາຍກ່ວາໃນ Grafan

ໂດຍທົ່ວໄປ, metrics ໃນ ELK ແມ່ນຫນັກແລະຍັງບໍ່ທັນສະດວກຄືກັບການແກ້ໄຂອື່ນໆ, ເຊິ່ງໃນປັດຈຸບັນມີຫຼາຍກ່ວາພຽງແຕ່ Prometheus: TSDB, Victoria Metrics, Cortex, ແລະອື່ນໆ. ແນ່ນອນ, ຂ້າພະເຈົ້າກໍ່ຢາກມີການແກ້ໄຂທັງຫມົດໃນຫນຶ່ງທັນທີ, ແຕ່ໃນກໍລະນີຂອງ metricbeat ມີການປະນີປະນອມຫຼາຍເກີນໄປ.

ແລະ stack ELK ຕົວຂອງມັນເອງມີຈໍານວນເວລາທີ່ຫຍຸ້ງຍາກ:

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

ຂ້າພະເຈົ້າຕ້ອງເວົ້າວ່າບໍ່ດົນມານີ້ຈຸດສຸດທ້າຍໄດ້ກາຍເປັນທີ່ດີກວ່າແລະນອກຈາກນັ້ນ ຜົນຜະລິດໃນ X-pack ເປີດ (ລວມທັງການພິສູດຢືນຢັນ) ຮູບແບບລາຄາຂອງມັນເອງເລີ່ມມີການປ່ຽນແປງ.

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

Loki - Grafana - Prometheus

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

ແຕ່ຫນ້າເສຍດາຍ, ໃນຊ່ວງເວລາເລີ່ມຕົ້ນຂອງການທົດລອງການຂາຍຂອງໂຄງການ (ເດືອນກັນຍາ-ຕຸລາ 19), Loki ຍັງຢູ່ໃນຮຸ່ນ beta 0.3-0.4, ແລະໃນເວລາທີ່ເລີ່ມຕົ້ນຂອງການພັດທະນາມັນບໍ່ສາມາດພິຈາລະນາເປັນການແກ້ໄຂການຜະລິດ. ທັງໝົດ.

ຂ້ອຍຍັງບໍ່ທັນມີປະສົບການໃນຕົວຈິງໃນການນໍາໃຊ້ Loki ໃນໂຄງການທີ່ຮ້າຍແຮງ, ແຕ່ຂ້ອຍສາມາດເວົ້າໄດ້ວ່າ Promtail (ຕົວແທນສໍາລັບການລວບລວມຂໍ້ມູນບັນທຶກ) ເຮັດວຽກໄດ້ດີສໍາລັບທັງໂລຫະເປົ່າແລະ pods ໃນ kubernetes.

ເຄັກ

ບາງທີທາງເລືອກທີ່ມີຄ່າທີ່ສຸດ (ອັນດຽວ?) ເຕັມຮູບແບບກັບ stack ELK ໃນປັດຈຸບັນສາມາດຖືກເອີ້ນວ່າ stack TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

ຂ້າພະເຈົ້າຈະອະທິບາຍອົງປະກອບທັງຫມົດຂ້າງລຸ່ມນີ້ໃນລາຍລະອຽດເພີ່ມເຕີມ, ແຕ່ແນວຄວາມຄິດທົ່ວໄປແມ່ນນີ້:

• Telegraf - ຕົວແທນສໍາລັບການລວບລວມ metrics
• InfluxDB - ຖານຂໍ້ມູນ metrics
• Kapacitor - ໂປເຊດເຊີ metrics ໃນເວລາຈິງສໍາລັບການແຈ້ງເຕືອນ
• Chronograf - ກະດານເວັບໄຊຕ໌ສໍາລັບການເບິ່ງເຫັນ

ສໍາລັບ InfluxDB, Kapacitor ແລະ Chronograf ມີຕາຕະລາງຫມວກກັນກະທົບຢ່າງເປັນທາງການທີ່ພວກເຮົາເຄີຍໃຊ້ພວກມັນ.

ຄວນສັງເກດວ່າໃນຮຸ່ນຫຼ້າສຸດຂອງ Influx 2.0 (beta), Kapacitor ແລະ Chronograf ໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງ InfluxDB ແລະບໍ່ມີຢູ່ແຍກຕ່າງຫາກ.

ໂທລະເລກ

ໂທລະເລກ ແມ່ນຕົວແທນທີ່ມີນ້ໍາຫນັກເບົາຫຼາຍສໍາລັບການລວບລວມ metrics ໃນເຄື່ອງຂອງລັດ.

ລາວສາມາດຕິດຕາມກວດກາເປັນຈໍານວນ huge ຂອງທຸກສິ່ງທຸກຢ່າງ, ຈາກ nginx ການ
ເຄື່ອງແມ່ຂ່າຍ minecraft.

ມັນ​ມີ​ຈໍາ​ນວນ​ຂອງ​ຄວາມ​ໄດ້​ປຽບ​ເຢັນ​:

• ໄວ ແລະ ນ້ຳໜັກເບົາ (ຂຽນເປັນ Go)
  • ກິນຈໍານວນຊັບພະຍາກອນຕໍາ່ສຸດທີ່
• ຊຸກຍູ້ການວັດແທກຕາມຄ່າເລີ່ມຕົ້ນ
• ເກັບກໍາຂໍ້ມູນວັດແທກທີ່ຈໍາເປັນທັງຫມົດ
  • ການວັດແທກລະບົບໂດຍບໍ່ມີການຕັ້ງຄ່າໃດໆ
  • ການວັດແທກຮາດແວເຊັ່ນ: ຂໍ້ມູນຈາກເຊັນເຊີ
  • ມັນງ່າຍຫຼາຍທີ່ຈະເພີ່ມ metrics ຂອງທ່ານເອງ
• ຫຼາຍ plugins ອອກຈາກກ່ອງ
• ເກັບກຳບັນທຶກ

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

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

Influx ສະເຫນີປະສົບການທີ່ສະດວກທີ່ສຸດສໍາລັບການເຮັດວຽກກັບບັນທຶກຖ້າທ່ານໃຊ້ syslog.

Telegraf ໂດຍທົ່ວໄປແມ່ນຕົວແທນທີ່ດີສໍາລັບການລວບລວມ metrics, ເຖິງແມ່ນວ່າທ່ານບໍ່ໄດ້ໃຊ້ສ່ວນທີ່ເຫຼືອຂອງ ICK stack.

ຫຼາຍຄົນຂ້າມມັນດ້ວຍ ELK ແລະຖານຂໍ້ມູນຊຸດເວລາອື່ນໆເພື່ອຄວາມສະດວກ, ເພາະວ່າມັນສາມາດຂຽນ metrics ໄດ້ເກືອບທຸກບ່ອນ.

InfluxDB

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

InfluxDB ຍັງຖືກຂຽນໄວ້ໃນ Go ແລະເບິ່ງຄືວ່າຈະແລ່ນໄວກວ່າເມື່ອທຽບກັບ ELK ໃນກຸ່ມຂອງພວກເຮົາ (ບໍ່ມີອໍານາດທີ່ສຸດ).

ຫນຶ່ງໃນຂໍ້ໄດ້ປຽບເຢັນຂອງ Influx ຍັງຈະປະກອບມີ API ທີ່ສະດວກແລະອຸດົມສົມບູນສໍາລັບການສອບຖາມຂໍ້ມູນ, ທີ່ພວກເຮົາໃຊ້ຢ່າງຫ້າວຫັນ.

ຂໍ້ເສຍ - $$$ ຫຼືຂະຫນາດ?

stack TICK ມີພຽງແຕ່ຫນຶ່ງຈຸດອ່ອນທີ່ພວກເຮົາຄົ້ນພົບ - ມັນ darling. ຍິ່ງກວ່ານັ້ນ.

ສະບັບຈ່າຍມີອັນໃດທີ່ສະບັບຟຣີບໍ່ມີ?

ເທົ່າທີ່ພວກເຮົາສາມາດເຂົ້າໃຈໄດ້, ຄວາມແຕກຕ່າງພຽງແຕ່ລະຫວ່າງສະບັບທີ່ຈ່າຍຂອງ TICK stack ແລະຟຣີແມ່ນຄວາມສາມາດໃນການປັບຂະຫນາດ.

ຄື, ທ່ານສາມາດຍົກກຸ່ມທີ່ມີຄວາມພ້ອມສູງພຽງແຕ່ຢູ່ໃນ ສະບັບວິສາຫະກິດ.

ຖ້າທ່ານຕ້ອງການ HA ຢ່າງເຕັມທີ່, ທ່ານຈໍາເປັນຕ້ອງຈ່າຍຫຼືໃຊ້ໄມ້ຄ້ອນບາງ. ມີບາງວິທີແກ້ໄຂຂອງຊຸມຊົນ - ຕົວຢ່າງ influxdb-ha ເບິ່ງຄືວ່າເປັນການແກ້ໄຂທີ່ມີຄວາມສາມາດ, ແຕ່ມັນຖືກຂຽນວ່າມັນບໍ່ເຫມາະສົມສໍາລັບການຜະລິດ, ເຊັ່ນດຽວກັນກັບ
influx-spout - ເປັນ​ການ​ແກ້​ໄຂ​ງ່າຍ​ດາຍ​ທີ່​ມີ​ການ​ສູບ​ຂໍ້​ມູນ​ໂດຍ​ຜ່ານ NATS (ມັນ​ຍັງ​ຈະ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ຂະ​ຫຍາຍ​, ແຕ່​ນີ້​ສາ​ມາດ​ແກ້​ໄຂ​ໄດ້​)​.

ມັນເປັນສິ່ງທີ່ ໜ້າ ສົງສານ, ແຕ່ທັງສອງເບິ່ງຄືວ່າຖືກປະຖິ້ມ - ບໍ່ມີ ຄຳ ໝັ້ນ ສັນຍາສົດ, ຂ້ອຍສົມມຸດວ່າບັນຫາແມ່ນການປ່ອຍ Influx 2.0 ລຸ້ນ ໃໝ່ ທີ່ຄາດວ່າຈະມີໃນໄວໆນີ້, ເຊິ່ງຫຼາຍສິ່ງຈະແຕກຕ່າງກັນ (ບໍ່ມີຂໍ້ມູນກ່ຽວກັບ ຂະ​ຫນາດ​ໃນ​ມັນ​ຍັງ​)​.

ຢ່າງເປັນທາງການມີສະບັບຟຣີ Relay - ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນ HA ເບື້ອງຕົ້ນ, ແຕ່ວ່າພຽງແຕ່ຜ່ານການດຸ່ນດ່ຽງ,
ເນື່ອງຈາກວ່າຂໍ້ມູນທັງຫມົດຈະຖືກຂຽນໃສ່ທຸກ influxDB instances ທີ່ຢູ່ເບື້ອງຫຼັງ load balancer.
ລາວມີບາງ ຂໍ້ເສຍປຽບ ຄືກັບບັນຫາທີ່ອາດຈະເກີດຂຶ້ນກັບການຂຽນທັບຈຸດ ແລະຄວາມຕ້ອງການສ້າງພື້ນຖານສໍາລັບ metrics ລ່ວງຫນ້າ
(ເຊິ່ງເກີດຂຶ້ນໂດຍອັດຕະໂນມັດໃນລະຫວ່າງການເຮັດວຽກປົກກະຕິກັບ InfluxDB).

ນອກຈາກນັ້ນ ບໍ່ຮອງຮັບ sharding, ນີ້ຫມາຍຄວາມວ່າຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມສໍາລັບ metrics ທີ່ຊ້ໍາກັນ (ທັງການປຸງແຕ່ງແລະການເກັບຮັກສາ) ທີ່ທ່ານອາດຈະບໍ່ຕ້ອງການ, ແຕ່ບໍ່ມີວິທີທີ່ຈະແຍກພວກມັນ.

Victoria Metrics?

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

ມີຖານຂໍ້ມູນຊຸດເວລາຫຼາຍ, ແຕ່ສິ່ງທີ່ດີທີ່ສຸດແມ່ນ Victoria Metrics, ມັນມີຂໍ້ດີຫຼາຍ:

• ໄວແລະງ່າຍ, ຢ່າງຫນ້ອຍອີງຕາມຜົນໄດ້ຮັບ ມາດຕະຖານ
• ມີສະບັບກຸ່ມ, ເຊິ່ງມີການທົບທວນຄືນທີ່ດີໃນປັດຈຸບັນ
  • ນາງສາມາດ shard
• ສະຫນັບສະຫນູນອະນຸສັນຍາ InfluxDB

ພວກເຮົາບໍ່ໄດ້ຕັ້ງໃຈທີ່ຈະສ້າງ stack custom ຢ່າງສົມບູນໂດຍອີງໃສ່ Victoria ແລະຄວາມຫວັງຕົ້ນຕໍແມ່ນວ່າພວກເຮົາສາມາດນໍາໃຊ້ມັນເປັນການຫຼຸດລົງໃນການທົດແທນ InfluxDB.

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

ຍິ່ງໄປກວ່ານັ້ນ, ພຽງແຕ່ຄ່າຕົວເລກແມ່ນສະຫນັບສະຫນູນສໍາລັບ metrics (ພວກເຮົາໄດ້ໃຊ້ຄ່າ string ສໍາລັບ custom metrics - ເພີ່ມເຕີມກ່ຽວກັບວ່າໃນພາກ ກະດານຜູ້ເບິ່ງແຍງ).

ແນ່ນອນ, ສໍາລັບເຫດຜົນດຽວກັນ, VM ບໍ່ສາມາດເກັບຮັກສາບັນທຶກຄືກັບ Influx.

ນອກຈາກນີ້, ຄວນສັງເກດວ່າໃນເວລາທີ່ຊອກຫາວິທີແກ້ໄຂທີ່ດີທີ່ສຸດ, Victoria Metrics ຍັງບໍ່ທັນເປັນທີ່ນິຍົມ, ເອກະສານມີຂະຫນາດນ້ອຍກວ່າແລະຫນ້າທີ່ຍັງອ່ອນກວ່າ.
(ຂ້ອຍບໍ່ຈື່ລາຍລະອຽດຂອງສະບັບ cluster ແລະ sharding).

ການຄັດເລືອກພື້ນຖານ

ດັ່ງນັ້ນ, ມັນໄດ້ຖືກຕັດສິນໃຈວ່າສໍາລັບນັກບິນພວກເຮົາຍັງຈະຈໍາກັດຕົວເອງກັບ InfluxDB node ດຽວ.

ມີຫຼາຍເຫດຜົນຕົ້ນຕໍສໍາລັບການເລືອກນີ້:

• ພວກເຮົາມັກຟັງຊັນທັງໝົດຂອງ TICK stack
• ພວກ​ເຮົາ​ໄດ້​ຈັດ​ການ​ນໍາ​ໃຊ້​ມັນ​ແລ້ວ​ແລະ​ມັນ​ເຮັດ​ວຽກ​ທີ່​ດີ​ເລີດ​
• ເສັ້ນຕາຍໝົດແລ້ວ ແລະບໍ່ມີເວລາເຫຼືອຫຼາຍເພື່ອທົດສອບທາງເລືອກອື່ນ.
• ພວກເຮົາບໍ່ໄດ້ຄາດຫວັງວ່າການໂຫຼດຫນັກດັ່ງກ່າວ

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

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

ພວກເຮົາໄດ້ຕັດສິນໃຈກ່ຽວກັບ stack ແລະພື້ນຖານ - ໃນປັດຈຸບັນກ່ຽວກັບອົງປະກອບທີ່ຍັງເຫຼືອຂອງ stack TICK.

Kapacitor

Kapacitor ແມ່ນສ່ວນຫນຶ່ງຂອງ TICK stack, ການບໍລິການທີ່ສາມາດຕິດຕາມ metrics ເຂົ້າໄປໃນຖານຂໍ້ມູນໃນເວລາທີ່ແທ້ຈິງແລະປະຕິບັດການປະຕິບັດຕ່າງໆໂດຍອີງໃສ່ກົດລະບຽບ.

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

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

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

ຕົວຢ່າງທີ່ງ່າຍດາຍ: ຫມໍ້ໄຟເພີ່ມເຕີມເພື່ອພະລັງງານ "ກ່ອງ" ຂອງພວກເຮົາໄດ້ແຕກຫັກຫຼືດ້ວຍເຫດຜົນບາງຢ່າງທີ່ພະລັງງານຫມົດ; ພຽງແຕ່ຕິດຕັ້ງໃຫມ່, ຫຼັງຈາກນັ້ນບໍ່ດົນພວກເຮົາຄວນຈະໄດ້ຮັບການແຈ້ງເຕືອນວ່າການເຮັດວຽກຂອງ scooter ໄດ້ຖືກຟື້ນຟູຄືນມາ.

ໃນ Influx 2.0 Kapacitor ໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງ DB

Chronograph

ຂ້ອຍໄດ້ເຫັນການແກ້ໄຂ UI ທີ່ແຕກຕ່າງກັນຫຼາຍສໍາລັບການຕິດຕາມ, ແຕ່ຂ້ອຍສາມາດເວົ້າໄດ້ວ່າໃນແງ່ຂອງການເຮັດວຽກແລະ UX, ບໍ່ມີຫຍັງປຽບທຽບກັບ Chronograf.

ພວກເຮົາໄດ້ເລີ່ມໃຊ້ TICK stack, oddly ພຽງພໍ, ກັບ Grafan ເປັນການໂຕ້ຕອບເວັບໄຊຕ໌.
ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບໍ່​ອະ​ທິ​ບາຍ​ການ​ທໍາ​ງານ​ຂອງ​ຕົນ​; ທຸກ​ຄົນ​ຮູ້​ວ່າ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ອັນ​ກວ້າງ​ຂວາງ​ຂອງ​ຕົນ​ສໍາ​ລັບ​ການ​ຕັ້ງ​ຄ່າ​ຫຍັງ​.

ຢ່າງໃດກໍຕາມ, Grafana ຍັງຄົງເປັນເຄື່ອງມືທົ່ວໄປຢ່າງສົມບູນ, ໃນຂະນະທີ່ Chronograf ສ່ວນໃຫຍ່ແມ່ນຖືກອອກແບບມາສໍາລັບການນໍາໃຊ້ກັບ Influx.

ແລະແນ່ນອນ, ຂໍຂອບໃຈກັບສິ່ງນີ້, Chronograf ສາມາດມີຫນ້າທີ່ສະຫລາດຫຼືສະດວກກວ່າ.

ບາງທີຄວາມສະດວກສະບາຍຕົ້ນຕໍຂອງການເຮັດວຽກກັບ Chronograf ແມ່ນວ່າທ່ານສາມາດເບິ່ງພາຍໃນຂອງ InfluxDB ຂອງທ່ານໂດຍຜ່ານ Explore.

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

Kibana ມີຄວາມສາມາດຫຼາຍກວ່າເກົ່າສໍາລັບການສ້າງ dashboards ແລະການຄວບຄຸມສໍາລັບພວກເຂົາ, ແຕ່ UX ສໍາລັບການດໍາເນີນງານດັ່ງກ່າວແມ່ນສັບສົນຫຼາຍ.

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

ກະດານ dashboards ຕົວຂອງມັນເອງ, ນອກເຫນືອຈາກຮູບແບບສາຍຕາທີ່ຫນ້າພໍໃຈ, ຕົວຈິງແລ້ວບໍ່ແຕກຕ່າງຈາກ dashboards ໃນ Grafana ຫຼື Kibana:

ນີ້ແມ່ນສິ່ງທີ່ຫນ້າຕ່າງການສອບຖາມເບິ່ງຄື:

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

ແລະແນ່ນອນ, Chronograf ແມ່ນສະດວກທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້ສໍາລັບການເບິ່ງບັນທຶກ. ມັນເບິ່ງຄືວ່ານີ້:

ໂດຍຄ່າເລີ່ມຕົ້ນ, ບັນທຶກ Influx ແມ່ນເຫມາະສົມກັບການນໍາໃຊ້ syslog ແລະດັ່ງນັ້ນພວກມັນມີພາລາມິເຕີທີ່ສໍາຄັນ - ຄວາມຮຸນແຮງ.

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

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

ແນ່ນອນ, ໂດຍວິທີທາງການ, ມັນຈະເປັນການຕິດຕັ້ງການແຈ້ງເຕືອນສໍາລັບຄວາມຜິດພາດດັ່ງກ່າວ, ເນື່ອງຈາກວ່າພວກເຮົາມີທຸກສິ່ງທຸກຢ່າງສໍາລັບການນີ້ແລ້ວ.

ພວກເຮົາກໍ່ເປີດມັນເປັນເວລາຫນຶ່ງ, ແຕ່ໃນຂະບວນການກະກຽມນັກບິນ, ມັນໄດ້ສະແດງໃຫ້ເຫັນວ່າພວກເຮົາໄດ້ຮັບຄວາມຜິດພາດຫຼາຍ (ລວມທັງລະບົບເຊັ່ນການບໍ່ມີເຄືອຂ່າຍ LTE), ເຊິ່ງ "ຂີ້ເຫຍື້ອ" ຊ່ອງ Slack. ຫຼາຍເກີນໄປ, ໂດຍບໍ່ມີການກໍ່ໃຫ້ເກີດບັນຫາໃດໆ.

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

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

ການຢືນຢັນ

ມັນຍັງມີມູນຄ່າການກ່າວເຖິງວ່າ Chronograf ສະຫນັບສະຫນູນ OAuth ແລະ OIDC ເປັນການກວດສອບຄວາມຖືກຕ້ອງ.

ນີ້ແມ່ນສະດວກຫຼາຍ, ຍ້ອນວ່າມັນຊ່ວຍໃຫ້ທ່ານສາມາດຕິດມັນກັບເຄື່ອງແມ່ຂ່າຍຂອງທ່ານແລະສ້າງ SSO ເຕັມຮູບແບບ.

ໃນກໍລະນີຂອງພວກເຮົາ, ເຄື່ອງແມ່ຂ່າຍແມ່ນ ກະແຈ — ມັນ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ເຊື່ອມ​ຕໍ່​ກັບ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​, ແຕ່​ເຄື່ອງ​ແມ່​ຂ່າຍ​ດຽວ​ກັນ​ຍັງ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ກວດ​ສອບ scooters ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກັບ back-end​.

"Admin"

ອົງປະກອບສຸດທ້າຍທີ່ຂ້ອຍຈະອະທິບາຍແມ່ນ "ກະດານ admin" ທີ່ຂຽນດ້ວຍຕົນເອງຂອງພວກເຮົາໃນ Vue.
ໂດຍພື້ນຖານແລ້ວມັນເປັນພຽງແຕ່ການບໍລິການແບບດ່ຽວທີ່ສະແດງຂໍ້ມູນ scooter ຈາກຖານຂໍ້ມູນຂອງພວກເຮົາເອງ, microservices, ແລະຂໍ້ມູນ metrics ຈາກ InfluxDB ພ້ອມກັນ.

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

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

ຫນຶ່ງໃນຂໍ້ໄດ້ປຽບທີ່ໄດ້ກ່າວມາແລ້ວຂອງ Influx ແມ່ນຄວາມສາມາດໃນການສ້າງຕົວວັດແທກຂອງທ່ານເອງ.
ນີ້ອະນຸຍາດໃຫ້ມັນຖືກນໍາໃຊ້ສໍາລັບຫຼາຍໆສະຖານະການ.

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

ແນ່ນອນ, ເງື່ອນໄຂທີ່ສໍາຄັນທີ່ສຸດສໍາລັບພວກເຮົາແມ່ນສະພາບການເຮັດວຽກຂອງ scooter - ໃນຄວາມເປັນຈິງ, Influx ກວດເບິ່ງຕົວມັນເອງແລະສະແດງມັນດ້ວຍ "ໄຟສີຂຽວ" ໃນສ່ວນ Nodes.

ນີ້ແມ່ນເຮັດໄດ້ໂດຍການທໍາງານ ຜູ້​ຊາຍ​ທີ່​ຕາຍ​ແລ້ວ — ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ມັນ​ເພື່ອ​ເຂົ້າ​ໃຈ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ປ່ອງ​ຂອງ​ພວກ​ເຮົາ​ແລະ​ສົ່ງ​ການ​ແຈ້ງ​ເຕືອນ​ດຽວ​ກັນ​ກັບ Slack​.

ໂດຍວິທີທາງການ, ພວກເຮົາໄດ້ຕັ້ງຊື່ scooters ຫຼັງຈາກຊື່ຂອງຕົວລະຄອນຈາກ The Simpsons - ມັນສະດວກຫຼາຍທີ່ຈະຈໍາແນກພວກເຂົາຈາກກັນແລະກັນ.

ແລະໂດຍທົ່ວໄປມັນມ່ວນຫຼາຍດ້ວຍວິທີນີ້. ປະໂຫຍກທີ່ຄ້າຍຄື "Guys, Smithers ແມ່ນຕາຍ!" ໄດ້ຖືກໄດ້ຍິນຢ່າງຕໍ່ເນື່ອງ.

String metrics

ມັນເປັນສິ່ງສໍາຄັນທີ່ InfluxDB ຊ່ວຍໃຫ້ທ່ານສາມາດເກັບຮັກສາບໍ່ພຽງແຕ່ມູນຄ່າຕົວເລກ, ເຊັ່ນດຽວກັນກັບກໍລະນີຂອງ Victoria Metrics.

ມັນຈະເບິ່ງຄືວ່ານີ້ບໍ່ສໍາຄັນ - ຫຼັງຈາກທີ່ທັງຫມົດ, ນອກຈາກບັນທຶກ, metrics ໃດສາມາດຖືກເກັບໄວ້ໃນຮູບແບບຂອງຕົວເລກ (ພຽງແຕ່ເພີ່ມແຜນທີ່ສໍາລັບລັດທີ່ຮູ້ຈັກ - ປະເພດຂອງ enum)?

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

ດັ່ງນັ້ນ, API ການສາກໄຟແມ່ນຢູ່ໄກຈາກຄວາມເຫມາະສົມ, ແຕ່ບັນຫາຕົ້ນຕໍແມ່ນວ່າພວກເຮົາບໍ່ສາມາດເຂົ້າໃຈສະຖານະຂອງເຂົາເຈົ້າສະເຫມີ.

ນີ້ແມ່ນບ່ອນທີ່ Influx ເຂົ້າມາຊ່ວຍ. ພວກເຮົາພຽງແຕ່ຂຽນສະຖານະພາບສະຕຣິງທີ່ເຂົ້າມາຫາພວກເຮົາໃນພາກສະຫນາມຖານຂໍ້ມູນ InfluxDB ໂດຍບໍ່ມີການປ່ຽນແປງ.

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

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

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

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

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

ນີ້ແມ່ນເປັນປະໂຫຍດຫຼາຍສໍາລັບພວກເຮົາໃນເວລາທີ່ພວກເຮົາກໍາລັງຊອກຫາ scooter (ເບິ່ງບົດສະຫຼຸບໃນຕອນທ້າຍ).

ການຕິດຕາມໂຄງສ້າງພື້ນຖານ

ນອກ ເໜືອ ໄປຈາກສະກູດເຕີເອງ, ພວກເຮົາຍັງຕ້ອງການຕິດຕາມໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາທັງ ໝົດ (ຂ້ອນຂ້າງກວ້າງຂວາງ).

ສະຖາປັດຕະຍະກໍາທົ່ວໄປຫຼາຍເບິ່ງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ຖ້າພວກເຮົາເນັ້ນໃສ່ຊຸດຕິດຕາມທີ່ບໍລິສຸດ, ມັນເບິ່ງຄືວ່າ:

ສິ່ງທີ່ພວກເຮົາຢາກຈະກວດເບິ່ງຢູ່ໃນຄລາວແມ່ນ:

• ຖານຂໍ້ມູນ
• ກະແຈ
• ການບໍລິການຈຸລະພາກ

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

ໂຊກດີ, Telegraf ອອກຈາກກ່ອງສາມາດເກັບກໍາຂໍ້ມູນຈໍານວນຫລາຍກ່ຽວກັບສະຖານະຂອງກຸ່ມ Kubernetes, ແລະ Chronograf ສະເຫນີ dashboards ທີ່ສວຍງາມສໍາລັບການນີ້.

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

ມີສອງວິທີທີ່ຈະຕິດຕາມຝັກໃນ Kubernetes: DaemonSet ແລະ Sidecar.
ວິທີການທັງສອງໄດ້ຖືກອະທິບາຍຢ່າງລະອຽດ ໃນບົດຄວາມ blog ນີ້.

ພວກເຮົາໄດ້ໃຊ້ Telegraf Sidecar ແລະ, ນອກເຫນືອໄປຈາກ metrics, ເກັບກໍາຂໍ້ມູນບັນທຶກ pod.

ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງໄດ້ tinker ກັບໄມ້ທ່ອນ. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າ Telegraf ສາມາດດຶງບັນທຶກຈາກ Docker API, ພວກເຮົາຕ້ອງການໃຫ້ມີການເກັບກໍາບັນທຶກທີ່ເປັນເອກະພາບກັບອຸປະກອນສຸດທ້າຍຂອງພວກເຮົາແລະ syslog ທີ່ຖືກຕັ້ງຄ່າສໍາລັບບັນຈຸສໍາລັບການນີ້. ບາງທີການແກ້ໄຂນີ້ບໍ່ສວຍງາມ, ແຕ່ບໍ່ມີການຮ້ອງທຸກກ່ຽວກັບວຽກງານຂອງມັນແລະບັນທຶກໄດ້ຖືກສະແດງຢູ່ໃນ Chronograf.

ຕິດ​ຕາມ​ກວດ​ກາ ???

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

ເຖິງແມ່ນວ່າ Telegraf ສາມາດສົ່ງ metrics ຂອງຕົນເອງໄດ້ຢ່າງງ່າຍດາຍຫຼືເກັບກໍາ metrics ຈາກຖານຂໍ້ມູນ InfluxDB ສໍາລັບການສົ່ງກັບ Influx ດຽວກັນຫຼືບ່ອນອື່ນ.

ການຄົ້ນພົບ

ພວກເຮົາເອົາບົດສະຫຼຸບອັນໃດຈາກຜົນຂອງນັກບິນ?

ເຈົ້າສາມາດຕິດຕາມໄດ້ແນວໃດ?

ກ່ອນອື່ນ ໝົດ, TICK stack ໄດ້ບັນລຸຄວາມຄາດຫວັງຂອງພວກເຮົາຢ່າງເຕັມທີ່ແລະໃຫ້ໂອກາດພວກເຮົາຫຼາຍກ່ວາສິ່ງທີ່ພວກເຮົາຄາດຫວັງໃນເບື້ອງຕົ້ນ.

ຟັງຊັນທັງໝົດທີ່ພວກເຮົາຕ້ອງການແມ່ນມີຢູ່. ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາເຮັດກັບມັນເຮັດວຽກໂດຍບໍ່ມີບັນຫາ.

ຜະລິດຕະພັນ

ບັນຫາຕົ້ນຕໍກັບ stack TICK ໃນສະບັບຟຣີແມ່ນການຂາດຄວາມສາມາດໃນການປັບຂະຫນາດ. ນີ້ບໍ່ແມ່ນບັນຫາສໍາລັບພວກເຮົາ.

ພວກເຮົາບໍ່ໄດ້ເກັບກໍາຂໍ້ມູນການໂຫຼດທີ່ແນ່ນອນ, ແຕ່ພວກເຮົາເກັບກໍາຂໍ້ມູນຈາກປະມານ 30 scooter ໃນເວລາດຽວ.

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

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

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

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

ໃນບາງກໍລະນີ, ຖ້າການເບິ່ງບັນທຶກຍັງມີຄວາມຈໍາເປັນ, ພວກເຮົາພຽງແຕ່ເຊື່ອມຕໍ່ຜ່ານ WireGuard ຜ່ານ VPN.

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

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

TICK - ເຫມາະສໍາລັບໂຄງການຂະຫນາດນ້ອຍເຖິງຂະຫນາດກາງ

ອີງຕາມຂໍ້ມູນນີ້, ຂ້າພະເຈົ້າຈະສະຫຼຸບວ່າ stack TICK ແມ່ນເຫມາະສົມສໍາລັບໂຄງການຂະຫນາດນ້ອຍຫຼືໂຄງການທີ່ແນ່ນອນວ່າບໍ່ຄາດວ່າຈະມີ HighLoad.

ຖ້າທ່ານບໍ່ມີຝັກຫຼາຍພັນຫຼືຫຼາຍຮ້ອຍເຄື່ອງ, ເຖິງແມ່ນວ່າ InfluxDB ໂຕດຽວຈະຈັດການການໂຫຼດໄດ້ດີ.

ໃນບາງກໍລະນີ, ທ່ານອາດຈະພໍໃຈກັບ Influx Relay ເປັນການແກ້ໄຂການມີຢູ່ສູງ primitive.

ແລະ, ແນ່ນອນ, ບໍ່ມີໃຜຂັດຂວາງທ່ານຈາກການຕັ້ງຄ່າ "ຕັ້ງ" ຂະຫນາດແລະພຽງແຕ່ຈັດສັນເຄື່ອງແມ່ຂ່າຍທີ່ແຕກຕ່າງກັນສໍາລັບປະເພດທີ່ແຕກຕ່າງກັນຂອງ metrics.

ຖ້າທ່ານບໍ່ແນ່ໃຈກ່ຽວກັບການໂຫຼດທີ່ຄາດວ່າຈະຢູ່ໃນການບໍລິການຕິດຕາມ, ຫຼືທ່ານຮັບປະກັນວ່າມີ / ຈະມີສະຖາປັດຕະຍະກໍາ "ຫນັກ", ຂ້າພະເຈົ້າບໍ່ແນະນໍາໃຫ້ໃຊ້ TICK stack ສະບັບຟຣີ.

ແນ່ນອນ, ການແກ້ໄຂງ່າຍໆແມ່ນການຊື້ ບໍລິສັດ InfluxDB - ແຕ່ໃນທີ່ນີ້ຂ້າພະເຈົ້າບໍ່ສາມາດໃຫ້ຄໍາເຫັນ somehow, ເນື່ອງຈາກວ່າຂ້າພະເຈົ້າເອງບໍ່ຄຸ້ນເຄີຍກັບ subtleties. ນອກຈາກຄວາມຈິງທີ່ວ່າມັນມີລາຄາແພງຫຼາຍແລະແນ່ນອນບໍ່ເຫມາະສົມສໍາລັບບໍລິສັດຂະຫນາດນ້ອຍ.

ໃນກໍລະນີນີ້, ມື້ນີ້, ຂ້າພະເຈົ້າຈະແນະນໍາໃຫ້ຊອກຫາການເກັບກໍາ metrics ຜ່ານ Victoria Metrics ແລະບັນທຶກການນໍາໃຊ້ Loki.

ແທ້ຈິງແລ້ວ, ຂ້ອຍຈະຈອງອີກວ່າ Loki/Grafana ມີຄວາມສະດວກສະບາຍຫນ້ອຍຫຼາຍ (ເນື່ອງຈາກຄວາມຄ່ອງແຄ້ວຂອງພວກເຂົາ) ຫຼາຍກວ່າ TICK ທີ່ກຽມພ້ອມ, ແຕ່ພວກມັນແມ່ນບໍ່ເສຍຄ່າ.

ທີ່ສໍາຄັນ: ຂໍ້ມູນທັງໝົດທີ່ອະທິບາຍຢູ່ນີ້ແມ່ນມີຄວາມກ່ຽວຂ້ອງສຳລັບລຸ້ນ Influx 1.8, ໃນຂະນະນີ້ Influx 2.0 ກຳລັງຈະອອກມາ.

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

ຟັງຊັນນີ້ຍັງຈະປາກົດຢູ່ໃນ Influx 2.0, ແຕ່ພວກເຮົາບໍ່ສາມາດຊອກຫາກໍານົດເວລາກໍານົດ, ແມ່ນແຕ່ປະມານ.

ວິທີການບໍ່ສ້າງເວທີ IoT (ຕອນນີ້)

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

ຢ່າງໃດກໍຕາມ, ບໍ່ດົນມານີ້, ມັນມີຢູ່ໃນສະບັບ Beta OpenBalena — ມັນ​ເປັນ​ການ​ເສຍ​ໃຈ​ທີ່​ນາງ​ບໍ່​ໄດ້​ຢູ່​ໃນ​ເວ​ລາ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ເຮັດ​ໂຄງ​ການ​.

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

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

ມັນຮູ້ແລ້ວວ່າບໍ່ພຽງແຕ່ສົ່ງການອັບເດດເທົ່ານັ້ນ, ແຕ່ຍັງມີ VPN ຢູ່ໃນຕົວແລະເຫມາະສົມກັບການນໍາໃຊ້ໃນສະພາບແວດລ້ອມ IoT.

ແລະພຽງແຕ່ບໍ່ດົນມານີ້, ພວກເຂົາເຈົ້າເຖິງແມ່ນວ່າປ່ອຍຂອງເຂົາເຈົ້າ ອຸປະກອນ, ເຊິ່ງໄດ້ຢ່າງງ່າຍດາຍເຊື່ອມຕໍ່ກັບລະບົບນິເວດຂອງເຂົາເຈົ້າ.

Hey, ສິ່ງທີ່ກ່ຽວກັບ scooter ຫາຍໄປ?

ດັ່ງນັ້ນ scooter, "Ralph", ຫາຍໄປໂດຍບໍ່ມີຮ່ອງຮອຍ.

ພວກ​ເຮົາ​ໄດ້​ແລ່ນ​ໄປ​ເບິ່ງ​ແຜນ​ທີ່​ໃນ “ຄະ​ນະ​ບໍ​ລິ​ຫານ” ຂອງ​ພວກ​ເຮົາ​ໃນ​ທັນ​ທີ, ດ້ວຍ​ຂໍ້​ມູນ GPS metrics ຈາກ InfluxDB.

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

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

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

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

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

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