العمليات واستكشاف الأخطاء وإصلاحها
راقب عمليات نشر بوابة النماذج (Model Gateway) وصنها واستكشف أخطاءها وأصلحها، بما في ذلك تحديثات تكوين النماذج، وتدوير بيانات الاعتماد، ومراقبة الصحة، وجمع السجلات، وحل مشكلات الاتصال والمصادقة الشائعة.
بعد النشر، تساعد الإدارة التشغيلية المستمرة لبوابة النماذج (Model Gateway) في ضمان الوصول الموثوق إلى نماذج الذكاء الاصطناعي المهيأة وتقليل انقطاع الخدمة. يمكن للمسؤولين مراجعة تكوينات النماذج النشطة، وتحديث بيانات اعتماد الموفرين، وتدوير الأسرار، ومراقبة صحة البوابة، وجمع المعلومات التشخيصية عند حدوث مشكلات.
عرض النماذج المهيأة
هناك مستويان لعرض النماذج — ما هو موجود في ملف التكوين وما قامت bob-inference بتحميله بالفعل في وقت التشغيل.
- مستوى التكوين — استرداد تكوين بوابة النماذج الحالي من ConfigMap الخاص بالاستدلال:
oc get cm bob-inference-config -n <bob-namespace> -o yaml | yq '.data."config.yaml"' - مستوى وقت التشغيل — ما سجلته
bob-inferenceوتوجه الطلبات إليه بنشاط: استعلم عن نقطة النهاية/v1/modelsمباشرةً (راجع التحقق من اتصال النماذج).
تسرد نقطة نهاية /v1/models في وقت التشغيل النماذج التي تحتوي على exposed: true فقط. ويعد ملف التكوين هو الطريقة الوحيدة لرؤية المجموعة الكاملة من النماذج المهيأة.
تحديث بيانات اعتماد الموفرين
يتم تركيب بيانات الاعتماد كمتغيرات بيئة من bob.modelGateway.secrets. ويعد تحديثها عملية من خطوتين — تحديث قيمة السر، ثم إعادة تشغيل خدمة الاستدلال لتحميل التركيب الجديد.
تحديث السر
عدّل المورد المخصص Bob وطبّق القيمة الجديدة:
oc edit bob <instance-name> -n <bob-namespace>
# Update the value under bob.modelGateway.secretsإعادة تشغيل خدمة الاستدلال
أعد تشغيل خدمة الاستدلال (Inference Service) حتى يتم تركيب السر الجديد:
oc rollout restart deploy/inference-service -n <bob-namespace>
oc rollout status deploy/inference-service -n <bob-namespace>يجب إعادة تشغيل pod الخاص بخدمة الاستدلال بعد أي تحديث للأسرار. يمكن تجميع تغييرات تكوين النماذج (إضافة النماذج أو إزالتها، وتغيير base_url) وتغييرات الأسرار في تحديث واحد للمورد المخصص يتبعه إعادة تشغيل واحدة.
تدوير الأسرار (Rotating secrets)
يتبع تدوير الأسرار النمط نفسه لتحديث بيانات الاعتماد، مع عناية إضافية بشأن التوقيت لتجنب فترات التوقف.
التسلسل الموصى به للتدوير بدون توقف عن العمل:
- حدّث
bob.modelGateway.secretsبقيمة بيانات الاعتماد الجديدة. - أعد تشغيل خدمة الاستدلال:
oc rollout restart deploy/inference-service -n <bob-namespace>. - تأكد من عمل بيانات الاعتماد الجديدة باستخدام اختبار الاستدلال من التحقق بعد التثبيت.
- قم بإلغاء بيانات الاعتماد القديمة من جانب موفر الخدمة فقط بعد التأكد من صحة الـ pod وعمله بشكل سليم.
ملاحظات خاصة بموفري الخدمات:
openai_compatible/ مفاتيح API — يسري مفعول المفتاح الجديد فورًا عند إعادة التشغيل. من الآمن إلغاء المفتاح القديم بمجرد أن يصبح الـ pod سليمًا.bedrock— تأكد من أن مفتاح وصول IAM الجديد نشط في AWS قبل إعادة التشغيل. قد يستغرق انتشار IAM بضع ثوانٍ.vertex— أنشئ مفتاح حساب الخدمة الجديد وقم بتشفيره بـ base64، وحدّث السر، ثم أعد التشغيل وتحقق، ثم احذف المفتاح القديم في GCP.ca_cert_pem— لتجديد الشهادة، تحقق من أن الشهادة الجديدة غير منتهية الصلاحية قبل التطبيق. راجع التحقق من شهادات TLS.
مراقبة صحة البوابة
عدد مرات إعادة تشغيل الـ pod — يعد ارتفاع عدد مرات إعادة التشغيل إشارة مبكرة على فشل متكرر في بدء التشغيل (تركيب سر خاطئ، خطأ في تحليل التكوين):
oc get pods -n <bob-namespace> -l app=bob-inference \
-o custom-columns='NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount'فحوصات الجاهزية والنشاط (Liveness and readiness probes) — تحقق من تكوين الفحص الحالي وحالته:
oc describe deploy/bob-inference -n <bob-namespace> | grep -A 10 "Liveness\|Readiness"فحص الصحة الدوري — تعمل نقطة نهاية /v1/models كفحص نشاط بسيط. إذا أرجعت قائمة نماذج صالحة، فإن البوابة تعمل. يمكن استطلاع ذلك من خلال أداة مراقبة أو مهمة cron داخل المجموعة.
جمع السجلات والتشخيصات
السجلات لإطار زمني محدد (الأكثر فائدة عند التحقيق في حادث تم الإبلاغ عنه):
oc logs -n <bob-namespace> deploy/bob-inference \
--since-time="2025-01-01T12:00:00Z" > bob-inference.logالسجلات من مثيل pod سابق (إذا تمت إعادة تشغيل الـ pod واختفت سجلات الفشل):
oc logs -n <bob-namespace> deploy/bob-inference --previousحزمة تشخيص كاملة للدعم:
oc describe pod -n <bob-namespace> -l app=bob-inference >> diagnostics.txt
oc get events -n <bob-namespace> --sort-by='.lastTimestamp' >> diagnostics.txt
oc logs -n <bob-namespace> deploy/bob-inference --since=1h >> diagnostics.txtتحتوي حزمة التشخيص على أسماء متغيرات بيئة الـ pod ولكنها لا تحتوي على قيم الأسرار (يتم تركيب الأسرار، ولا تُطبع في السجلات). راجع السجلات للتأكد من عدم وجود أي مخرجات لبيانات الاعتماد عن طريق الخطأ قبل إرسالها إلى الدعم.
استكشاف أخطاء الاتصال والمصادقة وإصلاحها
النموذج لا يظهر في /v1/models
- تحقق مما إذا تم تعيين
exposed: false— إذا كان الأمر كذلك، فهذا هو السلوك المتوقع. - تحقق من سجلات بدء التشغيل بحثًا عن خطأ تسجيل لـ
model_nameهذا. - تحقق من كتلة الموفر — صحة
base_url، ومعرفmodel، وبيانات الاعتماد.
401 Unauthorized في طلبات الاستدلال
- تأكد من أن قيمة السر في
bob.modelGateway.secretsصحيحة ومحدثة. - تأكد من أن مرجع
env.<VAR>في تكوين النموذج يتطابق تمامًا مع اسم مفتاح السر (حساس لحالة الأحرف). - أعد تشغيل خدمة الاستدلال وحاول مرة أخرى — ربما تم تحديث السر دون إعادة التشغيل.
- اختبر بيانات الاعتماد خارج النطاق. راجع التحقق من المصادقة.
502 Bad Gateway أو connection refused
- تأكد من أن نقطة نهاية النموذج تعمل ويمكن الوصول إليها من المجموعة. راجع اختبار الاتصال.
- تحقق من مشكلات
base_url— الشرطات المائلة اللاحقة، والبروتوكول الخاطئ (httpمقابلhttps)، والمنفذ الخاطئ. - تحقق من تغييرات سياسة الشبكة التي قد تكون حظرت حركة البيانات الصادرة منذ التثبيت.
certificate signed by unknown authority
- تأكد من تعيين
ca_cert_pemوإشارته إلى متغير بيئة صالح. - تأكد من وجود متغير البيئة في
bob.modelGateway.secrets. - تحقق من عدم انتهاء صلاحية الشهادة:
openssl x509 -noout -dates. - تأكد من أن الشهادة تغطي اسم مضيف نقطة النهاية من خلال فحص أسماء البدائل للموضوع (Subject Alternative Names).
pod خدمة الاستدلال في حالة CrashLoopBackOff
- افحص السجلات من المثيل السابق:
oc logs --previous. - ابحث عن أخطاء في تحليل التكوين — تنسيق YAML غير صحيح في تكوين بوابة النماذج.
- ابحث عن تركيبات الأسرار المفقودة في قسم الأحداث:
oc describe pod. - تأكد من صحة تنسيق YAML لتكوين بوابة النماذج قبل إعادة التطبيق.