മറ്റൊരു നിരീക്ഷണ സംവിധാനം

16 മോഡമുകൾ, 4 സെല്ലുലാർ ഓപ്പറേറ്റർമാർ = ഔട്ട്‌ഗോയിംഗ് വേഗത 933.45 Mbit/s

ആമുഖം

ഹലോ! ഈ ലേഖനം ഞങ്ങൾ എങ്ങനെ ഒരു പുതിയ നിരീക്ഷണ സംവിധാനം എഴുതി എന്നതിനെക്കുറിച്ചാണ്. ഉയർന്ന ഫ്രീക്വൻസി സിൻക്രണസ് മെട്രിക്‌സ് നേടാനുള്ള കഴിവിലും വളരെ കുറഞ്ഞ വിഭവ ഉപഭോഗത്തിലും ഇത് നിലവിലുള്ളതിൽ നിന്ന് വ്യത്യസ്തമാണ്. 0.1 നാനോസെക്കൻഡുകളുടെ മെട്രിക്‌സ് തമ്മിലുള്ള സമന്വയ കൃത്യതയോടെ പോളിംഗ് നിരക്ക് 10 മില്ലിസെക്കൻഡിൽ എത്താം. എല്ലാ ബൈനറി ഫയലുകളും 6 മെഗാബൈറ്റുകൾ ഉൾക്കൊള്ളുന്നു.

പ്രോജക്ട് കുറിച്ച്

ഞങ്ങൾക്ക് ഒരു പ്രത്യേക ഉൽപ്പന്നമുണ്ട്. ഡാറ്റാ ട്രാൻസ്മിഷൻ ചാനലുകളുടെ ത്രൂപുട്ടും തെറ്റ് സഹിഷ്ണുതയും സംഗ്രഹിക്കുന്നതിന് ഞങ്ങൾ ഒരു സമഗ്രമായ പരിഹാരം നിർമ്മിക്കുന്നു. നിരവധി ചാനലുകൾ ഉള്ളപ്പോഴാണിത്, നമുക്ക് പറയാം Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ മറ്റെന്തെങ്കിലും (5 Mbit/s), ഫലം സുസ്ഥിരവും വേഗതയേറിയതുമായ ഒരു ചാനലാണ്, അതിന്റെ വേഗത ഇതുപോലെയായിരിക്കും ഇത്: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

നിരവധി വർഷങ്ങളായി, ഒരു മൾട്ടി-ലെവൽ, ഫാസ്റ്റ്, ക്രോസ്-പ്ലാറ്റ്ഫോം, ലൈറ്റ്വെയ്റ്റ് മോണിറ്ററിംഗ് സിസ്റ്റം എന്നിവ സൃഷ്ടിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഇതാണ് ഞങ്ങളുടെ ബഹുമാനപ്പെട്ട സമൂഹവുമായി പങ്കിടാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്.

പ്രശ്ന പ്രസ്താവന

മോണിറ്ററിംഗ് സിസ്റ്റം അടിസ്ഥാനപരമായി വ്യത്യസ്തമായ രണ്ട് ക്ലാസുകളുടെ മെട്രിക്‌സ് നൽകുന്നു: തത്സമയ മെട്രിക്‌സും മറ്റുള്ളവയും. നിരീക്ഷണ സംവിധാനത്തിന് ഇനിപ്പറയുന്ന ആവശ്യകതകൾ മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ:

1. തത്സമയ മെട്രിക്‌സിന്റെ ഹൈ-ഫ്രീക്വൻസി സിൻക്രണസ് ഏറ്റെടുക്കലും കാലതാമസമില്ലാതെ ആശയവിനിമയ മാനേജ്‌മെന്റ് സിസ്റ്റത്തിലേക്ക് അവയുടെ കൈമാറ്റവും.
   വ്യത്യസ്ത അളവുകളുടെ ഉയർന്ന ആവൃത്തിയും സമന്വയവും പ്രധാനമല്ല, ഡാറ്റാ ട്രാൻസ്മിഷൻ ചാനലുകളുടെ എൻട്രോപ്പി വിശകലനം ചെയ്യുന്നതിന് ഇത് അത്യന്താപേക്ഷിതമാണ്. ഒരു ഡാറ്റാ ട്രാൻസ്മിഷൻ ചാനലിൽ ശരാശരി കാലതാമസം 30 മില്ലിസെക്കൻഡ് ആണെങ്കിൽ, ഒരു മില്ലിസെക്കൻഡിന്റെ ശേഷിക്കുന്ന മെട്രിക്കുകൾ തമ്മിലുള്ള സമന്വയത്തിലെ ഒരു പിശക്, തത്ഫലമായുണ്ടാകുന്ന ചാനലിന്റെ വേഗത ഏകദേശം 5% കുറയുന്നതിന് ഇടയാക്കും. 1 ചാനലുകളിൽ 4 മില്ലിസെക്കൻഡ് സമയം തെറ്റിച്ചാൽ, വേഗത ഡീഗ്രഡേഷൻ എളുപ്പത്തിൽ 30% ആയി കുറയും. കൂടാതെ, ചാനലുകളിലെ എൻട്രോപ്പി വളരെ വേഗത്തിൽ മാറുന്നു, അതിനാൽ ഓരോ 0.5 മില്ലിസെക്കൻഡിലും ഒരിക്കലെങ്കിലും ഞങ്ങൾ ഇത് അളക്കുകയാണെങ്കിൽ, ചെറിയ കാലതാമസമുള്ള ഫാസ്റ്റ് ചാനലുകളിൽ നമുക്ക് ഉയർന്ന വേഗതയുള്ള ഡീഗ്രഡേഷൻ ലഭിക്കും. തീർച്ചയായും, അത്തരം കൃത്യത എല്ലാ അളവുകൾക്കും ആവശ്യമില്ല, എല്ലാ സാഹചര്യങ്ങളിലും അല്ല. ചാനലിലെ കാലതാമസം 500 മില്ലിസെക്കൻഡ് ആയിരിക്കുമ്പോൾ, ഞങ്ങൾ അത്തരത്തിൽ പ്രവർത്തിക്കുമ്പോൾ, 1 മില്ലിസെക്കൻഡ് പിശക് മിക്കവാറും ശ്രദ്ധിക്കപ്പെടില്ല. കൂടാതെ, ലൈഫ് സപ്പോർട്ട് സിസ്റ്റം മെട്രിക്‌സിനായി, ഞങ്ങൾക്ക് മതിയായ പോളിംഗും സിൻക്രൊണൈസേഷൻ റേറ്റുകളും 2 സെക്കൻഡ് ഉണ്ട്, എന്നാൽ മോണിറ്ററിംഗ് സിസ്റ്റത്തിന് തന്നെ അത്യധികം പോളിംഗ് നിരക്കുകളും മെട്രിക്‌സിന്റെ അൾട്രാ-കൃത്യമായ സമന്വയവും ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ കഴിയണം.
2. കുറഞ്ഞ വിഭവ ഉപഭോഗവും ഒരൊറ്റ സ്റ്റാക്കും.
   അവസാന ഉപകരണം ഒന്നുകിൽ റോഡിലെ സ്ഥിതിഗതികൾ വിശകലനം ചെയ്യാനോ ആളുകളുടെ ബയോമെട്രിക് റെക്കോർഡിംഗ് നടത്താനോ കഴിയുന്ന ശക്തമായ ഓൺ-ബോർഡ് സമുച്ചയമോ അല്ലെങ്കിൽ ഒരു പ്രത്യേക സേന സൈനികൻ തന്റെ ശരീര കവചത്തിന് കീഴിൽ വീഡിയോ പ്രക്ഷേപണം ചെയ്യാൻ ധരിക്കുന്ന ഈന്തപ്പന വലിപ്പമുള്ള സിംഗിൾ ബോർഡ് കമ്പ്യൂട്ടറോ ആകാം. മോശം ആശയവിനിമയ സാഹചര്യങ്ങളിൽ തത്സമയം. ഇത്രയും വൈവിധ്യമാർന്ന ആർക്കിടെക്ചറുകളും കമ്പ്യൂട്ടിംഗ് പവറും ഉണ്ടായിരുന്നിട്ടും, ഒരേ സോഫ്റ്റ്‌വെയർ സ്റ്റാക്ക് ഉണ്ടായിരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.
3. കുട വാസ്തുവിദ്യ
   മെട്രിക്‌സ് അന്തിമ ഉപകരണത്തിൽ ശേഖരിക്കുകയും സമാഹരിക്കുകയും പ്രാദേശികമായി സംഭരിക്കുകയും തത്സമയവും മുൻകാലവും ദൃശ്യവൽക്കരിക്കുകയും വേണം. ഒരു കണക്ഷൻ ഉണ്ടെങ്കിൽ, സെൻട്രൽ മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്ക് ഡാറ്റ കൈമാറുക. കണക്ഷൻ ഇല്ലാത്തപ്പോൾ, അയയ്ക്കുന്ന ക്യൂ കുമിഞ്ഞുകൂടുകയും റാം ഉപയോഗിക്കാതിരിക്കുകയും വേണം.
4. ഉപഭോക്താവിന്റെ നിരീക്ഷണ സംവിധാനത്തിലേക്ക് സംയോജിപ്പിക്കുന്നതിനുള്ള API, കാരണം ആർക്കും ധാരാളം നിരീക്ഷണ സംവിധാനങ്ങൾ ആവശ്യമില്ല. ഉപഭോക്താവ് ഏതെങ്കിലും ഉപകരണങ്ങളിൽ നിന്നും നെറ്റ്‌വർക്കുകളിൽ നിന്നും ഒരൊറ്റ നിരീക്ഷണത്തിലേക്ക് ഡാറ്റ ശേഖരിക്കണം.

എന്ത് സംഭവിച്ചു

ഇതിനകം ശ്രദ്ധേയമായ ദീർഘവായനയ്ക്ക് ഭാരം വരാതിരിക്കാൻ, എല്ലാ നിരീക്ഷണ സംവിധാനങ്ങളുടെയും ഉദാഹരണങ്ങളും അളവുകളും ഞാൻ നൽകില്ല. ഇത് മറ്റൊരു ലേഖനത്തിലേക്ക് നയിക്കും. 1 മില്ലിസെക്കൻഡിൽ താഴെയുള്ള പിശക് ഉപയോഗിച്ച് ഒരേസമയം രണ്ട് മെട്രിക്‌സ് എടുക്കാൻ കഴിയുന്ന ഒരു മോണിറ്ററിംഗ് സിസ്റ്റം കണ്ടെത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല എന്ന് ഞാൻ പറയാം, അത് 64 MB റാം ഉള്ള ARM ആർക്കിടെക്‌ചറിലും 86 ഉള്ള x64_32 ആർക്കിടെക്‌ചറിലും ഒരുപോലെ ഫലപ്രദമായി പ്രവർത്തിക്കുന്നു. ജിബി റാം. അതിനാൽ, ഇതെല്ലാം ചെയ്യാൻ കഴിയുന്ന സ്വന്തമായി എഴുതാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഞങ്ങൾക്ക് ലഭിച്ചത് ഇതാ:

വ്യത്യസ്ത നെറ്റ്‌വർക്ക് ടോപ്പോളജികൾക്കായി മൂന്ന് ചാനലുകളുടെ ത്രോപുട്ട് സംഗ്രഹിക്കുന്നു

ചില പ്രധാന മെട്രിക്കുകളുടെ ദൃശ്യവൽക്കരണം

വാസ്തുവിദ്യ

ഉപകരണത്തിലും ഡാറ്റാ സെന്ററിലും പ്രധാന പ്രോഗ്രാമിംഗ് ഭാഷയായി ഞങ്ങൾ Golang ഉപയോഗിക്കുന്നു. മൾട്ടിടാസ്‌കിംഗ് നടപ്പിലാക്കുന്നതിലൂടെയും ഓരോ സേവനത്തിനും ഒരു സ്റ്റാറ്റിക്കലി ലിങ്ക്ഡ് എക്‌സിക്യൂട്ടബിൾ ബൈനറി ഫയൽ നേടാനുള്ള കഴിവിലൂടെയും ഇത് ജീവിതത്തെ വളരെയധികം ലളിതമാക്കി. തൽഫലമായി, ഉപകരണങ്ങൾ, വികസന സമയം, കോഡ് ഡീബഗ്ഗിംഗ് എന്നിവ അവസാനിപ്പിക്കുന്നതിന് സേവനം വിന്യസിക്കുന്നതിനുള്ള ഉറവിടങ്ങളിലും രീതികളിലും ട്രാഫിക്കിലും ഞങ്ങൾ ഗണ്യമായി ലാഭിക്കുന്നു.

ക്ലാസിക് മോഡുലാർ തത്വമനുസരിച്ച് സിസ്റ്റം നടപ്പിലാക്കുകയും നിരവധി ഉപസിസ്റ്റങ്ങൾ അടങ്ങിയിരിക്കുകയും ചെയ്യുന്നു:

1. മെട്രിക്സ് രജിസ്ട്രേഷൻ.
   ഓരോ മെട്രിക്കും അതിന്റേതായ ത്രെഡ് നൽകുകയും ചാനലുകളിലുടനീളം സമന്വയിപ്പിക്കുകയും ചെയ്യുന്നു. 10 നാനോസെക്കൻഡ് വരെ സിൻക്രൊണൈസേഷൻ കൃത്യത കൈവരിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു.
2. മെട്രിക്സ് സംഭരണം
   ടൈം സീരീസിനായി സ്വന്തം സ്റ്റോറേജ് എഴുതുന്നതിനോ ഇതിനകം ലഭ്യമായ എന്തെങ്കിലും ഉപയോഗിക്കുന്നതിനോ ഇടയിൽ ഞങ്ങൾ തിരഞ്ഞെടുക്കുകയായിരുന്നു. തുടർന്നുള്ള ദൃശ്യവൽക്കരണത്തിന് വിധേയമായ മുൻകാല ഡാറ്റയ്ക്ക് ഡാറ്റാബേസ് ആവശ്യമാണ്. അതായത്, ഓരോ 0.5 മില്ലിസെക്കൻഡിലും ചാനലിലെ കാലതാമസത്തെക്കുറിച്ചോ ട്രാൻസ്പോർട്ട് നെറ്റ്‌വർക്കിലെ പിശക് റീഡിംഗിനെക്കുറിച്ചോ അതിൽ ഡാറ്റ അടങ്ങിയിട്ടില്ല, എന്നാൽ ഓരോ 500 മില്ലിസെക്കൻഡിലും ഓരോ ഇന്റർഫേസിലും വേഗതയുണ്ട്. ക്രോസ്-പ്ലാറ്റ്‌ഫോമിനും കുറഞ്ഞ വിഭവ ഉപഭോഗത്തിനും ഉയർന്ന ആവശ്യകതകൾക്ക് പുറമേ, പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്നത് ഞങ്ങൾക്ക് വളരെ പ്രധാനമാണ്. ഡാറ്റ എവിടെയാണ് സംഭരിച്ചിരിക്കുന്നത്. ഇത് വലിയ കമ്പ്യൂട്ടിംഗ് വിഭവങ്ങൾ ലാഭിക്കുന്നു. 2016 മുതൽ ഈ പ്രോജക്റ്റിൽ ഞങ്ങൾ Tarantool DBMS ഉപയോഗിക്കുന്നു, ഇതുവരെ ചക്രവാളത്തിൽ അതിനൊരു പകരക്കാരനെ ഞങ്ങൾ കാണുന്നില്ല. ഫ്ലെക്സിബിൾ, ഒപ്റ്റിമൽ റിസോഴ്സ് ഉപഭോഗം, മതിയായ സാങ്കേതിക പിന്തുണയേക്കാൾ കൂടുതൽ. Tarantool ഒരു GIS മൊഡ്യൂളും നടപ്പിലാക്കുന്നു. തീർച്ചയായും, ഇത് PostGIS പോലെ ശക്തമല്ല, എന്നാൽ ലൊക്കേഷനുമായി ബന്ധപ്പെട്ട ചില മെട്രിക്കുകൾ (ഗതാഗതത്തിന് പ്രസക്തമായത്) സൂക്ഷിക്കുന്നതിനുള്ള ഞങ്ങളുടെ ചുമതലകൾക്ക് ഇത് മതിയാകും.
3. മെട്രിക്സിന്റെ ദൃശ്യവൽക്കരണം
   ഇവിടെ എല്ലാം താരതമ്യേന ലളിതമാണ്. ഞങ്ങൾ വെയർഹൗസിൽ നിന്ന് ഡാറ്റ എടുത്ത് അത് തത്സമയം അല്ലെങ്കിൽ മുൻകാലങ്ങളിൽ പ്രദർശിപ്പിക്കുന്നു.
4. സെൻട്രൽ മോണിറ്ററിംഗ് സിസ്റ്റവുമായി ഡാറ്റയുടെ സമന്വയം.
   സെൻട്രൽ മോണിറ്ററിംഗ് സിസ്റ്റം എല്ലാ ഉപകരണങ്ങളിൽ നിന്നും ഡാറ്റ സ്വീകരിക്കുകയും ഒരു നിർദ്ദിഷ്ട ചരിത്രത്തിൽ സംഭരിക്കുകയും API വഴി ഉപഭോക്താവിന്റെ നിരീക്ഷണ സംവിധാനത്തിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. ക്ലാസിക് മോണിറ്ററിംഗ് സിസ്റ്റങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, "തല" ചുറ്റും നടന്ന് ഡാറ്റ ശേഖരിക്കുന്നു, ഞങ്ങൾക്ക് വിപരീത സ്കീം ഉണ്ട്. ഒരു കണക്ഷൻ ഉള്ളപ്പോൾ ഉപകരണങ്ങൾ തന്നെ ഡാറ്റ അയയ്ക്കുന്നു. ഇത് വളരെ പ്രധാനപ്പെട്ട ഒരു കാര്യമാണ്, കാരണം ഉപകരണം ലഭ്യമല്ലാത്ത സമയങ്ങളിൽ ഉപകരണത്തിൽ നിന്ന് ഡാറ്റ സ്വീകരിക്കാനും ഉപകരണം ലഭ്യമല്ലാത്തപ്പോൾ ചാനലുകളും ഉറവിടങ്ങളും ലോഡ് ചെയ്യാതിരിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. ഒരു സെൻട്രൽ മോണിറ്ററിംഗ് സിസ്റ്റമായി ഞങ്ങൾ ഇൻഫ്ലക്സ് മോണിറ്ററിംഗ് സെർവർ ഉപയോഗിക്കുന്നു. അതിന്റെ അനലോഗുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഇതിന് മുൻകാല ഡാറ്റ ഇറക്കുമതി ചെയ്യാൻ കഴിയും (അതായത്, മെട്രിക്‌സ് ലഭിച്ച നിമിഷത്തിൽ നിന്ന് വ്യത്യസ്തമായ ടൈം സ്റ്റാമ്പ് ഉപയോഗിച്ച്). ശേഖരിച്ച മെട്രിക്‌സ് ഗ്രാഫാന ദൃശ്യവൽക്കരിക്കുകയും ഒരു ഫയൽ ഉപയോഗിച്ച് പരിഷ്‌ക്കരിക്കുകയും ചെയ്യുന്നു. മിക്കവാറും എല്ലാ ഉപഭോക്തൃ നിരീക്ഷണ സംവിധാനവുമായും റെഡിമെയ്ഡ് API സംയോജനം ഉള്ളതിനാൽ ഈ സ്റ്റാൻഡേർഡ് സ്റ്റാക്കും തിരഞ്ഞെടുത്തു.
5. ഒരു കേന്ദ്ര ഉപകരണ മാനേജ്മെന്റ് സിസ്റ്റവുമായുള്ള ഡാറ്റ സമന്വയം.
   ഡിവൈസ് മാനേജ്മെന്റ് സിസ്റ്റം സീറോ ടച്ച് പ്രൊവിഷനിംഗ് (ഫേംവെയർ, കോൺഫിഗറേഷൻ മുതലായവ അപ്ഡേറ്റ് ചെയ്യുന്നു) നടപ്പിലാക്കുന്നു, കൂടാതെ മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്ന് വ്യത്യസ്തമായി, ഓരോ ഉപകരണത്തിനും പ്രശ്നങ്ങൾ മാത്രമേ ലഭിക്കൂ. ഓൺ-ബോർഡ് ഹാർഡ്‌വെയർ വാച്ച്‌ഡോഗ് സേവനങ്ങളുടെയും ലൈഫ് സപ്പോർട്ട് സിസ്റ്റങ്ങളുടെ എല്ലാ അളവുകോലുകളുടെയും പ്രവർത്തനത്തിനുള്ള ട്രിഗറുകൾ ഇവയാണ്: സിപിയു, എസ്എസ്ഡി താപനില, സിപിയു ലോഡ്, ഫ്രീ സ്പേസ്, ഡിസ്‌കുകളിലെ സ്മാർട്ട് ഹെൽത്ത്. സബ്സിസ്റ്റം സ്റ്റോറേജും ടാരന്റൂളിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്. ഇത് ആയിരക്കണക്കിന് ഉപകരണങ്ങളിൽ സമയ ശ്രേണികൾ സമാഹരിക്കുന്നതിലെ ഗണ്യമായ വേഗത നൽകുന്നു, കൂടാതെ ഈ ഉപകരണങ്ങളുമായി ഡാറ്റ സമന്വയിപ്പിക്കുന്നതിനുള്ള പ്രശ്നം പൂർണ്ണമായും പരിഹരിക്കുന്നു. മികച്ച ക്യൂയിംഗും ഗ്യാരണ്ടീഡ് ഡെലിവറി സംവിധാനവും ടാരന്റൂളിനുണ്ട്. ഈ സുപ്രധാന സവിശേഷത ഞങ്ങൾക്ക് ബോക്സിൽ നിന്ന് ലഭിച്ചു, കൊള്ളാം!

നെറ്റ്വർക്ക് മാനേജ്മെന്റ് സിസ്റ്റം

അടുത്തത് എന്താണ്

ഇതുവരെ, ഞങ്ങളുടെ ഏറ്റവും ദുർബലമായ ലിങ്ക് കേന്ദ്ര നിരീക്ഷണ സംവിധാനമാണ്. ഇത് ഒരു സ്റ്റാൻഡേർഡ് സ്റ്റാക്കിൽ 99.9% നടപ്പിലാക്കുന്നു, കൂടാതെ നിരവധി ദോഷങ്ങളുമുണ്ട്:

1. പവർ നഷ്‌ടപ്പെടുമ്പോൾ InfluxDB ഡാറ്റ നഷ്‌ടപ്പെടുന്നു. ചട്ടം പോലെ, ഉപഭോക്താവ് ഉപകരണങ്ങളിൽ നിന്ന് വരുന്നതെല്ലാം ഉടനടി ശേഖരിക്കുന്നു, കൂടാതെ ഡാറ്റാബേസിൽ തന്നെ 5 മിനിറ്റിൽ കൂടുതൽ പഴയ ഡാറ്റ അടങ്ങിയിട്ടില്ല, എന്നാൽ ഭാവിയിൽ ഇത് ഒരു വേദനയായി മാറിയേക്കാം.
2. ഡാറ്റാ അഗ്രഗേഷനിലും ഡിസ്പ്ലേയുടെ സമന്വയത്തിലും ഗ്രാഫാനയ്ക്ക് നിരവധി പ്രശ്‌നങ്ങളുണ്ട്. ഏറ്റവും സാധാരണമായ പ്രശ്നം, ഡാറ്റാബേസിൽ 2:00:00 മുതൽ ആരംഭിക്കുന്ന 00 സെക്കൻഡ് ഇടവേളയുള്ള ഒരു സമയ ശ്രേണി അടങ്ങിയിരിക്കുമ്പോഴാണ്, ഗ്രാഫാന +1 സെക്കൻഡിൽ നിന്ന് ഡാറ്റ സംഗ്രഹത്തിൽ കാണിക്കാൻ തുടങ്ങുന്നത്. തൽഫലമായി, ഉപയോക്താവ് ഒരു നൃത്ത ഗ്രാഫ് കാണുന്നു.
3. മൂന്നാം കക്ഷി നിരീക്ഷണ സംവിധാനങ്ങളുമായുള്ള API സംയോജനത്തിനായുള്ള കോഡിന്റെ അമിത അളവ്. ഇത് കൂടുതൽ ഒതുക്കമുള്ളതും തീർച്ചയായും Go-യിൽ മാറ്റിയെഴുതാനും കഴിയും)

ഗ്രാഫാന എങ്ങനെയുണ്ടെന്ന് നിങ്ങൾ എല്ലാവരും നന്നായി കണ്ടിട്ടുണ്ടെന്നും ഞാനില്ലാതെ അതിന്റെ പ്രശ്‌നങ്ങൾ അറിയാമെന്നും ഞാൻ കരുതുന്നു, അതിനാൽ ഞാൻ ചിത്രങ്ങൾ ഉപയോഗിച്ച് പോസ്റ്റ് ഓവർലോഡ് ചെയ്യില്ല.

തീരുമാനം

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

ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറം ആർക്കെങ്കിലും ചോദ്യങ്ങളുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് a.rodin @ qedr.com എന്ന വിലാസത്തിൽ എനിക്ക് എഴുതാവുന്നതാണ്.

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