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