നഷ്‌ടമായ സ്‌കൂട്ടർ അല്ലെങ്കിൽ ഒരു ഐഒടി നിരീക്ഷണത്തിന്റെ കഥ തിരികെ നൽകുക

ഒരു വർഷം മുമ്പ് ഞങ്ങൾ ഒരു പ്രൊമോഷണൽ പ്രോജക്റ്റിന്റെ പൈലറ്റ് പതിപ്പ് സമാരംഭിച്ചു ഇലക്ട്രിക് സ്കൂട്ടറുകളുടെ വികേന്ദ്രീകൃത വാടക.

തുടക്കത്തിൽ, പദ്ധതിയെ റോഡ്-ടു-ബാഴ്സലോണ എന്ന് വിളിച്ചിരുന്നു, പിന്നീട് അത് റോഡ്-ടു-ബെർലിൻ ആയി മാറി (അതിനാൽ സ്ക്രീൻഷോട്ടുകളിൽ R2B), അവസാനം അത് xRide എന്ന് വിളിക്കപ്പെട്ടു.

പദ്ധതിയുടെ പ്രധാന ആശയം ഇതായിരുന്നു: ഒരു കേന്ദ്രീകൃത കാർ അല്ലെങ്കിൽ സ്കൂട്ടർ വാടകയ്‌ക്ക് നൽകുന്നതിന് പകരം (ഞങ്ങൾ സംസാരിക്കുന്നത് ഇലക്ട്രിക് മോട്ടോർസൈക്കിളുകളെക്കുറിച്ചാണ്, കിക്ക്‌സ്‌കൂട്ടറുകൾ / സ്‌കൂട്ടറുകൾ അല്ല) വികേന്ദ്രീകൃത വാടകയ്‌ക്ക് ഒരു പ്ലാറ്റ്ഫോം ഉണ്ടാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഞങ്ങൾ നേരിട്ട ബുദ്ധിമുട്ടുകളെക്കുറിച്ച് നേരത്തെ എഴുതി.

തുടക്കത്തിൽ, പ്രോജക്റ്റ് കാറുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചിരുന്നു, എന്നാൽ സമയപരിധി, നിർമ്മാതാക്കളുമായുള്ള വളരെ നീണ്ട ആശയവിനിമയം, ധാരാളം സുരക്ഷാ നിയന്ത്രണങ്ങൾ എന്നിവ കാരണം പൈലറ്റിനായി ഇലക്ട്രിക് സ്കൂട്ടറുകൾ തിരഞ്ഞെടുത്തു.

ഉപയോക്താവ് ഫോണിൽ ഒരു iOS അല്ലെങ്കിൽ Android ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാൾ ചെയ്തു, അയാൾക്ക് ഇഷ്ടപ്പെട്ട സ്കൂട്ടറിനെ സമീപിച്ചു, അതിനുശേഷം ഫോണും സ്കൂട്ടറും ഒരു പിയർ-ടു-പിയർ കണക്ഷൻ സ്ഥാപിച്ചു, ETH കൈമാറ്റം ചെയ്തു, ഉപയോക്താവിന് സ്കൂട്ടർ ഓണാക്കി സവാരി ആരംഭിക്കാം. ഫോണ്. യാത്രയുടെ അവസാനം, ഫോണിലെ ഉപയോക്താവിന്റെ വാലറ്റിൽ നിന്ന് Ethereum ഉപയോഗിച്ച് യാത്രയ്ക്ക് പണം നൽകാനും സാധിച്ചു.

സ്കൂട്ടറുകൾക്ക് പുറമേ, ഉപയോക്താവ് ആപ്ലിക്കേഷനിൽ "സ്മാർട്ട് ചാർജറുകൾ" കണ്ടു, അത് സന്ദർശിക്കുന്നതിലൂടെ ഉപയോക്താവിന് നിലവിലെ ബാറ്ററി കുറവാണെങ്കിൽ അത് സ്വയം മാറ്റാൻ കഴിയും.

ഞങ്ങളുടെ പൈലറ്റ് പൊതുവെ ഇങ്ങനെയായിരുന്നു, കഴിഞ്ഞ വർഷം സെപ്റ്റംബറിൽ രണ്ട് ജർമ്മൻ നഗരങ്ങളിൽ വിക്ഷേപിച്ചു: ബോൺ, ബെർലിൻ.

തുടർന്ന്, ഒരു ദിവസം, ബോണിൽ, അതിരാവിലെ, ഞങ്ങളുടെ സപ്പോർട്ട് ടീം (സ്കൂട്ടറുകൾ പ്രവർത്തന ക്രമത്തിൽ പരിപാലിക്കുന്നതിനായി സൈറ്റിൽ സ്ഥിതിചെയ്യുന്നു) മുന്നറിയിപ്പ് നൽകി: സ്കൂട്ടറുകളിലൊന്ന് ഒരു തുമ്പും കൂടാതെ അപ്രത്യക്ഷമായി.

അത് എങ്ങനെ കണ്ടെത്തി തിരികെ നൽകും?

ഈ ലേഖനത്തിൽ ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിക്കും, പക്ഷേ ആദ്യം - ഞങ്ങൾ എങ്ങനെ ഞങ്ങളുടെ സ്വന്തം IoT പ്ലാറ്റ്ഫോം നിർമ്മിച്ചുവെന്നും ഞങ്ങൾ അത് എങ്ങനെ നിരീക്ഷിച്ചു എന്നതിനെക്കുറിച്ചും.

എന്താണ്, എന്തുകൊണ്ട് നിരീക്ഷിക്കണം: സ്കൂട്ടറുകൾ, അടിസ്ഥാന സൗകര്യങ്ങൾ, ചാർജിംഗ് സ്റ്റേഷനുകൾ?

അപ്പോൾ, ഞങ്ങളുടെ പ്രോജക്റ്റിൽ എന്താണ് നിരീക്ഷിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചത്?

ഒന്നാമതായി, ഇവയാണ് സ്കൂട്ടറുകൾ - ഇലക്ട്രിക് സ്കൂട്ടറുകൾ തന്നെ വളരെ ചെലവേറിയതാണ്, വേണ്ടത്ര തയ്യാറാകാതെ നിങ്ങൾക്ക് അത്തരമൊരു പ്രോജക്റ്റ് സമാരംഭിക്കാൻ കഴിയില്ല; സാധ്യമെങ്കിൽ, സ്കൂട്ടറുകളെക്കുറിച്ച് കഴിയുന്നത്ര വിവരങ്ങൾ ശേഖരിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു: അവയുടെ സ്ഥാനം, ചാർജ് നില എന്നിവയെക്കുറിച്ച് , തുടങ്ങിയവ.

കൂടാതെ, ഞങ്ങളുടെ സ്വന്തം ഐടി ഇൻഫ്രാസ്ട്രക്ചറിന്റെ അവസ്ഥ നിരീക്ഷിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു - ഡാറ്റാബേസുകൾ, സേവനങ്ങൾ, അവ പ്രവർത്തിക്കാൻ ആവശ്യമായ എല്ലാം. "സ്മാർട്ട് ചാർജറുകൾ" തകരാറിലാകുകയോ പൂർണ്ണ ബാറ്ററികൾ തീർന്നുപോകുകയോ ചെയ്താൽ അവയുടെ നില നിരീക്ഷിക്കേണ്ടതും ആവശ്യമാണ്.

സ്കൂട്ടറുകൾ

ഞങ്ങളുടെ സ്കൂട്ടറുകൾ എന്തായിരുന്നു, അവയെക്കുറിച്ച് എന്താണ് അറിയാൻ ഞങ്ങൾ ആഗ്രഹിച്ചത്?

ആദ്യത്തേതും ഏറ്റവും പ്രധാനപ്പെട്ടതുമായ കാര്യം ജിപിഎസ് കോർഡിനേറ്റുകളാണ്, കാരണം അവ എവിടെയാണെന്നും അവ എവിടേക്ക് നീങ്ങുന്നുവെന്നും നമുക്ക് മനസ്സിലാക്കാൻ കഴിയും.

അടുത്തത് ബാറ്ററി ചാർജ് ആണ്, സ്കൂട്ടറുകളുടെ ചാർജിംഗ് അവസാനിക്കുന്നുവെന്ന് നിർണ്ണയിക്കാനും ഒരു ജ്യൂസർ അയയ്ക്കാനും അല്ലെങ്കിൽ ഉപയോക്താവിന് മുന്നറിയിപ്പ് നൽകാനും കഴിയുന്ന നന്ദി.

തീർച്ചയായും, ഞങ്ങളുടെ ഹാർഡ്‌വെയർ ഘടകങ്ങളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് പരിശോധിക്കേണ്ടതും ആവശ്യമാണ്:

• ബ്ലൂടൂത്ത് പ്രവർത്തിക്കുന്നുണ്ടോ?
• GPS മൊഡ്യൂൾ തന്നെ പ്രവർത്തിക്കുന്നുണ്ടോ?
  • GPS-ന് തെറ്റായ കോർഡിനേറ്റുകൾ അയച്ച് കുടുങ്ങിപ്പോകുമെന്ന വസ്തുതയിലും ഞങ്ങൾക്ക് ഒരു പ്രശ്‌നമുണ്ടായിരുന്നു, സ്‌കൂട്ടറിലെ അധിക പരിശോധനകളിലൂടെ മാത്രമേ ഇത് നിർണ്ണയിക്കാൻ കഴിയൂ,
    പ്രശ്നം പരിഹരിക്കാൻ കഴിയുന്നതും വേഗം പിന്തുണ അറിയിക്കുക

അവസാനമായി: സോഫ്‌റ്റ്‌വെയറിന്റെ പരിശോധനകൾ, OS, പ്രോസസ്സർ, നെറ്റ്‌വർക്ക്, ഡിസ്‌ക് ലോഡ് എന്നിവയിൽ തുടങ്ങി, ഞങ്ങൾക്ക് കൂടുതൽ പ്രത്യേകമായ ഞങ്ങളുടെ സ്വന്തം മൊഡ്യൂളുകളുടെ പരിശോധനയിൽ അവസാനിക്കുന്നു (ജോലോകോം, കീക്ലോക്ക്).

ഹാർഡ്വെയർ

ഞങ്ങളുടെ "ഇരുമ്പ്" ഭാഗം എന്തായിരുന്നു?

സാധ്യമായ ഏറ്റവും കുറഞ്ഞ സമയപരിധിയും ദ്രുതഗതിയിലുള്ള പ്രോട്ടോടൈപ്പിംഗിന്റെ ആവശ്യകതയും കണക്കിലെടുത്ത്, ഘടകങ്ങൾ നടപ്പിലാക്കുന്നതിനും തിരഞ്ഞെടുക്കുന്നതിനുമുള്ള ഏറ്റവും എളുപ്പമുള്ള ഓപ്ഷൻ ഞങ്ങൾ തിരഞ്ഞെടുത്തു - റാസ്ബെറി പൈ.
Rpi-യ്ക്ക് പുറമേ, ഞങ്ങൾക്ക് ഒരു ഇഷ്‌ടാനുസൃത ബോർഡും (അവസാന പരിഹാരത്തിന്റെ അസംബ്ലി പ്രക്രിയ വേഗത്തിലാക്കാൻ ഞങ്ങൾ സ്വയം വികസിപ്പിക്കുകയും ചൈനയിൽ നിന്ന് ഓർഡർ ചെയ്യുകയും ചെയ്തു) ഒരു കൂട്ടം ഘടകങ്ങളും - ഒരു റിലേ (സ്കൂട്ടർ ഓൺ / ഓഫ് ചെയ്യാൻ), ഒരു ബാറ്ററി ചാർജ് റീഡർ, ഒരു മോഡം, ആന്റിനകൾ. ഇവയെല്ലാം ഒരു പ്രത്യേക "xRide ബോക്സിൽ" ഒതുക്കപ്പെട്ടതാണ്.

മുഴുവൻ ബോക്സും ഒരു അധിക പവർ ബാങ്ക് ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത് എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്, അത് സ്കൂട്ടറിന്റെ പ്രധാന ബാറ്ററിയാണ്.

ഇഗ്നിഷൻ കീ “ഓഫ്” സ്ഥാനത്തേക്ക് മാറ്റിയ ഉടൻ തന്നെ പ്രധാന ബാറ്ററി ഓഫാക്കിയതിനാൽ, യാത്ര അവസാനിച്ചതിന് ശേഷവും നിരീക്ഷണം ഉപയോഗിക്കാനും സ്കൂട്ടർ ഓണാക്കാനും ഇത് സാധ്യമാക്കി.

ഡോക്കർ? പ്ലെയിൻ ലിനക്സ്? വിന്യാസവും

നമുക്ക് മോണിറ്ററിംഗിലേക്ക് മടങ്ങാം, അതിനാൽ റാസ്ബെറി - നമുക്ക് എന്താണ് ഉള്ളത്?

ഫിസിക്കൽ ഉപകരണങ്ങളിലേക്ക് ഘടകങ്ങൾ വിന്യസിക്കുന്നതിനും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള പ്രക്രിയ വേഗത്തിലാക്കാൻ ഞങ്ങൾ ഉപയോഗിക്കാൻ ആഗ്രഹിച്ച ആദ്യത്തെ കാര്യങ്ങളിലൊന്ന് ഡോക്കർ ആയിരുന്നു.

നിർഭാഗ്യവശാൽ, RPi-യിലെ ഡോക്കറിന്, അത് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, പ്രത്യേകിച്ച് വൈദ്യുതി ഉപഭോഗത്തിന്റെ കാര്യത്തിൽ, വളരെയധികം ഓവർഹെഡ് ഉണ്ടെന്ന് പെട്ടെന്ന് വ്യക്തമായി.

"നേറ്റീവ്" OS ഉപയോഗിക്കുന്ന വ്യത്യാസം, അത്ര ശക്തമല്ലെങ്കിലും, ചാർജ് വളരെ വേഗത്തിൽ നഷ്‌ടപ്പെടാനുള്ള സാധ്യതയെക്കുറിച്ച് ജാഗ്രത പുലർത്താൻ ഞങ്ങൾക്ക് ഇപ്പോഴും മതിയായിരുന്നു.

രണ്ടാമത്തെ കാരണം Node.js-ലെ ഞങ്ങളുടെ പങ്കാളി ലൈബ്രറികളിലൊന്നാണ് (sic!) - Go/C/C++-ൽ എഴുതിയിട്ടില്ലാത്ത സിസ്റ്റത്തിന്റെ ഏക ഘടകം.

ലൈബ്രറിയുടെ രചയിതാക്കൾക്ക് "നേറ്റീവ്" ഭാഷകളിലൊന്നും പ്രവർത്തന പതിപ്പ് നൽകാൻ സമയമില്ല.

കുറഞ്ഞ പ്രവർത്തനക്ഷമതയുള്ള ഉപകരണങ്ങൾക്കുള്ള നോഡ് തന്നെ ഏറ്റവും സുന്ദരമായ പരിഹാരമല്ലെന്ന് മാത്രമല്ല, ലൈബ്രറി തന്നെ വളരെ റിസോഴ്സ്-ഹങ്കാരിയായിരുന്നു.

ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽപ്പോലും, ഡോക്കർ ഉപയോഗിക്കുന്നത് ഞങ്ങൾക്ക് ഒരു ഓവർഹെഡ് ആയിരിക്കുമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. നേറ്റീവ് ഒഎസിന് അനുകൂലമായി തിരഞ്ഞെടുക്കുകയും അതിന് കീഴിൽ നേരിട്ട് പ്രവർത്തിക്കുകയും ചെയ്തു.

OS

തൽഫലമായി, ഞങ്ങൾ വീണ്ടും OS ആയി ഏറ്റവും ലളിതമായ ഓപ്ഷൻ തിരഞ്ഞെടുത്ത് റാസ്‌ബിയൻ (പൈയ്‌ക്കായി ഡെബിയൻ ബിൽഡ്) ഉപയോഗിച്ചു.

ഞങ്ങളുടെ എല്ലാ സോഫ്‌റ്റ്‌വെയറുകളും ഞങ്ങൾ Go-യിൽ എഴുതുന്നു, അതിനാൽ ഞങ്ങളുടെ സിസ്റ്റത്തിലെ പ്രധാന ഹാർഡ്‌വെയർ ഏജന്റ് മൊഡ്യൂളും Go-യിൽ ഞങ്ങൾ എഴുതി.

ജിപിഎസ്, ബ്ലൂടൂത്ത്, ചാർജ് റീഡിംഗ്, സ്കൂട്ടർ ഓണാക്കൽ തുടങ്ങിയവയിൽ പ്രവർത്തിക്കാനുള്ള ഉത്തരവാദിത്തം അവനാണ്.

വിന്യസിക്കുക

ഉപകരണങ്ങളിലേക്ക് (OTA) അപ്‌ഡേറ്റുകൾ നൽകുന്നതിനുള്ള ഒരു സംവിധാനം നടപ്പിലാക്കേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ചുള്ള ചോദ്യം ഉടനടി ഉയർന്നു - ഞങ്ങളുടെ ഏജന്റ്/ആപ്ലിക്കേഷനിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ, കൂടാതെ OS/ഫേംവെയറിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ (ഏജൻറിന്റെ പുതിയ പതിപ്പുകൾക്ക് കേർണലിലേക്ക് അപ്‌ഡേറ്റുകൾ ആവശ്യമായിരിക്കാം അല്ലെങ്കിൽ സിസ്റ്റം ഘടകങ്ങൾ, ലൈബ്രറികൾ മുതലായവ) .

മാർക്കറ്റിന്റെ നീണ്ട വിശകലനത്തിന് ശേഷം, ഉപകരണത്തിലേക്ക് അപ്‌ഡേറ്റുകൾ നൽകുന്നതിന് ധാരാളം പരിഹാരങ്ങൾ ഉണ്ടെന്ന് മനസ്സിലായി.

swupd/SWUpdate/OSTree പോലുള്ള താരതമ്യേന ലളിതമായ, മിക്കവാറും അപ്‌ഡേറ്റ്/ഡ്യുവൽ-ബൂട്ട് ഓറിയന്റഡ് യൂട്ടിലിറ്റികൾ മുതൽ മെൻഡർ, ബലേന പോലുള്ള പൂർണ്ണമായ പ്ലാറ്റ്‌ഫോമുകൾ വരെ.

ഒന്നാമതായി, എൻഡ്-ടു-എൻഡ് സൊല്യൂഷനുകളിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, അതിനാൽ തിരഞ്ഞെടുപ്പ് ഉടൻ പ്ലാറ്റ്‌ഫോമുകളിൽ പതിച്ചു.

സ്വയം ബലേന യഥാർത്ഥത്തിൽ അതിന്റെ balenaEngine ഉള്ളിൽ അതേ ഡോക്കർ ഉപയോഗിക്കുന്നതിനാൽ ഇത് ഒഴിവാക്കപ്പെട്ടു.

ഇതൊക്കെയാണെങ്കിലും, ഞങ്ങൾ അവരുടെ ഉൽപ്പന്നം നിരന്തരം ഉപയോഗിക്കുന്നത് അവസാനിപ്പിച്ചതായി ഞാൻ ശ്രദ്ധിക്കുന്നു ബാലെഎന്നച്ചർ SD കാർഡുകളിലെ ഫ്ലാഷ് ഫേംവെയറിനായി - ഇതിനുള്ള ലളിതവും വളരെ സൗകര്യപ്രദവുമായ യൂട്ടിലിറ്റി.

അതിനാൽ, അവസാനം തിരഞ്ഞെടുപ്പ് വീണു മെൻഡർ. ഫേംവെയർ കൂട്ടിച്ചേർക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുമുള്ള ഒരു സമ്പൂർണ്ണ പ്ലാറ്റ്ഫോമാണ് മെൻഡർ.

മൊത്തത്തിൽ പ്ലാറ്റ്‌ഫോം മികച്ചതായി തോന്നുന്നു, പക്ഷേ മെൻഡർ ബിൽഡർ ഉപയോഗിച്ച് ഞങ്ങളുടെ ഫേംവെയറിന്റെ ശരിയായ പതിപ്പ് നിർമ്മിക്കാൻ ഞങ്ങൾക്ക് ഒന്നര ആഴ്ചയെടുത്തു.
അതിന്റെ ഉപയോഗത്തിന്റെ സങ്കീർണതകളിൽ നാം എത്രമാത്രം മുഴുകുന്നുവോ അത്രയധികം അത് പൂർണ്ണമായി വിന്യസിക്കാൻ ഞങ്ങൾക്ക് ഉണ്ടായിരുന്നതിനേക്കാൾ കൂടുതൽ സമയം ആവശ്യമാണെന്ന് വ്യക്തമായി.

അയ്യോ, ഞങ്ങളുടെ ഇറുകിയ സമയപരിധി അർത്ഥമാക്കുന്നത് മെൻഡറിന്റെ ഉപയോഗം ഉപേക്ഷിച്ച് അതിലും ലളിതമായ ഒന്ന് തിരഞ്ഞെടുക്കാൻ ഞങ്ങൾ നിർബന്ധിതരായി എന്നാണ്.

അസാധ്യം

ഞങ്ങളുടെ സാഹചര്യത്തിലെ ഏറ്റവും ലളിതമായ പരിഹാരം അൻസിബിൾ ഉപയോഗിക്കുക എന്നതായിരുന്നു. ആരംഭിക്കാൻ രണ്ട് പ്ലേബുക്കുകൾ മതിയായിരുന്നു.

അവരുടെ സാരം, ഞങ്ങൾ ഹോസ്റ്റിൽ നിന്ന് (CI സെർവർ) ssh വഴി ഞങ്ങളുടെ റാസ്‌ബെറിയിലേക്ക് കണക്റ്റുചെയ്‌ത് അവർക്ക് അപ്‌ഡേറ്റുകൾ വിതരണം ചെയ്തു എന്നതാണ്.

തുടക്കത്തിൽ തന്നെ, എല്ലാം ലളിതമായിരുന്നു - നിങ്ങൾ ഉപകരണങ്ങളുമായി ഒരേ നെറ്റ്വർക്കിൽ ഉണ്ടായിരിക്കണം, വൈഫൈ വഴിയാണ് പകരുന്നത്.

ഓഫീസിൽ ഒരേ നെറ്റ്‌വർക്കിലേക്ക് കണക്റ്റുചെയ്തിരിക്കുന്ന ഒരു ഡസൻ ടെസ്റ്റ് റാസ്‌ബെറികൾ ഉണ്ടായിരുന്നു, ഓരോ ഉപകരണത്തിനും ഒരു സ്റ്റാറ്റിക് ഐപി വിലാസവും അൻസിബിൾ ഇൻവെന്ററിയിൽ വ്യക്തമാക്കിയിട്ടുണ്ട്.

അവസാന ഉപകരണങ്ങളിലേക്ക് ഞങ്ങളുടെ മോണിറ്ററിംഗ് ഏജന്റിനെ എത്തിച്ചത് അൻസിബിൾ ആയിരുന്നു

3G / LTE

നിർഭാഗ്യവശാൽ, ഞങ്ങൾക്ക് യഥാർത്ഥ സ്‌കൂട്ടറുകൾ ലഭിക്കുന്നതിന് മുമ്പ് അൻസിബിളിനായുള്ള ഈ ഉപയോഗ കേസ് വികസന മോഡിൽ മാത്രമേ പ്രവർത്തിക്കൂ.

കാരണം, സ്കൂട്ടറുകൾ, നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, ഒരു Wi-Fi റൂട്ടറുമായി ബന്ധിപ്പിച്ചിരിക്കില്ല, നെറ്റ്‌വർക്കിൽ അപ്‌ഡേറ്റുകൾക്കായി നിരന്തരം കാത്തിരിക്കുന്നു.

വാസ്തവത്തിൽ, സ്കൂട്ടറുകൾക്ക് മൊബൈൽ 3G/LTE ഒഴികെയുള്ള ഒരു കണക്ഷനും ഉണ്ടായിരിക്കില്ല (അപ്പോഴും എല്ലായ്‌പ്പോഴും അല്ല).

കുറഞ്ഞ കണക്ഷൻ വേഗതയും അസ്ഥിരമായ ആശയവിനിമയവും പോലുള്ള നിരവധി പ്രശ്നങ്ങളും പരിമിതികളും ഇത് ഉടനടി അടിച്ചേൽപ്പിക്കുന്നു.

എന്നാൽ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം, ഒരു 3G/LTE നെറ്റ്‌വർക്കിൽ നമുക്ക് നെറ്റ്‌വർക്കിലേക്ക് നൽകിയിട്ടുള്ള ഒരു സ്റ്റാറ്റിക് ഐപിയെ ആശ്രയിക്കാൻ കഴിയില്ല എന്നതാണ്.

ചില സിം കാർഡ് ദാതാക്കൾ ഇത് ഭാഗികമായി പരിഹരിക്കുന്നു; സ്റ്റാറ്റിക് ഐപി വിലാസങ്ങളുള്ള IoT ഉപകരണങ്ങൾക്കായി രൂപകൽപ്പന ചെയ്ത പ്രത്യേക സിം കാർഡുകൾ പോലും ഉണ്ട്. എന്നാൽ ഞങ്ങൾക്ക് അത്തരം സിം കാർഡുകളിലേക്ക് ആക്‌സസ് ഇല്ലായിരുന്നു കൂടാതെ IP വിലാസങ്ങൾ ഉപയോഗിക്കാനും കഴിഞ്ഞില്ല.

തീർച്ചയായും, കോൺസൽ പോലെ എവിടെയെങ്കിലും IP വിലാസങ്ങളുടെ രജിസ്ട്രേഷൻ അല്ലെങ്കിൽ സേവന കണ്ടെത്തൽ നടത്താനുള്ള ആശയങ്ങൾ ഉണ്ടായിരുന്നു, പക്ഷേ ഞങ്ങൾക്ക് അത്തരം ആശയങ്ങൾ ഉപേക്ഷിക്കേണ്ടിവന്നു, കാരണം ഞങ്ങളുടെ പരിശോധനകളിൽ IP വിലാസം പലപ്പോഴും മാറാം, ഇത് വലിയ അസ്ഥിരതയിലേക്ക് നയിച്ചു.

ഇക്കാരണത്താൽ, മെട്രിക്‌സ് ഡെലിവറി ചെയ്യുന്നതിനുള്ള ഏറ്റവും സൗകര്യപ്രദമായ ഉപയോഗം പുൾ മോഡൽ ഉപയോഗിക്കുന്നതല്ല, അവിടെ ഞങ്ങൾ ആവശ്യമായ അളവുകൾക്കായുള്ള ഉപകരണങ്ങളിലേക്ക് പോകും, ​​പക്ഷേ ഉപകരണത്തിൽ നിന്ന് മെട്രിക്‌സ് നേരിട്ട് സെർവറിലേക്ക് എത്തിക്കുക.

വിപിഎൻ

ഈ പ്രശ്നത്തിനുള്ള പരിഹാരമായി, ഞങ്ങൾ VPN തിരഞ്ഞെടുത്തു - പ്രത്യേകം വയർഗാർഡ്.

വിപിഎൻ സെർവറിലേക്ക് കണക്റ്റുചെയ്‌തിരിക്കുന്ന സിസ്റ്റത്തിന്റെ തുടക്കത്തിൽ ക്ലയന്റുകൾ (സ്‌കൂട്ടറുകൾ) അവയുമായി ബന്ധിപ്പിക്കാൻ കഴിഞ്ഞു. ഈ ടണൽ അപ്‌ഡേറ്റുകൾ നൽകാൻ ഉപയോഗിച്ചു.

സൈദ്ധാന്തികമായി, നിരീക്ഷണത്തിനായി ഇതേ തുരങ്കം ഉപയോഗിക്കാമായിരുന്നു, എന്നാൽ അത്തരമൊരു കണക്ഷൻ ലളിതമായ പുഷ് എന്നതിനേക്കാൾ സങ്കീർണ്ണവും വിശ്വാസ്യത കുറവുമായിരുന്നു.

ക്ലൗഡ് ഉറവിടങ്ങൾ

അവസാനമായി, ഞങ്ങളുടെ ക്ലൗഡ് സേവനങ്ങളും ഡാറ്റാബേസുകളും നിരീക്ഷിക്കേണ്ടത് ആവശ്യമാണ്, കാരണം ഞങ്ങൾ അവയ്‌ക്കായി Kubernetes ഉപയോഗിക്കുന്നു, അതിനാൽ ക്ലസ്റ്ററിൽ നിരീക്ഷണം വിന്യസിക്കുന്നത് കഴിയുന്നത്ര ലളിതമാണ്. അനുയോജ്യമായി, ഉപയോഗിക്കുന്നത് ഹെൽം, വിന്യാസത്തിനായി, മിക്ക കേസുകളിലും ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു. കൂടാതെ, തീർച്ചയായും, ക്ലൗഡ് നിരീക്ഷിക്കാൻ നിങ്ങൾ സ്കൂട്ടറുകൾക്കുള്ള അതേ പരിഹാരങ്ങൾ ഉപയോഗിക്കേണ്ടതുണ്ട്.

നൽകിയത്

ഓ, ഞങ്ങൾ വിവരണം ക്രമീകരിച്ചതായി തോന്നുന്നു, അവസാനം നമുക്ക് ആവശ്യമുള്ളതിന്റെ ഒരു ലിസ്റ്റ് ഉണ്ടാക്കാം:

• ഒരു ദ്രുത പരിഹാരം, കാരണം വികസന പ്രക്രിയയിൽ ഇതിനകം നിരീക്ഷണം ആവശ്യമാണ്
• വോളിയം/അളവ് - നിരവധി മെട്രിക്കുകൾ ആവശ്യമാണ്
• ലോഗ് ശേഖരണം ആവശ്യമാണ്
• വിശ്വാസ്യത - വിജയത്തിന് ഡാറ്റ നിർണായകമാണ്
• നിങ്ങൾക്ക് പുൾ മോഡൽ ഉപയോഗിക്കാൻ കഴിയില്ല - നിങ്ങൾക്ക് പുഷ് ആവശ്യമാണ്
• ഞങ്ങൾക്ക് ഹാർഡ്‌വെയറിന്റെ മാത്രമല്ല, ക്ലൗഡിന്റെയും ഏകീകൃത നിരീക്ഷണം ആവശ്യമാണ്

അവസാന ചിത്രം ഇതുപോലെ കാണപ്പെട്ടു

സ്റ്റാക്ക് തിരഞ്ഞെടുക്കൽ

അതിനാൽ, ഒരു മോണിറ്ററിംഗ് സ്റ്റാക്ക് തിരഞ്ഞെടുക്കുന്നതിനുള്ള ചോദ്യം ഞങ്ങൾ അഭിമുഖീകരിച്ചു.

ഒന്നാമതായി, ഞങ്ങളുടെ എല്ലാ ആവശ്യങ്ങളും ഒരേസമയം ഉൾക്കൊള്ളുന്ന ഏറ്റവും പൂർണ്ണമായ ഓൾ-ഇൻ-വൺ സൊല്യൂഷനാണ് ഞങ്ങൾ തിരയുന്നത്, എന്നാൽ അതേ സമയം ഞങ്ങളുടെ ആവശ്യങ്ങൾക്കനുസരിച്ച് അതിന്റെ ഉപയോഗം ക്രമീകരിക്കാൻ പര്യാപ്തമായിരിക്കും. എന്നിരുന്നാലും, ഹാർഡ്‌വെയർ, ആർക്കിടെക്ചർ, ഡെഡ്‌ലൈനുകൾ എന്നിവയാൽ ഞങ്ങൾക്ക് നിരവധി നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തിയിട്ടുണ്ട്.

പോലുള്ള സമ്പൂർണ്ണ സംവിധാനങ്ങളിൽ തുടങ്ങി നിരവധി വൈവിധ്യമാർന്ന നിരീക്ഷണ പരിഹാരങ്ങളുണ്ട് നാഗോസ്, ഐസിംഗ അഥവാ zabbix ഫ്ലീറ്റ് മാനേജ്മെന്റിനുള്ള റെഡിമെയ്ഡ് സൊല്യൂഷനുകളിൽ അവസാനിക്കുന്നു.

തുടക്കത്തിൽ, രണ്ടാമത്തേത് ഞങ്ങൾക്ക് അനുയോജ്യമായ ഒരു പരിഹാരമായി തോന്നി, എന്നാൽ ചിലർക്ക് പൂർണ്ണമായ നിരീക്ഷണം ഇല്ലായിരുന്നു, മറ്റുള്ളവർക്ക് സ്വതന്ത്ര പതിപ്പുകളുടെ പരിമിതമായ കഴിവുകൾ ഉണ്ടായിരുന്നു, മറ്റുള്ളവർ ഞങ്ങളുടെ "ആഗ്രഹങ്ങൾ" കവർ ചെയ്തില്ല അല്ലെങ്കിൽ ഞങ്ങളുടെ സാഹചര്യങ്ങൾക്ക് അനുയോജ്യമല്ല. ചിലത് കേവലം കാലഹരണപ്പെട്ടതാണ്.

സമാനമായ നിരവധി പരിഹാരങ്ങൾ വിശകലനം ചെയ്ത ശേഷം, സമാനമായ ഒരു സ്റ്റാക്ക് സ്വയം കൂട്ടിച്ചേർക്കുന്നത് എളുപ്പവും വേഗവുമാകുമെന്ന നിഗമനത്തിലെത്തി. അതെ, പൂർണ്ണമായും റെഡിമെയ്ഡ് ഫ്ലീറ്റ് മാനേജുമെന്റ് പ്ലാറ്റ്ഫോം വിന്യസിക്കുന്നതിനേക്കാൾ ഇത് അൽപ്പം സങ്കീർണ്ണമായിരിക്കും, പക്ഷേ ഞങ്ങൾ വിട്ടുവീഴ്ച ചെയ്യേണ്ടതില്ല.

തീർച്ചയായും, എല്ലാ വലിയ സമൃദ്ധമായ പരിഹാരങ്ങളിലും, ഞങ്ങൾക്ക് പൂർണ്ണമായും അനുയോജ്യമായ ഒരു റെഡിമെയ്ഡ് ഇതിനകം തന്നെ ഉണ്ട്, എന്നാൽ ഞങ്ങളുടെ കാര്യത്തിൽ ഒരു നിശ്ചിത സ്റ്റാക്ക് സ്വന്തമായി കൂട്ടിച്ചേർക്കുകയും "നമുക്കുവേണ്ടി" ഇഷ്ടാനുസൃതമാക്കുകയും ചെയ്യുന്നത് വളരെ വേഗത്തിലായിരുന്നു. റെഡിമെയ്ഡ് ഉൽപ്പന്നങ്ങൾ പരിശോധിക്കുന്നു.

ഇതെല്ലാം ഉപയോഗിച്ച്, ഒരു മുഴുവൻ മോണിറ്ററിംഗ് പ്ലാറ്റ്‌ഫോമും സ്വയം കൂട്ടിച്ചേർക്കാൻ ഞങ്ങൾ ശ്രമിച്ചില്ല, മറിച്ച് ഏറ്റവും പ്രവർത്തനക്ഷമമായ “റെഡിമെയ്ഡ്” സ്റ്റാക്കുകൾക്കായി തിരയുകയായിരുന്നു, അവ വഴക്കത്തോടെ കോൺഫിഗർ ചെയ്യാനുള്ള കഴിവ് കൊണ്ട് മാത്രം.

(B)ELK?

യഥാർത്ഥത്തിൽ പരിഗണിക്കപ്പെട്ട ആദ്യത്തെ പരിഹാരം അറിയപ്പെടുന്ന ELK സ്റ്റാക്ക് ആയിരുന്നു.
വാസ്തവത്തിൽ, ഇതിനെ BELK എന്ന് വിളിക്കണം, കാരണം ഇതെല്ലാം ആരംഭിക്കുന്നത് ബീറ്റ്സിൽ നിന്നാണ് - https://www.elastic.co/what-is/elk-stack

തീർച്ചയായും, നിരീക്ഷണ മേഖലയിലെ ഏറ്റവും പ്രശസ്തവും ശക്തവുമായ പരിഹാരങ്ങളിലൊന്നാണ് ELK, അതിലുപരിയായി ലോഗുകൾ ശേഖരിക്കുന്നതിലും പ്രോസസ്സ് ചെയ്യുന്നതിലും.

ലോഗുകൾ ശേഖരിക്കുന്നതിനും പ്രോമിത്യൂസിൽ നിന്ന് ലഭിച്ച മെട്രിക്കുകളുടെ ദീർഘകാല സംഭരണത്തിനും ELK ഉപയോഗിക്കുമെന്ന് ഞങ്ങൾ ഉദ്ദേശിച്ചു.

ദൃശ്യവൽക്കരണത്തിനായി നിങ്ങൾക്ക് ഗ്രാഫാൻ ഉപയോഗിക്കാം.

വാസ്തവത്തിൽ, പുതിയ ELK സ്റ്റാക്കിന് മെട്രിക്കുകൾ സ്വതന്ത്രമായി ശേഖരിക്കാനാകും (മെട്രിക്ബീറ്റ്), കൂടാതെ കിബാനയ്ക്ക് അവ പ്രദർശിപ്പിക്കാനും കഴിയും.

എന്നിട്ടും, ELK തുടക്കത്തിൽ ലോഗുകളിൽ നിന്ന് വളർന്നു, ഇതുവരെ മെട്രിക്സിന്റെ പ്രവർത്തനത്തിന് ഗുരുതരമായ നിരവധി പോരായ്മകളുണ്ട്:

• പ്രോമിത്യൂസിനേക്കാൾ വളരെ പതുക്കെ
• പ്രോമിത്യൂസിനേക്കാൾ വളരെ കുറച്ച് സ്ഥലങ്ങളിലേക്ക് സംയോജിപ്പിക്കുന്നു
• അവർക്കായി അലേർട്ടുകൾ സജ്ജീകരിക്കുന്നത് ബുദ്ധിമുട്ടാണ്
• അളവുകൾ ധാരാളം ഇടം എടുക്കുന്നു
• കിബാനിൽ മെട്രിക്‌സ് ഉപയോഗിച്ച് ഡാഷ്‌ബോർഡുകൾ സജ്ജീകരിക്കുന്നത് ഗ്രാഫനേക്കാൾ സങ്കീർണ്ണമാണ്

പൊതുവേ, ELK ലെ മെട്രിക്‌സ് ഭാരമുള്ളതും മറ്റ് പരിഹാരങ്ങളെപ്പോലെ ഇതുവരെ സൗകര്യപ്രദവുമല്ല, അവയിൽ ഇപ്പോൾ പ്രോമിത്യൂസിനേക്കാൾ കൂടുതൽ ഉണ്ട്: TSDB, വിക്ടോറിയ മെട്രിക്സ്, കോർട്ടെക്സ് മുതലായവ. തീർച്ചയായും, ഒരു സമ്പൂർണ്ണ ഓൾ-ഇൻ-വൺ പരിഹാരം ഉടനടി ലഭിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, എന്നാൽ മെട്രിക്ബീറ്റിന്റെ കാര്യത്തിൽ വളരെയധികം വിട്ടുവീഴ്ചകൾ ഉണ്ടായിരുന്നു.

ELK സ്റ്റാക്കിന് തന്നെ നിരവധി ബുദ്ധിമുട്ടുള്ള നിമിഷങ്ങളുണ്ട്:

• നിങ്ങൾ ഒരു വലിയ അളവിലുള്ള ഡാറ്റ ശേഖരിക്കുകയാണെങ്കിൽ അത് ഭാരമുള്ളതാണ്, ചിലപ്പോൾ വളരെ ഭാരമുള്ളതാണ്
• നിങ്ങൾ ഇത് "പാചകം ചെയ്യണമെന്ന്" അറിയേണ്ടതുണ്ട് - നിങ്ങൾ അത് സ്കെയിൽ ചെയ്യണം, പക്ഷേ ഇത് ചെയ്യുന്നത് നിസ്സാരമല്ല
• ഒഴിവാക്കിയ സൗജന്യ പതിപ്പ് - സൗജന്യ പതിപ്പിന് സാധാരണ അലേർട്ടിംഗ് ഇല്ല, കൂടാതെ തിരഞ്ഞെടുക്കുന്ന സമയത്ത് ആധികാരികത ഇല്ലായിരുന്നു

അടുത്തിടെ അവസാന പോയിന്റ് മികച്ചതും അധികമായി മാറിയെന്ന് ഞാൻ പറയണം ഓപ്പൺ സോഴ്സ് എക്സ്-പാക്കിലെ ഔട്ട്പുട്ട് (ആധികാരികത ഉൾപ്പെടെ) വിലനിർണ്ണയ മാതൃക തന്നെ മാറാൻ തുടങ്ങി.

എന്നാൽ ഞങ്ങൾ ഈ പരിഹാരം വിന്യസിക്കാൻ പോകുന്ന സമയത്ത്, ഒരു മുന്നറിയിപ്പും ഉണ്ടായിരുന്നില്ല.
എലാസ്റ്റ് അലർട്ട് അല്ലെങ്കിൽ മറ്റ് കമ്മ്യൂണിറ്റി സൊല്യൂഷനുകൾ ഉപയോഗിച്ച് ഞങ്ങൾക്ക് എന്തെങ്കിലും നിർമ്മിക്കാൻ ശ്രമിക്കാമായിരുന്നു, പക്ഷേ മറ്റ് ബദലുകൾ പരിഗണിക്കാൻ ഞങ്ങൾ ഇപ്പോഴും തീരുമാനിച്ചു.

ലോകി - ഗ്രാഫാന - പ്രൊമിത്യൂസ്

നിലവിൽ, ഒരു മെട്രിക്സ് ദാതാവെന്ന നിലയിൽ പ്രോമിത്യൂസിനെ അടിസ്ഥാനമാക്കി ഒരു മോണിറ്ററിംഗ് സ്റ്റാക്ക് നിർമ്മിക്കുക, ലോഗുകൾക്കുള്ള ലോക്കി, ദൃശ്യവൽക്കരണത്തിനായി നിങ്ങൾക്ക് അതേ ഗ്രാഫാന ഉപയോഗിക്കാം.

നിർഭാഗ്യവശാൽ, പ്രോജക്റ്റിന്റെ വിൽപ്പന പൈലറ്റ് ആരംഭിക്കുന്ന സമയത്ത് (സെപ്റ്റംബർ-ഒക്ടോബർ 19), ലോകി ഇപ്പോഴും ബീറ്റ പതിപ്പ് 0.3-0.4-ലായിരുന്നു, വികസനം ആരംഭിക്കുന്ന സമയത്ത് ഇത് ഒരു പ്രൊഡക്ഷൻ സൊല്യൂഷനായി കണക്കാക്കാൻ കഴിഞ്ഞില്ല. എല്ലാം.

ഗുരുതരമായ പ്രോജക്‌ടുകളിൽ ലോകി ഉപയോഗിക്കുന്നതിൽ എനിക്ക് ഇതുവരെ പരിചയമില്ല, പക്ഷേ ബെയർ-മെറ്റലിനും ക്യൂബർനെറ്റസ് പോഡുകൾക്കും പ്രോംടെയിൽ (ലോഗുകൾ ശേഖരിക്കുന്നതിനുള്ള ഒരു ഏജന്റ്) മികച്ച രീതിയിൽ പ്രവർത്തിക്കുമെന്ന് എനിക്ക് പറയാൻ കഴിയും.

ടിക്ക് ചെയ്യുക

ഒരുപക്ഷേ ELK സ്റ്റാക്കിന് ഏറ്റവും യോഗ്യമായ (ഏകമായത്?) പൂർണ്ണമായ ഫീച്ചറുള്ള ബദലിനെ ഇപ്പോൾ TICK സ്റ്റാക്ക് എന്ന് മാത്രമേ വിളിക്കാൻ കഴിയൂ - Telegraf, InfluxDB, Chronograf, Kapacitor.

ചുവടെയുള്ള എല്ലാ ഘടകങ്ങളും ഞാൻ കൂടുതൽ വിശദമായി വിവരിക്കും, എന്നാൽ പൊതുവായ ആശയം ഇതാണ്:

• ടെലിഗ്രാഫ് - അളവുകൾ ശേഖരിക്കുന്നതിനുള്ള ഏജന്റ്
• InfluxDB - മെട്രിക്സ് ഡാറ്റാബേസ്
• കപ്പാസിറ്റർ - മുന്നറിയിപ്പ് നൽകുന്നതിനുള്ള തത്സമയ മെട്രിക്സ് പ്രോസസർ
• ക്രോണോഗ്രാഫ് - ദൃശ്യവൽക്കരണത്തിനുള്ള വെബ് പാനൽ

InfluxDB, Kapacitor, Chronograf എന്നിവയ്‌ക്കായി ഞങ്ങൾ വിന്യസിക്കാൻ ഉപയോഗിച്ചിരുന്ന ഔദ്യോഗിക ഹെൽം ചാർട്ടുകൾ ഉണ്ട്.

Influx 2.0 (ബീറ്റ) യുടെ ഏറ്റവും പുതിയ പതിപ്പിൽ, Kapacitor ഉം Chronograf ഉം InfluxDB-യുടെ ഭാഗമായിത്തീർന്നു, ഇനി വെവ്വേറെ നിലവിലില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

ടെലിഗ്രാഫ്

ടെലിഗ്രാഫ് ഒരു സ്റ്റേറ്റ് മെഷീനിൽ മെട്രിക്കുകൾ ശേഖരിക്കുന്നതിനുള്ള വളരെ ഭാരം കുറഞ്ഞ ഏജന്റാണ്.

അവൻ എല്ലാ കാര്യങ്ങളും ഒരു വലിയ തുക നിരീക്ഷിക്കാൻ കഴിയും nginx ഇതിനായി
സെർവർ മകള്.

ഇതിന് നിരവധി രസകരമായ ഗുണങ്ങളുണ്ട്:

• വേഗതയേറിയതും ഭാരം കുറഞ്ഞതും (ഗോയിൽ എഴുതിയത്)
  • കുറഞ്ഞ അളവിൽ വിഭവങ്ങൾ കഴിക്കുന്നു
• സ്ഥിരസ്ഥിതിയായി മെട്രിക്സ് പുഷ് ചെയ്യുക
• ആവശ്യമായ എല്ലാ അളവുകളും ശേഖരിക്കുന്നു
  • ക്രമീകരണങ്ങളൊന്നുമില്ലാതെ സിസ്റ്റം മെട്രിക്‌സ്
  • സെൻസറുകളിൽ നിന്നുള്ള വിവരങ്ങൾ പോലുള്ള ഹാർഡ്‌വെയർ മെട്രിക്‌സ്
  • നിങ്ങളുടെ സ്വന്തം മെട്രിക്‌സ് ചേർക്കുന്നത് വളരെ എളുപ്പമാണ്
• ബോക്‌സിന് പുറത്ത് ധാരാളം പ്ലഗിനുകൾ
• രേഖകൾ ശേഖരിക്കുന്നു

പുഷ് മെട്രിക്‌സ് ഞങ്ങൾക്ക് ആവശ്യമായതിനാൽ, മറ്റെല്ലാ നേട്ടങ്ങളും മനോഹരമായ കൂട്ടിച്ചേർക്കലുകളേക്കാൾ കൂടുതലായിരുന്നു.

ലോഗുകൾ ലോഗ് ചെയ്യുന്നതിന് അധിക യൂട്ടിലിറ്റികൾ ബന്ധിപ്പിക്കേണ്ട ആവശ്യമില്ലാത്തതിനാൽ, ഏജന്റ് തന്നെ ലോഗുകളുടെ ശേഖരണവും വളരെ സൗകര്യപ്രദമാണ്.

നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ ലോഗുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള ഏറ്റവും സൗകര്യപ്രദമായ അനുഭവം ഇൻഫ്ലക്സ് വാഗ്ദാനം ചെയ്യുന്നു സിസ്‌ലോഗ്.

നിങ്ങൾ ബാക്കിയുള്ള ICK സ്റ്റാക്ക് ഉപയോഗിക്കുന്നില്ലെങ്കിലും, അളവുകൾ ശേഖരിക്കുന്നതിനുള്ള മികച്ച ഏജന്റാണ് ടെലിഗ്രാഫ്.

മെട്രിക്കുകൾ എവിടെയും എഴുതാൻ കഴിയുന്നതിനാൽ, സൗകര്യാർത്ഥം ELK-ഉം മറ്റ് വിവിധ ടൈം-സീരീസ് ഡാറ്റാബേസുകളും ഉപയോഗിച്ച് പലരും ഇത് മറികടക്കുന്നു.

InfluxDB

InfluxDB ആണ് TICK സ്റ്റാക്കിന്റെ പ്രധാന കാതൽ, അതായത് മെട്രിക്കുകൾക്കായുള്ള ഒരു ടൈം സീരീസ് ഡാറ്റാബേസ്.
മെട്രിക്സിന് പുറമേ, ഇൻഫ്ലക്സിന് ലോഗുകളും സംഭരിക്കാൻ കഴിയും, എന്നിരുന്നാലും, സാരാംശത്തിൽ, അതിനുള്ള ലോഗുകൾ ഒരേ അളവുകൾ മാത്രമാണ്, സാധാരണ സംഖ്യാ സൂചകങ്ങൾക്ക് പകരം, പ്രധാന പ്രവർത്തനം ലോഗ് ടെക്സ്റ്റിന്റെ ഒരു വരിയാണ് നടത്തുന്നത്.

InfluxDB Go-യിലും എഴുതിയിരിക്കുന്നു, ഞങ്ങളുടെ (ഏറ്റവും ശക്തമായതല്ല) ക്ലസ്റ്ററിലെ ELK-യെ അപേക്ഷിച്ച് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു.

ഇൻഫ്‌ളക്‌സിന്റെ രസകരമായ ഒരു ഗുണം ഡാറ്റാ അന്വേഷണങ്ങൾക്കായി വളരെ സൗകര്യപ്രദവും സമ്പന്നവുമായ API ഉൾപ്പെടുന്നു, അത് ഞങ്ങൾ വളരെ സജീവമായി ഉപയോഗിച്ചു.

ദോഷങ്ങൾ - $$$ അല്ലെങ്കിൽ സ്കെയിലിംഗ്?

TICK സ്റ്റാക്കിന് ഞങ്ങൾ കണ്ടെത്തിയ ഒരു പോരായ്മ മാത്രമേയുള്ളൂ - അത് ഡാർലിംഗ്. അതിലും കൂടുതൽ.

പണമടച്ചുള്ള പതിപ്പിന് സൗജന്യ പതിപ്പിന് ഇല്ലാത്തത് എന്താണ്?

ഞങ്ങൾക്ക് മനസ്സിലാക്കാൻ കഴിയുന്നിടത്തോളം, TICK സ്റ്റാക്കിന്റെ പണമടച്ചുള്ള പതിപ്പും സൗജന്യവും തമ്മിലുള്ള ഒരേയൊരു വ്യത്യാസം സ്കെയിലിംഗ് കഴിവുകൾ മാത്രമാണ്.

അതായത്, ഉയർന്ന ലഭ്യതയിൽ മാത്രം നിങ്ങൾക്ക് ഒരു ക്ലസ്റ്റർ ഉയർത്താം എന്റർപ്രൈസ് പതിപ്പുകൾ.

നിങ്ങൾക്ക് പൂർണ്ണമായ എച്ച്എ വേണമെങ്കിൽ, ഒന്നുകിൽ പണം നൽകണം അല്ലെങ്കിൽ കുറച്ച് ക്രച്ചുകൾ ഉപയോഗിക്കണം. കുറച്ച് കമ്മ്യൂണിറ്റി പരിഹാരങ്ങളുണ്ട് - ഉദാഹരണത്തിന് influxdb-ha ഒരു സമർത്ഥമായ പരിഹാരം പോലെ കാണപ്പെടുന്നു, പക്ഷേ അത് ഉൽപ്പാദനത്തിന് അനുയോജ്യമല്ലെന്ന് എഴുതിയിരിക്കുന്നു, അതുപോലെ തന്നെ
influx-spout - NATS വഴി ഡാറ്റ പമ്പ് ചെയ്യുന്ന ഒരു ലളിതമായ പരിഹാരം (ഇത് സ്കെയിൽ ചെയ്യേണ്ടിവരും, പക്ഷേ ഇത് പരിഹരിക്കാനാകും).

ഖേദകരമാണ്, പക്ഷേ അവ രണ്ടും ഉപേക്ഷിച്ചതായി തോന്നുന്നു - പുതിയ കമ്മിറ്റുകളൊന്നുമില്ല, പുതിയ പതിപ്പായ Influx 2.0 ന്റെ ഉടൻ പ്രതീക്ഷിക്കുന്ന റിലീസാണ് പ്രശ്‌നം എന്ന് ഞാൻ കരുതുന്നു, അതിൽ പലതും വ്യത്യസ്തമായിരിക്കും (ഇതിനെക്കുറിച്ച് ഒരു വിവരവുമില്ല. ഇതുവരെ അതിൽ സ്കെയിലിംഗ്).

ഔദ്യോഗികമായി ഒരു സ്വതന്ത്ര പതിപ്പ് ഉണ്ട് റിലേ - വാസ്തവത്തിൽ, ഇത് ഒരു പ്രാകൃത എച്ച്എ ആണ്, എന്നാൽ സന്തുലിതാവസ്ഥയിലൂടെ മാത്രം,
എല്ലാ ഡാറ്റയും ലോഡ് ബാലൻസറിന് പിന്നിലെ എല്ലാ InfluxDB സംഭവങ്ങളിലേക്കും എഴുതപ്പെടും.
അവന് ചിലത് ഉണ്ട് അസൗകര്യങ്ങൾ പോയിന്റുകൾ ഓവർറൈറ്റുചെയ്യുന്നതിലെ സാധ്യമായ പ്രശ്‌നങ്ങളും മുൻകൂറായി മെട്രിക്കുകൾക്കായി അടിസ്ഥാനങ്ങൾ സൃഷ്ടിക്കേണ്ടതിന്റെ ആവശ്യകതയും പോലെ
(ഇൻഫ്ലക്സ് ഡിബിയുമായുള്ള സാധാരണ പ്രവർത്തന സമയത്ത് ഇത് യാന്ത്രികമായി സംഭവിക്കുന്നു).

കൂടാതെ ഷാർഡിംഗിനെ പിന്തുണയ്ക്കുന്നില്ല, നിങ്ങൾക്ക് ആവശ്യമില്ലാത്ത ഡ്യൂപ്ലിക്കേറ്റ് മെട്രിക്‌സിന് (പ്രോസസ്സിംഗും സ്റ്റോറേജും) അധിക ഓവർഹെഡ് എന്നാണ് ഇതിനർത്ഥം, എന്നാൽ അവയെ വേർതിരിക്കാൻ ഒരു മാർഗവുമില്ല.

വിക്ടോറിയ മെട്രിക്സ്?

തൽഫലമായി, പണമടച്ചുള്ള സ്കെയിലിംഗ് ഒഴികെ മറ്റെല്ലാ കാര്യങ്ങളിലും ഞങ്ങൾ TICK സ്റ്റാക്കിൽ പൂർണ്ണ സംതൃപ്തരാണെങ്കിലും, ശേഷിക്കുന്ന T_CK ഘടകങ്ങൾ ഉപേക്ഷിക്കുമ്പോൾ InfluxDB ഡാറ്റാബേസിന് പകരം വയ്ക്കാൻ കഴിയുന്ന എന്തെങ്കിലും സൗജന്യ പരിഹാരങ്ങൾ ഉണ്ടോ എന്ന് കാണാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

ധാരാളം ടൈം സീരീസ് ഡാറ്റാബേസുകൾ ഉണ്ട്, എന്നാൽ ഏറ്റവും പ്രതീക്ഷ നൽകുന്ന ഒന്ന് വിക്ടോറിയ മെട്രിക്സ് ആണ്, ഇതിന് നിരവധി ഗുണങ്ങളുണ്ട്:

• വേഗത്തിലും എളുപ്പത്തിലും, കുറഞ്ഞത് ഫലങ്ങൾ അനുസരിച്ച് മാനദണ്ഡങ്ങൾ
• ഒരു ക്ലസ്റ്റർ പതിപ്പ് ഉണ്ട്, അതിനെക്കുറിച്ച് ഇപ്പോൾ നല്ല അവലോകനങ്ങൾ പോലും ഉണ്ട്
  • അവൾക്ക് കീറാൻ കഴിയും
• InfluxDB പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്നു

വിക്ടോറിയയെ അടിസ്ഥാനമാക്കി പൂർണ്ണമായും ഇഷ്‌ടാനുസൃത സ്റ്റാക്ക് നിർമ്മിക്കാൻ ഞങ്ങൾ ഉദ്ദേശിച്ചിരുന്നില്ല, മാത്രമല്ല InfluxDB-യുടെ ഡ്രോപ്പ്-ഇൻ പകരമായി ഞങ്ങൾക്ക് ഇത് ഉപയോഗിക്കാമെന്നായിരുന്നു പ്രധാന പ്രതീക്ഷ.

നിർഭാഗ്യവശാൽ, ഇത് സാധ്യമല്ല, InfluxDB പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിലും, ഇത് മെട്രിക്‌സ് റെക്കോർഡിംഗിനായി മാത്രമേ പ്രവർത്തിക്കൂ - Prometheus API മാത്രമേ "പുറത്ത്" ലഭ്യമാകൂ, അതിനർത്ഥം അതിൽ ക്രോണോഗ്രാഫ് സജ്ജീകരിക്കാൻ കഴിയില്ല എന്നാണ്.

മാത്രമല്ല, മെട്രിക്‌സിന് സംഖ്യാ മൂല്യങ്ങൾ മാത്രമേ പിന്തുണയ്‌ക്കൂ (ഇഷ്‌ടാനുസൃത മെട്രിക്‌സിനായി ഞങ്ങൾ സ്‌ട്രിംഗ് മൂല്യങ്ങൾ ഉപയോഗിച്ചു - വിഭാഗത്തിൽ കൂടുതൽ അഡ്മിൻ പാനൽ).

വ്യക്തമായും, അതേ കാരണത്താൽ, ഇൻഫ്ലക്സ് പോലെയുള്ള ലോഗുകൾ VM-ന് സംഭരിക്കാൻ കഴിയില്ല.

കൂടാതെ, ഒപ്റ്റിമൽ പരിഹാരത്തിനായി തിരയുന്ന സമയത്ത്, വിക്ടോറിയ മെട്രിക്സ് ഇതുവരെ അത്ര പ്രചാരത്തിലായിരുന്നില്ല, ഡോക്യുമെന്റേഷൻ വളരെ ചെറുതും പ്രവർത്തനക്ഷമത ദുർബലവുമായിരുന്നു.
(ക്ലസ്റ്റർ പതിപ്പിന്റെയും ഷാർഡിംഗിന്റെയും വിശദമായ വിവരണം ഞാൻ ഓർക്കുന്നില്ല).

അടിസ്ഥാന തിരഞ്ഞെടുപ്പ്

തൽഫലമായി, പൈലറ്റിന് ഞങ്ങൾ ഇപ്പോഴും ഒരൊറ്റ InfluxDB നോഡിലേക്ക് സ്വയം പരിമിതപ്പെടുത്താൻ തീരുമാനിച്ചു.

ഈ തിരഞ്ഞെടുപ്പിന് നിരവധി പ്രധാന കാരണങ്ങളുണ്ട്:

• TICK സ്റ്റാക്കിന്റെ മുഴുവൻ പ്രവർത്തനവും ഞങ്ങൾ ശരിക്കും ഇഷ്ടപ്പെട്ടു
• ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ഇത് വിന്യസിക്കാൻ കഴിഞ്ഞു, അത് മികച്ച രീതിയിൽ പ്രവർത്തിച്ചു
• സമയപരിധി അവസാനിച്ചു, മറ്റ് ഓപ്ഷനുകൾ പരീക്ഷിക്കാൻ കൂടുതൽ സമയമില്ല.
• ഇത്രയും വലിയ ഭാരം ഞങ്ങൾ പ്രതീക്ഷിച്ചിരുന്നില്ല

പൈലറ്റിന്റെ ആദ്യ ഘട്ടത്തിനായി ഞങ്ങൾക്ക് ധാരാളം സ്‌കൂട്ടറുകൾ ഇല്ലായിരുന്നു, വികസന സമയത്ത് നടത്തിയ പരിശോധനയിൽ പ്രകടന പ്രശ്‌നങ്ങളൊന്നും കണ്ടെത്തിയില്ല.

അതിനാൽ, ഈ പ്രോജക്റ്റിനായി സ്കെയിലിംഗ് ആവശ്യമില്ലാതെ ഞങ്ങൾക്ക് ഒരു ഇൻഫ്ലക്സ് നോഡ് മതിയെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു (അവസാനം നിഗമനങ്ങൾ കാണുക).

ഞങ്ങൾ സ്റ്റാക്കും അടിത്തറയും തീരുമാനിച്ചു - ഇപ്പോൾ TICK സ്റ്റാക്കിന്റെ ശേഷിക്കുന്ന ഘടകങ്ങളെ കുറിച്ച്.

കപ്പാസിറ്റർ

കപ്പാസിറ്റർ TICK സ്റ്റാക്കിന്റെ ഭാഗമാണ്, ഡാറ്റാബേസിൽ പ്രവേശിക്കുന്ന മെട്രിക്കുകൾ തത്സമയം നിരീക്ഷിക്കാനും നിയമങ്ങളെ അടിസ്ഥാനമാക്കി വിവിധ പ്രവർത്തനങ്ങൾ ചെയ്യാനും കഴിയുന്ന ഒരു സേവനമാണ്.

പൊതുവേ, സാധ്യതയുള്ള അപാകത ട്രാക്കിംഗിനും മെഷീൻ ലേണിംഗിനുമുള്ള ഒരു ഉപകരണമായാണ് ഇത് സ്ഥാപിച്ചിരിക്കുന്നത് (ഈ ഫംഗ്ഷനുകൾക്ക് ആവശ്യക്കാരുണ്ടെന്ന് എനിക്ക് ഉറപ്പില്ല), എന്നാൽ അതിന്റെ ഉപയോഗത്തിന്റെ ഏറ്റവും പ്രചാരമുള്ള കേസ് കൂടുതൽ സാധാരണമാണ് - മുന്നറിയിപ്പ്.

അറിയിപ്പുകൾക്കായി ഞങ്ങൾ അത് ഉപയോഗിച്ചത് അങ്ങനെയാണ്. ഒരു പ്രത്യേക സ്‌കൂട്ടർ ഓഫ്‌ലൈനിൽ പോകുമ്പോൾ ഞങ്ങൾ സ്ലാക്ക് അലേർട്ടുകൾ സജ്ജീകരിച്ചു, സ്‌മാർട്ട് ചാർജറുകൾക്കും പ്രധാനപ്പെട്ട ഇൻഫ്രാസ്ട്രക്ചർ ഘടകങ്ങൾക്കും ഇതുതന്നെ ചെയ്‌തു.

പ്രശ്‌നങ്ങളോട് പെട്ടെന്ന് പ്രതികരിക്കാനും എല്ലാം സാധാരണ നിലയിലേക്ക് മടങ്ങിയെന്ന അറിയിപ്പുകൾ സ്വീകരിക്കാനും ഇത് സാധ്യമാക്കി.

ഒരു ലളിതമായ ഉദാഹരണം: ഞങ്ങളുടെ "ബോക്‌സ്" പവർ ചെയ്യാനുള്ള ഒരു അധിക ബാറ്ററി തകരാറിലായി അല്ലെങ്കിൽ ചില കാരണങ്ങളാൽ പവർ തീർന്നു; പുതിയൊരെണ്ണം ഇൻസ്റ്റാൾ ചെയ്യുന്നതിലൂടെ, കുറച്ച് സമയത്തിന് ശേഷം സ്‌കൂട്ടറിന്റെ പ്രവർത്തനം പുനഃസ്ഥാപിച്ചതായി ഞങ്ങൾക്ക് ഒരു അറിയിപ്പ് ലഭിക്കും.

ഇൻഫ്ലക്സിൽ 2.0 കപ്പാസിറ്റർ ഡിബിയുടെ ഭാഗമായി

ക്രോണോഗ്രാഫ്

മോണിറ്ററിംഗിനായി നിരവധി വ്യത്യസ്ത യുഐ സൊല്യൂഷനുകൾ ഞാൻ കണ്ടിട്ടുണ്ട്, എന്നാൽ പ്രവർത്തനക്ഷമതയുടെയും യുഎക്സിന്റെയും കാര്യത്തിൽ, ക്രോണോഗ്രാഫുമായി താരതമ്യപ്പെടുത്താൻ ഒന്നുമില്ല എന്ന് എനിക്ക് പറയാൻ കഴിയും.

ഞങ്ങൾ TICK സ്റ്റാക്ക് ഉപയോഗിക്കാൻ തുടങ്ങി, വിചിത്രമായി, ഗ്രഫാൻ ഒരു വെബ് ഇന്റർഫേസായി.
അതിന്റെ പ്രവർത്തനക്ഷമത ഞാൻ വിവരിക്കില്ല; എന്തും സജ്ജീകരിക്കുന്നതിനുള്ള വിശാലമായ സാധ്യതകൾ എല്ലാവർക്കും അറിയാം.

എന്നിരുന്നാലും, ഗ്രാഫാന ഇപ്പോഴും തികച്ചും സാർവത്രിക ഉപകരണമാണ്, അതേസമയം ക്രോണോഗ്രാഫ് പ്രധാനമായും രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് ഇൻഫ്ലക്സിനൊപ്പം ഉപയോഗിക്കാനാണ്.

തീർച്ചയായും, ഇതിന് നന്ദി, ക്രോണോഗ്രാഫിന് കൂടുതൽ ബുദ്ധിപരമോ സൗകര്യപ്രദമോ ആയ പ്രവർത്തനം താങ്ങാൻ കഴിയും.

ക്രോണോഗ്രാഫിനൊപ്പം പ്രവർത്തിക്കുന്നതിന്റെ പ്രധാന സൗകര്യം, എക്സ്പ്ലോറിലൂടെ നിങ്ങളുടെ ഇൻഫ്‌ളക്‌സ് ഡിബിയുടെ ഉൾവശങ്ങൾ കാണാനാകും എന്നതാണ്.

ഗ്രാഫാനയ്ക്ക് ഏതാണ്ട് സമാനമായ പ്രവർത്തനക്ഷമതയുണ്ടെന്ന് തോന്നുന്നു, എന്നാൽ വാസ്തവത്തിൽ, ക്രോണോഗ്രാഫിൽ ഒരു ഡാഷ്‌ബോർഡ് സജ്ജീകരിക്കുന്നത് കുറച്ച് മൗസ് ക്ലിക്കുകളിലൂടെ ചെയ്യാം (അതേ സമയം അവിടെയുള്ള വിഷ്വലൈസേഷൻ നോക്കുമ്പോൾ), ഗ്രാഫാനയിൽ നിങ്ങൾക്ക് താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ഉണ്ടാകും. JSON കോൺഫിഗറേഷൻ എഡിറ്റ് ചെയ്യാൻ (തീർച്ചയായും Chronograf നിങ്ങളുടെ കൈകൊണ്ട് കോൺഫിഗർ ചെയ്‌ത ഡാഷകൾ അപ്‌ലോഡ് ചെയ്യാനും ആവശ്യമെങ്കിൽ JSON ആയി എഡിറ്റ് ചെയ്യാനും അനുവദിക്കുന്നു - എന്നാൽ UI-ൽ സൃഷ്‌ടിച്ചതിന് ശേഷം എനിക്ക് ഒരിക്കലും അവ സ്പർശിക്കേണ്ടി വന്നിട്ടില്ല).

കിബാനയ്‌ക്ക് ഡാഷ്‌ബോർഡുകളും നിയന്ത്രണങ്ങളും സൃഷ്‌ടിക്കുന്നതിന് കൂടുതൽ സമ്പന്നമായ കഴിവുകളുണ്ട്, എന്നാൽ അത്തരം പ്രവർത്തനങ്ങൾക്കായുള്ള UX വളരെ സങ്കീർണ്ണമാണ്.

സൗകര്യപ്രദമായ ഒരു ഡാഷ്‌ബോർഡ് സൃഷ്‌ടിക്കാൻ കുറച്ച് നല്ല ധാരണ ആവശ്യമാണ്. ക്രോണോഗ്രാഫ് ഡാഷ്‌ബോർഡുകളുടെ പ്രവർത്തനക്ഷമത കുറവാണെങ്കിലും, അവ നിർമ്മിക്കുന്നതും ഇഷ്ടാനുസൃതമാക്കുന്നതും വളരെ ലളിതമാണ്.

മനോഹരമായ വിഷ്വൽ ശൈലി കൂടാതെ ഡാഷ്‌ബോർഡുകൾ യഥാർത്ഥത്തിൽ ഗ്രാഫാനയിലോ കിബാനയിലോ ഉള്ള ഡാഷ്‌ബോർഡുകളിൽ നിന്ന് വ്യത്യസ്തമല്ല:

അന്വേഷണ ജാലകം ഇതുപോലെ കാണപ്പെടുന്നു:

InfluxDB ഡാറ്റാബേസിലെ ഫീൽഡുകളുടെ തരങ്ങൾ അറിയുന്നത്, ക്രോണോഗ്രാഫ് തന്നെ ചിലപ്പോൾ സ്വയം ഒരു ചോദ്യം എഴുതുന്നതിനോ അല്ലെങ്കിൽ ശരാശരി പോലെ ശരിയായ അഗ്രഗേഷൻ ഫംഗ്‌ഷൻ തിരഞ്ഞെടുക്കുന്നതിനോ നിങ്ങളെ സഹായിക്കും എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

തീർച്ചയായും, ലോഗുകൾ കാണുന്നതിന് ക്രോണോഗ്രാഫ് കഴിയുന്നത്ര സൗകര്യപ്രദമാണ്. ഇത് ഇതുപോലെ കാണപ്പെടുന്നു:

ഡിഫോൾട്ടായി, ഇൻഫ്ലക്സ് ലോഗുകൾ സിസ്ലോഗ് ഉപയോഗിക്കുന്നതിന് അനുയോജ്യമായതാണ്, അതിനാൽ അവയ്ക്ക് ഒരു പ്രധാന പാരാമീറ്റർ ഉണ്ട് - തീവ്രത.

മുകളിലുള്ള ഗ്രാഫ് പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്; അതിൽ നിങ്ങൾക്ക് സംഭവിക്കുന്ന പിശകുകൾ കാണാനും തീവ്രത കൂടുതലാണെങ്കിൽ നിറം ഉടനടി വ്യക്തമായി കാണിക്കാനും കഴിയും.

രണ്ട് തവണ ഞങ്ങൾ പ്രധാനപ്പെട്ട ബഗുകൾ ഈ രീതിയിൽ പിടികൂടി, കഴിഞ്ഞ ആഴ്‌ചയിലെ ലോഗുകൾ കാണാൻ പോകുകയും ഒരു ചുവന്ന സ്പൈക്ക് കാണുകയും ചെയ്തു.

തീർച്ചയായും, അത്തരം പിശകുകൾക്കായി അലേർട്ടുകൾ സജ്ജീകരിക്കുന്നതാണ് നല്ലത്, കാരണം ഇതിനുള്ള എല്ലാം ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ഉണ്ടായിരുന്നു.

ഞങ്ങൾ ഇത് കുറച്ച് സമയത്തേക്ക് പോലും ഓണാക്കി, പക്ഷേ പൈലറ്റ് തയ്യാറാക്കുന്ന പ്രക്രിയയിൽ ഞങ്ങൾക്ക് ധാരാളം പിശകുകൾ ലഭിക്കുന്നുണ്ടെന്ന് മനസ്സിലായി (എൽടിഇ നെറ്റ്‌വർക്കിന്റെ ലഭ്യതയില്ലാത്ത സിസ്റ്റം ഉൾപ്പെടെ), ഇത് സ്ലാക്ക് ചാനലിനെയും "സ്പാം" ചെയ്തു. വളരെയധികം, ഒരു പ്രശ്നവും ഉണ്ടാക്കാതെ, വലിയ പ്രയോജനം.

ഇത്തരത്തിലുള്ള മിക്ക പിശകുകളും കൈകാര്യം ചെയ്യുകയും അവയുടെ തീവ്രത ക്രമീകരിക്കുകയും തുടർന്ന് അലേർട്ടിംഗ് പ്രവർത്തനക്ഷമമാക്കുകയും ചെയ്യുക എന്നതാണ് ശരിയായ പരിഹാരം.

ഈ രീതിയിൽ, പുതിയതോ പ്രധാനപ്പെട്ടതോ ആയ പിശകുകൾ മാത്രമേ സ്ലാക്കിൽ പോസ്റ്റുചെയ്യൂ. കർശനമായ സമയപരിധി കണക്കിലെടുത്ത് അത്തരമൊരു സജ്ജീകരണത്തിന് മതിയായ സമയം ഇല്ലായിരുന്നു.

പ്രാമാണീകരണം

OAuth, OIDC എന്നിവയെ പ്രാമാണീകരണമായി ക്രോണോഗ്രാഫ് പിന്തുണയ്ക്കുന്നുവെന്നതും എടുത്തുപറയേണ്ടതാണ്.

ഇത് വളരെ സൗകര്യപ്രദമാണ്, കാരണം ഇത് നിങ്ങളുടെ സെർവറിലേക്ക് എളുപ്പത്തിൽ അറ്റാച്ചുചെയ്യാനും പൂർണ്ണമായ SSO സൃഷ്ടിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

ഞങ്ങളുടെ കാര്യത്തിൽ, സെർവർ ആയിരുന്നു കീക്ലോക്ക് — ഇത് മോണിറ്ററിംഗിലേക്ക് കണക്റ്റുചെയ്യാൻ ഉപയോഗിച്ചു, എന്നാൽ അതേ സെർവർ തന്നെ സ്കൂട്ടറുകളും ബാക്ക്-എൻഡിലേക്കുള്ള അഭ്യർത്ഥനകളും പ്രാമാണീകരിക്കാനും ഉപയോഗിച്ചു.

"അഡ്മിൻ"

ഞാൻ വിവരിക്കുന്ന അവസാന ഘടകം Vue-യിലെ ഞങ്ങളുടെ സ്വയം എഴുതിയ "അഡ്മിൻ പാനൽ" ആണ്.
അടിസ്ഥാനപരമായി ഇത് ഞങ്ങളുടെ സ്വന്തം ഡാറ്റാബേസുകളിൽ നിന്നുള്ള സ്കൂട്ടർ വിവരങ്ങൾ, മൈക്രോ സർവീസുകൾ, InfluxDB-യിൽ നിന്നുള്ള മെട്രിക്സ് ഡാറ്റ എന്നിവയിൽ നിന്ന് ഒരേസമയം പ്രദർശിപ്പിക്കുന്ന ഒരു ഒറ്റപ്പെട്ട സേവനം മാത്രമാണ്.

കൂടാതെ, അടിയന്തര റീബൂട്ട് അല്ലെങ്കിൽ പിന്തുണാ ടീമിനായി വിദൂരമായി ഒരു ലോക്ക് തുറക്കൽ പോലുള്ള നിരവധി അഡ്മിനിസ്ട്രേറ്റീവ് ഫംഗ്ഷനുകൾ അവിടേക്ക് നീക്കി.

ഭൂപടങ്ങളും ഉണ്ടായിരുന്നു. ക്രോണോഗ്രാഫിന് പകരം ഞങ്ങൾ ഗ്രാഫാനയിൽ നിന്നാണ് ആരംഭിച്ചതെന്ന് ഞാൻ ഇതിനകം സൂചിപ്പിച്ചു - കാരണം ഗ്രാഫാനയ്ക്ക് പ്ലഗിനുകളുടെ രൂപത്തിൽ മാപ്പുകൾ ലഭ്യമാണ്, അതിൽ ഞങ്ങൾക്ക് സ്കൂട്ടറുകളുടെ കോർഡിനേറ്റുകൾ കാണാൻ കഴിയും. നിർഭാഗ്യവശാൽ, ഗ്രാഫാനയ്‌ക്കായുള്ള മാപ്പ് വിജറ്റുകളുടെ കഴിവുകൾ വളരെ പരിമിതമാണ്, തൽഫലമായി, കോർഡിനേറ്റുകൾ കാണുന്നതിന് മാത്രമല്ല, പ്രദർശിപ്പിക്കാനും കുറച്ച് ദിവസത്തിനുള്ളിൽ നിങ്ങളുടെ സ്വന്തം വെബ് ആപ്ലിക്കേഷൻ മാപ്പുകൾ ഉപയോഗിച്ച് എഴുതുന്നത് വളരെ എളുപ്പമായിരുന്നു. സ്കൂട്ടർ എടുത്ത റൂട്ട്, മാപ്പിലെ ഡാറ്റ ഫിൽട്ടർ ചെയ്യാൻ കഴിയും മുതലായവ. (ഒരു ലളിതമായ ഡാഷ്ബോർഡിൽ നമുക്ക് കോൺഫിഗർ ചെയ്യാൻ കഴിയാത്ത എല്ലാ പ്രവർത്തനങ്ങളും).

നിങ്ങളുടെ സ്വന്തം മെട്രിക്‌സ് എളുപ്പത്തിൽ സൃഷ്‌ടിക്കാനുള്ള കഴിവാണ് ഇൻഫ്‌ളക്‌സിന്റെ ഇതിനകം സൂചിപ്പിച്ച നേട്ടങ്ങളിലൊന്ന്.
വൈവിധ്യമാർന്ന സാഹചര്യങ്ങൾക്കായി ഇത് ഉപയോഗിക്കാൻ ഇത് അനുവദിക്കുന്നു.

ഞങ്ങൾ അവിടെ ഉപയോഗപ്രദമായ എല്ലാ വിവരങ്ങളും രേഖപ്പെടുത്താൻ ശ്രമിച്ചു: ബാറ്ററി ചാർജ്, ലോക്ക് സ്റ്റാറ്റസ്, സെൻസർ പ്രകടനം, ബ്ലൂടൂത്ത്, GPS, കൂടാതെ മറ്റ് പല ആരോഗ്യ പരിശോധനകളും.
ഞങ്ങൾ ഇതെല്ലാം അഡ്മിൻ പാനലിൽ പ്രദർശിപ്പിച്ചു.

തീർച്ചയായും, ഞങ്ങൾക്ക് ഏറ്റവും പ്രധാനപ്പെട്ട മാനദണ്ഡം സ്കൂട്ടറിന്റെ ഓപ്പറേറ്റിംഗ് അവസ്ഥയായിരുന്നു - വാസ്തവത്തിൽ, ഇൻഫ്ലക്സ് ഇത് തന്നെ പരിശോധിക്കുകയും നോഡുകൾ വിഭാഗത്തിലെ "പച്ച ലൈറ്റുകൾ" ഉപയോഗിച്ച് കാണിക്കുകയും ചെയ്യുന്നു.

ഫംഗ്ഷൻ വഴിയാണ് ഇത് ചെയ്യുന്നത് മരിച്ചവൻ - ഞങ്ങളുടെ ബോക്‌സിന്റെ പ്രകടനം മനസിലാക്കാനും അതേ അലേർട്ടുകൾ സ്ലാക്കിലേക്ക് അയയ്ക്കാനും ഞങ്ങൾ ഇത് ഉപയോഗിച്ചു.

വഴിയിൽ, ഞങ്ങൾ സ്കൂട്ടറുകൾക്ക് ദി സിംസൺസിലെ കഥാപാത്രങ്ങളുടെ പേരുകൾ നൽകി - അവയെ പരസ്പരം വേർതിരിച്ചറിയാൻ വളരെ സൗകര്യപ്രദമായിരുന്നു

പൊതുവേ, ഈ വഴി കൂടുതൽ രസകരമായിരുന്നു. "Guys, Smithers is dead!" തുടങ്ങിയ വാക്യങ്ങൾ നിരന്തരം കേട്ടുകൊണ്ടിരുന്നു.

സ്ട്രിംഗ് മെട്രിക്സ്

വിക്ടോറിയ മെട്രിക്സിന്റെ കാര്യത്തിലെന്നപോലെ, സംഖ്യാ മൂല്യങ്ങൾ മാത്രമല്ല സംഭരിക്കാൻ InfluxDB നിങ്ങളെ അനുവദിക്കുന്നത് പ്രധാനമാണ്.

ഇത് അത്ര പ്രധാനമല്ലെന്ന് തോന്നുന്നു - എല്ലാത്തിനുമുപരി, ലോഗുകൾ കൂടാതെ, ഏതെങ്കിലും മെട്രിക്സ് അക്കങ്ങളുടെ രൂപത്തിൽ സൂക്ഷിക്കാൻ കഴിയുമോ (അറിയപ്പെടുന്ന സംസ്ഥാനങ്ങൾക്ക് മാപ്പിംഗ് ചേർക്കുക - ഒരു തരം enum)?

ഞങ്ങളുടെ കാര്യത്തിൽ, സ്ട്രിംഗ് മെട്രിക്‌സ് വളരെ ഉപയോഗപ്രദമായ ഒരു സാഹചര്യമെങ്കിലും ഉണ്ടായിരുന്നു.
ഞങ്ങളുടെ "സ്മാർട്ട് ചാർജറുകളുടെ" വിതരണക്കാരൻ ഒരു മൂന്നാം കക്ഷിയായിരുന്നു, വികസന പ്രക്രിയയിലും ഈ ചാർജറുകൾക്ക് നൽകാൻ കഴിയുന്ന വിവരങ്ങളിലും ഞങ്ങൾക്ക് നിയന്ത്രണമില്ലായിരുന്നു.

തൽഫലമായി, ചാർജിംഗ് API ആദർശത്തിൽ നിന്ന് വളരെ അകലെയായിരുന്നു, എന്നാൽ പ്രധാന പ്രശ്നം ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും അവരുടെ അവസ്ഥ മനസ്സിലാക്കാൻ കഴിഞ്ഞില്ല എന്നതാണ്.

ഇവിടെയാണ് സഹായത്തിനെത്തിയത്. InfluxDB ഡാറ്റാബേസ് ഫീൽഡിലേക്ക് ഞങ്ങൾക്ക് വന്ന സ്ട്രിംഗ് സ്റ്റാറ്റസ് മാറ്റങ്ങളില്ലാതെ ഞങ്ങൾ ലളിതമായി എഴുതി.

കുറച്ച് സമയത്തേക്ക്, "ഓൺലൈൻ", "ഓഫ്‌ലൈൻ" തുടങ്ങിയ മൂല്യങ്ങൾ മാത്രമേ അവിടെ ലഭിച്ചിട്ടുള്ളൂ, അതിന്റെ അടിസ്ഥാനത്തിൽ ഞങ്ങളുടെ അഡ്മിൻ പാനലിൽ വിവരങ്ങൾ പ്രദർശിപ്പിക്കുകയും അറിയിപ്പുകൾ Slack-ലേക്ക് അയയ്ക്കുകയും ചെയ്തു. എന്നിരുന്നാലും, ചില ഘട്ടങ്ങളിൽ, "വിച്ഛേദിക്കപ്പെട്ടത്" പോലുള്ള മൂല്യങ്ങളും അവിടെ പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങി.

പിന്നീട് തെളിഞ്ഞതുപോലെ, ഒരു നിശ്ചിത എണ്ണം ശ്രമങ്ങൾക്ക് ശേഷം ചാർജറിന് സെർവറുമായി ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, കണക്ഷൻ നഷ്ടപ്പെട്ടതിന് ശേഷം ഒരിക്കൽ ഈ നില അയച്ചു.

അതിനാൽ, ഞങ്ങൾ ഒരു നിശ്ചിത മൂല്യങ്ങൾ മാത്രമേ ഉപയോഗിച്ചിട്ടുള്ളൂവെങ്കിൽ, ശരിയായ സമയത്ത് ഫേംവെയറിൽ ഈ മാറ്റങ്ങൾ ഞങ്ങൾ കാണാനിടയില്ല.

പൊതുവേ, സ്ട്രിംഗ് മെട്രിക്‌സ് ഉപയോഗത്തിന് കൂടുതൽ സാധ്യതകൾ നൽകുന്നു; നിങ്ങൾക്ക് അവയിൽ ഏത് വിവരവും രേഖപ്പെടുത്താനാകും. എന്നിരുന്നാലും, തീർച്ചയായും, നിങ്ങൾ ഈ ഉപകരണം ശ്രദ്ധാപൂർവ്വം ഉപയോഗിക്കേണ്ടതുണ്ട്.

സാധാരണ മെട്രിക്കുകൾക്ക് പുറമേ, InfluxDB-യിൽ GPS ലൊക്കേഷൻ വിവരങ്ങളും ഞങ്ങൾ രേഖപ്പെടുത്തി. ഞങ്ങളുടെ അഡ്മിൻ പാനലിലെ സ്കൂട്ടറുകളുടെ സ്ഥാനം നിരീക്ഷിക്കുന്നതിന് ഇത് അവിശ്വസനീയമാംവിധം ഉപയോഗപ്രദമായിരുന്നു.
വാസ്തവത്തിൽ, ഞങ്ങൾക്ക് ആവശ്യമുള്ള നിമിഷത്തിൽ എവിടെയാണെന്നും ഏത് സ്കൂട്ടറാണെന്നും ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും അറിയാമായിരുന്നു.

ഞങ്ങൾ ഒരു സ്കൂട്ടറിനായി തിരയുമ്പോൾ ഇത് ഞങ്ങൾക്ക് വളരെ ഉപയോഗപ്രദമായിരുന്നു (അവസാനം നിഗമനങ്ങൾ കാണുക).

അടിസ്ഥാന സൗകര്യങ്ങളുടെ നിരീക്ഷണം

സ്കൂട്ടറുകൾക്ക് പുറമേ, ഞങ്ങളുടെ മുഴുവൻ (പകരം വിപുലമായ) അടിസ്ഥാന സൗകര്യങ്ങളും നിരീക്ഷിക്കേണ്ടതുണ്ട്.

വളരെ സാധാരണമായ ഒരു വാസ്തുവിദ്യ ഇതുപോലെ കാണപ്പെടുന്നു:

ഞങ്ങൾ ഒരു പ്യുവർ മോണിറ്ററിംഗ് സ്റ്റാക്ക് ഹൈലൈറ്റ് ചെയ്യുകയാണെങ്കിൽ, അത് ഇതുപോലെ കാണപ്പെടുന്നു:

ഞങ്ങൾ ക്ലൗഡിൽ പരിശോധിക്കാൻ ആഗ്രഹിക്കുന്നത്:

• ഡാറ്റാബേസുകൾ
• കീക്ലോക്ക്
• മൈക്രോസർവീസുകൾ

ഞങ്ങളുടെ എല്ലാ ക്ലൗഡ് സേവനങ്ങളും കുബർനെറ്റസിൽ സ്ഥിതി ചെയ്യുന്നതിനാൽ, അതിന്റെ അവസ്ഥയെക്കുറിച്ചുള്ള വിവരങ്ങൾ ശേഖരിക്കുന്നത് നന്നായിരിക്കും.

ഭാഗ്യവശാൽ, ടെലിഗ്രാഫിന് കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ അവസ്ഥയെക്കുറിച്ച് ധാരാളം അളവുകൾ ശേഖരിക്കാൻ കഴിയും, കൂടാതെ ക്രോണോഗ്രാഫ് ഉടൻ തന്നെ ഇതിനായി മനോഹരമായ ഡാഷ്‌ബോർഡുകൾ വാഗ്ദാനം ചെയ്യുന്നു.

ഞങ്ങൾ പ്രധാനമായും പോഡുകളുടെ പ്രകടനവും മെമ്മറി ഉപഭോഗവും നിരീക്ഷിച്ചു. വീഴ്ചയുണ്ടായാൽ, സ്ലാക്കിൽ അലേർട്ടുകൾ.

കുബർനെറ്റസിൽ പോഡുകൾ ട്രാക്ക് ചെയ്യാൻ രണ്ട് വഴികളുണ്ട്: ഡെമോൺസെറ്റ്, സൈഡ്കാർ.
രണ്ട് രീതികളും വിശദമായി വിവരിച്ചിരിക്കുന്നു ഈ ബ്ലോഗ് പോസ്റ്റിൽ.

ഞങ്ങൾ ടെലിഗ്രാഫ് സൈഡ്കാർ ഉപയോഗിച്ചു, മെട്രിക്കുകൾക്ക് പുറമേ, പോഡ് ലോഗുകൾ ശേഖരിച്ചു.

ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾക്ക് ലോഗുകൾ ഉപയോഗിച്ച് ടിങ്കർ ചെയ്യേണ്ടിവന്നു. ഡോക്കർ എപിഐയിൽ നിന്ന് ടെലിഗ്രാഫിന് ലോഗുകൾ പിൻവലിക്കാൻ കഴിയുമെന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും, ഞങ്ങളുടെ എൻഡ് ഡിവൈസുകൾക്കൊപ്പം ലോഗുകളുടെ ഒരു ഏകീകൃത ശേഖരവും ഇതിനായി കണ്ടെയ്‌നറുകൾക്കായി കോൺഫിഗർ ചെയ്ത സിസ്‌ലോഗും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഒരുപക്ഷേ ഈ പരിഹാരം മനോഹരമായിരുന്നില്ല, പക്ഷേ അതിന്റെ പ്രവർത്തനത്തെക്കുറിച്ച് പരാതികളൊന്നും ഉണ്ടായിരുന്നില്ല, കൂടാതെ ക്രോണോഗ്രാഫിൽ ലോഗുകൾ നന്നായി പ്രദർശിപ്പിച്ചു.

മോണിറ്റർ മോണിറ്ററിംഗ് ???

അവസാനം, മോണിറ്ററിംഗ് മോണിറ്ററിംഗ് സിസ്റ്റങ്ങളുടെ പഴക്കമുള്ള ചോദ്യം ഉയർന്നു, പക്ഷേ ഭാഗ്യവശാൽ, അല്ലെങ്കിൽ നിർഭാഗ്യവശാൽ, ഞങ്ങൾക്ക് ഇതിന് വേണ്ടത്ര സമയമില്ല.

ടെലിഗ്രാഫിന് സ്വന്തം മെട്രിക്‌സ് അയയ്‌ക്കാനോ ഇൻഫ്‌ളക്‌സ്‌ഡിബി ഡാറ്റാബേസിൽ നിന്ന് മെട്രിക്‌സ് ശേഖരിക്കാനോ ഒരേ ഇൻഫ്‌ളക്‌സിലേക്കോ മറ്റെവിടെയെങ്കിലുമോ അയയ്‌ക്കാനാകുമെങ്കിലും.

കണ്ടെത്തലുകൾ

പൈലറ്റിന്റെ ഫലങ്ങളിൽ നിന്ന് ഞങ്ങൾ എന്ത് നിഗമനങ്ങളിൽ എത്തി?

നിങ്ങൾക്ക് എങ്ങനെ നിരീക്ഷണം നടത്താൻ കഴിയും?

ഒന്നാമതായി, TICK സ്റ്റാക്ക് ഞങ്ങളുടെ പ്രതീക്ഷകൾ പൂർണ്ണമായും നിറവേറ്റുകയും ഞങ്ങൾ ആദ്യം പ്രതീക്ഷിച്ചതിലും കൂടുതൽ അവസരങ്ങൾ നൽകുകയും ചെയ്തു.

ഞങ്ങൾക്ക് ആവശ്യമായ എല്ലാ പ്രവർത്തനങ്ങളും ഉണ്ടായിരുന്നു. ഞങ്ങൾ അത് ഉപയോഗിച്ച് ചെയ്തതെല്ലാം പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിച്ചു.

ഉത്പാദനക്ഷമത

സ്വതന്ത്ര പതിപ്പിലെ TICK സ്റ്റാക്കിന്റെ പ്രധാന പ്രശ്നം സ്കെയിലിംഗ് കഴിവുകളുടെ അഭാവമാണ്. ഇത് ഞങ്ങൾക്ക് ഒരു പ്രശ്നമായിരുന്നില്ല.

ഞങ്ങൾ കൃത്യമായ ലോഡ് ഡാറ്റ/കണക്കുകൾ ശേഖരിച്ചില്ല, എന്നാൽ ഞങ്ങൾ ഒരേ സമയം ഏകദേശം 30 സ്കൂട്ടറുകളിൽ നിന്ന് ഡാറ്റ ശേഖരിച്ചു.

ഓരോരുത്തരും മൂന്ന് ഡസനിലധികം മെട്രിക്കുകൾ ശേഖരിച്ചു. അതേ സമയം, ഉപകരണങ്ങളിൽ നിന്നുള്ള ലോഗുകൾ ശേഖരിച്ചു. ഓരോ 10 സെക്കൻഡിലും ഡാറ്റ ശേഖരണവും അയയ്‌ക്കലും നടക്കുന്നു.

പൈലറ്റിന്റെ ഒന്നര ആഴ്ചയ്ക്ക് ശേഷം, “ബാല്യകാല പ്രശ്‌നങ്ങളുടെ” ഭൂരിഭാഗവും ശരിയാക്കുകയും ഏറ്റവും പ്രധാനപ്പെട്ട പ്രശ്‌നങ്ങൾ ഇതിനകം പരിഹരിക്കുകയും ചെയ്‌തപ്പോൾ, സെർവറിലേക്ക് ഡാറ്റ അയയ്‌ക്കുന്നതിന്റെ ആവൃത്തി ഞങ്ങൾക്ക് കുറയ്ക്കേണ്ടി വന്നു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. 30 സെക്കൻഡ്. ഞങ്ങളുടെ LTE സിം കാർഡുകളിലെ ട്രാഫിക് പെട്ടെന്ന് അപ്രത്യക്ഷമാകാൻ തുടങ്ങിയതിനാൽ ഇത് ആവശ്യമായി വന്നു.

ട്രാഫിക്കിന്റെ ഭൂരിഭാഗവും ലോഗുകൾ ഉപയോഗിച്ചു; മെട്രിക്‌സ് തന്നെ, 10 സെക്കൻഡ് ഇടവേളയിൽ പോലും, പ്രായോഗികമായി അത് പാഴാക്കിയില്ല.

തൽഫലമായി, കുറച്ച് സമയത്തിന് ശേഷം ഞങ്ങൾ ഉപകരണങ്ങളിലെ ലോഗുകളുടെ ശേഖരണം പൂർണ്ണമായും പ്രവർത്തനരഹിതമാക്കി, കാരണം നിരന്തരമായ ശേഖരണമില്ലാതെ പോലും നിർദ്ദിഷ്ട പ്രശ്നങ്ങൾ ഇതിനകം തന്നെ വ്യക്തമായിരുന്നു.

ചില സന്ദർഭങ്ങളിൽ, ലോഗുകൾ കാണുന്നത് ഇപ്പോഴും ആവശ്യമാണെങ്കിൽ, ഞങ്ങൾ VPN വഴി WireGuard വഴി കണക്റ്റുചെയ്‌തു.

ഓരോ പ്രത്യേക പരിതസ്ഥിതിയും പരസ്പരം വേർപെടുത്തിയിട്ടുണ്ടെന്നും മുകളിൽ വിവരിച്ച ലോഡ് ഉൽപാദന അന്തരീക്ഷത്തിന് മാത്രം പ്രസക്തമാണെന്നും ഞാൻ കൂട്ടിച്ചേർക്കും.

വികസന പരിതസ്ഥിതിയിൽ, ഓരോ 10 സെക്കൻഡിലും ഡാറ്റ ശേഖരിക്കുന്നത് തുടരുന്ന ഒരു പ്രത്യേക InfluxDB ഉദാഹരണം ഞങ്ങൾ ഉയർത്തി, പ്രകടന പ്രശ്‌നങ്ങളൊന്നും ഞങ്ങൾ നേരിട്ടില്ല.

ടിക്ക് - ചെറുകിട ഇടത്തരം പ്രോജക്റ്റുകൾക്ക് അനുയോജ്യം

ഈ വിവരങ്ങളുടെ അടിസ്ഥാനത്തിൽ, താരതമ്യേന ചെറിയ പ്രോജക്റ്റുകൾക്കോ ​​അല്ലെങ്കിൽ ഹൈലോഡ് പ്രതീക്ഷിക്കാത്ത പ്രോജക്റ്റുകൾക്കോ ​​ടിക്ക് സ്റ്റാക്ക് അനുയോജ്യമാണെന്ന് ഞാൻ നിഗമനം ചെയ്യുന്നു.

നിങ്ങൾക്ക് ആയിരക്കണക്കിന് പോഡുകളോ നൂറുകണക്കിന് മെഷീനുകളോ ഇല്ലെങ്കിൽ, ഒരു InfluxDB ഉദാഹരണം പോലും ലോഡ് നന്നായി കൈകാര്യം ചെയ്യും.

ചില സന്ദർഭങ്ങളിൽ, ഒരു പ്രാകൃതമായ ഉയർന്ന ലഭ്യത പരിഹാരമെന്ന നിലയിൽ ഇൻഫ്ലക്സ് റിലേയിൽ നിങ്ങൾ തൃപ്തരായിരിക്കാം.

കൂടാതെ, തീർച്ചയായും, "ലംബമായ" സ്കെയിലിംഗ് സജ്ജീകരിക്കുന്നതിൽ നിന്നും വ്യത്യസ്ത തരം മെട്രിക്സുകൾക്കായി വ്യത്യസ്ത സെർവറുകൾ അനുവദിക്കുന്നതിൽ നിന്നും ആരും നിങ്ങളെ തടയുന്നില്ല.

മോണിറ്ററിംഗ് സേവനങ്ങളിൽ പ്രതീക്ഷിക്കുന്ന ലോഡിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഉറപ്പില്ലെങ്കിൽ, അല്ലെങ്കിൽ നിങ്ങൾക്ക് വളരെ "കനത്ത" ആർക്കിടെക്ചർ ഉണ്ടെന്ന് ഉറപ്പുണ്ടെങ്കിൽ, TICK സ്റ്റാക്കിന്റെ സൗജന്യ പതിപ്പ് ഉപയോഗിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല.

തീർച്ചയായും, ഒരു ലളിതമായ പരിഹാരം വാങ്ങുക എന്നതാണ് InfluxDB എന്റർപ്രൈസ് - എന്നാൽ ഇവിടെ എനിക്ക് എങ്ങനെയെങ്കിലും അഭിപ്രായം പറയാൻ കഴിയില്ല, കാരണം എനിക്ക് തന്നെ സൂക്ഷ്മതകൾ പരിചിതമല്ല. ഇത് വളരെ ചെലവേറിയതും ചെറുകിട കമ്പനികൾക്ക് തീർച്ചയായും അനുയോജ്യമല്ലാത്തതുമാണ് എന്നതിന് പുറമെ.

ഈ സാഹചര്യത്തിൽ, ഇന്ന്, വിക്ടോറിയ മെട്രിക്‌സ് വഴി മെട്രിക്‌സ് ശേഖരിക്കാനും ലോകി ഉപയോഗിച്ചുള്ള ലോഗുകൾ നോക്കാനും ഞാൻ ശുപാർശ ചെയ്യുന്നു.

ശരിയാണ്, റെഡിമെയ്ഡ് ടിക്കിനെ അപേക്ഷിച്ച് ലോക്കി/ഗ്രാഫാന വളരെ സൗകര്യപ്രദമല്ല (അവരുടെ മികച്ച വൈദഗ്ധ്യം കാരണം) എന്നാൽ അവ സൗജന്യമാണെന്ന് ഞാൻ വീണ്ടും റിസർവേഷൻ ചെയ്യും.

പ്രധാനപ്പെട്ട: ഇവിടെ വിവരിച്ചിരിക്കുന്ന എല്ലാ വിവരങ്ങളും ഇൻഫ്ലക്സ് 1.8 പതിപ്പിന് പ്രസക്തമാണ്, ഇപ്പോൾ ഇൻഫ്ലക്സ് 2.0 പുറത്തിറങ്ങാൻ പോകുന്നു.

യുദ്ധസാഹചര്യങ്ങളിൽ ഇത് പരീക്ഷിക്കാൻ എനിക്ക് അവസരം ലഭിച്ചിട്ടില്ലെങ്കിലും മെച്ചപ്പെടുത്തലുകളെ കുറിച്ച് നിഗമനങ്ങളിൽ എത്തിച്ചേരാൻ പ്രയാസമാണ്, ഇന്റർഫേസ് തീർച്ചയായും കൂടുതൽ മെച്ചപ്പെട്ടിട്ടുണ്ട്, ആർക്കിടെക്ചർ ലളിതമാക്കിയിരിക്കുന്നു (കപ്പാസിറ്ററും ക്രോണോഗ്രാഫും ഇല്ലാതെ),
ടെംപ്ലേറ്റുകൾ പ്രത്യക്ഷപ്പെട്ടു ("കൊലയാളി സവിശേഷത" - നിങ്ങൾക്ക് ഫോർട്ട്‌നൈറ്റിൽ കളിക്കാരെ ട്രാക്ക് ചെയ്യാനും നിങ്ങളുടെ പ്രിയപ്പെട്ട കളിക്കാരൻ ഒരു ഗെയിമിൽ വിജയിക്കുമ്പോൾ അറിയിപ്പുകൾ സ്വീകരിക്കാനും കഴിയും). പക്ഷേ, നിർഭാഗ്യവശാൽ, ഇപ്പോൾ, ഞങ്ങൾ ആദ്യ പതിപ്പ് തിരഞ്ഞെടുത്ത പ്രധാന കാര്യം പതിപ്പ് 2 ന് ഇല്ല - ലോഗ് ശേഖരണമില്ല.

ഈ പ്രവർത്തനം Influx 2.0-ലും ദൃശ്യമാകും, എന്നാൽ ഏകദേശ സമയപരിധികൾ പോലും ഞങ്ങൾക്ക് കണ്ടെത്താനായില്ല.

എങ്ങനെ IoT പ്ലാറ്റ്‌ഫോമുകൾ ഉണ്ടാക്കരുത് (ഇപ്പോൾ)

അവസാനം, പൈലറ്റ് വിക്ഷേപിച്ച ശേഷം, ഞങ്ങളുടെ മാനദണ്ഡങ്ങൾക്കനുസൃതമായി അനുയോജ്യമായ ഒരു ബദലിന്റെ അഭാവത്തിൽ ഞങ്ങൾ സ്വന്തമായി ഒരു പൂർണ്ണമായ IoT സ്റ്റാക്ക് കൂട്ടിച്ചേർക്കുന്നു.

എന്നിരുന്നാലും, അടുത്തിടെ ഇത് ബീറ്റ പതിപ്പിൽ ലഭ്യമാണ് ഓപ്പൺബലേന - ഞങ്ങൾ പ്രോജക്റ്റ് നിർമ്മിക്കാൻ തുടങ്ങുമ്പോൾ അവൾ അവിടെ ഇല്ലായിരുന്നു എന്നത് ഖേദകരമാണ്.

അന്തിമഫലത്തിലും ഞങ്ങൾ സ്വയം സമാഹരിച്ച Ansible + TICK + WireGuard അടിസ്ഥാനമാക്കിയുള്ള പ്ലാറ്റ്‌ഫോമിലും ഞങ്ങൾ പൂർണ്ണമായും സംതൃപ്തരാണ്. എന്നാൽ ഇന്ന്, നിങ്ങളുടെ സ്വന്തം IoT പ്ലാറ്റ്ഫോം നിർമ്മിക്കാൻ ശ്രമിക്കുന്നതിന് മുമ്പ് ബലേനയെ അടുത്തറിയാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു.

കാരണം ആത്യന്തികമായി ഞങ്ങൾ ചെയ്ത മിക്ക കാര്യങ്ങളും ഇതിന് ചെയ്യാൻ കഴിയും, കൂടാതെ OpenBalena സ്വതന്ത്രവും ഓപ്പൺ സോഴ്‌സുമാണ്.

അപ്‌ഡേറ്റുകൾ അയയ്‌ക്കുക മാത്രമല്ല, ഒരു ഐഒടി പരിതസ്ഥിതിയിൽ ഉപയോഗിക്കുന്നതിനായി ഒരു VPN ഇതിനകം തന്നെ ബിൽറ്റ് ഇൻ ചെയ്‌തിരിക്കുന്നതും എങ്ങനെയെന്ന് ഇതിന് ഇതിനകം തന്നെ അറിയാം.

അടുത്തിടെ, അവർ അവരുടെ റിലീസ് പോലും ചെയ്തു ഹാർഡ്വെയർ, അത് അവരുടെ ആവാസവ്യവസ്ഥയുമായി എളുപ്പത്തിൽ ബന്ധിപ്പിക്കുന്നു.

ഹേയ്, സ്കൂട്ടർ കാണാതായാലോ?

അങ്ങനെ "റാൽഫ്" എന്ന സ്കൂട്ടർ ഒരു തുമ്പും കൂടാതെ അപ്രത്യക്ഷമായി.

InfluxDB-യിൽ നിന്നുള്ള GPS മെട്രിക്സ് ഡാറ്റ ഉപയോഗിച്ച് ഞങ്ങളുടെ "അഡ്മിൻ പാനലിലെ" മാപ്പ് കാണാൻ ഞങ്ങൾ ഉടൻ ഓടി.

ഡാറ്റ മോണിറ്ററിംഗ് ചെയ്തതിന് നന്ദി, കഴിഞ്ഞ ദിവസം 21:00 ഓടെ സ്‌കൂട്ടർ പാർക്കിംഗ് ലോട്ടിൽ നിന്ന് പുറപ്പെട്ടുവെന്നും ഏകദേശം അരമണിക്കൂറോളം കുറച്ച് പ്രദേശത്തേക്ക് പോയി എന്നും പുലർച്ചെ 5 മണി വരെ ഏതോ ജർമ്മൻ വീടിന്റെ അടുത്ത് പാർക്ക് ചെയ്തിട്ടുണ്ടെന്നും ഞങ്ങൾ എളുപ്പത്തിൽ നിർണ്ണയിച്ചു.

പുലർച്ചെ 5 മണിക്ക് ശേഷം, മോണിറ്ററിംഗ് ഡാറ്റയൊന്നും ലഭിച്ചില്ല - ഇതിനർത്ഥം ഒന്നുകിൽ അധിക ബാറ്ററി പൂർണ്ണമായും ഡിസ്ചാർജ് ചെയ്തു, അല്ലെങ്കിൽ സ്കൂട്ടറിൽ നിന്ന് സ്മാർട്ട് ഹാർഡ്‌വെയർ എങ്ങനെ നീക്കംചെയ്യാമെന്ന് ആക്രമണകാരി ഒടുവിൽ കണ്ടെത്തി.
ഇത് വകവയ്ക്കാതെ, സ്കൂട്ടർ സ്ഥിതി ചെയ്യുന്ന വിലാസത്തിലേക്ക് പോലീസിനെ വിളിച്ചിരുന്നു. സ്കൂട്ടർ അവിടെ ഉണ്ടായിരുന്നില്ല.

എന്നിരുന്നാലും, വീടിന്റെ ഉടമയും ഇത് ആശ്ചര്യപ്പെട്ടു, കാരണം അദ്ദേഹം ഇന്നലെ രാത്രി ഓഫീസിൽ നിന്ന് ഈ സ്കൂട്ടറിൽ വീട്ടിലേക്ക് പോയി.

അത് മാറിയതനുസരിച്ച്, സപ്പോർട്ട് ജീവനക്കാരിലൊരാൾ അതിരാവിലെ എത്തി സ്കൂട്ടർ എടുത്തു, അതിന്റെ അധിക ബാറ്ററി പൂർണ്ണമായും ഡിസ്ചാർജ് ചെയ്തതായി കണ്ട് (കാൽനടയായി) പാർക്കിംഗ് സ്ഥലത്തേക്ക് കൊണ്ടുപോയി. ഈർപ്പം കാരണം അധിക ബാറ്ററി പരാജയപ്പെട്ടു.

ഞങ്ങളിൽ നിന്ന് സ്കൂട്ടർ മോഷ്ടിച്ചു. വഴിയിൽ, പോലീസ് കേസിലെ പ്രശ്നം എങ്ങനെ, ആരാണ് പരിഹരിച്ചതെന്ന് എനിക്കറിയില്ല, പക്ഷേ നിരീക്ഷണം നന്നായി പ്രവർത്തിച്ചു ...

അവലംബം: www.habr.com