ഒരു സേവനമായി നിരീക്ഷണം: മൈക്രോ സർവീസ് ആർക്കിടെക്ചറിനുള്ള ഒരു മോഡുലാർ സിസ്റ്റം

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

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

ഭൂതകാലം: പദ്ധതികളും പദ്ധതികളും

നിലവിലെ നിരീക്ഷണ സംവിധാനത്തിലേക്ക് ഞങ്ങൾ എങ്ങനെയാണ് എത്തിയത്? ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ, നിങ്ങൾ 2015-ലേക്ക് പോകേണ്ടതുണ്ട്. അപ്പോൾ അത് ഇങ്ങനെയായിരുന്നു:

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

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

സ്റ്റാൻഡേർഡ്: മോണിറ്ററിംഗ് 2.0

2015-ലെ പദ്ധതികൾ ഇങ്ങനെയായിരുന്നു. എന്നാൽ അടിസ്ഥാന സൗകര്യങ്ങളും സേവനവും മാത്രമല്ല, അതിനുള്ള ഡോക്യുമെന്റേഷനും ഞങ്ങൾ തയ്യാറാക്കേണ്ടതുണ്ട്. ഞങ്ങൾ സ്വയം ഒരു കോർപ്പറേറ്റ് നിലവാരം വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്, അതിനെ ഞങ്ങൾ മോണിറ്ററിംഗ് 2.0 എന്ന് വിളിക്കുന്നു. സിസ്റ്റത്തിന്റെ ആവശ്യകതകൾ എന്തായിരുന്നു?

• സ്ഥിരമായ ലഭ്യത;
• മെട്രിക്സ് സ്റ്റോറേജ് ഇടവേള = 10 സെക്കൻഡ്;
• മെട്രിക്കുകളുടെയും ഡാഷ്ബോർഡുകളുടെയും ഘടനാപരമായ സംഭരണം;
• SLA > 99,99%
• UDP (!) വഴി ഇവന്റ് മെട്രിക്‌സിന്റെ ശേഖരണം.

ഞങ്ങൾക്ക് UDP ആവശ്യമാണ്, കാരണം ഞങ്ങൾക്ക് വലിയ ട്രാഫിക്കും മെട്രിക്‌സ് സൃഷ്‌ടിക്കുന്ന ഇവന്റുകളും ഉണ്ട്. നിങ്ങൾ അവയെല്ലാം ഒരേസമയം ഗ്രാഫൈറ്റിൽ എഴുതിയാൽ, സംഭരണം തകരും. എല്ലാ മെട്രിക്‌സിനും ഞങ്ങൾ ഫസ്റ്റ് ലെവൽ പ്രിഫിക്‌സുകളും തിരഞ്ഞെടുത്തു.

ഓരോ പ്രിഫിക്സുകൾക്കും ചില ഗുണങ്ങളുണ്ട്. സെർവറുകൾ, നെറ്റ്‌വർക്കുകൾ, കണ്ടെയ്‌നറുകൾ, ഉറവിടങ്ങൾ, ആപ്ലിക്കേഷനുകൾ തുടങ്ങിയവയ്‌ക്കായി മെട്രിക്‌സ് ഉണ്ട്. വ്യക്തമായ, കർശനമായ, ടൈപ്പ് ചെയ്‌ത ഫിൽട്ടറിംഗ് നടപ്പിലാക്കി, അവിടെ ഞങ്ങൾ ഫസ്റ്റ് ലെവൽ മെട്രിക്‌സ് സ്വീകരിക്കുകയും ബാക്കിയുള്ളവ ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു. 2015ൽ ഞങ്ങൾ ഈ സംവിധാനം ആസൂത്രണം ചെയ്തത് ഇങ്ങനെയാണ്. വർത്തമാനകാലത്തിൽ എന്താണ് ഉള്ളത്?

നിലവിലുള്ളത്: മോണിറ്ററിംഗ് ഘടകങ്ങളുടെ പ്രതിപ്രവർത്തനത്തിന്റെ ഡയഗ്രം

ഒന്നാമതായി, ഞങ്ങൾ ആപ്ലിക്കേഷനുകൾ നിരീക്ഷിക്കുന്നു: ഞങ്ങളുടെ PHP കോഡ്, ആപ്ലിക്കേഷനുകൾ, മൈക്രോസർവീസുകൾ - ചുരുക്കത്തിൽ, ഞങ്ങളുടെ ഡവലപ്പർമാർ എഴുതുന്ന എല്ലാം. എല്ലാ ആപ്ലിക്കേഷനുകളും UDP വഴി ബ്രൂബെക്ക് അഗ്രഗേറ്ററിലേക്ക് മെട്രിക്‌സ് അയയ്‌ക്കുന്നു (statsd, C-യിൽ വീണ്ടും എഴുതിയത്). സിന്തറ്റിക് ടെസ്റ്റുകളിൽ ഏറ്റവും വേഗതയേറിയതായി ഇത് മാറി. TCP വഴി ഗ്രാഫൈറ്റിലേക്ക് ഇതിനകം സമാഹരിച്ച മെട്രിക്‌സ് അയയ്‌ക്കുന്നു.

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

ഹാർഡ്‌വെയർ, സോഫ്‌റ്റ്‌വെയർ, സിസ്റ്റം മെട്രിക്‌സ്, ഞങ്ങളുടെ പഴയ മുനിൻ മോണിറ്ററിംഗ് സിസ്റ്റം (ഇത് 2015 വരെ ഞങ്ങൾക്ക് വേണ്ടി പ്രവർത്തിച്ചിരുന്നു) എന്നിവയിലെ മെട്രിക്കുകൾക്കായുള്ള സംഗ്രഹവും ഞങ്ങൾക്കുണ്ട്. C's CollectD ഡെമൺ വഴിയാണ് ഞങ്ങൾ ഇതെല്ലാം ശേഖരിക്കുന്നത് (ഇതിൽ വ്യത്യസ്‌ത പ്ലഗിനുകളുടെ ഒരു കൂട്ടം അതിൽ അന്തർനിർമ്മിതമാണ്, അത് ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്ന ഹോസ്റ്റ് സിസ്റ്റത്തിന്റെ എല്ലാ ഉറവിടങ്ങളും ഇതിന് പോൾ ചെയ്യാൻ കഴിയും, ഡാറ്റ എവിടെ എഴുതണമെന്ന് കോൺഫിഗറേഷനിൽ വ്യക്തമാക്കുക) കൂടാതെ അതിലൂടെ ഗ്രാഫൈറ്റിലേക്ക് ഡാറ്റ എഴുതുക. ഇത് പൈത്തൺ പ്ലഗിന്നുകളും ഷെൽ സ്ക്രിപ്റ്റുകളും പിന്തുണയ്ക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ഇഷ്‌ടാനുസൃത പരിഹാരങ്ങൾ എഴുതാം: CollectD ഈ ഡാറ്റ ഒരു ലോക്കൽ അല്ലെങ്കിൽ റിമോട്ട് ഹോസ്റ്റിൽ നിന്ന് ശേഖരിച്ച് ഗ്രാഫൈറ്റിലേക്ക് അയയ്ക്കും.

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

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

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

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

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

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

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

ശരി, ഞങ്ങൾ ഒരു പുരോഗമന കമ്പനിയായതിനാൽ, ഈ സിസ്റ്റത്തിൽ ഞങ്ങൾ കുബർനെറ്റുകളും നിരീക്ഷിച്ചു. ഞങ്ങൾ ക്ലസ്റ്ററിൽ ഇൻസ്റ്റാൾ ചെയ്ത Heapster ഉപയോഗിച്ച് സിസ്റ്റത്തിൽ ഉൾപ്പെടുത്തി, അത് ഡാറ്റ ശേഖരിക്കുകയും ഗ്രാഫൈറ്റിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. തൽഫലമായി, ഡയഗ്രം ഇതുപോലെ കാണപ്പെടുന്നു:

മോണിറ്ററിംഗ് ഘടകങ്ങൾ

ഈ ടാസ്ക്കിനായി ഞങ്ങൾ ഉപയോഗിച്ച ഘടകങ്ങളിലേക്കുള്ള ലിങ്കുകളുടെ ഒരു ലിസ്റ്റ് ഇതാ. അവയെല്ലാം ഓപ്പൺ സോഴ്‌സ് ആണ്.

ഗ്രാഫൈറ്റ്:

• ഗോ-കാർബൺ: github.com/lomik/go-carbon
• മന്ത്രിക്കുക: github.com/graphite-project/whisper
• ഗ്രാഫൈറ്റ്-എപിഐ: github.com/brutasse/graphite-api

കാർബൺ-സി-റിലേ:

github.com/grobian/carbon-c-relay

ബ്രൂബെക്ക്:

github.com/github/brubeck

ശേഖരിച്ചത്:

collected.org

മൊയ്‌റ:

github.com/moira-alert

ഗ്രാഫാന:

grafana.com

ഹെപ്സ്റ്റർ:

github.com/kubernetes/heapster

സ്ഥിതിവിവരക്കണക്കുകൾ

സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ചില നമ്പറുകൾ ഇവിടെയുണ്ട്.

അഗ്രഗേറ്റർ (ബ്രൂബെക്ക്)

മെട്രിക്കുകളുടെ എണ്ണം: ~300/സെക്കൻഡ്
ഗ്രാഫൈറ്റിലേക്ക് മെട്രിക്‌സ് അയക്കുന്നതിനുള്ള ഇടവേള: 30 സെ
സെർവർ റിസോഴ്സ് ഉപയോഗം: ~ 6% CPU (ഞങ്ങൾ പൂർണ്ണമായ സെർവറുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്); ~ 1Gb റാം; ~3 Mbps ലാൻ

ഗ്രാഫൈറ്റ് (ഗോ-കാർബൺ)

മെട്രിക്കുകളുടെ എണ്ണം: ~ 1 / മിനിറ്റ്
മെട്രിക്സ് അപ്ഡേറ്റ് ഇടവേള: 30 സെ
മെട്രിക്‌സ് സ്‌റ്റോറേജ് സ്‌കീം: 30സെക്കന്റ് 35ഡി, 5മിനിറ്റ് 90ഡി, 10മിനിറ്റ് 365ഡി (ദീർഘകാലത്തേക്ക് സേവനത്തിന് എന്ത് സംഭവിക്കുമെന്ന് നിങ്ങൾക്ക് ഒരു ധാരണ നൽകുന്നു)
സെർവർ റിസോഴ്സ് ഉപയോഗം: ~10% CPU; ~ 20Gb റാം; ~30 Mbps ലാൻ

വഴക്കം

ഞങ്ങളുടെ മോണിറ്ററിംഗ് സേവനത്തിലെ വഴക്കത്തെ ഞങ്ങൾ Avito-യിൽ ശരിക്കും വിലമതിക്കുന്നു. എന്തുകൊണ്ടാണ് അവൻ യഥാർത്ഥത്തിൽ ഇങ്ങനെ മാറിയത്? ഒന്നാമതായി, അതിന്റെ ഘടകങ്ങൾ പരസ്പരം മാറ്റാവുന്നവയാണ്: ഘടകങ്ങളും അവയുടെ പതിപ്പുകളും. രണ്ടാമതായി, പിന്തുണ. മുഴുവൻ പ്രോജക്‌റ്റും ഓപ്പൺ സോഴ്‌സ് ആയതിനാൽ, നിങ്ങൾക്ക് കോഡ് സ്വയം എഡിറ്റ് ചെയ്യാനും മാറ്റങ്ങൾ വരുത്താനും ബോക്‌സിന് പുറത്ത് ലഭ്യമല്ലാത്ത ഫംഗ്‌ഷനുകൾ നടപ്പിലാക്കാനും കഴിയും. വളരെ സാധാരണമായ സ്റ്റാക്കുകൾ ഉപയോഗിക്കുന്നു, പ്രധാനമായും ഗോയും പൈത്തണും, അതിനാൽ ഇത് വളരെ ലളിതമായി ചെയ്യുന്നു.

ഒരു യഥാർത്ഥ പ്രശ്നത്തിന്റെ ഒരു ഉദാഹരണം ഇതാ. ഗ്രാഫൈറ്റിലെ മെട്രിക് ഒരു ഫയലാണ്. അതിന് ഒരു പേരുണ്ട്. ഫയലിന്റെ പേര് = മെട്രിക് നാമം. പിന്നെ അവിടെയെത്താൻ വഴിയുണ്ട്. Linux-ലെ ഫയൽ നാമങ്ങൾ 255 പ്രതീകങ്ങളായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഡാറ്റാബേസ് ഡിപ്പാർട്ട്‌മെന്റിൽ നിന്നുള്ള ("ആന്തരിക ഉപഭോക്താക്കൾ" എന്ന നിലയിൽ) ഞങ്ങൾക്കുണ്ട്. അവർ ഞങ്ങളോട് പറയുന്നു: “ഞങ്ങളുടെ SQL അന്വേഷണങ്ങൾ നിരീക്ഷിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. അവ 255 പ്രതീകങ്ങളല്ല, 8 MB വീതമാണ്. ഞങ്ങൾ അവ ഗ്രാഫാനയിൽ പ്രദർശിപ്പിക്കാൻ ആഗ്രഹിക്കുന്നു, ഈ അഭ്യർത്ഥനയ്ക്കുള്ള പാരാമീറ്ററുകൾ കാണുക, അതിലും മികച്ചത്, അത്തരം അഭ്യർത്ഥനകളുടെ മുകളിൽ കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇത് തത്സമയം പ്രദർശിപ്പിക്കുകയാണെങ്കിൽ അത് വളരെ മികച്ചതായിരിക്കും. അവരെ അലേർട്ടിൽ നിർത്തുന്നത് ശരിക്കും രസകരമായിരിക്കും. ”

SQL ചോദ്യം ഉദാഹരണമായി എടുത്തതാണ് സൈറ്റ് postgrespro.ru

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

ഫലങ്ങൾ

ലഭ്യത ഞങ്ങളുടെ നിരീക്ഷണ സേവനം ഏത് ആപ്ലിക്കേഷനിൽ നിന്നും ഏത് കോഡിൽ നിന്നും 24/7 ലഭ്യമാണ്. നിങ്ങൾക്ക് സ്റ്റോറേജ് സൗകര്യങ്ങളുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് സേവനത്തിലേക്ക് ഡാറ്റ എഴുതാം. ഭാഷ പ്രധാനമല്ല, തീരുമാനങ്ങളല്ല. ഒരു സോക്കറ്റ് തുറക്കാനും അവിടെ ഒരു മെട്രിക് ഇടാനും സോക്കറ്റ് അടയ്ക്കാനും മാത്രം നിങ്ങൾക്കറിയണം.

വിശ്വാസ്യത എല്ലാ ഘടകങ്ങളും തെറ്റ്-സഹിഷ്ണുതയുള്ളതും ഞങ്ങളുടെ ലോഡുകൾ നന്നായി കൈകാര്യം ചെയ്യുന്നതുമാണ്.

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

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

നമ്മൾ എന്താണ് ലക്ഷ്യമിടുന്നത്?

ചുവടെ ലിസ്റ്റുചെയ്‌തിരിക്കുന്നതെല്ലാം വെറും അമൂർത്തമായ ചിന്തകൾ മാത്രമല്ല, കുറഞ്ഞത് ആദ്യ ചുവടുകളെങ്കിലും എടുത്തിട്ടുള്ള ഒന്നാണ്.

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

നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് നന്ദി! വിഷയത്തെക്കുറിച്ചുള്ള നിങ്ങളുടെ ചോദ്യങ്ങൾ ചോദിക്കുക, ഞാൻ ഇവിടെ അല്ലെങ്കിൽ ഇനിപ്പറയുന്ന പോസ്റ്റുകളിൽ ഉത്തരം നൽകാൻ ശ്രമിക്കും. ഒരുപക്ഷേ ആർക്കെങ്കിലും സമാനമായ നിരീക്ഷണ സംവിധാനം നിർമ്മിക്കുന്നതോ അല്ലെങ്കിൽ സമാനമായ സാഹചര്യത്തിൽ ക്ലിക്ക്ഹൗസിലേക്ക് മാറുന്നതോ ആയ അനുഭവം ഉണ്ടായിരിക്കാം - അഭിപ്രായങ്ങളിൽ അത് പങ്കിടുക.

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