Observability का अंत करीब है (और मैं इससे ठीक हूँ)

 (honeycomb.io)
22 पॉइंट द्वारा GN⁺ 2025-06-13 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • पिछले कई दशकों से Observability tools का मुख्य लक्ष्य बड़े पैमाने के heterogeneous telemetry data को इंसानों के समझने लायक बनाना रहा है
  • AI और LLM के आगमन के साथ पारंपरिक "dashboard + alert + sampling" केंद्रित paradigm बदल रहा है, और analysis process की जगह automation ले रही है
  • वास्तव में, AI agent ने सिर्फ 80 सेकंड में 8 tool calls के जरिए latency spike के कारण का विश्लेषण किया, यानी जो काम पहले demo में किया जाता था वह अपने-आप हो गया और लागत भी सिर्फ 60 सेंट रही
  • पारंपरिक सुंदर dashboards या आसान instrumentation अब कोई खास value नहीं रखते, क्योंकि LLM analysis को और OpenTelemetry instrumentation को commoditize कर रहे हैं
  • भविष्य की Observability में "fast feedback loop" और AI + human collaboration workflow ही सफलता की कुंजी होंगे, और यही अधिक software तथा automation के दौर को आगे बढ़ाएंगे

Observability tools का इतिहास और AI का आगमन

  • दशकों से observability tools का मुख्य उद्देश्य विशाल heterogeneous data (telemetry) को इंसानों के समझने योग्य स्तर तक compress/summarize करना रहा है
  • जब भी नए software abstractions सामने आए हैं, जैसे Rails, AWS, Kubernetes, OpenTelemetry आदि,
    उनकी जटिलता को छिपाने के लिए monitoring, measurement, dashboards, adaptive alerts, dynamic sampling जैसे कई tools विकसित किए गए, और data की complexity को मानव cognition के अनुकूल compress करके पेश किया गया

LLM = universal function approximator, और अब सचमुच उपयोगी

  • गणितीय रूप से LLM सिर्फ universal function approximator हैं, लेकिन व्यवहार में observability समस्याओं को हल करने में ये बेहद उपयोगी साबित हो रहे हैं
  • उदाहरण के तौर पर, Honeycomb demo में heatmap पर दिख रहे latency spike का natural language में AI agent से analysis करवाया गया
    • “frontend service में हर 4 घंटे पर होने वाले latency spike के कारण का विश्लेषण करो”
    • off-the-shelf LLM (Claude Sonnet 4) और Honeycomb के Model Context Protocol(MCP) का integration
    • 80 सेकंड, 8 tool calls और 60 सेंट की लागत में कारण का automatic analysis
  • अतिरिक्त prompts, अलग training या guidance के बिना वास्तविक scenario को zero-shot तरीके से हल करने के स्तर तक बात पहुंच चुकी है
  • analysis का commoditization:
    • जब LLM analysis work को automate कर देंगे, तो मौजूदा observability products की differentiation, जैसे सुंदर graphs या आसान instrumentation, अपना मतलब खो देगी
    • OpenTelemetry instrumentation को, और LLM analysis को commoditize कर रहे हैं
    • आगे चलकर observability tools की मुख्य value की जगह “fast feedback loop” ले लेगा

इंसानों की भूमिका, और भविष्य के बदलाव

  • इंसानों की भूमिका पूरी तरह खत्म नहीं होगी
    • जैसे cloud के आने से IT का अस्तित्व खत्म नहीं हुआ, वैसे ही AI भी developers/operators को replace नहीं करेगा
    • productivity में बढ़ोतरी पूरे landscape का विस्तार करती है, और इससे और अधिक software पैदा होता है
  • असली सवाल यह है:
    ऐसी दुनिया में, जहां code writing/refactor/analysis की लागत बहुत कम हो जाए और analysis लगभग constant बन जाए,
    observability का मूल स्वरूप आखिर किस दिशा में जाएगा?

सच में महत्वपूर्ण है "fast feedback"

  • सबसे महत्वपूर्ण बात है development और operations के हर चरण में "तेज़ और घना feedback loop" तैयार करना
    • AI गति के मामले में हमेशा इंसानों से आगे रहेगा
    • LLM बहुत तेजी से दर्जनों hypotheses बनाते हैं, असफल होते हैं, और आखिरकार सही परिणाम तक पहुंच जाते हैं
      (और इसकी लागत भी बहुत कम होती है)
  • Honeycomb का दर्शन:
    • fast feedback loop, collaborative knowledge sharing, experimental development/operations
    • आगे चलकर software development और operations के पूरे lifecycle में AI assistance शामिल होगी
      • उदाहरण
        • code writing और deployment के समय AI agent real-time feedback दे, bugs/quality improvement के सुझाव दे
        • operations के दौरान emergent behavior को detect/analyze करके automatic report बनाए, approval के बाद अपने-आप सुधार करे
        • अग्रणी organizations SRE/SWE roles को AI + tools के जरिए automate करके business goals तक सीधे हासिल करें
  • success के लिए observability के भविष्य की शर्तें
    • ultra-low-latency query performance
    • integrated data store
    • इंसानों और AI के बीच seamless collaboration workflow
  • निष्कर्ष:
    • पारंपरिक dashboard, alert और visualization-केंद्रित observability tools
      AI युग में अब मुख्य चीज़ नहीं रहेंगे,
      और सिर्फ “fast feedback loop” तथा AI-human collaboration platform ही टिकेंगे

संबंधित पढ़ाई

4 टिप्पणियां

 
redlasha 2025-06-14

जिस तरह observability, monitoring का अंत नहीं था, उसी तरह LLM भी observability का अंत नहीं होगा
जैसे उन्नत monitoring की नींव पर observability विकसित हुई, वैसे ही उन्नत observability की नींव पर LLM analysis विकसित होगा
 
ethanhur 2025-06-13

LLM की वजह से लगता है कि Observability क्षेत्र में तेज़ी से innovation होगा, इसलिए उत्साहित हूँ, लेकिन title काफ़ी clickbait है lol
 
crawler 2025-06-13

अपनी ही सेवा का प्रचार "अंत करीब है" कहकर करना थोड़ा शर्मनाक लगता है...

व्यक्तिगत रूप से, मैं उम्मीद कर रहा हूँ कि vision LLM आगे बढ़े और उसे monitoring कामों में इस्तेमाल किया जाए। हाल ही में मैंने एक माता-पिता की पोस्ट देखी थी, जिसमें उन्होंने VLM का इस्तेमाल इस बात की जांच के लिए किया था कि बच्चा सोते समय कोई असामान्यता तो नहीं है; वह मुझे काफ़ी दिलचस्प लगा।
 
GN⁺ 2025-06-13
Hacker News राय
  • ऐसा लगता है कि हम सामूहिक रूप से deterministic तरीकों की वैल्यू को बहुत कम आँक रहे हैं, और उल्टा non-determinism की लागत को भी कम करके देख रहे हैं। हाल ही में मैंने इसी तरह की sales pitch वाले एक दूसरे product को test किया, और वह मेरे events को graph से जोड़कर RCE करने की कोशिश कर रहा था। नतीजा Spurious Correlations पेज जैसा बन गया, जिसे सामने देखकर साफ़ पता चलता है और थोड़ा मज़ेदार भी लगता है
    • यह एक ऐसी बात है जिसे ज़्यादा लोगों को जानना चाहिए कि time-series data वाकई spurious correlations के प्रति बहुत संवेदनशील होता है। r² value भी कोई खास मायने नहीं रखती। इससे भी बुरा तब होता है जब लोग graph को बस देखकर अंदाज़ा लगाते हैं; अगर data समय के साथ बदलता है, तो उसके लिए उपयुक्त measurement criteria का इस्तेमाल होना चाहिए
    • हो सकता है कि मैंने बात ठीक से न समझी हो, लेकिन LLM-आधारित apps में भी अगर design अच्छा हो तो बहुत महत्वपूर्ण मौकों पर deterministic UX लागू किया जा सकता है। ज़रूरत पड़ने पर LLM किसी काम को करने के लिए deterministic specification generate कर सकता है, और उसी task या action को log किया जा सकता है। ऐसा setup बनाया जा सकता है जहाँ user उस specification को conversation के साथ save करे और जब चाहे उसे फिर से चला सके, और specification fail होने पर AI उसे ठीक करने का तरीका सुझाए। यह flow AI के साथ coding करने के अनुभव जैसा है। बस spec domain को और संकीर्ण करना होगा और failed specifications को recover कैसे किया जाए, इस पर अधिक सोचना होगा। यह सब user से किसी specification language को अलग से सीखे बिना भी संभव है
  • RCA अच्छे से करने वाले व्यक्ति के रूप में, मुझे चिंता है कि मेरे वे सहकर्मी जो असहज महसूस करते हैं, वे 10% गलत नतीजे बहुत आत्मविश्वास से देने वाले tools पर वैसे ही भरोसा कर बैठेंगे और स्थिति और खराब हो जाएगी। मुझे डर है कि जब सच में कुछ पता न हो तब लोग सार्वजनिक रूप से “मुझे नहीं पता” कहने के बजाय सिर्फ tool पर निर्भर हो जाएँगे। अगर tool किसी निष्कर्ष पर पहुँचने के बाद उस interpretation का खंडन करने वाला data भी ढूँढे, और अधिक विश्वसनीय evidence या uncertainty को साफ़ तौर पर बताए, तो बात कुछ कम खराब होगी
    • अच्छा system prompt लिखकर इस हिस्से को काफी हद तक सुधारा जा सकता है। मैंने खुद ऐसे custom prompts/instructions बनाए हैं जो LLM से default रूप से ज़्यादा rigorous और research-backed जवाब निकलवाते हैं, और अनुभव काफी अच्छा रहा। ChatGPT में मैं यह prompt इस्तेमाल करता हूँ: "वस्तु, स्पष्टता और गहराई को प्राथमिकता दो। हर प्रस्ताव, design और निष्कर्ष को hypothesis मानकर तीखे सवाल करो। छिपी assumptions, trade-offs और failure cases को जल्दी सामने लाओ। अनावश्यक प्रशंसा को बिना आधार के छोड़ दो। अगर अनिश्चित हो तो साफ़ बताओ। हमेशा वैकल्पिक दृष्टिकोण सुझाओ। factual claims तभी निश्चित रूप से कहो जब citation या पुख्ता आधार हो। अगर reasoning या अपूर्ण जानकारी पर निर्भर हो to उसे स्पष्ट रूप से बताओ। confidence से ज़्यादा accuracy को महत्व दो।" इस तरह की संरचना से जवाबों की quality और depth सच में काफी बढ़ जाती है
  • “New Relic Rails क्रांति में, Datadog AWS के उभार में, Honeycomb OpenTelemetry को lead करने में” जैसी history एक पक्षपाती व्याख्या है। OpenTelemetry(OTel) की शुरुआत Google के OpenCensus और LightStep के OpenTracing के आधिकारिक रूप से विलय से हुई थी। Google, LightStep, Microsoft, Uber जैसी कई संस्थाओं ने शुरुआती governance में भाग लिया। यह सही है कि Honeycomb ने code, community और technical adoption को आगे बढ़ाने में बड़ा योगदान दिया, लेकिन “lead किया” कहना अतिशयोक्ति है
    • मैं यह एक ऐसे व्यक्ति के रूप में पढ़ रहा हूँ जिसने हाल ही में Honeycomb अपनाया है, और यह सच में कमाल का tool है। खासकर otel auto-instrumentation की वजह से कुछ ही घंटों में insight मिलना संभव हो जाता है। dashboard/query features भी साफ़ दिखाते हैं कि यह deep Observability philosophy से निकले हैं। हमारी पूरी team इस tool की polish देखकर चौंक गई। Datadog ज़्यादा marketing और 'observability' checklist पर केंद्रित लगता है
  • “sales pitch” वाले हिस्से को एक तरफ रख दें तो यह LLM का सच में value देने वाला application है। अब तक monitoring और observability बड़े enterprise SRE की दुनिया रही है, और छोटे संगठनों के लिए इसकी barrier बहुत ऊँची थी (कम से कम IT के नज़रिए से)। meaningful metrics चुनना, heartbeat और baseline set करना, इन सबके लिए समय, specialized tools, बड़ा development environment और change validation systems चाहिए होते थे, इसलिए सामान्य IT teams के लिए यह मुश्किल था। अब सबसे लोकप्रिय tools पर trained LLM की वजह से budget या skill की कमी वाली IT teams भी open framework/tool आधारित “वास्तविक” observability systems बना सकती हैं। अब हर बार चमकदार subscription solution की ज़रूरत नहीं। dashboard बनाना हो या practical monitoring setup चाहिए हो, LLM सच में वरदान जैसा है। अगर IT staff documentation पढ़कर troubleshooting कर सकता है, तो CIO द्वारा push किए जाने वाले ढेरों product suites में हर चीज़ को गहराई से सीखे बिना भी इसकी utility बहुत बड़ी है। अगर PagerDuty alerts के साथ कम से कम probable cause recommendation भी जुड़ जाए, तो SMB/SME के नज़रिए से यह observability क्रांति होगी
    • meaningful metrics खोज निकालना LLM के बस की बात नहीं, लेकिन heartbeat, baseline जैसी बाकी चीज़ें तो बहुत पहले से ConvNet (convolutional neural network) के जरिए काफी हद तक automate की जा सकती थीं। change validation या stability control जैसे deployment concerns observability tools के दायरे से बाहर की समस्या हैं
    • मुझे छोटे SRE teams में भी बहुत बड़ा impact दिखता है। हमारी team में 2 लोग सैकड़ों bare-metal servers manage करते हैं, और जब incident होता है तो cause को narrow down करना बहुत stressful होता है। हम तो MCP(Master Control Program) जैसा tool खुद बना लें क्या, यह तक सोच चुके हैं। कई बार लंबे समय से dormant issue अचानक error बनकर फूट पड़ता है, और ऐसे cases में LLM काफी मददगार होगा
  • title कुछ ज़्यादा sensational लगता है। इससे existing observability tools बेकार नहीं हो जाते। बस graphs बनाकर उन्हें लगातार देखते रहने में लगने वाला समय कम हो सकता है। यह वैसा ही है जैसा LLM का असर बाकी क्षेत्रों में है। यह उन कामों को तेज़ कर सकता है जो आप पहले से जानते हैं, या आपको वह तरीका सीखने में मदद कर सकता है, लेकिन किसी खास तकनीक को पूरी तरह replace नहीं करता
    • “जो काम पहले से आता है उसकी speed बढ़ाना”, “नई चीज़ें सीखने में मदद करना” — यह निष्कर्ष मैं आज ही दूसरी बार सुन रहा हूँ। 2 नंबर के लिए inference, और 1 नंबर की efficiency को चरम तक बढ़ाना, यही आगे की सबसे productive दिशा है
    • title sensational है, लेकिन message साफ़ है — entry barrier (moat) लगातार कम हो रही है
    • इस phenomenon को “Charity Majors effect” कहा जाता है
  • demo में कहा जाता है, “यह कोई बनावटी उदाहरण नहीं है। हमने demo में user से जो सवाल पूछा, वही LLM agent से भी पूछा, और उसने बिना किसी अतिरिक्त prompt, training या guidance के तुरंत सही जवाब ढूँढ लिया।” लेकिन असलियत यह है कि यह scenario पहले से demo में शामिल था, और solution भी पहले से मौजूद case है। बल्कि artificial example इस्तेमाल करके यह दिखाना चाहिए था कि model training data में ठीक-ठीक मौजूद न होने वाली नई situation पर generalize कर सकता है या नहीं। LLM की वास्तविक क्षमता उपयोगी है, यह मानता हूँ, लेकिन “observability का अंत” जैसे चरम दावे के लिए tool को generalization दिखानी होगी
  • मुझे नहीं लगता कि यह “observability का अंत” है। लेकिन लेख में रखी गई बात पूरी तरह बकवास भी नहीं है। निश्चित रूप से एक नई AI agent layer उभर सकती है जो SRE में, खासकर RCA समेत, कई भूमिकाएँ निभाए। फिर भी, ऐसा हो जाने पर भी मौजूदा observability stack का अधिकांश हिस्सा — शायद पूरा का पूरा — अब भी ज़रूरी रहेगा। और जब तक LLM की hallucination/reliability/stability समस्याएँ मूल रूप से हल नहीं होतीं, तब तक गहरी समस्या-समझ के लिए इंसानों की ज़रूरत बनी रहेगी
  • “AI से थोड़ी-सी मेहनत में वह सब हो जाएगा जो विशेषज्ञ करते थे” — business strategy के रूप में यह सच में बहुत आकर्षक है। दुख की बात है, लेकिन आजकल के 80% AI startups पर यह pitch copy-paste कर दें तो भी अजीब नहीं लगेगा
    • मुझे पता है इसे तंज़ की तरह कहा गया है, लेकिन वे “काम के विशेषज्ञ” <i>बेहद</i> महंगे resource होते हैं। अगर यह automation वास्तव में हो जाए, तो आधे-अधूरे AI startups की भरमार क्यों है, यह भी समझ में आता है
  • इस article को पढ़कर लगता है जैसे इसे AI ने ही लिखा हो। “AI इस paradigm को खत्म कर देगा, यह पहले से हो रहा है, system design और operation के तरीके तक बुनियादी रूप से बदल जाएँगे” — कुछ data की interpretation कैसे “observability का अंत” बन जाती है, यह समझ नहीं आता
  • “अब graph और UI से data देखने की ज़रूरत नहीं” वाली दलील की वास्तविक सीमा है। जब LLM अच्छा काम करता है तो वह शानदार होता है, लेकिन जब वह fail होता है, तो इंसान को बीच में आकर graph जैसी visualization खुद देखनी पड़ती है। graph या visualization भी कठिन हैं, लेकिन असली data collection या complex query और storage design तो उससे भी कठिन समस्याएँ हैं। observability तभी “गायब” होगी जब वास्तविक AI लगभग पूरी तरह सही निर्णय लेने लगेगी। और उस समय समाज की पूरी संरचना ही बदल जाएगी — एक सांस्कृतिक परिवर्तन आएगा जो भले विनाश न हो, पर कष्टदायक संक्रमण ज़रूर होगा। AI observability की दुनिया बदल रही है, यह सच है। यह अभी भी जारी है, लेकिन अभी मंज़िल दूर है