महत्वपूर्ण लिंक
*Service Health डैशबोर्ड वर्तमान में केवल Enterprise API ग्राहकों के लिए उपलब्ध है.
सही डिफ़ॉल्ट सेटिंग्स से शुरू करें
जब आप Service Health डैशबोर्ड खोलते हैं, तो यह डिफ़ॉल्ट रूप से इन पर सेट होता है:
सभी प्रोजेक्ट
पिछले 30 दिन
प्रति घंटा रिज़ॉल्यूशन
यह दृश्य केवल प्रारंभिक समझ के लिए उपयोगी है. सार्थक समस्या निवारण के लिए हमेशा फ़िल्टर करना आवश्यक होता है.
जांच शुरू करने से पहले फ़िल्टर करें
सही फ़िल्टरिंग सबसे महत्वपूर्ण चरण है. अधिकतर गलत व्याख्याएं मॉडल, टियर, या प्रोजेक्ट को मिलाने से होती हैं.
मॉडल के अनुसार फ़िल्टर करें (एक बार में एक)
हमेशा एक ही मॉडल पर फ़िल्टर करें.
क्यों:
कम-ट्रैफ़िक वाले मॉडलों की समस्याएं अधिक-वॉल्यूम ट्रैफ़िक में छिप सकती हैं
अधिक-वॉल्यूम वाले मॉडल स्थानीय समस्याओं को वैश्विक जैसा दिखा सकते हैं
अलग-अलग मॉडलों के प्रदर्शन लक्ष्य अलग होते हैं
नोट: कई मॉडल चुनने पर वे एकत्रित हो जाते हैं. यह उनके बीच स्विच नहीं करता.
सेवा टियर के अनुसार फ़िल्टर करें
यदि आप एक से अधिक टियर (standard, priority, scale) का उपयोग करते हैं, तो हमेशा उसी टियर पर फ़िल्टर करें जिसकी आप जांच कर रहे हैं.
क्यों:
टियर की प्रदर्शन विशेषताएं अलग-अलग होती हैं
Priority और scale टियर के लिए परिभाषित SLA होते हैं
टियर को मिलाने से पेड-टियर प्रदर्शन अस्पष्ट हो जाता है
यह लेटेंसी विश्लेषण के लिए विशेष रूप से महत्वपूर्ण है.
प्रोजेक्ट के अनुसार फ़िल्टर करें
डिफ़ॉल्ट रूप से, Service Health सभी प्रोजेक्ट दिखाता है.
समस्या निवारण के लिए, उस प्रोजेक्ट या उन प्रोजेक्ट्स पर फ़िल्टर करें जहां समस्या देखी गई थी.
क्यों:
एक अकेला उच्च-वॉल्यूम प्रोजेक्ट मेट्रिक्स पर हावी हो सकता है
छोटे प्रभावित प्रोजेक्ट असंबंधित ट्रैफ़िक के कारण छिप सकते हैं
केवल तभी "सभी प्रोजेक्ट" चयनित रहने दें जब आपको विश्वास हो कि समस्या वास्तव में पूरे संगठन में है.
त्रुटियों का समस्या निवारण
HTTP Requests दृश्य का उपयोग करें
त्रुटियों की जांच करने के लिए:
मॉडल और टियर के अनुसार फ़िल्टर करें
Uptime से HTTP Requests पर स्विच करने के लिए HTTP Requests टैब पर क्लिक करें
यह दृश्य HTTP status code के अनुसार कुल अनुरोधों और त्रुटि गणना को दिखाता है. सूक्ष्म स्पाइक्स या परिवर्तनों की पहचान करने के लिए मिनट-स्तरीय रिज़ॉल्यूशन तक ज़ूम करें.
त्रुटि गणना नहीं, त्रुटि दर समझें
किसी भी प्रोडक्शन सिस्टम में कुछ त्रुटियां अपेक्षित होती हैं. कच्ची कुल संख्या नहीं, बल्कि त्रुटि प्रतिशत पर ध्यान दें.
आपका कुल वॉल्यूम जितना अधिक होगा, अत्यंत कम त्रुटि दर होने पर भी संभावित त्रुटियों की संख्या उतनी अधिक हो सकती है.
जब Service Health में त्रुटियां नहीं दिखतीं
यदि आपको क्लाइंट-साइड त्रुटियां दिखती हैं लेकिन Service Health में उनसे संबंधित कोई डेटा नहीं है:
संभावना है कि अनुरोध OpenAI तक पहुंचे ही नहीं
समस्या आमतौर पर upstream में होती है (timeouts, proxies, networking)
आक्रामक क्लाइंट-साइड timeouts के साथ यह आम बात है.
लेटेंसी का समस्या निवारण
लेटेंसी विश्लेषण priority और scale टियर पर सबसे अधिक सार्थक होता है, क्योंकि इनके लिए परिभाषित SLA होते हैं. Standard टियर में लेटेंसी में अधिक भिन्नता दिख सकती है, और इसमें लेटेंसी की गारंटी नहीं होती.
मुख्य मेट्रिक्स
इनमें से प्रत्येक मेट्रिक देखने के लिए संबंधित टैब पर क्लिक करें:
टोकन वेग
प्रति सेकंड जनरेट किए गए टोकन.
प्रॉम्प्ट के आकार से स्वतंत्र.
अनुरोध समय
अनुरोध की कुल अवधि.
आउटपुट आकार और रीज़निंग से बहुत प्रभावित.
पहले टोकन तक का समय (TTFT)
पहला टोकन जनरेट होने तक का समय.
अनकैश्ड इनपुट प्रॉम्प्ट के आकार और रीज़निंग से बहुत प्रभावित.
हमेशा P50 / P75 / P95 percentile की समीक्षा करें. औसत वास्तविक उपयोगकर्ता पर पड़ने वाले प्रभाव को छिपा सकते हैं.
6. टोकन उपयोग के साथ लेटेंसी का संबंध समझना
Service Health दिखाता है कि व्यवहार कब बदला. Usage डेटा यह समझाने में मदद करता है कि क्यों.
Usage डैशबोर्ड में, यह सुनिश्चित करने के लिए निम्न करें कि आप वही डेटा देख रहे हैं जो Service Health Dashboard में आपके दृश्य से संबंधित है:
उसी प्रोजेक्ट, मॉडल पर फ़िल्टर करें
यदि लागू हो तो service tier के अनुसार Group by करें
आउटपुट टोकन पर ध्यान दें, क्योंकि वे लेटेंसी को सबसे अधिक प्रभावित करते हैं
अधिक गहन विश्लेषण के लिए, Activity Data एक्सपोर्ट करें और समय के साथ प्रति अनुरोध टोकन की जांच करें.
7. सपोर्ट के साथ क्या साझा करें (यदि ज़रूरत हो)
यदि आप सपोर्ट से संपर्क करते हैं, तो इसमें शामिल करें:
प्रभावित Org IDs (यह महत्वपूर्ण है)
प्रभावित एंडपॉइंट्स (Chat Completions, Responses, आदि) (यह महत्वपूर्ण है)
प्रभावित मॉडल (यह महत्वपूर्ण है)
क्या यह scale या priority tier पर है? (यह महत्वपूर्ण है)
लेटेंसी या त्रुटि के लिए timezone सहित समय सीमाएं (यह महत्वपूर्ण है)
संबंधित x-request-id या X-Client-Request-Id (अक्सर महत्वपूर्ण. यदि संभव हो तो शामिल करें)
दिए गए अनुरोधों के timezone सहित timestamps (या कम से कम तारीख)
लेटेंसी - यदि आप धीमे अनुरोधों के उदाहरण साझा कर रहे हैं, तो बताएं कि आपकी तरफ़ कितना समय लगा. आदर्श रूप से, अनुरोध कब भेजा गया और कब प्राप्त हुआ, उसके timestamps भी शामिल करें.
त्रुटियां - कृपया विफल/त्रुटिपूर्ण अनुरोधों का अनुमानित प्रतिशत, response code(s), error message(s), और त्रुटि प्रतिक्रिया प्राप्त होने में कितना समय लगा, यह साझा करें
अनुरोधों से संबंधित Project id
क्या यह डेटा रेज़िडेंसी अनुरोधों को प्रभावित कर रहा है? यदि हां, तो कौन से?
आप जो रुझान देख रहे हैं उनका विवरण
त्रुटियां: विफल/त्रुटिपूर्ण अनुरोधों का अनुमानित %
लेटेंसी: कौन से percentiles प्रभावित हैं (p50 / p90 / p95 / p99), और ग्राहक के baseline की तुलना में वे कितने अधिक हैं
दोनों: त्रुटि या लेटेंसी डेटा के screenshots या तालिका (आपने कैसे निर्धारित किया कि त्रुटि दर या लेटेंसी अपेक्षा से अधिक है?)
सामान्य समस्या निवारण परिदृश्य
Timeouts होते हैं लेकिन Service Health सामान्य दिखता है
संभावित कारण: अनुरोध OpenAI तक पहुंचने से पहले ही timeout हो रहे हैं.
जांच करें:
क्लाइंट या प्रॉक्सी timeout सेटिंग्स
स्थानीय नेटवर्क या load balancer में परिवर्तन
Service Health डैशबोर्ड में 499 त्रुटियों की उपस्थिति (ये आपके अपने सिस्टम में 5xx त्रुटियों के रूप में दिख सकती हैं).
डिप्लॉयमेंट के बिना लेटेंसी बढ़ गई
संभावित कारण: आउटपुट टोकन आकार या रीज़निंग उपयोग बढ़ गया और\or ट्रैफ़िक service tiers के बीच शिफ्ट हो गया
जांच करें:
Usage डैशबोर्ड में प्रति अनुरोध औसत आउटपुट टोकन (इसके लिए डेटा डाउनलोड करके आउटपुट टोकन को कुल अनुरोधों से विभाजित करना होगा).
Service Health डैशबोर्ड में Request Time और TTFT percentiles.
Priority या Scale Tier धीमा दिखाई देता है
संभावित कारण: मेट्रिक्स टियरों के बीच मिल गए हैं (अर्थात standard-tier ट्रैफ़िक paid-tier प्रदर्शन को छिपा रहा है)
जांच करें:
फ़िल्टर एक ही टियर और मॉडल तक सीमित हों
टियरों के बीच टोकन वेग की तुलना
5XX त्रुटियों में स्पाइक
संभावित कारण: अस्थायी विफलताएं, जो ट्रैफ़िक के एक छोटे प्रतिशत को प्रभावित कर रही हैं.
जांच करें:
त्रुटि दर प्रतिशत
क्या उसी समय ट्रैफ़िक वॉल्यूम बदला था
समस्या केवल एक प्रोजेक्ट को प्रभावित करती है
संभावित कारण: प्रोजेक्ट-विशिष्ट कॉन्फ़िगरेशन या उपयोग पैटर्न.
जांच करें:
प्रोजेक्ट-स्तरीय फ़िल्टरिंग
अप्रभावित प्रोजेक्ट्स के साथ तुलना
अंतिम मुख्य बातें
मेट्रिक्स की व्याख्या करने से पहले मॉडल, टियर, और जहां प्रासंगिक हो वहां प्रोजेक्ट के अनुसार फ़िल्टर करें
लेटेंसी विश्लेषण के लिए औसत नहीं, percentiles का उपयोग करें
छोटी त्रुटि दरें अपेक्षित हैं
गायब डेटा आमतौर पर upstream समस्याओं का संकेत देता है
Usage डेटा यह समझाने में मदद कर सकता है कि लेटेंसी क्यों बदली. Service Health यह दिखाने में मदद करता है कि कब