महत्वपूर्ण लिंक
सेवा स्वास्थ्य डैशबोर्ड (वर्तमान में केवल एंटरप्राइज़ API ग्राहकों के लिए उपलब्ध)
सही डिफ़ॉल्ट से शुरू करें
जब आप सेवा स्वास्थ्य डैशबोर्ड खोलते हैं, तो यह डिफ़ॉल्ट रूप से यह दिखाता है:
सभी प्रोजेक्ट
पिछले 30 दिन
घंटेवार रिज़ॉल्यूशन
यह व्यू केवल ओरिएंटेशन के लिए उपयोगी है. सार्थक निवारण के लिए हमेशा फ़िल्टरिंग आवश्यक होती है.
जाँच से पहले फ़िल्टर करें
सही फ़िल्टरिंग सबसे महत्वपूर्ण चरण है. अधिकांश गलत व्याख्याएँ मॉडल, टियर या प्रोजेक्ट मिलाने से होती हैं.
मॉडल के अनुसार फ़िल्टर करें (एक बार में एक)
हमेशा एक ही मॉडल तक फ़िल्टर करें.
क्यों:
कम-ट्रैफ़िक मॉडल की समस्याएँ अधिक-वॉल्यूम ट्रैफ़िक से छिप सकती हैं
अधिक-वॉल्यूम मॉडल स्थानीय समस्याओं को वैश्विक जैसा दिखा सकते हैं
अलग-अलग मॉडल के प्रदर्शन लक्ष्य अलग होते हैं
ध्यान दें: कई मॉडल चुनने से वे एकत्रित होते हैं—यह उनके बीच स्विच नहीं करता.
सर्विस टियर के अनुसार फ़िल्टर करें
यदि आप एक से अधिक टियर (मानक, तेज़ मोड (पहले प्राथमिकता प्रोसेसिंग), स्केल टियर) का उपयोग करते हैं, तो हमेशा उस टियर के अनुसार फ़िल्टर करें जिसकी आप जांच कर रहे हैं.
क्यों:
टियरों की प्रदर्शन संबंधी विशेषताएं अलग-अलग होती हैं.
तेज़ मोड और स्केल टियर के SLA निर्धारित हैं.
टियरों को मिलाने से सशुल्क टियर का प्रदर्शन स्पष्ट नहीं दिखता.
यह विलंबता के विश्लेषण के लिए विशेष रूप से महत्वपूर्ण है.
मौजूदा मॉडलों के लिए तेज़ मोड का ट्रैफ़िक अब भी उपयोग डैशबोर्ड में प्राथमिकता के रूप में दिखाई देता है.
प्रोजेक्ट के अनुसार फ़िल्टर करें
डिफ़ॉल्ट रूप से, सेवा स्वास्थ्य सभी प्रोजेक्ट दिखाता है.
निवारण के लिए, उस प्रोजेक्ट/प्रोजेक्टों तक फ़िल्टर करें जहाँ समस्या देखी गई थी.
क्यों:
एक अधिक-वॉल्यूम प्रोजेक्ट मेट्रिक्स पर हावी हो सकता है.
छोटे प्रभावित प्रोजेक्ट असंबंधित ट्रैफ़िक से छिप सकते हैं.
"सभी प्रोजेक्ट" को चयनित केवल तभी छोड़ें जब आपको लगे कि समस्या सचमुच पूरे संगठन में है.
त्रुटियों का निवारण
HTTP अनुरोध व्यू का उपयोग करें
त्रुटियों की जाँच करने के लिए:
मॉडल और सर्विस टियर के अनुसार फ़िल्टर करें.
अपटाइम टैब के बजाय HTTP अनुरोध टैब खोलें.
यह व्यू HTTP स्थिति कोड के अनुसार कुल अनुरोध और त्रुटि गणना दिखाता है. सूक्ष्म उछाल या बदलाव पहचानने के लिए मिनट-स्तर रिज़ॉल्यूशन तक ज़ूम करें.
गणना नहीं, त्रुटि दरों की व्याख्या करें
किसी भी प्रोडक्शन सिस्टम में कुछ त्रुटियाँ अपेक्षित होती हैं. कच्चे कुलों पर नहीं, त्रुटि प्रतिशत पर ध्यान दें.
आपका कुल वॉल्यूम जितना बड़ा होगा, अत्यंत कम त्रुटि दर के साथ भी त्रुटियों की संभावित संख्या उतनी ही बड़ी होगी.
जब सेवा स्वास्थ्य में त्रुटियाँ गायब हों
यदि आपको क्लाइंट-साइड त्रुटियाँ दिखती हैं लेकिन सेवा स्वास्थ्य में संबंधित डेटा नहीं है:
अनुरोध संभवतः OpenAI तक नहीं पहुँचे.
समस्या आम तौर पर अपस्ट्रीम होती है (टाइमआउट, प्रॉक्सी, नेटवर्किंग).
यह आक्रामक क्लाइंट-साइड टाइमआउट के साथ आम है.
विलंबता की समस्या का समाधान
विलंबता का विश्लेषण तेज़ मोड और स्केल टियर टियरों पर सबसे सार्थक होता है, जिनके SLA निर्धारित हैं. मानक टियर में विलंबता का उतार-चढ़ाव अधिक हो सकता है और इसकी विलंबता की गारंटी नहीं है.
मुख्य मेट्रिक्स
प्रत्येक मेट्रिक देखने के लिए, संबंधित टैब पर क्लिक करें:
टोकन वेग: प्रति सेकंड जनरेट किए गए टोकन; प्रॉम्प्ट आकार से स्वतंत्र.
अनुरोध समय: कुल अनुरोध अवधि; आउटपुट आकार और रीज़निंग से बहुत प्रभावित.
पहले टोकन तक का समय (TTFT): पहला टोकन जनरेट होने तक का समय; अनकैश्ड इनपुट प्रॉम्प्ट आकार और रीज़निंग से बहुत प्रभावित.
हमेशा P50 / P75 / P95 पर्सेंटाइल की समीक्षा करें. औसत वास्तविक उपयोगकर्ता प्रभाव को छिपा सकते हैं.
विलंब और टोकन उपयोग के बीच संबंध समझना
सेवा की स्थिति से पता चलता है कि सेवा का व्यवहार कब बदला. उपयोग के डेटा से यह समझने में मदद मिलती है कि ऐसा क्यों हुआ.
यह सुनिश्चित करने के लिए कि उपयोग डैशबोर्ड में दिख रहा डेटा सेवा की स्थिति वाले डैशबोर्ड में आपके दृश्य से संबंधित है, ये कदम उठाएँ:
उसी प्रोजेक्ट और मॉडल के अनुसार फ़िल्टर करें.
यदि लागू हो, तो सर्विस टियर के अनुसार समूह बनाएँ.
आउटपुट टोकन पर ध्यान दें, क्योंकि विलंब पर इनका सबसे अधिक असर पड़ता है.
अधिक गहराई से विश्लेषण करने के लिए, गतिविधि डेटा निर्यात करें और जाँचें कि समय के साथ प्रति अनुरोध टोकन की संख्या कैसे बदली है.
सहायता टीम के साथ क्या साझा करें (ज़रूरत पड़ने पर)
यदि आप सहायता टीम से संपर्क करते हैं, तो ये जानकारी दें:
प्रभावित संगठनों की आईडी (महत्वपूर्ण)
प्रभावित एंडपॉइंट, जैसे Chat Completions या Responses (महत्वपूर्ण)
प्रभावित मॉडल (महत्वपूर्ण)
यह समस्या तेज़ मोड में हो रही है या स्केल टियर पर (महत्वपूर्ण)
विलंब या त्रुटियाँ होने की समयावधियाँ, समय क्षेत्र सहित (महत्वपूर्ण)
संबंधित x-request-id या X-Client-Request-Id, यदि उपलब्ध हो
आप जिन अनुरोधों का विवरण दे रहे हैं, उनके टाइमस्टैम्प समय क्षेत्र सहित, या कम-से-कम उनकी तारीख
यदि उपलब्ध हो, तो यह भी शामिल करें:
अनुरोधों से संबंधित प्रोजेक्ट आईडी
क्या डेटा रेज़िडेंसी वाले अनुरोध प्रभावित हैं, और यदि हाँ, तो कौन-से
आपको दिख रहे रुझानों का विवरण
समस्या के प्रकार के अनुसार, यह जानकारी दें:
त्रुटियाँ: विफल होने वाले या त्रुटि लौटाने वाले अनुरोधों का अनुमानित प्रतिशत, प्रतिक्रिया कोड, त्रुटि संदेश और त्रुटि वाली प्रतिक्रिया मिलने में लगा समय.
विलंब: कौन-से प्रतिशतक प्रभावित हैं (P50 / P90 / P95 / P99), वे ग्राहक के सामान्य स्तर से कितने अधिक हैं, और धीमे अनुरोधों के उदाहरण, भेजने और प्राप्त करने के टाइमस्टैम्प सहित.
दोनों: त्रुटि या विलंब के डेटा के स्क्रीनशॉट या तालिका, साथ ही यह जानकारी कि आपने कैसे तय किया कि त्रुटि दर या विलंब अपेक्षा से अधिक था.
सामान्य निवारण परिदृश्य
टाइमआउट होते हैं लेकिन सेवा स्वास्थ्य सामान्य दिखता है
संभावित कारण: अनुरोध OpenAI तक पहुँचने से पहले टाइम आउट हो रहे हैं.
जाँचें:
क्लाइंट या प्रॉक्सी टाइमआउट सेटिंग्स
स्थानीय नेटवर्क या लोड बैलेंसर बदलाव
सेवा स्वास्थ्य डैशबोर्ड में 499 त्रुटियों की मौजूदगी (ये आपके अपने सिस्टम में 5xx त्रुटियों के रूप में दिख सकती हैं).
डिप्लॉयमेंट के बिना लेटेंसी बढ़ी
संभावित कारण: आउटपुट टोकन आकार या रीज़निंग उपयोग बढ़ गया और/या ट्रैफ़िक सर्विस टियरों के बीच शिफ़्ट हुआ.
जाँचें:
उपयोग डैशबोर्ड में प्रति अनुरोध औसत आउटपुट टोकन (डेटा डाउनलोड कर आउटपुट टोकन को कुल अनुरोधों से भाग देना आवश्यक है).
सेवा स्वास्थ्य डैशबोर्ड में अनुरोध समय और TTFT पर्सेंटाइल.
तेज़ मोड या स्केल टियर धीमा दिखाई देता है
संभावित कारण: अलग-अलग टियर के मेट्रिक मिले हुए हैं, जिससे मानक टियर का ट्रैफ़िक सशुल्क टियर के प्रदर्शन को छिपा रहा है.
जांचें:
फ़िल्टर केवल एक टियर और मॉडल तक सीमित हैं.
टियरों के बीच टोकन गति की तुलना.
5XX त्रुटियों में उछाल
संभावित कारण: ट्रैफ़िक के छोटे प्रतिशत को प्रभावित करने वाली अस्थायी विफलताएँ.
जाँचें:
त्रुटि दर का प्रतिशत
क्या उसी समय ट्रैफ़िक वॉल्यूम बदला था
समस्या केवल एक प्रोजेक्ट को प्रभावित करती है
संभावित कारण: प्रोजेक्ट-विशिष्ट कॉन्फ़िगरेशन या उपयोग पैटर्न.
जाँचें:
प्रोजेक्ट-स्तर फ़िल्टरिंग
अप्रभावित प्रोजेक्टों के साथ तुलना
अंतिम निष्कर्ष
मेट्रिक्स की व्याख्या करने से पहले, जहाँ प्रासंगिक हो, मॉडल, टियर और प्रोजेक्ट के अनुसार फ़िल्टर करें.
लेटेंसी विश्लेषण के लिए औसत नहीं, पर्सेंटाइल का उपयोग करें.
छोटी त्रुटि दरें अपेक्षित हैं.
डेटा गायब होना आम तौर पर अपस्ट्रीम समस्याओं का संकेत देता है.
उपयोग डेटा यह समझाने में मदद कर सकता है कि लेटेंसी क्यों बदली; सेवा स्वास्थ्य दिखाता है कि व्यवहार कब बदला.