مجموعة أدوات المراقبة: بروميثيوس، جرافانا، DCGM، لوكي لخوادم الذكاء الاصطناعي

خادم الذكاء الاصطناعي الذي لا يراقبه أحد هو خادم يعاني من تباطؤ خفي، وتسرب في ذاكرة الوصول العشوائي للفيديو، وتراكم أخطاء تصحيح الأخطاء، أو يتم إيقافه بسبب نفاد الذاكرة في الساعة 03:00 صباحًا - وتكتشف ذلك بعد ثلاثة أيام عندما يسأل أحدهم عن سبب إنتاج عملية الضبط الدقيق لبيانات غير مفهومة. معظم أسوأ حالات الفشل في وحدة معالجة الرسومات غير مرئية للتطبيق: لا يتم تسجيل التباطؤ الحراري في الخطأ القياسي، ولا تتسبب تصحيحات تصحيح الأخطاء في تعطل أي شيء على الفور، ويقوم برنامج إيقاف العمليات بسبب نفاد الذاكرة بإيقاف عملية ما، ثم يعيد المنسق تشغيلها بسلاسة. بدون مقاييس على الجهاز نفسه، لن ترى أيًا من هذا حتى بعد مرور أسبوع كامل.

مجموعة أدوات إدارة النظام القياسية (htop, df, uptimeلا يغطي نظام syslog هذا الأمر. تُعدّ وحدة معالجة الرسومات (GPU) أغلى مكون في الهيكل وأكثرها عرضةً للأعطال، ولها نظام قياس عن بُعد خاص بها يتطلب بنيةً مُفصّلة. تُقدّم هذه المقالة شرحًا مُفصّلًا لبنية هذا النظام - Prometheus وGrafana وDCGM-exporter وnode_exporter وLoki وAlertmanager - مُجمّعة في حزمة docker-compose واحدة نُشغّلها على كل خادم Kentino AI نُصدره.

الجمهور المستهدف هو شخص يقوم بإنشاء خادم ذكاء اصطناعي بأربعة أو ثمانية وحدات معالجة رسومية، ويمكنه كتابة ملف docker-compose ويريد الإجابة على سؤال "ما الذي يجب علي مراقبته فعليًا، وعند أي عتبة يجب أن أطلق الإنذار".

المكدس القياسي في عام 2026

خمسة مكونات تقوم بمعظم العمل. أما الباقي فهو مجرد إضافة.

إجمالي استهلاك الموارد أقل بكثير من 0.5% من نواة معالج واحدة على معالج EPYC ذي 96 نواة وذاكرة وصول عشوائي (RAM) تبلغ حوالي 700 ميجابايت. على خادم بسعة 256 جيجابايت و8 وحدات معالجة رسومية (GPU)، يُعد هذا خطأً بسيطًا جدًا. لم تعد مقولة "المراقبة تستنزف موارد التدريب" صحيحةً تقريبًا منذ عام 2019.

القرار المعماري الوحيد الذي يستحق اتخاذه مسبقًا: تشغيل النظام على جهاز افتراضي منفصل للإدارة أو جهاز صغير، وليس على خادم وحدة معالجة الرسومات نفسه. جهاز كمبيوتر صغير مخصص، أو جهاز NUC، أو عقدة خدمة EPYC، أو جهاز افتراضي على برنامج إدارة الأجهزة الافتراضية في المختبر - أي شيء عدا خادم وحدة معالجة الرسومات. هناك سببان: أولًا، عند تعطل خادم وحدة معالجة الرسومات (بسبب نفاد الذاكرة، أو انقطاع التيار الكهربائي، أو الإغلاق الحراري)، ستحتاج إلى سجل المقاييس لتشخيص ما حدث، وثانيًا، لن ترغب في أن تتنافس مهمة تدريب غير منضبطة مع Prometheus على الذاكرة وتُطلق تنبيهًا خاصًا بها. يعمل كل من DCGM-exporter وnode_exporter على مضيف وحدة معالجة الرسومات (وهذا ضروري لأنهما يقرآن الأجهزة المحلية)؛ بينما يعمل كل من Prometheus وGrafana وLoki وAlertmanager على الجهاز الافتراضي للإدارة ويقومون بجمع البيانات داخليًا.

مُصدِّر السلع المعبأة بالتيار المستمر — الشيء الوحيد الذي لا يمكنك الاستغناء عنه

يُعدّ برنامج إدارة وحدات معالجة الرسومات في مركز البيانات (DCGM) من NVIDIA المصدر المعتمد والموثوق لبيانات قياس أداء وحدات معالجة الرسومات. dcgm-exporter يعرض الحاوية مقاييس DCGM بتنسيق Prometheus على المنفذ 9400. وهو المكون الأهم في النظام، وهو الشيء الوحيد nvidia-smi لن يحل الاستطلاع محل الاستطلاع أبداً.

قم بالتثبيت عبر حاوية NGC (nvcr.io/nvidia/k8s/dcgm-exporter(الإصدار الحالي 4.x اعتبارًا من منتصف عام 2026) أو مخطط Helm الأصلي لـ Kubernetes. على Docker الأساسي، واحد docker run --gpus all --rm يكفي ذلك؛ ثم ينشر البرنامج حوالي 80 مقياسًا على :9400/metrics. تلك التي تهم فعلاً، مرتبة حسب مدى تكرار اكتشافها للمشاكل الحقيقية:

تُعد عدادات دواسة الوقود الميزة الأبرز. DCGM_FI_DEV_THERMAL_VIOLATION هو عداد رتيب بالنانو ثانية التي قضتها وحدة معالجة الرسومات (GPU) في وضع التباطؤ. احسب معدله على مدى 5 دقائق وستحصل على إجابة دقيقة لسؤال "هل خادمي محدود حراريًا الآن؟". بدونه، ستعتمد على التخمين بناءً على درجة الحرارة فقط، وهو أمر غير دقيق - فبطاقة 4090 ستخفض ترددها عند 83 درجة مئوية مع استمرار العمل بغض النظر عما تعرضه لوحة درجة الحرارة.

هناك سمتان غريبتان معروفتان لمصدري DCGM يجدر معرفتهما في عام 2026: بعض رموز XID (وخاصة XID 62) لا تظهر دائمًا من خلال DCGM_FI_DEV_XID_ERRORSوالمقياس هو مؤشر على آخر تم رصد XID، لذا قد يفشل في إعادة التعيين بعد الاسترداد دون إعادة تشغيل المُصدِّر. ويتمثل الحل في أيضا راقب مخزن الحلقة الخاص بالنواة عبر Loki للحصول على المعنى الحرفي NVRM: Xid خيط (المزيد عن ذلك أدناه). حزام وحمالات.

بالنسبة لبطاقات الرسومات المخصصة للمستهلكين (RTX 4090، 5090)، فإن بعض ميزات مركز بيانات DCGM غير مكتملة - فميزة MIG غير موجودة، وميزة NVLink غائبة في بطاقات Blackwell المخصصة للمستهلكين، وبعض عدادات ECC تُرجع القيمة صفر. ومع ذلك، لا يزال DCGM يعمل ويُبلغ عن البيانات المكشوفة؛ وهو البديل المجتمعي خفيف الوزن. nvidia_gpu_exporter (الذي يخدش nvidia-smiيُعدّ هذا خيارًا احتياطيًا مناسبًا إذا كنت لا ترغب في استخدام سلسلة تبعيات DCGM. بالنسبة إلى Pro 6000 Blackwell وL40 وL4 - أي شيء ضمن خط مراكز البيانات/الاحترافي - استخدم DCGM، وليس الغلاف.

node_exporter — نصف النظام

لا تُظهر مقاييس وحدة معالجة الرسومات سوى نصف الحقيقة. node_exporter ويغطي الباقي:

يتم رصد وضع الفشل "نفاد ذاكرة الوصول العشوائي للنظام، واستخدام برنامج إيقاف التشغيل بسبب نفاد الذاكرة لـ vLLM، وإعادة تشغيل الحاوية بسلاسة" هنا، وليس بواسطة DCGM. راقب node_memory_MemAvailable_bytes ويصدر تنبيهًا عندما ينخفض ​​إلى أقل من 5% من الإجمالي. في نظام لينكس، يتم تشغيل برنامج إنهاء العمليات بالقرب من 0% افتراضيًا، ولكن بحلول ذلك الوقت تكون العملية قد توقفت.

بروميثيوس - التكوين، والاحتفاظ، والتحجيم

بروميثيوس هو قاعدة بيانات السلاسل الزمنية وأداة تنسيق عمليات جمع البيانات. الإعدادات الافتراضية مناسبة؛ والإعدادان اللذان يُنصح بتغييرهما في اليوم الأول هما فاصل جمع البيانات وفترة الاحتفاظ بها.

يُعدّ فاصل جمع البيانات الذي يبلغ 15 ثانية نقطة انطلاق مثالية لخادم الذكاء الاصطناعي: فهو سريع بما يكفي لرصد أي ارتفاع مفاجئ في درجة الحرارة قبل أن يتحول إلى تقييد مستمر للأداء، وبطيء بما يكفي للحفاظ على تكلفة البيانات على مدى فترة زمنية معقولة. مدة الاحتفاظ الافتراضية هي 15 يومًا؛ بينما يُعدّ 30 يومًا مدة أفضل في سياق دليل بناء النظام، حيث يمكنك مقارنة أداء النظام اليوم بتغييرات الضبط التي أُجريت الشهر الماضي.

ميزانية التخزين عند جمع البيانات كل 15 ثانية، مع حوالي 80 مقياس DCGM × N وحدة معالجة رسومية + حوالي 400 مقياس node_exporter + حوالي 50 مقياس vLLM: ما يقارب 1.5-2 جيجابايت أسبوعيًا، أي ما يعادل 6-10 جيجابايت خلال 30 يومًا على جهاز بثمانية وحدات معالجة رسومية. يُنصح بتحديد مدة الاحتفاظ بالبيانات وحجمها كإجراء وقائي.

command:
  - "--storage.tsdb.retention.time=30d"
  - "--storage.tsdb.retention.size=20GB"

يؤدي أي من الحدين إلى ضغط البيانات؛ ويتم تطبيق الحد الذي يتم الوصول إليه أولاً. يمنحك تخصيص 100 جيجابايت مساحة تخزين كافية لأكثر من عام دون الحاجة إلى التفكير في الأمر.

لوحات معلومات Grafana - ابدأ باللوحات الجاهزة

لا تقم بإنشاء لوحات المعلومات من الصفر. لقد قام المجتمع بذلك بالفعل.

استورد أولًا اللوحتين 12239 و1860. فهما تغطيان حوالي 90% مما ترغب في رؤيته، وقد تم تحسينهما على مر السنين. ابدأ ببناء لوحتك الخاصة بعد شهر، عندما تعرف أي اللوحات ستفتحها فعليًا. التعديلات البسيطة التي يُنصح بإجرائها على أجهزة Kentino AI هي: ضبط لوحات عتبة درجة حرارة وحدة معالجة الرسومات (GPU) على نطاقات مناسبة لشركة Blackwell (يبدأ أداء 5090 عند حوالي 87 درجة مئوية، وRTX Pro 6000 عند حوالي 90 درجة مئوية)، وإضافة لوحة لكل فتحة PCIe تُظهر DCGM_FI_DEV_PCIE_LINK_GEN و DCGM_FI_DEV_PCIE_LINK_WIDTH لذا يمكنك أن ترى بنظرة سريعة ما إذا كان ارتفاع الركيزة قد انخفض من x16 إلى x8.

لوكي - سجلات توضح ما تُظهره المقاييس

تُخبرك المقاييس بما تغيّر، بينما تُخبرك السجلات بالسبب . Loki هي قاعدة بيانات سجلات Grafana، وPromtail هو برنامج إرسال الملفات الذي يتتبعها ويرسلها. وجّه Promtail إلى:

• /var/log/syslog و journalctl -k — رسائل نفاد الذاكرة في النواة، شكاوى متعلقة ببرنامج تشغيل NVIDIA، ملفات تفريغ XID
• /var/log/nvidia-installer.log — حالة تثبيت برنامج التشغيل
• مخرجات حاوية vLLM القياسية (عبر برنامج تشغيل سجل Docker JSON)
• سجلات التطبيقات من أي شيء يقوم العميل بتشغيله

الاستعلام ذو القيمة الأعلى في علامة تبويب "استكشاف" في Grafana هو:

{job="syslog"} |= "NVRM:"

يُظهر هذا كل رسالة من برنامج تشغيل NVIDIA في مخزن بيانات النواة الحلقي - أخطاء XID، وأعطال المراوح، وأحداث انقطاع الاتصال بالحافلة، ومهلات GSP RPC. قم بإقرانه مع DCGM_FI_DEV_XID_ERRORS تنبيه بروميثيوس، وستحصل على كل من المقياس المنظم والتفاصيل غير المنظمة في لوحة واحدة.

لا نقوم بنقل سجلات النظام إلى خادم خارجي افتراضيًا. يحتفظ Loki بها محليًا لمدة 30 يومًا، مع توفير أنفاق SSH عند الحاجة للوصول إلى Grafana. يمكن للعملاء الراغبين في الحصول على سجلات مركزية عبر خوادم متعددة توجيه Loki إلى S3 أو تشغيل نسخة إقليمية - وهذا يتعلق بالنشر، وليس بالبنية التحتية.

مقاييس vLLM وSGLang — قم بقياس التطبيق، وليس فقط الجهاز.

يُخبرك DCGM أن وحدة معالجة الرسومات مشغولة، لكنه لا يُخبرك ما إذا كانت طلبات الاستدلال ستُستجاب في غضون 200 مللي ثانية أو ثانيتين. لذلك، عليك تجهيز طبقة الخدمة.

يكشف vLLM /metrics يعمل بشكل أصلي على نفس المنفذ الذي يعمل عليه OpenAI API. مع الإعدادات الافتراضية، تكون نقطة النهاية عند :8000/metrics ينشر مقاييس بروميثيوس مع vllm: البادئة (التي تصبح) vllm_ بعد كشط بروميثيوس). تلك التي تستحق الكشط:

المزيج vllm:num_requests_waiting > 0 و DCGM_FI_DEV_GPU_UTIL < 90% هذا يعني أن قائمة الانتظار تتراكم بينما وحدة معالجة الرسومات (GPU) في وضع الخمول - وعادةً ما يكون السبب هو اختناق في مُجزئ الرموز أو مُجدول المهام، وليس في عملية الحساب نفسها. لا يظهر هذا إلا عند عرض كلا المقياسين في لوحة تحكم واحدة، وهذا هو الهدف الأساسي من توحيد بيانات التطبيق وبيانات الأجهزة في بروميثيوس واحد.

تعرض NVIDIA NIM نفس مقاييس vLLM تحت /v1/metrics دون إعادة تسميتها، لذا يمكن نقل لوحات معلومات vLLM وقواعد التنبيه الحالية إلى بيئة نشر NIM دون تغيير. ينشر SGLang مجموعة مماثلة على منفذه الخاص (الافتراضي 30000)؛ ويعرض خادم HTTP الخاص بـ llama.cpp مجموعة فرعية أصغر. ينشر Triton تصنيفه الخاص. أيًا كان ما تقدمه، اجمع بيانات التطبيق - وليس بيانات الجهاز فقط.

قواعد Alertmanager - القواعد الفعلية التي نوفرها

لوحات المعلومات جذابة. التنبيهات مفيدة. القواعد التالية هي التي كشفت عن مشاكل حقيقية في أجهزة عملاء حقيقيين.

groups:
  - name: gpu
    interval: 30s
    rules:
      - alert: GPUTempCritical
        expr: DCGM_FI_DEV_GPU_TEMP > 87
        for: 30s
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} thermal critical ({{ $value }} °C)"

      - alert: GPUThermalThrottling
        expr: rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 0
        for: 1m
        labels: { severity: warning }

      - alert: GPUECCUncorrectable
        expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[10m]) > 0
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} uncorrectable ECC — schedule replacement"

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels: { severity: critical }

      - alert: GPUPowerEnvelopeExceeded
        expr: DCGM_FI_DEV_POWER_USAGE > 590  # 5090 nominal 575 W; alarm above sustained ceiling
        for: 5m
        labels: { severity: warning }

      - alert: GPUIdleDuringWork
        expr: DCGM_FI_DEV_GPU_UTIL < 5 and DCGM_FI_DEV_FB_USED > 1024
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "GPU {{ $labels.gpu }} idle with VRAM allocated — likely hung"

  - name: system
    interval: 30s
    rules:
      - alert: HostMemoryLow
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.05
        for: 2m
        labels: { severity: critical }

      - alert: OOMKillerFired
        expr: increase(node_vmstat_oom_kill[5m]) > 0
        labels: { severity: critical }

      - alert: ContainerRestartLoop
        expr: rate(container_start_time_seconds[15m]) > 3
        for: 10m
        labels: { severity: warning }

  - name: serving
    interval: 30s
    rules:
      - alert: vLLMQueueBacklog
        expr: vllm:num_requests_waiting > 10
        for: 5m
        labels: { severity: warning }

      - alert: vLLMHighLatency
        expr: histogram_quantile(0.95, rate(vllm:e2e_request_latency_seconds_bucket[5m])) > 10
        for: 5m
        labels: { severity: warning }

تتضمن تلك القواعد مكالمات ذات آراء متحيزة:

• 87 درجة مئوية درجة حرارة حرجة لوحدة معالجة الرسومات. تُعاني بطاقة الرسومات 5090 من انخفاض الأداء عند درجات حرارة تتجاوز 80 درجة مئوية في معظم اللوحات الأم. إذا لم تتمكن غرفتك من الحفاظ على درجة حرارة البطاقات أقل من 80 درجة مئوية تحت الحمل المستمر، فالمشكلة تكمن في نظام التكييف، وليس في البرمجيات.
• أي صفحات ECC غير قابلة للتصحيح يتم استدعاؤها. يؤدي حدث تصحيح الأخطاء المزدوج (ECC) إلى إبطال جميع البيانات الموجودة في صفحة ذاكرة الوصول العشوائي للفيديو (VRAM) - حيث تصبح خطوة التدريب خاطئة، ونتيجة الاستدلال خاطئة. تحتاج البطاقة إلى استبدال، وليس إعادة تشغيل.
• GPUIdleDuringWork هو كاشف حالات التعطل. إذا تم تخصيص أكثر من 1 جيجابايت وكان استخدام الذاكرة أقل من 5% لمدة 10 دقائق، فهذا يعني وجود عطل ما. يكشف هذا الكاشف حالات التعطل في جانب CUDA التي يتجاهلها التطبيق تلقائيًا.
• يُعد تنبيه نفاد الذاكرة (OOM killer alert) القاعدة الأكثر إغفالاً في أي عملية نشر. إن قيام نظام لينكس بإيقاف مهمة التدريب الخاصة بك بهدوء وإعادة تشغيلها بشكل نظيف بواسطة دوكر هو القادم نمط العطل الذي يهدر أكبر عدد من ساعات عمل المهندسين سنوياً. اجعله واضحاً للعيان.
• حلقة إعادة تشغيل الحاويات تلتقط دورات إعادة تشغيل NIM و vLLM تبدو سليمة من الخارج (الحاوية "تعمل") ولكنها في الواقع تتعطل عند كل تحميل للنموذج.

الهيكل والتخزين - IPMI و SMART

يتوقف DCGM عند وحدة معالجة الرسومات (GPU). ويتوقف node_exporter عند نظام التشغيل. أما باقي مكونات الهيكل - المراوح، ووحدات تزويد الطاقة، ودرجة الحرارة المحيطة، وحالة التخزين - فتحتاج إلى مُصدِّرين إضافيين.

ipmi_exporter يتواصل برنامج (prometheus-community) مع وحدة التحكم في إدارة اللوحة الأم (BMC) عبر بروتوكول IPMI/RMCP، ويعرض بيانات القياس عن بُعد على مستوى الهيكل: سرعة دوران كل مروحة، وجهد وتيار دخل وحدة التزويد بالطاقة، وسجل أحداث النظام، ودرجة حرارة مدخل الهواء المحيط، وحالة مراقبة وحدة التحكم في إدارة اللوحة الأم. على هيكل Supermicro أو Bone64c مزود بوحدة تحكم في إدارة اللوحة الأم تعمل بشكل سليم، يستغرق هذا نصف يوم عمل، ويكشف عن أمور لا يستطيع DCGM رصدها - على سبيل المثال، يظهر عطل في وحدة التزويد بالطاقة في نظام ثنائي التزويد بالطاقة وثماني وحدات معالجة رسومية على شكل انخفاض في الجهد في بيانات مستشعر IPMI قبل دقائق من وصول وحدة معالجة الرسوميات إلى XID 79. قم بتشغيله على الجهاز المضيف (يحتاج إلى /dev/ipmi0) أو عن بعد باستخدام بيانات اعتماد BMC المخزنة باستخدام نمط المصدر متعدد الأهداف.

smartctl_exporter (أو الأقدم) smart_exporterيقرأ هذا البرنامج سمات SMART لوحدات NVMe وSATA: مؤشر تآكل الوسائط، والمساحة الاحتياطية المتاحة، ودرجة الحرارة، وعدد الأخطاء. تُرهق أحمال عمل الذكاء الاصطناعي وحدات NVMe بشدة - حيث تدفع برامج تحميل مجموعات البيانات، وعمليات كتابة نقاط التحقق، وذاكرة التخزين المؤقت HuggingFace، معدلات التآكل المستهدفة للمؤسسات إلى شهور على محركات الأقراص المخصصة للمستهلكين. المقياس الذي يجب الانتباه إليه هو nvme_available_spare انخفاض النسبة إلى أقل من 20% و nvme_percentage_used (مؤشر التآكل) يرتفع فوق 80%. يُعد عطل القرص الصلب ثاني أكثر أعطال الأجهزة شيوعًا في خوادم الذكاء الاصطناعي المشغولة بعد فئة وحدة التزويد بالطاقة/الرافعة.

يشمل نظام مراقبة الذكاء الاصطناعي الكامل من كينتينو كلا الأمرين. التكلفة الإضافية لا تتجاوز دقائق، أما القيمة الحقيقية فتتمثل في ساعات عند تعطل مروحة بشكل مفاجئ أو وصول جهاز سامسونج 990 برو إلى الحد الأقصى لعدد مرات تشغيله اليومية.

ملف docker-compose حقيقي للآلة الافتراضية للإدارة

ما نقوم بنشره فعليًا على جهاز الإدارة. اضبط host.docker.internal (أو استخدم اسم المضيف/عنوان IP لخادم وحدة معالجة الرسومات) لتوجيه Prometheus إلى منافذ التصدير الخاصة بمضيف وحدة معالجة الرسومات.

version: "3.8"

networks:
  monitoring: { driver: bridge }

volumes:
  prometheus_data:
  grafana_data:
  loki_data:

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules:/etc/prometheus/rules:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=20GB"
      - "--web.enable-lifecycle"
    ports: ["9090:9090"]
    networks: [monitoring]

  grafana:
    image: grafana/grafana:11.4.0
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/grafana_pw
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    secrets: [grafana_pw]
    ports: ["3000:3000"]
    networks: [monitoring]

  alertmanager:
    image: prom/alertmanager:v0.28.0
    restart: unless-stopped
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports: ["9093:9093"]
    networks: [monitoring]

  loki:
    image: grafana/loki:3.3.0
    restart: unless-stopped
    command: -config.file=/etc/loki/loki.yml
    volumes:
      - ./loki.yml:/etc/loki/loki.yml:ro
      - loki_data:/loki
    ports: ["3100:3100"]
    networks: [monitoring]

secrets:
  grafana_pw: { file: ./secrets/grafana_pw.txt }

على مضيف وحدة معالجة الرسومات نفسه (تكوين منفصل، على خادم وحدة معالجة الرسومات):

services:
  dcgm-exporter:
    image: nvcr.io/nvidia/k8s/dcgm-exporter:4.5.1-4.8.0-ubuntu22.04
    restart: unless-stopped
    runtime: nvidia
    environment: [NVIDIA_VISIBLE_DEVICES=all]
    cap_add: [SYS_ADMIN]
    ports: ["9400:9400"]

  node-exporter:
    image: prom/node-exporter:v1.9.0
    restart: unless-stopped
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--path.rootfs=/rootfs"
    ports: ["9100:9100"]

  ipmi-exporter:
    image: prometheuscommunity/ipmi-exporter:v1.10.0
    restart: unless-stopped
    privileged: true
    volumes: ["/dev/ipmi0:/dev/ipmi0"]
    ports: ["9290:9290"]

  smartctl-exporter:
    image: prometheuscommunity/smartctl-exporter:v0.13.0
    restart: unless-stopped
    privileged: true
    ports: ["9633:9633"]

  promtail:
    image: grafana/promtail:3.3.0
    restart: unless-stopped
    volumes:
      - /var/log:/var/log:ro
      - ./promtail.yml:/etc/promtail/promtail.yml:ro
    command: -config.file=/etc/promtail/promtail.yml

إعدادات برنامج Prometheus لاستخراج البيانات على الجهاز الظاهري للإدارة:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: dcgm
    static_configs:
      - targets: ["k-ai-01.lan:9400", "k-ai-02.lan:9400"]

  - job_name: node
    static_configs:
      - targets: ["k-ai-01.lan:9100", "k-ai-02.lan:9100"]

  - job_name: ipmi
    static_configs:
      - targets: ["k-ai-01.lan:9290", "k-ai-02.lan:9290"]

  - job_name: smart
    static_configs:
      - targets: ["k-ai-01.lan:9633", "k-ai-02.lan:9633"]

  - job_name: vllm
    metrics_path: /metrics
    static_configs:
      - targets: ["k-ai-01.lan:8000"]

هذه حزمة برمجية مناسبة لمختبر يتكون من خادم واحد إلى ثلاثة خوادم. بعد أربعة أو خمسة خوادم، قم بتغيير إعدادات Prometheus scrape إلى اكتشاف الخدمة القائم على الملفات، أو - إذا كنت تستخدم Kubernetes - إلى مخطط Helm الخاص بـ DCGM-exporter المدمج مع GPU Operator و Prometheus Operator. ServiceMonitor CRDs.

OpenTelemetry وPixie وeBPF - صورة عام 2026

ملاحظة حول العناصر المتحركة، لأن السؤال يطرح نفسه دائماً.

OpenTelemetry هو معيار CNCF لأدوات مراقبة الأداء، وبحلول أوائل عام 2026، أصبحت جميع أنواع الإشارات الثلاثة (المقاييس، والتتبعات، والسجلات) مستقرة. يحلّ مسار OTel Collector محلّ البرامج الوسيطة الخاصة بالبائعين في العديد من المؤسسات، باعتباره موجّه القياس عن بُعد العالمي. بالنسبة لخادم الذكاء الاصطناعي، فإنّ الحلّ العملي في عام 2026 هو: الإبقاء على Prometheus للمقاييس (يدعم DCGM-exporter وnode_exporter لغة Prometheus بشكل أصلي، وتُستخدم لغة PromQL لكتابة قواعد التنبيه)، وإضافة OTel Collector عند الحاجة إلى تتبّع موزّع عبر رسم بياني للاستدلال (طلب ← بوابة API ← vLLM ← استدعاء أداة ← قاعدة بيانات متجهة ← استجابة). بالنسبة لتثبيت خادم واحد مع نموذج واحد خلف nginx، يُضيف OTel تكلفةً دون فائدة. تستخدم 71% من المؤسسات التي "تستخدم كليهما" Prometheus للمقاييس وOTel لتتبعات التطبيقات - وهو تقسيم منطقي.

لابيلا بيكسي هي أداة مراقبة أصلية لـ Kubernetes تستخدم eBPF لجمع مقاييس وتتبعات وسجلات على مستوى النواة دون تغييرات في التعليمات البرمجية. يُعدّ العمل على eBPF على وحدة معالجة الرسومات (GPU) من أهم التطورات التي تستحق المتابعة في عام 2026.bpftime, eGPUوحدات نواة NVIDIA المفتوحة (التي تُوسّع نطاق أدوات eBPF لتشمل نواة وحدة معالجة الرسومات عبر حقن PTX أثناء التشغيل). هذه التقنية لا تزال في مرحلة البحث والتطوير، وليست جزءًا من أي حزمة إنتاجية نُقدّمها. حاليًا، يُعدّ DCGM هو الحل المدعوم.

يُعدّ التحليل المستمر للأداء (Grafana Phlare، Pyroscope) إضافةً ثالثةً جديرةً بالمعرفة. بالنسبة لأحمال عمل الاستدلال التي تتحكم فيها بشفرة الإطار (مثل تصحيحات vLLM المخصصة، وتحسينات المُجزِّئ)، يُخبرك هذا التحليل بالوظائف التي تستهلك موارد المعالج بكثافة. أما بالنسبة لخدمة النماذج باستخدام الحاويات الافتراضية، فهو يُعدّ مبالغةً.

ما الذي يتعطل (إصدار المراقبة)

أنماط الفشل المتوقعة للمكدس نفسه، مرتبة حسب مدى تكرار حدوثها:

• يمتلئ قرص بروميثيوس. مدة الاحتفاظ الافتراضية هي 15 يومًا؛ قمنا بتحديدها 30 يومًا بحد أقصى 20 جيجابايت. بعد 60 يومًا على خادم ذي استخدام عالٍ، خطط لعشرات الجيجابايت. حدد مدة الاحتفاظ بناءً على كل من الوقت والحجم.
• يفقد برنامج DCGM-exporter وحدات معالجة الرسومات بعد ترقية برنامج التشغيل. العرض: تصبح جميع لوحات وحدة معالجة الرسومات سوداء. الحل: أعد تشغيل الحاوية؛ أعد تشغيلها nvidia-ctk runtime configure إذا تم نقل وقت التشغيل.
• لم يتم تكوين برنامج إدارة التنبيهات لجهاز الاستقبال الذي تستخدمه فعليًا. يقوم المستخدمون بتثبيت Prometheus وGrafana، وينسون توجيه Alertmanager إلى البريد الإلكتروني أو Slack، ليكتشفوا بعد ستة أشهر أنه لم يتم إطلاق أي تنبيه. اختبر ذلك عن طريق تعطيل النظام عمدًا. GPUTempCritical مع عبء عمل مرهق، أو استخدام amtool alert add لإطلاق تنبيه اصطناعي في اليوم الأول.
• تضخم هائل في عدد العناصر نتيجةً لتصنيفات كل طلب. لا تقم بتسمية مقاييس vLLM بـ user_id or request_idلم يتم تصميم بروميثيوس لهذا الغرض - ستواجه مشكلة نفاد الذاكرة في قاعدة البيانات.
• تسريب كلمة مرور Grafana عبر بيئة Compose. استخدم أسرار Docker، وليس GF_SECURITY_ADMIN_PASSWORD في كتلة البيئة. docker inspect وتكشف السجلات عن قيم البيئة.
• مؤشر XID الذي لا تتم إعادة ضبطه. كما ذُكر، قد يعلق مقياس مُصدِّر DCGM XID على آخر قيمة مُشاهدة بعد الاستعادة. اجمع المقياس مع Loki's NVRM: استخدم الأمر syslog tail لتجنب الثقة الزائفة.

الرأي الصريح

معظم المختبرات تُثبّت Grafana مرة واحدة، وتُنشئ لوحة تحكم تُعجب الفريق لمدة أسبوع، ثم لا تعود إليها أبدًا. لوحة التحكم مجرد إضافة مُرضية، لكنها ليست ما يكشف المشاكل. التنبيهات هي ما يكشفها. اضبط Alertmanager مع مُستقبِل حقيقي (البريد الإلكتروني، Slack، PagerDuty) ومجموعة صغيرة من القواعد عالية الدقة - مثل درجة حرارة وحدة معالجة الرسومات، وتصحيح الأخطاء ECC ثنائي البت، وXID، وقاتل نفاد الذاكرة، وحلقة إعادة تشغيل الحاوية - واضبطها حتى تُفعّل فقط عند وجود خطأ فعلي. افعل هذا أولًا. ثم أنشئ لوحات تحكم لعملية تصحيح الأخطاء بعد وقوع الحادث.

أما الجانب الآخر من الصدق: على نطاق خادم واحد من نوع كينتينو، ستتلقى تنبيهًا من هذه المجموعة مرة واحدة شهريًا تقريبًا، وفي معظم الأشهر سيكون تنبيهًا خاطئًا تتجاهله. هذا هو أداء النظام. تكمن القيمة في التنبيه الذي يُطلق في اليوم الذي يبدأ فيه أحد الموصلات بالتعطل، قبل يومين من وصول البطاقة إلى XID 79، عندما لا يزال هناك متسع من الوقت لإعادة توصيل الكابل بدلًا من إرجاع وحدة معالجة الرسومات. هذا الحدث وحده يُغطي تكلفة جهد المراقبة بالكامل، بل ويُغطيها أضعافًا مضاعفة.

---

هذا جزء من موسوعة كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على البريد الإلكتروني info@kentino.com.