Prometheus, Clickhouse, ELK എന്നിവയിൽ ഞങ്ങൾ എങ്ങനെയാണ് നിരീക്ഷണം നടത്തിയത്

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

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

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

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

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

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

കൂടാതെ, അതിന്റെ കൂടുതൽ വികസനത്തിന്റെ നിരർത്ഥകതയെക്കുറിച്ച് വ്യക്തമായ ധാരണയുണ്ടായിരുന്നു. ഐസിംഗയെ പരിചയമുള്ളവർ എന്നെ മനസ്സിലാക്കുമെന്ന് കരുതുന്നു. അതിനാൽ, പ്രോജക്റ്റിനായി വെബ് ആപ്ലിക്കേഷൻ മോണിറ്ററിംഗ് സിസ്റ്റം പൂർണ്ണമായും പുനർരൂപകൽപ്പന ചെയ്യാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

പ്രോമിത്തിയസ്

മൂന്ന് പ്രധാന സൂചകങ്ങളെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ പ്രോമിത്യൂസിനെ തിരഞ്ഞെടുത്തു:

1. ലഭ്യമായ മെട്രിക്കുകളുടെ ഒരു വലിയ എണ്ണം. ഞങ്ങളുടെ കാര്യത്തിൽ, അവയിൽ 60 ആയിരം ഉണ്ട്. തീർച്ചയായും, അവയിൽ ഭൂരിഭാഗവും ഞങ്ങൾ ഉപയോഗിക്കുന്നില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ് (ഒരുപക്ഷേ ഏകദേശം 95%). മറുവശത്ത്, അവയെല്ലാം താരതമ്യേന വിലകുറഞ്ഞതാണ്. ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം, മുമ്പ് ഉപയോഗിച്ച ഐസിംഗയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇത് മറ്റൊരു തീവ്രമാണ്. അതിൽ, മെട്രിക്സ് ചേർക്കുന്നത് ഒരു പ്രത്യേക വേദനയായിരുന്നു: നിലവിലുള്ളവ ചെലവേറിയതാണ് (ഏതെങ്കിലും പ്ലഗിന്റെ സോഴ്സ് കോഡ് നോക്കുക). ഏതൊരു പ്ലഗിനും ബാഷിലോ പൈത്തണിലോ ഉള്ള ഒരു സ്ക്രിപ്റ്റായിരുന്നു, അതിന്റെ ലോഞ്ച് ഉപഭോഗം ചെയ്യുന്ന വിഭവങ്ങളുടെ കാര്യത്തിൽ ചെലവേറിയതാണ്.
2. ഈ സംവിധാനം താരതമ്യേന ചെറിയ അളവിലുള്ള വിഭവങ്ങൾ ഉപയോഗിക്കുന്നു. 600 MB റാം, ഒരു കോറിന്റെ 15%, രണ്ട് ഡസൻ IOPS എന്നിവ ഞങ്ങളുടെ എല്ലാ മെട്രിക്കുകൾക്കും മതിയാകും. തീർച്ചയായും, നിങ്ങൾ മെട്രിക്സ് കയറ്റുമതിക്കാരെ പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്, എന്നാൽ അവയെല്ലാം Go- ൽ എഴുതിയിരിക്കുന്നു, മാത്രമല്ല അവയ്ക്ക് ശക്തിയൊന്നും ആവശ്യമില്ല. ആധുനിക യാഥാർത്ഥ്യങ്ങളിൽ ഇത് ഒരു പ്രശ്നമാണെന്ന് ഞാൻ കരുതുന്നില്ല.
3. കുബർനെറ്റസിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യാനുള്ള കഴിവ് നൽകുന്നു. ഉപഭോക്താവിന്റെ പദ്ധതികൾ കണക്കിലെടുക്കുമ്പോൾ, തിരഞ്ഞെടുപ്പ് വ്യക്തമാണ്.

ELK

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

ക്ലിക്ഹൗസ്

തുടക്കത്തിൽ, തിരഞ്ഞെടുപ്പ് InfluxDB-യിൽ വീണു. Nginx ലോഗുകളും pg_stat_statements-ൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകളും ശേഖരിക്കേണ്ടതിന്റെ ആവശ്യകത ഞങ്ങൾ മനസ്സിലാക്കി, Prometheus ചരിത്രപരമായ ഡാറ്റ സംഭരിക്കുക. ഞങ്ങൾക്ക് ഇൻഫ്‌ളക്‌സ് ഇഷ്ടപ്പെട്ടില്ല, കാരണം അത് ഇടയ്‌ക്കിടെ വലിയ അളവിൽ മെമ്മറി ഉപയോഗിക്കാനും ക്രാഷ് ആകാനും തുടങ്ങി. കൂടാതെ, remote_addr വഴി ചോദ്യങ്ങൾ ഗ്രൂപ്പുചെയ്യാൻ ഞാൻ ആഗ്രഹിച്ചു, എന്നാൽ ഈ DBMS-ൽ ഗ്രൂപ്പുചെയ്യുന്നത് ടാഗുകൾ വഴി മാത്രമാണ്. ടാഗുകൾ ചെലവേറിയതാണ് (മെമ്മറി), അവയുടെ എണ്ണം സോപാധികമായി പരിമിതമാണ്.

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

ക്ലിക്ക്ഹൗസ് ഈ എല്ലാ മാനദണ്ഡങ്ങളും പാലിക്കുന്നു, ഞങ്ങളുടെ തിരഞ്ഞെടുപ്പിൽ ഞങ്ങൾ ഒരിക്കലും ഖേദിച്ചിട്ടില്ല. ഞങ്ങൾ അതിൽ അസാധാരണമായ അളവിലുള്ള ഡാറ്റ എഴുതുന്നില്ല (ഇൻസേർഷനുകളുടെ എണ്ണം മിനിറ്റിൽ അയ്യായിരം മാത്രമാണ്).

ന്യൂറെലിക്

NewRelic ചരിത്രപരമായി ഞങ്ങളോടൊപ്പമുണ്ട്, കാരണം അത് ഉപഭോക്താവിന്റെ തിരഞ്ഞെടുപ്പായിരുന്നു. ഞങ്ങൾ ഇത് ഒരു APM ആയി ഉപയോഗിക്കുന്നു.

സബ്ബിക്സ്

വിവിധ API-കളുടെ ബ്ലാക്ക് ബോക്‌സ് നിരീക്ഷിക്കാൻ ഞങ്ങൾ Zabbix മാത്രം ഉപയോഗിക്കുന്നു.

ഒരു മോണിറ്ററിംഗ് സമീപനം നിർവചിക്കുന്നു

ചുമതല വിഘടിപ്പിക്കാനും അതുവഴി നിരീക്ഷണത്തിനുള്ള സമീപനം ചിട്ടപ്പെടുത്താനും ഞങ്ങൾ ആഗ്രഹിച്ചു.

ഇത് ചെയ്യുന്നതിന്, ഞാൻ ഞങ്ങളുടെ സിസ്റ്റത്തെ ഇനിപ്പറയുന്ന ലെവലുകളായി വിഭജിച്ചു:

• ഹാർഡ്‌വെയറും വിഎംഎസും;
• ഓപ്പറേറ്റിംഗ് സിസ്റ്റം;
• സിസ്റ്റം സേവനങ്ങൾ, സോഫ്റ്റ്വെയർ സ്റ്റാക്ക്;
• അപേക്ഷ;
• ബിസിനസ്സ് യുക്തി.

എന്തുകൊണ്ട് ഈ സമീപനം സൗകര്യപ്രദമാണ്:

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

സിസ്റ്റത്തിന്റെ പ്രവർത്തനത്തിലെ ലംഘനങ്ങൾ തിരിച്ചറിയുക എന്നതാണ് ഞങ്ങളുടെ ചുമതല എന്നതിനാൽ, അലേർട്ടിംഗ് നിയമങ്ങൾ എഴുതുമ്പോൾ ശ്രദ്ധിക്കേണ്ട ഒരു നിശ്ചിത അളവുകോലുകൾ ഞങ്ങൾ ഓരോ തലത്തിലും ഹൈലൈറ്റ് ചെയ്യണം. അടുത്തതായി, നമുക്ക് "VMS", "ഓപ്പറേറ്റിംഗ് സിസ്റ്റം", "സിസ്റ്റം സേവനങ്ങൾ, സോഫ്റ്റ്വെയർ സ്റ്റാക്ക്" എന്നീ തലങ്ങളിലൂടെ പോകാം.

വെർച്വൽ മെഷീനുകൾ

ഹോസ്റ്റിംഗ് ഞങ്ങൾക്ക് പ്രോസസർ, ഡിസ്ക്, മെമ്മറി, നെറ്റ്‌വർക്ക് എന്നിവ അനുവദിക്കുന്നു. ആദ്യത്തെ രണ്ടെണ്ണത്തിൽ ഞങ്ങൾക്ക് പ്രശ്‌നങ്ങളുണ്ടായിരുന്നു. അതിനാൽ, അളവുകൾ:

CPU മോഷ്ടിച്ച സമയം - നിങ്ങൾ ആമസോണിൽ ഒരു വെർച്വൽ മെഷീൻ വാങ്ങുമ്പോൾ (ഉദാഹരണത്തിന്, t2.micro), നിങ്ങൾക്ക് ഒരു മുഴുവൻ പ്രോസസർ കോർ അനുവദിച്ചിട്ടില്ല, മറിച്ച് അതിന്റെ സമയത്തിന്റെ ഒരു ക്വാട്ട മാത്രമാണെന്ന് നിങ്ങൾ മനസ്സിലാക്കണം. നിങ്ങൾ അത് തീരുമ്പോൾ, പ്രോസസർ നിങ്ങളിൽ നിന്ന് എടുത്തുകളയും.

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

IOPS + CPU iowait സമയം - ചില കാരണങ്ങളാൽ, മതിയായ IOPS നൽകാത്തതിനാൽ പല ക്ലൗഡ് ഹോസ്റ്റിംഗുകളും പാപം ചെയ്യുന്നു. മാത്രമല്ല, കുറഞ്ഞ IOPS ഉള്ള ഒരു ഷെഡ്യൂൾ അവർക്ക് ഒരു വാദമല്ല. അതിനാൽ, CPU iowait ശേഖരിക്കുന്നത് മൂല്യവത്താണ്. ഈ ജോടി ഗ്രാഫുകൾ ഉപയോഗിച്ച് - കുറഞ്ഞ IOPS ഉം ഉയർന്ന I/O കാത്തിരിപ്പും ഉപയോഗിച്ച് - നിങ്ങൾക്ക് ഇതിനകം തന്നെ ഹോസ്റ്റിംഗുമായി സംസാരിച്ച് പ്രശ്നം പരിഹരിക്കാനാകും.

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം മെട്രിക്കുകൾ:

• % ൽ ലഭ്യമായ മെമ്മറിയുടെ അളവ്;
• സ്വാപ്പ് ഉപയോഗ പ്രവർത്തനം: vmstat swapin, swapout;
• ലഭ്യമായ ഐനോഡുകളുടെ എണ്ണവും ഫയൽ സിസ്റ്റത്തിൽ %-ൽ ശൂന്യമായ ഇടവും
• ശരാശരി ലോഡ്;
• രണ്ട് സംസ്ഥാനത്തെ കണക്ഷനുകളുടെ എണ്ണം;
• കോൺട്രാക്ക് ടേബിൾ പൂർണ്ണത;
• ss യൂട്ടിലിറ്റി, iproute2 പാക്കേജ് ഉപയോഗിച്ച് നെറ്റ്‌വർക്കിന്റെ ഗുണനിലവാരം നിരീക്ഷിക്കാൻ കഴിയും - അതിന്റെ ഔട്ട്‌പുട്ടിൽ നിന്ന് RTT കണക്ഷനുകളുടെ ഒരു സൂചകം നേടുകയും ഡെസ്റ്റ് പോർട്ട് വഴി ഗ്രൂപ്പുചെയ്യുകയും ചെയ്യുക.

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

മെട്രിക്സിന്റെ സെറ്റ് ഇപ്രകാരമാണ്:

• സിപിയു;
• മെമ്മറി പ്രാഥമികമായി റസിഡന്റ് ആണ്;
• IO - വെയിലത്ത് IOPS ൽ;
• FileFd - തുറന്ന് പരിധി;
• കാര്യമായ പേജ് പരാജയങ്ങൾ - ഇതുവഴി ഏത് പ്രക്രിയയാണ് സ്വാപ്പ് ചെയ്യുന്നതെന്ന് നിങ്ങൾക്ക് മനസ്സിലാക്കാൻ കഴിയും.

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

സിസ്റ്റം സേവനങ്ങൾ, സോഫ്റ്റ്വെയർ സ്റ്റാക്ക്

ഓരോ ആപ്ലിക്കേഷനും അതിന്റേതായ പ്രത്യേകതകൾ ഉണ്ട്, കൂടാതെ ഒരു പ്രത്യേക സെറ്റ് മെട്രിക്കുകൾ ഒറ്റപ്പെടുത്തുന്നത് ബുദ്ധിമുട്ടാണ്.

സാർവത്രിക സെറ്റ് ഇതാണ്:

• അഭ്യർത്ഥന നിരക്ക്;
• തെറ്റുകളുടെ എണ്ണം;
• ലേറ്റൻസി;
• സാച്ചുറേഷൻ.

ഈ തലത്തിലുള്ള നിരീക്ഷണത്തിന്റെ ഏറ്റവും ശ്രദ്ധേയമായ ഉദാഹരണങ്ങൾ Nginx, PostgreSQL എന്നിവയാണ്.

ഞങ്ങളുടെ സിസ്റ്റത്തിൽ ഏറ്റവും കൂടുതൽ ലോഡ് ചെയ്ത സേവനം ഡാറ്റാബേസ് ആണ്. മുൻകാലങ്ങളിൽ, ഡാറ്റാബേസ് എന്താണ് ചെയ്യുന്നതെന്ന് കണ്ടെത്തുന്നതിൽ ഞങ്ങൾക്ക് പലപ്പോഴും പ്രശ്‌നമുണ്ടായിരുന്നു.

ഡിസ്കുകളിൽ ഉയർന്ന ലോഡ് ഞങ്ങൾ കണ്ടു, പക്ഷേ സ്ലോ ലോഗുകൾ ശരിക്കും ഒന്നും കാണിച്ചില്ല. അന്വേഷണ സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുന്ന ഒരു കാഴ്ച pg_stat_statements ഉപയോഗിച്ച് ഞങ്ങൾ ഈ പ്രശ്നം പരിഹരിച്ചു.

അഡ്മിന് വേണ്ടത് ഇത്രമാത്രം.

അഭ്യർത്ഥനകൾ വായിക്കാനും എഴുതാനുമുള്ള പ്രവർത്തനത്തിന്റെ ഗ്രാഫുകൾ ഞങ്ങൾ നിർമ്മിക്കുന്നു:

എല്ലാം ലളിതവും വ്യക്തവുമാണ്, ഓരോ അഭ്യർത്ഥനയ്ക്കും അതിന്റേതായ നിറമുണ്ട്.

സമാനമായ ശ്രദ്ധേയമായ ഉദാഹരണം Nginx ലോഗുകളാണ്. ചുരുക്കം ചിലർ അവ പാഴ്‌സ് ചെയ്യുന്നതിനോ നിർബന്ധമായും ഉണ്ടായിരിക്കേണ്ടവയുടെ പട്ടികയിൽ പരാമർശിക്കുന്നതിനോ അതിശയിക്കാനില്ല. സ്റ്റാൻഡേർഡ് ഫോർമാറ്റ് വളരെ വിവരദായകമല്ല, അത് വിപുലീകരിക്കേണ്ടതുണ്ട്.

വ്യക്തിപരമായി, ഞാൻ request_time, upstream_response_time, body_bytes_sent, request_length, request_id എന്നിവ ചേർത്തു. പ്രതികരണ സമയവും പിശകുകളുടെ എണ്ണവും ഞങ്ങൾ പ്ലോട്ട് ചെയ്യുന്നു:

പ്രതികരണ സമയത്തിന്റെയും പിശകുകളുടെ എണ്ണത്തിന്റെയും ഗ്രാഫുകൾ ഞങ്ങൾ നിർമ്മിക്കുന്നു. ഓർക്കുന്നുണ്ടോ? ഞാൻ ബിസിനസ്സ് ജോലികളെ കുറിച്ച് സംസാരിച്ചോ? വേഗത്തിലും പിശകുകളില്ലാതെയും? രണ്ട് ചാർട്ടുകൾ ഉപയോഗിച്ച് ഈ പ്രശ്നങ്ങൾ ഞങ്ങൾ ഇതിനകം ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. അവ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇതിനകം തന്നെ ഡ്യൂട്ടിയിലുള്ള അഡ്മിനിസ്ട്രേറ്റർമാരെ വിളിക്കാം.

എന്നാൽ ഒരു പ്രശ്നം കൂടി അവശേഷിക്കുന്നു - സംഭവത്തിന്റെ കാരണങ്ങൾ വേഗത്തിൽ ഇല്ലാതാക്കുന്നത് ഉറപ്പാക്കാൻ.

സംഭവ പരിഹാരം

ഒരു പ്രശ്നം തിരിച്ചറിയുന്നത് മുതൽ പരിഹരിക്കുന്നത് വരെയുള്ള മുഴുവൻ പ്രക്രിയയും നിരവധി ഘട്ടങ്ങളായി തിരിക്കാം:

• പ്രശ്നം തിരിച്ചറിയൽ;
• ഡ്യൂട്ടി അഡ്മിനിസ്ട്രേറ്റർക്ക് അറിയിപ്പ്;
• ഒരു സംഭവത്തോടുള്ള പ്രതികരണം;
• കാരണങ്ങൾ ഇല്ലാതാക്കൽ.

കഴിയുന്നത്ര വേഗത്തിൽ ഇത് ചെയ്യേണ്ടത് പ്രധാനമാണ്. ഒരു പ്രശ്നം തിരിച്ചറിയുകയും ഒരു അറിയിപ്പ് അയയ്ക്കുകയും ചെയ്യുന്ന ഘട്ടങ്ങളിൽ ഞങ്ങൾക്ക് കൂടുതൽ സമയം നേടാൻ കഴിയുന്നില്ലെങ്കിൽ - ഏത് സാഹചര്യത്തിലും രണ്ട് മിനിറ്റ് അവയ്ക്കായി ചെലവഴിക്കും, തുടർന്നുള്ളവ മെച്ചപ്പെടുത്തലുകൾക്കായി ഉഴുതുമറിച്ച വയലാണ്.

ഡ്യൂട്ടി ഓഫീസറുടെ ഫോൺ റിംഗ് ചെയ്തു എന്ന് സങ്കൽപ്പിക്കുക. അവൻ എന്ത് ചെയ്യും? ചോദ്യങ്ങൾക്കുള്ള ഉത്തരങ്ങൾക്കായി തിരയുക - എന്താണ് തകർന്നത്, എവിടെയാണ് തകർന്നത്, എങ്ങനെ പ്രതികരിക്കണം? ഈ ചോദ്യങ്ങൾക്ക് ഞങ്ങൾ എങ്ങനെ ഉത്തരം നൽകുന്നു:

വിജ്ഞാപനത്തിന്റെ വാചകത്തിൽ ഈ വിവരങ്ങളെല്ലാം ഞങ്ങൾ ഉൾപ്പെടുത്തി, ഈ പ്രശ്‌നത്തോട് എങ്ങനെ പ്രതികരിക്കാമെന്നും അത് എങ്ങനെ പരിഹരിക്കാമെന്നും അത് എങ്ങനെ വർദ്ധിപ്പിക്കാമെന്നും വിവരിക്കുന്ന ഒരു വിക്കി പേജിലേക്ക് ഒരു ലിങ്ക് നൽകുക.

ആപ്ലിക്കേഷൻ ലെയറിനെയും ബിസിനസ് ലോജിക്കിനെയും കുറിച്ച് ഞാൻ ഇതുവരെ ഒന്നും പറഞ്ഞിട്ടില്ല. നിർഭാഗ്യവശാൽ, ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ ഇതുവരെ മെട്രിക്സ് ശേഖരണം നടപ്പിലാക്കിയിട്ടില്ല. ഈ തലങ്ങളിൽ നിന്നുള്ള ഏതെങ്കിലും വിവരങ്ങളുടെ ഏക ഉറവിടം ലോഗുകൾ മാത്രമാണ്.

കുറച്ച് പോയിന്റുകൾ.

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

രണ്ടാമതായി, തീവ്രത ലെവലുകൾ ശരിയായി ഉപയോഗിക്കുക. ഓരോ ഭാഷയ്ക്കും അതിന്റേതായ നിലവാരമുണ്ട്. വ്യക്തിപരമായി, ഞാൻ നാല് തലങ്ങളെ വേർതിരിക്കുന്നു:

1. തെറ്റില്ല;
2. ക്ലയന്റ് സൈഡ് പിശക്;
3. തെറ്റ് ഞങ്ങളുടെ ഭാഗത്താണ്, ഞങ്ങൾക്ക് പണം നഷ്ടപ്പെടുന്നില്ല, ഞങ്ങൾ അപകടസാധ്യതകൾ വഹിക്കുന്നില്ല;
4. തെറ്റ് നമ്മുടെ ഭാഗത്താണ്, നമുക്ക് പണം നഷ്ടപ്പെടും.

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

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

നിങ്ങൾക്ക് ഇത് ഇല്ലെങ്കിൽ, ഞങ്ങൾ ചെയ്തതുപോലെ ആപ്ലിക്കേഷൻ ലോഗുകൾ, Nginx ലോഗുകൾ മുതലായവയിൽ നിങ്ങൾക്ക് ഇത് കണ്ടെത്താൻ ശ്രമിക്കാം. നിങ്ങൾ ആപ്ലിക്കേഷനുമായി കഴിയുന്നത്ര അടുത്തായിരിക്കണം.

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം മെട്രിക്‌സ് തീർച്ചയായും പ്രധാനമാണ്, എന്നാൽ ബിസിനസ്സിന് അവയിൽ താൽപ്പര്യമില്ല, ഞങ്ങൾക്ക് അവയ്‌ക്ക് പണം നൽകുന്നില്ല.

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