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

B2B, B2C എന്നിവയ്‌ക്കായി ഓൺലൈൻ ട്രേഡിംഗും ഫിൻ‌ടെക് ഉൽപ്പന്നങ്ങളും വികസിപ്പിക്കുന്ന ഫിൻ‌ടെക് കമ്പനിയായ എക്‌നെസ്സിൽ നിന്നുള്ളവരാണ് ഞങ്ങൾ. ഞങ്ങളുടെ ഗവേഷണ-വികസനത്തിന് വ്യത്യസ്ത ടീമുകളുണ്ട്, വികസന വകുപ്പിൽ 100+ ജീവനക്കാരുണ്ട്.

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

ഞങ്ങളുടെ പ്രചോദനം

എന്താണ് കത്തുന്നത്? ആർക്കും ഉത്തരം പറയാൻ കഴിയില്ല. അടുപ്പ് എവിടെയാണ്? മനസ്സിലാക്കാൻ പ്രയാസമാണ്. എപ്പോഴാണ് അതിന് തീപിടിച്ചത്? നിങ്ങൾക്ക് കണ്ടെത്താനാകും, പക്ഷേ ഉടനടി അല്ല. 

എന്തുകൊണ്ടാണ് ചില പാത്രങ്ങൾ നിൽക്കുമ്പോൾ മറ്റുള്ളവ വീണത്? ഏത് കണ്ടെയ്നറാണ് കുറ്റപ്പെടുത്തേണ്ടത്? എല്ലാത്തിനുമുപരി, കണ്ടെയ്നറുകളുടെ പുറംഭാഗം ഒന്നുതന്നെയാണ്, എന്നാൽ ഓരോന്നിനും അതിന്റേതായ നിയോ ഉണ്ട്.

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

ഏജന്റുമാർ

ഉള്ളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാൻ, ഏജന്റുമാരെ നേരിട്ട് കണ്ടെയ്നറുകളിൽ സ്ഥാപിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

കണ്ടെയ്‌നറുകൾ പരസ്പരം തകർക്കാത്ത അവസ്ഥയിൽ സൂക്ഷിക്കുന്ന പരിപാടികളാണ് ഈ ഏജന്റുമാർ നിയന്ത്രിക്കുന്നത്. ഏജന്റുമാർ സ്റ്റാൻഡേർഡ് ആണ്, ഇത് കണ്ടെയ്നറുകൾക്ക് സേവനം നൽകുന്നതിന് ഒരു സ്റ്റാൻഡേർഡ് സമീപനം അനുവദിക്കുന്നു. 

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

വ്യത്യസ്‌ത ചിത്രങ്ങൾ (ഡെബിയൻ, ആൽപൈൻ, സെന്റോസ് മുതലായവ) പിന്തുണയ്‌ക്കുന്ന വ്യത്യസ്ത ഓർക്കസ്‌ട്രേഷൻ സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കാൻ കഴിയുന്ന പ്രവർത്തനത്തിനും പരിപാലനത്തിനുമുള്ള യൂട്ടിലിറ്റികൾ കൂടിയാണ് ഏജന്റുകൾ അർത്ഥമാക്കുന്നത്.

അവസാനമായി, ഡോക്കർ ഫയലുകൾ ഉൾപ്പെടുന്ന ലളിതമായ CI/CD-യെ ഏജന്റുകൾ പിന്തുണയ്ക്കണം. അല്ലെങ്കിൽ, കപ്പൽ തകരും, കാരണം "വളഞ്ഞ" റെയിലുകളിൽ കണ്ടെയ്നറുകൾ വിതരണം ചെയ്യാൻ തുടങ്ങും.

നിർമ്മാണ പ്രക്രിയയും ടാർഗെറ്റ് ഇമേജ് ഉപകരണവും

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

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

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

ഈ സമീപനത്തിൽ എന്താണ് നല്ലത്? 

• ആദ്യം, ബിൽഡ് ടൂളുകളുടെ പൂർണ്ണ പതിപ്പ് നിയന്ത്രണം - ബിൽഡ് കണ്ടെയ്നർ, സ്ക്രിപ്റ്റ്, ഡിസ്ട്രിബ്യൂഷൻ പതിപ്പുകൾ. 
• രണ്ടാമതായി, ഞങ്ങൾ സ്റ്റാൻഡേർഡൈസേഷൻ കൈവരിച്ചു: ഞങ്ങൾ ടെംപ്ലേറ്റുകളും ഇന്റർമീഡിയറ്റും ഉപയോഗിക്കാൻ തയ്യാറുള്ളതുമായ ഇമേജ് അതേ രീതിയിൽ സൃഷ്ടിക്കുന്നു. 
• മൂന്നാമതായി, കണ്ടെയ്നറുകൾ നമുക്ക് പോർട്ടബിലിറ്റി നൽകുന്നു. ഇന്ന് ഞങ്ങൾ Gitlab ഉപയോഗിക്കുന്നു, നാളെ ഞങ്ങൾ TeamCity അല്ലെങ്കിൽ Jenkins ലേക്ക് മാറും, ഞങ്ങളുടെ കണ്ടെയ്നറുകൾ അതേ രീതിയിൽ പ്രവർത്തിപ്പിക്കാൻ ഞങ്ങൾക്ക് കഴിയും. 
• നാലാമത്, ആശ്രിതത്വം കുറയ്ക്കൽ. ഞങ്ങൾ വിതരണ കിറ്റുകൾ കണ്ടെയ്‌നറിൽ ഇടുന്നത് യാദൃശ്ചികമല്ല, കാരണം ഇത് ഇന്റർനെറ്റിൽ നിന്ന് ഓരോ തവണയും ഡൗൺലോഡ് ചെയ്യുന്നത് ഒഴിവാക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു. 
• അഞ്ചാമതായി, നിർമ്മാണ വേഗത വർദ്ധിച്ചു - ചിത്രങ്ങളുടെ പ്രാദേശിക പകർപ്പുകളുടെ സാന്നിധ്യം ഒരു പ്രാദേശിക ഇമേജ് ഉള്ളതിനാൽ ഡൗൺലോഡ് ചെയ്യുന്നതിൽ സമയം പാഴാക്കാതിരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. 

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നിയന്ത്രിതവും വഴക്കമുള്ളതുമായ അസംബ്ലി പ്രക്രിയ ഞങ്ങൾ കൈവരിച്ചു. പൂർണ്ണമായി പതിപ്പിച്ച ഏതെങ്കിലും കണ്ടെയ്‌നറുകൾ നിർമ്മിക്കാൻ ഞങ്ങൾ ഒരേ ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നു. 

ഞങ്ങളുടെ നിർമ്മാണ നടപടിക്രമം എങ്ങനെ പ്രവർത്തിക്കുന്നു

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

തലക്കെട്ട് അനുബന്ധ ചിത്രങ്ങളിൽ നിന്നുള്ള വിതരണങ്ങൾ ചേർക്കുന്നു. ഒപ്പം അടിക്കുറിപ്പ് ഞങ്ങളുടെ സേവനങ്ങൾ ഉള്ളിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ജോലിഭാരം, ലോഗിംഗ്, മറ്റ് ഏജന്റുകൾ എന്നിവയുടെ സമാരംഭം കോൺഫിഗർ ചെയ്യുന്നു, എൻട്രി പോയിന്റ് മാറ്റിസ്ഥാപിക്കുന്നു മുതലായവ. 

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

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

 

ഒരേ കണ്ടെയ്‌നറിന് ഡോക്കറിലും കുബർനെറ്റസിലും നമുക്ക് വ്യത്യസ്ത പ്രോസസ്സ് ട്രീകൾ ലഭിക്കും:

S6 ന്റെ മേൽനോട്ടത്തിലാണ് പേലോഡ് നടപ്പിലാക്കുന്നത്. കളക്ടറും ഇവന്റുകളും ശ്രദ്ധിക്കുക - ലോഗുകൾക്കും മെട്രിക്‌സിനും ഉത്തരവാദിത്തമുള്ള ഞങ്ങളുടെ ഏജന്റുമാരാണ് ഇവരാണ്. കുബെർനെറ്റസിന് അവയില്ല, പക്ഷേ ഡോക്കറിന് ഉണ്ട്. എന്തുകൊണ്ട്? 

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

മെട്രിക്കുകളും ലോഗുകളും

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

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

ബോക്‌സിന് പുറത്ത് കഴിയുന്നത്ര മെട്രിക്‌സ് ശേഖരണ രീതികളെ പിന്തുണയ്‌ക്കേണ്ടത് ആവശ്യമാണ് എന്നതാണ് മൂന്നാമത്തെ വശം. ഫയലുകൾ വായിക്കുന്നതും പോളിംഗ് പ്രോമിത്യൂസ്-എൻഡ് പോയിന്റ് മുതൽ ആപ്ലിക്കേഷൻ നിർദ്ദിഷ്ട പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നത് വരെ.

അവസാന വശം വിഭവ ഉപഭോഗം കുറയ്ക്കുക എന്നതാണ്.

ഞങ്ങൾ ടെലിഗ്രാഫ് എന്ന ഓപ്പൺ സോഴ്‌സ് ഗോ സൊല്യൂഷൻ തിരഞ്ഞെടുത്തു. 140-ലധികം തരത്തിലുള്ള ഇൻപുട്ട് ചാനലുകളും (ഇൻപുട്ട് പ്ലഗിനുകൾ) 30 തരം ഔട്ട്പുട്ട് ചാനലുകളും (ഔട്ട്പുട്ട് പ്ലഗിനുകൾ) പിന്തുണയ്ക്കുന്ന ഒരു സാർവത്രിക കണക്ടറാണിത്. ഞങ്ങൾ ഇത് അന്തിമമാക്കിയിട്ടുണ്ട്, ഒരു ഉദാഹരണമായി Kubernetes ഉപയോഗിച്ച് ഞങ്ങൾ ഇത് എങ്ങനെ ഉപയോഗിക്കുമെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും. 

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

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

ഡോക്കർ API വഴി ഞങ്ങൾ ലോഗുകൾ ശേഖരിക്കുന്നു: ഡെവലപ്പർമാർ അവ stdout അല്ലെങ്കിൽ stderr-ൽ ഇടുകയേ വേണ്ടൂ, കളക്ടർ അത് പരിഹരിക്കും. സാധ്യമായ ഹോസ്റ്റ് ഓവർലോഡ് തടയാൻ ലോഗുകൾ കുറച്ച് കാലതാമസത്തോടെ കഷണങ്ങളായി ശേഖരിക്കുന്നു. 

കണ്ടെയ്‌നറുകളിൽ വർക്ക് ലോഡ് സന്ദർഭങ്ങളിൽ (പ്രക്രിയകൾ) മെട്രിക്‌സ് ശേഖരിക്കുന്നു. എല്ലാം ടാഗ് ചെയ്‌തിരിക്കുന്നു: നെയിംസ്‌പെയ്‌സ്, താഴെ, അങ്ങനെ പലതും, തുടർന്ന് പ്രോമിത്യൂസ് ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്‌തു - കൂടാതെ ശേഖരണത്തിന് ലഭ്യമാകും (ലോഗുകൾ ഒഴികെ). ഞങ്ങൾ ലോഗുകളും മെട്രിക്കുകളും ഇവന്റുകളും കാഫ്കയിലേക്കും മറ്റും അയയ്ക്കുന്നു:

• ലോഗുകൾ ഗ്രേലോഗിൽ ലഭ്യമാണ് (വിഷ്വൽ വിശകലനത്തിനായി);
• ലോഗുകൾ, അളവുകൾ, ഇവന്റുകൾ എന്നിവ ദീർഘകാല സംഭരണത്തിനായി Clickhouse-ലേക്ക് അയയ്ക്കുന്നു.

AWS-ൽ എല്ലാം ഒരേപോലെ പ്രവർത്തിക്കുന്നു, ഞങ്ങൾ ഗ്രെയ്‌ലോഗിനെ കാഫ്കയ്‌ക്ക് പകരം ക്ലൗഡ് വാച്ച് ഉപയോഗിച്ച് മാത്രം. ഞങ്ങൾ ലോഗുകൾ അവിടെ അയയ്‌ക്കുന്നു, എല്ലാം വളരെ സൗകര്യപ്രദമായി മാറുന്നു: അവ ഏത് ക്ലസ്റ്ററും കണ്ടെയ്‌നറും ആണെന്ന് ഉടനടി വ്യക്തമാണ്. Google Stackdriver-ന്റെ കാര്യത്തിലും ഇതുതന്നെ സത്യമാണ്. അതായത്, ഞങ്ങളുടെ സ്കീം കാഫ്കയിലും ക്ലൗഡിലും പ്രവർത്തിക്കുന്നു. 

നമുക്ക് പോഡുകളുള്ള കുബെർനെറ്റസ് ഇല്ലെങ്കിൽ, സ്കീം കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്, എന്നാൽ ഇത് അതേ തത്വങ്ങളിൽ പ്രവർത്തിക്കുന്നു.

കണ്ടെയ്‌നറിനുള്ളിൽ സമാന പ്രക്രിയകൾ നടപ്പിലാക്കുന്നു, അവ S6 ഉപയോഗിച്ച് ക്രമീകരിക്കുന്നു. എല്ലാ പ്രക്രിയകളും ഒരേ കണ്ടെയ്‌നറിനുള്ളിൽ പ്രവർത്തിക്കുന്നു.

തത്ഫലമായി,

ലോഗുകളും മെട്രിക്കുകളും ശേഖരിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഓപ്ഷനുകൾക്കൊപ്പം ചിത്രങ്ങൾ നിർമ്മിക്കുന്നതിനും സമാരംഭിക്കുന്നതിനുമുള്ള ഒരു സമ്പൂർണ്ണ പരിഹാരം ഞങ്ങൾ സൃഷ്ടിച്ചിട്ടുണ്ട്:

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

സഹ-രചയിതാവ്: ഇല്യ പ്രുഡ്നിക്കോവ്

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