നിരീക്ഷണം മരിച്ചോ? - ദീർഘകാല നിരീക്ഷണം

2008 മുതൽ, ഞങ്ങളുടെ കമ്പനി പ്രാഥമികമായി ഇൻഫ്രാസ്ട്രക്ചർ മാനേജ്‌മെന്റിലും വെബ് പ്രോജക്റ്റുകൾക്കായുള്ള മുഴുവൻ സമയ സാങ്കേതിക പിന്തുണയിലും ഏർപ്പെട്ടിരിക്കുന്നു: ഞങ്ങൾക്ക് 400-ലധികം ക്ലയന്റുകൾ ഉണ്ട്, ഇത് റഷ്യൻ ഇ-കൊമേഴ്‌സിന്റെ ഏകദേശം 15% ആണ്. അതനുസരിച്ച്, വളരെ വൈവിധ്യമാർന്ന വാസ്തുവിദ്യയെ പിന്തുണയ്ക്കുന്നു. എന്തെങ്കിലും വീണാൽ, 15 മിനിറ്റിനുള്ളിൽ അത് പരിഹരിക്കാൻ ഞങ്ങൾ ബാധ്യസ്ഥരാണ്. എന്നാൽ ഒരു അപകടം സംഭവിച്ചുവെന്ന് മനസിലാക്കാൻ, നിങ്ങൾ പ്രോജക്റ്റ് നിരീക്ഷിക്കുകയും സംഭവങ്ങളോട് പ്രതികരിക്കുകയും വേണം. ഇത് എങ്ങനെ ചെയ്യണം?

ശരിയായ നിരീക്ഷണ സംവിധാനം സംഘടിപ്പിക്കുന്നതിൽ ഒരു പ്രശ്നമുണ്ടെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. പ്രശ്‌നങ്ങളൊന്നും ഉണ്ടായില്ലെങ്കിൽ, എന്റെ പ്രസംഗത്തിൽ ഒരു തീസിസ് അടങ്ങിയിരിക്കും: "ദയവായി പ്രോമിത്യൂസ് + ഗ്രാഫാനയും പ്ലഗിനുകൾ 1, 2, 3 എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുക." നിർഭാഗ്യവശാൽ, അത് ഇനി അങ്ങനെ പ്രവർത്തിക്കില്ല. സോഫ്റ്റ്‌വെയർ ഘടകങ്ങളുടെ കാര്യത്തിൽ, 2008-ൽ നിലനിന്നിരുന്ന ഒന്നിൽ എല്ലാവരും തുടർന്നും വിശ്വസിക്കുന്നു എന്നതാണ് പ്രധാന പ്രശ്നം.

മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ ഓർഗനൈസേഷനെ സംബന്ധിച്ച്, ഞാൻ പറയാൻ തുനിഞ്ഞതാണ്... യോഗ്യതയുള്ള നിരീക്ഷണമുള്ള പദ്ധതികൾ നിലവിലില്ല. സാഹചര്യം വളരെ മോശമാണ്, എന്തെങ്കിലും വീണാൽ, അത് ശ്രദ്ധിക്കപ്പെടാതെ പോകാനുള്ള സാധ്യതയുണ്ട് - എല്ലാത്തിനുമുപരി, "എല്ലാം നിരീക്ഷിക്കപ്പെടുന്നു" എന്ന് എല്ലാവർക്കും ഉറപ്പുണ്ട്.
ഒരുപക്ഷേ എല്ലാം നിരീക്ഷിക്കപ്പെടുന്നു. പക്ഷെ എങ്ങനെ?

ഇനിപ്പറയുന്നതുപോലുള്ള ഒരു സ്റ്റോറി ഞങ്ങൾ എല്ലാവരും നേരിട്ടിട്ടുണ്ട്: ഒരു പ്രത്യേക ഡെവോപ്പുകൾ, ഒരു നിശ്ചിത അഡ്മിൻ പ്രവർത്തിക്കുന്നു, ഒരു ഡെവലപ്‌മെന്റ് ടീം അവരുടെ അടുത്ത് വന്ന് പറയുന്നു - “ഞങ്ങളെ മോചിപ്പിച്ചു, ഇപ്പോൾ നിരീക്ഷിക്കുക.” എന്താണ് നിരീക്ഷിക്കുക? ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു?

ശരി. ഞങ്ങൾ പഴയ രീതി നിരീക്ഷിക്കുന്നു. ഇത് ഇതിനകം മാറിക്കൊണ്ടിരിക്കുകയാണ്, നിങ്ങൾ സേവനം A നിരീക്ഷിച്ചുവെന്ന് ഇത് മാറുന്നു, അത് സേവന ബി ആയി മാറി, അത് സേവനം C യുമായി സംവദിക്കുന്നു. എന്നാൽ വികസന ടീം നിങ്ങളോട് പറയുന്നു: "സോഫ്റ്റ്‌വെയർ ഇൻസ്റ്റാൾ ചെയ്യുക, അത് എല്ലാം നിരീക്ഷിക്കണം!"

അപ്പോൾ എന്താണ് മാറിയത്? - എല്ലാം മാറി!

2008 എല്ലാം നന്നായിട്ടുണ്ട്

രണ്ട് ഡെവലപ്പർമാർ ഉണ്ട്, ഒരു സെർവർ, ഒരു ഡാറ്റാബേസ് സെർവർ. എല്ലാം ഇവിടെ നിന്ന് പോകുന്നു. ഞങ്ങൾക്ക് ചില വിവരങ്ങൾ ഉണ്ട്, ഞങ്ങൾ zabbix, Nagios, cacti എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. തുടർന്ന് ഞങ്ങൾ സിപിയു, ഡിസ്ക് ഓപ്പറേഷൻ, ഡിസ്ക് സ്പേസ് എന്നിവയിൽ വ്യക്തമായ അലേർട്ടുകൾ സജ്ജമാക്കി. സൈറ്റ് പ്രതികരിക്കുന്നുവെന്നും ഡാറ്റാബേസിൽ ഓർഡറുകൾ എത്തുന്നുണ്ടെന്നും ഉറപ്പാക്കാൻ ഞങ്ങൾ രണ്ട് മാനുവൽ പരിശോധനകളും നടത്തുന്നു. അത്രയേയുള്ളൂ - ഞങ്ങൾ കൂടുതലോ കുറവോ പരിരക്ഷിതരാണ്.

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

2010 ലോഡ് വളരുകയാണ്

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

മാത്രമല്ല, ഇൻഫ്രാസ്ട്രക്ചറുമായി ബന്ധപ്പെട്ട സ്ഥാപനം ഇപ്പോഴും മാനേജരുടെ തലയിൽ ഏറ്റവും വലുതായി തുടരുന്നു. മോണിറ്ററിംഗ് നടത്തുന്ന വ്യക്തിയാണ് zabbix ഇൻസ്റ്റാൾ ചെയ്യുന്നതും കോൺഫിഗർ ചെയ്യാൻ കഴിയുന്നതും എന്ന ഒരു ആശയം ഇപ്പോഴും എന്റെ തലയിലുണ്ട്.

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

ശ്രദ്ധിക്കുക: ഞാൻ "ഒരു കൂട്ടം സ്ക്രിപ്റ്റുകൾ" 3 തവണ എഴുതി. അതായത്, നിരീക്ഷണത്തിന് ഉത്തരവാദിയായ വ്യക്തി ഇപ്പോൾ zabbix ഇൻസ്റ്റാൾ ചെയ്യുന്ന ആളല്ല. ഇത് കോഡിംഗ് ആരംഭിക്കുന്ന ഒരു വ്യക്തിയാണ്. എന്നാൽ ടീമിന്റെ മനസ്സിൽ ഇതുവരെ മാറ്റമൊന്നും ഉണ്ടായിട്ടില്ല.

എന്നാൽ ലോകം മാറുകയാണ്, കൂടുതൽ കൂടുതൽ സങ്കീർണ്ണമാവുകയാണ്. ഒരു വിർച്ച്വലൈസേഷൻ ലെയറും നിരവധി പുതിയ സിസ്റ്റങ്ങളും ചേർത്തിരിക്കുന്നു. അവർ പരസ്പരം ഇടപഴകാൻ തുടങ്ങുന്നു. "മൈക്രോ സർവീസസ് പോലെ മണക്കുന്നു" എന്ന് ആരാണ് പറഞ്ഞത്? എന്നാൽ ഓരോ സേവനവും ഇപ്പോഴും വ്യക്തിഗതമായി ഒരു വെബ്സൈറ്റ് പോലെ കാണപ്പെടുന്നു. നമുക്ക് അതിലേക്ക് തിരിയുകയും അത് ആവശ്യമായ വിവരങ്ങൾ നൽകുകയും സ്വന്തമായി പ്രവർത്തിക്കുകയും ചെയ്യുന്നുവെന്ന് മനസ്സിലാക്കാം. നിങ്ങൾ 5-7-10 വർഷമായി വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്രോജക്റ്റിൽ നിരന്തരം ഏർപ്പെട്ടിരിക്കുന്ന ഒരു അഡ്മിനിസ്ട്രേറ്ററാണെങ്കിൽ, ഈ അറിവ് അടിഞ്ഞു കൂടുന്നു: ഒരു പുതിയ ലെവൽ പ്രത്യക്ഷപ്പെടുന്നു - നിങ്ങൾ അത് മനസ്സിലാക്കി, മറ്റൊരു ലെവൽ പ്രത്യക്ഷപ്പെടുന്നു - നിങ്ങൾ അത് തിരിച്ചറിഞ്ഞു ...

എന്നാൽ അപൂർവ്വമായി ആരെങ്കിലും 10 വർഷത്തേക്ക് ഒരു പ്രോജക്റ്റിനെ അനുഗമിക്കാറില്ല.

മോണിറ്ററിംഗ്മാന്റെ ബയോഡാറ്റ

നിങ്ങൾ 20 ഡെവലപ്പർമാരെ ഉടൻ നിയമിക്കുകയും 15 മൈക്രോസർവീസുകൾ എഴുതുകയും ചെയ്ത ഒരു പുതിയ സ്റ്റാർട്ടപ്പിലേക്ക് നിങ്ങൾ വന്നുവെന്ന് കരുതുക, നിങ്ങളോട് പറയപ്പെടുന്ന ഒരു അഡ്മിൻ ആണ്: “സിഐ/സിഡി നിർമ്മിക്കുക. ദയവായി." നിങ്ങൾ CI/CD നിർമ്മിച്ചു, പെട്ടെന്ന് നിങ്ങൾ കേൾക്കുന്നു: "ഒരു "ക്യൂബിൽ" ഉൽപ്പാദനവുമായി പ്രവർത്തിക്കുന്നത് ഞങ്ങൾക്ക് ബുദ്ധിമുട്ടാണ്, അതിൽ ആപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് മനസ്സിലാക്കാതെ. അതേ "ക്യൂബിൽ" ഞങ്ങളെ ഒരു സാൻഡ്ബോക്സ് ഉണ്ടാക്കുക.
ഈ ക്യൂബിൽ നിങ്ങൾ ഒരു സാൻഡ്ബോക്സ് ഉണ്ടാക്കുന്നു. അവർ ഉടൻ നിങ്ങളോട് പറയുന്നു: "നിർമ്മാണത്തിൽ നിന്ന് എല്ലാ ദിവസവും അപ്‌ഡേറ്റ് ചെയ്യുന്ന ഒരു സ്റ്റേജ് ഡാറ്റാബേസ് ഞങ്ങൾക്ക് ആവശ്യമാണ്, അതുവഴി അത് ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു, എന്നാൽ അതേ സമയം പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് നശിപ്പിക്കരുത്."

നിങ്ങൾ ഇതിലെല്ലാം ജീവിക്കുന്നു. റിലീസിന് 2 ആഴ്ചകൾ ശേഷിക്കുന്നു, അവർ നിങ്ങളോട് പറയുന്നു: "ഇപ്പോൾ നമുക്ക് ഇതെല്ലാം നിരീക്ഷിക്കാം ..." അതായത്. ക്ലസ്റ്റർ ഇൻഫ്രാസ്ട്രക്ചർ നിരീക്ഷിക്കുക, മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ നിരീക്ഷിക്കുക, ബാഹ്യ സേവനങ്ങളുമായുള്ള പ്രവർത്തനം നിരീക്ഷിക്കുക...

എന്റെ സഹപ്രവർത്തകർ അവരുടെ തലയിൽ നിന്ന് സാധാരണ സ്കീം എടുത്ത് പറയുന്നു: “ശരി, ഇവിടെ എല്ലാം വ്യക്തമാണ്! ഇതെല്ലാം നിരീക്ഷിക്കുന്ന ഒരു പ്രോഗ്രാം ഇൻസ്റ്റാൾ ചെയ്യുക. അതെ, അതെ: പ്രോമിത്യൂസ് + ഗ്രാഫാന + പ്ലഗിനുകൾ.
അവർ കൂട്ടിച്ചേർക്കുന്നു: "നിങ്ങൾക്ക് രണ്ടാഴ്ചയുണ്ട്, എല്ലാം സുരക്ഷിതമാണെന്ന് ഉറപ്പാക്കുക."

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

• ഇരുമ്പ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ പ്രവർത്തനത്തിന്റെ നിരീക്ഷണവും പ്രത്യേകതകളും അദ്ദേഹം മനസ്സിലാക്കണം.
• കുബെർനെറ്റസ് നിരീക്ഷിക്കുന്നതിന്റെ പ്രത്യേകതകൾ അദ്ദേഹം മനസ്സിലാക്കണം (എല്ലാവരും "ക്യൂബിലേക്ക്" പോകാൻ ആഗ്രഹിക്കുന്നു, കാരണം നിങ്ങൾക്ക് എല്ലാത്തിൽ നിന്നും സംഗ്രഹിക്കാം, മറയ്ക്കാം, കാരണം അഡ്മിൻ ബാക്കിയുള്ളവ കൈകാര്യം ചെയ്യും) - തന്നെ, അതിന്റെ ഇൻഫ്രാസ്ട്രക്ചർ, കൂടാതെ ആപ്ലിക്കേഷനുകൾ എങ്ങനെ നിരീക്ഷിക്കാമെന്ന് മനസിലാക്കുക. അകത്ത്.
• സേവനങ്ങൾ പരസ്പരം പ്രത്യേക രീതികളിൽ ആശയവിനിമയം നടത്തുന്നുവെന്നും സേവനങ്ങൾ എങ്ങനെ പരസ്പരം ഇടപഴകുന്നു എന്നതിന്റെ പ്രത്യേകതകൾ അറിയണമെന്നും അദ്ദേഹം മനസ്സിലാക്കണം. ചില സേവനങ്ങൾ സിൻക്രണസ് ആയി ആശയവിനിമയം നടത്തുന്ന ഒരു പ്രോജക്റ്റ് കാണുന്നത് തികച്ചും സാദ്ധ്യമാണ്, കാരണം മറ്റൊരു മാർഗവുമില്ല. ഉദാഹരണത്തിന്, ബാക്കെൻഡ് REST വഴി, gRPC വഴി കാറ്റലോഗ് സേവനത്തിലേക്ക് പോകുന്നു, ഉൽപ്പന്നങ്ങളുടെ ഒരു ലിസ്റ്റ് സ്വീകരിക്കുകയും അത് തിരികെ നൽകുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് ഇവിടെ കാത്തിരിക്കാനാവില്ല. മറ്റ് സേവനങ്ങൾക്കൊപ്പം ഇത് അസമന്വിതമായി പ്രവർത്തിക്കുന്നു. ഡെലിവറി സേവനത്തിലേക്ക് ഓർഡർ കൈമാറുക, ഒരു കത്ത് അയയ്ക്കുക തുടങ്ങിയവ.
  ഇതിൽ നിന്നെല്ലാം നിങ്ങൾ ഇതിനകം നീന്തിയിട്ടുണ്ടാകുമോ? ഇത് നിരീക്ഷിക്കേണ്ട അഡ്മിൻ കൂടുതൽ ആശയക്കുഴപ്പത്തിലായി.
• കൃത്യമായി ആസൂത്രണം ചെയ്യാനും ആസൂത്രണം ചെയ്യാനും അയാൾക്ക് കഴിയണം - ജോലി കൂടുതൽ കൂടുതൽ ആകുമ്പോൾ.
• അതിനാൽ, സൃഷ്ടിച്ച സേവനത്തിൽ നിന്ന് എങ്ങനെ പ്രത്യേകമായി നിരീക്ഷിക്കാമെന്ന് മനസിലാക്കാൻ അവൻ അതിൽ നിന്ന് ഒരു തന്ത്രം സൃഷ്ടിക്കണം. പ്രോജക്റ്റിന്റെ വാസ്തുവിദ്യയെക്കുറിച്ചും അതിന്റെ വികസനത്തെക്കുറിച്ചും അദ്ദേഹത്തിന് ഒരു ധാരണ ആവശ്യമാണ് + വികസനത്തിൽ ഉപയോഗിക്കുന്ന സാങ്കേതികവിദ്യകളെക്കുറിച്ചുള്ള ധാരണ.

തികച്ചും സാധാരണമായ ഒരു കേസ് നമുക്ക് ഓർക്കാം: ചില സേവനങ്ങൾ PHP-യിലും ചില സേവനങ്ങൾ Go-യിലും ചില സേവനങ്ങൾ JS-ലുമാണ്. അവർ എങ്ങനെയെങ്കിലും പരസ്പരം പ്രവർത്തിക്കുന്നു. ഇവിടെ നിന്നാണ് "മൈക്രോ സർവീസ്" എന്ന പദം വരുന്നത്: ഡവലപ്പർമാർക്ക് പ്രോജക്റ്റ് മൊത്തത്തിൽ മനസ്സിലാക്കാൻ കഴിയാത്ത നിരവധി വ്യക്തിഗത സംവിധാനങ്ങളുണ്ട്. ടീമിന്റെ ഒരു ഭാഗം JS-ൽ സ്വന്തമായി പ്രവർത്തിക്കുന്ന സേവനങ്ങൾ എഴുതുന്നു, ബാക്കിയുള്ള സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് അറിയില്ല. മറ്റൊരു ഭാഗം പൈത്തണിൽ സേവനങ്ങൾ എഴുതുന്നു, മറ്റ് സേവനങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെ തടസ്സപ്പെടുത്തുന്നില്ല; അവർ സ്വന്തം പ്രദേശത്ത് ഒറ്റപ്പെട്ടിരിക്കുന്നു. മൂന്നാമത്തേത് PHP അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും സേവനങ്ങൾ എഴുതുന്നു.
ഈ 20 പേരെയും 15 സേവനങ്ങളായി തിരിച്ചിരിക്കുന്നു, ഇതെല്ലാം മനസ്സിലാക്കേണ്ട ഒരു അഡ്മിൻ മാത്രമേയുള്ളൂ. നിർത്തുക! 15 പേർക്ക് മുഴുവൻ സിസ്റ്റവും മനസ്സിലാക്കാൻ കഴിയാത്തതിനാൽ ഞങ്ങൾ സിസ്റ്റത്തെ 20 മൈക്രോ സർവീസുകളായി വിഭജിച്ചു.

പക്ഷെ അത് എങ്ങനെയെങ്കിലും നിരീക്ഷിക്കേണ്ടതുണ്ട് ...

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

ഞാൻ എന്ത് പറയും... ഹൂസ്റ്റൺ, ഞങ്ങൾക്ക് പ്രശ്നങ്ങളുണ്ട്.

ഒരു ആധുനിക സോഫ്‌റ്റ്‌വെയർ പ്രോജക്‌റ്റ് നിരീക്ഷിക്കുന്നത് ഒരു സോഫ്റ്റ്‌വെയർ പ്രോജക്‌റ്റാണ്

നിരീക്ഷണം സോഫ്‌റ്റ്‌വെയറാണെന്ന തെറ്റായ വിശ്വാസത്തിൽ നിന്ന്, ഞങ്ങൾ അത്ഭുതങ്ങളിൽ ഒരു വിശ്വാസം വളർത്തിയെടുക്കുന്നു. എന്നാൽ അത്ഭുതങ്ങൾ, അയ്യോ, സംഭവിക്കുന്നില്ല. നിങ്ങൾക്ക് zabbix ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയില്ല, എല്ലാം പ്രവർത്തിക്കുമെന്ന് പ്രതീക്ഷിക്കുക. ഗ്രാഫാന ഇൻസ്റ്റാൾ ചെയ്ത് എല്ലാം ശരിയാകുമെന്ന് പ്രതീക്ഷിക്കുന്നതിൽ അർത്ഥമില്ല. സേവനങ്ങളുടെ പ്രവർത്തനത്തിന്റെയും പരസ്പര ഇടപെടലിന്റെയും പരിശോധനകൾ സംഘടിപ്പിക്കുന്നതിനും ബാഹ്യ സംവിധാനങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് പരിശോധിക്കുന്നതിനും കൂടുതൽ സമയവും ചെലവഴിക്കും. വാസ്തവത്തിൽ, 90% സമയവും സ്ക്രിപ്റ്റുകൾ എഴുതുന്നതിലല്ല, സോഫ്റ്റ്വെയർ വികസിപ്പിക്കുന്നതിനാണ് ചെലവഴിക്കുന്നത്. പ്രോജക്റ്റിന്റെ പ്രവർത്തനം മനസ്സിലാക്കുന്ന ഒരു ടീമാണ് ഇത് കൈകാര്യം ചെയ്യേണ്ടത്.
ഈ സാഹചര്യത്തിൽ ഒരാളെ നിരീക്ഷണത്തിലാക്കിയാൽ, ദുരന്തം സംഭവിക്കും. എല്ലായിടത്തും സംഭവിക്കുന്നത് അതാണ്.

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

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

അപ്പോൾ തുടക്കം മുതൽ ആരംഭിക്കുന്ന ഒരു പ്രോജക്റ്റ് എങ്ങനെ നിരീക്ഷിക്കാം, നിരീക്ഷിക്കേണ്ട ഒരു പ്രോജക്റ്റ് നിങ്ങൾക്ക് ലഭിക്കുകയാണെങ്കിൽ എന്തുചെയ്യണം, എന്നാൽ എവിടെ തുടങ്ങണമെന്ന് നിങ്ങൾക്കറിയില്ലേ?

ആദ്യം, നിങ്ങൾ ആസൂത്രണം ചെയ്യേണ്ടതുണ്ട്.

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

ആദ്യം, നിങ്ങൾ എന്താണ്, എങ്ങനെ നിരീക്ഷിക്കണമെന്ന് തീരുമാനിക്കുക, തുടർന്ന് ഒരു ഉപകരണം തിരഞ്ഞെടുക്കുക, കാരണം മറ്റുള്ളവർക്ക് നിങ്ങൾക്കായി ചിന്തിക്കാൻ കഴിയില്ല. അവർ വേണോ? മറ്റുള്ളവർ സ്വയം ചിന്തിച്ചു, ഒരു സാർവത്രിക സംവിധാനത്തെക്കുറിച്ച് - അല്ലെങ്കിൽ ഈ പ്ലഗിൻ എഴുതിയപ്പോൾ ചിന്തിച്ചില്ല. ഈ പ്ലഗിൻ 5 ആയിരം ഉപയോക്താക്കൾ ഉള്ളതിനാൽ അത് പ്രയോജനകരമാണെന്ന് അർത്ഥമാക്കുന്നില്ല. ഒരുപക്ഷേ നിങ്ങൾ 5001-ാമത്തെ ആളായി മാറിയേക്കാം, കാരണം മുമ്പ് അവിടെ 5000 ആളുകൾ ഉണ്ടായിരുന്നു.

നിങ്ങൾ ഇൻഫ്രാസ്ട്രക്ചർ നിരീക്ഷിക്കാൻ തുടങ്ങുകയും നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ബാക്കെൻഡ് പ്രതികരിക്കുന്നത് നിർത്തുകയും ചെയ്താൽ, എല്ലാ ഉപയോക്താക്കൾക്കും മൊബൈൽ ആപ്ലിക്കേഷനുമായുള്ള ബന്ധം നഷ്ടപ്പെടും. ഒരു പിശക് ദൃശ്യമാകും. അവർ നിങ്ങളുടെ അടുത്ത് വന്ന് "അപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നില്ല, നിങ്ങൾ ഇവിടെ എന്താണ് ചെയ്യുന്നത്?" - "ഞങ്ങൾ നിരീക്ഷിക്കുന്നു." - "ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നില്ലെന്ന് നിങ്ങൾ കാണുന്നില്ലെങ്കിൽ നിങ്ങൾ എങ്ങനെ നിരീക്ഷിക്കും?!"

1. ഉപയോക്താവിന്റെ എൻട്രി പോയിന്റിൽ നിന്ന് കൃത്യമായി നിരീക്ഷണം ആരംഭിക്കേണ്ടതുണ്ടെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉപയോക്താവ് കാണുന്നില്ലെങ്കിൽ, അത്രയേയുള്ളൂ, ഇത് ഒരു പരാജയമാണ്. മോണിറ്ററിംഗ് സിസ്റ്റം ആദ്യം ഇതിനെക്കുറിച്ച് മുന്നറിയിപ്പ് നൽകണം.
2. അതിനുശേഷം മാത്രമേ നമുക്ക് അടിസ്ഥാന സൗകര്യങ്ങൾ നിരീക്ഷിക്കാൻ കഴിയൂ. അല്ലെങ്കിൽ സമാന്തരമായി ചെയ്യുക. ഇൻഫ്രാസ്ട്രക്ചർ ഉപയോഗിച്ച് ഇത് എളുപ്പമാണ് - ഇവിടെ നമുക്ക് ഒടുവിൽ zabbix ഇൻസ്റ്റാൾ ചെയ്യാം.
3. കാര്യങ്ങൾ എവിടെയാണ് പ്രവർത്തിക്കാത്തതെന്ന് മനസിലാക്കാൻ ഇപ്പോൾ നിങ്ങൾ ആപ്ലിക്കേഷന്റെ വേരുകളിലേക്ക് പോകേണ്ടതുണ്ട്.

വികസന പ്രക്രിയയ്ക്ക് സമാന്തരമായി നിരീക്ഷണം നടത്തണം എന്നതാണ് എന്റെ പ്രധാന ആശയം. മറ്റ് ടാസ്‌ക്കുകൾക്കായി നിങ്ങൾ മോണിറ്ററിംഗ് ടീമിന്റെ ശ്രദ്ധ തിരിക്കുകയാണെങ്കിൽ (CI/CD സൃഷ്‌ടിക്കുക, സാൻഡ്‌ബോക്‌സിംഗ്, ഇൻഫ്രാസ്ട്രക്ചർ പുനഃസംഘടിപ്പിക്കൽ), മോണിറ്ററിംഗ് കാലതാമസം നേരിടാൻ തുടങ്ങും, നിങ്ങൾ ഒരിക്കലും വികസനവുമായി ബന്ധപ്പെട്ടേക്കില്ല (അല്ലെങ്കിൽ താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് നിങ്ങൾ അത് നിർത്തേണ്ടിവരും).

എല്ലാം ലെവലുകൾ അനുസരിച്ച്

ഒരു മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ ഓർഗനൈസേഷനെ ഞാൻ കാണുന്നത് ഇങ്ങനെയാണ്.

1) ആപ്ലിക്കേഷൻ ലെവൽ:

• ആപ്ലിക്കേഷൻ ബിസിനസ് ലോജിക് നിരീക്ഷിക്കൽ;
• സേവനങ്ങളുടെ ആരോഗ്യ അളവുകൾ നിരീക്ഷിക്കൽ;
• സംയോജന നിരീക്ഷണം.

2) ഇൻഫ്രാസ്ട്രക്ചർ ലെവൽ:

• ഓർക്കസ്ട്രേഷൻ ലെവൽ നിരീക്ഷണം;
• സിസ്റ്റം സോഫ്റ്റ്വെയർ നിരീക്ഷണം;
• ഇരുമ്പ് നില നിരീക്ഷണം.

3) വീണ്ടും ആപ്ലിക്കേഷൻ ലെവൽ - എന്നാൽ ഒരു എഞ്ചിനീയറിംഗ് ഉൽപ്പന്നമായി:

• ആപ്ലിക്കേഷൻ ലോഗുകൾ ശേഖരിക്കുകയും നിരീക്ഷിക്കുകയും ചെയ്യുക;
• എപിഎം;
• കണ്ടെത്തൽ.

4) മുന്നറിയിപ്പ്:

• ഒരു മുന്നറിയിപ്പ് സംവിധാനത്തിന്റെ ഓർഗനൈസേഷൻ;
• ഒരു ഡ്യൂട്ടി സംവിധാനത്തിന്റെ ഓർഗനൈസേഷൻ;
• ഒരു "വിജ്ഞാന അടിത്തറ" യുടെ ഓർഗനൈസേഷനും സംഭവം പ്രോസസ്സിംഗിനുള്ള വർക്ക്ഫ്ലോയും.

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

ആപ്ലിക്കേഷൻ ലെയർ - ബിസിനസ് ലോജിക് മോണിറ്ററിംഗ്

ആപ്ലിക്കേഷൻ ഉപയോക്താവിനായി പ്രവർത്തിക്കുന്നു എന്ന വസ്തുത പരിശോധിക്കുന്നതിനെക്കുറിച്ചാണ് ഞങ്ങൾ ഇവിടെ സംസാരിക്കുന്നത്.

വികസന ഘട്ടത്തിൽ ഈ ലെവൽ ചെയ്യണം. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ഒരു സോപാധികമായ പ്രോമിത്യൂസ് ഉണ്ട്: അത് പരിശോധനകൾ നടത്തുന്ന സെർവറിലേക്ക് പോകുന്നു, എൻഡ്‌പോയിന്റ് വലിക്കുന്നു, എൻഡ്‌പോയിന്റ് പോയി API പരിശോധിക്കുന്നു.

സൈറ്റ് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഹോം പേജ് നിരീക്ഷിക്കാൻ പലപ്പോഴും ആവശ്യപ്പെടുമ്പോൾ, പ്രോഗ്രാമർമാർ API പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ആവശ്യമുള്ളപ്പോഴെല്ലാം വലിക്കാവുന്ന ഒരു ഹാൻഡിൽ നൽകുന്നു. ഈ നിമിഷം പ്രോഗ്രാമർമാർ ഇപ്പോഴും /api/test/helloworld എടുത്ത് എഴുതുന്നു
എല്ലാം പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനുള്ള ഏക മാർഗം? - ഇല്ല!

• അത്തരം പരിശോധനകൾ സൃഷ്ടിക്കുന്നത് പ്രധാനമായും ഡെവലപ്പർമാരുടെ ചുമതലയാണ്. കോഡ് എഴുതുന്ന പ്രോഗ്രാമർമാരാണ് യൂണിറ്റ് ടെസ്റ്റുകൾ എഴുതേണ്ടത്. കാരണം നിങ്ങൾ അത് അഡ്‌മിന് ചോർത്തുകയാണെങ്കിൽ, “സുഹൃത്തേ, എല്ലാ 25 ഫംഗ്‌ഷനുകൾക്കുമുള്ള API പ്രോട്ടോക്കോളുകളുടെ ഒരു ലിസ്റ്റ് ഇതാ, ദയവായി എല്ലാം നിരീക്ഷിക്കുക!” - ഒന്നും പ്രവർത്തിക്കില്ല.
• നിങ്ങൾ "ഹലോ വേൾഡ്" എന്ന് പ്രിന്റ് ചെയ്യുകയാണെങ്കിൽ, API പ്രവർത്തിക്കേണ്ടതും പ്രവർത്തിക്കുന്നതും ആരും ഒരിക്കലും അറിയുകയില്ല. ഓരോ API മാറ്റവും ചെക്കുകളിൽ മാറ്റത്തിന് കാരണമാകണം.
• നിങ്ങൾക്ക് ഇതിനകം അത്തരമൊരു പ്രശ്‌നമുണ്ടെങ്കിൽ, സവിശേഷതകൾ നിർത്തി, ഈ ചെക്കുകൾ എഴുതുന്ന ഡെവലപ്പർമാരെ അനുവദിക്കുക, അല്ലെങ്കിൽ നഷ്ടങ്ങൾ അംഗീകരിക്കുക, ഒന്നും പരിശോധിച്ചിട്ടില്ലെന്നും പരാജയപ്പെടുമെന്നും അംഗീകരിക്കുക.

സാങ്കേതിക നുറുങ്ങുകൾ:

• പരിശോധനകൾ ഓർഗനൈസുചെയ്യുന്നതിന് ഒരു ബാഹ്യ സെർവർ സംഘടിപ്പിക്കുന്നത് ഉറപ്പാക്കുക - നിങ്ങളുടെ പ്രോജക്റ്റ് പുറം ലോകത്തിന് ആക്‌സസ് ചെയ്യാനാകുമെന്ന് നിങ്ങൾക്ക് ഉറപ്പുണ്ടായിരിക്കണം.
• വ്യക്തിഗത എൻഡ് പോയിന്റുകൾ മാത്രമല്ല, മുഴുവൻ എപിഐ പ്രോട്ടോക്കോളിലുടനീളം പരിശോധനകൾ സംഘടിപ്പിക്കുക.
• പരിശോധനാ ഫലങ്ങൾക്കൊപ്പം ഒരു പ്രോമിത്യൂസ്-എൻഡ് പോയിന്റ് സൃഷ്ടിക്കുക.

ആപ്ലിക്കേഷൻ ലെയർ - ഹെൽത്ത് മെട്രിക്സ് മോണിറ്ററിംഗ്

ഇപ്പോൾ നമ്മൾ സംസാരിക്കുന്നത് സേവനങ്ങളുടെ ബാഹ്യ ഹെൽത്ത് മെട്രിക്സിനെക്കുറിച്ചാണ്.

ഒരു ബാഹ്യ മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്ന് ഞങ്ങൾ വിളിക്കുന്ന ബാഹ്യ പരിശോധനകൾ ഉപയോഗിച്ച് ആപ്ലിക്കേഷന്റെ എല്ലാ "ഹാൻഡിലുകളും" നിരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. എന്നാൽ ഉപയോക്താവ് "കാണുന്ന" "ഹാൻഡിലുകൾ" ഇവയാണ്. ഞങ്ങളുടെ സേവനങ്ങൾ തന്നെ പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇവിടെ ഒരു മികച്ച കഥയുണ്ട്: K8s- ന് ആരോഗ്യ പരിശോധനകൾ ഉണ്ട്, അങ്ങനെ കുറഞ്ഞത് "ക്യൂബ്" തന്നെ സേവനം പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ബോധ്യപ്പെടുത്താൻ കഴിയും. എന്നാൽ ഞാൻ കണ്ട ചെക്കുകളിൽ പകുതിയും അതേ പ്രിന്റ് “ഹലോ വേൾഡ്” ആണ്. ആ. വിന്യസിച്ചതിന് ശേഷം അദ്ദേഹം ഒരിക്കൽ വലിക്കുന്നു, എല്ലാം ശരിയാണെന്ന് അദ്ദേഹം മറുപടി നൽകി - അത്രമാത്രം. സേവനത്തിന്, അതിന്റേതായ API നൽകുന്നുണ്ടെങ്കിൽ, അതേ API-യ്‌ക്ക് ധാരാളം എൻട്രി പോയിന്റുകൾ ഉണ്ട്, അത് നിരീക്ഷിക്കേണ്ടതുണ്ട്, കാരണം അത് പ്രവർത്തിക്കുന്നുവെന്ന് അറിയാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ ഇതിനകം അത് ഉള്ളിൽ നിരീക്ഷിക്കുന്നു.

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

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

ആപ്ലിക്കേഷൻ ലെയർ - ഇന്റഗ്രേഷൻ മോണിറ്ററിംഗ്

ബിസിനസ്-നിർണ്ണായക സംവിധാനങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയം നിരീക്ഷിക്കുന്നതിൽ ഇന്റഗ്രേഷൻ മോണിറ്ററിംഗ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.

ഉദാഹരണത്തിന്, പരസ്പരം ആശയവിനിമയം നടത്തുന്ന 15 സേവനങ്ങളുണ്ട്. ഇവ ഇപ്പോൾ പ്രത്യേക സൈറ്റുകളല്ല. ആ. ഞങ്ങൾക്ക് സേവനം സ്വന്തമായി പിൻവലിക്കാനും /ഹെല്ലോവേൾഡ് നേടാനും സേവനം പ്രവർത്തിക്കുന്നുണ്ടെന്ന് മനസ്സിലാക്കാനും കഴിയില്ല. കാരണം, ഓർഡർ ചെയ്യുന്ന വെബ് സേവനം ബസിലേക്ക് ഓർഡറിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ അയയ്ക്കണം - ബസിൽ നിന്ന്, വെയർഹൗസ് സേവനത്തിന് ഈ സന്ദേശം ലഭിക്കുകയും അതുമായി കൂടുതൽ പ്രവർത്തിക്കുകയും വേണം. ഇമെയിൽ വിതരണ സേവനം ഇത് എങ്ങനെയെങ്കിലും കൂടുതൽ പ്രോസസ്സ് ചെയ്യണം.

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

എന്താണ് ചെയ്യാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നത്:

• സിൻക്രണസ് കമ്മ്യൂണിക്കേഷനായി: എൻഡ്‌പോയിന്റ് ബന്ധപ്പെട്ട സേവനങ്ങളിലേക്ക് അഭ്യർത്ഥനകൾ നടത്തുന്നു. ആ. ഞങ്ങൾ ഈ അവസാന പോയിന്റ് എടുക്കുന്നു, സേവനത്തിനുള്ളിൽ ഒരു സ്‌ക്രിപ്റ്റ് വലിക്കുക, അത് എല്ലാ പോയിന്റുകളിലേക്കും പോയി “എനിക്ക് അവിടെ വലിക്കാം, അവിടെ വലിക്കാം, എനിക്ക് അവിടെ വലിക്കാം...” എന്ന് പറയുന്നു.
• അസിൻക്രണസ് ആശയവിനിമയത്തിനായി: ഇൻകമിംഗ് സന്ദേശങ്ങൾ - ടെസ്റ്റ് സന്ദേശങ്ങൾക്കായി എൻഡ്‌പോയിന്റ് ബസിനെ പരിശോധിക്കുകയും പ്രോസസ്സിംഗ് നില പ്രദർശിപ്പിക്കുകയും ചെയ്യുന്നു.
• അസമന്വിത ആശയവിനിമയത്തിന്: ഔട്ട്‌ഗോയിംഗ് സന്ദേശങ്ങൾ - എൻഡ്‌പോയിന്റ് ബസിലേക്ക് ടെസ്റ്റ് സന്ദേശങ്ങൾ അയയ്ക്കുന്നു.

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

“കോംബാറ്റ് ഡാറ്റയിൽ ഇത് എങ്ങനെ പരിശോധിക്കാം?” എന്ന ചോദ്യം പലപ്പോഴും നമ്മൾ കേൾക്കാറുണ്ട്. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഒരേ ഓർഡർ സേവനത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. സാധനങ്ങൾ എഴുതിത്തള്ളുന്ന വെയർഹൗസിലേക്ക് ഓർഡർ സന്ദേശങ്ങൾ അയയ്ക്കുന്നു: "എന്റെ സാധനങ്ങൾ എഴുതിത്തള്ളപ്പെടും!" പരിഹാരം: ഈ മുഴുവൻ പരീക്ഷയും തുടക്കത്തിൽ തന്നെ ആസൂത്രണം ചെയ്യുക. പരിഹസിക്കുന്ന യൂണിറ്റ് ടെസ്റ്റുകളും നിങ്ങൾക്കുണ്ട്. അതിനാൽ, ബിസിനസ്സിന്റെ പ്രവർത്തനത്തെ ദോഷകരമായി ബാധിക്കാത്ത ഒരു ആശയവിനിമയ ചാനൽ ഉള്ള ഒരു ആഴത്തിലുള്ള തലത്തിൽ ഇത് ചെയ്യുക.

ഇൻഫ്രാസ്ട്രക്ചർ ലെവൽ

ഇൻഫ്രാസ്ട്രക്ചർ മോണിറ്ററിംഗ് എന്നത് വളരെക്കാലമായി നിരീക്ഷണമായി കണക്കാക്കപ്പെട്ടിരുന്ന ഒന്നാണ്.

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

ഒരു ബിസിനസ് യൂണിറ്റായി അപേക്ഷാ നില

പ്രധാന പോയിന്റുകൾ:

• ELK. ഇതാണ് വ്യവസായ മാനദണ്ഡം. ചില കാരണങ്ങളാൽ നിങ്ങൾ ലോഗുകൾ സമാഹരിക്കുന്നില്ലെങ്കിൽ, ഉടൻ തന്നെ അത് ചെയ്യാൻ ആരംഭിക്കുക.
• എ.പി.എം. ആപ്ലിക്കേഷൻ മോണിറ്ററിംഗ് (NewRelic, BlackFire, Datadog) പെട്ടെന്ന് അടയ്ക്കുന്നതിനുള്ള ഒരു മാർഗമായി ബാഹ്യ APM-കൾ. നിങ്ങൾക്ക് എന്താണ് സംഭവിക്കുന്നതെന്ന് എങ്ങനെയെങ്കിലും മനസിലാക്കാൻ നിങ്ങൾക്ക് ഇത് താൽക്കാലികമായി ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും.
• ട്രാക്കിംഗ്. ഡസൻ കണക്കിന് മൈക്രോസർവീസുകളിൽ, നിങ്ങൾ എല്ലാം കണ്ടെത്തേണ്ടതുണ്ട്, കാരണം അഭ്യർത്ഥന സ്വന്തമായി നിലനിൽക്കില്ല. പിന്നീട് ചേർക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, അതിനാൽ വികസനത്തിൽ ട്രേസിംഗ് ഉടൻ ഷെഡ്യൂൾ ചെയ്യുന്നതാണ് നല്ലത് - ഇതാണ് ഡവലപ്പർമാരുടെ പ്രവർത്തനവും പ്രയോജനവും. നിങ്ങൾ ഇത് ഇതുവരെ നടപ്പിലാക്കിയിട്ടില്ലെങ്കിൽ, അത് നടപ്പിലാക്കുക! ജെയ്ഗർ/സിപ്കിൻ കാണുക

മുന്നറിയിപ്പ് നൽകുന്നു

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

ടെക്നോളജി സ്റ്റാക്ക്

ഞങ്ങളുടെ സ്റ്റാക്ക് ഇപ്രകാരമാണെന്ന് സങ്കൽപ്പിക്കുക:

• ഡാറ്റ ശേഖരണം - പ്രൊമിത്യൂസ് + ഗ്രാഫാന;
• ലോഗ് വിശകലനം - ELK;
• APM അല്ലെങ്കിൽ ട്രേസിങ്ങിനായി - ജെയ്ഗർ (സിപ്കിൻ).

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

ഈയിടെയായി എല്ലായിടത്തും ഞാൻ കാണുന്ന ചില സാങ്കേതിക പോയിന്റുകൾ:

പ്രോമിത്യൂസിനെ കുബർനെറ്റസിനുള്ളിലേക്ക് തള്ളിവിടുന്നു - ആരാണ് ഇത് കൊണ്ടുവന്നത്?! നിങ്ങളുടെ ക്ലസ്റ്റർ തകർന്നാൽ, നിങ്ങൾ എന്തു ചെയ്യും? നിങ്ങൾക്ക് ഉള്ളിൽ സങ്കീർണ്ണമായ ഒരു ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, ക്ലസ്റ്ററിനുള്ളിൽ ഏതെങ്കിലും തരത്തിലുള്ള നിരീക്ഷണ സംവിധാനം ഉണ്ടായിരിക്കണം, കൂടാതെ ചിലത് ക്ലസ്റ്ററിനുള്ളിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കും.

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

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

• വികസനം നിരീക്ഷിക്കുന്നത് യൂട്ടിലിറ്റികളുടെ ഇൻസ്റ്റാളേഷനല്ല, മറിച്ച് ഒരു സോഫ്റ്റ്വെയർ ഉൽപ്പന്നത്തിന്റെ വികസനമാണ്. ഇന്നത്തെ നിരീക്ഷണത്തിന്റെ 98% കോഡിംഗാണ്. സേവനങ്ങളിൽ കോഡിംഗ്, ബാഹ്യ പരിശോധനകൾ കോഡിംഗ്, ബാഹ്യ സേവനങ്ങൾ പരിശോധിക്കൽ, അത്രമാത്രം.
• നിരീക്ഷണത്തിനായി നിങ്ങളുടെ ഡെവലപ്പർമാരുടെ സമയം പാഴാക്കരുത്: ഇത് അവരുടെ ജോലിയുടെ 30% വരെ എടുത്തേക്കാം, പക്ഷേ അത് വിലമതിക്കുന്നു.
• Devops, നിങ്ങൾക്ക് എന്തെങ്കിലും നിരീക്ഷിക്കാൻ കഴിയില്ലെന്ന് വിഷമിക്കേണ്ട, കാരണം ചില കാര്യങ്ങൾ തികച്ചും വ്യത്യസ്തമായ ചിന്താരീതിയാണ്. നിങ്ങൾ ഒരു പ്രോഗ്രാമർ ആയിരുന്നില്ല, നിരീക്ഷണ ജോലി കൃത്യമായി അവരുടെ ജോലിയാണ്.
• പ്രോജക്റ്റ് ഇതിനകം പ്രവർത്തിക്കുകയും നിരീക്ഷിക്കുകയും ചെയ്യുന്നില്ലെങ്കിൽ (നിങ്ങൾ ഒരു മാനേജരാണ്), നിരീക്ഷണത്തിനായി വിഭവങ്ങൾ അനുവദിക്കുക.
• ഉൽപ്പന്നം ഇതിനകം ഉൽപ്പാദനത്തിലാണെങ്കിൽ, നിങ്ങൾ "മോണിറ്ററിംഗ് സജ്ജീകരിക്കാൻ" പറഞ്ഞിട്ടുള്ള ഒരു devops ആണെങ്കിൽ - ഞാൻ എന്താണ് എഴുതിയതെന്ന് മാനേജ്മെന്റിനോട് വിശദീകരിക്കാൻ ശ്രമിക്കുക.

സെന്റ് ഹൈലോഡ്++ കോൺഫറൻസിലെ റിപ്പോർട്ടിന്റെ വിപുലമായ പതിപ്പാണിത്.

അതിനെക്കുറിച്ചുള്ള എന്റെ ആശയങ്ങളിലും ചിന്തകളിലും അനുബന്ധ വിഷയങ്ങളിലും നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, ഇവിടെ നിങ്ങൾക്ക് കഴിയും ചാനൽ വായിച്ചു 🙂

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