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