නැතිවූ ස්කූටරයක් ​​හෝ එක් IoT නිරීක්ෂණ කථාවක් ආපසු ලබා දෙන්න

වසරකට පෙර අපි ප්‍රවර්ධන ව්‍යාපෘතියක නියමු අනුවාදයක් දියත් කළෙමු විදුලි ස්කූටර විමධ්‍යගත කුලියට දීම.

මුලදී, මෙම ව්‍යාපෘතිය Road-to-Barcelona ලෙස හැඳින්වූ අතර පසුව එය Road-to-Berlin (එබැවින් R2B තිරපිටපත්වල) බවට පත් වූ අතර අවසානයේ එය xRide ලෙස නම් කරන ලදී.

ව්‍යාපෘතියේ ප්‍රධාන අදහස වූයේ මෙයයි: මධ්‍යගත කාර් හෝ ස්කූටර් කුලියට දෙන සේවාවක් වෙනුවට (අපි කතා කරන්නේ ස්කූටර හෙවත් විදුලි යතුරුපැදි ගැන මිස කික්ස්කූටර්/ස්කූටර් ගැන නොවේ) විමධ්‍යගත කුලියට ගැනීම සඳහා වේදිකාවක් සෑදීමට අපට අවශ්‍ය විය. අපි මුහුණ දුන් දුෂ්කරතා ගැන දැනටමත් කලින් ලියා ඇත.

මුලදී, ව්‍යාපෘතිය මෝටර් රථ කෙරෙහි අවධානය යොමු කළ නමුත් නියමිත කාලසීමාවන්, නිෂ්පාදකයින් සමඟ අතිශයින්ම දිගු සන්නිවේදනයන් සහ විශාල ආරක්ෂක සීමාවන් හේතුවෙන් නියමුවා සඳහා විදුලි ස්කූටර් තෝරා ගන්නා ලදී.

පරිශීලකයා දුරකථනයේ iOS හෝ Android යෙදුමක් ස්ථාපනය කර, ඔහු කැමති ස්කූටරය වෙත ළඟා විය, පසුව දුරකථනය සහ ස්කූටරය සම-සම සම්බන්ධතාවයක් ඇති කර, ETH හුවමාරු කර ගත් අතර පරිශීලකයාට ස්කූටරය ක්‍රියාත්මක කිරීමෙන් ගමන ආරම්භ කළ හැකිය. දුරකථනය. සංචාරය අවසානයේදී, දුරකථනයේ පරිශීලකයාගේ මුදල් පසුම්බියෙන් Ethereum භාවිතයෙන් සංචාරය සඳහා ගෙවීමටද හැකි විය.

ස්කූටර වලට අමතරව, පරිශීලකයා යෙදුමේ “ස්මාර්ට් චාජර්” දුටුවේය, එය නැරඹීමෙන් පරිශීලකයාට වත්මන් බැටරිය අඩු නම් එය වෙනස් කළ හැකිය.

සාමාන්‍යයෙන් අපගේ නියමුවා පෙනුනේ මෙයයි, පසුගිය වසරේ සැප්තැම්බර් මාසයේදී ජර්මානු නගර දෙකකින් දියත් කරන ලදී: බොන් සහ බර්ලින්.

ඉන්පසුව, දිනක්, බොන්හිදී, උදේ පාන්දර, අපගේ සහායක කණ්ඩායම (ස්කූටර ක්‍රියාකාරී පිළිවෙලට නඩත්තු කිරීම සඳහා වෙබ් අඩවියේ පිහිටා ඇත) අනතුරු ඇඟවීය: එක් ස්කූටරයක් ​​හෝඩුවාවක් නොමැතිව අතුරුදහන් විය.

එය සොයාගෙන එය ආපසු ලබා දෙන්නේ කෙසේද?

මෙම ලිපියෙන් මම මේ ගැන කතා කරමි, නමුත් පළමුව - අපි අපේම IoT වේදිකාවක් ගොඩනඟා ගත් ආකාරය සහ අපි එය නිරීක්ෂණය කළ ආකාරය ගැන.

නිරීක්ෂණය කළ යුත්තේ කුමක්ද සහ ඇයි: ස්කූටර්, යටිතල පහසුකම්, ආරෝපණ ස්ථාන?

ඉතින්, අපගේ ව්‍යාපෘතිය තුළ අපට නිරීක්ෂණය කිරීමට අවශ්‍ය වූයේ කුමක්ද?

පළමුවෙන්ම, මේවා ස්කූටර වේ - විදුලි ස්කූටර තරමක් මිල අධිකයි, ප්‍රමාණවත් ලෙස සූදානම් නොවී ඔබට එවැනි ව්‍යාපෘතියක් දියත් කළ නොහැක; හැකි නම්, ඔබට ස්කූටර පිළිබඳ හැකි තරම් තොරතුරු රැස් කිරීමට අවශ්‍ය වේ: ඒවායේ පිහිටීම, ආරෝපණ මට්ටම ගැන , ආදිය.

ඊට අමතරව, අපගේම තොරතුරු තාක්ෂණ යටිතල පහසුකම් - දත්ත සමුදායන්, සේවා සහ ඒවාට වැඩ කිරීමට අවශ්‍ය සියල්ල නිරීක්ෂණය කිරීමට මම කැමතියි. "ස්මාර්ට් චාජර්" වල තත්ත්වය නිරීක්ෂණය කිරීම ද අවශ්ය විය, ඒවා බිඳ වැටුණහොත් හෝ සම්පූර්ණ බැටරිය අවසන් විය.

ස්කූටර්

අපගේ ස්කූටර් මොනවාද සහ අපට ඒවා ගැන දැන ගැනීමට අවශ්‍ය වූයේ කුමක්ද?

පළමු හා වැදගත්ම දෙය වන්නේ ජීපීඑස් ඛණ්ඩාංක වේ, මන්ද ඔවුන්ට ස්තූතිවන්ත වන බැවින් ඒවා කොතැනද සහ ඔවුන් ගමන් කරන්නේ කොතැනද යන්න අපට තේරුම් ගත හැකිය.

ඊළඟට බැටරි ආරෝපණය වේ, ස්කූටර ආරෝපණය කිරීම අවසන් වන බව අපට තීරණය කළ හැකි අතර, ජූසර් යැවීම හෝ අවම වශයෙන් පරිශීලකයාට අනතුරු ඇඟවීමක් කළ හැකිය.

ඇත්ත වශයෙන්ම, අපගේ දෘඩාංග සංරචක සමඟ සිදුවන්නේ කුමක්ද යන්න පරීක්ෂා කිරීම ද අවශ්‍ය වේ:

• බ්ලූටූත් වැඩ කරනවද?
• GPS මොඩියුලයම ක්‍රියා කරයිද?
  • GPS මඟින් වැරදි ඛණ්ඩාංක යවා සිරවීමට හැකි වීමත් අපට ගැටලුවක් වූ අතර මෙය තීරණය කළ හැක්කේ ස්කූටරයේ අමතර චෙක්පත් මගින් පමණි.
    සහ ගැටලුව විසඳීමට හැකි ඉක්මනින් සහාය දැනුම් දෙන්න

සහ අවසාන වශයෙන්: මෘදුකාංගයේ චෙක්පත්, මෙහෙයුම් පද්ධතිය සහ ප්‍රොසෙසරය, ජාල සහ තැටි පැටවීම, අපට වඩාත් විශේෂිත වූ අපගේම මොඩියුලවල චෙක්පත් වලින් අවසන් වේ (ජොලොකොම්, යතුරු පුවරුව).

දෘඩාංග

අපගේ "යකඩ" කොටස කුමක්ද?

හැකි කෙටිම කාල රාමුව සහ වේගවත් මූලාකෘතිකරණයේ අවශ්‍යතාවය සැලකිල්ලට ගනිමින්, අපි ක්‍රියාත්මක කිරීම සහ සංරචක තෝරා ගැනීම සඳහා පහසුම විකල්පය තෝරා ගත්තෙමු - Raspberry Pi.
Rpi වලට අමතරව, අපට අභිරුචි පුවරුවක් (අවසාන විසඳුමේ එකලස් කිරීමේ ක්‍රියාවලිය වේගවත් කිරීම සඳහා අප විසින්ම සංවර්ධනය කර චීනයෙන් ඇණවුම් කරන ලද) සහ සංරචක කට්ටලයක් - රිලේ (ස්කූටරය සක්‍රිය / අක්‍රිය කිරීමට), බැටරි ආරෝපණ කියවනය, මොඩමයක්, ඇන්ටනා. මේ සියල්ල විශේෂ "xRide පෙට්ටියක" සංයුක්තව ඇසුරුම් කර ඇත.

සමස්ත පෙට්ටියම අතිරේක බලශක්ති බැංකුවකින් බල ගැන්වූ අතර එය ස්කූටරයේ ප්‍රධාන බැටරියෙන් බල ගැන්වූ බව ද සඳහන් කළ යුතුය.

ජ්වලන යතුර “අක්‍රිය” ස්ථානයට හැරීමෙන් පසු ප්‍රධාන බැටරිය ක්‍රියා විරහිත වූ බැවින්, සංචාරය අවසන් වූ පසුව පවා නිරීක්ෂණ භාවිතා කිරීමට සහ ස්කූටරය ක්‍රියාත්මක කිරීමට මෙය හැකි විය.

ඩොකර්? සරල ලිනක්ස්? සහ යෙදවීම

අපි නැවත නිරීක්ෂණයට යමු, ඉතින් Raspberry - අපට ඇත්තේ කුමක්ද?

භෞතික උපාංග වෙත සංරචක යෙදවීම, යාවත්කාලීන කිරීම සහ බෙදා හැරීමේ ක්‍රියාවලිය වේගවත් කිරීම සඳහා අපට භාවිතා කිරීමට අවශ්‍ය වූ පළමු දෙය වූයේ ඩොකර් ය.

අවාසනාවකට මෙන්, RPi හි ඩොකර්, එය ක්‍රියා කළද, විශේෂයෙන් බලශක්ති පරිභෝජනය අනුව, බොහෝ පොදු කාර්ය ඇති බව ඉක්මනින් පැහැදිලි විය.

"ස්වදේශීය" OS භාවිතා කරන වෙනස, එතරම් ශක්තිමත් නොවූවත්, ඉක්මනින් ආරෝපණය අහිමි වීමේ හැකියාව ගැන සැලකිලිමත් වීමට අපට තවමත් ප්රමාණවත් විය.

දෙවන හේතුව වූයේ Node.js හි අපගේ හවුල්කාර පුස්තකාලයකි (sic!) - Go/C/C++ හි ලියා නැති පද්ධතියේ එකම සංරචකය.

පුස්තකාලයේ කතුවරුන්ට කිසිදු "ස්වදේශීය" භාෂාවකින් වැඩ කරන අනුවාදයක් සැපයීමට කාලය නොතිබුණි.

අඩු කාර්ය සාධන උපාංග සඳහා නෝඩය වඩාත්ම අලංකාර විසඳුම නොවනවා පමණක් නොව, පුස්තකාලයම ඉතා සම්පත්-කුසගිනි විය.

අපට අවශ්‍ය වුවද, ඩොකර් භාවිතා කිරීම අපට අධික වියදමක් වන බව අපට වැටහුණි. තේරීම දේශීය මෙහෙයුම් පද්ධතියට පක්ෂව සිදු කර ඇති අතර එය යටතේ කෙලින්ම ක්‍රියා කරයි.

OS

එහි ප්රතිඵලයක් වශයෙන්, අපි නැවතත්, මෙහෙයුම් පද්ධතිය ලෙස සරලම විකල්පය තෝරාගෙන Raspbian (පයි සඳහා ඩේබියන් ගොඩනැගීම) භාවිතා කළෙමු.

අපි අපගේ සියලුම මෘදුකාංග Go හි ලියන්නෙමු, එබැවින් අපි අපගේ පද්ධතියේ ප්‍රධාන දෘඩාංග නියෝජිත මොඩියුලයද Go හි ලිව්වෙමු.

ජීපීඑස්, බ්ලූටූත් සමඟ වැඩ කිරීම, ආරෝපණය කියවීම, ස්කූටරය ක්‍රියාත්මක කිරීම යනාදිය සඳහා වගකිව යුත්තේ ඔහුය.

යොදවන්න

උපාංග (OTA) වෙත යාවත්කාලීන ලබා දීමේ යාන්ත්‍රණයක් ක්‍රියාත්මක කිරීමේ අවශ්‍යතාවය පිළිබඳ ප්‍රශ්නය වහාම පැන නැගුනි - අපගේ නියෝජිතයා/යෙදුම වෙතම යාවත්කාලීන කිරීම් සහ OS/firmware වෙතම යාවත්කාලීන කිරීම් යන දෙකම (නියෝජිතයාගේ නව අනුවාද සඳහා කර්නලයට යාවත්කාලීන අවශ්‍ය විය හැකි බැවින්. හෝ පද්ධති සංරචක, පුස්තකාල, ආදිය) .

වෙළඳපල පිළිබඳ තරමක් දිගු විශ්ලේෂණයකින් පසුව, උපාංගයට යාවත්කාලීන කිරීම් ලබා දීම සඳහා විසඳුම් රාශියක් ඇති බව පෙනී ගියේය.

swupd/SWUpdate/OSTree වැනි සාපේක්ෂ සරල, බොහෝ දුරට යාවත්කාලීන/ද්විත්ව-ආරම්භක උපයෝගිතා සිට Mender සහ Balena වැනි අංග සම්පූර්ණ වේදිකා දක්වා.

පළමුවෙන්ම, අපි අවසානයේ සිට අවසානය දක්වා විසඳුම් සඳහා උනන්දුවක් දක්වන බව අපි තීරණය කළෙමු, එබැවින් තේරීම වහාම වේදිකාවලට වැටුණි.

ඇය බැලෙනා එය ඇත්ත වශයෙන්ම එහි balenaEngine තුළ එකම ඩොකර් භාවිතා කරන නිසා බැහැර කරන ලදී.

නමුත් මෙය තිබියදීත්, අපි ඔවුන්ගේ නිෂ්පාදනය නිරන්තරයෙන් භාවිතා කළ බව මම සටහන් කරමි බැලෙනා එචර් SD කාඩ්පත් මත ෆ්ලෑෂ් ස්ථිරාංග සඳහා - මේ සඳහා සරල සහ අතිශයින්ම පහසු උපයෝගීතාවයක්.

එමනිසා, අවසානයේ තේරීම මත වැටුණි මෙන්ඩර්. මැන්ඩර් යනු ස්ථිරාංග එකලස් කිරීම, බෙදා හැරීම සහ ස්ථාපනය කිරීම සඳහා සම්පූර්ණ වේදිකාවකි.

සමස්තයක් ලෙස වේදිකාව ඉතා හොඳ පෙනුමක් ඇති නමුත්, මැන්ඩර් බිල්ඩර් භාවිතයෙන් අපගේ ස්ථිරාංගයේ නිවැරදි අනුවාදය සෑදීමට අපට සති එකහමාරක් පමණ ගත විය.
තවද එහි භාවිතයේ ඇති සංකීර්ණතා තුළ අප ගිලී ගිය තරමට, එය සම්පූර්ණයෙන්ම යෙදවීමට අපට තිබූ කාලයට වඩා බොහෝ කාලයක් අවශ්‍ය වන බව පැහැදිලි විය.

අහෝ, අපගේ දැඩි කාල සීමාවන් නිසා අපට මෙන්ඩර් භාවිතය අත්හැර ඊටත් වඩා සරල එකක් තෝරා ගැනීමට අපට බල කෙරුනි.

පිළිතුරු

අපගේ තත්වය තුළ ඇති සරලම විසඳුම වූයේ Ansible භාවිතා කිරීමයි. ආරම්භ කිරීමට ක්‍රීඩා පොත් කිහිපයක් ප්‍රමාණවත් විය.

ඔවුන්ගේ සාරය වූයේ අපි සරලවම ධාරකයෙන් (CI සේවාදායකය) ssh හරහා අපගේ රාස්බෙරි වෙත සම්බන්ධ කර ඒවාට යාවත්කාලීන බෙදා හැරීමයි.

ආරම්භයේදීම, සෑම දෙයක්ම සරලයි - ඔබට උපාංග සමඟ එකම ජාලයක සිටිය යුතුය, වත් කිරීම Wi-Fi හරහා සිදු කරන ලදී.

කාර්යාලයේ එකම ජාලයකට සම්බන්ධ වූ පරීක්ෂණ රාස්ප්බෙරි දුසිමක් තිබුණි, සෑම උපාංගයකම ස්ථිතික IP ලිපිනයක් ද Ansible Inventory හි දක්වා ඇත.

අපගේ අධීක්ෂණ නියෝජිතයා අවසාන උපාංග වෙත ලබා දුන්නේ Ansible විසිනි

3G / LTE

අවාසනාවකට මෙන්, ඇන්සිබල් සඳහා මෙම භාවිත අවස්ථාව ක්‍රියා කළ හැක්කේ අපට සැබෑ ස්කූටර ලබා ගැනීමට පෙර සංවර්ධන මාදිලියේ පමණි.

මන්ද ස්කූටර, ඔබ තේරුම් ගත් පරිදි, එක් Wi-Fi රවුටරයකට සම්බන්ධ වී නොසිටින අතර, ජාලය හරහා යාවත්කාලීන කිරීම් සඳහා නිරන්තරයෙන් බලා සිටියි.

ඇත්ත වශයෙන්ම, ස්කූටරවලට ජංගම 3G/LTE හැර වෙනත් කිසිම සම්බන්ධතාවයක් තිබිය නොහැක (එවිට පවා සෑම විටම නොවේ).

මෙය වහාම අඩු සම්බන්ධතා වේගය සහ අස්ථායී සන්නිවේදනය වැනි බොහෝ ගැටළු සහ සීමාවන් පැනවේ.

නමුත් වැදගත්ම දෙය නම් 3G/LTE ජාලයකදී අපට ජාලයට පවරා ඇති ස්ථිතික IP එකක් මත විශ්වාසය තැබිය නොහැකි වීමයි.

සමහර SIM කාඩ්පත් සපයන්නන් විසින් මෙය අර්ධ වශයෙන් විසඳනු ලැබේ; ස්ථිතික IP ලිපින සහිත IoT උපාංග සඳහා නිර්මාණය කර ඇති විශේෂ SIM කාඩ්පත් පවා තිබේ. නමුත් අපට එවැනි සිම් කාඩ්පත් සඳහා ප්‍රවේශය නොතිබූ අතර IP ලිපින භාවිතා කිරීමට නොහැකි විය.

ඇත්ත වශයෙන්ම, කොන්සල් වැනි කොතැනක හෝ IP ලිපින ලියාපදිංචි කිරීමක් හෝ සේවා සොයාගැනීමක් කිරීමට අදහස් තිබුණි, නමුත් එවැනි අදහස් අත්හැරීමට සිදු විය, මන්ද අපගේ පරීක්ෂණ වලදී IP ලිපිනය බොහෝ විට වෙනස් විය හැකි බැවින් එය විශාල අස්ථාවරත්වයට හේතු විය.

මේ හේතුව නිසා, ප්‍රමිතික ලබා දීම සඳහා වඩාත් පහසු භාවිතය වන්නේ ඇදීමේ ආකෘතිය භාවිතා කිරීම නොවේ, එහිදී අපි අවශ්‍ය ප්‍රමිතික සඳහා උපාංග වෙත යමු, නමුත් තල්ලු කිරීම, උපාංගයෙන් ප්‍රමිතික කෙලින්ම සේවාදායකයට ලබා දීම

අතාත්වික පෞද්ගලික ජාලය

මෙම ගැටලුවට විසඳුමක් ලෙස, අපි VPN - විශේෂයෙන් තෝරා ගත්තෙමු වයර්ගාඩ්.

VPN සේවාදායකයට සම්බන්ධ වී ඇති පද්ධතියේ ආරම්භයේ සේවාදායකයන් (ස්කූටර්) සහ ඒවාට සම්බන්ධ වීමට හැකි විය. මෙම උමග යාවත්කාලීන ලබා දීමට භාවිතා කරන ලදී.

න්‍යායාත්මකව, නිරීක්ෂණය සඳහා එකම උමග භාවිතා කළ හැකි නමුත් එවැනි සම්බන්ධතාවයක් සරල තල්ලුවකට වඩා සංකීර්ණ සහ අඩු විශ්වාසදායක විය.

වලාකුළු සම්පත්

අවසාන වශයෙන්, අපගේ වලාකුළු සේවා සහ දත්ත සමුදායන් නිරීක්ෂණය කිරීම අවශ්‍ය වේ, අපි ඒවා සඳහා Kubernetes භාවිතා කරන බැවින්, ඉතා මැනවින්, පොකුරේ අධීක්ෂණය යෙදවීම හැකි තරම් සරල ය. ඉතා මැනවින්, භාවිතා කිරීම හෙල්ම්, යෙදවීම සඳහා, අපි එය බොහෝ අවස්ථාවලදී භාවිතා කරමු. තවද, ඇත්ත වශයෙන්ම, වලාකුළ නිරීක්ෂණය කිරීම සඳහා, ඔබ ස්කූටර සඳහා සමාන විසඳුම් භාවිතා කළ යුතුය.

ලබා දී ඇත

පිව්, අපි විස්තරය නිරාකරණය කර ඇති බව පෙනේ, අවසානයේ අපට අවශ්‍ය දේ ලැයිස්තුවක් සාදන්න:

• සංවර්ධන ක්‍රියාවලියේදී දැනටමත් අධීක්ෂණය අවශ්‍ය බැවින් ඉක්මන් විසඳුමක්
• පරිමාව/ප්‍රමාණය - බොහෝ ප්‍රමිතික අවශ්‍යයි
• ලඝු-සටහන් එකතු කිරීම අවශ්ය වේ
• විශ්වසනීයත්වය - සාර්ථකත්වය දියත් කිරීම සඳහා දත්ත ඉතා වැදගත් වේ
• ඔබට අදින්න ආකෘතිය භාවිතා කළ නොහැක - ඔබට තල්ලු කිරීම අවශ්ය වේ
• අපට දෘඩාංග පමණක් නොව වලාකුළු ද ඒකාබද්ධ අධීක්ෂණය අවශ්‍ය වේ

අවසාන රූපය මේ වගේ දෙයක්

තොග තේරීම

එබැවින්, අධීක්ෂණ තොගයක් තෝරා ගැනීමේ ප්‍රශ්නයට අපට මුහුණ දීමට සිදු විය.

පළමුවෙන්ම, අපි අපේ අවශ්‍යතා සමගාමීව ආවරණය කරන, නමුත් ඒ සමඟම අපගේ අවශ්‍යතාවලට අනුව එහි භාවිතය සකස් කර ගැනීමට තරම් නම්‍යශීලී විය හැකි වඩාත් සම්පූර්ණ සියල්ලෙන් එක විසඳුමක් සොයමින් සිටියෙමු. තවමත්, දෘඩාංග, ගෘහ නිර්මාණ ශිල්පය සහ නියමිත කාලසීමාවන් මගින් අපට බොහෝ සීමාවන් පනවා තිබුණි.

වැනි අංගසම්පූර්ණ පද්ධති වලින් ආරම්භ වන අධීක්ෂණ විසඳුම් විශාල ප්‍රමාණයක් ඇත නයිජීස්, අයිසිංගා හෝ zabbix සහ Fleet කළමනාකරණය සඳහා සූදානම් කළ විසඳුම් සමඟ අවසන් වේ.

මුලදී, දෙවැන්න අපට කදිම විසඳුමක් ලෙස පෙනුනද, සමහරුන්ට පූර්ණ අධීක්ෂණයක් නොතිබුණි, අනෙක් අයට නිදහස් අනුවාදවල දැඩි ලෙස සීමිත හැකියාවන් තිබුණි, තවත් සමහරු අපගේ “අවශ්‍යතා” ආවරණය නොකළ හෝ අපගේ අවස්ථා වලට ගැලපෙන තරම් නම්‍යශීලී නොවීය. සමහර ඒවා යල් පැන ගිය ඒවා.

සමාන විසඳුම් ගණනාවක් විශ්ලේෂණය කිරීමෙන් පසුව, සමාන තොගයක් අප විසින්ම එකලස් කිරීම පහසු සහ වේගවත් බව අපි ඉක්මනින් නිගමනය කළෙමු. ඔව්, එය සම්පූර්ණයෙන්ම සූදානම් Fleet කළමනාකරණ වේදිකාවක් යෙදවීමට වඩා ටිකක් සංකීර්ණ වනු ඇත, නමුත් අපට සම්මුතීන් ඇති කර ගැනීමට සිදු නොවනු ඇත.

නිසැකවම, සියලු විසඳුම් විශාල ප්‍රමාණයක් තුළ, අපට සම්පූර්ණයෙන්ම ගැලපෙන සූදානම් කළ එකක් දැනටමත් ඇත, නමුත් අපගේ නඩුවේදී, යම් තොගයක් අප විසින්ම එකලස් කර එය “අප වෙනුවෙන්ම” අභිරුචිකරණය කිරීම වඩා වේගවත් විය. සූදානම් කළ නිෂ්පාදන පරීක්ෂා කිරීම.

මේ සියල්ල සමඟ, අපි සම්පූර්ණ අධීක්ෂණ වේදිකාවක් අප විසින්ම එකලස් කිරීමට උත්සාහ නොකළෙමු, නමුත් වඩාත් ක්‍රියාකාරී “සූදානම් කළ” අට්ටි සොයමින් සිටියේ ඒවා නම්‍යශීලීව වින්‍යාස කිරීමේ හැකියාවෙන් පමණි.

(ආ) ELK?

ඇත්ත වශයෙන්ම සලකා බැලූ පළමු විසඳුම වූයේ සුප්රසිද්ධ ELK තොගයයි.
ඇත්ත වශයෙන්ම, එය BELK ලෙස හැඳින්විය යුතුය, මන්ද එය ආරම්භ වන්නේ Beats වලින් - https://www.elastic.co/what-is/elk-stack

ඇත්ත වශයෙන්ම, ELK යනු අධීක්ෂණ ක්ෂේත්‍රයේ වඩාත් ප්‍රසිද්ධ සහ ප්‍රබල විසඳුම්වලින් එකක් වන අතර, ඊටත් වඩා ලඝු-සටහන් එකතු කිරීම සහ සැකසීම.

ප්‍රොමිතියස් වෙතින් ලබාගත් ප්‍රමිතික දිගුකාලීන ගබඩා කිරීමට මෙන්ම ලඝු-සටහන් එකතු කිරීමට ELK භාවිතා කිරීමට අපි අදහස් කළෙමු.

දෘශ්යකරණය සඳහා ඔබට Grafan භාවිතා කළ හැකිය.

ඇත්ත වශයෙන්ම, නව ELK තොගයට ප්‍රමිතික ස්වාධීනව (metricbeat) එකතු කළ හැකි අතර, Kibana හට ද ඒවා ප්‍රදර්ශනය කළ හැක.

නමුත් තවමත්, ELK මුලින් ලොග් වලින් වර්ධනය වූ අතර මෙතෙක් ප්‍රමිතික වල ක්‍රියාකාරිත්වයට බරපතල අඩුපාඩු ගණනාවක් තිබේ:

• Prometheus ට වඩා සැලකිය යුතු ලෙස මන්දගාමී වේ
• Prometheus වලට වඩා ඉතා අඩු ස්ථාන වලට ඒකාබද්ධ වේ
• ඔවුන් සඳහා ඇඟවීම් සැකසීම දුෂ්කර ය
• Metrics විශාල ඉඩක් ගනී
• Kiban හි ප්‍රමිතික සමඟ උපකරණ පුවරු සැකසීම ග්‍රැෆාන් වලට වඩා බෙහෙවින් සංකීර්ණ වේ

සාමාන්‍යයෙන්, ELK හි ප්‍රමිතික බර වන අතර වෙනත් විසඳුම්වල මෙන් තවමත් පහසු නැත, ඒවායින් දැන් ප්‍රොමිතියස් වලට වඩා බොහෝ දේ ඇත: TSDB, වික්ටෝරියා මෙට්‍රික්ස්, කෝටෙක්ස්, ආදිය. ඇත්ත වශයෙන්ම, මම සම්පුර්ණයෙන්ම සම්පූර්ණ විසඳුමක් ලබා ගැනීමට කැමැත්තෙමි, නමුත් මෙට්‍රික්බීට් සම්බන්ධයෙන් බොහෝ සම්මුතීන් තිබුණි.

ELK තොගයටම දුෂ්කර අවස්ථා ගණනාවක් ඇත:

• ඔබ තරමක් විශාල දත්ත ප්‍රමාණයක් එකතු කළහොත් එය බරයි, සමහර විට ඉතා බරයි
• ඔබ එය “උයන්නේ කෙසේදැයි දැන සිටිය යුතුය” - ඔබ එය පරිමාණය කළ යුතුය, නමුත් මෙය කිරීම සුළුපටු නොවේ
• ඉවත් කරන ලද නිදහස් අනුවාදය - නිදහස් අනුවාදයේ සාමාන්‍ය අනතුරු ඇඟවීමක් නොමැති අතර, තෝරා ගන්නා අවස්ථාවේ සත්‍යාපනයක් නොතිබුණි

මෑතකදී අවසාන කරුණ වඩා හොඳ වී ඇති බව මම පැවසිය යුතුයි open-source X-pack හි ප්‍රතිදානය (සත්‍යාපනය ඇතුළුව) මිලකරණ ආකෘතියම වෙනස් වීමට පටන් ගත්තේය.

නමුත් අපි මෙම විසඳුම යෙදවීමට යන අවස්ථාවේ කිසිදු අනතුරු ඇඟවීමක් නොතිබුණි.
සමහර විට අපට ElastAlert හෝ වෙනත් ප්‍රජා විසඳුම් භාවිතයෙන් යමක් ගොඩනඟා ගැනීමට උත්සාහ කළ හැකි නමුත්, අපි තවමත් වෙනත් විකල්ප සලකා බැලීමට තීරණය කළෙමු.

Loki - Grafana - Prometheus

මේ මොහොතේ, හොඳ විසඳුමක් වනුයේ ප්‍රමිතික සපයන්නෙකු ලෙස Prometheus මත පදනම් වූ අධීක්ෂණ තොගයක් ගොඩනැගීම, ලඝු-සටහන් සඳහා Loki සහ දෘශ්‍යකරණය සඳහා ඔබට එම Grafana භාවිතා කළ හැකිය.

අවාසනාවකට මෙන්, ව්‍යාපෘතියේ විකුණුම් නියමුවා ආරම්භ වන විට (සැප්තැම්බර්-ඔක්තෝබර් 19), Loki තවමත් බීටා අනුවාදය 0.3-0.4 හි සිටි අතර, සංවර්ධනය ආරම්භ වන විට එය නිෂ්පාදන විසඳුමක් ලෙස සැලකිය නොහැක. කොහෙත්ම.

ඇත්තටම බරපතල ව්‍යාපෘති වල Loki භාවිතා කිරීමේ අත්දැකීම මට තවම නැත, නමුත් මට කියන්න පුළුවන් Promtail (ලඝු-සටහන් එකතු කිරීමේ නියෝජිතයෙක්) kubernetes හි හිස්-ලෝහ සහ කරල් යන දෙකටම විශිෂ්ට ලෙස ක්‍රියා කරන බව.

ටික් කරන්න

සමහර විට ELK තොගයට වඩාත්ම වටිනා (එකම?) සම්පූර්ණ-විශේෂාංග විකල්පය දැන් TICK තොගය ලෙස හැඳින්විය හැක - Telegraf, InfluxDB, Chronograf, Kapacitor.

මම පහත සියලුම සංරචක වඩාත් විස්තරාත්මකව විස්තර කරමි, නමුත් සාමාන්‍ය අදහස මෙයයි:

• ටෙලිග්‍රාෆ් - ප්‍රමිතික එකතු කිරීමේ නියෝජිතයා
• InfluxDB - ප්‍රමිතික දත්ත සමුදාය
• Kapacitor - අනතුරු ඇඟවීම සඳහා තත්‍ය කාලීන මෙට්‍රික් ප්‍රොසෙසරය
• Chronograf - දෘශ්‍යකරණය සඳහා වෙබ් පැනලය

InfluxDB, Kapacitor සහ Chronograf සඳහා අපි ඒවා යෙදවීමට භාවිතා කළ නිල හෙල්ම් ප්‍රස්ථාර තිබේ.

Influx 2.0 (beta) හි නවතම අනුවාදයේ, Kapacitor සහ Chronograf InfluxDB හි කොටසක් බවට පත් වූ අතර තවදුරටත් වෙන වෙනම නොපවතින බව සැලකිල්ලට ගත යුතුය.

ටෙලිග්රාෆ්

ටෙලිග්රාෆ් රාජ්‍ය යන්ත්‍රයක ප්‍රමිතික එකතු කිරීම සඳහා ඉතා සැහැල්ලු නියෝජිතයෙකි.

ඔහුට සෑම දෙයක්ම විශාල ප්‍රමාණයක් නිරීක්ෂණය කළ හැකිය nginx කිරීමට
සේවාදායකය මයින්ක්රාෆ්ට් බිඳ.

එය සිසිල් වාසි ගණනාවක් ඇත:

• වේගවත් සහ සැහැල්ලු (Go හි ලියා ඇත)
  • අවම සම්පත් ප්‍රමාණයක් අනුභව කරයි
• පෙරනිමියෙන් මිතික තල්ලු කරන්න
• අවශ්‍ය සියලුම ප්‍රමිතික එකතු කරයි
  • කිසිදු සැකසීමකින් තොරව පද්ධති මිතික
  • සංවේදක වලින් ලැබෙන තොරතුරු වැනි දෘඪාංග ප්‍රමිතික
  • ඔබේම ප්‍රමිතික එකතු කිරීම ඉතා පහසුයි
• පෙට්ටියෙන් ප්ලගින ගොඩක්
• ලඝු-සටහන් එකතු කරයි

තල්ලු ප්‍රමිතික අපට අවශ්‍ය වූ බැවින්, අනෙකුත් සියලුම වාසි ප්‍රසන්න එකතු කිරීම්වලට වඩා වැඩි විය.

ලොග් ලොග් කිරීම සඳහා අමතර උපයෝගිතා සම්බන්ධ කිරීමට අවශ්‍ය නොවන බැවින් නියෝජිතයා විසින්ම ලඝු-සටහන් එකතු කිරීම ද ඉතා පහසු වේ.

ඔබ භාවිතා කරන්නේ නම් ලොග සමඟ වැඩ කිරීම සඳහා Influx වඩාත් පහසු අත්දැකීමක් ලබා දෙයි සිස්ලොග්.

Telegraf සාමාන්‍යයෙන් ඔබ ICK තොගයේ ඉතිරි කොටස් භාවිතා නොකළත්, ප්‍රමිතික එකතු කිරීම සඳහා විශිෂ්ට නියෝජිතයෙකි.

බොහෝ අය එය ඕනෑම තැනක පාහේ ප්‍රමිතික ලිවිය හැකි බැවින්, පහසුව සඳහා ELK සහ වෙනත් විවිධ කාල ශ්‍රේණි දත්ත සමුදායන් සමඟ එය හරස් කරයි.

InfluxDB

InfluxDB යනු TICK තොගයේ ප්‍රධාන හරයයි, එනම් ප්‍රමිතික සඳහා කාල ශ්‍රේණි දත්ත ගබඩාවකි.
ප්‍රමිතික වලට අමතරව, Influx හට ලඝු-සටහන් ගබඩා කළ හැක, කෙසේ වෙතත්, සාරය වශයෙන්, ඒ සඳහා වන ලඝු-සටහන් එකම ප්‍රමිතික වේ, සාමාන්‍ය සංඛ්‍යාත්මක දර්ශක වෙනුවට පමණක්, ප්‍රධාන කාර්යය සිදු කරනු ලබන්නේ ලොග් පෙළ රේඛාවක් මගිනි.

InfluxDB Go හි ද ලියා ඇති අතර අපගේ (වඩාත්ම බලගතු නොවන) පොකුරේ ELK හා සසඳන විට ඉතා වේගයෙන් ධාවනය වන බව පෙනේ.

Influx හි ඇති හොඳ වාසියක් වන්නේ දත්ත විමසුම් සඳහා ඉතා පහසු සහ පොහොසත් API එකක් ද ඇතුළත් වන අතර, එය අප ඉතා ක්‍රියාශීලීව භාවිතා කරයි.

අවාසි - $$$ හෝ පරිමාණය?

TICK තොගයේ ඇත්තේ අප සොයාගත් එක් අඩුපාඩුවක් පමණි - එය ආදරණීය. ඊටත් වඩා.

ගෙවන ලද අනුවාදයේ ඇති නිදහස් අනුවාදයේ නොමැති දේ කුමක්ද?

අපට තේරුම් ගැනීමට හැකි වූ පරිදි, TICK තොගයේ ගෙවන ලද අනුවාදය සහ නිදහස් එක අතර ඇති එකම වෙනස වන්නේ පරිමාණ කිරීමේ හැකියාවයි.

එනම්, ඔබට ඉහළ ලබා ගත හැකි පොකුරක් මතු කළ හැක්කේ තුළ පමණි ව්යවසාය අනුවාද.

ඔබට සම්පූර්ණ HA අවශ්‍ය නම්, ඔබට ගෙවීමට හෝ කිහිලිකරු භාවිතා කිරීමට අවශ්‍ය වේ. ප්‍රජා විසඳුම් කිහිපයක් තිබේ - උදාහරණයක් ලෙස influxdb-ha නිසි විසඳුමක් ලෙස පෙනේ, නමුත් එය නිෂ්පාදනය සඳහා සුදුසු නොවන බව ලියා ඇත, මෙන්ම
influx-spout - NATS හරහා දත්ත පොම්ප කිරීම සමඟ සරල විසඳුමක් (එය ද පරිමාණය කිරීමට සිදුවනු ඇත, නමුත් මෙය විසඳිය හැක).

එය කණගාටුවට කරුණකි, නමුත් ඔවුන් දෙදෙනාම අතහැර දමා ඇති බවක් පෙනේ - නැවුම් කැපවීම් නොමැත, ප්‍රශ්නය බොහෝ දේ වෙනස් වනු ඇති Influx 2.0 හි නව අනුවාදයේ ඉක්මනින් අපේක්ෂිත නිකුතුව බව මම උපකල්පනය කරමි (ඒ ගැන තොරතුරු නොමැත. තවමත් එහි පරිමාණය කිරීම).

නිල වශයෙන් නොමිලේ අනුවාදයක් තිබේ රිලේ - ඇත්ත වශයෙන්ම, මෙය ප්‍රාථමික HA වේ, නමුත් සමතුලිතතාවයෙන් පමණි,
සියලුම දත්ත load balancer පිටුපස ඇති සියලුම InfluxDB අවස්ථාවන් වෙත ලියා ඇති බැවින්.
ඔහුට සමහරක් ඇත අවාසි ලකුණු උඩින් ලිවීමේ ඇති විය හැකි ගැටළු සහ ප්‍රමිතික සඳහා පාදක කල්තියා නිර්මාණය කිරීමේ අවශ්‍යතාවය වැනි
(එය InfluxDB සමඟ සාමාන්‍ය වැඩ කිරීමේදී ස්වයංක්‍රීයව සිදු වේ).

ඊට අමතරව බෙදා හැරීමට සහය නොදක්වයි, මෙයින් අදහස් කරන්නේ ඔබට අවශ්‍ය නොවන අනුපිටපත් ප්‍රමිතික (සැකසීම සහ ගබඩා කිරීම යන දෙකම) සඳහා අමතර පොදු කාර්ය, නමුත් ඒවා වෙන් කිරීමට ක්‍රමයක් නැත.

වික්ටෝරියා මෙට්‍රික්ස්?

එහි ප්‍රතිඵලයක් ලෙස, ගෙවන ලද පරිමාණය හැර අනෙකුත් සෑම දෙයකම TICK තොගය පිළිබඳව අප සම්පුර්ණයෙන්ම සෑහීමකට පත් වුවද, ඉතිරි T_CK සංරචක හැර යන අතරම InfluxDB දත්ත සමුදාය ප්‍රතිස්ථාපනය කළ හැකි නිදහස් විසඳුම් තිබේදැයි බැලීමට අපි තීරණය කළෙමු.

කාල ශ්‍රේණි දත්ත සමුදායන් රාශියක් ඇත, නමුත් වඩාත්ම බලාපොරොත්තු සහගත එක වන්නේ වික්ටෝරියා මෙට්‍රික්ස් ය, එයට වාසි ගණනාවක් ඇත:

• අඩුම තරමින් ප්‍රතිඵල අනුව ඉක්මන් සහ පහසුයි මිණුම් සලකුණු
• පොකුරු අනුවාදයක් ඇත, ඒ ගැන දැන් හොඳ සමාලෝචන පවා ඇත
  • ඇයට කඩන්න පුළුවන්
• InfluxDB ප්‍රොටෝකෝලය සඳහා සහය දක්වයි

අපි වික්ටෝරියා මත පදනම් වූ සම්පූර්ණයෙන්ම අභිරුචි තොගයක් තැනීමට අදහස් නොකළ අතර ප්‍රධාන බලාපොරොත්තුව වූයේ අපට එය InfluxDB සඳහා ආදේශකයක් ලෙස භාවිතා කළ හැකි වීමයි.

අවාසනාවකට මෙන්, මෙය කළ නොහැක, InfluxDB ප්‍රොටෝකෝලය සහය දක්වනු ලැබුවද, එය ක්‍රියා කරන්නේ ප්‍රමිතික පටිගත කිරීම සඳහා පමණි - Prometheus API පමණක් “පිටත” ඇත, එයින් අදහස් කරන්නේ එය මත Chronograf සැකසීමට නොහැකි වනු ඇති බවයි.

එපමණක් නොව, ප්‍රමිතික සඳහා සහය දක්වන්නේ සංඛ්‍යාත්මක අගයන් පමණි (අපි අභිරුචි ප්‍රමිතික සඳහා තන්තු අගයන් භාවිතා කළෙමු - ඒ පිළිබඳ වැඩි විස්තර කොටසේ පරිපාලක මණ්ඩලය).

පැහැදිලිවම, එකම හේතුව නිසා, VM හට Influx මෙන් ලොග් ගබඩා කළ නොහැක.

එසේම, ප්‍රශස්ත විසඳුම සොයන අවස්ථාවේදී, වික්ටෝරියා මෙට්‍රික්ස් තවමත් එතරම් ජනප්‍රිය නොවූ බවත්, ප්‍රලේඛනය බෙහෙවින් කුඩා වූ අතර ක්‍රියාකාරීත්වය දුර්වල වූ බවත් සඳහන් කළ යුතුය.
(පොකුරු අනුවාදය සහ බෙදා හැරීම පිළිබඳ සවිස්තරාත්මක විස්තරයක් මට මතක නැත).

මූලික තේරීම

එහි ප්රතිඵලයක් වශයෙන්, නියමුවා සඳහා අපි තවමත් තනි InfluxDB නෝඩයකට සීමා කිරීමට තීරණය විය.

මෙම තේරීම සඳහා ප්රධාන හේතු කිහිපයක් විය:

• අපි ඇත්තටම TICK තොගයේ සම්පූර්ණ ක්‍රියාකාරීත්වයට කැමතියි
• අපි දැනටමත් එය යෙදවීමට සමත් වූ අතර එය විශිෂ්ට ලෙස ක්‍රියාත්මක විය
• නියමිත කාලසීමාවන් අවසන් වූ අතර වෙනත් විකල්ප පරීක්ෂා කිරීමට වැඩි කාලයක් ඉතිරි නොවීය.
• මේ තරම් බරක් අපි බලාපොරොත්තු වුණේ නැහැ

නියමුවාගේ පළමු අදියර සඳහා අප සතුව බොහෝ ස්කූටර නොතිබූ අතර, සංවර්ධනය අතරතුර පරීක්ෂා කිරීමේදී කාර්ය සාධන ගැටළු කිසිවක් අනාවරණය නොවීය.

එමනිසා, මෙම ව්‍යාපෘතිය සඳහා පරිමාණය කිරීමකින් තොරව එක් Influx node එකක් අපට ප්‍රමාණවත් බව අපි තීරණය කළෙමු (අවසානයේ නිගමන බලන්න).

අපි අට්ටිය සහ පදනම මත තීරණය කර ඇත - දැන් TICK තොගයේ ඉතිරි සංරචක ගැන.

කපසිටර්

Kapacitor යනු TICK තොගයේ කොටසකි, දත්ත සමුදායට ඇතුළු වන ප්‍රමිතික තත්‍ය කාලීනව නිරීක්ෂණය කළ හැකි සහ නීතිරීති මත පදනම්ව විවිධ ක්‍රියා සිදු කළ හැකි සේවාවකි.

පොදුවේ ගත් කල, එය විභව විෂමතා ලුහුබැඳීම සහ යන්ත්‍ර ඉගෙනීම සඳහා මෙවලමක් ලෙස ස්ථානගත කර ඇත (මෙම කාර්යයන් ඉල්ලුමේ පවතින බව මට විශ්වාස නැත), නමුත් එහි භාවිතයේ වඩාත් ජනප්‍රිය අවස්ථාව වඩාත් සුලභ වේ - අනතුරු ඇඟවීම.

අපි එය දැනුම්දීම් සඳහා භාවිතා කළේ එලෙසයි. විශේෂිත ස්කූටරයක් ​​නොබැඳි වූ විට අපි Slack ඇඟවීම් සකසන්නෙමු, ස්මාර්ට් චාජර් සහ වැදගත් යටිතල පහසුකම් සංරචක සඳහාද එයම කරන ලදී.

මෙමගින් ගැටළු වලට ඉක්මනින් ප්‍රතිචාර දැක්වීමට මෙන්ම සියල්ල යථා තත්ත්වයට පත් වූ බවට දැනුම්දීම් ලබා ගැනීමට හැකි විය.

සරල උදාහරණයක්: අපගේ “පෙට්ටිය” බල ගැන්වීම සඳහා අතිරේක බැටරියක් බිඳ වැටී හෝ කිසියම් හේතුවක් නිසා බලය අවසන් වී ඇත; සරලව නව එකක් ස්ථාපනය කිරීමෙන්, ටික වේලාවකට පසු ස්කූටරයේ ක්‍රියාකාරීත්වය ප්‍රතිසාධනය කර ඇති බවට අපට දැනුම් දීමක් ලැබිය යුතුය.

Influx 2.0 Kapacitor DB හි කොටසක් බවට පත් විය

කාල සටහන

මම නිරීක්ෂණය සඳහා විවිධ UI විසඳුම් දැක ඇත, නමුත් ක්‍රියාකාරීත්වය සහ UX අනුව, Chronograf සමඟ සැසඳෙන කිසිවක් මට කිව නොහැක.

අපි TICK ස්ටැක් භාවිතා කිරීමට පටන් ගත්තෙමු, අමුතු තරම්, වෙබ් අතුරු මුහුණතක් ලෙස Grafan සමඟ.
මම එහි ක්‍රියාකාරිත්වය විස්තර නොකරමි; ඕනෑම දෙයක් සැකසීම සඳහා එහි පුළුල් හැකියාවන් සෑම දෙනාම දනී.

කෙසේ වෙතත්, Grafana තවමත් සම්පූර්ණයෙන්ම විශ්වීය උපකරණයක් වන අතර Chronograf ප්රධාන වශයෙන් Influx සමඟ භාවිතා කිරීම සඳහා නිර්මාණය කර ඇත.

ඇත්ත වශයෙන්ම, මෙයට ස්තූතිවන්ත වන අතර, Chronograf හට වඩාත් දක්ෂ හෝ පහසු ක්රියාකාරිත්වයක් ලබා ගත හැකිය.

සමහර විට Chronograf සමඟ වැඩ කිරීමේ ප්‍රධාන පහසුව නම් ඔබට Explore හරහා ඔබේ InfluxDB හි අභ්‍යන්තරය බැලීමට හැකි වීමයි.

ග්‍රැෆානාට බොහෝ දුරට සමාන ක්‍රියාකාරීත්වයක් ඇති බව පෙනේ, නමුත් ඇත්ත වශයෙන්ම, ක්‍රොනොග්‍රාෆ් හි උපකරණ පුවරුවක් සැකසීම මූසික ක්ලික් කිරීම් කිහිපයකින් කළ හැකිය (ඒ සමඟම එහි දෘශ්‍යකරණය දෙස බැලීම), ග්‍රැෆානා හි ඔබට තවමත් ඉක්මනින් හෝ පසුව ලැබෙනු ඇත. JSON වින්‍යාසය සංස්කරණය කිරීමට (ඇත්තෙන්ම Chronograf මඟින් ඔබගේ අතින් වින්‍යාස කර ඇති dashas උඩුගත කිරීමට සහ අවශ්‍ය නම් JSON ලෙස සංස්කරණය කිරීමට ඉඩ ලබා දේ - නමුත් ඒවා UI මත නිර්මාණය කිරීමෙන් පසු මට ඒවා ස්පර්ශ කිරීමට කිසිදා සිදු නොවීය).

Kibana ඒවා සඳහා උපකරණ පුවරු සහ පාලන නිර්මාණය කිරීම සඳහා වඩා පොහොසත් හැකියාවන් ඇත, නමුත් එවැනි මෙහෙයුම් සඳහා UX ඉතා සංකීර්ණ වේ.

පහසු උපකරණ පුවරුවක් නිර්මාණය කිරීම සඳහා හොඳ අවබෝධයක් අවශ්ය වනු ඇත. Chronograf උපකරණ පුවරු වල ක්‍රියාකාරීත්වය අඩු වුවද, ඒවා සෑදීම සහ අභිරුචිකරණය කිරීම වඩාත් සරල ය.

ප්‍රසන්න දෘශ්‍ය විලාසය හැරුණු විට උපකරණ පුවරු ඇත්ත වශයෙන්ම ග්‍රැෆානා හෝ කිබානාහි උපකරණ පුවරුවලට වඩා වෙනස් නොවේ:

විමසුම් කවුළුව පෙනෙන්නේ මෙයයි:

වෙනත් දේ අතර, InfluxDB දත්ත ගබඩාවේ ඇති ක්ෂේත්‍ර වර්ග දැනගැනීම, chronograph විසින්ම විමසුමක් ලිවීමට හෝ මධ්‍යන්‍ය වැනි නිවැරදි එකතු කිරීමේ ශ්‍රිතය තෝරා ගැනීමට සමහර විට ස්වයංක්‍රීයව ඔබට උපකාර කළ හැකි බව සැලකිල්ලට ගැනීම වැදගත්ය.

ඇත්ත වශයෙන්ම, ලඝු-සටහන් බැලීම සඳහා Chronograf හැකි තරම් පහසු වේ. එය මෙසේ පෙනේ:

පෙරනිමියෙන්, Influx logs syslog භාවිතා කිරීමට සකස් කර ඇති අතර එබැවින් ඒවාට වැදගත් පරාමිතියක් ඇත - බරපතලකම.

ඉහළින් ඇති ප්‍රස්ථාරය විශේෂයෙන් ප්‍රයෝජනවත් වේ; එය මත ඔබට සිදුවන දෝෂ දැකිය හැකි අතර බරපතලකම වැඩි නම් වර්ණය වහාම පැහැදිලිව පෙන්වයි.

අපි කිහිප වතාවක්ම මේ ආකාරයෙන් වැදගත් දෝෂ හසුකර ගත්තෙමු, පසුගිය සතියේ ලඝු-සටහන් බැලීමට ගොස් රතු කටුවක් දුටුවෙමු.

ඇත්ත වශයෙන්ම, මේ සඳහා අපට දැනටමත් සෑම දෙයක්ම තිබූ බැවින්, එවැනි දෝෂ සඳහා ඇඟවීම් සැකසීම ඉතා සුදුසු ය.

අපි මෙය ටික වේලාවක් ක්‍රියාත්මක කර ඇත, නමුත් නියමුවා සූදානම් කිරීමේ ක්‍රියාවලියේදී අපට බොහෝ දෝෂ (LTE ජාලය නොමැතිකම වැනි පද්ධති ඇතුළුව) ලැබෙන බව පෙනී ගිය අතර එය Slack නාලිකාවට ද “ස්පෑම්” විය. බොහෝ, කිසිදු ගැටළුවක් ඇති නොකර, විශාල ප්රතිලාභයක්.

නිවැරදි විසඳුම වනුයේ මෙවැනි දෝෂ බොහොමයක් හැසිරවීම, ඒවායේ බරපතලකම සකස් කිරීම සහ පසුව පමණක් අනතුරු ඇඟවීම සක්‍රීය කිරීමයි.

මේ ආකාරයෙන්, නව හෝ වැදගත් දෝෂ පමණක් Slack වෙත පළ කරනු ලැබේ. දැඩි කාලසීමාවන් ලබා දී එවැනි සැකසුමක් සඳහා ප්රමාණවත් කාලයක් නොතිබුණි.

සත්යාපනය

Cronograf OAuth සහ OIDC සත්‍යාපනය ලෙස සහාය දක්වන බව ද සඳහන් කිරීම වටී.

මෙය ඉතා පහසු වේ, එය ඔබගේ සේවාදායකයට පහසුවෙන් සම්බන්ධ කිරීමට සහ සම්පූර්ණ SSO නිර්මාණය කිරීමට ඉඩ සලසයි.

අපගේ නඩුවේදී, සේවාදායකය විය යතුරු පුවරුව — එය අධීක්‍ෂණයට සම්බන්ධ වීමට භාවිතා කරන ලදී, නමුත් එම සේවාදායකයම ස්කූටර සත්‍යාපනය කිරීමට සහ පසුපස කෙළවරට ඉල්ලීම් කිරීමටද භාවිතා කරන ලදී.

"පරිපාලක"

මම විස්තර කරන අවසාන සංරචකය Vue හි අපගේ ස්වයං-ලිඛිත "පරිපාලක පැනලය" වේ.
මූලික වශයෙන් එය අපගේම දත්ත සමුදායන්, ක්ෂුද්‍ර සේවා සහ ප්‍රමිතික දත්ත වලින් එකවර InfluxDB වෙතින් ස්කූටර තොරතුරු ප්‍රදර්ශනය කරන ස්වාධීන සේවාවක් පමණි.

ඊට අමතරව, හදිසි නැවත පණගැන්වීමක් හෝ සහායක කණ්ඩායම සඳහා අගුලක් දුරස්ථව විවෘත කිරීම වැනි බොහෝ පරිපාලන කාර්යයන් එහි ගෙන යන ලදී.

සිතියම් ද තිබුණා. අපි Chronograf වෙනුවට Grafana සමඟ ආරම්භ කළ බව මම දැනටමත් සඳහන් කළෙමි - මන්ද ග්‍රැෆානා සඳහා සිතියම් ප්ලගීන ආකාරයෙන් ලබා ගත හැකි අතර එමඟින් අපට ස්කූටරවල ඛණ්ඩාංක නැරඹිය හැකිය. අවාසනාවකට මෙන්, ග්‍රැෆානා සඳහා සිතියම් විජට් වල හැකියාවන් ඉතා සීමිත වන අතර, එහි ප්‍රතිඵලයක් ලෙස, මේ මොහොතේ ඛණ්ඩාංක බැලීම පමණක් නොව, ප්‍රදර්ශනය කිරීම සඳහා දින කිහිපයකින් සිතියම් සමඟ ඔබේම වෙබ් යෙදුම ලිවීම වඩාත් පහසු විය. ස්කූටරය ගෙන යන මාර්ගය, සිතියමේ දත්ත පෙරීමට හැකි වීම යනාදිය. (අපට සරල උපකරණ පුවරුවක වින්‍යාස කිරීමට නොහැකි වූ සියලුම ක්‍රියාකාරීත්වය).

Influx හි දැනටමත් සඳහන් කර ඇති එක් වාසියක් වන්නේ පහසුවෙන් ඔබේම මිනුම් නිර්මාණය කිරීමේ හැකියාවයි.
මෙය විශාල විවිධ අවස්ථා සඳහා භාවිතා කිරීමට ඉඩ සලසයි.

අපි එහි සියලු ප්‍රයෝජනවත් තොරතුරු වාර්තා කිරීමට උත්සාහ කළෙමු: බැටරි ආරෝපණය, අගුලු දැමීමේ තත්ත්වය, සංවේදක ක්‍රියාකාරිත්වය, බ්ලූටූත්, ජීපීඑස්, සහ තවත් බොහෝ සෞඛ්‍ය පරීක්‍ෂණ.
අපි මේ සියල්ල පරිපාලක පැනලයේ ප්‍රදර්ශනය කළෙමු.

ඇත්ත වශයෙන්ම, අපට වඩාත්ම වැදගත් නිර්ණායකය වූයේ ස්කූටරයේ මෙහෙයුම් තත්ත්වයයි - ඇත්ත වශයෙන්ම, Influx විසින්ම මෙය පරීක්ෂා කර එය නෝඩ් කොටසේ "හරිත ලාම්පු" සමඟ පෙන්වයි.

මෙය සිදු කරනු ලබන්නේ ශ්‍රිතය මගිනි මළ මිනිසා — අපි එය අපගේ පෙට්ටියේ කාර්ය සාධනය තේරුම් ගැනීමට සහ එම ඇඟවීම් Slack වෙත යැවීමට භාවිතා කළෙමු.

මාර්ගය වන විට, අපි ස්කූටර නම් කළේ ද සිම්ප්සන් හි චරිතවල නම් වලින් - ඒවා එකිනෙකාගෙන් වෙන්කර හඳුනා ගැනීම එතරම් පහසු විය

පොදුවේ ගත් කල, මේ ආකාරයෙන් වඩාත් විනෝදජනක විය. “Guys, Smithers is dead!” වැනි වාක්‍ය ඛණ්ඩ නිරන්තරයෙන් ඇසෙන්නට විය.

තන්තු ප්‍රමිතික

වික්ටෝරියා මෙට්‍රික්ස් වල මෙන් සංඛ්‍යාත්මක අගයන් පමණක් ගබඩා කිරීමට InfluxDB ඔබට ඉඩ දීම වැදගත් වේ.

මෙය එතරම් වැදගත් නොවන බව පෙනේ - සියල්ලට පසු, ලඝු-සටහන් හැර, ඕනෑම ප්‍රමිතික සංඛ්‍යා ස්වරූපයෙන් ගබඩා කළ හැකිද (දන්නා ප්‍රාන්ත සඳහා සිතියම්කරණය එක් කරන්න - enum වර්ගයක්)?

අපගේ නඩුවේදී, තන්තු ප්‍රමිතික ඉතා ප්‍රයෝජනවත් වූ අවම වශයෙන් එක් අවස්ථාවක් තිබේ.
එය එසේ වූයේ අපගේ "ස්මාර්ට් චාජර්" සැපයුම්කරු තෙවන පාර්ශවයක් වූ අතර, සංවර්ධන ක්රියාවලිය සහ මෙම චාජර් සැපයිය හැකි තොරතුරු පිළිබඳව අපට පාලනයක් නොතිබුණි.

එහි ප්‍රතිඵලයක් වශයෙන්, ආරෝපණය කිරීමේ API පරමාදර්ශයෙන් බොහෝ දුරස් වූ නමුත් ප්‍රධාන ගැටලුව වූයේ අපට ඔවුන්ගේ තත්ත්වය සැමවිටම තේරුම් ගැනීමට නොහැකි වීමයි.

Influx ගලවා ගැනීමට පැමිණියේ මෙහිදීය. InfluxDB දත්ත සමුදා ක්ෂේත්‍රයට අප වෙත පැමිණි තන්තු තත්ත්වය වෙනස් කිරීමකින් තොරව අපි සරලව ලිව්වෙමු.

යම් කාලයක් සඳහා, “මාර්ගගත” සහ “නොබැඳි” වැනි අගයන් පමණක් එහි පැමිණියේ, අපගේ පරිපාලක පැනලයේ තොරතුරු ප්‍රදර්ශනය කරන ලද සහ Slack වෙත දැනුම්දීම් යවන ලද ඒවා මත පදනම්වය. කෙසේ වෙතත්, යම් අවස්ථාවක දී, "විසන්ධි" වැනි අගයන් ද එහි පෙනෙන්නට පටන් ගත්තේය.

පසුව පෙනී ගිය පරිදි, මෙම තත්ත්වය එක් වරක් යවනු ලැබුවේ සම්බන්ධතාවය නැතිවීමෙන් පසුව, චාජරයට නිශ්චිත උත්සාහයන් ගණනකින් පසු සේවාදායකය සමඟ සම්බන්ධතාවයක් ඇති කර ගත නොහැකි නම්.

මේ අනුව, අපි ස්ථාවර අගයන් කට්ටලයක් පමණක් භාවිතා කළේ නම්, නිවැරදි වේලාවට ස්ථිරාංගවල මෙම වෙනස්කම් අපට නොපෙනේ.

සාමාන්‍යයෙන්, තන්තු ප්‍රමිතික භාවිතය සඳහා බොහෝ අවස්ථාවන් සපයයි; ඔබට ඒවායේ ඕනෑම තොරතුරක් පාහේ වාර්තා කළ හැකිය. ඇත්ත වශයෙන්ම, ඔබ මෙම මෙවලම ප්‍රවේශමෙන් භාවිතා කළ යුතු වුවද.

සාමාන්‍ය ප්‍රමිතික වලට අමතරව, අපි InfluxDB හි GPS ස්ථාන තොරතුරු ද වාර්තා කළෙමු. අපගේ පරිපාලක පැනලයේ ස්කූටරවල පිහිටීම නිරීක්ෂණය කිරීම සඳහා මෙය ඇදහිය නොහැකි තරම් ප්‍රයෝජනවත් විය.
ඇත්ත වශයෙන්ම, අපට අවශ්‍ය මොහොතේ කොතැනද සහ කුමන ස්කූටරයද යන්න අපි සැමවිටම දැන සිටියෙමු.

අපි ස්කූටරයක් ​​සොයන විට මෙය අපට ඉතා ප්‍රයෝජනවත් විය (අවසානයේ නිගමන බලන්න).

යටිතල පහසුකම් අධීක්ෂණය

ස්කූටර වලට අමතරව, අපට අපගේ සම්පූර්ණ (තරමක් පුළුල්) යටිතල පහසුකම් ද නිරීක්ෂණය කිරීමට අවශ්‍ය විය.

ඉතා සාමාන්‍ය ගෘහනිර්මාණ ශිල්පයක් මේ වගේ දෙයක් පෙනුණා:

අපි පිරිසිදු අධීක්ෂණ තොගයක් උද්දීපනය කළහොත්, එය මෙසේ දිස්වේ:

අපි වලාකුළෙහි පරීක්ෂා කිරීමට කැමති දේ:

• දත්ත සමුදායන්
• යතුරු පුවරුව
• ක්ෂුද්ර සේවා

අපගේ සියලුම වලාකුළු සේවා Kubernetes හි පිහිටා ඇති බැවින්, එහි තත්වය පිළිබඳ තොරතුරු රැස් කිරීම සතුටක් වනු ඇත.

වාසනාවකට මෙන්, ටෙලිග්‍රාෆ්ට කුබර්නෙටස් පොකුරේ තත්වය පිළිබඳ විශාල ප්‍රමිතික සංඛ්‍යාවක් එකතු කර ගත හැකි අතර, ක්‍රොනොග්‍රාෆ් වහාම මේ සඳහා අලංකාර උපකරණ පුවරු ඉදිරිපත් කරයි.

අපි ප්‍රධාන වශයෙන් කරල්වල ක්‍රියාකාරිත්වය සහ මතක පරිභෝජනය නිරීක්ෂණය කළෙමු. වැටීමකදී, Slack හි ඇඟවීම්.

Kubernetes හි කරල් නිරීක්ෂණය කිරීමට ක්‍රම දෙකක් තිබේ: DaemonSet සහ Sidecar.
ක්රම දෙකම විස්තරාත්මකව විස්තර කර ඇත මෙම බ්ලොග් සටහනේ.

අපි Telegraf Sidecar භාවිත කළ අතර, ප්‍රමිතිකවලට අමතරව, පොඩ් ලොග් එකතු කළෙමු.

අපගේ නඩුවේදී, අපට ලොග් සමඟ ටින්කර් කිරීමට සිදු විය. Telegraf හට Docker API වෙතින් ලඝු-සටහන් ඇද ගත හැකි වුවද, අපගේ අවසාන උපාංග සමඟ ඒකාකාරී ලොග එකතුවක් සහ මේ සඳහා බහාලුම් සඳහා වින්‍යාස කළ syslog එකක් තිබීමට අපට අවශ්‍ය විය. සමහර විට මෙම විසඳුම අලංකාර නොවේ, නමුත් එහි කාර්යය පිළිබඳ පැමිණිලි නොමැති අතර ලොග් Chronograf හි හොඳින් ප්රදර්ශනය විය.

නිරීක්ෂණ අධීක්ෂණය ???

අවසානයේදී, අධීක්ෂණ පද්ධති අධීක්ෂණ කිරීමේ වයස්ගත ප්‍රශ්නය මතු වූ නමුත්, වාසනාවකට හෝ අවාසනාවකට මෙන්, අපට මේ සඳහා ප්‍රමාණවත් කාලයක් නොතිබුණි.

Telegraf හට පහසුවෙන්ම තමන්ගේම ප්‍රමිතික යැවීමට හෝ InfluxDB දත්ත ගබඩාවෙන් ප්‍රමිතික එකතු කිරීමට හැකි වුවද, එකම Influx වෙත හෝ වෙනත් ස්ථානයකට යැවීම සඳහා.

සොයා ගැනීම්

නියමුවාගේ ප්‍රතිඵලවලින් අප ගත් නිගමන මොනවාද?

ඔබට නිරීක්ෂණය කළ හැක්කේ කෙසේද?

පළමුවෙන්ම, TICK තොගය අපගේ අපේක්ෂාවන් සම්පුර්ණයෙන්ම සපුරාලන අතර අප මුලින් බලාපොරොත්තු වූවාට වඩා වැඩි අවස්ථාවන් අපට ලබා දුන්නේය.

අපට අවශ්‍ය සියලුම ක්‍රියාකාරීත්වය තිබුණි. අපි එය සමඟ කළ සෑම දෙයක්ම කිසිදු ගැටළුවක් නොමැතිව වැඩ කළා.

ඵලදායිතාව

නිදහස් අනුවාදයේ TICK තොගයේ ඇති ප්‍රධාන ගැටළුව වන්නේ පරිමාණ කිරීමේ හැකියාවන් නොමැතිකමයි. මේක අපිට ප්‍රශ්නයක් වුණේ නැහැ.

අපි නිශ්චිත පැටවුම් දත්ත/සංඛ්‍යා එකතු නොකළ නමුත් අපි වරකට ස්කූටර් 30කින් පමණ දත්ත රැස් කළෙමු.

ඒ සෑම එකක්ම මෙට්‍රික් දුසිම් තුනකට වඩා එකතු කර ගත්හ. ඒ සමගම, උපාංගවලින් ලොග් එකතු කරන ලදී. දත්ත රැස් කිරීම සහ යැවීම තත්පර 10කට වරක් සිදු විය.

නියමුවාගේ සති එකහමාරකට පසු, “ළමා ගැටළු” වලින් වැඩි ප්‍රමාණයක් නිවැරදි කර ඇති අතර වඩාත්ම වැදගත් ගැටළු දැනටමත් විසඳා ඇති විට, අපට සේවාදායකයට දත්ත යැවීමේ වාර ගණන අඩු කිරීමට සිදු වූ බව සැලකිල්ලට ගැනීම වැදගත්ය. තත්පර 30 යි. මෙය අවශ්‍ය වූයේ අපගේ LTE සිම් කාඩ්පත්වල ගමනාගමනය ඉක්මනින් අතුරුදහන් වීමට පටන් ගත් බැවිනි.

ගමනාගමනයෙන් වැඩි ප්‍රමාණයක් ලොග් විසින් පරිභෝජනය කරන ලදී; ප්‍රමිතික, තත්පර 10 ක පරතරයකින් වුවද, ප්‍රායෝගිකව එය අපතේ ගියේ නැත.

එහි ප්‍රතිඵලයක් වශයෙන්, නියත එකතු කිරීමකින් තොරව පවා නිශ්චිත ගැටළු දැනටමත් පැහැදිලිව පෙනෙන බැවින්, යම් කාලයකට පසු අපි උපාංගවල ලඝු-සටහන් එකතු කිරීම සම්පූර්ණයෙන්ම අක්‍රිය කළෙමු.

සමහර අවස්ථාවලදී, ලඝු-සටහන් බැලීම තවමත් අවශ්ය නම්, අපි VPN හරහා WireGuard හරහා සම්බන්ධ කළෙමු.

එක් එක් වෙනම පරිසරය එකිනෙකින් වෙන් කර ඇති බවත්, ඉහත විස්තර කර ඇති බර අදාළ වන්නේ නිෂ්පාදන පරිසරයට පමණක් බවත් මම එකතු කරමි.

සංවර්ධන පරිසරය තුළ, අපි සෑම තත්පර 10 කට වරක් දත්ත රැස් කිරීම දිගටම කරගෙන යන වෙනම InfluxDB අවස්ථාවක් මතු කළ අතර අපි කිසිදු කාර්ය සාධන ගැටලුවකට මුහුණ දුන්නේ නැත.

TICK - කුඩා හා මධ්යම ව්යාපෘති සඳහා වඩාත් සුදුසුය

මෙම තොරතුරු මත පදනම්ව, කිසිදු HighLoad එකක් බලාපොරොත්තු නොවන සාපේක්ෂව කුඩා ව්‍යාපෘති හෝ ව්‍යාපෘති සඳහා TICK තොගය වඩාත් සුදුසු බව මම නිගමනය කරමි.

ඔබට කරල් දහස් ගණනක් හෝ යන්ත්‍ර සිය ගණනක් නොමැති නම්, එක් InfluxDB අවස්ථාවක් පවා බර පැටවීම හොඳින් හසුරුවනු ඇත.

සමහර අවස්ථා වලදී, ඔබ ප්‍රාථමික ඉහළ ලබා ගත හැකි විසඳුමක් ලෙස Influx Relay සමඟ සෑහීමකට පත් විය හැක.

තවද, ඇත්ත වශයෙන්ම, "සිරස්" පරිමාණය සැකසීමෙන් සහ විවිධ වර්ගයේ මෙට්රික් සඳහා විවිධ සේවාදායකයන් සරලව වෙන් කිරීම කිසිවෙකු ඔබව වළක්වන්නේ නැත.

අධීක්ෂණ සේවාවන්හි අපේක්ෂිත භාරය ගැන ඔබට විශ්වාස නැත්නම්, හෝ ඔබට ඉතා "බර" ගෘහ නිර්මාණ ශිල්පයක් ඇති බවට/ඇති බවට සහතික නම්, මම TICK තොගයේ නිදහස් අනුවාදය භාවිතා කිරීම නිර්දේශ නොකරමි.

ඇත්ත වශයෙන්ම, සරල විසඳුමක් වනුයේ මිලදී ගැනීමයි InfluxDB ව්‍යවසාය - නමුත් මෙහි මට කෙසේ හෝ අදහස් දැක්විය නොහැක, මන්ද මම සියුම්කම් ගැන හුරුපුරුදු නැති බැවිනි. එය ඉතා මිල අධික වන අතර අනිවාර්යයෙන්ම කුඩා සමාගම් සඳහා සුදුසු නොවේ.

මෙම අවස්ථාවේ දී, අද, මම Victoria Metrics හරහා ප්‍රමිතික එකතු කිරීම සහ Loki භාවිතයෙන් ලොග් දෙස බැලීම නිර්දේශ කරමි.

ඇත්ත, මම නැවතත් Loki/Grafana සූදානම් කර ඇති TICK එකට වඩා ඉතා අඩු පහසු (ඔවුන්ගේ බහුකාර්යතාව නිසා) බව වෙන්කරවා ගන්නෙමි, නමුත් ඒවා නොමිලේ.

වැදගත්: මෙහි විස්තර කර ඇති සියලුම තොරතුරු Influx 1.8 අනුවාදය සඳහා අදාළ වේ, මේ මොහොතේ Influx 2.0 නිකුත් කිරීමට ආසන්නයි.

සටන් තත්වයන් තුළ එය උත්සාහ කිරීමට මට අවස්ථාවක් නොලැබුණු අතර වැඩිදියුණු කිරීම් පිළිබඳ නිගමනවලට එළඹීමට අපහසු වුවද, අතුරු මුහුණත අනිවාර්යයෙන්ම වඩා හොඳ වී ඇත, ගෘහ නිර්මාණ ශිල්පය සරල කර ඇත (කැපසිටර් සහ ක්‍රොනොග්‍රැෆ් නොමැතිව),
සැකිලි දර්ශනය විය ("ඝාතක ලක්ෂණය" - ඔබට ෆෝර්ට්නයිට් හි ක්‍රීඩකයන් නිරීක්ෂණය කළ හැකි අතර ඔබේ ප්‍රියතම ක්‍රීඩකයා ක්‍රීඩාවක් ජයග්‍රහණය කළ විට දැනුම්දීම් ලබා ගත හැක) නමුත්, අවාසනාවකට මෙන්, මේ මොහොතේ, අපි පළමු අනුවාදය තෝරා ගත් ප්‍රධාන දෙය 2 අනුවාදයේ නොමැත - ලොග් එකතුවක් නොමැත.

මෙම ක්‍රියාකාරීත්වය Influx 2.0 හි ද දිස් වනු ඇත, නමුත් අපට ආසන්න කාලසීමාවන් පවා සොයාගත නොහැකි විය.

IoT වේදිකා සාදා නොගන්නේ කෙසේද (දැන්)

අවසානයේදී, නියමුවා දියත් කිරීමෙන් පසු, අපගේ ප්‍රමිතීන්ට ගැලපෙන විකල්පයක් නොමැති විට, අපිම අපගේම සම්පූර්ණ IoT තොගයක් එක්රැස් කළෙමු.

කෙසේ වෙතත්, මෑතකදී එය බීටා අනුවාදයෙන් ලබා ගත හැකිය OpenBalena - අපි ව්‍යාපෘතිය ආරම්භ කරන විට ඇය එහි නොසිටීම කණගාටුවට කරුණකි.

අප විසින්ම එකලස් කරන ලද Ansible + TICK + WireGuard මත පදනම් වූ අවසාන ප්‍රතිඵලය සහ වේදිකාව පිළිබඳව අපි සම්පූර්ණයෙන්ම සෑහීමකට පත්වෙමු. නමුත් අද, ඔබේම IoT වේදිකාවක් ඔබම සාදා ගැනීමට උත්සාහ කිරීමට පෙර බැලේනා දෙස සමීපව බැලීමට මම නිර්දේශ කරමි.

මක්නිසාද යත් අවසානයේ එය අප කළ බොහෝ දේ කළ හැකි අතර OpenBalena නිදහස් සහ විවෘත මූලාශ්‍ර වේ.

එය දැනටමත් යාවත්කාලීන යැවීම පමණක් නොව, VPN එකක් දැනටමත් ගොඩනගා ඇති අතර IoT පරිසරයක භාවිතය සඳහා සකස් කර ඇත.

සහ මෑතකදී, ඔවුන් පවා ඔවුන්ගේ නිදහස් දෘඩාංග, ඔවුන්ගේ පරිසර පද්ධතියට පහසුවෙන් සම්බන්ධ වන.

හේයි, නැතිවූ ස්කූටරය ගැන කුමක් කිව හැකිද?

එබැවින් "රැල්ෆ්" ස්කූටරය හෝඩුවාවක් නොමැතිව අතුරුදහන් විය.

අපි වහාම InfluxDB වෙතින් GPS මෙට්‍රික් දත්ත සමඟ අපගේ “පරිපාලක පැනලයේ” සිතියම බැලීමට දිව ගියෙමු.

නිරීක්ෂණ දත්ත වලට ස්තූතිවන්ත වන්නට, ස්කූටරය පසුගිය දින 21:00 ට පමණ වාහන නැවැත්වීමේ ස්ථානයෙන් පිටත් වී පැය භාගයක් පමණ යම් ප්‍රදේශයකට ධාවනය කර ජර්මානු නිවසක් අසල පාන්දර 5 දක්වා නවතා තිබූ බව අපි පහසුවෙන් තීරණය කළෙමු.

උදෑසන 5 න් පසු, අධීක්ෂණ දත්ත කිසිවක් නොලැබුණි - මෙයින් අදහස් කළේ අමතර බැටරිය සම්පූර්ණයෙන්ම විසර්ජනය වී ඇති බවයි, නැතහොත් ප්‍රහාරකයා අවසානයේ ස්කූටරයෙන් ස්මාර්ට් දෘඩාංග ඉවත් කරන්නේ කෙසේදැයි සොයා ගත්තේය.
එසේ තිබියදීත් ස්කූටරය තිබූ ලිපිනයට පොලිසිය කැඳවා තිබිණි. ස්කූටරය එහි නොවීය.

කෙසේ වෙතත්, නිවසේ හිමිකරු ද මෙය පුදුමයට පත් කළේ ඔහු ඊයේ රාත්‍රියේ කාර්යාලයේ සිට මෙම ස්කූටරය පැදගෙන නිවසට පැමිණි බැවිනි.

පෙනෙන පරිදි, සහායක සේවකයෙකු උදේ පාන්දර පැමිණ ස්කූටරය රැගෙන, එහි අමතර බැටරිය සම්පූර්ණයෙන්ම විසර්ජනය වී ඇති බව දැක එය (පයින්) වාහන නැවැත්වීමේ ස්ථානයට ගෙන ගියේය. තවද තෙතමනය හේතුවෙන් අතිරේක බැටරිය අසාර්ථක විය.

අපිම තමයි ස්කූටරය හොරකම් කළේ. මාර්ගය වන විට, පොලිස් නඩුවේ ගැටලුව විසඳුවේ කෙසේද සහ කවුරුන්දැයි මම නොදනිමි, නමුත් අධීක්ෂණය හොඳින් ක්‍රියාත්මක විය ...

මූලාශ්රය: www.habr.com