ഇന്ന് കുബർനെറ്റസിലെ ലോഗുകൾ (മാത്രമല്ല): പ്രതീക്ഷകളും യാഥാർത്ഥ്യവും

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

എന്നിരുന്നാലും, ആദ്യം, ലോഗുകൾ ശേഖരിക്കുന്നതിലൂടെ വ്യത്യസ്ത ഉപഭോക്താക്കൾ വളരെ വ്യത്യസ്തമായ കാര്യങ്ങൾ മനസ്സിലാക്കുന്ന ഒരു റിസർവേഷൻ ഞാൻ നടത്തും:

• ആരെങ്കിലും സുരക്ഷയും ഓഡിറ്റ് ലോഗുകളും കാണാൻ ആഗ്രഹിക്കുന്നു;
• ആരെങ്കിലും - മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറിന്റെയും കേന്ദ്രീകൃത ലോഗിംഗ്;
• ചിലർക്ക്, ബാലൻസറുകൾ ഒഴികെ, ആപ്ലിക്കേഷൻ ലോഗുകൾ മാത്രം ശേഖരിച്ചാൽ മതിയാകും.

വിവിധ "വിഷ് ലിസ്റ്റുകൾ" ഞങ്ങൾ എങ്ങനെ നടപ്പിലാക്കി, എന്തൊക്കെ ബുദ്ധിമുട്ടുകൾ നേരിട്ടു എന്നതിനെ കുറിച്ചുള്ള കട്ട് ചുവടെയുണ്ട്.

സിദ്ധാന്തം: ലോഗിംഗ് ടൂളുകളെ കുറിച്ച്

ഒരു ലോഗിംഗ് സിസ്റ്റത്തിന്റെ ഘടകങ്ങളെക്കുറിച്ചുള്ള പശ്ചാത്തലം

ലോഗിംഗ് ഒരുപാട് മുന്നോട്ട് പോയി, അതിന്റെ ഫലമായി ലോഗുകൾ ശേഖരിക്കുന്നതിനും വിശകലനം ചെയ്യുന്നതിനുമുള്ള രീതികൾ വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്, അതാണ് നമ്മൾ ഇന്ന് ഉപയോഗിക്കുന്നത്. 1950-കളിൽ, ഫോർട്രാൻ സ്റ്റാൻഡേർഡ് ഇൻപുട്ട്/ഔട്ട്പുട്ട് സ്ട്രീമുകളുടെ ഒരു അനലോഗ് അവതരിപ്പിച്ചു, ഇത് പ്രോഗ്രാമറെ തന്റെ പ്രോഗ്രാം ഡീബഗ് ചെയ്യാൻ സഹായിച്ചു. അക്കാലത്തെ പ്രോഗ്രാമർമാർക്ക് ജീവിതം എളുപ്പമാക്കിയ ആദ്യത്തെ കമ്പ്യൂട്ടർ ലോഗുകൾ ഇവയായിരുന്നു. ലോഗിംഗ് സിസ്റ്റത്തിന്റെ ആദ്യ ഘടകം ഇന്ന് നമ്മൾ അവയിൽ കാണുന്നു - ലോഗുകളുടെ ഉറവിടം അല്ലെങ്കിൽ "നിർമ്മാതാവ്".

കമ്പ്യൂട്ടർ സയൻസ് നിശ്ചലമായി നിന്നില്ല: കമ്പ്യൂട്ടർ ശൃംഖലകൾ പ്രത്യക്ഷപ്പെട്ടു, ആദ്യ ക്ലസ്റ്ററുകൾ ... നിരവധി കമ്പ്യൂട്ടറുകൾ അടങ്ങിയ സങ്കീർണ്ണ സംവിധാനങ്ങൾ പ്രവർത്തിക്കാൻ തുടങ്ങി. ഇപ്പോൾ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ നിരവധി മെഷീനുകളിൽ നിന്ന് ലോഗുകൾ ശേഖരിക്കാൻ നിർബന്ധിതരായി, കൂടാതെ പ്രത്യേക സന്ദർഭങ്ങളിൽ ഒരു സിസ്റ്റം പരാജയത്തെക്കുറിച്ച് അന്വേഷിക്കേണ്ട സാഹചര്യത്തിൽ അവർക്ക് OS കേർണൽ സന്ദേശങ്ങൾ ചേർക്കാൻ കഴിയും. കേന്ദ്രീകൃത ലോഗ് ശേഖരണ സംവിധാനങ്ങളെ വിവരിക്കുന്നതിന്, 2000-കളുടെ തുടക്കത്തിൽ ഇത് പ്രസിദ്ധീകരിച്ചു RFC 3164, ഏത് remote_syslog സ്റ്റാൻഡേർഡ് ചെയ്തു. മറ്റൊരു പ്രധാന ഘടകം പ്രത്യക്ഷപ്പെട്ടത് ഇങ്ങനെയാണ്: ലോഗ് കളക്ടർ അവയുടെ സംഭരണവും.

ലോഗുകളുടെ വോളിയം വർദ്ധിക്കുകയും വെബ് സാങ്കേതികവിദ്യകൾ വ്യാപകമായി അവതരിപ്പിക്കുകയും ചെയ്തതോടെ, ഉപയോക്താക്കൾക്ക് ഏത് ലോഗുകളാണ് സൗകര്യപ്രദമായി കാണിക്കേണ്ടത് എന്ന ചോദ്യം ഉയർന്നു. ലളിതമായ കൺസോൾ ടൂളുകൾ (awk/sed/grep) കൂടുതൽ വിപുലമായവ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചു ലോഗ് വ്യൂവർ - മൂന്നാമത്തെ ഘടകം.

ലോഗുകളുടെ അളവിലെ വർദ്ധനവ് കാരണം, മറ്റെന്തെങ്കിലും വ്യക്തമായി: ലോഗുകൾ ആവശ്യമാണ്, പക്ഷേ അവയെല്ലാം അല്ല. വ്യത്യസ്ത ലോഗുകൾക്ക് വ്യത്യസ്ത തലത്തിലുള്ള സംരക്ഷണം ആവശ്യമാണ്: ചിലത് ഒരു ദിവസത്തിൽ നഷ്ടപ്പെടും, മറ്റുള്ളവ 5 വർഷത്തേക്ക് സൂക്ഷിക്കേണ്ടതുണ്ട്. അതിനാൽ, ഡാറ്റാ ഫ്ലോകൾ ഫിൽട്ടർ ചെയ്യുന്നതിനും റൂട്ടിംഗ് ചെയ്യുന്നതിനുമുള്ള ഒരു ഘടകം ലോഗിംഗ് സിസ്റ്റത്തിലേക്ക് ചേർത്തു - നമുക്ക് അതിനെ വിളിക്കാം ഫിൽട്ടർ.

സംഭരണവും ഒരു വലിയ കുതിച്ചുചാട്ടം നടത്തി: സാധാരണ ഫയലുകളിൽ നിന്ന് റിലേഷണൽ ഡാറ്റാബേസുകളിലേക്കും തുടർന്ന് ഡോക്യുമെന്റ്-ഓറിയന്റഡ് സ്റ്റോറേജിലേക്കും (ഉദാഹരണത്തിന്, ഇലാസ്റ്റിക് സെർച്ച്). അതിനാൽ സംഭരണം കളക്ടറിൽ നിന്ന് വേർപെടുത്തി.

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

തൽഫലമായി, താരതമ്യേന ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ, ലോഗ് ശേഖരണം ഒരു പ്രധാന ഉപസിസ്റ്റമായി വികസിച്ചു, അതിനെ ബിഗ് ഡാറ്റയിലെ ഉപവിഭാഗങ്ങളിലൊന്ന് എന്ന് വിളിക്കാം.

ഒരു കാലത്ത് ഒരു "ലോഗിംഗ് സിസ്റ്റത്തിന്" സാധാരണ പ്രിന്റുകൾ മതിയാകും എങ്കിൽ, ഇപ്പോൾ സ്ഥിതി വളരെ മാറിയിരിക്കുന്നു.

കുബർനെറ്റുകളും ലോഗുകളും

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

മുന്നോട്ട് നോക്കുമ്പോൾ, നിർഭാഗ്യവശാൽ, മറ്റെല്ലാവരുമായും അനുകൂലമായി താരതമ്യപ്പെടുത്തുന്ന ഒരു സ്റ്റാൻഡേർഡ് ലോഗിംഗ് ഓപ്ഷനും കുബർനെറ്റസിനായി ഇല്ലെന്ന് എനിക്ക് പറയാൻ കഴിയും. കമ്മ്യൂണിറ്റിയിലെ ഏറ്റവും ജനപ്രിയമായ സ്കീമുകൾ ഇനിപ്പറയുന്നവയാണ്:

• ആരോ സ്റ്റാക്ക് അഴിക്കുന്നു EFK (Elasticsearch, Fluentd, Kibana);
• അടുത്തിടെ പുറത്തിറങ്ങിയത് ആരോ ശ്രമിക്കുന്നു ലോയി അല്ലെങ്കിൽ ഉപയോഗിക്കുന്നു ലോഗിംഗ് ഓപ്പറേറ്റർ;
• нас (ഒരുപക്ഷേ നമ്മൾ മാത്രമല്ല?..) എന്റെ സ്വന്തം വികസനത്തിൽ ഞാൻ ഏറെക്കുറെ സംതൃപ്തനാണ് - ലോഗ് ഹൗസ്പങ്ക് € |

ചട്ടം പോലെ, ഞങ്ങൾ K8s ക്ലസ്റ്ററുകളിൽ ഇനിപ്പറയുന്ന ബണ്ടിലുകൾ ഉപയോഗിക്കുന്നു (സ്വയം-ഹോസ്‌റ്റ് ചെയ്‌ത പരിഹാരങ്ങൾക്കായി):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + loghouse.

എന്നിരുന്നാലും, അവയുടെ ഇൻസ്റ്റാളേഷനും കോൺഫിഗറേഷനുമുള്ള നിർദ്ദേശങ്ങളിൽ ഞാൻ താമസിക്കില്ല. പകരം, ഞാൻ അവരുടെ പോരായ്മകളിലും പൊതുവെ ലോഗുകളുള്ള സാഹചര്യത്തെക്കുറിച്ചുള്ള കൂടുതൽ ആഗോള നിഗമനങ്ങളിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കും.

K8s-ൽ ലോഗുകൾ ഉപയോഗിച്ച് പരിശീലിക്കുക

"ദൈനംദിന രേഖകൾ", നിങ്ങളിൽ എത്രപേർ ഉണ്ട്?..

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

നമുക്ക് ClickHouse പരീക്ഷിക്കാം

ലോഗുകൾ വളരെ സജീവമായി സൃഷ്ടിക്കുന്ന ഒരു ആപ്ലിക്കേഷനുള്ള ഒരു പ്രോജക്റ്റിലെ ഒരു കേന്ദ്രീകൃത സംഭരണം നോക്കാം: സെക്കൻഡിൽ 5000-ലധികം ലൈനുകൾ. അവന്റെ ലോഗുകൾ ക്ലിക്ക്ഹൗസിലേക്ക് ചേർത്തുകൊണ്ട് നമുക്ക് പ്രവർത്തിക്കാൻ തുടങ്ങാം.

പരമാവധി തത്സമയം ആവശ്യമുള്ള ഉടൻ, ക്ലിക്ക്ഹൗസ് ഉള്ള 4-കോർ സെർവർ ഇതിനകം തന്നെ ഡിസ്ക് സബ്സിസ്റ്റത്തിൽ ഓവർലോഡ് ചെയ്യപ്പെടും:

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

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

ഈ സ്വഭാവം ഒഴിവാക്കാൻ, ClickHouse-ലേക്ക് എഴുതണം കഴിയുന്നത്ര വലിയ കഷണങ്ങളായി, ഓരോ 1 സെക്കൻഡിലും 2 തവണയിൽ കൂടരുത്. എന്നിരുന്നാലും, വലിയ പൊട്ടിത്തെറികളിൽ എഴുതുന്നത് ക്ലിക്ക്ഹൗസിൽ കുറച്ച് ഇടയ്ക്കിടെ എഴുതണമെന്ന് നിർദ്ദേശിക്കുന്നു. ഇത്, ഒരു ബഫർ ഓവർഫ്ലോയ്ക്കും ലോഗുകളുടെ നഷ്ടത്തിനും ഇടയാക്കും. Fluentd ബഫർ വർദ്ധിപ്പിക്കുക എന്നതാണ് പരിഹാരം, എന്നാൽ മെമ്മറി ഉപഭോഗവും വർദ്ധിക്കും.

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

തൽഫലമായി, ക്ലിക്ക്ഹൗസിൽ തത്സമയം ലോഗുകൾ ശേഖരിക്കാൻ എല്ലാ പ്രോജക്റ്റിനും മതിയായ ഉറവിടങ്ങൾ ഇല്ലെന്ന് വ്യക്തമാകും (കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, അവയുടെ വിതരണം ഉചിതമായിരിക്കില്ല). കൂടാതെ, നിങ്ങൾ ഉപയോഗിക്കേണ്ടതുണ്ട് аккумулятор, അതിലേക്ക് ഞങ്ങൾ പിന്നീട് മടങ്ങും. മുകളിൽ വിവരിച്ച കേസ് യഥാർത്ഥമാണ്. ആ സമയത്ത്, ഉപഭോക്താവിന് അനുയോജ്യമായതും കുറഞ്ഞ കാലതാമസത്തോടെ ലോഗുകൾ ശേഖരിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നതുമായ വിശ്വസനീയവും സുസ്ഥിരവുമായ ഒരു പരിഹാരം നൽകാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല...

ഇലാസ്റ്റിക് സെർച്ചിനെക്കുറിച്ച്?

ഇലാസ്റ്റിക് സെർച്ച് കനത്ത ജോലിഭാരം കൈകാര്യം ചെയ്യുമെന്ന് അറിയപ്പെടുന്നു. അതേ പ്രൊജക്റ്റിൽ തന്നെ ശ്രമിക്കാം. ഇപ്പോൾ ലോഡ് ഇതുപോലെ കാണപ്പെടുന്നു:

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

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

അപ്പോൾ സ്വാഭാവികമായ ഒരു ചോദ്യം ഉയർന്നുവരുന്നു:

യഥാർത്ഥത്തിൽ എന്ത് ലോഗുകൾ ആവശ്യമാണ്?

സമീപനം തന്നെ മാറ്റാൻ ശ്രമിക്കാം: ലോഗുകൾ ഒരേസമയം വിവരദായകമായിരിക്കണം കൂടാതെ കവർ ചെയ്യരുത് എല്ലാം സിസ്റ്റത്തിലെ സംഭവം.

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

അതിനാൽ ഞങ്ങൾ ആ നിഗമനത്തിലെത്തി കേന്ദ്രീകൃത ലോഗിംഗ് എല്ലായ്പ്പോഴും ന്യായീകരിക്കപ്പെടുന്നില്ല. മിക്കപ്പോഴും ക്ലയന്റ് എല്ലാ ലോഗുകളും ഒരിടത്ത് ശേഖരിക്കാൻ ആഗ്രഹിക്കുന്നു, എന്നിരുന്നാലും, മുഴുവൻ ലോഗിൽ നിന്നും, ബിസിനസ്സിന് നിർണായകമായ ഒരു സോപാധികമായ 5% സന്ദേശങ്ങൾ മാത്രമേ ആവശ്യമുള്ളൂ:

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

ജീവിതത്തിൽ നിന്നുള്ള ചിത്രീകരണം

മറ്റൊരു കഥ നല്ല ഉദാഹരണമായി വർത്തിക്കും. Kubernetes അവതരിപ്പിക്കുന്നതിന് വളരെ മുമ്പുതന്നെ വികസിപ്പിച്ചെടുത്ത ഒരു വാണിജ്യ പരിഹാരം ഉപയോഗിക്കുന്ന ഞങ്ങളുടെ ക്ലയന്റുകളിൽ ഒരാളുടെ സുരക്ഷാ ടീമിൽ നിന്ന് ഞങ്ങൾക്ക് ഒരു അഭ്യർത്ഥന ലഭിച്ചു.

കോർപ്പറേറ്റ് പ്രശ്‌നങ്ങൾ കണ്ടെത്തുന്നതിനുള്ള സെൻസർ - ക്യുറഡാർ ഉപയോഗിച്ച് കേന്ദ്രീകൃത ലോഗ് ശേഖരണ സംവിധാനത്തിന്റെ “സുഹൃത്തുക്കളെ ഉണ്ടാക്കേണ്ടത്” ആവശ്യമാണ്. ഈ സിസ്റ്റത്തിന് സിസ്ലോഗ് പ്രോട്ടോക്കോൾ വഴി ലോഗുകൾ സ്വീകരിക്കാനും FTP-യിൽ നിന്ന് വീണ്ടെടുക്കാനും കഴിയും. എന്നിരുന്നാലും, fluentd-നുള്ള remote_syslog പ്ലഗിനുമായി ഇത് സംയോജിപ്പിക്കാൻ പെട്ടെന്ന് സാധിച്ചില്ല. (അത് സംഭവിച്ചതുപോലെ, ഞങ്ങൾ ഒറ്റയ്ക്കല്ല). ക്യുറഡാർ സജ്ജീകരിക്കുന്നതിലെ പ്രശ്‌നങ്ങൾ ക്ലയന്റിന്റെ സുരക്ഷാ ടീമിന്റെ ഭാഗത്താണ്.

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

മറ്റൊരു ഉദാഹരണം എന്തുചെയ്യാൻ പാടില്ല എന്നതിന്റെ സൂചനയാണ്. പ്രോസസ്സിംഗിനുള്ള ഞങ്ങളുടെ ക്ലയന്റുകളിൽ ഒരാൾ ഓരോന്നും ഉപയോക്താവിൽ നിന്ന് വരുന്ന ഇവന്റുകൾ, മൾട്ടിലൈൻ ഉണ്ടാക്കി ഘടനയില്ലാത്ത ഔട്ട്പുട്ട് ലോഗിലെ വിവരങ്ങൾ. നിങ്ങൾ ഊഹിക്കുന്നതുപോലെ, അത്തരം ലോഗുകൾ വായിക്കാനും സംഭരിക്കാനും വളരെ അസൗകര്യമായിരുന്നു.

രേഖകൾക്കുള്ള മാനദണ്ഡം

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

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

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

ഒരു റെഡിമെയ്ഡ് മാപ്പിംഗ് ഉപയോഗിച്ച് നിങ്ങൾ സൂചികയിലേക്ക് അസ്ഥിരമായ ഒരു ഫീൽഡ് അയയ്ക്കുന്നു എന്നാണ് പിശക് അർത്ഥമാക്കുന്നത്. ഒരു വേരിയബിളുള്ള nginx ലോഗിലെ ഒരു ഫീൽഡാണ് ഏറ്റവും ലളിതമായ ഉദാഹരണം $upstream_status. അതിൽ ഒരു സംഖ്യയോ സ്ട്രിംഗോ അടങ്ങിയിരിക്കാം. ഉദാഹരണത്തിന്:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

സെർവർ 10.100.0.10 ഒരു 404 പിശകോടെ പ്രതികരിച്ചതായും അഭ്യർത്ഥന മറ്റൊരു ഉള്ളടക്ക സംഭരണത്തിലേക്ക് അയച്ചതായും ലോഗുകൾ കാണിക്കുന്നു. തൽഫലമായി, ലോഗുകളിലെ മൂല്യം ഇതുപോലെയായി:

"upstream_response_time": "0.001, 0.007"

ഈ സാഹചര്യം വളരെ സാധാരണമാണ്, അത് പ്രത്യേകം അർഹിക്കുന്നു ഡോക്യുമെന്റേഷനിലെ റഫറൻസുകൾ.

വിശ്വാസ്യതയെക്കുറിച്ച്?

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

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

"helm.sh/hook-delete-policy": hook-succeeded

ഇക്കാരണത്താൽ, മൈഗ്രേഷൻ എക്സിക്യൂഷൻ ലോഗ് സ്റ്റോറേജിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. ഈ സാഹചര്യത്തിൽ രാഷ്ട്രീയത്തിന് സഹായിക്കാനാകും. before-hook-creation.

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

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

അവസാനമായി, നാം അത് മറക്കരുത് ഏതെങ്കിലും സബ്സിസ്റ്റം ശരിയായി നിരീക്ഷിക്കേണ്ടത് പ്രധാനമാണ്. അല്ലെങ്കിൽ, ഒഴുക്കുള്ള ഒരു അവസ്ഥയിലേക്ക് ഓടുന്നത് എളുപ്പമാണ് CrashLoopBackOff കൂടാതെ ഒന്നും അയയ്‌ക്കുന്നില്ല, ഇത് പ്രധാനപ്പെട്ട വിവരങ്ങൾ നഷ്ടപ്പെടുമെന്ന് വാഗ്ദാനം ചെയ്യുന്നു.

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

ഈ ലേഖനത്തിൽ, Datadog പോലുള്ള SaaS സൊല്യൂഷനുകളല്ല ഞങ്ങൾ നോക്കുന്നത്. ഇവിടെ വിവരിച്ചിരിക്കുന്ന പല പ്രശ്നങ്ങളും ലോഗുകൾ ശേഖരിക്കുന്നതിൽ വൈദഗ്ദ്ധ്യമുള്ള വാണിജ്യ കമ്പനികൾ ഇതിനകം ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു രീതിയിൽ പരിഹരിച്ചിട്ടുണ്ട്, എന്നാൽ എല്ലാവർക്കും വിവിധ കാരണങ്ങളാൽ SaaS ഉപയോഗിക്കാൻ കഴിയില്ല. (പ്രധാനമായവ വിലയും 152-FZ-ന്റെ അനുസരണം ആണ്).

സെൻട്രലൈസ്ഡ് ലോഗ് ശേഖരണം ഒരു ലളിതമായ ജോലിയാണെന്ന് തോന്നുന്നു, പക്ഷേ അത് അങ്ങനെയല്ല. ഇത് ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ്:

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

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

പി.എസ്

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

• «ലോഗ്ഹൗസ് അവതരിപ്പിക്കുന്നു - കുബർനെറ്റസിലെ ലോഗുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള ഒരു ഓപ്പൺ സോഴ്സ് സിസ്റ്റം";
• «KubeCon'19-ൽ നിന്നുള്ള കുബർനെറ്റസ് ഇക്കോസിസ്റ്റമിനായുള്ള റിലീസുകൾ: JFrog കണ്ടെയ്നർ രജിസ്ട്രി, IBM-ൽ നിന്നുള്ള Kui, Loki 1.0.0…";
• «നിരീക്ഷണവും കുബർനെറ്റസും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)".

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