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