യൂറി ബുഷ്മെലേവ് "ലോഗുകൾ ശേഖരിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഒരു റേക്കിന്റെ മാപ്പ്" - റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ്

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

• ആപ്ലിക്കേഷനിൽ നിന്ന് ലോഗുകൾ എങ്ങനെ എഴുതാം;
• ലോഗുകൾ എവിടെ എഴുതണം;
• സംഭരണത്തിനും പ്രോസസ്സിംഗിനുമായി ലോഗുകൾ എങ്ങനെ വിതരണം ചെയ്യാം;
• ലോഗുകൾ എങ്ങനെ പ്രോസസ്സ് ചെയ്യുകയും സംഭരിക്കുകയും ചെയ്യാം.

നിലവിൽ ജനപ്രിയമായ കണ്ടെയ്‌നറൈസേഷൻ സാങ്കേതികവിദ്യകളുടെ ഉപയോഗം പ്രശ്‌നപരിഹാര ഓപ്ഷനുകളുടെ ഫീൽഡിൽ മണലിന് മുകളിൽ മണൽ ചേർക്കുന്നു.

യൂറി ബുഷ്മെലേവിന്റെ റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് ഇതിനെക്കുറിച്ച് മാത്രമാണ് "ലോഗുകൾ ശേഖരിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഒരു റേക്കിന്റെ ഭൂപടം"

ആർക്കാണ്, പൂച്ചയുടെ കീഴിൽ ദയവായി.

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

നമ്മൾ എവിടെ നിന്നാണ്? നമ്മളാരാണ്? തെക്കുകിഴക്കൻ ഏഷ്യയിലെ ആറ് രാജ്യങ്ങളിലെ #1 ഓൺലൈൻ റീട്ടെയിലറാണ് ലസാഡ. ഈ രാജ്യങ്ങളെല്ലാം ഡാറ്റാ സെന്ററുകൾക്കിടയിൽ വിതരണം ചെയ്യപ്പെടുന്നു. ഇപ്പോൾ ആകെ 4 ഡാറ്റാ സെന്ററുകളുണ്ട്. എന്തുകൊണ്ട് ഇത് പ്രധാനമാണ്? കാരണം, കേന്ദ്രങ്ങൾ തമ്മിൽ വളരെ ദുർബ്ബലമായ ബന്ധം ഉള്ളതുകൊണ്ടാണ് ചില തീരുമാനങ്ങൾ ഉണ്ടായത്. ഞങ്ങൾക്ക് ഒരു മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ ഉണ്ട്. ഞങ്ങൾക്ക് ഇതിനകം 80 മൈക്രോ സർവീസുകൾ ഉണ്ടെന്ന് കണ്ടപ്പോൾ ഞാൻ ആശ്ചര്യപ്പെട്ടു. ഞാൻ ലോഗുകൾ ഉപയോഗിച്ച് ടാസ്‌ക്ക് ആരംഭിച്ചപ്പോൾ, അവയിൽ 20 എണ്ണം മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ. കൂടാതെ, PHP ലെഗസിയുടെ ഒരു വലിയ ഭാഗമുണ്ട്, അത് എനിക്കും ജീവിക്കുകയും സഹിക്കുകയും വേണം. ഇതെല്ലാം സിസ്റ്റത്തിന് മൊത്തത്തിൽ മിനിറ്റിൽ 6 ദശലക്ഷത്തിലധികം സന്ദേശങ്ങൾ സൃഷ്ടിക്കുന്നു. ഞങ്ങൾ ഇതിനൊപ്പം എങ്ങനെ ജീവിക്കാൻ ശ്രമിക്കുന്നുവെന്നും എന്തുകൊണ്ടാണ് ഇത് അങ്ങനെയെന്നും ഞാൻ കാണിക്കും.

എങ്ങനെയെങ്കിലും ഈ 6 ദശലക്ഷം സന്ദേശങ്ങൾക്കൊപ്പം നിങ്ങൾ ജീവിക്കണം. അവരോട് നമ്മൾ എന്താണ് ചെയ്യേണ്ടത്? 6 ദശലക്ഷം സന്ദേശങ്ങൾ ആവശ്യമാണ്:

• ആപ്പിൽ നിന്ന് അയയ്ക്കുക
• ഡെലിവറിക്കായി സ്വീകരിക്കുക
• വിശകലനത്തിനും സംഭരണത്തിനുമായി കൈമാറുക.
• വിശകലനം ചെയ്യുക
• എങ്ങനെയെങ്കിലും സംഭരിക്കുക.

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

അതിനൊപ്പം എങ്ങനെ ജീവിക്കും? ഇപ്പോൾ ഞാൻ ഓപ്ഷനുകളുടെ ഫീൽഡ് സംക്ഷിപ്തമായി വിവരിക്കും - ഈ പ്രശ്നം സാധാരണയായി എങ്ങനെ പരിഹരിക്കപ്പെടും. ലോഗുകൾ ശേഖരിക്കുന്നതിനും കൈമാറുന്നതിനും സൂക്ഷിക്കുന്നതിനുമുള്ള പ്രശ്നം എങ്ങനെ പരിഹരിക്കാം.

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

ലോഗുകളുടെ ശേഖരണത്തോടെ, സ്ഥിതി ഏകദേശം സമാനമാണ്. ഈ പ്രത്യേക ഭാഗം പരിഹരിക്കുന്നതിന് വളരെയധികം ഓപ്ഷനുകൾ ഇല്ല. അവയിൽ കൂടുതൽ ഉണ്ട്, എന്നാൽ ഇതുവരെ പലതും ഇല്ല.

എന്നാൽ ഡെലിവറിയും തുടർന്നുള്ള വിശകലനവും കൊണ്ട്, വ്യതിയാനങ്ങളുടെ എണ്ണം പൊട്ടിത്തെറിക്കാൻ തുടങ്ങുന്നു. ഓരോ ഓപ്ഷനും ഞാൻ ഇപ്പോൾ വിവരിക്കുന്നില്ല. വിഷയത്തിൽ താൽപ്പര്യമുള്ള എല്ലാവർക്കും പ്രധാന ഓപ്ഷനുകൾ നന്നായി അറിയാമെന്ന് ഞാൻ കരുതുന്നു.

ലസാഡയിൽ ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്തുവെന്നും അത് എങ്ങനെ ആരംഭിച്ചുവെന്നും ഞാൻ കാണിച്ചുതരാം.

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

കുറച്ചുകൂടി നോക്കാം. ഞങ്ങൾ എങ്ങനെയാണ് ഈ ലോഗുകൾ എത്തിച്ചത്. ആരോ td-ഏജൻറ് തിരഞ്ഞെടുത്തു, അത് യഥാർത്ഥത്തിൽ ഒഴുക്കുള്ളതും എന്നാൽ വളരെ ഒഴുക്കുള്ളതും അല്ല. ഈ രണ്ട് പ്രോജക്റ്റുകളുടെയും ബന്ധം എനിക്ക് ഇപ്പോഴും മനസ്സിലാകുന്നില്ല, പക്ഷേ അവ ഒരേ കാര്യത്തെക്കുറിച്ചാണെന്ന് തോന്നുന്നു. റൂബിയിൽ എഴുതിയ ഈ ഒഴുക്കൻ, ലോഗ് ഫയലുകൾ വായിക്കുകയും, ചില സാധാരണ എക്സ്പ്രഷനുകൾ ഉപയോഗിച്ച് JSON-ലേക്ക് പാഴ്‌സ് ചെയ്യുകയും ചെയ്തു. തുടർന്ന് അവരെ കാഫ്കയിലേക്ക് അയച്ചു. മാത്രമല്ല, കാഫ്കയിൽ, ഓരോ API-യ്ക്കും ഞങ്ങൾക്ക് 4 പ്രത്യേക വിഷയങ്ങൾ ഉണ്ടായിരുന്നു. എന്തുകൊണ്ട് 4? ലൈവ് ഉള്ളതിനാൽ സ്റ്റേജിംഗ് ഉണ്ട്, കൂടാതെ stdout ഉം stderr ഉം ഉള്ളതിനാൽ. ഡെവലപ്പർമാർ അവ നിർമ്മിക്കുന്നു, അടിസ്ഥാന സൗകര്യ തൊഴിലാളികൾ അവ കാഫ്കയിൽ സൃഷ്ടിക്കണം. മാത്രമല്ല, കാഫ്കയെ മറ്റൊരു വകുപ്പാണ് നിയന്ത്രിച്ചിരുന്നത്. അതിനാൽ, ഒരു ടിക്കറ്റ് സൃഷ്ടിക്കേണ്ടത് ആവശ്യമായിരുന്നു, അങ്ങനെ അവർ ഓരോ എപിപിക്കും 4 വിഷയങ്ങൾ അവിടെ സൃഷ്ടിച്ചു. എല്ലാവരും അത് മറന്നു. പൊതുവേ, അത് ചവറ്റുകുട്ടയും മാലിന്യവുമായിരുന്നു.

ഞങ്ങൾ അത് ഉപയോഗിച്ച് അടുത്തതായി എന്താണ് ചെയ്തത്? ഞങ്ങൾ അത് കാഫ്കയിലേക്ക് അയച്ചു. കാഫ്കയിൽ നിന്ന്, പകുതി തടികൾ ലോഗ്സ്റ്റാഷിലേക്ക് പറന്നു. ബാക്കി പകുതി രേഖകൾ പങ്കിട്ടു. ചിലർ ഒരു ഗ്രേലോഗിലേക്കും ചിലർ മറ്റൊരു ഗ്രേലോഗിലേക്കും പറന്നു. തൽഫലമായി, ഇതെല്ലാം ഒരു ഇലാസ്റ്റിക് സെർച്ച് ക്ലസ്റ്ററിലേക്ക് പറന്നു. അതായത്, ഈ കുഴപ്പങ്ങളെല്ലാം അവസാനം അവിടെ വീണു. നിങ്ങൾ അത് ചെയ്യേണ്ടതില്ല!

മുകളിൽ നിന്ന് നോക്കുമ്പോൾ ഇങ്ങനെയാണ് തോന്നുന്നത്. നിങ്ങൾ അത് ചെയ്യേണ്ടതില്ല! ഇവിടെ, പ്രശ്നമുള്ള പ്രദേശങ്ങൾ ഉടൻ തന്നെ അക്കങ്ങൾ കൊണ്ട് അടയാളപ്പെടുത്തുന്നു. യഥാർത്ഥത്തിൽ അവയിൽ കൂടുതൽ ഉണ്ട്, എന്നാൽ 6 ശരിക്കും പ്രശ്നമുള്ളവയാണ്, അവയിൽ എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട്. ഞാൻ ഇപ്പോൾ അവരെക്കുറിച്ച് പ്രത്യേകം പറയും.

ഇവിടെ (1,2,3) ഞങ്ങൾ ഫയലുകൾ എഴുതുന്നു, അതനുസരിച്ച്, ഇവിടെ ഒരേസമയം മൂന്ന് റേക്കുകൾ ഉണ്ട്.

ആദ്യത്തേത് (1) നമ്മൾ അവ എവിടെയെങ്കിലും എഴുതേണ്ടതുണ്ട് എന്നതാണ്. ഒരു ഫയലിലേക്ക് നേരിട്ട് എഴുതാനുള്ള കഴിവ് API-ക്ക് നൽകുന്നത് എല്ലായ്പ്പോഴും അഭികാമ്യമല്ല. API ഒരു കണ്ടെയ്‌നറിൽ വേർതിരിക്കുന്നതാണ് അഭികാമ്യം, അതിലും മികച്ചത്, അത് വായിക്കാൻ മാത്രം. ഞാൻ ഒരു സിസ്റ്റം അഡ്‌മിനിസ്‌ട്രേറ്ററാണ്, അതിനാൽ ഈ കാര്യങ്ങളെക്കുറിച്ച് എനിക്ക് അൽപ്പം ബദൽ വീക്ഷണമുണ്ട്.

രണ്ടാമത്തെ പോയിന്റ് (2,3) ഞങ്ങൾക്ക് API-യിലേക്ക് ധാരാളം അഭ്യർത്ഥനകൾ വരുന്നു എന്നതാണ്. API ഒരു ഫയലിലേക്ക് ധാരാളം ഡാറ്റ എഴുതുന്നു. ഫയലുകൾ വളരുകയാണ്. നമ്മൾ അവരെ തിരിയണം. കാരണം അല്ലെങ്കിൽ നിങ്ങൾക്ക് അവിടെ ഒരു ഡിസ്കും സേവ് ചെയ്യാൻ കഴിയില്ല. അവ തിരിയുന്നത് മോശമാണ്, കാരണം അവ ഷെൽ വഴി ഒരു ഡയറക്ടറിയിലേക്ക് റീഡയറക്‌ട് ചെയ്യുന്നു. നമുക്ക് അത് തിരിക്കാൻ ഒരു വഴിയുമില്ല. ഹാൻഡിലുകൾ വീണ്ടും തുറക്കാൻ നിങ്ങൾക്ക് ആപ്ലിക്കേഷനോട് പറയാൻ കഴിയില്ല. കാരണം ഡെവലപ്പർമാർ നിങ്ങളെ ഒരു വിഡ്ഢിയെപ്പോലെ നോക്കും: “എന്ത് വിവരണങ്ങൾ? ഞങ്ങൾ സാധാരണയായി stdout-ലേക്ക് എഴുതുന്നു. ചട്ടക്കൂടുകൾ കോപ്പിട്രൺകേറ്റിനെ ലോഗ്രോട്ടേറ്റാക്കി മാറ്റി, അത് ഫയലിന്റെ ഒരു പകർപ്പും ഒറിജിനൽ ട്രങ്കുകളും ഉണ്ടാക്കുന്നു. അതനുസരിച്ച്, ഈ പകർത്തൽ പ്രക്രിയകൾക്കിടയിൽ, ഡിസ്ക് സ്പേസ് സാധാരണയായി തീരുന്നു.

(4) വ്യത്യസ്ത API-കളിൽ ഞങ്ങൾക്ക് വ്യത്യസ്ത ഫോർമാറ്റുകൾ ഉണ്ടായിരുന്നു. അവ അല്പം വ്യത്യസ്തമായിരുന്നു, പക്ഷേ regexp വ്യത്യസ്തമായി എഴുതേണ്ടതായി വന്നു. എല്ലാം പപ്പറ്റ് കൈകാര്യം ചെയ്തിരുന്നതിനാൽ, സ്വന്തം കാക്കപ്പൂക്കളുള്ള ഒരു വലിയ കൂട്ടം ക്ലാസുകൾ ഉണ്ടായിരുന്നു. കൂടാതെ, td-ഏജൻറ് മിക്ക സമയത്തും മെമ്മറി തിന്നും, വിഡ്ഢിയാകാം, അവൻ ജോലി ചെയ്യുന്നതായി നടിക്കുകയും ഒന്നും ചെയ്യാതിരിക്കുകയും ചെയ്യാം. ബാഹ്യമായി, അവൻ ഒന്നും ചെയ്യുന്നില്ലെന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല. ഏറ്റവും മികച്ചത്, അവൻ വീഴും, ആരെങ്കിലും അവനെ പിന്നീട് എടുക്കും. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഒരു അലേർട്ട് പറക്കും, ആരെങ്കിലും പോയി കൈകൊണ്ട് ഉയർത്തും.

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

ഞങ്ങൾ ഈ ചോദ്യങ്ങൾ ചോദിക്കാൻ തുടങ്ങി. കുറ്റവാളികളെ അന്വേഷിക്കേണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു.

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

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

അവിടെ (സ്ലൈഡിൽ) "ലോഗ് ഡെലിവറിക്കുള്ള SLA" പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങിയിട്ടില്ല. അത് ഇതുവരെ ഇല്ലെങ്കിലും ഞങ്ങൾ അതിനായി പ്രവർത്തിക്കുകയാണ്. കാരണം, നിങ്ങൾ അത്തരം ഒരു സ്ഥലത്തേക്ക് അത്തരമൊരു ഫോർമാറ്റിൽ എഴുതുകയും സെക്കൻഡിൽ N സന്ദേശങ്ങളിൽ കൂടുതൽ എഴുതാതിരിക്കുകയും ചെയ്താൽ, ഞങ്ങൾ അത് മിക്കവാറും അവിടെ എത്തിക്കുമെന്ന് ഇൻഫ്രാ പറയുമ്പോൾ അത് വളരെ സൗകര്യപ്രദമാണ്. ഇത് ഒരുപാട് തലവേദനകളെ അകറ്റുന്നു. ഒരു SLA ഉണ്ടെങ്കിൽ, അത് വളരെ മികച്ചതാണ്!

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

ഒഴുക്കുള്ള. ഒന്നാമതായി, മുമ്പത്തെ ജോലിയിൽ ഞാൻ അവനെ കണ്ടുമുട്ടി, അവനും ഇടയ്ക്കിടെ അവിടെ വീണു. രണ്ടാമതായി, ഇത് സമാനമാണ്, പ്രൊഫൈലിൽ മാത്രം.

ഫയൽബീറ്റ്. അത് ഞങ്ങൾക്ക് എങ്ങനെ നല്ലതായിരുന്നു? അവൻ ഗോയിലാണെന്ന വസ്തുത, ഞങ്ങൾക്ക് ഗോയിൽ വലിയ വൈദഗ്ധ്യമുണ്ട്. അതനുസരിച്ച്, എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, നമുക്ക് എങ്ങനെയെങ്കിലും അത് നമ്മിൽത്തന്നെ ചേർക്കാമായിരുന്നു. അതുകൊണ്ടാണ് ഞങ്ങൾ എടുക്കാതിരുന്നത്. അതിനാൽ നിങ്ങൾക്കായി ഇത് വീണ്ടും എഴുതാൻ തുടങ്ങാനുള്ള പ്രലോഭനങ്ങൾ പോലും ഉണ്ടാകില്ല.

ഈ അളവിൽ (syslog-ng/rsyslog/nxlog) എല്ലാത്തരം സിസ്‌ലോഗുകളും ആണ് sysadmin-നുള്ള വ്യക്തമായ പരിഹാരം.

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

അതിനാൽ, ചോയ്സ് യഥാർത്ഥത്തിൽ syslog-ng, rsyslog എന്നിവയ്ക്കിടയിലുള്ള ഒരു ചോയിസിലേക്ക് ഇറങ്ങി. പപ്പറ്റിൽ ഇതിനകം തന്നെ rsyslog-ന് ക്ലാസുകൾ ഉണ്ടായിരുന്നതിനാലും അവ തമ്മിൽ വ്യക്തമായ വ്യത്യാസം കാണാത്തതിനാലും ഞാൻ rsyslog-ലേക്ക് ചായുന്നു. എന്താണ് സിസ്ലോഗ്, എന്താണ് സിസ്ലോഗ്. അതെ, ചില ഡോക്യുമെന്റേഷൻ മോശമാണ്, ചിലത് മികച്ചതാണ്. അവന് ഈ വഴി അറിയാം, അവൻ അത് വ്യത്യസ്തമായി ചെയ്യുന്നു.

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

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

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

എന്തുകൊണ്ട് ഒരു ഫയൽ അല്ല? കാരണം എല്ലാവരും വായിച്ചിട്ടുണ്ട് ബദുഷെക്കയെക്കുറിച്ചുള്ള ലേഖനം, ഡോക്കറിലേക്ക് ഫയൽ ഫോർവേഡ് ചെയ്യാൻ ശ്രമിച്ചു, rsyslog പുനരാരംഭിച്ചതിന് ശേഷം ഫയൽ ഡിസ്ക്രിപ്റ്റർ മാറുകയും ഡോക്കറിന് ഈ ഫയൽ നഷ്ടപ്പെടുകയും ചെയ്യുന്നു. അവൻ മറ്റെന്തെങ്കിലും തുറന്ന് സൂക്ഷിക്കുന്നു, പക്ഷേ അവർ എഴുതുന്ന അതേ സോക്കറ്റ് അല്ല. ഈ പ്രശ്നം മറികടക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അതേ സമയം, തടയൽ പ്രശ്നം മറികടക്കും.

സ്ലൈഡിൽ സൂചിപ്പിച്ചിരിക്കുന്ന പ്രവർത്തനങ്ങൾ Rsyslog ചെയ്യുകയും റിലേയിലേക്കോ കാഫ്കയിലേക്കോ ലോഗുകൾ അയയ്ക്കുകയും ചെയ്യുന്നു. കാഫ്ക പഴയ രീതി തന്നെയാണ് പിന്തുടരുന്നത്. റെയ്‌ലീ - ലോഗുകൾ ഡെലിവർ ചെയ്യാൻ ഞാൻ pure rsyslog ഉപയോഗിക്കാൻ ശ്രമിച്ചു. സന്ദേശ ക്യൂ ഇല്ലാതെ, സാധാരണ rsyslog ടൂളുകൾ ഉപയോഗിച്ച്. അടിസ്ഥാനപരമായി, ഇത് പ്രവർത്തിക്കുന്നു.

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

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

എന്തൊക്കെയാണ് പ്രശ്നങ്ങൾ? ഞങ്ങളുടെ തത്സമയ API-കൾ സെക്കൻഡിൽ 50 സന്ദേശങ്ങൾ എഴുതുന്നുവെന്ന് ഞങ്ങൾ (പെട്ടെന്ന്!) കണ്ടെത്തിയതാണ് പ്രശ്‌നം ഉടലെടുത്തത്. ഇത് സ്റ്റേജ് ചെയ്യാതെയുള്ള ലൈവ് API മാത്രമാണ്. ഗ്രേലോഗ് ഒരു സെക്കൻഡിൽ 12 ആയിരം സന്ദേശങ്ങൾ മാത്രമേ കാണിക്കൂ. ന്യായമായ ഒരു ചോദ്യം ഉയർന്നു, അവശിഷ്ടങ്ങൾ എവിടെയാണ്? അതിൽ നിന്ന് ഗ്രേലോഗിന് നേരിടാൻ കഴിയില്ലെന്ന് ഞങ്ങൾ നിഗമനം ചെയ്തു. ഞങ്ങൾ നോക്കി, ഇലാസ്റ്റിക് സെർച്ച് ഉപയോഗിച്ചുള്ള ഗ്രേലോഗ് ഈ ഒഴുക്കിൽ പ്രാവീണ്യം നേടിയില്ല.

അടുത്തതായി, ഞങ്ങൾ വഴിയിൽ നടത്തിയ മറ്റ് കണ്ടെത്തലുകൾ.

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

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

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

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

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

ലോഗ്‌സ്റ്റാഷും ഗ്രേലോഗും ഉള്ള ഈ ഭാഗം, ഇത് ശരിക്കും ഉയരുന്നു. അതിനാൽ, നിങ്ങൾ അതിൽ നിന്ന് മുക്തി നേടേണ്ടതുണ്ട്. നിങ്ങൾ ഒരെണ്ണം തിരഞ്ഞെടുക്കണം.

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

പുതിയ ഗ്രേലോഗിൽ കൃത്യമായി എന്താണ് ഉൾപ്പെടുത്തിയിരിക്കുന്നത്. ഞങ്ങൾ എല്ലാം ഡോക്കറിൽ എഴുതി. ഞങ്ങൾ ഒരു കൂട്ടം സെർവറുകൾ എടുത്തു, മൂന്ന് കാഫ്ക ഇൻസ്‌റ്റൻസുകൾ പുറത്തിറക്കി, 7 ഗ്രേലോഗ് സെർവറുകൾ പതിപ്പ് 2.3 (എനിക്ക് ഇലാസ്റ്റിക് സെർച്ച് പതിപ്പ് 5 വേണം). ഇതെല്ലാം എച്ച്ഡിഡിയിൽ നിന്നുള്ള റെയ്ഡുകളിൽ ഉന്നയിച്ചതാണ്. സെക്കൻഡിൽ 100 സന്ദേശങ്ങൾ വരെയുള്ള സൂചിക നിരക്ക് ഞങ്ങൾ കണ്ടു. ആഴ്ചയിൽ 140 ടെറാബൈറ്റ് ഡാറ്റ എന്ന കണക്ക് ഞങ്ങൾ കണ്ടു.

വീണ്ടും ഒരു റേക്ക്! ഞങ്ങൾക്ക് രണ്ട് വിൽപ്പനയുണ്ട്. ഞങ്ങൾ 6 ദശലക്ഷം പോസ്റ്റുകൾക്കപ്പുറത്തേക്ക് നീങ്ങി. ഞങ്ങൾ ഗ്രേലോഗിന് ചവയ്ക്കാൻ സമയമില്ല. എങ്ങനെയെങ്കിലും വീണ്ടും അതിജീവിക്കണം.

ഞങ്ങൾ അതിജീവിച്ചത് ഇങ്ങനെയാണ്. കുറച്ച് സെർവറുകളും SSD-കളും ചേർത്തു. ഈ നിമിഷം നമ്മൾ ഇങ്ങനെയാണ് ജീവിക്കുന്നത്. ഇപ്പോൾ ഞങ്ങൾ ഇതിനകം സെക്കൻഡിൽ 160 സന്ദേശങ്ങൾ ചവച്ചുകൊണ്ടിരിക്കുന്നു. ഞങ്ങൾ ഇതുവരെ പരിധിയിൽ എത്തിയിട്ടില്ല, അതിനാൽ നമുക്ക് അതിൽ നിന്ന് എത്രത്തോളം പുറത്തുകടക്കാൻ കഴിയുമെന്ന് വ്യക്തമല്ല.

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

ഗ്രേലോഗിൽ നിന്ന് മെട്രിക്കുകൾ ശേഖരിക്കുക.

ബാൻഡ്‌വിഡ്‌ത്തും മറ്റെല്ലാറ്റിനെയും നശിപ്പിക്കാത്ത ഒരു ഭ്രാന്തൻ API ഞങ്ങൾക്ക് ലഭിക്കുന്നതിന് നിരക്ക് പരിധി ഉണ്ടാക്കുക.

അവസാനമായി, ഡെവലപ്പർമാരുമായി ഏതെങ്കിലും തരത്തിലുള്ള SLA ഒപ്പിടുക, അതുവഴി ഞങ്ങൾക്ക് അത്രയും സേവിക്കാൻ കഴിയും. കൂടുതൽ എഴുതിയാൽ ക്ഷമിക്കണം.

കൂടാതെ ഡോക്യുമെന്റേഷൻ എഴുതുക.

ചുരുക്കത്തിൽ, നമ്മൾ അനുഭവിച്ച എല്ലാറ്റിന്റെയും ഫലങ്ങൾ. ആദ്യം, മാനദണ്ഡങ്ങൾ. രണ്ടാമതായി, സിസ്ലോഗ് കേക്ക് ആണ്. മൂന്നാമതായി, സ്ലൈഡിൽ എഴുതിയിരിക്കുന്നതുപോലെ തന്നെ rsyslog പ്രവർത്തിക്കുന്നു. പിന്നെ ചോദ്യങ്ങളിലേക്ക് കടക്കാം.

ചോദ്യങ്ങൾ.

നിങ്ങളുടെ ചോദ്യം: എന്തുകൊണ്ടാണ് അവർ എടുക്കേണ്ടെന്ന് തീരുമാനിച്ചത് ... (ഫയൽബീറ്റ്?)

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

നിങ്ങളുടെ ചോദ്യം: എന്തുകൊണ്ടാണ് നിങ്ങൾ HDFS-ലേക്ക് ലോഗുകൾ എഴുതാത്തത്?

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

നിങ്ങളുടെ ചോദ്യം: ഒരു കോളം ഫോർമാറ്റ് കൂടുതൽ ഉചിതമായിരിക്കും.

മറുപടി: ഞാൻ മനസ്സിലാക്കുന്നു. ഞങ്ങൾ രണ്ട് കൈകളാലും "വേണ്ടി" ആണ്.

നിങ്ങളുടെ ചോദ്യം: നിങ്ങൾ rsyslog-ലേക്ക് എഴുതുക. ടിസിപിയും യുഡിപിയും അവിടെ ലഭ്യമാണ്. എന്നാൽ UDP ആണെങ്കിൽ, ഡെലിവറിക്ക് എങ്ങനെ ഗ്യാരന്റി നൽകും?

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

നിങ്ങളുടെ ചോദ്യം: API ലോഗിലേക്ക് ചില സന്ദേശം ജനറേറ്റ് ചെയ്യുകയും മൈക്രോസർവീസുകളിലേക്ക് നിയന്ത്രണം കൈമാറുകയും ചെയ്യുമ്പോൾ, വ്യത്യസ്ത മൈക്രോസർവീസുകളിൽ നിന്നുള്ള സന്ദേശങ്ങൾ തെറ്റായ ക്രമത്തിൽ എത്തുമെന്ന പ്രശ്നം നിങ്ങൾ നേരിട്ടിട്ടുണ്ടോ? ഇക്കാരണത്താൽ, ആശയക്കുഴപ്പം ഉണ്ടാകുന്നു.

മറുപടിഉത്തരം: അവ വ്യത്യസ്തമായ ക്രമത്തിൽ വരുന്നത് സാധാരണമാണ്. നിങ്ങൾ ഇതിന് തയ്യാറായിരിക്കണം. കാരണം ഏതെങ്കിലും നെറ്റ്‌വർക്ക് ഡെലിവറി നിങ്ങൾക്ക് ഓർഡർ ഉറപ്പുനൽകുന്നില്ല, അല്ലെങ്കിൽ നിങ്ങൾ ഇതിനായി പ്രത്യേക വിഭവങ്ങൾ ചെലവഴിക്കേണ്ടതുണ്ട്. നമ്മൾ ഫയൽ സ്റ്റോറേജുകൾ എടുക്കുകയാണെങ്കിൽ, ഓരോ API യും സ്വന്തം ഫയലിലേക്ക് ലോഗുകൾ സംരക്ഷിക്കുന്നു. പകരം, rsyslog അവയെ അവിടെ ഡയറക്ടറികളാക്കി വിഘടിപ്പിക്കുന്നു. ഓരോ എപിഐക്കും അതിന്റേതായ ലോഗുകൾ ഉണ്ട്, അവിടെ നിങ്ങൾക്ക് പോയി നോക്കാം, തുടർന്ന് ഈ ലോഗിലെ ടൈംസ്റ്റാമ്പ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് അവ താരതമ്യം ചെയ്യാം. അവർ ഗ്രേലോഗിൽ നോക്കാൻ പോയാൽ, അവിടെ അവർ ടൈംസ്റ്റാമ്പ് പ്രകാരം അടുക്കും. അവിടെ എല്ലാം ശരിയാകും.

നിങ്ങളുടെ ചോദ്യം: ടൈംസ്റ്റാമ്പ് മില്ലിസെക്കൻഡ് വ്യത്യാസപ്പെട്ടേക്കാം.

മറുപടി: ടൈംസ്റ്റാമ്പ് സൃഷ്ടിച്ചത് API തന്നെയാണ്. വാസ്തവത്തിൽ, ഇതാണ് മുഴുവൻ പോയിന്റ്. ഞങ്ങൾക്ക് എൻ.ടി.പി. API സന്ദേശത്തിൽ തന്നെ ഒരു ടൈംസ്റ്റാമ്പ് സൃഷ്ടിക്കുന്നു. ഇത് rsyslog ചേർത്തിട്ടില്ല.

നിങ്ങളുടെ ചോദ്യം: ഡാറ്റാ സെന്ററുകൾ തമ്മിലുള്ള ഇടപെടൽ വളരെ വ്യക്തമല്ല. ഡാറ്റാ സെന്ററിന്റെ ചട്ടക്കൂടിനുള്ളിൽ, ലോഗുകൾ എങ്ങനെ ശേഖരിക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്തുവെന്ന് വ്യക്തമാണ്. ഡാറ്റാ സെന്ററുകൾ തമ്മിലുള്ള ഇടപെടൽ എങ്ങനെയാണ്? അതോ ഓരോ ഡാറ്റാ സെന്ററും സ്വന്തം ജീവിതം നയിക്കുന്നുണ്ടോ?

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

നിങ്ങളുടെ ചോദ്യം: അസാധാരണമായ സാഹചര്യങ്ങളിൽ നിങ്ങൾക്ക് അവിടെ നിന്ന് ലോഗുകൾ ലഭിക്കുമോ?

മറുപടി: നിങ്ങൾക്ക് അവിടെ (ഫയൽ സംഭരണത്തിലേക്ക്) പോയി നോക്കാം.

നിങ്ങളുടെ ചോദ്യം: ലോഗുകൾ നഷ്‌ടപ്പെടുന്നില്ലെന്ന് നിങ്ങൾ എങ്ങനെ നിരീക്ഷിക്കും?

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

നിങ്ങളുടെ ചോദ്യം: ഇലാസ്റ്റിക് തിരയലിൽ, നിങ്ങൾ റിഡൻഡൻസിയോടെ ലോഗുകൾ സംഭരിക്കുന്നു. നിങ്ങൾക്ക് എത്ര പകർപ്പുകൾ ഉണ്ട്?

മറുപടി: ഒരു പകർപ്പ്.

നിങ്ങളുടെ ചോദ്യം: ഇത് ഒരു വരി മാത്രമാണോ?

മറുപടി: ഇതാണ് മാസ്റ്ററും പകർപ്പും. ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റിൽ സൂക്ഷിക്കുന്നു.

നിങ്ങളുടെ ചോദ്യം: നിങ്ങൾ എങ്ങനെയെങ്കിലും rsyslog ബഫറിന്റെ വലുപ്പം മാറ്റിയിട്ടുണ്ടോ?

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

ചോദ്യം: നിങ്ങൾ തകർന്ന JSON എഴുതുന്നുണ്ടോ?

മറുപടി: പാക്കറ്റ് വളരെ വലുതായതിനാൽ തകർന്ന JSON ഒന്നുകിൽ റിലേ സമയത്ത് ഉപേക്ഷിക്കപ്പെടും. അല്ലെങ്കിൽ ഗ്രേലോഗ് ഉപേക്ഷിക്കപ്പെടും, കാരണം ഇതിന് JSON പാഴ്‌സ് ചെയ്യാൻ കഴിയില്ല. എന്നാൽ ഇവിടെ സൂക്ഷ്മതകൾ പരിഹരിക്കേണ്ടതുണ്ട്, അവ കൂടുതലും rsyslog-മായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഞാൻ ഇതിനകം അവിടെ കുറച്ച് ലക്കങ്ങൾ പൂരിപ്പിച്ചിട്ടുണ്ട്, അത് ഇനിയും പ്രവർത്തിക്കേണ്ടതുണ്ട്.

ചോദ്യം: എന്തുകൊണ്ട് കാഫ്ക? നിങ്ങൾ RabbitMQ പരീക്ഷിച്ചിട്ടുണ്ടോ? അത്തരം ലോഡുകൾക്ക് കീഴിൽ ഗ്രേലോഗ് കൂട്ടിച്ചേർക്കുന്നില്ലേ?

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

കാഫ്കയെക്കുറിച്ച്. ചരിത്രപരമായി അങ്ങനെയാണ് സംഭവിച്ചത്. ഞാൻ എത്തിയപ്പോൾ, അത് ഇതിനകം അവിടെ ഉണ്ടായിരുന്നു, ലോഗുകൾ ഇതിനകം അതിൽ എഴുതിയിരുന്നു. ഞങ്ങൾ ഞങ്ങളുടെ ക്ലസ്റ്റർ ഉയർത്തി അതിലേക്ക് ലോഗുകൾ നീക്കി. ഞങ്ങൾ അവനെ നിയന്ത്രിക്കുന്നു, അവന്റെ വികാരങ്ങൾ ഞങ്ങൾക്കറിയാം. RabbitMQ നെ സംബന്ധിച്ചിടത്തോളം... RabbitMQ-ൽ ഞങ്ങൾക്ക് പ്രശ്‌നമുണ്ട്. റാബിറ്റ്എംക്യു ഞങ്ങൾക്കായി വികസിച്ചുകൊണ്ടിരിക്കുന്നു. ഞങ്ങൾക്ക് അത് ഉൽപാദനത്തിൽ ഉണ്ട്, അതിൽ പ്രശ്നങ്ങളുണ്ടായിരുന്നു. ഇപ്പോൾ, വിൽപ്പനയ്‌ക്ക് മുമ്പ്, അയാൾ ഷാമനൈസ് ചെയ്യപ്പെടും, അവൻ സാധാരണ ജോലി ചെയ്യാൻ തുടങ്ങും. എന്നാൽ അതിനുമുമ്പ്, അത് നിർമ്മാണത്തിലേക്ക് റിലീസ് ചെയ്യാൻ ഞാൻ തയ്യാറായിരുന്നില്ല. ഒരു കാര്യം കൂടിയുണ്ട്. ഗ്രേലോഗിന് AMQP 0.9 പതിപ്പും rsyslog-ന് AMQP 1.0 പതിപ്പും വായിക്കാൻ കഴിയും. മധ്യത്തിൽ രണ്ടും ചെയ്യാൻ കഴിയുന്ന ഒരു പരിഹാരവുമില്ല. ഒന്നോ രണ്ടോ ഉണ്ട്. അതുകൊണ്ട് ഇപ്പോൾ കാഫ്ക മാത്രം. എന്നാൽ സൂക്ഷ്മതകളും ഉണ്ട്. കാരണം, നമ്മൾ ഉപയോഗിക്കുന്ന rsyslog-ന്റെ പതിപ്പിന്റെ omkafka, rsyslog-ൽ നിന്ന് എടുത്ത മുഴുവൻ സന്ദേശ ബഫറും നഷ്‌ടപ്പെടുത്തും. നമ്മൾ അത് സഹിക്കുന്നിടത്തോളം.

ചോദ്യം: നിങ്ങൾ കാഫ്ക ഉപയോഗിക്കുന്നതു കൊണ്ടാണോ? മറ്റ് ആവശ്യങ്ങൾക്ക് ഉപയോഗിക്കുന്നില്ലേ?

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

ചോദ്യം: സോക്കറ്റുകളുള്ള ഈ ഷാമനിസം എന്തിന് ആവശ്യമാണ്? കണ്ടെയ്‌നറുകൾക്കായി നിങ്ങൾ syslog ലോഗ് ഡ്രൈവർ ഉപയോഗിക്കാൻ ശ്രമിച്ചിട്ടുണ്ടോ.

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

ചോദ്യം: നിങ്ങൾ rsyslog ഉപയോഗിച്ച് ഡാറ്റാ സെന്ററുകൾക്കിടയിൽ ഡെലിവർ ചെയ്യുന്നു. എന്തുകൊണ്ട് കാഫ്കയിൽ പാടില്ല?

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

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