AI സോഫ്റ്റ്‌വെയർ നിർമ്മാണ രീതികളെ മാറ്റിമറിച്ചു, എന്നാൽ യന്ത്രങ്ങളെ സംബന്ധിച്ച അടിസ്ഥാനപരമായ ഒരു സത്യം അത് മാറ്റിക്കളഞ്ഞില്ല. നമ്മളെപ്പോലെ തന്നെ അവയും അമിതമായ വിവരങ്ങളുടെ (noise) കുപ്പായത്തിൽ മുങ്ങിപ്പോകുന്നു. എൻജിനീയർമാർ ആദ്യമായി AI-അസിസ്റ്റഡ് ഡിബഗ്ഗിംഗ് പരീക്ഷിക്കുമ്പോൾ, അവർക്ക് തോന്നുന്ന ലളിതമായ ഒരു കാര്യം എല്ലാ വിവരങ്ങളും മോഡലിന് നൽകുക എന്നതാണ്. റോ ലോഗുകൾ (raw logs), ട്രേസുകൾ (traces), മെട്രിക്സുകൾ (metrics) എന്നിവയെല്ലാം കോൺടെക്സ്റ്റ് വിൻഡോയിലേക്ക് (context window) കുത്തിനിറയ്ക്കുന്നു. ഇതിന്റെ ഫലം ഉൾക്കാഴ്ചയല്ല, മറിച്ച് പരാജയമാണ്. വിവരങ്ങളുടെ അളവ് വളരെ കൂടുതലാണ്. സിഗ്നലുകൾ തകരാറിലാകുന്നു. മെട്രിക്സുകൾ ഒരു ടൂളിലും, ട്രേസുകൾ മറ്റൊരു ടൂളിലും ആയിരിക്കും, അവയെ കോർത്തിണക്കി ഒരു വ്യക്തമായ ചിത്രം നൽകാൻ മോഡലിന് കഴിയില്ല. നിങ്ങളുടെ സിസ്റ്റങ്ങളെ നിരീക്ഷിക്കാൻ AI സഹായിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾ അവയെ സ്വയം നിരീക്ഷിക്കണം. നിങ്ങൾ ആദ്യം ഡാറ്റയെ കൃത്യമായി രൂപപ്പെടുത്തണം.

എന്തുകൊണ്ടാണ് Raw Logs AI പൈപ്പ്‌ലൈനുകളെ തകരാറിലാക്കുന്നത്?

ആധുനിക സിസ്റ്റങ്ങൾ മനുഷ്യർക്ക് വായിക്കാൻ കഴിയാത്ത വേഗതയിൽ ടെലിമെട്രി (telemetry) ഉത്പാദിപ്പിക്കുന്നു. ഇത് അവയെ ആർട്ടിഫിഷ്യൽ ഇന്റലിജൻസിന് അനുയോജ്യമാക്കണമെന്നാണ് തോന്നുന്നത്. എന്നാൽ അങ്ങനെയല്ല. ഒരു ലാർജ് ലാംഗ്വേജ് മോഡലിന്റെ (LLM) കോൺടെക്സ്റ്റ് വിൻഡോ വലുതാകുന്നുണ്ടെങ്കിലും, അത് പരിമിതമാണ്. അൺഫിൽട്ടർ ചെയ്ത പ്രൊഡക്ഷൻ ലോഗുകൾ അതിലേക്ക് നിറച്ചാൽ, യഥാർത്ഥ തകരാറുകൾ (outage) മറയ്ക്കപ്പെടുകയും ക്രോൺ ജോബ് ഹാർട്ട്ബീറ്റുകൾക്കും (cron job heartbeats) ഹെൽത്ത്-ചെക്ക് നോയിസിനും (health-check noise) വേണ്ടി ടോക്കണുകൾ പാഴാകുകയും ചെയ്യുന്നു. ഇതിലും മോശമായ കാര്യം, റോ ലോഗുകളിൽ ബന്ധങ്ങൾ (relationships) ഇല്ലാത്തതാണ്. ഉദാഹരണത്തിന്, ഉച്ചയ്ക്ക് 2:00 മണിയിലെ ലേറ്റൻസി വർദ്ധനവും (latency spike) അതേ സമയത്തെ ഡാറ്റാബേസ് കണക്ഷൻ എററും തമ്മിൽ വ്യക്തമായ ബന്ധമുണ്ടായിരിക്കാം, എന്നാൽ ആ ബന്ധം മുൻകൂട്ടി ക്രമീകരിച്ചിട്ടില്ലെങ്കിൽ, AI അത് ഊഹിക്കേണ്ടി വരും. ഊഹിക്കുന്നത് ചെലവേറിയതും സാവധാനത്തിലുള്ളതും പലപ്പോഴും തെറ്റായതുമാണ്.

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

മോണിറ്ററിംഗിന്റെ നാല് അച്ചുതണ്ടുകൾ

airCloset-ൽ, എൻജിനീയറിംഗ് ടീം ഒബ്സർവബിലിറ്റിയെ (observability) ഒരു ഒറ്റ ഫയർഹോസ് (firehose) ആയി കാണുന്നത് നിർത്തി. അവർ മോണിറ്ററിംഗിനെ നാല് വ്യത്യസ്ത അച്ചുതണ്ടുകളായി തിരിച്ചു. ഓരോന്നിനും ഒരു പ്രത്യേക രൂപവും പ്രത്യേക ചോദ്യത്തിനുള്ള ഉത്തരവും ഉണ്ട്.

  • Application: ലോഗുകളും ട്രേസുകളും "ഇപ്പോൾ എന്താണ് സംഭവിക്കുന്നത്?" എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.
  • Infrastructure: മെട്രിക്സുകൾ "നമുക്ക് ആവശ്യത്തിന് റിസോഴ്‌സുകൾ ഉണ്ടോ?" എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.
  • CI: ലോഗുകളും അലേർട്ടുകളും "എന്താണ് തകരാറിലായത്, എപ്പോൾ?" എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.
  • LLM: മെട്രിക്സുകളും സ്ട്രക്ചേർഡ് റെക്കോർഡുകളും "നമ്മൾ എത്രത്തോളം ചെലവാക്കുന്നു?" എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

ഈ വേർതിരിക്കൽ പ്രധാനമാണ്, കാരണം റിയൽ-ടൈം ലേറ്റൻസി ഗ്രാഫിന് (latency graph) അനുയോജ്യമായ രൂപം ഒരു പോസ്റ്റ്-ഹോക് കോസ്റ്റ് അനാലിസിസിന് (post-hoc cost analysis) ഉപയോഗപ്രദമല്ല. നാല് ഡൊമെയ്‌നുകളിലും ഒരേ സ്കീമ (schema) നിർബന്ധമാക്കുന്നത് AI സഹായത്തെ അപ്രസക്തമാക്കുന്ന തരത്തിലുള്ള നോയിസ് സൃഷ്ടിക്കാൻ കാരണമാകും.

CI Observability: Pull ചെയ്യുക, Push ചെയ്യരുത്

കോഡ് യാഥാർത്ഥ്യവുമായി ഇടപഴകുന്ന ഇടമാണ് കൺറ്റിന്യൂസ് ഇന്റഗ്രേഷൻ (Continuous integration). ഒരു ബിൽഡ് പരാജയപ്പെടുമ്പോൾ, ഡെവലപ്പർമാർക്ക് വേഗത്തിൽ വിവരങ്ങൾ അറിയേണ്ടതുണ്ട്. സിഐ റണ്ണർ (CI runner) പ്രവർത്തിക്കുമ്പോൾ തന്നെ ലോഗുകൾ നേരിട്ട് ഒബ്സർവബിലിറ്റി ബാക്കെൻഡിലേക്ക് പുഷ് ചെയ്യുന്നതാണ് സാധാരണ രീതി. ഇത് കാര്യക്ഷമമായി തോന്നാമെങ്കിലും യഥാർത്ഥത്തിൽ അപകടകരമാണ്.

airCloset-ൽ അവർ ഈ രീതി മാറ്റി. സിഐ റണ്ണർ ഒബ്സർവബിലിറ്റി സ്റ്റാക്കിനെ (observability stack) സ്പർശിക്കുന്നില്ല. GitHub Actions വർക്ക്ഫ്ലോ പൂർത്തിയായ ശേഷം, അവർ GitHub API-ൽ നിന്ന് ലോഗുകൾ പുൾ ചെയ്യുകയും അവ Loki-ലേക്ക് ഇൻജസ്റ്റ് (ingest) ചെയ്യുകയും ചെയ്യുന്നു.

ഈ പുൾ ആർക്കിടെക്ചർ മൂന്ന് വ്യക്തമായ നേട്ടങ്ങൾ നൽകുന്നു.

Decoupling. ഇൻജസ്റ്റൻ പൈപ്പ്‌ലൈനിൽ (ingestion pipeline) തകരാറോ അല്ലെങ്കിൽ Grafana ലഭ്യമാകാത്ത അവസ്ഥയോ ഉണ്ടായാൽ പോലും, ടെസ്റ്റ് റണ്ണിനെ അത് ബാധിക്കില്ല. ബിൽഡ് അതിന്റെ ഗുണനിലവാരത്തിന്റെ അടിസ്ഥാനത്തിൽ തന്നെ വിജയിക്കുകയോ പരാജയപ്പെടുകയോ ചെയ്യുന്നു. ഒബ്സർവബിലിറ്റി പരാജയപ്പെടുന്നത് ഒരു ഡിപ്ലോയ്‌മെന്റിനെ തടസ്സപ്പെടുത്താൻ പാടില്ല.

Security. സിഐ വർക്ക്ഫ്ലോയ്ക്ക് ഒരിക്കലും ഒരു Grafana API കീ ആവശ്യമില്ല. ടെസ്റ്റ് കോഡുകൾ പലപ്പോഴും കൈകാര്യം ചെയ്യരുതാത്ത രഹസ്യ വിവരങ്ങൾ (secrets) ഉപയോഗിക്കാറുണ്ട്, അത്തരം വെളിപ്പെടുത്തലുകൾ ഒഴിവാക്കുന്നത് ഒരു ഡിപെൻഡൻസി (dependency) കോംപ്രമൈസ് ചെയ്യപ്പെട്ടാൽ ഉണ്ടാകുന്ന ആഘാതം കുറയ്ക്കുന്നു.

Cross-querying. ഒരിക്കൽ CI