വെബ് പ്രോജക്റ്റുകളുടെ ലഭ്യത ഉറപ്പാക്കുന്നതിനുള്ള ഒരു സമീപനമാണ് SRE (സൈറ്റ് വിശ്വാസ്യത എഞ്ചിനീയറിംഗ്). ഇത് DevOps-നുള്ള ഒരു ചട്ടക്കൂടായി കണക്കാക്കുകയും DevOps പ്രാക്ടീസുകൾ പ്രയോഗിക്കുന്നതിൽ എങ്ങനെ വിജയം നേടാം എന്നതിനെ കുറിച്ച് സംസാരിക്കുകയും ചെയ്യുന്നു. ഈ ലേഖനത്തിലെ വിവർത്തനം അധ്യായം 6 മോണിറ്ററിംഗ് ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങൾ പുസ്തകങ്ങൾ സൈറ്റ് വിശ്വാസ്യത എഞ്ചിനീയറിംഗ് Google-ൽ നിന്ന്. ഞാൻ ഈ വിവർത്തനം സ്വയം തയ്യാറാക്കുകയും നിരീക്ഷണ പ്രക്രിയകൾ മനസ്സിലാക്കുന്നതിൽ എന്റെ സ്വന്തം അനുഭവത്തെ ആശ്രയിക്കുകയും ചെയ്തു. ടെലിഗ്രാം ചാനലിൽ @monitorim_it и മീഡിയത്തിൽ ബ്ലോഗ് സേവനതല ലക്ഷ്യങ്ങളെക്കുറിച്ചുള്ള അതേ പുസ്തകത്തിന്റെ നാലാം അധ്യായത്തിന്റെ വിവർത്തനത്തിലേക്കുള്ള ലിങ്കും ഞാൻ പ്രസിദ്ധീകരിച്ചു.

പൂച്ചയുടെ വിവർത്തനം. വായന ആസ്വദിക്കൂ!

വിജയകരമായ നിരീക്ഷണ, അറിയിപ്പ് സംവിധാനങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള അടിസ്ഥാന തത്വങ്ങളും മികച്ച രീതികളും Google-ന്റെ SRE ടീമുകൾക്ക് ഉണ്ട്. ഒരു വെബ് പേജ് സന്ദർശകർക്ക് എന്ത് പ്രശ്‌നങ്ങൾ നേരിടേണ്ടി വന്നേക്കാം എന്നതിനെക്കുറിച്ചും വെബ് പേജുകൾ പ്രദർശിപ്പിക്കുന്നത് ബുദ്ധിമുട്ടുള്ള പ്രശ്‌നങ്ങൾ എങ്ങനെ പരിഹരിക്കാമെന്നതിനെക്കുറിച്ചും ഈ അധ്യായം മാർഗ്ഗനിർദ്ദേശം നൽകുന്നു.

നിർവചനങ്ങൾ

നിരീക്ഷണവുമായി ബന്ധപ്പെട്ട വിഷയങ്ങൾ ചർച്ച ചെയ്യാൻ ഒരൊറ്റ പദാവലിയും ഉപയോഗിക്കുന്നില്ല. Google-ൽ പോലും, ചുവടെയുള്ള പദങ്ങൾ സാധാരണയായി ഉപയോഗിക്കാറില്ല, എന്നാൽ ഞങ്ങൾ ഏറ്റവും സാധാരണമായ വ്യാഖ്യാനങ്ങൾ ലിസ്റ്റ് ചെയ്യും.

നിരീക്ഷിക്കുന്നു

സിസ്റ്റത്തെക്കുറിച്ചുള്ള തത്സമയം അളവ് ഡാറ്റയുടെ ശേഖരണം, പ്രോസസ്സിംഗ്, സംഗ്രഹം, പ്രദർശിപ്പിക്കൽ: അഭ്യർത്ഥനകളുടെയും അഭ്യർത്ഥനകളുടെയും എണ്ണം, പിശകുകളുടെയും പിശകുകളുടെയും എണ്ണം, അഭ്യർത്ഥന പ്രോസസ്സിംഗ് സമയവും സെർവർ പ്രവർത്തന സമയവും.

വൈറ്റ് ബോക്സ് നിരീക്ഷണം

ലോഗുകൾ, ജാവ വെർച്വൽ മെഷീൻ പ്രൊഫൈലിംഗ് മെട്രിക്‌സ് അല്ലെങ്കിൽ ആന്തരിക സ്ഥിതിവിവരക്കണക്കുകൾ സൃഷ്ടിക്കുന്ന HTTP ഹാൻഡ്‌ലർ മെട്രിക്‌സ് എന്നിവയുൾപ്പെടെ ആന്തരിക സിസ്റ്റം ഘടകങ്ങൾ പ്രദർശിപ്പിക്കുന്ന മെട്രിക്‌സിനെ അടിസ്ഥാനമാക്കിയുള്ള നിരീക്ഷണം.

ബ്ലാക്ക് ബോക്സ് നിരീക്ഷണം

ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന് ആപ്ലിക്കേഷൻ സ്വഭാവം പരിശോധിക്കുന്നു.

ഡാഷ്ബോർഡ്

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

മുന്നറിയിപ്പ് (അറിയിപ്പ്)

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

മൂലകാരണം

ഒരു സോഫ്‌റ്റ്‌വെയർ തകരാർ അല്ലെങ്കിൽ മാനുഷിക പിശക്, ഒരിക്കൽ തിരുത്തിയാൽ, വീണ്ടും സംഭവിക്കരുത്. പ്രശ്‌നത്തിന് നിരവധി പ്രധാന കാരണങ്ങളുണ്ടാകാം: അപര്യാപ്തമായ പ്രോസസ്സ് ഓട്ടോമേഷൻ, സോഫ്റ്റ്‌വെയർ വൈകല്യം, ആപ്ലിക്കേഷൻ ലോജിക്കിന്റെ അപര്യാപ്തമായ വിശദീകരണം. ഈ ഘടകങ്ങളിൽ ഓരോന്നും മൂലകാരണമായിരിക്കാം, അവ ഓരോന്നും ഇല്ലാതാക്കണം.

നോഡും മെഷീനും (നോഡും മെഷീനും)

ഒരു ഫിസിക്കൽ സെർവറിലോ വെർച്വൽ മെഷീനിലോ കണ്ടെയ്‌നറിലോ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷന്റെ ഒരൊറ്റ ഉദാഹരണത്തെ സൂചിപ്പിക്കാൻ പരസ്പരം മാറ്റാവുന്ന പദങ്ങൾ. ഒരു മെഷീന് നിരവധി സേവനങ്ങൾ ഹോസ്റ്റ് ചെയ്യാൻ കഴിയും. സേവനങ്ങൾ ഇവയാകാം:

• പരസ്പരം ബന്ധിപ്പിച്ചിരിക്കുന്നു: ഉദാഹരണത്തിന്, ഒരു കാഷിംഗ് സെർവറും ഒരു വെബ് സെർവറും;
• ഒരൊറ്റ ഹാർഡ്‌വെയറിലെ ബന്ധമില്ലാത്ത സേവനങ്ങൾ: ഉദാഹരണത്തിന്, ഒരു കോഡ് ശേഖരണവും കോൺഫിഗറേഷൻ സിസ്റ്റത്തിനായുള്ള ഒരു വിസാർഡും. പാവ അഥവാ തല.

ഉന്ത്

സോഫ്റ്റ്‌വെയർ കോൺഫിഗറേഷനിൽ എന്തെങ്കിലും മാറ്റം.

എന്തുകൊണ്ട് നിരീക്ഷണം ആവശ്യമാണ്

ആപ്ലിക്കേഷനുകൾ നിരീക്ഷിക്കേണ്ടതിന് നിരവധി കാരണങ്ങളുണ്ട്:

ദീർഘകാല പ്രവണതകളുടെ വിശകലനം

ഡാറ്റാബേസ് എത്ര വലുതാണ്, അത് എത്ര വേഗത്തിൽ വളരുന്നു? ദൈനംദിന ഉപയോക്താക്കളുടെ എണ്ണം എങ്ങനെ മാറുന്നു?

പ്രകടന താരതമ്യം

Ajax DB 2.72 നെ അപേക്ഷിച്ച് Acme Bucket of Bytes 3.14-ൽ അഭ്യർത്ഥനകൾ വേഗമേറിയതാണോ? ഒരു അധിക നോഡ് പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം അഭ്യർത്ഥനകൾ കാഷെ ചെയ്യുന്നത് എത്രത്തോളം മികച്ചതാണ്? കഴിഞ്ഞ ആഴ്‌ചയെ അപേക്ഷിച്ച് സൈറ്റ് മന്ദഗതിയിലാണോ പ്രവർത്തിക്കുന്നത്?

മുന്നറിയിപ്പ് (അറിയിപ്പുകൾ)

എന്തോ തകർന്നു, ആരെങ്കിലും അത് പരിഹരിക്കേണ്ടതുണ്ട്. അല്ലെങ്കിൽ എന്തെങ്കിലും ഉടൻ തകരും, ആരെങ്കിലും അത് ഉടൻ പരിശോധിക്കേണ്ടതുണ്ട്.

ഡാഷ്ബോർഡുകൾ സൃഷ്ടിക്കുന്നു

ഡാഷ്‌ബോർഡുകൾ അടിസ്ഥാന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുകയും അതിൽ നിന്ന് എന്തെങ്കിലും ഉൾപ്പെടുത്തുകയും വേണം "4 സുവർണ്ണ സിഗ്നലുകൾ" - കാലതാമസം (ലേറ്റൻസി), ട്രാഫിക് (ട്രാഫിക്), പിശകുകൾ (പിശകുകൾ), ലോഡ് വലുപ്പം (സാച്ചുറേഷൻ).

മുൻകാല വിശകലനം നടത്തുന്നു (ഡീബഗ്ഗിംഗ്)

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

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

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

മോണിറ്ററിംഗ് സിസ്റ്റത്തിനായി ന്യായമായ പ്രതീക്ഷകൾ സജ്ജമാക്കുന്നു

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

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

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

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

അതുപോലെ, ശബ്‌ദ നിലവാരം കുറയ്‌ക്കാനും സിഗ്നൽ ലെവലുകൾ ഉയർന്ന നിലയിലാക്കാനും, മുന്നറിയിപ്പ് നൽകുന്ന അസറ്റുകൾ നിരീക്ഷിക്കുന്നതിനുള്ള സമീപനങ്ങൾ വളരെ ലളിതവും വിശ്വസനീയവുമായിരിക്കണം. ആളുകൾക്ക് മുന്നറിയിപ്പുകൾ സൃഷ്ടിക്കുന്ന നിയമങ്ങൾ മനസ്സിലാക്കാനും വ്യക്തമായ പ്രശ്നം അവതരിപ്പിക്കാനും എളുപ്പമായിരിക്കണം.

ലക്ഷണങ്ങൾ, കാരണങ്ങൾ

നിങ്ങളുടെ നിരീക്ഷണ സംവിധാനം രണ്ട് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകണം: "എന്താണ് തകർന്നത്", "എന്തുകൊണ്ടാണ് അത് തകർന്നത്."
"എന്താണ് തകർന്നത്" രോഗലക്ഷണത്തെക്കുറിച്ച് സംസാരിക്കുന്നു, "എന്തുകൊണ്ടാണ് അത് തകർന്നത്" എന്നതിന്റെ കാരണത്തെക്കുറിച്ച് സംസാരിക്കുന്നു. താഴെയുള്ള പട്ടിക അത്തരം കണക്ഷനുകളുടെ ഉദാഹരണങ്ങൾ കാണിക്കുന്നു.

ഒരു ലക്ഷണം
കാരണം

HTTP പിശക് 500 അല്ലെങ്കിൽ 404 ലഭിക്കുന്നു
ഡാറ്റാബേസ് സെർവറുകൾ കണക്ഷനുകൾ നിരസിക്കുന്നു

മന്ദഗതിയിലുള്ള സെർവർ പ്രതികരണങ്ങൾ
ഉയർന്ന സിപിയു ഉപയോഗം അല്ലെങ്കിൽ കേടായ ഇഥർനെറ്റ് കേബിൾ

അന്റാർട്ടിക്കയിലെ ഉപയോക്താക്കൾക്ക് പൂച്ച GIF-കൾ ലഭിക്കുന്നില്ല
നിങ്ങളുടെ CDN ശാസ്ത്രജ്ഞരെയും പൂച്ചകളെയും വെറുക്കുന്നു, അതിനാൽ ചില IP വിലാസങ്ങൾ കരിമ്പട്ടികയിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്

എല്ലായിടത്തുനിന്നും സ്വകാര്യ ഉള്ളടക്കം ലഭ്യമായി
ഒരു പുതിയ സോഫ്‌റ്റ്‌വെയർ റിലീസിന്റെ റോളൗട്ട് ഫയർവാളിനെ എല്ലാ ACL-കളും മറക്കുകയും എല്ലാവരെയും അകത്തേക്ക് അനുവദിക്കുകയും ചെയ്തു

പരമാവധി സിഗ്നലും കുറഞ്ഞ ശബ്ദവും ഉള്ള ഒരു നല്ല നിരീക്ഷണ സംവിധാനം സൃഷ്ടിക്കുന്നതിനുള്ള ഏറ്റവും പ്രധാനപ്പെട്ട നിർമ്മാണ ബ്ലോക്കുകളിൽ ചിലതാണ് "എന്ത്", "എന്തുകൊണ്ട്".

ബ്ലാക്ക് ബോക്സ് vs വൈറ്റ് ബോക്സ്

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

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

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

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

നാല് സുവർണ്ണ സിഗ്നലുകൾ

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

കാലതാമസം

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

ട്രാഫിക്

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

തെറ്റുകൾ

ഇത് വ്യക്തമായ (ഉദാ: HTTP 500), പരോക്ഷമായ (ഉദാ: HTTP 200 എന്നാൽ അസാധുവായ ഉള്ളടക്കവുമായി സംയോജിപ്പിച്ചത്) അല്ലെങ്കിൽ നയം (ഉദാ: "നിങ്ങൾ ഒരു സെക്കൻഡിനുള്ളിൽ ഒരു പ്രതികരണം ക്യാപ്‌ചർ ചെയ്‌താൽ, ഏതെങ്കിലും ഒരു സെക്കൻഡ് പിശകാണ്") പരാജയപ്പെട്ട അഭ്യർത്ഥനകളുടെ നിരക്ക്. എല്ലാ പരാജയ സാഹചര്യങ്ങളും പ്രകടിപ്പിക്കാൻ HTTP പ്രതികരണ കോഡുകൾ പര്യാപ്തമല്ലെങ്കിൽ, ഭാഗിക പരാജയം കണ്ടെത്തുന്നതിന് ദ്വിതീയ (ആന്തരിക) പ്രോട്ടോക്കോളുകൾ ആവശ്യമായി വന്നേക്കാം. അത്തരം പരാജയപ്പെട്ട എല്ലാ അഭ്യർത്ഥനകളും നിരീക്ഷിക്കുന്നത് വിജ്ഞാനപ്രദമായേക്കില്ല, അതേസമയം നിങ്ങൾ തെറ്റായ ഉള്ളടക്കമാണ് പ്രോസസ്സ് ചെയ്യുന്നതെന്ന് കണ്ടെത്താൻ എൻഡ്-ടു-എൻഡ് സിസ്റ്റം ടെസ്റ്റുകൾ സഹായിക്കും.

സാച്ചുറേഷൻ

നിങ്ങളുടെ സേവനം എത്രമാത്രം തീവ്രമായി ഉപയോഗിക്കപ്പെടുന്നുവെന്ന് മെട്രിക് കാണിക്കുന്നു. ഇത് ഏറ്റവും പരിമിതമായ ഉറവിടങ്ങളെ തിരിച്ചറിയുന്ന ഒരു സിസ്റ്റം മോണിറ്ററിംഗ് അളവാണ് (ഉദാഹരണത്തിന്, മെമ്മറി-നിയന്ത്രിത സിസ്റ്റത്തിൽ, മെമ്മറി കാണിക്കുന്നു, ഒരു I/O- നിയന്ത്രിത സിസ്റ്റത്തിൽ, I/Os എണ്ണം കാണിക്കുന്നു). പല സിസ്റ്റങ്ങളും 100% വിനിയോഗത്തിൽ എത്തുന്നതിന് മുമ്പ് പ്രകടനത്തെ തരംതാഴ്ത്തുന്നു, അതിനാൽ ഒരു വിനിയോഗ ലക്ഷ്യം പ്രധാനമാണ്.

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

അവസാനമായി, സാച്ചുറേഷൻ വരാനിരിക്കുന്ന സാച്ചുറേഷൻ സംബന്ധിച്ച പ്രവചനങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, ഉദാഹരണത്തിന്: "നിങ്ങളുടെ ഡാറ്റാബേസ് 4 മണിക്കൂറിനുള്ളിൽ നിങ്ങളുടെ ഹാർഡ് ഡ്രൈവ് നിറയ്ക്കുമെന്ന് തോന്നുന്നു."

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

"വാൽ" (അല്ലെങ്കിൽ ഇൻസ്ട്രുമെന്റേഷനും പ്രകടനവും) സംബന്ധിച്ച ആശങ്കകൾ

ആദ്യം മുതൽ ഒരു മോണിറ്ററിംഗ് സിസ്റ്റം സൃഷ്ടിക്കുമ്പോൾ, ശരാശരി മൂല്യങ്ങളെ അടിസ്ഥാനമാക്കി ഒരു സിസ്റ്റം വികസിപ്പിക്കാനുള്ള ഒരു പ്രലോഭനമുണ്ട്: ശരാശരി ലേറ്റൻസി, നോഡുകളുടെ ശരാശരി സിപിയു ഉപയോഗം അല്ലെങ്കിൽ ശരാശരി ഡാറ്റാബേസ് പൂർണ്ണത. അവസാന രണ്ട് ഉദാഹരണങ്ങളുടെ അപകടം വ്യക്തമാണ്: പ്രോസസ്സറുകളും ഡാറ്റാബേസുകളും വളരെ പ്രവചനാതീതമായ രീതിയിൽ വിനിയോഗിക്കപ്പെടുന്നു. കാലതാമസത്തിനും ഇത് ബാധകമാണ്. സെക്കൻഡിൽ 100 അഭ്യർത്ഥനകളുള്ള ശരാശരി 1000 മി.എസ് ലേറ്റൻസിയുള്ള ഒരു വെബ് സേവനം നിങ്ങൾ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, 1% അഭ്യർത്ഥനകൾക്ക് 5 സെക്കൻഡ് എടുത്തേക്കാം. ഉപയോക്താക്കൾ അത്തരത്തിലുള്ള ഒന്നിലധികം വെബ് സേവനങ്ങളെ ആശ്രയിക്കുന്നുണ്ടെങ്കിൽ, ഒരു ബാക്കെൻഡിന്റെ 99-ാം ശതമാനം എളുപ്പത്തിൽ ഫ്രണ്ട്‌എൻഡിന്റെ മീഡിയൻ പ്രതികരണ സമയമായി മാറും.

അഭ്യർത്ഥനകളുടെ സ്ലോ ആവറേജും വളരെ മന്ദഗതിയിലുള്ള അഭ്യർത്ഥനകളും തമ്മിൽ വേർതിരിച്ചറിയാനുള്ള ഏറ്റവും ലളിതമായ മാർഗ്ഗം, യഥാർത്ഥ ലേറ്റൻസികൾക്ക് പകരം സ്ഥിതിവിവരക്കണക്കുകളിൽ പ്രകടിപ്പിക്കുന്ന അഭ്യർത്ഥനകളുടെ അളവുകൾ ശേഖരിക്കുക എന്നതാണ് (പ്രദർശനത്തിനുള്ള ഒരു നല്ല ഉപകരണം ഹിസ്റ്റോഗ്രാമുകളാണ്): സേവനത്തിന് 0 മി. കൂടാതെ 10 ms, 10 ms നും 30 ms നും ഇടയിൽ, 30 ms നും 100 ms നും ഇടയിൽ, 100 ms നും 300 ms നും ഇടയിൽ, മുതലായവ. ഹിസ്റ്റോഗ്രാം അതിരുകൾ ഏകദേശം വിസ്തൃതമായി വികസിപ്പിക്കുന്നത് (ഏകദേശം 3 ന്റെ ഘടകം കൊണ്ട്) പലപ്പോഴും വിതരണം ദൃശ്യവൽക്കരിക്കുന്നതിനുള്ള ഒരു ലളിതമായ മാർഗമാണ്. അഭ്യർത്ഥനകളുടെ.

അളവുകൾക്കായി വിശദാംശങ്ങളുടെ ഉചിതമായ തലം തിരഞ്ഞെടുക്കുന്നു

സിസ്റ്റത്തിന്റെ വിവിധ ഘടകങ്ങൾ വിശദാംശങ്ങളുടെ വ്യത്യസ്ത തലങ്ങളിൽ അളക്കണം. ഉദാഹരണത്തിന്:

• ഒരു നിശ്ചിത കാലയളവിൽ CPU ഉപയോഗം നിരീക്ഷിക്കുന്നത് ഉയർന്ന കാലതാമസത്തിലേക്ക് നയിക്കുന്ന ദീർഘകാല സ്പൈക്കുകൾ കാണിക്കില്ല.
• മറുവശത്ത്, പ്രതിവർഷം 9 മണിക്കൂറിൽ കൂടുതൽ പ്രവർത്തനരഹിതമായ ഒരു വെബ് സേവനത്തിനായി (99,9% വാർഷിക പ്രവർത്തനസമയം), ഒരു HTTP 200 പ്രതികരണത്തിനായി മിനിറ്റിൽ ഒന്നോ രണ്ടോ തവണ കൂടുതൽ തവണ പരിശോധിക്കുന്നത് അനാവശ്യമായി ഇടയ്ക്കിടെ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്.
• അതുപോലെ, ഓരോ 99,9-1 മിനിറ്റിലും ഒന്നിലധികം തവണ 2% ലഭ്യതയ്ക്കായി ഹാർഡ് ഡ്രൈവ് സ്ഥലം പരിശോധിക്കുന്നത് ഒരുപക്ഷേ ആവശ്യമില്ല.

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

1. ഓരോ സെക്കൻഡിലും CPU ലോഡ് അളക്കുക.
2. വിശദാംശങ്ങൾ 5% ആയി കുറയ്ക്കുക.
3. ഓരോ മിനിറ്റിലും മെട്രിക്കുകൾ സമാഹരിക്കുക.

ഉയർന്ന വിശകലനവും സ്റ്റോറേജ് ഓവർഹെഡും കൂടാതെ ഉയർന്ന ഗ്രാനുലാരിറ്റിയിൽ ഡാറ്റ ശേഖരിക്കാൻ ഈ തന്ത്രം നിങ്ങളെ അനുവദിക്കും.

കഴിയുന്നത്ര ലളിതമാണ്, പക്ഷേ ലളിതമല്ല

ഒന്നിനു മുകളിൽ ഒന്നായി വ്യത്യസ്‌തമായ ആവശ്യകതകളുടെ ഓവർലേ വളരെ സങ്കീർണമായ നിരീക്ഷണ സംവിധാനത്തിന് കാരണമാകും. ഉദാഹരണത്തിന്, നിങ്ങളുടെ സിസ്റ്റത്തിന് ഇനിപ്പറയുന്ന സങ്കീർണ്ണ ഘടകങ്ങൾ ഉണ്ടായിരിക്കാം:

• അഭ്യർത്ഥന പ്രോസസ്സിംഗ് ലേറ്റൻസിക്കായി വ്യത്യസ്ത പരിധികൾക്കനുസരിച്ചുള്ള അലേർട്ടുകൾ, വ്യത്യസ്ത ശതമാനത്തിൽ, എല്ലാത്തരം വ്യത്യസ്ത സൂചകങ്ങൾക്കും.
• സാധ്യമായ കാരണങ്ങൾ കണ്ടെത്തുന്നതിനും തിരിച്ചറിയുന്നതിനും അധിക കോഡ് എഴുതുന്നു.
• പ്രശ്നങ്ങളുടെ സാധ്യമായ ഓരോ കാരണങ്ങൾക്കും അനുബന്ധ ഡാഷ്ബോർഡുകൾ സൃഷ്ടിക്കുക.

സാധ്യമായ സങ്കീർണതയുടെ ഉറവിടങ്ങൾ ഒരിക്കലും അവസാനിക്കുന്നില്ല. എല്ലാ സോഫ്‌റ്റ്‌വെയർ സിസ്റ്റങ്ങളെയും പോലെ, മോണിറ്ററിംഗ് വളരെ സങ്കീർണ്ണമാകുകയും അത് ദുർബലമാവുകയും മാറ്റാനും പരിപാലിക്കാനും പ്രയാസകരമാക്കുകയും ചെയ്യും.

അതിനാൽ, കഴിയുന്നത്ര ലളിതമാക്കാൻ നിങ്ങളുടെ നിരീക്ഷണ സംവിധാനം രൂപകൽപ്പന ചെയ്യുക. എന്താണ് ട്രാക്ക് ചെയ്യേണ്ടതെന്ന് തിരഞ്ഞെടുക്കുമ്പോൾ, ഇനിപ്പറയുന്ന കാര്യങ്ങൾ മനസ്സിൽ വയ്ക്കുക:

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

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

തത്ത്വങ്ങൾ ഒരുമിച്ച് ബന്ധിപ്പിക്കുന്നു

ഈ അധ്യായത്തിൽ ചർച്ച ചെയ്‌തിരിക്കുന്ന തത്ത്വങ്ങൾ Google SRE ടീമുകൾ അംഗീകരിക്കുകയും പിന്തുടരുകയും ചെയ്യുന്ന ഒരു നിരീക്ഷണ, മുന്നറിയിപ്പ് തത്ത്വചിന്തയിലേക്ക് കൂട്ടിച്ചേർക്കാവുന്നതാണ്. ഈ മോണിറ്ററിംഗ് ഫിലോസഫി പാലിക്കുന്നത് അഭികാമ്യമാണ്, നിങ്ങളുടെ അലേർട്ടിംഗ് രീതിശാസ്ത്രം സൃഷ്ടിക്കുന്നതിനോ പരിഷ്കരിക്കുന്നതിനോ ഉള്ള ഒരു നല്ല തുടക്കമാണ്, കൂടാതെ നിങ്ങളുടെ ഓർഗനൈസേഷന്റെ വലുപ്പമോ സേവനത്തിന്റെയോ സിസ്റ്റത്തിന്റെയോ സങ്കീർണ്ണതയോ പരിഗണിക്കാതെ നിങ്ങളുടെ പ്രവർത്തന പ്രവർത്തനത്തെക്കുറിച്ചുള്ള ശരിയായ ചോദ്യങ്ങൾ ചോദിക്കാൻ നിങ്ങളെ സഹായിക്കാനും കഴിയും.

നിരീക്ഷണ, മുന്നറിയിപ്പ് നിയമങ്ങൾ സൃഷ്ടിക്കുമ്പോൾ, ഇനിപ്പറയുന്ന ചോദ്യങ്ങൾ ചോദിക്കുന്നത് തെറ്റായ പോസിറ്റീവുകളും അനാവശ്യ അലേർട്ടുകളും ഒഴിവാക്കാൻ നിങ്ങളെ സഹായിക്കും:

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

ഈ ചോദ്യങ്ങൾ അലേർട്ടുകളുടെയും മുന്നറിയിപ്പ് സംവിധാനങ്ങളുടെയും അടിസ്ഥാന തത്വശാസ്ത്രത്തെ പ്രതിഫലിപ്പിക്കുന്നു:

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

ഈ സമീപനം ചില വ്യതിരിക്തതകളെ മങ്ങിക്കുന്നു: അലേർട്ട് മുമ്പത്തെ നാല് വ്യവസ്ഥകൾ പാലിക്കുന്നുണ്ടെങ്കിൽ, ഒരു വൈറ്റ്-ബോക്‌സിൽ നിന്നോ ബ്ലാക്ക്-ബോക്‌സ് മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്നാണോ അലേർട്ട് അയച്ചത് എന്നത് പ്രശ്നമല്ല. ഈ സമീപനം ചില വ്യത്യാസങ്ങളെ ദൃഢപ്പെടുത്തുന്നു: കാരണങ്ങളേക്കാൾ രോഗലക്ഷണങ്ങൾ തിരിച്ചറിയാൻ കൂടുതൽ പരിശ്രമിക്കുന്നതാണ് നല്ലത്; കാരണങ്ങളെക്കുറിച്ച് പറയുമ്പോൾ, അനിവാര്യമായ കാരണങ്ങളെക്കുറിച്ച് മാത്രം നിങ്ങൾ വിഷമിക്കേണ്ടതുണ്ട്.

ദീർഘകാല നിരീക്ഷണം

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

ദീർഘകാല ലക്ഷ്യങ്ങൾ മനസ്സിൽ വെച്ചുകൊണ്ട് നിരീക്ഷണ തീരുമാനങ്ങൾ എടുക്കുന്നത് പ്രധാനമാണ്. ഇന്ന് പ്രവർത്തിക്കുന്ന എല്ലാ അലേർട്ടുകളും നാളെ സിസ്റ്റം മെച്ചപ്പെടുത്തുന്നതിൽ നിന്ന് ഒരു വ്യക്തിയെ വ്യതിചലിപ്പിക്കുന്നു, അതിനാൽ ദീർഘകാലാടിസ്ഥാനത്തിൽ നിരീക്ഷണ സംവിധാനം മെച്ചപ്പെടുത്തുന്നതിന് ആവശ്യമായ സമയത്തേക്ക് ഉൽപ്പാദനക്ഷമമായ സംവിധാനത്തിന്റെ ലഭ്യതയിലോ പ്രകടനത്തിലോ പലപ്പോഴും കുറവുണ്ടാകും. ഈ പ്രതിഭാസം വ്യക്തമാക്കുന്നതിന് നമുക്ക് രണ്ട് ഉദാഹരണങ്ങൾ നോക്കാം.

ബിഗ്‌ടേബിൾ SRE: എ ടെയിൽ ഓഫ് ഓവർ-അലേർട്ട്

Google-ന്റെ ആന്തരിക ഇൻഫ്രാസ്ട്രക്ചർ സാധാരണയായി ഒരു സേവന തലത്തിൽ (SLO) നൽകുകയും അളക്കുകയും ചെയ്യുന്നു. നിരവധി വർഷങ്ങൾക്ക് മുമ്പ്, ബിഗ്‌ടേബിളിന്റെ സേവനമായ SLO ഒരു തത്സമയ ക്ലയന്റിനെ അനുകരിക്കുന്ന ഒരു സിന്തറ്റിക് ഇടപാടിന്റെ ശരാശരി പ്രകടനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതായിരുന്നു. ബിഗ്‌ടേബിളിലെയും സ്‌റ്റോറേജ് സ്റ്റാക്കിന്റെ താഴ്ന്ന നിലകളിലെയും പ്രശ്‌നങ്ങൾ കാരണം, ശരാശരി പ്രകടനം ഒരു "വലിയ" വാലാൽ നയിക്കപ്പെട്ടു: ഏറ്റവും മോശം 5% അന്വേഷണങ്ങൾ ബാക്കിയുള്ളവയെ അപേക്ഷിച്ച് വളരെ മന്ദഗതിയിലായിരുന്നു.

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

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

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

Gmail: പ്രവചിക്കാവുന്ന, അൽഗോരിതമിക് ഹ്യൂമൻ പ്രതികരണങ്ങൾ

അതിന്റെ തുടക്കത്തിൽ, ഒരു തിരയൽ സൂചികയുടെ പ്രോസസ്സ് ഭാഗങ്ങൾ ബാച്ച് ചെയ്യാൻ രൂപകൽപ്പന ചെയ്ത പരിഷ്കരിച്ച വർക്ക്ക്യൂ പ്രോസസ് മാനേജ്മെന്റ് സിസ്റ്റത്തിലാണ് Gmail നിർമ്മിച്ചിരിക്കുന്നത്. വർക്ക്ക്യൂ ദീർഘകാല പ്രോസസ്സുകൾക്ക് അനുയോജ്യമാക്കുകയും പിന്നീട് Gmail-ൽ പ്രയോഗിക്കുകയും ചെയ്തു, എന്നാൽ അതാര്യമായ ഷെഡ്യൂളർ കോഡിലെ ചില ബഗുകൾ പരിഹരിക്കാൻ വളരെ ബുദ്ധിമുട്ടായിരുന്നു.

വർക്ക്ക്യൂ ഉപയോഗിച്ച് വ്യക്തിഗത ടാസ്ക്കുകൾ റദ്ദാക്കുമ്പോൾ അലേർട്ടുകൾ പ്രവർത്തനക്ഷമമാക്കുന്ന തരത്തിൽ അക്കാലത്ത് Gmail നിരീക്ഷണം ഘടനാപരമായിരുന്നു. ഈ സമീപനം അനുയോജ്യമല്ല, കാരണം ആ സമയത്തും Gmail ആയിരക്കണക്കിന് ജോലികൾ ചെയ്തു, അവയിൽ ഓരോന്നും ഞങ്ങളുടെ ഉപയോക്താക്കളിൽ ഒരു ശതമാനത്തിന് നൽകിയിട്ടുണ്ട്. Gmail ഉപയോക്താക്കൾക്ക് മികച്ച ഉപയോക്തൃ അനുഭവം നൽകുന്നതിൽ ഞങ്ങൾ വളരെയധികം ആശങ്കാകുലരായിരുന്നു, എന്നാൽ നിരവധി അലേർട്ടുകൾ കൈകാര്യം ചെയ്യുന്നത് കൈയ്യെത്താത്തതായിരുന്നു.

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

ഈ പിരിമുറുക്കം ടീമിൽ സാധാരണമായിരുന്നു, അത് പലപ്പോഴും സ്വയം അച്ചടക്കത്തിലുള്ള വിശ്വാസമില്ലായ്മയെ പ്രതിഫലിപ്പിക്കുന്നു: ചില ടീം അംഗങ്ങൾ ശരിയായ പരിഹാരത്തിനായി സമയം അനുവദിക്കണമെന്ന് ആഗ്രഹിക്കുന്നു, മറ്റുള്ളവർ അന്തിമ പരിഹാരം മറന്നുപോകുമെന്നും താൽക്കാലിക പരിഹാരം എന്നെന്നേക്കുമായി നടക്കുമെന്നും ആശങ്കപ്പെടുന്നു. ഈ പ്രശ്നം ശ്രദ്ധ അർഹിക്കുന്നു, കാരണം സാഹചര്യം ശാശ്വതമാക്കുന്നതിന് പകരം പ്രശ്നങ്ങൾ താൽക്കാലികമായി പരിഹരിക്കുന്നത് വളരെ എളുപ്പമാണ്. പ്രാരംഭ "വേദന" ശമിച്ച ശേഷവും ദീർഘകാല പരിഹാരങ്ങൾ നടപ്പിലാക്കുന്നതിലും ദീർഘകാല പരിഹാരങ്ങൾക്ക് പിന്തുണ നൽകുന്നതിലും മുൻഗണന നൽകുന്നതിലും മാനേജർമാരും സാങ്കേതിക ജീവനക്കാരും ഒരു പ്രധാന പങ്ക് വഹിക്കുന്നു.

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

ദീർഘകാലം

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

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

തീരുമാനം

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

ദീർഘകാലാടിസ്ഥാനത്തിൽ, രോഗലക്ഷണങ്ങളെയും ആസന്നമായ യഥാർത്ഥ പ്രശ്‌നങ്ങളെയും കുറിച്ചുള്ള അലേർട്ടുകളുടെ വിജയകരമായ ഭ്രമണം നേടേണ്ടത് ആവശ്യമാണ്, നിരീക്ഷണം ദ്രുതഗതിയിലുള്ള രോഗനിർണയത്തെ പിന്തുണയ്ക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നതിന് ലക്ഷ്യങ്ങൾ പൊരുത്തപ്പെടുത്തുക.

വിവർത്തനം അവസാനം വരെ വായിച്ചതിന് നന്ദി. നിരീക്ഷണത്തെക്കുറിച്ച് എന്റെ ടെലിഗ്രാം ചാനൽ സബ്സ്ക്രൈബ് ചെയ്യുക @monitorim_it и മീഡിയത്തിൽ ബ്ലോഗ്.

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