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