اہم لنکس
سروس ہیلتھ ڈیش بورڈ (فی الحال صرف Enterprise API صارفین کے لیے دستیاب ہے)
صحیح ڈیفالٹس سے شروع کریں
جب آپ سروس ہیلتھ ڈیش بورڈ کھولتے ہیں، تو یہ ڈیفالٹ طور پر دکھاتا ہے:
تمام پروجیکٹس
گزشتہ 30 دن
گھنٹہ وار ریزولوشن
یہ منظر صرف ابتدائی سمجھ کے لیے مفید ہے. معنی خیز ازالے کے لیے ہمیشہ فلٹرنگ ضروری ہے.
تحقیق سے پہلے فلٹر کریں
درست فلٹرنگ سب سے اہم قدم ہے. زیادہ تر غلط تشریحات ماڈلز، ٹیئرز، یا پروجیکٹس کو ملانے سے ہوتی ہیں.
ماڈل کے لحاظ سے فلٹر کریں (ایک وقت میں ایک)
ہمیشہ ایک ہی ماڈل تک فلٹر کریں.
کیوں:
کم ٹریفک والے ماڈلز کے مسائل زیادہ والیوم والی ٹریفک سے چھپ سکتے ہیں
زیادہ والیوم والے ماڈلز مقامی مسائل کو عالمی دکھا سکتے ہیں
مختلف ماڈلز کے کارکردگی اہداف مختلف ہوتے ہیں
نوٹ: متعدد ماڈلز منتخب کرنے سے وہ مجموعی طور پر دکھتے ہیں—یہ ان کے درمیان سوئچ نہیں کرتا.
سروس ٹیئر کے لحاظ سے فلٹر کریں
اگر آپ ایک سے زیادہ ٹیئر استعمال کرتے ہیں (standard، priority، scale)، تو ہمیشہ اسی ٹیئر تک فلٹر کریں جس کی آپ تحقیق کر رہے ہیں.
کیوں:
ٹیئرز کی کارکردگی خصوصیات مختلف ہوتی ہیں
Priority اور scale ٹیئرز کے متعین SLAs ہوتے ہیں
ٹیئرز کو ملانے سے paid-tier کارکردگی دھندلی ہو جاتی ہے
یہ لیٹنسی تجزیے کے لیے خاص طور پر اہم ہے.
پروجیکٹ کے لحاظ سے فلٹر کریں
ڈیفالٹ طور پر، سروس ہیلتھ تمام پروجیکٹس دکھاتا ہے.
ازالے کے لیے، اس پروجیکٹ یا پروجیکٹس تک فلٹر کریں جہاں مسئلہ دیکھا گیا تھا.
کیوں:
ایک ہی زیادہ والیوم والا پروجیکٹ میٹرکس پر غالب آ سکتا ہے.
چھوٹے متاثرہ پروجیکٹس غیر متعلقہ ٹریفک سے چھپ سکتے ہیں.
صرف اس صورت میں "تمام پروجیکٹس" منتخب رہنے دیں جب آپ کو یقین ہو کہ مسئلہ واقعی پوری تنظیم میں ہے.
خرابیوں کا ازالہ
HTTP درخواستوں کا منظر استعمال کریں
خرابیوں کی تحقیق کے لیے:
ماڈل اور سروس ٹیئر کے لحاظ سے فلٹر کریں.
Uptime ٹیب کے بجائے HTTP Requests ٹیب کھولیں.
یہ منظر HTTP اسٹیٹس کوڈ کے لحاظ سے کل درخواستیں اور خرابیوں کی تعداد دکھاتا ہے. باریک اسپائکس یا تبدیلیوں کی شناخت کے لیے منٹ کی سطح کی ریزولوشن تک زوم کریں.
خرابی کی شرحیں سمجھیں، تعداد نہیں
کسی بھی پروڈکشن سسٹم میں کچھ خرابیوں کی توقع ہوتی ہے. خام کل تعداد کے بجائے خرابی کے فیصد پر توجہ دیں.
آپ کا کل والیوم جتنا بڑا ہوگا، انتہائی کم خرابی کی شرح کے باوجود خرابیوں کی ممکنہ تعداد اتنی ہی زیادہ ہوگی.
جب سروس ہیلتھ میں خرابیوں کا ڈیٹا غائب ہو
اگر آپ کو کلائنٹ سائیڈ خرابیوں نظر آئیں لیکن سروس ہیلتھ میں متعلقہ ڈیٹا نہ ہو:
غالباً درخواستیں OpenAI تک نہیں پہنچیں.
مسئلہ عموماً اپ اسٹریم ہوتا ہے (ٹائم آؤٹس، پراکسیز، نیٹ ورکنگ).
یہ سخت کلائنٹ سائیڈ ٹائم آؤٹس کے ساتھ عام ہے.
لیٹنسی کا ازالہ
لیٹنسی تجزیہ priority اور scale ٹیئرز پر سب سے زیادہ معنی خیز ہوتا ہے، جن کے متعین SLAs ہوتے ہیں. standard ٹیئر میں لیٹنسی کا تغیر زیادہ وسیع ہو سکتا ہے، اور اس میں لیٹنسی کی ضمانت نہیں ہوتی.
اہم میٹرکس
ہر میٹرک دیکھنے کے لیے متعلقہ ٹیب پر کلک کریں:
ٹوکن رفتار: فی سیکنڈ بننے والے ٹوکنز؛ پرومپٹ سائز سے آزاد.
درخواست کا وقت: کل درخواست کا دورانیہ؛ آؤٹ پٹ سائز اور ریزننگ سے بہت متاثر ہوتا ہے.
پہلے ٹوکن تک وقت (TTFT): پہلا ٹوکن بننے تک کا وقت؛ غیر کیش شدہ ان پٹ پرومپٹ سائز اور ریزننگ سے بہت متاثر ہوتا ہے.
ہمیشہ P50 / P75 / P95 پرسنٹائلز کا جائزہ لیں. اوسط حقیقی صارف کے اثر کو چھپا سکتے ہیں.
6. لیٹنسی کو ٹوکن استعمال سے جوڑنا
سروس ہیلتھ دکھاتا ہے کہ رویہ کب بدلا. استعمال کا ڈیٹا یہ سمجھانے میں مدد کرتا ہے کہ کیوں.
استعمال کے ڈیش بورڈ میں، یہ یقینی بنانے کے لیے کہ آپ سروس ہیلتھ ڈیش بورڈ میں اپنے منظر سے متعلق ڈیٹا دیکھ رہے ہیں، درج ذیل کریں:
اسی پروجیکٹ اور ماڈل تک فلٹر کریں.
اگر قابل اطلاق ہو، سروس ٹیئر کے لحاظ سے گروپ کریں.
آؤٹ پٹ ٹوکنز پر توجہ دیں، جو لیٹنسی کو سب سے زیادہ متاثر کرتے ہیں.
زیادہ گہرے تجزیے کے لیے، Activity Data ایکسپورٹ کریں اور وقت کے ساتھ فی درخواست ٹوکنز کا جائزہ لیں.
7. سپورٹ کے ساتھ کیا شیئر کریں (اگر ضرورت ہو)
اگر آپ سپورٹ سے رابطہ کریں، تو شامل کریں:
متاثرہ Org IDs (اہم)
متاثرہ اینڈپوائنٹس، جیسے Chat Completions یا Responses (اہم)
متاثرہ ماڈلز (اہم)
آیا یہ Scale یا Priority ٹیئر پر ہے (اہم)
لیٹنسی یا خرابیوں کے لیے ٹائم زون کے ساتھ وقت کی حدود (اہم)
متعلقہ x-request-id یا X-Client-Request-Id، اگر دستیاب ہو
آپ جو درخواستیں فراہم کرتے ہیں ان کے لیے ٹائم زون کے ساتھ ٹائم اسٹیمپس، یا کم از کم تاریخ
اگر دستیاب ہو، تو یہ بھی شامل کریں:
درخواستوں سے متعلق پروجیکٹ ID
آیا ڈیٹا ریزیڈنسی درخواستیں متاثر ہیں، اور کون سی
آپ جو رجحانات دیکھ رہے ہیں ان کی تفصیلات
مسئلے کی قسم کے لیے، شامل کریں:
خرابیاں: ناکام یا خرابی دینے والی درخواستوں کا تخمینی فیصد، رسپانس کوڈز، ایرر میسیجز، اور ایرر رسپانس موصول ہونے میں کتنا وقت لگا.
لیٹنسی: کون سے پرسنٹائلز متاثر ہیں (P50 / P90 / P95 / P99)، وہ گاہک کی بنیادی سطح کے مقابلے کتنے زیادہ ہیں، اور بھیجنے اور وصول کرنے کے ٹائم اسٹیمپس کے ساتھ سست درخواستوں کی مثالیں.
دونوں: خرابی یا لیٹنسی ڈیٹا کے اسکرین شاٹس یا ٹیبل، نیز آپ نے کیسے طے کیا کہ خرابی کی شرحیں یا لیٹنسی توقع سے زیادہ تھیں.
ازالے کے عام منظرنامے
ٹائم آؤٹس ہوتے ہیں مگر سروس ہیلتھ نارمل دکھتا ہے
ممکنہ وجہ: درخواستیں OpenAI تک پہنچنے سے پہلے ٹائم آؤٹ ہو رہی ہیں.
چیک کریں:
کلائنٹ یا پراکسی ٹائم آؤٹ سیٹنگز
مقامی نیٹ ورک یا لوڈ بیلنسر کی تبدیلیاں
سروس ہیلتھ ڈیش بورڈ میں 499 خرابیوں کی موجودگی (یہ آپ کے اپنے سسٹمز میں 5xx خرابیوں کے طور پر دکھ سکتی ہیں).
ڈپلائمنٹ کے بغیر لیٹنسی بڑھ گئی
ممکنہ وجہ: آؤٹ پٹ ٹوکن سائز یا ریزننگ کا استعمال بڑھ گیا اور/یا ٹریفک سروس ٹیئرز کے درمیان منتقل ہوئی.
چیک کریں:
استعمال کے ڈیش بورڈ میں فی درخواست اوسط آؤٹ پٹ ٹوکنز (اس کے لیے ڈیٹا ڈاؤن لوڈ کر کے آؤٹ پٹ ٹوکنز کو کل درخواستوں سے تقسیم کرنا ضروری ہے).
سروس ہیلتھ ڈیش بورڈ میں Request Time اور TTFT پرسنٹائلز.
Priority یا اسکیل ٹیئر سست دکھائی دیتا ہے
ممکنہ وجہ: میٹرکس مختلف ٹیئرز میں مل گئے ہیں، یعنی standard-tier ٹریفک paid-tier کارکردگی کو چھپا رہی ہے.
چیک کریں:
فلٹرز کو ایک ہی ٹیئر اور ماڈل تک محدود رکھا گیا ہے.
ٹیئرز کے درمیان ٹوکن رفتار کا موازنہ.
5XX خرابیوں میں اضافہ
ممکنہ وجہ: عارضی ناکامیاں جو ٹریفک کے ایک چھوٹے فیصد کو متاثر کر رہی ہیں.
چیک کریں:
خرابی کی شرح کا فیصد
آیا اسی وقت ٹریفک والیوم بدلا تھا
مسئلہ صرف ایک پروجیکٹ کو متاثر کرتا ہے
ممکنہ وجہ: پروجیکٹ مخصوص کنفیگریشن یا استعمال کا پیٹرن.
چیک کریں:
پروجیکٹ سطح کی فلٹرنگ
غیر متاثرہ پروجیکٹس کے ساتھ موازنہ
حتمی نکات
میٹرکس کی تشریح سے پہلے، جہاں متعلقہ ہو، ماڈل، ٹیئر، اور پروجیکٹ کے لحاظ سے فلٹر کریں.
لیٹنسی تجزیے کے لیے اوسط نہیں، پرسنٹائلز استعمال کریں.
خرابی کی چھوٹی شرحیں متوقع ہیں.
غائب ڈیٹا عموماً اپ اسٹریم مسائل کی نشاندہی کرتا ہے.
استعمال کا ڈیٹا یہ سمجھانے میں مدد کر سکتا ہے کہ لیٹنسی کیوں بدلی؛ سروس ہیلتھ دکھاتا ہے کہ رویہ کب بدلا.