روابط مهمة
لوحة معلومات صحة الخدمة (متاحة حاليًا فقط لعملاء واجهة برمجة التطبيقات من فئة Enterprise)
ابدأ بالإعدادات الافتراضية الصحيحة
عند فتح لوحة معلومات صحة الخدمة، تكون افتراضيًا على:
كل المشاريع
آخر 30 يومًا
دقة بالساعة
هذا العرض مفيد للتوجيه فقط. يتطلب استكشاف المشكلات المفيد دائمًا التصفية.
التصفية قبل التحقيق
التصفية الصحيحة هي الخطوة الأهم. تنتج معظم التفسيرات الخاطئة عن خلط النماذج أو المستويات أو المشاريع.
التصفية حسب النموذج (واحدًا تلو الآخر)
صفِّ دائمًا إلى نموذج واحد.
السبب:
يمكن إخفاء المشكلات في النماذج منخفضة الحركة بسبب حركة أعلى حجمًا
قد تجعل النماذج عالية الحجم المشكلات المحلية تبدو عالمية
للنماذج المختلفة أهداف أداء مختلفة
ملاحظة: يؤدي تحديد عدة نماذج إلى تجميعها، ولا يبدّل بينها.
التصفية حسب مستوى الخدمة
إذا كنت تستخدم أكثر من مستوى واحد (قياسي، أولوية، سعة)، فصفِّ دائمًا إلى المستوى الذي تحقق فيه.
السبب:
للمستويات خصائص أداء مختلفة
لدى مستويَي الأولوية والسعة اتفاقيات مستوى خدمة محددة
خلط المستويات يحجب أداء المستوى المدفوع
هذا مهم خاصةً لتحليل زمن الاستجابة.
التصفية حسب المشروع
افتراضيًا، تعرض صحة الخدمة كل المشاريع.
لاستكشاف المشكلات وإصلاحها، صفِّ إلى المشروع أو المشاريع التي لوحظت فيها المشكلة.
السبب:
يمكن لمشروع واحد عالي الحجم أن يهيمن على المقاييس.
يمكن أن تُحجب المشاريع الأصغر المتأثرة بحركة بيانات غير ذات صلة.
اترك «كل المشاريع» محددًا فقط إذا كنت تعتقد أن المشكلة على مستوى المؤسسة بأكملها فعلًا.
استكشاف الأخطاء وإصلاحها
استخدم عرض طلبات HTTP
للتحقيق في الأخطاء:
صفِّ حسب النموذج ومستوى الخدمة.
افتح علامة تبويب طلبات HTTP بدلًا من علامة تبويب وقت التشغيل.
يعرض هذا العرض إجمالي الطلبات وعدد الأخطاء حسب رمز حالة HTTP. قرّب العرض إلى دقة مستوى الدقيقة لتحديد الارتفاعات أو التغيرات الدقيقة.
فسّر معدلات الأخطاء، لا الأعداد
بعض الأخطاء متوقعة في أي نظام إنتاجي. ركّز على النسبة المئوية للأخطاء، وليس الإجماليات الخام.
كلما زاد حجمك الإجمالي، زاد العدد المحتمل للأخطاء حتى مع معدل أخطاء منخفض للغاية.
عندما تكون الأخطاء مفقودة من صحة الخدمة
إذا رأيت أخطاء من جانب العميل ولكن لا توجد بيانات مقابلة في صحة الخدمة:
من المرجح أن الطلبات لم تصل إلى OpenAI.
تكون المشكلة عادةً في المنبع (مهلات، وكلاء، شبكات).
هذا شائع مع مهلات جانب العميل الصارمة.
استكشاف مشكلات زمن الاستجابة وإصلاحها
يكون تحليل زمن الاستجابة أكثر معنى في مستويَي الأولوية والسعة، اللذين لديهما اتفاقيات مستوى خدمة محددة. قد يُظهر المستوى القياسي تباينًا أوسع في زمن الاستجابة، ولا يضمن زمن استجابة محددًا.
المقاييس الرئيسية
لعرض كل مقياس، انقر على علامة التبويب ذات الصلة:
سرعة الرموز: الرموز المُولّدة في الثانية؛ مستقلة عن حجم المطالبة.
وقت الطلب: إجمالي مدة الطلب؛ يتأثر بشدة بحجم الإخراج والاستدلال.
الوقت حتى أول رمز (TTFT): الوقت حتى يتم توليد أول رمز؛ يتأثر بشدة بحجم مطالبة الإدخال غير المخزنة مؤقتًا وبالاستدلال.
راجع دائمًا النسب المئوية P50 / P75 / P95. يمكن للمتوسطات أن تخفي التأثير الفعلي على المستخدمين.
6. ربط زمن الاستجابة باستخدام الرموز
تُظهر صحة الخدمة متى تغيّر السلوك. تساعد بيانات الاستخدام في تفسير السبب.
في لوحة معلومات الاستخدام، نفّذ ما يلي للتأكد من أنك تنظر إلى البيانات ذات الصلة بعرضك في لوحة معلومات صحة الخدمة:
صفِّ إلى المشروع والنموذج نفسيهما.
جمّع حسب مستوى الخدمة، إن أمكن.
ركّز على رموز الإخراج، فهي الأكثر تأثيرًا في زمن الاستجابة.
لتحليل أعمق، صدّر بيانات النشاط وافحص الرموز لكل طلب بمرور الوقت.
7. ما يجب مشاركته مع الدعم (إذا لزم الأمر)
إذا تواصلت مع الدعم، فأدرج:
معرّفات المؤسسات المتأثرة (مهم)
نقاط النهاية المتأثرة، مثل Chat Completions أو Responses (مهم)
النماذج المتأثرة (مهم)
ما إذا كان ذلك على مستوى السعة أو مستوى الأولوية (مهم)
النطاقات الزمنية مع المنطقة الزمنية لزمن الاستجابة أو الأخطاء (مهم)
x-request-id أو X-Client-Request-Id ذي الصلة، إذا كان متاحًا
الطوابع الزمنية مع المنطقة الزمنية، أو التاريخ على الأقل، للطلبات التي تقدمها
إذا كان متاحًا، فأدرج أيضًا:
معرّف المشروع المرتبط بالطلبات
ما إذا كانت طلبات إقامة البيانات متأثرة، وأيها
أوصاف الاتجاهات التي تراها
بالنسبة إلى نوع المشكلة، أدرج:
الأخطاء: النسبة المئوية التقريبية للطلبات الفاشلة أو التي تُرجع أخطاء، ورموز الاستجابة، ورسائل الخطأ، والوقت الذي استغرقه تلقي استجابة الخطأ.
زمن الاستجابة: النسب المئوية المتأثرة (P50 / P90 / P95 / P99)، ومدى ارتفاعها مقارنة بخط الأساس لدى العميل، وأمثلة على الطلبات البطيئة مع طوابع وقت الإرسال والاستلام.
كلاهما: لقطات شاشة أو جدول لبيانات الأخطاء أو زمن الاستجابة، بالإضافة إلى كيفية تحديدك أن معدلات الأخطاء أو زمن الاستجابة كانت أعلى من المتوقع.
سيناريوهات شائعة لاستكشاف المشكلات وإصلاحها
تحدث مهلات لكن صحة الخدمة تبدو طبيعية
السبب المحتمل: تنتهي مهلة الطلبات قبل وصولها إلى OpenAI.
تحقق من:
إعدادات مهلة العميل أو الوكيل
تغييرات الشبكة المحلية أو موازن التحميل
وجود أخطاء 499 في لوحة معلومات صحة الخدمة (قد تظهر هذه كأخطاء 5xx في أنظمتك الخاصة).
زمن الاستجابة ازداد دون نشر
السبب المحتمل: زاد حجم رموز الإخراج أو استخدام الاستدلال و/أو انتقلت حركة البيانات بين مستويات الخدمة.
تحقق من:
متوسط رموز الإخراج لكل طلب في لوحة معلومات الاستخدام (يتطلب تنزيل البيانات وقسمة رموز الإخراج على إجمالي الطلبات).
النسب المئوية لوقت الطلب وTTFT في لوحة معلومات صحة الخدمة.
يبدو مستوى الأولوية أو مستوى السعة بطيئًا
السبب المحتمل: يتم خلط المقاييس عبر المستويات، ما يعني أن حركة بيانات المستوى القياسي تحجب أداء المستوى المدفوع.
تحقق من:
أن المرشحات مقتصرة على مستوى ونموذج واحد.
مقارنة سرعة الرموز بين المستويات.
ارتفاع مفاجئ في أخطاء 5XX
السبب المرجح: إخفاقات عابرة تؤثر في نسبة صغيرة من حركة البيانات.
تحقق من:
النسبة المئوية لمعدل الأخطاء
ما إذا كان حجم حركة البيانات قد تغيّر في الوقت نفسه
المشكلة تؤثر في مشروع واحد فقط
السبب المرجح: تكوين أو نمط استخدام خاص بالمشروع.
تحقق من:
التصفية على مستوى المشروع
المقارنة مع المشاريع غير المتأثرة
الخلاصات النهائية
صفِّ حسب النموذج والمستوى والمشروع عند الاقتضاء قبل تفسير المقاييس.
استخدم النسب المئوية، لا المتوسطات، لتحليل زمن الاستجابة.
من المتوقع وجود معدلات أخطاء صغيرة.
عادةً ما تشير البيانات المفقودة إلى مشكلات في المنبع.
يمكن أن تساعد بيانات الاستخدام في تفسير سبب تغيّر زمن الاستجابة؛ وتُظهر صحة الخدمة متى تغيّر السلوك.