AI ने सॉफ्टवेयर बनाने के हमारे तरीके को बदल दिया है, लेकिन इसने मशीनों के बारे में एक बुनियादी सच्चाई को नहीं बदला है। वे भी हमारी तरह ही शोर (noise) में डूब जाते हैं। जब इंजीनियर पहली बार AI-assisted debugging के साथ प्रयोग करते हैं, तो उनकी प्रवृत्ति सरल होती है: मॉडल को सब कुछ खिला दें। Raw logs, traces और metrics सभी को context window में डाल दिया जाता है। परिणाम अंतर्दृष्टि (insight) नहीं, बल्कि विफलता होती है। डेटा की मात्रा बहुत अधिक होती है। सिग्नल (signal) खत्म हो जाता है। Metrics एक टूल में होते हैं, traces दूसरे में, और मॉडल उन्हें एक सुसंगत कहानी में नहीं जोड़ पाता। इससे पहले कि AI आपके सिस्टम को observe करने में आपकी मदद कर सके, आपको उन्हें खुद observe करना होगा। आपको पहले डेटा को सही रूप (shape) देना होगा।

क्यों Raw Logs AI Pipelines को खराब कर देते हैं

आधुनिक सिस्टम ऐसी दर से टेलीमेट्री (telemetry) जेनरेट करते हैं जिसे कोई इंसान नहीं पढ़ सकता। इससे उन्हें आर्टिफिशियल इंटेलिजेंस के लिए एकदम सही होना चाहिए। लेकिन ऐसा नहीं है। एक Large Language Model का context window, हालांकि बढ़ रहा है, फिर भी एक सीमित पाइप की तरह है। इसे अनफ़िल्टर्ड प्रोडक्शन लॉग्स से भर देने पर आप cron job heartbeats और health-check के शोर पर टोकन बर्बाद करते हैं, जबकि वास्तविक आउटेज (outage) दब जाता है। इससे भी बुरा यह है कि raw logs में संबंधों (relationships) की कमी होती है। दोपहर 2:00 बजे latency में उछाल और उसी टाइमस्टैम्प पर लॉग में डेटाबेस कनेक्शन एरर स्पष्ट रूप से संबंधित हैं, लेकिन जब तक कोई पहले से उस संबंध को स्ट्रक्चर (structure) न कर दे, AI को अनुमान लगाना पड़ता है। अनुमान लगाना महंगा, धीमा और अक्सर गलत होता है।

इसका समाधान आर्किटेक्चरल (architectural) है, एल्गोरिथमिक (algorithmic) नहीं। किसी मॉडल को प्रॉम्प्ट (prompt) देने से पहले आपको यह तय करना होगा कि क्या एकत्र किया जाना है, उसे कैसे आकार दिया जाना है, और कौन सा बैकएंड किस प्रश्न का उत्तर देगा।

मॉनिटरिंग के चार अक्ष (Axes)

airCloset में, इंजीनियरिंग टीम ने observability को एक सिंगल फायरहोज़ (firehose) के रूप में मानना बंद कर दिया। उन्होंने मॉनिटरिंग को चार अलग-अलग अक्षों (axes) में विभाजित किया। प्रत्येक का एक विशिष्ट आकार है और वह एक विशिष्ट प्रश्न का उत्तर देता है।

  • Application: Logs और traces उत्तर देते हैं "अभी क्या हो रहा है?"
  • Infrastructure: Metrics उत्तर देते हैं "क्या हमारे पास पर्याप्त संसाधन हैं?"
  • CI: Logs और alerts उत्तर देते हैं "क्या टूटा और कब?"
  • LLM: Metrics और स्ट्रक्चर्ड रिकॉर्ड्स उत्तर देते हैं "हम कितना खर्च कर रहे हैं?"

यह अलगाव महत्वपूर्ण है क्योंकि रियल-टाइम latency ग्राफ के लिए सही आकार post-hoc लागत विश्लेषण (cost analysis) के लिए बेकार है। चारों डोमेन में एक ही schema थोपने से ठीक उसी तरह का शोर पैदा होता है जो AI सहायता को बेकार बना देता है।

CI Observability: Pull करें, Push नहीं

Continuous integration वह जगह है जहाँ कोड वास्तविकता से मिलता है। जब कोई बिल्ड विफल होता है, तो डेवलपर्स को तेजी से जानकारी चाहिए होती है। एक सरल (naive) दृष्टिकोण यह है कि CI runner चलते समय सीधे आपके observability backend पर logs को push कर दे। यह कुशल लगता है, लेकिन वास्तव में खतरनाक है।

airCloset में, उन्होंने इस मॉडल को उलट दिया। CI runner observability stack को नहीं छूता है। GitHub Actions workflow समाप्त होने के बाद, वे GitHub API से logs को pull करते हैं और उन्हें Loki में ingest करते हैं।

यह pull आर्किटेक्चर तीन ठोस लाभ प्रदान करता है।

Decoupling. यदि ingestion pipeline में कोई समस्या आती है या Grafana तक पहुँचा नहीं जा सकता, तो टेस्ट रन स्वयं अप्रभावित रहता है। बिल्ड अपने गुणों के आधार पर पास या फेल होता है। observability की विफलता के कारण कभी भी डिप्लॉयमेंट (deployment) नहीं रुकना चाहिए।

Security. CI workflow को कभी भी Grafana API key की आवश्यकता नहीं होती है। टेस्ट कोड उन secrets को छूने के लिए कुख्यात है जिन्हें उसे नहीं छूना चाहिए, और उस जोखिम को हटाना 'blast radius' को कम करता है यदि कोई dependency समझौता (compromised) हो जाती है।

Cross-querying. एक बार जब CI