വിതരണം ചെയ്‌ത ട്രെയ്‌സിംഗ്: ഞങ്ങൾ എല്ലാം തെറ്റാണ് ചെയ്തത്

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

[ചിത്രം എടുത്തത് മറ്റ് മെറ്റീരിയൽ വിതരണം ചെയ്ത ട്രെയ്‌സിംഗിനെക്കുറിച്ച്.]

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

ഡിസ്ട്രിബ്യൂഡ് ട്രെയ്‌സിംഗിലെ പ്രധാന വെല്ലുവിളി ഡാറ്റ ശേഖരിക്കുകയോ ഫലങ്ങൾ വിതരണം ചെയ്യുന്നതിനും അവതരിപ്പിക്കുന്നതിനുമുള്ള ഫോർമാറ്റുകൾ സ്റ്റാൻഡേർഡ് ചെയ്യുകയോ എപ്പോൾ, എവിടെ, എങ്ങനെ സാമ്പിൾ ചെയ്യണമെന്ന് നിർണ്ണയിക്കുകയോ അല്ല. ഞാൻ സങ്കൽപ്പിക്കാൻ ശ്രമിക്കുന്നില്ല നിസ്സാരമായ ഈ "ഗ്രഹണശേഷി പ്രശ്നങ്ങൾ", വാസ്തവത്തിൽ, വളരെ പ്രധാനപ്പെട്ട സാങ്കേതികവും (ഞങ്ങൾ യഥാർത്ഥത്തിൽ ഓപ്പൺ സോഴ്‌സ് പരിഗണിക്കുകയാണെങ്കിൽ) മാനദണ്ഡങ്ങളും പ്രോട്ടോക്കോളുകളും) ഈ പ്രശ്‌നങ്ങൾ പരിഹരിക്കപ്പെടുന്നതിന് മറികടക്കേണ്ട രാഷ്ട്രീയ വെല്ലുവിളികൾ.

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

അത്തരമൊരു വ്യത്യസ്തമായ അടയാളം

ഡിസ്ട്രിബ്യൂട്ട് ട്രെയ്‌സിംഗിൽ നിരവധി വ്യത്യസ്ത ഘടകങ്ങൾ ഉൾപ്പെടുന്നു:

• നിയന്ത്രണ ഉപകരണങ്ങൾ ഉപയോഗിച്ച് ആപ്ലിക്കേഷനുകളും മിഡിൽവെയറുകളും സജ്ജമാക്കുക;
• വിതരണം ചെയ്ത സന്ദർഭ കൈമാറ്റം;
• അടയാളങ്ങളുടെ ശേഖരണം;
• ട്രേസ് സ്റ്റോറേജ്;
• അവയുടെ വേർതിരിച്ചെടുക്കലും ദൃശ്യവൽക്കരണവും.

ഡിസ്ട്രിബ്യൂട്ടഡ് ട്രെയ്‌സിംഗിനെക്കുറിച്ചുള്ള ധാരാളം സംസാരങ്ങൾ അതിനെ ഒരുതരം അനിയന്ത്രിത പ്രവർത്തനമായി കണക്കാക്കുന്നു, അതിന്റെ ഏക ഉദ്ദേശ്യം സിസ്റ്റത്തെ പൂർണ്ണമായി നിർണ്ണയിക്കാൻ സഹായിക്കുക എന്നതാണ്. ഡിസ്ട്രിബ്യൂട്ടഡ് ട്രെയ്‌സിംഗിനെക്കുറിച്ചുള്ള ആശയങ്ങൾ ചരിത്രപരമായി എങ്ങനെ രൂപപ്പെട്ടു എന്നതിനാലാണ് ഇത് പ്രധാനമായും കാരണം. IN ബ്ലോഗ് എൻട്രികൾ, സിപ്കിൻ സ്രോതസ്സുകൾ തുറന്നപ്പോൾ അത് സൂചിപ്പിച്ചിരുന്നു ഇത് [സിപ്കിൻ] ട്വിറ്ററിനെ വേഗത്തിലാക്കുന്നു. ട്രെയ്‌സിംഗിനായുള്ള ആദ്യ വാണിജ്യ ഓഫറുകളും പ്രമോട്ട് ചെയ്യപ്പെട്ടു എപിഎം ടൂളുകൾ.

കുറിപ്പ്. വിവർത്തനം.: കൂടുതൽ വാചകം മനസ്സിലാക്കാൻ എളുപ്പമാക്കുന്നതിന്, അനുസരിച്ച് രണ്ട് അടിസ്ഥാന പദങ്ങൾ നമുക്ക് നിർവചിക്കാം OpenTracing പ്രോജക്റ്റ് ഡോക്യുമെന്റേഷൻ:

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

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

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

മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന ഓപ്ഷനുകളൊന്നും സാഹചര്യത്തിന് പൂർണ്ണമായും ബാധകമല്ല ഡീബഗ് ചെയ്യുക, ഈ സമയത്ത് എഞ്ചിനീയർ ട്രെയ്സ് നോക്കി പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിക്കുന്നു.

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

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

പണ്ട് ഐ പരാതിപ്പെട്ടു UI/UX ട്രെയ്‌സിംഗിലെ മിക്ക "പുതുമകളും" പരിമിതപ്പെടുത്തിയിരിക്കുന്നതായി തോന്നുന്നു ഓൺചെയ്യുന്നു അധിക മെറ്റാഡാറ്റ, അവയിൽ ഉയർന്ന കാർഡിനാലിറ്റി ഉള്ള വിവരങ്ങൾ നിക്ഷേപിക്കുന്നു (ഉയർന്ന കാർഡിനാലിറ്റി) അല്ലെങ്കിൽ നിർദ്ദിഷ്ട സ്പാനുകളിലേക്ക് തുളച്ചുകയറാനോ അന്വേഷണങ്ങൾ പ്രവർത്തിപ്പിക്കാനോ ഉള്ള കഴിവ് നൽകുന്നു ഇന്റർ, ഇൻട്രാ ട്രേസ്... അതിൽ ട്രെയ്സ് വ്യൂ പ്രാഥമിക ദൃശ്യവൽക്കരണ ഉപകരണമായി തുടരുന്നു. ഈ അവസ്ഥ തുടരുന്നിടത്തോളം, മെട്രിക്‌സ്, ലോഗുകൾ, സ്റ്റാക്ക് ട്രെയ്‌സുകൾ എന്നിവയ്‌ക്ക് ശേഷം ഒരു ഡീബഗ്ഗിംഗ് ടൂൾ എന്ന നിലയിൽ വിതരണം ചെയ്‌ത ട്രെയ്‌സിംഗ് (മികച്ചത്) നാലാം സ്ഥാനത്തെത്തും, ഏറ്റവും മോശമായാൽ അത് പണവും സമയവും പാഴാക്കും.

ട്രെയ്‌സ്‌വ്യൂവിൽ പ്രശ്‌നം

ഉദ്ദേശ്യം ട്രെയ്സ് വ്യൂ - അതുമായി ബന്ധപ്പെട്ടിരിക്കുന്ന വിതരണം ചെയ്ത സിസ്റ്റത്തിന്റെ എല്ലാ ഘടകങ്ങളിലുടനീളമുള്ള ഒരൊറ്റ അഭ്യർത്ഥനയുടെ ചലനത്തിന്റെ പൂർണ്ണമായ ചിത്രം നൽകുക. കൂടുതൽ നൂതനമായ ട്രെയ്‌സിംഗ് സിസ്റ്റങ്ങൾ വ്യക്തിഗത സ്പാനുകളിലേക്ക് തുളച്ചുകയറാനും കാലക്രമേണ ഒരു തകർച്ച കാണാനും നിങ്ങളെ അനുവദിക്കുന്നു അകത്ത് ഒരു പ്രക്രിയ (സ്പാനുകൾക്ക് പ്രവർത്തനപരമായ അതിരുകൾ ഉള്ളപ്പോൾ).

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

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

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

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

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

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

സ്പാനുകൾ വളരെ താഴ്ന്ന നിലയിലാണ്

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

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

ട്രെയ്‌സ്‌വ്യൂവിനുള്ള ഇതരമാർഗങ്ങൾ

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

ഞാൻ ഒരു വിഷ്വൽ ഡിസൈനറോ UX സ്പെഷ്യലിസ്റ്റോ അല്ല, എന്നാൽ അടുത്ത വിഭാഗത്തിൽ ഈ വിഷ്വലൈസേഷനുകൾ എങ്ങനെയായിരിക്കാം എന്നതിനെക്കുറിച്ചുള്ള കുറച്ച് ആശയങ്ങൾ പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

നിർദ്ദിഷ്ട സേവനങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക

വ്യവസായം ആശയങ്ങൾക്ക് ചുറ്റും ഏകീകരിക്കുന്ന ഒരു സമയത്ത് SLO (സേവന തല ലക്ഷ്യങ്ങൾ), SLI (സർവീസ് ലെവൽ സൂചകങ്ങൾ), വ്യക്തിഗത ടീമുകൾ അവരുടെ സേവനങ്ങൾ ഈ ലക്ഷ്യങ്ങളുമായി യോജിപ്പിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുന്നതിന് മുൻഗണന നൽകേണ്ടത് ന്യായമാണെന്ന് തോന്നുന്നു. അത് പിന്തുടരുന്നു സേവന അധിഷ്ഠിത അത്തരം ടീമുകൾക്ക് ദൃശ്യവൽക്കരണം ഏറ്റവും അനുയോജ്യമാണ്.

ട്രെയ്‌സുകൾ, പ്രത്യേകിച്ച് സാമ്പിൾ ചെയ്യാതെ, ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിന്റെ ഓരോ ഘടകത്തെയും കുറിച്ചുള്ള വിവരങ്ങളുടെ ഒരു നിധിയാണ്. ഈ വിവരങ്ങൾ ഉപയോക്താക്കൾക്ക് വിതരണം ചെയ്യുന്ന ഒരു തന്ത്രശാലിയായ പ്രോസസ്സറിന് നൽകാം സേവന അധിഷ്ഠിത കണ്ടെത്തലുകൾ. അവ മുൻകൂട്ടി തിരിച്ചറിയാൻ കഴിയും - ഉപയോക്താവ് ട്രെയ്‌സുകൾ നോക്കുന്നതിന് മുമ്പുതന്നെ:

1. വളരെ പ്രധാനപ്പെട്ട അഭ്യർത്ഥനകൾക്ക് മാത്രം ലേറ്റൻസി ഡിസ്ട്രിബ്യൂഷൻ ഡയഗ്രമുകൾ (പുറമെയുള്ള അഭ്യർത്ഥനകൾ);
2. സേവന SLO ലക്ഷ്യങ്ങൾ കൈവരിക്കാത്ത കേസുകൾക്കുള്ള കാലതാമസം വിതരണത്തിന്റെ ഡയഗ്രമുകൾ;
3. ചോദ്യങ്ങളിലെ ഏറ്റവും "സാധാരണ", "രസകരമായ", "വിചിത്രമായ" ടാഗുകൾ ആവർത്തിക്കപ്പെടുന്നു;
4. കേസുകൾക്കുള്ള ലേറ്റൻസി ബ്രേക്ക്ഡൗൺ ഡിപൻഡൻസികൾ സേവനങ്ങൾ അവരുടെ SLO ലക്ഷ്യങ്ങൾ കൈവരിക്കുന്നില്ല;
5. വിവിധ ഡൗൺസ്ട്രീം സേവനങ്ങൾക്കുള്ള ലേറ്റൻസി ബ്രേക്ക്ഡൗൺ.

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

ഇത് ചോദ്യം ഉയർത്തുന്നു: വ്യത്യസ്ത ടീമുകൾ നിയന്ത്രിക്കുന്ന വൈവിധ്യമാർന്ന സേവനങ്ങൾ തമ്മിലുള്ള സങ്കീർണ്ണമായ ഇടപെടലുകളെക്കുറിച്ച്? അല്ലേ ട്രെയ്സ് വ്യൂ അത്തരമൊരു സാഹചര്യം ഉയർത്തിക്കാട്ടുന്നതിനുള്ള ഏറ്റവും ഉചിതമായ ഉപകരണമായി കണക്കാക്കുന്നില്ലേ?

മൊബൈൽ ഡെവലപ്പർമാർ, സ്‌റ്റേറ്റ്‌ലെസ് സേവനങ്ങളുടെ ഉടമകൾ, നിയന്ത്രിത സ്‌റ്റേറ്റ്‌ഫുൾ സേവനങ്ങളുടെ ഉടമകൾ (ഡാറ്റാബേസുകൾ പോലുള്ളവ) പ്ലാറ്റ്‌ഫോം ഉടമകൾ മറ്റെന്തെങ്കിലും താൽപ്പര്യമുള്ളവരായിരിക്കാം അവതരണം വിതരണം ചെയ്ത സംവിധാനം; ട്രെയ്സ് വ്യൂ അടിസ്ഥാനപരമായി വ്യത്യസ്തമായ ഈ ആവശ്യങ്ങൾക്ക് വളരെ സാധാരണമായ ഒരു പരിഹാരമാണ്. വളരെ സങ്കീർണ്ണമായ ഒരു മൈക്രോ സർവീസ് ആർക്കിടെക്ചറിൽ പോലും, സേവന ഉടമകൾക്ക് രണ്ടോ മൂന്നോ അപ്‌സ്ട്രീം, ഡൗൺസ്ട്രീം സേവനങ്ങളെക്കുറിച്ച് ആഴത്തിലുള്ള അറിവ് ആവശ്യമില്ല. അടിസ്ഥാനപരമായി, മിക്ക സാഹചര്യങ്ങളിലും, ഉപയോക്താക്കൾ ഇതുമായി ബന്ധപ്പെട്ട ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകേണ്ടതുണ്ട് പരിമിതമായ സേവനങ്ങൾ.

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

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

ഒരു ടോപ്പോളജി നിർമ്മിക്കുന്നു

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

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

നമുക്ക് ഒരു ഉദാഹരണം എടുക്കാം. നമുക്ക് ഒരു സാങ്കൽപ്പിക വാർത്താ സൈറ്റ് സങ്കൽപ്പിക്കാം. ഹോം പേജ് സേവനം (മുൻ പേജ്) റെഡിസുമായി, ഒരു ശുപാർശ സേവനത്തോടൊപ്പം, ഒരു പരസ്യ സേവനവും ഒരു വീഡിയോ സേവനവും ഉപയോഗിച്ച് ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നു. വീഡിയോ സേവനം S3-ൽ നിന്ന് വീഡിയോകളും DynamoDB-യിൽ നിന്ന് മെറ്റാഡാറ്റയും എടുക്കുന്നു. ശുപാർശ സേവനത്തിന് DynamoDB-ൽ നിന്ന് മെറ്റാഡാറ്റ ലഭിക്കുന്നു, Redis, MySQL എന്നിവയിൽ നിന്ന് ഡാറ്റ ലോഡ് ചെയ്യുന്നു, കാഫ്കയിലേക്ക് സന്ദേശങ്ങൾ എഴുതുന്നു. പരസ്യ സേവനം MySQL-ൽ നിന്ന് ഡാറ്റ സ്വീകരിക്കുകയും കാഫ്കയിലേക്ക് സന്ദേശങ്ങൾ എഴുതുകയും ചെയ്യുന്നു.

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

ഒരു സാങ്കൽപ്പിക വാർത്താ സൈറ്റിന്റെ സേവന ഡയഗ്രം

ചുവടെയുള്ള ഡയഗ്രം കൂടുതൽ അനുയോജ്യമാകും. സേവനത്തിൽ ഒരു പ്രശ്നമുണ്ട് (വീഡിയോ) മധ്യഭാഗത്ത് വലതുവശത്ത് ചിത്രീകരിച്ചിരിക്കുന്നു. ഉപയോക്താവ് അത് ഉടനടി ശ്രദ്ധിക്കുന്നു. ഈ ദൃശ്യവൽക്കരണത്തിൽ നിന്ന്, പ്രധാന പേജിന്റെ ഭാഗത്തിന്റെ ലോഡിംഗ് വേഗതയെ ബാധിക്കുന്ന S3 പ്രതികരണ സമയത്തിന്റെ വർദ്ധനവ് കാരണം വീഡിയോ സേവനം അസാധാരണമായി പ്രവർത്തിക്കുന്നുവെന്ന് വ്യക്തമാകും.

"രസകരമായ" സേവനങ്ങൾ മാത്രം പ്രദർശിപ്പിക്കുന്ന ഡൈനാമിക് ടോപ്പോളജി

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

താരതമ്യ പ്രദർശനം

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

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

തീരുമാനം

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

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

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

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

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «Kubernetes പോഡുകളിലെ ഡീബഗ്ഗിംഗിനുള്ള kubectl-debug പ്ലഗിൻ";
• «മൈക്രോസർവീസുകൾ: നിങ്ങൾക്ക് കുബർനെറ്റുകളുണ്ടെങ്കിൽപ്പോലും വലുപ്പം പ്രധാനമാണ്";
• «നിരീക്ഷണവും കുബർനെറ്റസും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)".

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