Sazabi
आधिकारिकAI-नेटिव ऑब्ज़र्वेबिलिटी और सुरक्षा: अपने कोडिंग एजेंट को प्रोडक्शन लॉग खोजने, पहचानी गई समस्याएँ देखने और लाइव डैशबोर्ड इस्तेमाल करने दें।
Sazabi MCP के साथ आप क्या कर सकते हैं?
- सरल भाषा में लॉग खोज — प्राकृतिक भाषा में सवाल पूछें और मेल खाने वाले लॉग रिकॉर्ड के साथ जवाब पाएँ।
- संरचित लॉग क्वेरी — जाँच को सीमित करने के लिए लॉग के खास फ़ील्ड और बार-बार दिखने वाले पैटर्न खोजें।
- कोडिंग एजेंट के लिए लॉग ऐक्सेस — कोडिंग एजेंट को CLI और MCP इंटीग्रेशन के ज़रिए अपने टूल से प्रोडक्शन लॉग क्वेरी करने दें।
- स्वचालित समस्या पहचान — अलर्ट नियम लिखे बिना लॉग में विसंगतियों का पता लगाएँ, जिनमें बिना किसी संकेत के होने वाली सेवाबाधाएँ और उपयोगकर्ताओं का असामान्य व्यवहार शामिल हैं।
- मूल कारण का विश्लेषण — संबंधित त्रुटियों को समूहित करें और उनका पता उस कोड तक लगाएँ जिसने उन्हें उत्पन्न किया।
- सुझाए गए समाधान — हर पहचानी गई समस्या को हल करने की योजना पाएँ, जिसका उपयोग इंजीनियर और कोडिंग एजेंट कर सकें।
होस्ट किया गया MCP सर्वर
npx add-mcp 'https://mcp.sazabi.com/mcp'Claude Code, Codex, Cursor और अन्य में इंस्टॉल होता है
दस्तावेज़
AI-नेटिव ऑब्ज़र्वेबिलिटी और सुरक्षा
त्वरित शुरुआत: https://docs.sazabi.com/get-started/quickstart
शुरू करें: npx @sazabi/cli start
स्वायत्त अलर्ट, संवादात्मक डिबगिंग और कोडिंग एजेंट इंटीग्रेशन। Sazabi उन समस्याओं को सामने लाता है जो मायने रखती हैं और आपकी टीम को उन्हें हल करने के लिए संदर्भ देता है।
भरोसा करने वाले
- Mastra
- Weave
- Sandstone
- Wajo
- Autumn
- Agree.com
- Inth
- Hoplite
- Taiga
- XMTP Labs
Sazabi उन टीमों के लिए एक AI-नेटिव ऑब्ज़र्वेबिलिटी और सुरक्षा प्लेटफ़ॉर्म है जो तेज़ी से सॉफ़्टवेयर रिलीज़ करती हैं। यह प्रोडक्शन लॉग को कोड से जोड़ता है, हाथ से बनाए गए मॉनिटर के बिना महत्वपूर्ण समस्याओं का पता लगाता है, मूल कारणों की जाँच करता है और उपयोगी संदर्भ उन टूल तक पहुँचाता है जिनमें इंजीनियर काम करते हैं। सामान्य भाषा में सवाल पूछें, समझें कि क्या बदला है और कोडिंग एजेंट को उस संदर्भ का उपयोग करके प्रोडक्शन समस्याएँ हल करने में मदद करने दें।
स्वायत्त अलर्ट, संवादात्मक डिबगिंग और कोडिंग एजेंट वर्कफ़्लो के लिए Sazabi का उपयोग करें। Sazabi उन इंजीनियरिंग टीमों के लिए बनाया गया है जिन्हें डैशबोर्ड और स्थिर मॉनिटर का बड़ा संग्रह बनाए रखे बिना प्रोडक्शन समस्याएँ ढूँढ़नी और ठीक करनी होती हैं। जानें कि Sazabi आपके स्टैक में कैसे फिट बैठता है—इसके लिए उत्पाद, इंटीग्रेशन, सुरक्षा प्रक्रियाओं और डेवलपर संसाधनों को देखें।
क्षमताएँ
बिना किसी सेटअप के पहचान
उन समस्याओं को पकड़ें जिनकी आपने योजना नहीं बनाई थी
मॉनिटर केवल उन्हीं विफलताओं को पकड़ते हैं जिनका आपने अनुमान लगाया हो। Sazabi हर लॉग पर नज़र रखता है और बाकी समस्याओं को भी फ़्लैग करता है—चाहे वे बिना संकेत वाली रुकावटें हों, निराश उपयोगकर्ता हों या नियंत्रण से बाहर होते एजेंट। कनेक्ट करते ही यह काम शुरू हो जाता है।
- स्वचालित पहचान: अलर्ट नियम लिखे बिना अपने लॉग में बदलाव ढूँढ़ें।
- मूल कारण विश्लेषण: संबंधित त्रुटियों को समूहित करें और उन्हें अपने कोड तक ट्रेस करें।
- सुझाए गए समाधान: इंजीनियरों और कोडिंग एजेंट को हर समस्या हल करने की योजना दें।
सुरक्षा निगरानी
जानें कि आप कब जोखिम में हैं
Sazabi सुरक्षा कमियों के लिए आपका कोड स्कैन करता है और आपके द्वारा चलाए जा रहे किसी घटक पर नया CVE आते ही आपको बताता है। जब बॉटनेट, धोखाधड़ी या घुसपैठिए आपके लॉग में दिखाई दें, तो आपकी टीम को तुरंत इसकी सूचना मिलती है।
- कोड स्कैनिंग: अपने कनेक्ट किए गए रिपॉज़िटरी में कमज़ोरियाँ ढूँढ़ें।
- CVE ट्रैकिंग: जानें कि कोई नई कमज़ोरी आपकी निर्भरताओं को कब प्रभावित करती है।
- खतरे की पहचान: अपने लॉग में बॉटनेट, धोखाधड़ी और संदिग्ध गतिविधि पहचानें।
सामान्य भाषा में खोज
आपके एजेंट के लिए बने लॉग
आपके कोडिंग एजेंट लॉग पढ़कर डिबग करते हैं, इसलिए Sazabi सभी लॉग सुरक्षित रखता है और उन्हें तेज़ी से खोजने योग्य बनाता है। स्टोरेज इतना सस्ता है कि आपको कभी यह चुनने की ज़रूरत नहीं पड़ती कि क्या हटाना है।
- सामान्य भाषा में खोज: सवाल पूछें और उससे मेल खाते लॉग रिकॉर्ड के साथ जवाब पाएँ।
- संरचित क्वेरी: जाँच को सीमित करने के लिए लॉग फ़ील्ड और बार-बार दिखने वाले पैटर्न खोजें।
- CLI & MCP: कोडिंग एजेंट को अपने टूल से प्रोडक्शन लॉग क्वेरी करने दें।
हमेशा लाइव डैशबोर्ड
पहले से लॉग की जा रही किसी भी चीज़ का चार्ट बनाएँ
अगर कोई चीज़ आपके लॉग में है, तो आप उसे लाइव डैशबोर्ड पर दिखा सकते हैं: p99 लेटेंसी, मेमोरी, धीमी क्वेरी, साइनअप। आपको मेट्रिक्स पाइपलाइन की बिल्कुल ज़रूरत नहीं पड़ती।
- AI से बनाए गए डैशबोर्ड: बताएं कि आप क्या ट्रैक करना चाहते हैं और अपने लॉग को चार्ट में बदलें।
- लॉग-आधारित मेट्रिक्स: पहले से भेजे जा रहे डेटा से लॉग वॉल्यूम, मेमोरी और CPU का चार्ट बनाएँ।
- लाइव अपडेट: नए लॉग आते ही चार्ट को अपडेट रखें।
Sazabi कैसे काम करता है
- GitHub और Slack कनेक्ट करें: कुछ ही क्लिक में GitHub और Slack ऐप इंस्टॉल करें। Sazabi संदर्भ के लिए आपका कोडबेस पढ़ता है और उन चैनलों से जुड़ता है जहाँ आपकी टीम पहले से काम करती है।
- लॉग भेजें: जिन प्लेटफ़ॉर्म का आप पहले से उपयोग करते हैं, उनसे लॉग फ़ॉरवर्ड करें। संरचित हों या असंरचित, Sazabi उन्हें उसी रूप में स्वीकार करता है। स्कीमा, पार्सिंग नियम या डैशबोर्ड बनाने की ज़रूरत नहीं।
- अलर्ट पाएँ: Sazabi आपके लॉग में असामान्यताओं पर नज़र रखता है, आपके कोड के आधार पर हर एक की जाँच करता है और मूल कारण की पहचान करके समस्या को Slack, Microsoft Teams या ईमेल पर भेजता है।
सैकड़ों संकेतों से समस्याएँ सामने लाएँ
हमले के प्रयास
प्रमाणीकरण संबंधी असामान्यताएँ
असफल लॉगिन की अचानक बढ़ोतरी, क्रेडेंशियल स्टफ़िंग, असंभव यात्रा, सेशन का दोबारा उपयोग।
समस्या का प्रकार: सक्रिय हमला (क्रेडेंशियल स्टफ़िंग, स्कैनिंग, शोषण के प्रयास।)
900 खातों पर क्रेडेंशियल स्टफ़िंग
स्थिति: खुली
विवरण
एक समन्वित लॉगिन प्रयास सैकड़ों खातों के क्रेडेंशियल आज़मा रहा है और अपने स्रोत पते बदल रहा है।
क्या हुआ
प्रमाणीकरण लॉग में 900 खातों पर 2,000 असफल लॉगिन दर्ज हैं। सामान्य साइन-इन ट्रैफ़िक में बिखरी हुई गलतियों के विपरीत, अलग-अलग IP से एक ही खाता-क्रम दिखाई देता है। ये विफलताएँ स्वचालित खाता-कब्ज़े के प्रयास का संकेत देती हैं; इनसे यह साबित नहीं होता कि किसी खाते तक पहुँच बनाई गई थी।
जाँच कैसे करें
खाते और सेशन फ़िंगरप्रिंट के आधार पर प्रयासों को समूहित करें, उस समूह में सफल लॉगिन की जाँच करें और दुरुपयोग वाले ट्रैफ़िक पर दर-सीमा लागू करें।
हमले के पेलोड
अनुरोधों में SQL इंजेक्शन, पाथ ट्रैवर्सल, SSRF या टेम्पलेट इंजेक्शन के प्रयास।
समस्या का प्रकार: सक्रिय हमला (क्रेडेंशियल स्टफ़िंग, स्कैनिंग, शोषण के प्रयास।)
ऑब्ज़र्वेबिलिटी टूल पर SQL इंजेक्शन की जाँच
स्थिति: खुली
विवरण
बिना प्रमाणीकरण वाले SQL इंजेक्शन प्रयास एक सेल्फ-होस्टेड ऑब्ज़र्वेबिलिटी टूल के ज़रिए डेटाबेस तक पहुँचे और टीम की त्रुटि ट्रैकिंग से बच निकले।
क्या हुआ
बिना सेशन वाले किसी व्यक्ति ने सेल्फ-होस्टेड ऑब्ज़र्वेबिलिटी टूल पर SQL इंजेक्शन के प्रयास भेजे, जिसने उन्हें सीधे अपने डेटाबेस तक पहुँचा दिया। टीम की त्रुटि ट्रैकिंग ने उन्हें कभी नहीं देखा; वे कुछ असफल अनुरोधों जैसे दिखे।
जाँच कैसे करें
प्रभावित अनुरोध पथ को ट्रेस करें और अनधिकृत पहुँच के लिए डेटाबेस क्वेरी लॉग की समीक्षा करें। उजागर टूल का संस्करण जाँचें और जाँच के दौरान इनग्रेेस सीमित करें।
शोषण के प्रयास
ऐसा ट्रैफ़िक जो आपके स्टैक पर किसी ज्ञात शोषण से मेल खाता हो।
समस्या का प्रकार: सक्रिय हमला (क्रेडेंशियल स्टफ़िंग, स्कैनिंग, शोषण के प्रयास।)
कमज़ोर एंडपॉइंट की जाँच
स्थिति: खुली
विवरण
अनुरोध नए सुरक्षा परामर्श में बताए गए एंडपॉइंट को निशाना बना रहे हैं, जिससे डिप्लॉय किए गए एप्लिकेशन के जोखिम पर सवाल उठता है।
क्या हुआ
एक्सेस लॉग में परामर्श में बताए गए रूट और पेलोड के आकार से मेल खाते बार-बार के प्रयास दिखते हैं। ये अनुरोध सामान्य नेविगेशन को छोड़कर सीधे प्रभावित एंडपॉइंट पर जाते हैं। मेल खाता ट्रैफ़िक शोषण के प्रयास की पुष्टि करता है, लेकिन न तो कमज़ोर डिप्लॉयमेंट की और न ही सफल निष्पादन की पुष्टि हुई है।
जाँच कैसे करें
डिप्लॉय किए गए पैकेज संस्करण और सक्षम रूट की परामर्श से तुलना करें, फिर यह तय करने से पहले कि पैच या रोकथाम की ज़रूरत है या नहीं, प्रतिक्रियाओं और बाद के प्रभावों की जाँच करें।
बॉट और स्क्रैपिंग
तेज़ दर से अनुरोध करने वाले क्लाइंट, हेडलेस ब्राउज़र, बदलते IP।
समस्या का प्रकार: दुरुपयोग और धोखाधड़ी (प्रमोशन या रेफ़रल का दुरुपयोग, नकली साइनअप, स्पैम, स्क्रैपिंग।)
डायरेक्टरी को स्क्रैप किया जा रहा है
स्थिति: खुली
विवरण
स्वचालित क्लाइंट कंपनी की डायरेक्टरी को क्रम से देख रहे हैं, जिससे लगातार रीड लोड बन रहा है और प्रोफ़ाइल डेटा बड़ी मात्रा में इकट्ठा किया जा रहा है।
क्या हुआ
एक नेटवर्क से आए अनुरोध नियमित अंतराल पर और बीच में किसी नेविगेशन के बिना डायरेक्टरी के हर पेज पर जाते हैं। बदलते क्लाइंट पते एक ही पेज क्रम और अनुरोध के आकार को साझा करते हैं। यह गतिविधि इंटरैक्टिव ब्राउज़िंग से अलग है और डायरेक्टरी को व्यवस्थित रूप से डेटा इकट्ठा करने के जोखिम में डालती है।
जाँच कैसे करें
देखें कि कौन-से फ़ील्ड सार्वजनिक रूप से पढ़े जा सकते हैं, व्यवहार के आधार पर क्लाइंट को समूहित करें और सामान्य ब्राउज़िंग को रोके बिना डायरेक्टरी-विशिष्ट दर-सीमाएँ लागू करें।
संदिग्ध पहुँच
पहुँच संबंधी असामान्यताएँ
कोई एक व्यक्ति सामान्य से कहीं अधिक डेटा पढ़ता है या क्रम से ID देखता है।
समस्या का प्रकार: संदिग्ध पहुँच (खाते से छेड़छाड़, अंदरूनी दुरुपयोग, डेटा की चोरी।)
रिकॉर्ड क्रम से पढ़े गए
स्थिति: खुली
विवरण
एक प्रमाणित खाता अपने सामान्य ब्राउज़िंग पैटर्न के बजाय हज़ारों रिकॉर्ड की सूची बना रहा है।
क्या हुआ
खाता क्रम से 1 से 5,000 तक के रिकॉर्ड ID का अनुरोध करता है। सफल रीड उन रिकॉर्ड तक जारी रहते हैं जिन तक सेशन खोज या नेविगेशन के ज़रिए नहीं पहुँचा था। यह बड़ी मात्रा में डेटा इकट्ठा किए जाने का संकेत देता है; यह मानने से पहले कि लौटाया गया हर रिकॉर्ड अधिकृत था, पहुँच के दायरे की जाँच करना उचित है।
जाँच कैसे करें
सेशन, उसके अपेक्षित कार्यभार और रिकॉर्ड-स्तर पर किए गए प्राधिकरण निर्णयों की जाँच करें। अगर पहुँच अनधिकृत थी, तो उसे रद्द करें और पता लगाएँ कि कौन-से रिकॉर्ड लौटाए गए थे।
विशेषाधिकार में बदलाव
नए एडमिन, भूमिका में बढ़ोतरी, नई API कुंजियाँ।
समस्या का प्रकार: संदिग्ध पहुँच (खाते से छेड़छाड़, अंदरूनी दुरुपयोग, डेटा की चोरी।)
रात 3 बजे एडमिन भूमिका दी गई
स्थिति: खुली
विवरण
किसी खाते को उसकी सामान्य गतिविधि से बाहर, एक अपरिचित स्थान से एडमिन विशेषाधिकार मिले, जिससे विशेषाधिकार वाले ऑपरेशन का नया रास्ता बन गया।
क्या हुआ
ऑडिट ट्रेल में रात 3 बजे ऐसे स्थान से एडमिन भूमिका दिए जाने का रिकॉर्ड है जो उस व्यक्ति के पहले के सेशन में मौजूद नहीं था। इसके बाद की पहुँच में नई भूमिका का उपयोग हुआ। यह भूमिका देना वैध रखरखाव का हिस्सा हो सकता है, लेकिन विशेषाधिकार पर भरोसा करने से पहले उसके कर्ता, समय और दायरे की पुष्टि ज़रूरी है।
जाँच कैसे करें
खाते के मालिक से भूमिका दिए जाने की पुष्टि करें, अधिकृत करने वाले सेशन की जाँच करें और उसके बाद की विशेषाधिकार वाली कार्रवाइयों की समीक्षा करें। अगर भूमिका स्वीकृत नहीं थी, तो उसे रद्द करें।
असामान्य डेटा निकासी
किसी एक व्यक्ति को बड़े एक्सपोर्ट या प्रतिक्रियाएँ।
समस्या का प्रकार: संदिग्ध पहुँच (खाते से छेड़छाड़, अंदरूनी दुरुपयोग, डेटा की चोरी।)
एक्सपोर्ट सामान्य से 50 गुना बड़ा
स्थिति: खुली
विवरण
एक्सपोर्ट में इस खाते द्वारा सामान्यतः प्राप्त किए जाने वाले डेटा से काफ़ी अधिक डेटा जा रहा है, जिससे गलती से या अनधिकृत रूप से बड़ी मात्रा में डेटा तक पहुँच की आशंका पैदा होती है।
क्या हुआ
एक CSV प्रतिक्रिया खाते के सामान्य एक्सपोर्ट से 50 गुना बड़ी है। अनुरोध में पहले के एक्सपोर्ट में इस्तेमाल किए गए फ़िल्टर हटा दिए गए हैं और रिकॉर्ड का कहीं बड़ा समूह लौटाया गया है। आकार में बदलाव असामान्य डेटा निकासी की पुष्टि करता है; फिर भी प्राधिकरण और इच्छित दायरे की जाँच करनी होगी।
जाँच कैसे करें
एक्सपोर्ट के फ़िल्टर, लौटाए गए फ़ील्ड और खाते की अनुमतियों की तुलना अनुरोधित कार्य से करें। गंतव्य की समीक्षा करें और अगर एक्सपोर्ट अनधिकृत था, तो सेशन रद्द करें।
अनियंत्रित एजेंट
AI एजेंट—आपके या किसी तीसरे पक्ष के—अपने सामान्य दायरे से बाहर काम करते हैं।
समस्या का प्रकार: एजेंट का अनुचित व्यवहार (AI एजेंट का दायरे से बाहर काम करना, प्रॉम्प्ट इंजेक्शन, अनियंत्रित लूप।)
सपोर्ट एजेंट एडमिन एंडपॉइंट को कॉल कर रहा है
स्थिति: खुली
विवरण
एक सपोर्ट एजेंट ऐसा प्रशासनिक ऑपरेशन कर रहा है जो उसके सामान्य सपोर्ट कार्यों में इस्तेमाल होने वाले टूल और दायरे से बाहर है।
क्या हुआ
टूल-कॉल लॉग दिखाते हैं कि एजेंट ऐसे एडमिन एंडपॉइंट तक पहुँचा है जिसका उसने पहले कभी उपयोग नहीं किया। यह कॉल ऑपरेटर के निर्देश के बजाय ग्राहक द्वारा दी गई सामग्री के बाद हुई। यह क्रम दायरे के संभावित उल्लंघन का संकेत देता है; ऑपरेशन से वास्तव में कुछ बदला या नहीं, यह प्रतिक्रिया और ऑडिट लॉग से पता लगाना होगा।
जाँच कैसे करें
ट्रिगर करने वाली सामग्री, टूल आर्ग्युमेंट और प्राधिकरण परिणाम की जाँच करें। एजेंट के टूल को उसके सपोर्ट दायरे तक सीमित करें और प्रशासनिक कार्रवाइयों के लिए स्वीकृति अनिवार्य करें।
कमज़ोरियाँ
लॉग में सीक्रेट या व्यक्तिगत डेटा
लॉग में लिखे गए टोकन, कुंजियाँ, ईमेल या ID नंबर।
समस्या का प्रकार: जोखिम में पड़ना (ऐसा CVE जो आपको प्रभावित करता है, कमज़ोर कोड पथ, गलत कॉन्फ़िगरेशन, लीक हुए सीक्रेट।)
त्रुटि में API कुंजी प्रिंट हुई
स्थिति: खुली
विवरण
एक त्रुटि हैंडलर क्रेडेंशियल को डायग्नोस्टिक आउटपुट में कॉपी कर रहा है, जिससे लॉग तक पहुँच रखने वाले सिस्टम और लोगों के सामने वह उजागर हो रहा है।
क्या हुआ
एक असफल आउटबाउंड अनुरोध में लॉग किए गए त्रुटि संदेश के साथ उसकी API कुंजी शामिल है। लॉगिंग की सीमा पर उसे छिपाने के बजाय, यह मान अपवाद के साथ आगे भेजा जाता है। उस रिकॉर्ड को पढ़ सकने वाला कोई भी व्यक्ति कुंजी रद्द होने तक उसका दोबारा उपयोग कर सकता है।
जाँच कैसे करें
उजागर कुंजी रद्द करें, पता लगाएँ कि रिकॉर्ड कहाँ भेजा और कितने समय तक रखा गया, और अनुरोध त्रुटियों को सीरियलाइज़ करने से पहले क्रेडेंशियल छिपाएँ।
नया सुरक्षा परामर्श आपको प्रभावित करता है
नया प्रकाशित CVE आपकी निर्भरताओं या रनटाइम से मेल खाता है (cve.now के ज़रिए)।
समस्या का प्रकार: जोखिम में पड़ना (ऐसा CVE जो आपको प्रभावित करता है, कमज़ोर कोड पथ, गलत कॉन्फ़िगरेशन, लीक हुए सीक्रेट।)
नया परामर्श आपकी लॉकफ़ाइल से मेल खाता है
स्थिति: खुली
विवरण
नए प्रकाशित फ़्रेमवर्क सुरक्षा परामर्श में एप्लिकेशन की लॉकफ़ाइल में पिन किया गया संस्करण शामिल है, इसलिए डिप्लॉय किए गए बिल्ड के जोखिम की जाँच करना ज़रूरी है। क्या हुआ
एडवाइज़री की प्रभावित संस्करण सीमा, हल की गई फ़्रेमवर्क निर्भरता से मेल खाती है। लॉकफ़ाइल का मिलान संभावित रूप से असुरक्षित आर्टिफ़ैक्ट की पहचान करता है, लेकिन यह नहीं दिखाता कि प्रभावित सुविधा सक्षम है या उस तक पहुँचा जा सकता है। वास्तविक जोखिम का निर्धारण डिप्लॉय किए गए बिल्ड और उसके रूट कॉन्फ़िगरेशन से होता है।
जाँच कैसे करें
डिप्लॉय किए गए संस्करण और प्रभावित सुविधा की पुष्टि करें, एडवाइज़री में दिए गए शमन उपायों की समीक्षा करें, फिर किसी ठीक किए गए संस्करण पर अपग्रेड करें और संबंधित रूट को चलाकर जाँचें।
जोखिमपूर्ण कोड
कोड स्कैनिंग नए कमिट में छूटे हुए ऑथ जाँचों, ऑथ बायपास या इंजेक्शन के जोखिमों को फ़्लैग करती है।
समस्या का प्रकार: जोखिम (ऐसा CVE जो आपको प्रभावित करता है, असुरक्षित कोड पथ, गलत कॉन्फ़िगरेशन, लीक हुए सीक्रेट।)
डिप्लॉय त्रुटियों में होस्ट फ़ाइलें लीक होना
स्थिति: खुली
विवरण
डिप्लॉय विफलताओं के दौरान बिल्डर होस्ट की फ़ाइलें उपयोगकर्ताओं के सामने ऐसे त्रुटि संदेशों के ज़रिए उजागर हुईं, जो सामान्य पार्स विफलताओं जैसे दिखते थे।
क्या हुआ
एक डिप्लॉय बिल्डर ने अपने ही होस्ट से फ़ाइलें पढ़ीं और उन्हें डिप्लॉय त्रुटि संदेशों में उपयोगकर्ताओं को लौटा दिया, जिनमें /etc/passwd जैसी सामग्री भी शामिल थी। ऊपर से देखने पर ये पार्स त्रुटि वाले असफल डिप्लॉय थे।
जाँच कैसे करें
पता लगाएँ कि बिल्ड इनपुट होस्ट फ़ाइलों तक और फिर त्रुटि आउटपुट तक कैसे पहुँच सकता है। फ़ाइल निष्कर्षण की सीमाओं की समीक्षा करें और उपयोगकर्ता को दिखने वाली त्रुटियों से होस्ट फ़ाइलों की सामग्री हटाएँ।
सप्लाई चेन
किसी निर्भरता का स्वामित्व बदल जाता है, उसका टाइपोस्क्वैट किया जाता है या उसे दुर्भावनापूर्ण चिह्नित किया जाता है।
समस्या का प्रकार: जोखिम (ऐसा CVE जो आपको प्रभावित करता है, असुरक्षित कोड पथ, गलत कॉन्फ़िगरेशन, लीक हुए सीक्रेट।)
समझौता किया गया पैकेज संस्करण
स्थिति: खुली
विवरण
निर्भरता की एक रिलीज़ को समझौता किया हुआ चिह्नित किया गया है, और लॉकफ़ाइल से संकेत मिलता है कि वह एप्लिकेशन बिल्ड में शामिल हो सकती है।
क्या हुआ
फ़्लैग किया गया पैकेज संस्करण, केवल एक अनुमत संस्करण सीमा से नहीं, बल्कि हल की गई निर्भरता से मेल खाता है। बिल्ड रिकॉर्ड से यह पता लगाना होगा कि वह संस्करण कहाँ इंस्टॉल किया गया था और उसका कोड या इंस्टॉल स्क्रिप्ट चली थी या नहीं। यह मिलान जोखिम पैदा करता है, लेकिन इससे यह साबित नहीं होता कि क्रेडेंशियल या डेटा चुराए गए थे।
जाँच कैसे करें
प्रभावित बिल्ड की पहचान करें, पैकेज की तुलना विश्वसनीय रिलीज़ से करें, उसे बदलें, और क्रेडेंशियल केवल तभी रोटेट करें जब निष्पादन के दौरान उनके उजागर होने की संभावना रही हो।
लॉग पैटर्न
घटना का गायब होना
ट्रैफ़िक सामान्य होने पर भी कोई सामान्यतः होने वाली चीज़ बंद हो गई है।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्प्रभावी कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
एप्लिकेशन सबमिशन आना बंद हो गए
स्थिति: खुली
विवरण
उपयोगकर्ता फ़ॉर्म तक पहुँचते रहे, लेकिन एप्लिकेशन सबमिशन इवेंट आना बंद हो गए। इससे संकेत मिलता है कि बिना किसी स्पष्ट त्रुटि के काम खो रहा है।
क्या हुआ
फ़ॉर्म व्यू और सबमिट करने के प्रयास जारी रहने के बावजूद, “Application submitted” इवेंट 2:14pm के बाद गायब हो जाता है। अब उन प्रयासों के बाद सामान्य पूर्णता इवेंट नहीं आता। ट्रैफ़िक स्वस्थ दिखता है, लेकिन यह छूटा हुआ बदलाव बताता है कि एप्लिकेशन शायद अपनी संग्रहीत स्थिति तक नहीं पहुँच रहे हैं।
जाँच कैसे करें
सबमिट करने के प्रयास को वैलिडेशन, पर्सिस्टेंस और इवेंट उत्सर्जन तक ट्रेस करें। लॉगिंग में कमी और सबमिशन खोने के बीच अंतर करने के लिए संग्रहीत एप्लिकेशन की तुलना प्रयासों से करें।
मात्रा में बदलाव
किसी इवेंट की दर उसके सामान्य पैटर्न से बहुत अधिक बढ़ जाती है या घट जाती है।
समस्या का प्रकार: दुरुपयोग और धोखाधड़ी (प्रोमो या रेफ़रल का दुरुपयोग, नकली साइनअप, स्पैम, स्क्रैपिंग।)
पासवर्ड रीसेट में उछाल
स्थिति: खुली
विवरण
पासवर्ड रीसेट अनुरोध अपने सामान्य साप्ताहिक पैटर्न से काफ़ी अधिक हैं, जिससे ईमेल लोड बढ़ रहा है और संभावित रूप से अकाउंट मालिकों को अनचाहे संदेशों से भर रहा है।
क्या हुआ
रीसेट ईमेल इवेंट मंगलवार की सामान्य दर से छह गुना चल रहे हैं, जबकि सामान्य साइन-इन ट्रैफ़िक अपने आधार स्तर के करीब है। बार-बार लक्षित किए गए अकाउंट और मिलते-जुलते अनुरोध क्रम इस बढ़ोतरी का बड़ा हिस्सा हैं। यह व्यापक उपयोगकर्ता वृद्धि के बजाय दुरुपयोग या अनजाने रीट्राई लूप की ओर संकेत करता है।
जाँच कैसे करें
लक्षित अकाउंट और अनुरोध शुरू करने वाले के आधार पर अनुरोधों को समूहित करें, क्लाइंट रीट्राई लूप की जाँच करें, और दुरुपयोग वाले ट्रैफ़िक पर प्रति-अकाउंट रीसेट सीमाएँ लागू करें।
टूटा हुआ क्रम
A के बाद सामान्यतः B होता है; अब A होता है, लेकिन B नहीं।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्प्रभावी कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
अपलोड कभी पूरे नहीं होते
स्थिति: खुली
विवरण
अपलोड अनुरोध सामान्य रूप से शुरू होते हैं, लेकिन पूर्णता चरण तक नहीं पहुँचते। इससे फ़ाइलें अनुपलब्ध रह जाती हैं, जबकि उपयोगकर्ताओं ने ट्रांसफ़र शुरू कर दिया होता है।
क्या हुआ
“Upload started” रिकॉर्ड आते रहते हैं, लेकिन उनके अनुरोध ID से मेल खाने वाला कोई “upload complete” इवेंट नहीं है। छूटी हुई पूर्णताएँ स्टोरेज हैंडऑफ़ के बाद समूहित होती हैं। उपयोगकर्ता ऐसी फ़ाइल का इंतज़ार करते रह जाते हैं जिसे अंतिम रूप नहीं दिया गया है, और इसके साथ कोई संबंधित एप्लिकेशन त्रुटि भी नहीं आती।
जाँच कैसे करें
प्रभावित अपलोड ID को स्टोरेज और फ़ाइनलाइज़ेशन तक फ़ॉलो करें। छोड़े गए मल्टीपार्ट अपलोड, विफल कॉलबैक और अनुपस्थित टाइमआउट या त्रुटि हैंडलिंग की जाँच करें।
क्रम या समय में बदलाव
चरण गलत क्रम में होते हैं या उनके बीच का अंतराल बढ़ जाता है।
समस्या का प्रकार: डेटा अखंडता (खोए हुए राइट, डुप्लिकेट, करप्शन, बेमेल रिकॉर्ड।)
वेबहुक रिकॉर्ड बनने से पहले प्रोसेस हुए
स्थिति: खुली
विवरण
वेबहुक प्रोसेसिंग उस रिकॉर्ड के बनने से पहले हो रही है जिसे वह अपडेट करता है। इससे एक अन्यथा वैध इवेंट को डेटा अनुपलब्ध होने के कारण खारिज किया जा सकता है।
क्या हुआ
वेबहुक हैंडलर, संबंधित क्रिएशन ट्रांज़ैक्शन कमिट होने से पहले रिकॉर्ड खोजते हैं। लुकअप में कुछ नहीं मिलता, लेकिन बाद में पढ़ने पर रिकॉर्ड मिल जाता है और उस पर वेबहुक अपडेट लागू नहीं हुआ होता। इवेंट का क्रम स्थानीय स्थिति को प्रोवाइडर की स्थिति से पीछे छोड़ देता है, भले ही दोनों अनुरोध पूरे हो जाएँ।
जाँच कैसे करें
वेबहुक प्राप्त होने के समय का ट्रांज़ैक्शन कमिट से मिलान करें, बेमेल इवेंट को रीट्राई के लिए सुरक्षित रखें, और लक्ष्य रिकॉर्ड उपलब्ध होने पर रीप्ले को सुरक्षित बनाएँ।
फ़ील्ड में बदलाव
इवेंट के भीतर की वैल्यू बदलती हैं: नई श्रेणियाँ, null, खाली स्ट्रिंग, असामान्य आकार।
समस्या का प्रकार: डेटा अखंडता (खोए हुए राइट, डुप्लिकेट, करप्शन, बेमेल रिकॉर्ड।)
राइट में कंपनी का संदर्भ गायब
स्थिति: खुली
विवरण
कुछ राइट में कंपनी का संबंध खो रहा है, जिससे ऐसे रिकॉर्ड बन रहे हैं जिन्हें अपेक्षित दायरे में विश्वसनीय रूप से एट्रिब्यूट या पुनः प्राप्त नहीं किया जा सकता।
क्या हुआ
company_id फ़ील्ड उन 3% राइट में null है जिनमें पहले वैल्यू मौजूद थी। ये रिकॉर्ड ऐसे इनपुट पथ से आते हैं जो पर्सिस्टेंस से पहले कंपनी का संदर्भ छोड़ देता है। राइट सफल होते हैं, लेकिन बाद में कंपनी-स्कोप वाले रीड उन्हें अपेक्षित संग्रह में नहीं ढूँढ़ पाते।
जाँच कैसे करें
ट्रेस करें कि कंपनी का संदर्भ उस राइट पथ तक कैसे पहुँचता है, आवश्यक ओनरशिप फ़ील्ड अनुपस्थित होने पर अनुरोध अस्वीकार करें, और स्कोप के भीतर सुधार करने से पहले प्रभावित रिकॉर्ड की पहचान करें।
कार्डिनैलिटी में उछाल
किसी फ़ील्ड में अचानक कहीं अधिक अलग-अलग वैल्यू होने लगती हैं।
समस्या का प्रकार: क्षमता जोखिम (सीमा तक पहुँचने से पहले चेतावनी।)
कैश कीज़ की संख्या बढ़ रही है
स्थिति: खुली
विवरण
कैश लगभग समान अनुरोधों के लिए नई कीज़ बना रहा है, जिससे पुनः उपयोग घट रहा है और स्टोरेज पर दबाव बढ़ रहा है।
क्या हुआ
हर मिनट समान छोटे रूट सेट के लिए हज़ारों अलग-अलग कैश कीज़ दिखाई देती हैं। कीज़ में अनुरोध-विशिष्ट प्रत्यय अलग-अलग होते हैं, इसलिए बार-बार किए गए अनुरोध उन प्रविष्टियों को मिस करते हैं जिनका पुनः उपयोग होना चाहिए। कीज़ का बढ़ता सेट मेमोरी उपयोग बढ़ाता है और बैकिंग सर्विस पर अधिक काम डालता है।
जाँच कैसे करें
पुराने और नए की निर्माण की तुलना करें, अनचाहे अनुरोध-विशिष्ट फ़ील्ड हटाएँ, और पहुँच से बाहर प्रविष्टियाँ साफ़ करने से पहले एक्सपायरी की पुष्टि करें।
विफलता बताने वाली शांत भाषा
ऐसे इवेंट जो विफलता बताते हैं, लेकिन info या debug के रूप में लॉग किए जाते हैं।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्प्रभावी कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
प्राइसिंग अपडेट में सबसे बड़ा अकाउंट छूट गया
स्थिति: खुली
विवरण
प्राइसिंग जॉब ने एक अकाउंट को छोड़ने को सफल पूर्णता माना, जिससे सबसे बड़े अकाउंट के उपयोगकर्ता पिछली क्रेडिट लागत पर बने रहे।
क्या हुआ
प्राइसिंग बदलाव लागू करने वाली जॉब ने हार्ड-कोडेड सीमा के कारण सबसे बड़े अकाउंट को छोड़ दिया, फिर “completed” रिपोर्ट किया। इस छूट को info के रूप में लॉग किया गया, इसलिए उस ग्राहक के उपयोगकर्ता पुरानी क्रेडिट लागत चुकाते रहे।
जाँच कैसे करें
सीमा और छोड़े गए अकाउंट के हैंडलिंग की समीक्षा करें, छूटे हुए अकाउंट के लिए अपडेट फिर से चलाएँ, और पूर्णता दर्ज करने से पहले लागू की गई कीमतों की पुष्टि करें।
रीट्राई की बाढ़
एक ही ऑपरेशन कम अंतराल पर बार-बार रीट्राई होता है।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (छूटा हुआ, डुप्लिकेट, अटका हुआ या खाली शेड्यूल किया गया काम।)
जॉब कम अंतराल पर रीट्राई हो रही है
स्थिति: खुली
विवरण
एक बैकग्राउंड वर्कर प्रगति किए बिना उन्हीं विफल रिकॉर्ड को बार-बार रीट्राई कर रहा है, जिससे अन्य जॉब के लिए आवश्यक क्षमता खर्च हो रही है।
क्या हुआ
एक जॉब हर प्रभावित रिकॉर्ड पर कम अंतराल में 30 बार प्रयास करती है। प्रयासों के बीच त्रुटि और इनपुट अपरिवर्तित रहते हैं, और देरी भी नहीं बढ़ती। बार-बार की विफलताएँ वर्कर को व्यस्त रखती हैं, जिससे स्वतंत्र रिकॉर्ड आगे नहीं बढ़ पाते और अवरुद्ध काम सामने नहीं आता।
जाँच कैसे करें
बार-बार आने वाली त्रुटि को अस्थायी या स्थायी के रूप में वर्गीकृत करें, सीमित बैकऑफ़ लागू करें, और जिन रिकॉर्ड के प्रयास समाप्त हो गए हैं उन्हें समीक्षा योग्य विफल स्थिति में भेजें।
सहसंबंध टूटना
दो सेवाएँ, जो सामान्यतः साथ-साथ चलती हैं, अलग-अलग दिशा में जाने लगती हैं।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (छूटा हुआ, डुप्लिकेट, अटका हुआ या खाली शेड्यूल किया गया काम।)
वर्कर काम पूरा नहीं कर पा रहे
स्थिति: खुली
विवरण
API ट्रैफ़िक बढ़ रहा है, लेकिन वर्कर पूर्णताओं में उसी अनुपात में वृद्धि नहीं हो रही। इससे संकेत मिलता है कि स्वीकार किया गया काम अब कतार तक नहीं पहुँच रहा या वहाँ से बाहर नहीं निकल रहा।
क्या हुआ
API अनुरोध स्वीकार करना जारी रखता है, जबकि पूरी हुई वर्कर जॉब की संख्या स्थिर रहती है। पहले दोनों संख्याएँ साथ-साथ बढ़ती थीं। इस अंतर का अर्थ है कि सफल API प्रतिक्रियाएँ अब यह साबित नहीं करतीं कि अनुरोधित बैकग्राउंड काम पूरा हुआ, और उनके बीच कतार या डिस्पैच की विफलता छिपी हो सकती है।
जाँच कैसे करें
काम को रीप्ले करने या स्केल करने से पहले, जॉब ID के अनुसार स्वीकार किए गए, कतार में डाले गए, शुरू किए गए और पूरे हुए काम की संख्याओं की तुलना करके टूटे हुए चरण का पता लगाएँ।
नया इवेंट
ऐसी इवेंट किस्म जो पहले कभी दिखाई नहीं दी।
समस्या का प्रकार: रिग्रेशन (किसी खास डिप्लॉय या कॉन्फ़िगरेशन बदलाव से व्यवहार टूटना।)
डिप्लॉय के बाद ड्राफ़्ट सेव नहीं हुए
स्थिति: खुली
विवरण
रिलीज़ के बाद नया सेव पथ लॉक किए गए ड्राफ़्ट को छोड़ रहा है, जिससे उपयोगकर्ताओं के संपादन बिना अपवाद उठाए लागू नहीं हो रहे।
क्या हुआ
“skipping save, draft locked” संदेश पहली बार डिप्लॉय के बाद दिखाई देता है। प्रभावित अनुरोध सामान्य पर्सिस्ट किए गए ड्राफ़्ट इवेंट के बिना लौटते हैं, जबकि बाद में पढ़ने पर पिछला संशोधन ही दिखता है। नई ब्रांच केवल डायग्नोस्टिक लॉगिंग नहीं जोड़ रही, बल्कि सेव को रोक रही है।
जाँच कैसे करें
रिलीज़ में जोड़ी गई लॉक जाँच की समीक्षा करें, पुराने लॉक की सफ़ाई की जाँच करें, और पुष्टि करें कि अस्वीकृत सेव की सूचना उपयोगकर्ता को स्पष्ट रूप से दी जाती है।
उपयोगकर्ता व्यवहार
कार्रवाई का कोई असर नहीं
क्लिक के बाद कोई सर्वर अनुरोध नहीं, या अनुरोध के बाद कोई पर्सिस्ट किया गया परिणाम नहीं।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्प्रभावी कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
स्क्रीन कनेक्ट हुई, टोकन नहीं
स्थिति: खुली
विवरण
अकाउंट कनेक्शन फ़्लो ने सफलता दिखाई, जबकि उसका OAuth टोकन कभी पर्सिस्ट नहीं हुआ। इससे कनेक्शन ऑथेंटिकेट नहीं कर सका।
क्या हुआ
अकाउंट कनेक्ट करने वाले उपयोगकर्ता को “connected” दिखा, लेकिन OAuth टोकन कभी सेव नहीं हुआ। डुप्लिकेट कॉलबैक ने उन्हें सफलता पेज पर भेज दिया, जबकि मूल अनुरोध बैकग्राउंड में विफल हो गया।
जाँच कैसे करें
मूल और डुप्लिकेट कॉलबैक के परिणामों को साथ में जाँचें। कनेक्शन की सफलता तभी दिखाएँ जब टोकन स्टोर हो जाए, फिर प्रभावित अकाउंट दोबारा कनेक्ट करें।
झुंझलाहट में बार-बार क्लिक
एक ही कंट्रोल पर बार-बार क्लिक किया जाता है।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्प्रभावी कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
उपयोगकर्ता Save पर बार-बार क्लिक कर रहे हैं
स्थिति: खुली
विवरण उपयोगकर्ता बार-बार Save दबाते हैं, क्योंकि फ़ॉर्म यह पुष्टि नहीं करता कि उनके बदलाव स्वीकार किए गए हैं या नहीं। इससे वे दोबारा प्रयास करते हैं और काम की नकल हो सकती है।
क्या हुआ
एक ही सत्र में दस सेकंड के भीतर उसी नियंत्रण पर पाँच बार क्लिक किया जाता है। पहला अनुरोध लंबित रहता है, जबकि बाद के क्लिक और अनुरोध शुरू कर देते हैं। फ़ॉर्म की जगह सफलता या विफलता की कोई स्थिति नहीं दिखती। यह इंटरैक्शन पैटर्न अटके हुए सेव या फ़ीडबैक की कमी का संकेत देता है।
जाँच कैसे करें
पहले सेव अनुरोध का पता लगाएँ, उसकी लंबित और विफलता स्थितियाँ दिखाएँ, और यह जाँचते हुए कि दोबारा प्रयास सुरक्षित रहें, डुप्लिकेट सबमिशन रोकें।
फ़नल में गिरावट
एक चरण से अगले चरण तक रूपांतरण घटता है।
समस्या का प्रकार: व्यावसायिक प्रवाह में रुकावट (तकनीकी कारण से किसी प्रमुख मेट्रिक में गिरावट।)
साइनअप पूरा होने की दर 50% तक गिर गई
स्थिति: खुला
विवरण
साइनअप शुरू करने वाले लोगों की संख्या, इसे पूरा करने वालों से अधिक है। यह कमी फ़ॉर्म सबमिट करने और खाता बनाने के बीच केंद्रित है।
क्या हुआ
शुरू किए गए सत्रों की संख्या लगभग समान रहते हुए साइनअप पूरा होने की दर 80% से गिरकर 50% हो जाती है। सत्र सबमिशन चरण तक पहुँचते हैं, लेकिन उनमें खाता बनाए जाने का इवेंट नहीं होता। यह गिरावट अधूरे ऑनबोर्डिंग को दर्शाती है, न कि केवल साइट पर पहुँचने वाले कम विज़िटर को।
जाँच कैसे करें
पहले छूटे हुए चरण पर विफल और सफल साइनअप ट्रेस की तुलना करें, फिर सत्यापन के नतीजे, क्लाइंट संस्करण और पहचान प्रदाता के आधार पर उन्हें अलग-अलग देखें।
नेविगेशन लूप
उपयोगकर्ता उन्हीं पेजों के बीच आते-जाते रहते हैं।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्क्रिय कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत नतीजे, अटकी हुई स्थितियाँ।)
उपयोगकर्ता सेटिंग और बिलिंग के बीच फँसे हैं
स्थिति: खुला
विवरण
उपयोगकर्ताओं को सेटिंग और बिलिंग के बीच बार-बार भेजा जा रहा है, और वे अपना काम पूरा करने के लिए ज़रूरी स्क्रीन तक नहीं पहुँच पा रहे हैं।
क्या हुआ
सत्रों में बार-बार settings → billing → settings का क्रम दिखता है, और बीच में पूर्णता का कोई इवेंट नहीं होता। हर गंतव्य, खाते की स्थिति की अलग-अलग जाँच के आधार पर उपयोगकर्ता को वापस भेजता है। दोनों रूट सफल प्रतिक्रियाएँ लौटाते हैं, फिर भी यह लूप बिलिंग नियंत्रणों तक पहुँच रोकता है।
जाँच कैसे करें
दोनों रूट द्वारा उपयोग की जाने वाली पहुँच शर्तों और खाते की स्थिति की तुलना करें। परस्पर विरोधी रीडायरेक्ट ठीक करें और प्रभावित सत्र से यात्रा की पुष्टि करें।
आगे बढ़ने का रास्ता बंद
सत्र त्रुटि स्थितियों, खाली स्क्रीन या अंतहीन स्पिनर पर समाप्त होते हैं।
समस्या का प्रकार: फ़्रंटएंड में खराबी (किसी खास ब्राउज़र, डिवाइस या ऐप संस्करण में काम नहीं करता।)
डैशबोर्ड का स्पिनर कभी बंद नहीं होता
स्थिति: खुला
विवरण
डैशबोर्ड उपयोगकर्ताओं के जाने तक लोडिंग स्थिति में रहता है। इस तरह उपयोगी सामग्री या त्रुटि दिखाने के बजाय अटके हुए अनुरोध को छिपा देता है।
क्या हुआ
टैब बंद होने से पहले सत्रों में डैशबोर्ड का स्पिनर 30 सेकंड से अधिक समय तक दिखता है। शुरुआती डेटा अनुरोध से रेंडर की गई सफलता या विफलता की स्थिति कभी नहीं मिलती। पेज की अन्य एसेट सामान्य रूप से लोड होती हैं, जिससे समस्या पूरे पेज की अनुपलब्धता के बजाय डेटा लोड करने के पथ तक सीमित होती है।
जाँच कैसे करें
लंबित अनुरोध और कंपोनेंट के एरर बाउंड्री की जाँच करें, ऐसी टाइमआउट स्थिति जोड़ें जिससे उपयोगकर्ता उबर सके, और पुष्टि करें कि लोड विफल होने पर उपयोगकर्ता दोबारा प्रयास कर सकता है।
क्लाइंट त्रुटियाँ
JavaScript अपवाद, विफल fetches, hydration त्रुटियाँ।
रिलीज़ के बाद नया TypeError
स्थिति: खुला
विवरण
हाल ही में रिलीज़ किया गया पेज रेंडरिंग के दौरान TypeError देता है, जिससे प्रभावित उपयोगकर्ता उसकी सामग्री तक नहीं पहुँच पाते।
क्या हुआ
यह अपवाद पहली बार नई रिलीज़ का उपयोग करने वाले सत्रों में दिखता है और सभी में स्टैक का एक ही स्थान होता है। पेज रेंडर होने से पहले विफल कोड, अनुपस्थित response object की प्रॉपर्टी पढ़ता है। नेटवर्क स्तर पर अनुरोध सफल हो सकते हैं, फिर भी इंटरफ़ेस उनका नतीजा दिखाने में विफल रहता है।
जाँच कैसे करें
स्टैक को रिलीज़ किए गए सोर्स से जोड़ें, प्रभावित सत्रों में response का आकार जाँचें, और रेंडरिंग से पहले अनुपस्थित मान को संभालें।
Web vitals में गिरावट
पेज लोड और प्रतिक्रिया की गति खराब हो जाती है।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे हो जाते हैं—अचानक या धीरे-धीरे।)
इंटरैक्शन लेटेंसी दोगुनी हो गई
स्थिति: खुला
विवरण
एक पेज पर इंटरैक्शन के बाद दृश्य प्रतिक्रिया मिलने में काफ़ी अधिक समय लगता है, जबकि सर्वर सामान्य रूप से जवाब देता रहता है।
क्या हुआ
पेज पर इंटरैक्शन लेटेंसी, उसके पहले के आधार स्तर की तुलना में दोगुनी हो जाती है। ब्राउज़र ट्रेस के अनुसार, उपयोगकर्ता के इनपुट के बाद मुख्य थ्रेड पर लंबे समय तक काम होने से अतिरिक्त प्रतीक्षा होती है, जबकि नेटवर्क का समय लगभग समान रहता है। उपयोगकर्ताओं को इंटरफ़ेस में देरी महसूस होती है, लेकिन इसके साथ API त्रुटि या लेटेंसी में उछाल नहीं होता।
जाँच कैसे करें
इनपुट के बाद चलने वाले लंबे टास्क की प्रोफ़ाइल बनाएँ, बदले हुए रेंडर पथ की तुलना करें, और प्रतिक्रिया की गति फिर से मापने से पहले सिंक्रोनस काम को कहीं और ले जाएँ या कम करें।
सेगमेंट-विशिष्ट व्यवहार
केवल एक ब्राउज़र, OS, ऐप संस्करण, क्षेत्र या ग्राहक प्रभावित होता है।
समस्या का प्रकार: फ़्रंटएंड में खराबी (किसी खास ब्राउज़र, डिवाइस या ऐप संस्करण में काम नहीं करता।)
Safari 18 पर चेकआउट विफल
स्थिति: खुला
विवरण
Safari 18 सत्रों में चेकआउट विफल होता है, जबकि अन्य ब्राउज़र में वही प्रवाह पूरा हो जाता है। इससे समग्र सफलता दर में यह गिरावट छिप जाती है।
क्या हुआ
विफल चेकआउट सत्र मुख्यतः Safari 18 में केंद्रित हैं। उनके क्लाइंट ट्रेस भुगतान अनुरोध से पहले ही रुक जाते हैं, जबकि अन्य ब्राउज़र में वही कार्ट भुगतान तक पहुँचता है। ब्राउज़र-विशिष्ट यह समस्या खरीदारी रोकती है, लेकिन भुगतान प्रदाता की कोई संबंधित विफलता नहीं होती।
जाँच कैसे करें
Safari 18 में विफल इंटरैक्शन को दोहराएँ, ब्राउज़र API की अनुकूलता और क्लाइंट अपवादों की जाँच करें, फिर काम करने वाले ब्राउज़र पर सुधार की पुष्टि करें।
डिप्लॉय और कॉन्फ़िगरेशन
डिप्लॉय के बाद बदलाव
कोई भी अन्य संकेत जो डिप्लॉय के कुछ ही मिनटों में शुरू हो और कमिट से जुड़ा हो।
समस्या का प्रकार: रिग्रेशन (किसी खास डिप्लॉय या कॉन्फ़िगरेशन बदलाव से व्यवहार बिगड़ गया।)
रिलीज़ के तुरंत बाद फ़नल में गिरावट
स्थिति: खुला
विवरण
रिलीज़ के साथ उपयोगकर्ता यात्राएँ पूरी करने वालों की संख्या घटती है और अस्वीकृति का एक नया इवेंट दिखता है। इससे रिग्रेशन का संबंध बदले हुए अनुरोध पथ से जुड़ता है।
क्या हुआ
रिलीज़ के चार मिनट बाद, पहले कभी न देखा गया सत्यापन इवेंट दिखता है और फ़नल पूरा होने की दर गिर जाती है। विफल सत्र एक ही चरण तक पहुँचते हैं और उनमें नया बिल्ड आइडेंटिफ़ायर होता है; पिछले बिल्ड वाले सत्र अब भी पूरे होते हैं। यह तुलना बताती है कि जाँच के लिए रिलीज़ किया गया पथ अगली जगह है।
जाँच कैसे करें
दोनों बिल्ड में सत्यापन और प्रतिक्रिया संभालने के तरीके की तुलना करें। प्रभावित इनपुट को दोहराएँ और बदलाव को अलग रखते हुए रोलबैक पर विचार करें।
कॉन्फ़िगरेशन या फ़्लैग में बदलाव
फ़ीचर फ़्लैग, पर्यावरण वेरिएबल या इन्फ़्रा में बदलाव के बाद व्यवहार बदलता है।
समस्या का प्रकार: रिग्रेशन (किसी खास डिप्लॉय या कॉन्फ़िगरेशन बदलाव से व्यवहार बिगड़ गया।)
फ़्लैग रोलआउट से सेव विफल
स्थिति: खुला
विवरण
आंशिक रूप से सक्षम फ़ीचर फ़्लैग, कुछ सेव को विफल पथ से भेज रहा है, जबकि बाकी ट्रैफ़िक सामान्य रूप से चलता रहता है।
क्या हुआ
फ़्लैग 10% ट्रैफ़िक के लिए सक्षम है और विफल सेव भी उतने ही हिस्से में होते हैं। विफलता रिकॉर्ड सक्षम समूह के हैं; अक्षम समूह में बदलाव अब भी सहेजे जाते हैं। रोलआउट की सीमा रिग्रेशन का पता लगाने के लिए सीधी तुलना उपलब्ध कराती है।
जाँच कैसे करें
प्रभावित फ़्लैग समूह को अक्षम करें, दोनों सेव पथों की तुलना करें, और रोलआउट फिर से बढ़ाने से पहले सहेजे गए नतीजों की पुष्टि करें।
डिपेंडेंसी में बदलाव
अपग्रेड किया गया पैकेज नए व्यवहार के साथ मेल खाता है।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे हो जाते हैं—अचानक या धीरे-धीरे।)
ORM अपग्रेड के बाद क्वेरी धीमी
स्थिति: खुला
विवरण
ORM अपग्रेड से आम तौर पर की जाने वाली रीड का निष्पादन बदल जाता है। इससे उपयोगकर्ताओं द्वारा माँगे गए डेटा की मात्रा बदले बिना अनुरोध धीमे हो जाते हैं।
क्या हुआ
धीमी क्वेरी के रिकॉर्ड अपग्रेड किए गए बिल्ड के साथ शुरू होते हैं और एक जनरेट की गई क्वेरी के आसपास केंद्रित हैं। पिछले संस्करण में उसी इनपुट के लिए क्वेरी का आकार अलग था, जबकि अनुरोधों की संख्या लगभग समान रहती है। डिपेंडेंसी में बदलाव नए डेटाबेस कार्य का संभावित कारण है।
जाँच कैसे करें
ORM संस्करणों के बीच जनरेट किए गए SQL और क्वेरी प्लान की तुलना करें, लोडिंग व्यवहार में हुए बदलाव की जाँच करें, और सुधारी गई क्वेरी या डिपेंडेंसी रोलबैक का परीक्षण करें।
जोड़ी गई त्रुटि-दमन व्यवस्था
किसी कमिट में महत्वपूर्ण पथ पर सभी त्रुटियों को पकड़ने वाला हैंडलिंग जोड़ा जाता है।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्क्रिय कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत नतीजे, अटकी हुई स्थितियाँ।)
कंट्रोलर हर अपवाद छिपाता है
स्थिति: खुला
विवरण
अब एक कंट्रोलर विफल ऑपरेशन को सफल प्रतिक्रियाओं में बदल देता है। इससे कॉलर और त्रुटि मॉनिटरिंग यह पहचान नहीं पाते कि काम पूरा नहीं हुआ।
क्या हुआ
बदला हुआ कंट्रोलर अपने मुख्य ऑपरेशन को सभी त्रुटियाँ पकड़ने वाले हैंडलर में लपेटता है, जो सफलता लौटाता है। अनुरोध ट्रेस में प्रतिक्रिया से पहले अपवाद दिखता है, लेकिन उससे जुड़ा कोई सहेजा गया नतीजा नहीं होता। नया हैंडलर विफलताओं से उबरने के बजाय उन्हें छिपाता है, इसलिए उपयोगकर्ताओं के बदलाव खो सकते हैं और उन्हें त्रुटि भी नहीं दिखती।
जाँच कैसे करें
सभी त्रुटियाँ पकड़ने वाली शाखा की समीक्षा करें, असफल ऑपरेशन के लिए विफलता प्रतिक्रियाएँ बनाए रखें, और पुष्टि करें कि सफलता केवल लिखने का काम पूरा होने के बाद ही लौटाई जाती है।
माइग्रेशन का प्रभाव
स्कीमा माइग्रेशन से क्वेरी का व्यवहार बदलता है।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे हो जाते हैं—अचानक या धीरे-धीरे।)
माइग्रेशन के बाद क्वेरी 20x धीमी
स्थिति: खुला
विवरण
स्कीमा माइग्रेशन से बार-बार की जाने वाली क्वेरी में इस्तेमाल होने वाला इंडेक्स हट जाता है। इससे क्वेरी का निष्पादन समय बढ़ता है और उस पर निर्भर अनुरोध धीमे हो जाते हैं।
क्या हुआ
प्रभावित क्वेरी, माइग्रेशन के बाद 20 गुना अधिक समय लेती है। अनुरोध का आकार बदले बिना उसका प्लान इंडेक्स से खोजने के बजाय व्यापक स्कैन करने लगता है। इंडेक्स न होने से हर अनुरोध को कहीं अधिक पंक्तियाँ जाँचनी पड़ती हैं और सामान्य ट्रैफ़िक में डेटाबेस का काम बढ़ जाता है।
जाँच कैसे करें
माइग्रेशन और क्वेरी प्लान की तुलना करें, आवश्यक इंडेक्स के आकार की पुष्टि करें, और डेटाबेस की सुरक्षित माइग्रेशन प्रक्रिया का उपयोग करके उपयुक्त इंडेक्स फिर से बनाएँ।
प्रदर्शन
लेटेंसी में अचानक बदलाव
अचानक उछाल।
समस्या का प्रकार: रिग्रेशन (किसी खास डिप्लॉय या कॉन्फ़िगरेशन बदलाव से व्यवहार बिगड़ गया।)
पेज लोड बढ़कर 1.2s हो गया
स्थिति: खुला
विवरण
डिप्लॉय के तुरंत बाद पेज लोड चार गुना धीमा हो गया, जिससे अन्यथा सफल उपयोगकर्ता प्रवाह में स्पष्ट प्रतीक्षा जुड़ गई।
क्या हुआ
डिप्लॉय के बाद पेज लोड की अवधि 300ms से बढ़कर 1.2s हो जाती है। अनुरोध ट्रेस में यह बढ़ोतरी एसेट डाउनलोड के बजाय सर्वर-साइड डेटा लोडिंग स्पैन में दिखती है। प्रतिक्रियाएँ अब भी सफल होती हैं, इसलिए केवल त्रुटियों की संख्या से धीमे अनुभव का पता नहीं चलता।
जाँच कैसे करें
डिप्लॉय के दोनों ओर डेटा लोड करने वाले कोड और क्वेरी के समय की तुलना करें, फिर उसी अनुरोध इनपुट से धीमे पथ की पुष्टि करें।
लेटेंसी में धीरे-धीरे बढ़ोतरी
दिनों या हफ़्तों में होने वाली धीमी बढ़ोतरी, जिस पर किसी का ध्यान नहीं जाता।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे हो जाते हैं—अचानक या धीरे-धीरे।)
हर हफ़्ते धीमी होती खोज
स्थिति: खुला
विवरण
खोज थोड़ी-थोड़ी धीमी होती जा रही है। इससे उपयोगकर्ताओं को महसूस होने वाली देरी बढ़ती जाती है, लेकिन यह किसी एक घटना के उछाल के रूप में नहीं दिखती।
क्या हुआ
तुलनीय खोजों में हर हफ़्ते लगभग 5% अधिक समय लगता है। अनुरोधों की संख्या को ध्यान में रखने के बाद भी यह बढ़ोतरी बनी रहती है और प्रतिक्रिया भेजने के बजाय डेटा खोजने में केंद्रित है। हर क्वेरी में बढ़ता काम इसका संभावित कारण है, भले ही कोई एक डिप्लॉय इस रुझान को न समझाता हो।
जाँच कैसे करें
आधार अवधि के दौरान क्वेरी प्लान, जाँची गई पंक्तियों और इंडेक्स के आकार की तुलना करें। देखें कि डेटा बढ़ने से आम खोज पथ की लागत तो नहीं बदली है।
टेल लेटेंसी
केवल सबसे धीमे अनुरोध और धीमे होते हैं।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे हो जाते हैं—अचानक या धीरे-धीरे।)
p99 लेटेंसी तीन गुना हो गई
स्थिति: खुला
विवरण
सबसे धीमे अनुरोधों में काफ़ी अधिक समय लग रहा है, जबकि सामान्य अनुरोध तेज़ बने हुए हैं। इससे उपयोगकर्ताओं के एक छोटे समूह का खराब अनुभव छिप जाता है।
क्या हुआ p99 विलंबता तीन गुना हो जाती है, जबकि माध्यिका स्थिर रहती है। धीमे ट्रेस में निष्पादन से पहले किसी साझा संसाधन की प्रतीक्षा में अधिकांश अतिरिक्त समय बीतता है। समग्र औसत इन प्रतीक्षाओं को छिपा देते हैं, लेकिन प्रभावित अनुरोध इतने लंबे समय तक अवरुद्ध रहते हैं कि क्लाइंट टाइमआउट का जोखिम पैदा हो जाता है।
जाँच कैसे करें
धीमे ट्रेस को संसाधन और वर्कलोड के आधार पर समूहित करें, उनके प्रतीक्षा समय की तुलना निष्पादन समय से करें, और क्षमता बढ़ाने से पहले प्रतिस्पर्धा की जाँच करें।
धीमी क्वेरी का उभरना
कोई नई धीमी क्वेरी या नया N+1 पैटर्न।
समस्या का प्रकार: प्रदर्शन में गिरावट (पेज, जॉब या API धीमे होना, अचानक या धीरे-धीरे।)
एक पेज 400 क्वेरी चला रहा है
स्थिति: खुला
विवरण
एक पेज हर दिखाई गई आइटम के लिए अलग डेटाबेस लुकअप कर रहा है, जिससे सूची बढ़ने के साथ प्रतिक्रिया समय और डेटाबेस लोड बढ़ रहा है।
क्या हुआ
एक पेज अनुरोध अब अलग-अलग रिकॉर्ड ID के साथ, एक ही स्टेटमेंट आकार वाली 400 क्वेरी चलाता है। शुरुआती सूची क्वेरी के बाद बार-बार होने वाले रीड क्रमिक रूप से होते हैं। यह N+1 पैटर्न संबंधित डेटा को एक साथ लाने के बजाय, दिखाई गई आइटम की संख्या के अनुपात में काम बढ़ाता है।
जाँच कैसे करें
हर आइटम के लुकअप का पता लगाएँ, संबंधित रीड को बैच में करें या जॉइन करें, और किसी प्रतिनिधि सूची के साथ क्वेरी की संख्या तथा प्रतिक्रिया समय की तुलना करें।
बूट और कोल्ड-स्टार्ट में बढ़ोतरी
सेवाएँ शुरू होने में अधिक समय लेती हैं।
समस्या का प्रकार: क्षमता जोखिम (सीमा तक पहुँचने से पहले की चेतावनी।)
डिप्लॉयमेंट को स्वस्थ होने में अधिक समय लगना
स्थिति: खुला
विवरण
नए इंस्टेंस तैयार होने में अधिक समय लेते हैं, जिससे डिप्लॉयमेंट धीमे होते हैं और अतिरिक्त माँग का जवाब देने की सेवा की क्षमता घटती है।
क्या हुआ
प्रोसेस शुरू होने से लेकर स्वस्थ स्थिति में तैयार होने तक का समय अपने पिछले आधार-स्तर से तीन गुना है। स्टार्टअप लॉग में दिखता है कि इनिशियलाइज़ेशन पूरा होने से पहले अतिरिक्त देरी होती है, जबकि स्थिर अवस्था में अनुरोध विलंबता समान रहती है। इसलिए रोलआउट और स्केल-आउट उपयोग योग्य क्षमता की प्रतीक्षा में अधिक समय बिताते हैं।
जाँच कैसे करें
स्टार्टअप को निर्भरता लोड करने, इनिशियलाइज़ेशन और तत्परता जाँचों में बाँटें, हर चरण की तुलना पिछले बिल्ड से करें, और तत्परता पथ से अनावश्यक काम हटाएँ।
कतार में प्रतीक्षा बढ़ना
काम शुरू होने से पहले अधिक समय तक प्रतीक्षा करता है।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (निर्धारित काम छूटना, दोहराया जाना, अटकना या खाली होना।)
ईमेल 20 मिनट की देरी से भेजे जा रहे हैं
स्थिति: खुला
विवरण
ईमेल जॉब निष्पादन से काफी पहले कतार में प्रतीक्षा कर रहे हैं, जिससे संदेशों में देरी हो रही है, जबकि डिलीवरी स्वयं अब भी सफल होती है।
क्या हुआ
ईमेल ट्रिगर और भेजने के प्रयास के बीच का अंतर 20 मिनट तक बढ़ जाता है। वर्कर के जॉब शुरू करने के बाद, प्रोसेसिंग और प्रदाता की प्रतिक्रिया का समय सामान्य रहता है। देरी निष्पादन से पहले होती है, इसलिए केवल सफल डिलीवरी की गिनती से यह पता नहीं चलता कि संदेश देर से पहुँच रहे हैं।
जाँच कैसे करें
कतार की आयु, वर्कर की समवर्ती क्षमता और प्रतिस्पर्धी जॉब प्रकारों की तुलना करें। सुरक्षित रीट्राई व्यवहार बनाए रखते हुए बाधा हटाएँ या अत्यावश्यक मेल को अलग करें।
इन्फ्रास्ट्रक्चर
किसी सीमा के करीब पहुँचना
क्लाउड कोटा, बर्स्ट क्रेडिट, API दर सीमाएँ, फ़ाइल हैंडल, प्लान सीमाएँ।
समस्या का प्रकार: क्षमता जोखिम (सीमा तक पहुँचने से पहले की चेतावनी।)
बर्स्ट क्रेडिट समाप्त हो रहे हैं
स्थिति: खुला
विवरण
फ़ाइल सिस्टम के बर्स्ट क्रेडिट उनके रिकवर होने की गति से अधिक तेज़ी से खर्च हो रहे हैं, जिससे स्टार्टअप और अन्य स्टोरेज-भारी कामों पर थ्रॉटलिंग का जोखिम है।
क्या हुआ
लगातार अंतरालों में क्रेडिट बैलेंस घटता है, क्योंकि रीड प्रोविज़न किए गए आधार-स्तर से अधिक हैं। नए इंस्टेंस का स्टार्टअप इन रीड के साथ ओवरलैप करता है और उपलब्ध थ्रूपुट के प्रति संवेदनशील है। यह रुझान सीमित बची हुई बर्स्ट क्षमता दर्शाता है, न कि यह साबित करता है कि वॉल्यूम पहले ही थ्रॉटल हो चुका है।
जाँच कैसे करें
स्टोरेज थ्रूपुट की उसके आधार-स्तर और क्रेडिट रिकवरी दर से तुलना करें, प्रमुख रीड करने वालों की पहचान करें, और क्रेडिट समाप्त होने से पहले प्रोविज़निंग या स्टार्टअप I/O समायोजित करें।
संतृप्ति
CPU, मेमोरी, कनेक्शन पूल, थ्रेड पूल, डिस्क।
समस्या का प्रकार: क्षमता जोखिम (सीमा तक पहुँचने से पहले की चेतावनी।)
कनेक्शन पूल लगभग भर चुका है
स्थिति: खुला
विवरण
ट्रैफ़िक के चरम समय में डेटाबेस कनेक्शन पूल में बहुत कम अतिरिक्त क्षमता बचती है, जिससे अनुरोधों को क्वेरी निष्पादित करने से पहले प्रतीक्षा करनी पड़ती है।
क्या हुआ
चरम लोड पर पूल का उपयोग 95% तक पहुँच जाता है और कनेक्शन प्राप्त करने की प्रतीक्षा भी इसके साथ बढ़ती है। कनेक्शन उपलब्ध होने के बाद क्वेरी निष्पादन का समय तुलनात्मक रूप से स्थिर रहता है। प्रतिस्पर्धा पूल की सीमा पर है और सामान्य अनुरोध उछाल को टाइमआउट में बदल सकती है।
जाँच कैसे करें
लंबे समय तक रोके गए कनेक्शन और ट्रांज़ैक्शन की अवधि की जाँच करें, डेटाबेस की क्षमता देखें, और पूल की सीमा बढ़ाने से पहले कनेक्शन को अनावश्यक रूप से रोके रखने की समस्या ठीक करें।
बैकलॉग बढ़ना
कतार का काम उसके खाली होने की गति से तेज़ी से बढ़ रहा है।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (निर्धारित काम छूटना, दोहराया जाना, अटकना या खाली होना।)
जॉब कतार 6 घंटे से बढ़ रही है
स्थिति: खुला
विवरण
आने वाले जॉब पूरे होने वाले जॉब से अधिक हैं, जिससे प्रोसेसिंग की प्रतीक्षा कर रहे स्वीकार किए गए काम की मात्रा लगातार बढ़ रही है।
क्या हुआ
जॉब कतार लगातार छह घंटे तक बढ़ती है, क्योंकि एनक्यू की संख्या पूरी होने वाले जॉब की संख्या से अधिक रहती है। वर्कर सक्रिय होने के बावजूद पुराने जॉब की प्रतीक्षा अवधि बढ़ती रहती है। सेवा कुछ काम प्रोसेस कर रही है, लेकिन उसका थ्रूपुट आने वाले लोड को पूरा करने के लिए पर्याप्त नहीं है।
जाँच कैसे करें
जॉब प्रकार के अनुसार आने और पूरे होने की दरों की तुलना करें, धीमे या रीट्राई हो रहे काम की पहचान करें, और सबसे पुराने बैकलॉग को खाली करने के लिए पर्याप्त प्रोसेसिंग क्षमता बहाल करें।
निर्धारित रन छूटना
क्रॉन जॉब नहीं चला, दो बार चला या लंबे समय तक चला।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (निर्धारित काम छूटना, दोहराया जाना, अटकना या खाली होना।)
रात का एक्सपोर्ट छूट गया
स्थिति: खुला
विवरण
निर्धारित एक्सपोर्ट शुरू नहीं हुआ, जिससे डाउनस्ट्रीम उपभोक्ताओं को उस रन से सामान्यतः मिलने वाला ताज़ा डेटा नहीं मिला।
क्या हुआ
रविवार के रात वाले एक्सपोर्ट का कोई प्रारंभ या पूर्णता रिकॉर्ड नहीं है, जबकि उससे पहले और बाद के निर्धारित रन मौजूद हैं। उस निर्धारित अंतराल का आउटपुट भी नहीं है। यह अंतर किसी छूटे हुए ट्रिगर या काम स्वीकार न किए जाने से मेल खाता है, न कि ऐसे जॉब से जो चला और त्रुटि के साथ लौटा।
जाँच कैसे करें
शेड्यूलर का निष्पादन, टाइमज़ोन हैंडलिंग और ओवरलैप लॉक जाँचें, फिर यह पुष्टि करने के बाद छूटे हुए अंतराल को बैकफ़िल करें कि रीप्ले से एक्सपोर्ट दोहराए नहीं जाएँगे।
क्रैश लूप
रीस्टार्ट, आउट-ऑफ़-मेमोरी किल, विफल हेल्थ चेक।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (निर्धारित काम छूटना, दोहराया जाना, अटकना या खाली होना।)
वर्कर हर 12 मिनट में रीस्टार्ट हो रहा है
स्थिति: खुला
विवरण
एक वर्कर सामान्य प्रोसेसिंग जारी रखने से पहले बार-बार रीस्टार्ट हो रहा है, जिससे चल रहे जॉब बाधित होते हैं और कतार में मौजूद काम में देरी होती है।
क्या हुआ
वर्कर शुरू होता है, जॉब प्रोसेस करता है और लगभग हर 12 मिनट में बाहर निकल जाता है। हर रीस्टार्ट पर मौजूदा प्रोसेस की स्थिति खो जाती है और अधूरे काम फिर से डिलीवर किए जाते हैं। यह पैटर्न बार-बार होने वाली प्रोसेस विफलता दर्शाता है, लेकिन बाहर निकलने का कारण जानने के लिए क्रैश, संसाधन द्वारा किल और विफल हेल्थ चेक में अंतर करना होगा।
जाँच कैसे करें
हर रीस्टार्ट के आसपास एग्ज़िट कोड, मेमोरी उपयोग और हेल्थ-चेक इवेंट की जाँच करें। विफलता ठीक करें और सत्यापित करें कि बाधित जॉब बिना दोहरे साइड इफ़ेक्ट के फिर से शुरू हों।
समाप्ति निकट है
सर्टिफ़िकेट, डोमेन, API टोकन, OAuth ग्रांट।
समस्या का प्रकार: क्षमता जोखिम (सीमा तक पहुँचने से पहले की चेतावनी।)
TLS सर्टिफ़िकेट की अवधि समाप्त होने वाली है
स्थिति: खुला
विवरण
सक्रिय सर्विंग पथ में मौजूद एक सर्टिफ़िकेट की अवधि समाप्त होने वाली है, लेकिन ऐसा कोई प्रमाण नहीं है कि उसका प्रतिस्थापन इंस्टॉल किया गया है।
क्या हुआ
एंडपॉइंट द्वारा दिया गया TLS सर्टिफ़िकेट छह दिनों में समाप्त हो जाएगा। बार-बार की गई जाँचों में अब भी वही सर्टिफ़िकेट मिलता है, इसलिए नवीनीकरण अभी सर्विंग लेयर तक नहीं पहुँचा है। अभी कनेक्शन काम कर रहे हैं, लेकिन यदि वह सर्टिफ़िकेट अपनी वैधता अवधि के बाद भी सक्रिय रहा तो कनेक्शन का सत्यापन विफल हो जाएगा।
जाँच कैसे करें
नवीनीकरण ऑटोमेशन और सर्टिफ़िकेट डिप्लॉयमेंट जाँचें, प्रतिस्थापन इंस्टॉल करें, और सत्यापित करें कि क्लाइंट को वास्तव में कौन-सा सर्टिफ़िकेट दिया जा रहा है।
क्लाउड प्रदाता की त्रुटियाँ
AWS या GCP API से थ्रॉटलिंग या त्रुटियाँ।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या बदल गई है।)
S3 अपलोड धीमे कर रहा है
स्थिति: खुला
विवरण
ऑब्जेक्ट अपलोड में स्टोरेज प्रदाता के अनुरोधों को रीट्राई करने में अधिक समय लग रहा है, जिससे उपयोगकर्ता ट्रांसफ़र धीमे हो रहे हैं और अपलोड वर्कर व्यस्त हो रहे हैं।
क्या हुआ
अपलोड के दौरान S3 अनुरोधों पर SlowDown प्रतिक्रियाएँ मिलती हैं, जिसके बाद उन्हीं ऑब्जेक्ट के लिए बार-बार प्रयास किए जाते हैं। अतिरिक्त समय स्थानीय फ़ाइल प्रोसेसिंग के बजाय स्टोरेज रीट्राई में लगता है। अंततः सफल प्रतिक्रियाएँ अपलोड पथ में लगे अतिरिक्त समय और संसाधनों को छिपा सकती हैं।
जाँच कैसे करें
अनुरोधों की समवर्ती संख्या और रीट्राई बैकऑफ़ की समीक्षा करें, प्रभावित ऑब्जेक्ट प्रीफ़िक्स की तुलना करें, और पुष्टि करें कि थ्रॉटल किए गए अपलोड पूरा हो चुका काम दोबारा शुरू किए बिना सुरक्षित रूप से आगे बढ़ते हैं।
तृतीय-पक्ष सेवाएँ
वेबहुक में अंतराल
अपेक्षित इनबाउंड वेबहुक आने बंद हो जाते हैं।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या बदल गई है।)
ईमेल डिलीवरी वेबहुक बंद हो गए
स्थिति: खुला
विवरण
ईमेल भेजे जा रहे हैं, लेकिन डिलीवरी कॉलबैक बंद हो गए हैं, इसलिए स्थानीय डिलीवरी स्थिति यह नहीं दिखा पा रही कि प्रदाता ने वास्तव में क्या किया।
क्या हुआ
एक घंटे तक कोई ईमेल डिलीवरी इवेंट नहीं आता, जबकि आउटबाउंड भेजने के अनुरोधों को अब भी प्रदाता ID मिलती हैं। यह अंतर सभी ईमेल गतिविधियों के बजाय केवल कॉलबैक तक सीमित है। संदेश डिलीवर हुए या विफल, लेकिन इनमें से कोई भी परिणाम एप्लिकेशन तक नहीं पहुँचा हो सकता है।
जाँच कैसे करें
प्रदाता के डिलीवरी रिकॉर्ड की स्थानीय वेबहुक प्राप्तियों से तुलना करें, कॉलबैक एंडपॉइंट और सिग्नेचर सत्यापन जाँचें, फिर छूटे हुए इवेंट सुरक्षित रूप से रीप्ले करें।
विक्रेता की सेवा में गिरावट
आप जिस प्रदाता पर निर्भर हैं, उससे त्रुटियाँ या विलंबता।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या बदल गई है।)
साइन-इन कोड कभी नहीं भेजे गए
स्थिति: खुला
विवरण
साइन-इन अनुरोध सफल दिखाई दिए, जबकि ईमेल प्रदाता ने उपयोगकर्ताओं के प्रमाणीकरण पूरा करने के लिए आवश्यक संदेश अस्वीकार कर दिए।
क्या हुआ
साइन-इन कोड नहीं पहुँचे, क्योंकि ईमेल प्रदाता ने भेजने वाले डोमेन को सत्यापित मानना बंद कर दिया था। भेजने का काम बैकग्राउंड टास्क के रूप में चला, इसलिए API ने फिर भी 200 लौटाया।
जाँच कैसे करें
भेजने वाले डोमेन का सत्यापन बहाल करें और बैकग्राउंड भेजने के परिणामों की जाँच करें। अस्वीकृत कोड डिलीवरी को स्पष्ट रूप से दिखाएँ; API की 200 प्रतिक्रिया को डिलीवरी का प्रमाण न मानें।
विक्रेता की दर सीमा
आपको थ्रॉटल किया जा रहा है।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या बदल गई है।)
टिकटिंग API का कोटा हर दिन समाप्त हो गया
स्थिति: खुला
विवरण
बार-बार चलने वाला टिकट क्रॉल प्रदाता का कोटा पार कर गया और अंतिम क्षेत्र को आंशिक रूप से पुराना छोड़ गया, जबकि सामान्य रूप से पूरा होने की रिपोर्ट देता रहा।
क्या हुआ
दो सप्ताह तक हर दिन एक दैनिक क्रॉल ने टिकटिंग API का कोटा पार किया—10k की सीमा के मुकाबले लगभग 10.5k अनुरोध। अंतिम क्षेत्र कभी पूरी तरह रीफ़्रेश नहीं हुआ और हर बार जॉब सामान्य रूप से समाप्त हुआ।
जाँच कैसे करें
क्षेत्रों के बीच अनुरोधों का बजट बाँटें, कोटा बहाल होने के बाद अधूरे हिस्से से फिर शुरू करें, और जब भी क्रॉल प्रदाता की सीमा पर रुक जाए तो आंशिक पूर्णता दर्ज करें।
अनुबंध में बदलाव
विक्रेता की प्रतिक्रिया का स्वरूप बदल जाता है।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या बदल गई है।)
विक्रेता का फ़ील्ड खाली आ रहा है
स्थिति: खुला
विवरण
प्रदाता की प्रतिक्रिया में अब वह फ़ील्ड नहीं आ रहा जिसकी एप्लिकेशन को आवश्यकता है, जिससे अपस्ट्रीम अनुरोध सफल होने के बावजूद प्रोसेसिंग बाधित हो रही है।
क्या हुआ
पहले भरे हुए मान अब सफल प्रदाता प्रतिक्रियाओं में खाली आ रहे हैं। एप्लिकेशन अब भी मानता है कि फ़ील्ड मौजूद है और संबंधित अपडेट पूरा नहीं कर पाता। यह बदलाव HTTP विफलता के बिना इंटीग्रेशन सीमा पार करता है, इसलिए ट्रांसपोर्ट-स्तर की निगरानी स्वस्थ बनी रहती है।
जाँच कैसे करें
कच्ची प्रतिक्रिया के स्वरूप की अपेक्षित अनुबंध और प्रदाता के बदलावों से तुलना करें, आवश्यक फ़ील्ड सत्यापित करें, और अपडेट रीट्राई करने से पहले अनुपस्थित मान को स्पष्ट रूप से संभालें।
विक्रेता की घटना से मेल
किसी प्रदाता के स्थिति पृष्ठ पर दिया गया घटना-विवरण आपकी त्रुटियों के समय से मेल खाता है।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या उसमें बदलाव हुआ है।)
लॉगिन त्रुटियाँ प्रदाता की घटना से मेल खाती हैं
स्थिति: खुली
विवरण
साइन-इन विफलताएँ किसी पहचान प्रदाता की घटना के साथ हो रही हैं, जो व्यापक एप्लिकेशन आउटेज के बजाय अपस्ट्रीम निर्भरता की समस्या का संकेत देती हैं।
क्या हुआ
लॉगिन त्रुटियाँ उसी समयावधि और क्षेत्र में शुरू होती हैं जिसका उल्लेख पहचान प्रदाता के स्थिति पृष्ठ पर है। प्रदाता के साथ आदान-प्रदान के दौरान विफलताएँ होती हैं, जबकि एप्लिकेशन के असंबंधित अनुरोध जारी रहते हैं। समय और प्रभावित निर्भरता इस संबंध का समर्थन करते हैं, लेकिन किसी अतिरिक्त स्थानीय खराबी की संभावना को खारिज नहीं करते।
जाँच कैसे करें
विफल आदान-प्रदान की तुलना प्रदाता की घटना के दायरे से करें, स्थानीय कॉन्फ़िगरेशन जाँचें, और उपयोगकर्ताओं को स्पष्ट पुनः प्रयास का विकल्प देते हुए सेवा की बहाली पर नज़र रखें।
LLM के व्यवहार में बदलाव
मॉडल के आउटपुट बदलते हैं: लंबाई, अस्वीकृतियाँ, अमान्य JSON, टोकन उपयोग।
समस्या का प्रकार: निर्भरता विफलता (कोई विक्रेता या अपस्ट्रीम सेवा खराब है या उसमें बदलाव हुआ है।)
संरचित आउटपुट 4% समय विफल
स्थिति: खुली
विवरण
मॉडल के जवाब अधिक बार संरचित-आउटपुट अनुबंध का उल्लंघन कर रहे हैं, जिससे डाउनस्ट्रीम कार्य अन्यथा सफल पूर्णताओं का उपयोग नहीं कर पा रहे हैं।
क्या हुआ
उसी सुविधा में संरचित-आउटपुट पार्सिंग विफलताएँ 0.1% से बढ़कर 4% हो जाती हैं। अमान्य जवाबों में आवश्यक फ़ील्ड नहीं होते या अपेक्षित JSON संरचना से बाहर का पाठ होता है। प्रदाता के अनुरोध फिर भी पूरे होते हैं, लेकिन एप्लिकेशन उन परिणामों का सुरक्षित रूप से उपयोग नहीं कर सकता और प्रभावित कार्यों को अस्वीकार या पुनः प्रयास करना पड़ता है।
जाँच कैसे करें
बदलाव के दौरान मॉडल संस्करण, प्रॉम्प्ट और स्कीमा सत्यापन की तुलना करें, अमान्य आउटपुट की जाँच करें, और सामान्य प्रोसेसिंग बहाल करने से पहले सीमित-आउटपुट वाले सुधार की पुष्टि करें।
डेटा अखंडता
लिखने के बाद डेटा सहेजा नहीं गया
सहेजने की पुष्टि मिलती है, लेकिन बाद में डेटा दिखाई नहीं देता।
समस्या का प्रकार: मौन विफलता (कोई सुविधा ठीक दिखती है, लेकिन काम नहीं करती: निष्क्रिय कार्रवाइयाँ, दबाए गए अपवाद, आंशिक पूर्णता, गलत परिणाम, अटकी हुई स्थितियाँ।)
CI सिंक ने कुछ भी सहेजे बिना सफलता की सूचना दी
स्थिति: खुली
विवरण
CI सिंक ने पाइपलाइनें प्राप्त करने के बाद सफलता की सूचना दी, लेकिन उनमें से कुछ भी सहेजा नहीं। इससे पुराना प्रोजेक्ट डेटा भी स्वस्थ रीफ़्रेश जैसा दिख सकता था।
क्या हुआ
CI सिंक पूरे 30 मिनट चला, हज़ारों पाइपलाइनें प्राप्त कीं, उनमें से कुछ भी सहेजे बिना सफल चिह्नित हो गया। प्रति-प्रोजेक्ट त्रुटियाँ दबा दी गईं, इसलिए सिंक इतिहास स्वस्थ दिखता रहा, जबकि डेटा पुराना होता गया।
जाँच कैसे करें
दबाई गई प्रति-प्रोजेक्ट त्रुटियों की जाँच करें, प्राप्त पाइपलाइनों का सहेजी गई पंक्तियों से मिलान करें, और प्रभावित प्रोजेक्ट को तभी दोबारा चलाएँ जब लिखे जाने की पुष्टि हो जाए।
दोहरी प्रोसेसिंग
एक ही इवेंट, जॉब या भुगतान को दो बार संभाला जाता है।
समस्या का प्रकार: डेटा अखंडता (लिखे गए डेटा का खोना, डुप्लिकेट, भ्रष्टाचार, बेमेल रिकॉर्ड।)
हर साइनअप पर दो स्वागत ईमेल
स्थिति: खुली
विवरण
हर नए खाते को दो स्वागत ईमेल मिलते हैं, क्योंकि एक ही साइनअप इवेंट से डिलीवरी एक से अधिक बार शुरू हो सकती है।
क्या हुआ
दो पूर्ण भेजने के प्रयासों में एक ही साइनअप इवेंट ID और प्राप्तकर्ता है, लेकिन डिलीवरी ID अलग-अलग हैं। दोबारा भेजा गया इवेंट स्वागत-ईमेल हैंडलर में फिर से प्रवेश करता है, जबकि डिलीवरी रोकने का कोई रिकॉर्डेड गार्ड नहीं है। दोनों प्रयास अलग-अलग सफल होने के बावजूद, उपयोगकर्ता तक दोहरा प्रभाव पहुँचता है।
जाँच कैसे करें
इवेंट के दोबारा डिलीवर होने और भेजने के गार्ड का पता लगाएँ, हर साइनअप इवेंट के लिए डिलीवरी को idempotent बनाएँ, और पुष्टि करें कि रीप्ले से केवल एक ईमेल भेजा जाता है।
मिलान में विसंगति
अलग-अलग सिस्टमों की गणनाएँ मेल नहीं खातीं।
समस्या का प्रकार: डेटा अखंडता (लिखे गए डेटा का खोना, डुप्लिकेट, भ्रष्टाचार, बेमेल रिकॉर्ड।)
जमा राशि का भुगतान हुआ, लेकिन खाते में जमा नहीं हुई
स्थिति: खुली
विवरण
प्रदाता द्वारा पहले जमा राशि को विफल बताए जाने के बाद, उसके भुगतान से उपयोगकर्ता का वॉलेट अपडेट नहीं हुआ।
क्या हुआ
भुगतान प्रदाता ने जमा राशि को विफल बताया, फिर 40 मिनट बाद उसका भुगतान कर दिया। पैसा आ गया, लेकिन उपयोगकर्ता के वॉलेट में जमा नहीं हुआ और कोई त्रुटि भी नहीं आई।
जाँच कैसे करें
प्रदाता की जमा राशि की अंतिम स्थिति की तुलना वॉलेट लेज़र से करें। छूटी हुई राशि जमा करें और पुष्टि करें कि बाद के स्थिति-परिवर्तनों को दोहरी जमा किए बिना संभाला जाता है।
व्यावसायिक मेट्रिक में बदलाव
साइनअप, आवेदन, भुगतान या संदेश सामान्य सीमा से बहुत बाहर चले जाते हैं।
समस्या का प्रकार: व्यावसायिक प्रवाह में खराबी (किसी प्रमुख मेट्रिक में तकनीकी कारण से गिरावट।)
आवेदन 35% कम
स्थिति: खुली
विवरण
प्रवेश ट्रैफ़िक तुलनीय होने के बावजूद, पूरे किए गए आवेदन सामान्य स्तर से कम हैं। यह सबमिशन प्रवाह के भीतर किसी समस्या की ओर संकेत करता है।
क्या हुआ
पिछले सप्ताह के इसी घंटे की तुलना में आवेदन 35% कम हैं, जबकि आवेदन फ़ॉर्म पर आने वाले विज़िट तुलनीय बने हुए हैं। यह अंतर सबमिट करने के प्रयासों और सहेजे गए आवेदनों के बीच शुरू होता है। यह पैटर्न माँग में साधारण गिरावट के बजाय प्रोसेसिंग या सत्यापन की समस्या का संकेत देता है।
जाँच कैसे करें
सबमिशन के परिणामों और सत्यापन के कारणों की आधार अवधि से तुलना करें, फिर गिरावट को उपयोगकर्ता के व्यवहार से जोड़ने से पहले प्रभावित प्रयासों को डेटा सहेजे जाने तक ट्रेस करें।
खाली आउटपुट
जॉब सफलता की सूचना देते हैं, लेकिन कुछ भी उत्पन्न नहीं करते।
समस्या का प्रकार: बैकग्राउंड जॉब विफलता (छूटा हुआ, दोहराया गया, अटका हुआ या खाली शेड्यूल किया गया काम।)
रिटेंशन सफ़ाई ने कुछ भी छिपाया नहीं
स्थिति: खुली
विवरण
रिटेंशन सफ़ाई जॉब उन संगठनों के लिए पहचाने गए प्रॉम्प्ट डेटा को छिपाए बिना पूरी होती रही, जिन्होंने रिटेंशन से बाहर रहने का विकल्प चुना था।
क्या हुआ
जिन संगठनों ने प्रॉम्प्ट रिटेंशन से बाहर रहने का विकल्प चुना था, उनके लिए सफ़ाई जॉब डेटा को छिपाने योग्य पाती रही, शून्य पंक्तियाँ छिपाती और आगे बढ़ जाती। यह 11 संगठनों में एक महीने तक, बिना अपवाद के, निर्धारित समय पर चलती रही।
जाँच कैसे करें
उम्मीदवार डेटा के चयन की तुलना छिपाने की शर्त और प्रभावित पंक्तियों की संख्या से करें। प्रभावित सफ़ाई को दोबारा चलाने से पहले पुष्टि करें कि पात्र डेटा हटाया गया है।
पुराना डेटा
कैश और सिंक जॉब रीफ़्रेश होना बंद कर देते हैं।
समस्या का प्रकार: डेटा अखंडता (लिखे गए डेटा का खोना, डुप्लिकेट, भ्रष्टाचार, बेमेल रिकॉर्ड।)
डायरेक्टरी डेटा तीन दिन पुराना
स्थिति: खुली
विवरण
अपस्ट्रीम स्रोत में बदलाव होने के बावजूद, डायरेक्टरी से पुराना स्नैपशॉट दिया जा रहा है, जिससे उपयोगकर्ताओं को पुराने रिकॉर्ड मिलते हैं।
क्या हुआ
डायरेक्टरी का सबसे हाल का सफल रीफ़्रेश तीन दिन पुराना है। रीड उसी स्नैपशॉट को लौटाते रहते हैं, जबकि सिंक के प्रयास उसकी नवीनता का मार्कर आगे नहीं बढ़ा पाते। उपलब्धता जाँचें हरी रहती हैं क्योंकि कैश जवाब देता है, लेकिन नई जोड़ी गई या बदली गई प्रविष्टियाँ मौजूद नहीं हैं।
जाँच कैसे करें
रीफ़्रेश जॉब और चेकपॉइंट अपडेट को ट्रेस करें, स्रोत रिकॉर्ड की कैश किए गए स्नैपशॉट से तुलना करें, और सुरक्षित री-सिंक के बाद डेटा की नवीनता की पुष्टि करें।
लागत
लॉग वॉल्यूम में उछाल
डिप्लॉय के बाद अचानक बहुत अधिक लॉग आने लगते हैं।
समस्या का प्रकार: लागत विसंगति (लॉग, क्लाउड या LLM उपयोग पर खर्च में उछाल।)
डिबग लाइन दिन में 40M बार लॉग हो रही है
स्थिति: खुली
विवरण
हाल ही में बार-बार आने वाला एक डिबग संदेश लॉग स्ट्रीम पर हावी हो रहा है, जिससे ट्रैफ़िक में समान वृद्धि के बिना इनजेशन और स्टोरेज का काम बढ़ रहा है।
क्या हुआ
डिप्लॉय के बाद एक डिबग लाइन प्रतिदिन 40 मिलियन लॉग इवेंट का कारण बनती है। उसका कॉल साइट बार-बार होने वाले ऑपरेशन के भीतर है, इसलिए अब हर अनुरोध कई प्रतियाँ उत्सर्जित करता है। वॉल्यूम में बदलाव लॉगिंग के व्यवहार से आया है, न कि उपयोगी एप्लिकेशन गतिविधि में तुलनीय वृद्धि से।
जाँच कैसे करें
बार-बार होने वाले लॉग कॉल का पता लगाएँ, अनावश्यक आउटपुट कम करें या उसका सैंपल लें, और वॉल्यूम के आधार स्तर पर लौटने के बाद पुष्टि करें कि निदान के लिए पर्याप्त जानकारी उपलब्ध है।
क्लाउड खर्च में विसंगति
किसी सेवा या संसाधन का खर्च बढ़ जाता है।
समस्या का प्रकार: लागत विसंगति (लॉग, क्लाउड या LLM उपयोग पर खर्च में उछाल।)
डेटा ट्रांसफ़र की लागत दोगुनी
स्थिति: खुली
विवरण
ट्रैफ़िक में तुलनीय वृद्धि के बिना डेटा ट्रांसफ़र का खर्च दोगुना हो गया है, जिससे संकेत मिलता है कि अनुरोध अधिक महँगे मार्ग से डेटा भेज रहे हैं।
क्या हुआ
एप्लिकेशन अनुरोधों की संख्या समान रहने के बावजूद, रातोंरात ट्रांसफ़र लागत दोगुनी हो जाती है। वृद्धि उपयोगकर्ता को दिखने वाले जवाब के आकार के बजाय सेवाओं के बीच ट्रैफ़िक में केंद्रित है। रूटिंग या प्लेसमेंट में बदलाव के कारण बार-बार या क्रॉस-रीजन ट्रांसफ़र हो सकता है, जिसे सामान्य अनुरोध मेट्रिक्स उजागर नहीं करते।
जाँच कैसे करें
स्रोत, गंतव्य और डिप्लॉय बदलाव के अनुसार ट्रांसफ़र उपयोग का विश्लेषण करें, फिर पुष्टि करें कि रूटिंग या दोहराए गए फ़ेच अतिरिक्त बाइट्स की वजह हैं या नहीं।
LLM खर्च में उछाल
सुविधा या ग्राहक के अनुसार टोकन उपयोग बढ़ जाता है।
समस्या का प्रकार: लागत विसंगति (लॉग, क्लाउड या LLM उपयोग पर खर्च में उछाल।)
एजेंट लूप ने एक सप्ताह का बजट खर्च कर दिया
स्थिति: खुली
विवरण
एक एजेंट अपना काम पूरा किए बिना बार-बार मिलते-जुलते मॉडल कॉल करता है, जिससे एक ही वर्कफ़्लो में असामान्य रूप से अधिक टोकन उपयोग होता है।
क्या हुआ
एक खाते का एजेंट रन एक दिन में सामान्यतः एक सप्ताह में खर्च होने वाला टोकन बजट इस्तेमाल कर लेता है। लगातार कॉल में वही टूल परिणाम दोहराया जाता है और संदर्भ बढ़ता जाता है, लेकिन कार्य पूरा होने का कोई अंतिम परिणाम नहीं दिखता। यह दोहराया गया लूप उपयोगी प्रगति किए बिना लागत बढ़ाता है।
जाँच कैसे करें
दोहराए गए निर्णय और टूल परिणाम की जाँच करें, निष्फल रन रोकें, और कार्य दोबारा शुरू करने से पहले सीमित पुनः प्रयास तथा प्रगति न होने पर बाहर निकलने की व्यवस्था जोड़ें।
टेलीमेट्री में अंतराल
सेवा से लॉग आना बंद हो गया
कोई स्रोत लॉग भेजना बंद कर देता है।
समस्या का प्रकार: अवलोकनीयता में अंतराल (ऐसी जगहें जहाँ आप अंधेरे में हैं, या ऐसी टेलीमेट्री जो जोखिम पैदा करती है।)
वर्कर फ़्लीट से लॉग आना बंद
स्थिति: खुली
विवरण
कॉन्फ़िगरेशन में बदलाव के बाद वर्कर फ़्लीट ने लॉग भेजना बंद कर दिया, जिससे उसके जारी काम को समझने के लिए आवश्यक निदान रिकॉर्ड उपलब्ध नहीं रहे।
क्या हुआ
कतार की गतिविधि दिखाती है कि जॉब अब भी प्रोसेस हो रहे हैं, जबकि वर्कर लॉग वॉल्यूम शून्य हो जाता है। यह चुप्पी कॉन्फ़िगरेशन बदलाव के साथ शुरू होती है और किसी एक होस्ट के बजाय पूरे फ़्लीट को प्रभावित करती है। यह लॉगिंग या डिलीवरी पथ की समस्या की ओर संकेत करता है, न कि इस बात का प्रमाण कि हर वर्कर रुक गया है।
जाँच कैसे करें
लॉगर और एक्सपोर्टर कॉन्फ़िगरेशन की पिछले संस्करण से तुलना करें, डिलीवरी त्रुटियों की जाँच करें, और उत्सर्जन से लेकर इनजेशन तक किसी ज्ञात वर्कर इवेंट की पुष्टि करें।
अपठनीय फ़ॉर्मैट
नया लॉग फ़ॉर्मैट पार्स नहीं किया जा सकता।
समस्या का प्रकार: अवलोकनीयता में अंतराल (ऐसी जगहें जहाँ आप अंधेरे में हैं, या ऐसी टेलीमेट्री जो जोखिम पैदा करती है।)
नया लॉग फ़ॉर्मैट अपठनीय
स्थिति: खुली
विवरण
लॉगर अपग्रेड ने रिकॉर्ड फ़ॉर्मैटिंग बदल दी, जिससे आने वाले लॉग विश्लेषण और सहसंबंध के लिए उपयोग किए जाने वाले संरचित फ़ील्ड खोने लगे।
क्या हुआ
स्रोत रिकॉर्ड भेजना जारी रखता है, लेकिन अपग्रेड किए गए लॉगर के साथ पार्सिंग विफलताएँ शुरू हो जाती हैं। कच्ची पंक्तियों में अपेक्षित शीर्ष-स्तरीय फ़ील्ड के चारों ओर एक नया एनवेलप होता है। इवेंट विश्वसनीय गंभीरता, संदेश या अनुरोध संदर्भ के बिना आते हैं, जिससे उनका निदानात्मक महत्व घट जाता है।
जाँच कैसे करें
पुराने और नए कच्चे रिकॉर्ड की तुलना करें, पार्सिंग अनुबंध अपडेट करें, और स्रोत को स्वस्थ मानने से पहले प्रतिनिधि मल्टीलाइन और त्रुटि इवेंट की पुष्टि करें।
ब्लाइंड स्पॉट
किसी महत्वपूर्ण रूट या जॉब के लिए टेलीमेट्री उपलब्ध नहीं है।
समस्या का प्रकार: अवलोकनीयता में अंतराल (ऐसी जगहें जहाँ आप अंधेरे में हैं, या ऐसी टेलीमेट्री जो जोखिम पैदा करती है।)
पेमेंट्स एंडपॉइंट कुछ भी लॉग नहीं करता
स्थिति: खुली
विवरण
नया पेमेंट्स एंडपॉइंट अनुरोध संभालता है, लेकिन एप्लिकेशन टेलीमेट्री उत्पन्न नहीं करता। इससे विफलताओं और अधूरे ऑपरेशनों की जाँच करना कठिन हो जाता है।
क्या हुआ
इनग्रेस रिकॉर्ड दिखाते हैं कि अनुरोध एंडपॉइंट तक पहुँच रहे हैं, लेकिन लॉग स्ट्रीम में उनसे मेल खाने वाला कोई एप्लिकेशन आरंभ, परिणाम या अनुरोध ID नहीं दिखता। पेमेंट के अन्य रूट अब भी ये इवेंट उत्सर्जित करते हैं। कवरेज न होने से अनुरोध को सत्यापन, प्रदाता कॉल और डेटा सहेजने की प्रक्रिया में ट्रेस करना संभव नहीं है।
जाँच कैसे करें
रूट के लॉगिंग मिडलवेयर को ट्रेस करें, सहसंबंध ID वाले संरचित परिणाम इवेंट जोड़ें, और भुगतान क्रेडेंशियल या संवेदनशील पेलोड रिकॉर्ड किए बिना पूरे ट्रेल की पुष्टि करें।
घड़ी का समय मेल नहीं खाता
अलग-अलग स्रोतों के टाइमस्टैम्प में अंतर आ जाता है।
समस्या का प्रकार: अवलोकनीयता में अंतराल (ऐसी जगहें जहाँ आप अंधेरे में हैं, या ऐसी टेलीमेट्री जो जोखिम पैदा करती है।)
होस्ट 4 मिनट पीछे
स्थिति: खुली
विवरण एक होस्ट अपने समकक्षों से पहले के समय पर इवेंट का टाइमस्टैम्प दर्ज करता है, जिससे एक ही अनुरोध अलग-अलग सेवाओं में क्रम से बाहर निष्पादित होता हुआ दिखाई देता है।
क्या हुआ
इस होस्ट के इवेंट, अन्य स्रोतों से मेल खाने वाली अनुरोध ID की तुलना में चार मिनट पीछे हैं। इनजेशन का समय लगभग समान रहता है, इसलिए विसंगति ट्रांसपोर्ट में देरी के बजाय दर्ज किए गए इवेंट समय में है। यह समय-अंतर टाइमलाइन को विकृत करता है और लेटेंसी या क्रम के विश्लेषण को भ्रामक बना सकता है।
जाँच कैसे करें
होस्ट के समय-सिंक्रनाइज़ेशन और टाइमस्टैम्प सीरियलाइज़ेशन की जाँच करें, घड़ी ठीक करें और क्रॉस-सर्विस समय पर भरोसा करने से पहले सहसंबंधित इवेंट की फिर से तुलना करें।
Sazabi Detection Catalog के उदाहरण। कुछ सिग्नल अभी आने बाकी हैं।
आपके स्टैक के साथ काम करता है
चैट प्रदाता (3 इंटीग्रेशन)
Git प्रदाता (2 इंटीग्रेशन)
इश्यू ट्रैकर और ऑन-कॉल (6 इंटीग्रेशन)
लॉग स्रोत (73 इंटीग्रेशन)
- AWS
- Vercel
- Supabase
- Cloudflare
- OpenTelemetry
- Fluent Bit
- GitHub
- Linear
- Webhooks
- Cursor
- GitHub Copilot
- Factory Droid
- OpenHands
- OpenClaw
- Hermes Agent
- Claude Agent SDK
- Google Cloud
- Railway
- Render
- Fly.io
- Netlify
- DigitalOcean
- Porter
- Modal
- Northflank
- Neon
- Convex
- Inngest
- Trigger.dev
- Temporal
- Mastra
- LangChain
- E2B
- Daytona
- OpenRouter
- Datadog
- Sentry
- PostHog
- Prometheus
- Elastic Cloud
- SigNoz
- Vector
- Respan
- New Relic
- evlog
- Plain
- Shopify
- Okta
- Auth0
- WorkOS
- SentinelOne
- Palo Alto Networks
- Zscaler
- HashiCorp Vault
- Jamf Pro
- osquery
- Linux auditd
- Stripe
- Claude Code
- Codex
- Devin
- Doppler
- Gemini
- Grafana Alloy
- oh-my-pi
- Sazabi Browser SDK
- Tailscale
- Unkey
- Jenkins
- Buildkite
- RunsOn
- WarpBuild
- Sazabi React Native SDK
इन्फ्रास्ट्रक्चर टूल (17 इंटीग्रेशन)
- AWS
- Google Cloud
- Vercel
- Cloudflare
- Kubernetes
- Terraform
- Railway
- Render
- Fly.io
- Netlify
- DigitalOcean
- Porter
- Argo CD
- Azure
- Heroku
- RunPod
- Tailscale
डेटाबेस टूल (12 इंटीग्रेशन)
- Supabase
- Neon
- Postgres
- MySQL
- Redis
- ClickHouse
- Convex
- PlanetScale
- Airbyte
- Aiven
- MongoDB Atlas
- MongoDB Shell
AI और वर्कफ़्लो टूल (32 इंटीग्रेशन)
- Codex
- Cursor
- Gemini
- OpenCode
- Temporal
- Inngest
- Claude Agent
- Warp Oz
- Capy
- Tembo
- Hoplite
- Replicas
- Composio
- Exa
- The Context Company
- RentAHuman
- Cekura
- Langfuse
- Braintrust
- Respan
- Tines
- DeepWiki
- Context.dev
- AgentCat
- CodeRabbit
- Dagster
- DBOS Cloud
- Deepsec
- Devin
- ElevenLabs
- LangSmith
- Rivet
टीम और संचालन टूल (43 इंटीग्रेशन)
- Notion
- Google Drive
- Grafana
- Attio
- 1Password
- Intercom
- Axiom
- Honeycomb
- Better Stack
- Pydantic Logfire
- down.guide
- Pylon
- Clay
- Calendly
- Circleback
- Granola
- Happenstance
- Superhuman
- Mercury
- X
- Wiz
- Vanta
- Drata
- Semgrep
- Socket
- GitGuardian
- Google Security Operations
- VirusTotal
- Have I Been Pwned
- cve.now
- Clerk
- Resend
- Autumn
- Arize
- Checkly
- DoorDash
- Graphite
- GrowthBook
- Herd
- Mobbin
- Secureframe
- Stream
- Twilio
केस स्टडी
Weave
Sazabi के साथ मैन्युअल डिटेक्शन की जगह लेकर Weave हर हफ़्ते 20+ इंजीनियरिंग घंटे कैसे बचाता है
Sazabi ने उन चीज़ों को, जो पहले हमारी नज़र से छूट जाती थीं, ऐसे इश्यू में बदल दिया जिन्हें हम ग्राहकों के ध्यान में आने से पहले पकड़कर ठीक कर लेते हैं। किसी समस्या को पूरी तरह रोकने के बाद सबसे अच्छी बात है उसके बारे में तुरंत जानना—और Sazabi हमें ठीक यही देता है।
Andrew Churchill, Weave के सह-संस्थापक और CTO
- 8.5 min: प्रोडक्शन इश्यू का मूल कारण पता करने में लगा समय
- 9 min: सेटअप करने में लगा समय
Mastra
Sazabi के रूट-कॉज़ अलर्ट से Mastra ने 45 मिनट की जाँचों की जगह कैसे ली
Sazabi ने हमें लॉन्च के लिए ज़रूरी प्रोडक्शन दृश्यता दी, और इसके लिए हमें अपना सामान्य ऑब्ज़र्वेबिलिटी सेटअप बनाने की ज़रूरत नहीं पड़ी। अब हर डिप्लॉय के समय यह एक ऐसा सुरक्षा-जाल है जिस पर हमें भरोसा है।
Abhi Aiyer, Mastra के सह-संस्थापक और CTO
- 45 min: Sazabi से पहले मैन्युअल जाँच में लगा समय
- 150 issues: दो हफ़्तों में पहचाने गए प्रोडक्शन इश्यू
XMTP Labs
Sazabi के साथ XMTP Labs ने बग का पता लगाने का समय दिनों से घटाकर मिनटों में कैसे किया
Sazabi को अपने ऑब्ज़र्वेबिलिटी स्टैक का हिस्सा बनाने के बाद, हम अपने पिछले किसी भी तरीके की तुलना में मूल कारण तक बहुत तेज़ी से पहुँचते हैं।
Nick Molnar, XMTP Labs के CTO
- 5 min: किसी बड़ी घटना को फ़्लैग करने में लगा समय
- 20 min: किसी गंभीर इश्यू का फ़िक्स शिप करने में लगा समय
हमारे ब्लॉग से
- Sazabi Security का परिचय: अलर्ट करने से पहले जाँच करने वाली सुरक्षा निगरानी: Sazabi Security आपके आइडेंटिटी, क्लाउड और नेटवर्क लॉग में हमलों पर नज़र रखता है, संदिग्ध गतिविधि की जाँच करता है और सुरक्षा इश्यू तभी खोलता है जब वास्तव में कुछ गड़बड़ हो।
- YC कंपनियों के लिए अब लॉग मुफ़्त: मौजूदा YC बैच को 3 साल के मुफ़्त लॉग (1 PB तक) और Sazabi Startup प्लान के 12 महीने मिलते हैं। पूर्व छात्रों को 2 साल और 6 महीने मिलते हैं।
- Sazabi BYOC का परिचय: Sazabi को अपने क्लाउड में चलाएँ: Sazabi BYOC के साथ, Sazabi का वह हिस्सा जो आपके लॉग प्राप्त करता है, प्रोसेस करता है और स्टोर करता है, आपके अपने क्लाउड खाते में चलता है और Sazabi उसका संचालन करता है।
ऑब्ज़र्वेबिलिटी और सुरक्षा का एक अलग तरीका
01 सब कुछ एक लॉग है
मेट्रिक्स, ट्रेस, एप्लिकेशन इवेंट, एजेंट की कार्रवाइयाँ—ये सभी बताते हैं कि क्या हुआ। लॉग इंसानों और एजेंटों को सिस्टम समझने के लिए एक साझा आधार देते हैं।
02 लॉग विसंगति का पता लगाने में मदद करते हैं
किसी विफलता को पकड़ने के लिए आपको हर बार उसका अनुमान लगाने की ज़रूरत नहीं होनी चाहिए। लॉग का आधार Sazabi को आपके सिस्टम के व्यवहार में बदलाव खोजने और यह जाँचने देता है कि क्या हुआ।
03 AI-नेटिव दुनिया के लिए निर्मित
AI सॉफ़्टवेयर बनाने और चलाने के तरीकों को बदल रहा है। Sazabi इंसानों और एजेंटों को कार्रवाई के लिए ज़रूरी सबूतों और टूल तक साझा पहुँच देता है।
ग्राहक क्या कहते हैं
पहले दो दिनों में ही Sazabi ने लगभग 8 ऐसे इश्यू पकड़ लिए जिन्हें हम अन्यथा नहीं खोज पाते, Sentry के साथ भी नहीं।
Bence R., Hoplite
भविष्य में जी रहे हैं: Sazabi PR खोलता है, Cursor जोखिम का आकलन करके उसे मंज़ूर करता है, CI पूरी तरह हरा है।
Evan, AGREE
हर अलर्ट उच्च प्राथमिकता का नहीं होता, लेकिन हर अलर्ट पर कार्रवाई की जा सकती है। गुणवत्ता से मैं बहुत प्रभावित हूँ।
Yash N., Sandstone
Sazabi के भेजे कुछ इश्यू देखकर मैं 🤯 रह जाता हूँ—और यह बहुत मददगार है। हमारी माइक्रोसर्विसेज़ बढ़ने के साथ यह और भी अहम हो जाता है।
Nanda G., Taiga
Slack अलर्ट इतने अच्छे हैं कि मुझे डैशबोर्ड खोलने की ज़रूरत नहीं पड़ी। कोडिंग एजेंट आते ही बग ठीक कर देता है।
Charlie L., Autumn
Sazabi हमारी ऑन-कॉल व्यवस्था की रीढ़ है। और नए सुरक्षा अलर्ट के साथ, हम वास्तविक समय में घबरा सकते हैं।
Ed P., WAJO
एंटरप्राइज़ के लिए तैयार
अपना क्लाउड इस्तेमाल करें
लॉग इनटेक, प्रोसेसिंग और स्टोरेज अपने AWS खाते में चलाएँ। डिप्लॉयमेंट का संचालन Sazabi करता है।
- स्टोरेज का स्वामित्व आपके संगठन के पास
- आपकी रिटेंशन नीति
- ऐसी पहुँच जिसे आप रद्द कर सकते हैं
अनुपालन
आपकी टीम की समीक्षा में सहायता के लिए सुरक्षा मानक और गोपनीयता प्रतिबद्धताएँ।
- SOC 2
- SOC 1
- ISO 27017
- ISO 27001
- GDPR
पहुँच और सुरक्षा
अपने आइडेंटिटी प्रोवाइडर को कनेक्ट करें और पूरे संगठन में पहुँच नियंत्रित करें।
- SAML / OIDC के साथ SSO
- SCIM प्रोविज़निंग
- भूमिका-आधारित अनुमतियाँ
- प्रतिबंधित प्रोजेक्ट पहुँच
- दो-कारक प्रमाणीकरण
अक्सर पूछे जाने वाले प्रश्न
Sazabi क्या है?
Sazabi इंजीनियरिंग टीमों और कोडिंग एजेंटों के लिए AI-नेटिव ऑब्ज़र्वेबिलिटी और सुरक्षा प्लेटफ़ॉर्म है। यह आपके कोड के साथ आपके प्रोडक्शन लॉग पढ़ता है, महत्वपूर्ण इश्यू का पता लगाता है, हर इश्यू की मूल वजह तक जाँच करता है और नतीजा उन टूल तक भेजता है जिनका आपकी टीम पहले से इस्तेमाल करती है।
क्या मुझे मॉनिटर या अलर्ट नियम लिखने होंगे?
नहीं। Sazabi आपके लॉग में ऐसे बदलावों पर नज़र रखता है जिनकी बारीकी से जाँच ज़रूरी हो सकती है—जैसे कोई इवेंट आना बंद हो जाए, कोई चरण चुपचाप विफल होने लगे या डिप्लॉय के बाद लेटेंसी बढ़ जाए। इसका एजेंट इन सिग्नल की जाँच करता है, वास्तविक प्रभाव की पुष्टि करता है और उसके बाद ही इश्यू खोलता है—बिना मॉनिटर, थ्रेशोल्ड या अलर्ट नियमों को बनाए रखने की ज़रूरत के।
Sazabi किन लॉग और टूल से जुड़ता है?
Datadog, PostHog, Sentry, Google Cloud, Supabase और Cloudflare जैसे स्रोतों से लॉग भेजें, और GitHub से अपना कोड कनेक्ट करें, ताकि Sazabi समस्याओं का पता उनके पीछे मौजूद कमिट और फ़ाइल तक लगा सके। समस्याओं की जानकारी आपकी टीम तक Slack, Microsoft Teams, ईमेल या SMS के ज़रिए पहुँचती है।
Sazabi कोडिंग एजेंट के साथ कैसे काम करता है?
हर समस्या के साथ उसका मूल कारण और सुधार की योजना मिलती है, जिसे आप सीधे Claude Code, Codex या Cursor जैसे कोडिंग एजेंट को दे सकते हैं। काम करते समय एजेंट CLI और MCP के ज़रिए Sazabi से आपके लॉग के बारे में पूछ भी सकते हैं।
क्या मेरे लॉग मेरे अपने क्लाउड में रह सकते हैं?
हाँ। Sazabi BYOC के साथ, लॉग का इनटेक, प्रोसेसिंग और स्टोरेज आपके अपने AWS खाते में चलता है और आपके लॉग ऐसे स्टोरेज में रहते हैं जिसका स्वामित्व आपके संगठन के पास है, जबकि Sazabi डिप्लॉयमेंट संचालित करता है। क्वेरी के नतीजे और लॉग के अंश फिर भी Sazabi और मॉडल प्रदाताओं तक पहुँच सकते हैं।
Sazabi की कीमत कितनी है?
Hobby की कीमत $50, Startup की $200 और Growth की $1,000 प्रति 30-दिन के चक्र की है; हर प्लान में कुछ उपयोग शामिल है। Enterprise के लिए कस्टम कीमत और शर्तें हैं। हर प्लान में क्या शामिल है, यह जानने के लिए मूल्य निर्धारण पेज देखें।
मैं शुरुआत कैसे करूँ?
Sazabi सेट अप करने के लिए अपने टर्मिनल में npx @sazabi/cli start चलाएँ, या दस्तावेज़ों में दिए गए क्विकस्टार्ट का पालन करें।