എങ്ങനെയാണ് ഞങ്ങൾ CIAN ടെറാബൈറ്റ് ലോഗുകൾ മെരുക്കിയത്

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

നമ്മൾ എവിടെയാണ് തുടങ്ങിയത്?

കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി, cian.ru-ലെ ലോഡ് വളരെ വേഗത്തിൽ വളർന്നു, 2018 മൂന്നാം പാദത്തോടെ റിസോഴ്സ് ട്രാഫിക് പ്രതിമാസം 11.2 ദശലക്ഷം അദ്വിതീയ ഉപയോക്താക്കളിൽ എത്തി. ആ സമയത്ത്, നിർണായക നിമിഷങ്ങളിൽ ഞങ്ങൾക്ക് 40% വരെ ലോഗുകൾ നഷ്ടപ്പെട്ടു, അതിനാലാണ് ഞങ്ങൾക്ക് സംഭവങ്ങൾ വേഗത്തിൽ കൈകാര്യം ചെയ്യാൻ കഴിയാതെ വന്നത്, അവ പരിഹരിക്കാൻ ധാരാളം സമയവും പരിശ്രമവും ചെലവഴിക്കുകയും ചെയ്തു. പ്രശ്‌നത്തിന്റെ കാരണം കണ്ടെത്താൻ ഞങ്ങൾക്ക് പലപ്പോഴും കഴിഞ്ഞില്ല, കുറച്ച് സമയത്തിന് ശേഷം അത് ആവർത്തിക്കും. അത് നരകമായിരുന്നു, അതിനെക്കുറിച്ച് എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട്.

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

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

ദ്രുതഗതിയിലുള്ള വളർച്ചയുടെ വെല്ലുവിളികൾ

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

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

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

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

ലോഗുകളുടെ നഷ്‌ടം പൂർണ്ണമായും ഇല്ലാതാക്കാനും ELK ക്ലസ്റ്ററിലേക്കുള്ള അവരുടെ ഡെലിവറി സമയം ഫോഴ്‌സ് മജ്യൂർ സമയത്ത് പരമാവധി 15 മിനിറ്റായി കുറയ്ക്കാനും ഞങ്ങൾ ഒരു ലക്ഷ്യം വെച്ചു (ഞങ്ങൾ പിന്നീട് ഈ കണക്കിനെ ഒരു ആന്തരിക കെപിഐ ആയി ആശ്രയിച്ചു).

പുതിയ റൊട്ടേഷൻ മെക്കാനിസവും ഹോട്ട്-വാം നോഡുകളും

ElasticSearch പതിപ്പ് 5.5.2 ൽ നിന്ന് 6.4.3 ലേക്ക് അപ്ഡേറ്റ് ചെയ്തുകൊണ്ട് ഞങ്ങൾ ക്ലസ്റ്റർ പരിവർത്തനം ആരംഭിച്ചു. ഒരിക്കൽ കൂടി ഞങ്ങളുടെ പതിപ്പ് 5 ക്ലസ്റ്റർ മരിച്ചു, ഞങ്ങൾ അത് ഓഫാക്കി പൂർണ്ണമായും അപ്ഡേറ്റ് ചെയ്യാൻ തീരുമാനിച്ചു - ഇപ്പോഴും ലോഗുകൾ ഒന്നുമില്ല. അതിനാൽ ഞങ്ങൾ ഈ പരിവർത്തനം വെറും രണ്ട് മണിക്കൂറിനുള്ളിൽ നടത്തി.

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

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

ക്ലസ്റ്റർ ഒപ്റ്റിമൈസേഷൻ

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

ഉദാഹരണത്തിന്, റൊട്ടേഷൻ കോൺഫിഗറിനായി:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

റോൾഓവർ അപരനാമം ഇല്ലെങ്കിൽ, ഒരു പിശക് സംഭവിച്ചു:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

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

ഞങ്ങൾ ക്ലസ്റ്റർ മെച്ചപ്പെടുത്തിക്കൊണ്ടിരിക്കുമ്പോൾ, cian.ru-ന്റെ ട്രാഫിക് പ്രതിമാസം 12,8 ദശലക്ഷം അദ്വിതീയ ഉപയോക്താക്കളായി വർദ്ധിച്ചു. തൽഫലമായി, ഞങ്ങളുടെ പരിവർത്തനങ്ങൾ ഉൽ‌പാദനത്തിലെ മാറ്റങ്ങൾക്ക് അൽപ്പം പിന്നിലാണെന്ന് തെളിഞ്ഞു, കൂടാതെ “ഊഷ്മള” നോഡുകൾക്ക് ലോഡിനെ നേരിടാൻ കഴിയില്ലെന്നും ലോഗുകളുടെ മുഴുവൻ ഡെലിവറി മന്ദഗതിയിലാണെന്നും ഞങ്ങൾ അഭിമുഖീകരിച്ചു. പരാജയങ്ങളില്ലാതെ ഞങ്ങൾക്ക് "ചൂടുള്ള" ഡാറ്റ ലഭിച്ചു, എന്നാൽ ബാക്കിയുള്ളവയുടെ വിതരണത്തിൽ ഞങ്ങൾക്ക് ഇടപെടുകയും സൂചികകൾ തുല്യമായി വിതരണം ചെയ്യുന്നതിനായി ഒരു മാനുവൽ റോൾഓവർ നടത്തുകയും വേണം. 

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

ലോഗ് പുനർവിതരണം

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

ഒരു ഹാർഡ്‌വെയർ അപ്‌ഡേറ്റ് ഉപയോഗിച്ച് ഞങ്ങൾ അടുത്ത ആവർത്തനം ആരംഭിച്ചു. ഞങ്ങൾ അഞ്ച് കോർഡിനേറ്റർമാരിൽ നിന്ന് മൂന്നിലേക്ക് മാറി, ഡാറ്റ നോഡുകൾ മാറ്റി, പണത്തിന്റെയും സംഭരണ ​​സ്ഥലത്തിന്റെയും കാര്യത്തിൽ ഞങ്ങൾ വിജയിച്ചു. നോഡുകൾക്കായി ഞങ്ങൾ രണ്ട് കോൺഫിഗറേഷനുകൾ ഉപയോഗിക്കുന്നു: 

• "ഹോട്ട്" നോഡുകൾക്ക്: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3-ന് 1, Hot3-ന് 2).
• "ഊഷ്മള" നോഡുകൾക്ക്: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

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

ചെറിയ സൂചികകൾ അപ്രത്യക്ഷമാകുന്നതിന്റെ പ്രശ്നം അവയുടെ റൊട്ടേഷൻ പുനഃക്രമീകരിച്ചുകൊണ്ട് ഞങ്ങൾ പരിഹരിച്ചു. ഇപ്പോൾ സൂചികകൾ ഓരോ 23 മണിക്കൂറിലും തിരിക്കപ്പെടുന്നു, അവിടെ കുറച്ച് ഡാറ്റയുണ്ടെങ്കിലും. ഇത് ഷാർഡുകളുടെ എണ്ണം ചെറുതായി വർദ്ധിപ്പിച്ചു (അവയിൽ ഏകദേശം 800 എണ്ണം ഉണ്ടായിരുന്നു), എന്നാൽ ക്ലസ്റ്റർ പ്രകടനത്തിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഇത് സഹനീയമാണ്. 

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

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

ഭാവിയിലേക്കുള്ള പദ്ധതികൾ

നടപ്പിലാക്കിയ കോൺഫിഗറേഷൻ സ്കെയിലുകൾ മികച്ചതാണ്, ഇപ്പോൾ ഞങ്ങൾ 13,3 TB ഡാറ്റ സംഭരിക്കുന്നു - എല്ലാ ലോഗുകളും 4 ദിവസത്തേക്ക്, ഇത് അലേർട്ടുകളുടെ അടിയന്തര വിശകലനത്തിന് ആവശ്യമാണ്. ഞങ്ങൾ ചില ലോഗുകളെ മെട്രിക്സുകളായി പരിവർത്തനം ചെയ്യുന്നു, അത് ഞങ്ങൾ ഗ്രാഫൈറ്റിലേക്ക് ചേർക്കുന്നു. എഞ്ചിനീയർമാരുടെ ജോലി എളുപ്പമാക്കുന്നതിന്, ഇൻഫ്രാസ്ട്രക്ചർ ക്ലസ്റ്ററിനായുള്ള മെട്രിക്കുകളും സാധാരണ പ്രശ്‌നങ്ങളുടെ സെമി-ഓട്ടോമാറ്റിക് റിപ്പയർ ചെയ്യുന്നതിനുള്ള സ്‌ക്രിപ്റ്റുകളും ഞങ്ങളുടെ പക്കലുണ്ട്. അടുത്ത വർഷം ആസൂത്രണം ചെയ്തിരിക്കുന്ന ഡാറ്റ നോഡുകളുടെ എണ്ണം വർദ്ധിപ്പിച്ച ശേഷം, ഞങ്ങൾ 4 മുതൽ 7 ദിവസം വരെ ഡാറ്റ സംഭരണത്തിലേക്ക് മാറും. പ്രവർത്തന പ്രവർത്തനത്തിന് ഇത് മതിയാകും, കാരണം ഞങ്ങൾ എല്ലായ്പ്പോഴും സംഭവങ്ങൾ എത്രയും വേഗം അന്വേഷിക്കാൻ ശ്രമിക്കുന്നു, കൂടാതെ ദീർഘകാല അന്വേഷണങ്ങൾക്ക് ടെലിമെട്രി ഡാറ്റയുണ്ട്. 

2019 ഒക്ടോബറിൽ, cian.ru-ലേക്കുള്ള ട്രാഫിക് ഇതിനകം പ്രതിമാസം 15,3 ദശലക്ഷം അദ്വിതീയ ഉപയോക്താക്കളായി വളർന്നു. ലോഗുകൾ വിതരണം ചെയ്യുന്നതിനുള്ള വാസ്തുവിദ്യാ പരിഹാരത്തിന്റെ ഗുരുതരമായ പരീക്ഷണമായി ഇത് മാറി. 

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

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

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