Jan 12, 2026 · 8510 words · 40 min read

6. الرصد الشامل#

فشل وحدة مروحة في موجّه أساسي لمزود خدمة بصمت خلال الليل. لم تُرسَل أي تنبيهات. اكتشف النظام الفرعي لإدارة الحرارة في بطاقات الخطوط ارتفاع درجات الحرارة، وبدأ في تقليل أداء دوائر ASICs المسؤولة عن إعادة التوجيه لحماية الأجهزة. انخفض الإنتاجية على رابط عبور في الإنتاج بنسبة 40%. لم يرصد نظام المراقبة شيئاً: كانت مستشعرات الحرارة التي يستطلعها موجودة على وحدة الإشراف في الهيكل، لا على بطاقات الخطوط الفردية. كانت استطلاعات SNMP تُجرى كل خمس دقائق وتُفيد بأن الجهاز سليم. أظهرت عدادات الواجهة إنتاجية منخفضة، لكن لم يُهيَّأ أي حد لهذا النمط لأن الرابط كان دائماً أقل من طاقته الكاملة.

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

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

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

تراقب أدوات مراقبة الشبكة التقليدية الأشياء المعطوبة: هل الواجهة تعمل؟ هل المعالج فوق 90%؟ هل هذه الخدمة تستجيب؟ هذا مفيد، لكنه تفاعلي: تراقب الفشل.

الرصد الشامل مختلف. يتعلق بفهم سبب تعطل الأشياء أو اقترابها من التعطل. ليس فقط “هذا الجهاز معطوب” بل “لماذا معطوب، وما الذي يتعطل بسببه، وما هو التأثير على الأعمال.” مع أتمتة الشبكة، يصبح الرصد الشامل حلقة التغذية الراجعة: ترصد شيئاً، يكتشفه نظامك، يقرر كيف يستجيب، يتخذ إجراء، ويتحقق من نجاح الإصلاح. هذه هي الأتمتة ذات الحلقة المغلقة (Closed-Loop Automation).

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

نغطي هنا كتلتين: Collector وObservability، لأنهما مترابطتان ارتباطاً وثيقاً.

سواء استخدمت منصة شاملة تقليدية (SolarWinds، LibreNMS)، أو خدمة سحابية (Datadog، New Relic)، أو بنيت مجموعتك الخاصة من المكونات مفتوحة المصدر (Prometheus، Grafana، إلخ)، فإن البنية الأساسية واحدة. يساعدك فهم هذه الأنماط على اختيار النهج الصحيح لحجمك وفريقك.

تنويه: في هذا القسم، أذكر موردين وحلولاً مختلفة كأمثلة. لا يُعدّ ذلك في أي حال توصية، بل لأغراض توضيحية فقط.

هذا القسم مستوحى بشكل كبير من كتاب Modern Network Observability الصادر عن Packt، الذي شاركت في تأليفه مع David Flores وJosh Vanderaa. إن أردت التعمق العملي وتعلم التنفيذ باستخدام مجموعة TPG (Telegraf-Prometheus-Grafana) وأدوات أخرى، أنصح بشدة بقراءته.

6.1. الأساسيات#

قبل الخوض في التفاصيل الدقيقة، نرسي هنا المفاهيم التأسيسية للرصد الشامل للشبكة ضمن استراتيجية أتمتة الشبكة، بتحديد أهدافه وركائزه الداعمة ونطاقه.

6.1.1. السياق#

على الأرجح تراقب شبكتك بالفعل. تستخدم Simple Network Management Protocol (SNMP)، وتطّلع على System Logging Protocol (Syslog)، ولديك لوحات معلومات تُظهر استخدام الروابط. هذه مراقبة: تخبرك إذا كانت الأشياء تعمل.

لكن الأتمتة تحتاج أكثر. حين تتغير شبكتك (لأن الأتمتة غيّرتها)، تحتاج معرفة ذلك فوراً إن كانت قد أفسدت شيئاً. حين تتلقى تنبيهاً، تحتاج السياق: أي عملاء يتأثرون؟ أي خدمات فشلت؟ ما حجم التأثير؟ تمنحك المراقبة التقليدية إنذارات. الأتمتة تحتاج ذكاءً.

الفرق الرئيسي:

المراقبة: هل الواجهة تعمل؟ هل المعالج مرتفع؟ أسئلة بسيطة بنعم أو لا.
الرصد الشامل: لماذا توقفت الواجهة؟ ما الذي تؤثر عليه؟ كيف نصلحها تلقائياً؟ ما الذي حدث تاريخياً وأفضى إلى ذلك؟

يُغذّي الرصد الشامل الأتمتة. يرصد نظامك الشبكة، يكتشف المشكلات، يقرر ما يفعله، يتخذ إجراء، ويتحقق من نجاح الإصلاح. تكرار هذه الدورة يُسمى “الأتمتة ذات الحلقة المغلقة.”

تحاول أدوات المراقبة التقليدية (المتكاملة الكبرى كـSolarWinds) فعل كل شيء في منتج واحد. يمكن أن ينجح ذلك، لكنك كثيراً ما تدفع مقابل ميزات لا تحتاجها وتُقيَّد بميزات تحتاجها. البديل هو بناء الرصد الشامل من قطع: اختر المجمِّع الذي يناسب أجهزتك، والتخزين الذي يتوسع مع بياناتك، والتنبيه الذي يناسب سير عمل أتمتتك. هذا أصعب في التجميع لكنه أكثر مرونة بكثير.

يستعرض هذا الفصل كلا النهجين والأنماط التي تنجح بصرف النظر عن أيهما تختار.

أحد الخيارات الأولية يتعلق بكيفية تشغيل المنصة:

المتكامل (SolarWinds، LibreNMS): منتج واحد يفعل كل شيء. تثبّته، تُهيِّئه، وتبدأ. جيد إن كانت شبكتك بسيطة وليس لديك خبرة DevOps. سيء إن أردت المرونة أو كانت شبكتك غير اعتيادية: ستكون مقيداً بنموذجهم.
SaaS السحابي (Datadog، New Relic، Kentik): يديرون كل شيء لك. سريع النشر، بلا صداع بنية تحتية، لوحات معلومات رائعة من البداية. لكنك تدفع شهرياً بناءً على الحجم، وبياناتك تعيش على خوادمهم (يهم ذلك في بعض أنظمة الامتثال)، وحين تصطدم بحدودهم تكون عالقاً. رأيت فرقاً تنفق 50 ألف دولار شهرياً على SaaS للرصد متسائلةً لماذا مديرها المالي غير سعيد.
البناء الذاتي (Prometheus + Grafana، أو مجموعة Telegraf-Prometheus-Grafana (TPG)): مرونة كاملة، بلا ارتباط بمورد، اقتصاديات أفضل على نطاق واسع. لكنك الآن تُشغِّل قواعد بيانات وقوائم رسائل وبنية تحتية لمجمِّعات. إن لم يكن لديك أشخاص يمكنهم تشغيل هذه الأشياء، ستقضي وقتاً أطول في إصلاح الرصد بدلاً من إصلاح شبكتك.

السؤال الحقيقي: هل لديك الفريق اللازم لتشغيله؟ إن كانت الإجابة نعم، ابنه. إن كانت لا، اشتره. لا تخدع نفسك بشأن أي فئة أنت فيها.

بعد ذلك الخيار، يطرح سؤالان آخران:

أين يعمل؟ في مرافقك (تتحكم في كل شيء لكنك تُشغِّله)، في السحابة (يُشغِّلونه، لكن بياناتك تغادر شبكتك)، أو هجين (بعض الأماكن محلية وبعضها في السحابة)؟
ما نموذج التكلفة؟ لكل جهاز؟ لكل مقياس مُستوعب؟ اشتراك ثابت؟ هذه القرارات تتراكم بسرعة حين تجمع ملايين نقاط البيانات في الدقيقة.

6.1.2. الأهداف#

يحتاج نظام الرصد الشامل الخاص بك إلى تحقيق سبعة أشياء:

رصد كل شيء تلقائياً. اتصل جهاز جديد؟ ينبغي أن يبدأ في الإبلاغ عن البيانات دون أن يُسجِّله أحد يدوياً. جاءت خدمة جديدة؟ تُراقَب بالفعل. يتطلب ذلك تكاملاً مع مصدر الحقيقة حتى تعرف المراقبة ما هو موجود.
التعامل مع البيئات غير المتجانسة ببيانات جيدة. شبكتك على الأرجح تحتوي Cisco وArista وJuniper ومزودي سحابة وخوادم Linux وحاويات. لكل منها طرق مختلفة لكشف البيانات. وانسَ فترات 5 دقائق: تحتاج بيانات قريبة من الوقت الفعلي حين تجري الأتمتة تغييرات.
ربط البيانات عبر الطبقات. خادم بطيء. هل الشبكة مزدحمة، أم مشكلة قاعدة بيانات؟ تحتاج بيانات من أجهزة الشبكة والخوادم والتطبيقات، جميعها تتحدث لغة واحدة حتى تتمكن من رسم صلات بينها.
التوسع دون انهيار. الشبكات تنمو. حين تجمع مليون مقياس في الثانية، تتهاوى البنى التقليدية. تحتاج أنظمة مصمَّمة للنطاق الواسع من اليوم الأول.
السماح للناس بتحليل البيانات بذكاء. امنح المحللين إمكانية الاستعلام عن بياناتك، لا مجرد لوحات معلومات جاهزة، بل استعلامات قوية حتى يتمكنوا من الإجابة عن أسئلتهم بأنفسهم. ويحتاجون البيانات الآنية والتاريخية (الاتجاهات، اكتشاف الشذوذ).
اكتشاف المشكلات وإصلاحها تلقائياً. في معظم الأحيان، ينبغي لأتمتتك الاستجابة للمشكلات دون انتظار إنسان. فقط حين لا تستطيع الأتمتة اكتشاف الحل ينبغي أن يُنبَّه أحد. وعلى ذلك التنبيه أن يشرح ما هو الخطأ، لا مجرد إظهار أرقام خام.
إظهار ما يحتاجه الناس. لوحة المعلومات بلا قيمة إن أظهرت الكثير أو الشيء الخاطئ. امنح فريق عمليات الشبكة رؤيتهم، والأعمال رؤيتها، والمهندسين رؤيتهم. كل شخص يحصل على ما يساعده في أداء عمله.

6.1.3. الركائز#

كل هدف يحتاج لبنات بناء محددة كي يعمل. إليك ما تحتاجه:

معرفة ما يجب رصده. مصدر الحقيقة لديه جميع الأجهزة والخدمات وبيانات الاعتماد. ينبغي للرصد الشامل سحب تلك البيانات تلقائياً حتى تعرف المجمِّعات ما تُراقبه. حين تضيف جهازاً إلى مصدر الحقيقة، تبدأ مراقبته تلقائياً.
جمع البيانات بكفاءة. تحتاج طرق جمع متعددة: Simple Network Management Protocol (SNMP) للمعدات القديمة، بث gRPC Network Management Interface (gNMI) للأجهزة الحديثة، System Logging Protocol (Syslog) للأحداث، التدفقات (NetFlow، IP Flow Information Export (IPFIX)) لحركة المرور، وربما التقاط حزم للتشخيص العميق. أدوات مختلفة، سرعات مختلفة، ثراء مختلف في البيانات. الخبر السار: لا يجب عليك اختيار واحدة فقط.
توحيد كل شيء. تبدو مقاييس Arista مختلفة عن مقاييس Cisco، التي تبدو مختلفة عن مقاييس مزود السحابة. سجلاتك نص غير منظم، والتدفقات ثنائية. تحتاج طبقة تترجم كل هذا إلى لغة مشتركة وتضيف السياق (أي جهاز، أي عميل، أي خدمة).
نقل البيانات بموثوقية على نطاق واسع. خطوط أنابيب المراقبة التقليدية تسلسلية: مجمِّع ← معالج ← تخزين. على نطاق واسع، هذا عنق زجاجة. تحتاج حافلات رسائل ومنصات بث تفصل كل مرحلة حتى تتوسع باستقلالية.
التخزين الذكي. بيانات السلاسل الزمنية (المقاييس) تحتاج قواعد بيانات مُحسَّنة لها. السجلات تحتاج شيئاً مختلفاً. تحتاج الاستعلام عبر ملايين نقاط البيانات في ميلي ثوانٍ. لا تتساوى قواعد البيانات في هذا.
تحويل البيانات إلى إجراءات. المقاييس الخام لا تُشغِّل الأتمتة. تحتاج قواعد: “إذا كان المعالج فوق 90%، تحقق إن كانت صيانة متوقعة، وإلا اتخذ هذه الخطوات.” وتلك القواعد تُغذِّي منسِّق أتمتتك أو نظام التنبيه.
العرض المرئي. البيانات عديمة الفائدة إن لم ينظر إليها أحد. تحتاج لوحات معلومات، لكن ذكية: رؤى مختلفة لأشخاص مختلفين، قادرة على التعمق، قادرة على إظهار الاتجاهات والمقارنات.

أخيراً، قبل تفصيل الوظائف السبع التي تُحقق هذه الركائز، لنوضح ما يقع ضمن نطاق الرصد الشامل.

6.1.4. النطاق#

لتوسيع الأهداف المُقدَّمة أعلاه، ثمة نقاط أخرى تنتمي أيضاً إلى مسؤوليات الرصد الشامل:

مستويات مختلفة من الرصد تتكيف مع وجهات نظر المستخدمين (تقنية وتشغيلية وتجارية)
التكامل مع خطوط أنابيب CI/CD، وتوفير تغذية راجعة للاختبار والتحقق الآلي
رصد نظام الأتمتة ذاته (مراقبة ذاتية للميتا للـCollectorات والمعالجات وأنظمة التنبيه)

في المقابل، ثمة وظائف تنتمي إلى مكونات أخرى في البنية المعمارية:

تعريف نية الشبكة: كيف ينبغي أن تبدو الشبكة (مسؤولية النوايا/مصدر الحقيقة)
تنفيذ تغييرات الشبكة: التطبيق الفعلي للمعالجة (مسؤولية Executor)
تنسيق سير العمل المعقدة: تنسيق معالجة متعددة الخطوات عبر أنظمة متعددة (مسؤولية Orchestrator)

يضمن هذا الحد الواضح تركيز Observability على الاكتشاف والرؤى، بينما تتولى كتل البناء الأخرى تعريف النوايا والتنفيذ والتنسيق.

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

بعد هذه المقدمة الأولية التي تكشف المفاهيم الرئيسية المتعلقة بكتلة الرصد الشامل، لننتقل إلى كل وظيفة على حدة.

6.2. الوظائف#

تُحقَّق الأهداف والركائز السبعة من خلال سبع وظائف أساسية. كل وظيفة ترتبط بهدف وركيزة داعمة له، مما يخلق سلسلة مباشرة من متطلبات الأعمال إلى التطبيق التقني:

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

graph LR

    %% --- Subgraphs ---
    subgraph الأهداف
        direction TB
        A1[رصد الشبكة بالكامل بأقل جهد بشري]
        A2[دعم البيئات الشبكية غير المتجانسة بما يكفي من البيانات والدقة]
        A3[رصد البيانات من طبقات تقنية المعلومات المختلفة مع السياق]
        A4[التعامل مع سيناريوهات الشبكة واسعة النطاق]
        A5[توفير الوصول إلى بيانات الرصد لتحليل متقدم في الوقت الفعلي تقريباً]
        A6[الاستباقية في اكتشاف مشكلات الشبكة وتقليل وقت الاسترداد]
        A7[إنشاء تصورات مخصصة موجهة للمستخدم]
    end

    subgraph الركائز
        direction TB
        B1[تكامل وثيق مع مصدر الحقيقة لفهم ما يحتاج إلى مراقبة]
        B2[القدرة على جمع البيانات عبر بروتوكولات مختلفة تدعم تحديثات متكررة جداً/عند الطلب]
        B3[توحيد البيانات غير المتجانسة مع البيانات الوصفية السياقية لتحليل أغنى]
        B4[أنظمة توزيع بيانات قابلة للتوسع لدعم البنى الموسعة أفقياً]
        B5[طبقة حفظ تدعم بيانات السلاسل الزمنية ولغات استعلام قوية]
        B6[تعريفات قواعد مرنة وسيناريوهات توجيه مع تكامل أنظمة خارجية]
        B7[تصورات مخصصة وتكامل مع مخازن بيانات متعددة]
    end

    subgraph الوظائف
        direction TB
        C1[الجرد]
        C2[المجمِّع]
        C3[المعالج]
        C4[التوزيع]
        C5[الحفظ]
        C6[التنبيه]
        C7[التصور]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

يمكن النظر إلى هذه المكونات باعتبارها خط أنابيب بيانات أو ETL (استخراج وتحويل وتحميل)، كما يُوضح المخطط التالي:

flowchart TB
    A[الشبكة] --> B[المجمِّع]

    subgraph الرصد الشامل
       direction LR
       B --> C[التوزيع] -->  D[الحفظ]
       B -.-> P[المعالجة]
       C -.-> P
       D -.-> P
       D --> E[التنبيه]
       E -.-> P
       D --> G[التصور]
       X[الجرد] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[التنسيق]
    G -.-> H[العرض]
    Y[مصدر الحقيقة] -.-> X

الشكل 1: خط أنابيب الرصد الشامل.

6.2.1. الجرد#

يُجيب مكوّن الجرد على سؤال بسيط: ما الذي ينبغي مراقبته؟

لديك هذه البيانات بالفعل في مكان ما: إنها في مصدر الحقيقة. عندك أسماء الأجهزة وعناوين IP وما هي الأجهزة وما إذا كانت نشطة وبيانات الاعتماد. لا تكرر ذلك يدوياً. اسحبه تلقائياً.

ما تحتاجه من مصدر الحقيقة:

اسم أو معرّف فريد لكل جهاز أو خدمة (حتى تعرف أنه الجهاز الذي تظن أنه هو)
كيفية الوصول إليه: عنوان IP والاسم المضيف وبيانات الاعتماد (إذا كنت بحاجة لسحب البيانات منه بشكل نشط)
ما هو: النوع والمورد (حتى تعرف أي Collectorات تعمل معه)
هل هو نشط: إن كان مخططاً أو نشطاً أو قيد التوقف (حتى لا تنبّه على التوقف المتوقع)

بجانب الأساسيات، قد تهتم أيضاً بـ:

تفاصيل نظام التشغيل أو الجهاز: بعض الأجهزة تستخدم بروتوكولات مختلفة، وبعضها قديم ويحتاج معالجة خاصة
السياق: من يملكه، أين موقعه، أي عملاء يعتمدون عليه (مفيد لتصفية التنبيهات ولوحات المعلومات)

لماذا تُؤتمَت هذا بدلاً من بناء قائمة يدوياً؟ لأن الناس ينسون تحديث القوائم. تُضاف أجهزة ولا يُبلَّغ الرصد، وفجأة تفقد الرؤية. لكن إن قرأ الرصد الشامل من مصدر الحقيقة، حين تضيف جهازاً هناك، يُراقَب تلقائياً.

دفع أم سحب؟

السحب: يتحقق الرصد الشامل من مصدر الحقيقة دورياً بحثاً عن تحديثات. بسيط، لكن إن تغير شيء في منتصف الفترة، تفوته.
الدفع: حين يتغير مصدر الحقيقة، يُشير إلى الرصد الشامل تلقائياً (webhooks، حافلة رسائل). أسرع وأكثر موثوقية.

إن كانت لديك بيانات جيدة في مصدر الحقيقة وتكامل حقيقي (لا نسخ لصق يدوي)، يصبح الجرد تلقائياً ولا تفوتك مراقبة أي جهاز جديد.

6.2.2. المجمِّعات#

بياناتك يجب أن تأتي من مكان ما. Collectorات هي الجسور بين شبكتك وObservability منصتك. مسؤولة عن سحب (أو استقبال) البيانات من أجهزتك وتغذيتها في خط الأنابيب. بدون Collectorات فعّالة، كل ما بعدها غير موثوق.

ثمة نهجان أساسيان من منظور من يمتلك تدفق البيانات:

سلبي أو دفع: أجهزتك ترسل البيانات إلى المجمِّع. فكّر في خوادم syslog تستقبل رسائل سجل من الموجّهات، أو مجمِّعات IPFIX تستمع لسجلات التدفق. الجهاز يقرر ما يُرسله ومتى.
نشط أو استطلاع: يطلب Collector البيانات من الأجهزة. يتصل بكل جهاز ويسحب المعلومات باستخدام Simple Network Management Protocol (SNMP) أو gRPC Network Management Interface (gNMI) أو Representational State Transfer (REST) Application Programming Interface (API)ات، أو يشترك في بيانات البث. Collector في السيطرة: يقرر ما يطلبه ومتى.

يمكن أيضاً تصنيف المجمِّعات حسب النشر:

بلا وكيل: لا برنامج للتثبيت على الأجهزة. خادم مجمِّع مركزي (يعمل عادةً في مكان آخر) يتصل بكل جهاز بشكل فردي. بسيط للبدء، لكن قد يصبح عنق زجاجة عند التوسع.
قائم على وكيل: تثبيت وكيل صغير على كل جهاز أو خدمة. يدفع الوكلاء البيانات إلى موقع مركزي، أو يسحبون مباشرة من المصادر المحلية. أكثر توزيعاً وأسهل في التوسع، لكن مع مزيد من الأجزاء المتحركة للإدارة.

بصرف النظر عن طريقة الجمع، من المهم تسليط الضوء على أنواع البيانات المختلفة التي قد تكون ذات اهتمام في بيئة أتمتة الشبكة. أصنّفها في أربع فئات عريضة:

المستوى الإداري: حالة الجهاز، أو قراءة بيانات عن التهيئة أو السجلات أو إحصاءات الشبكة. البروتوكولات في هذه المجموعة هي Simple Network Management Protocol (SNMP) وSystem Logging Protocol (Syslog) وgRPC Network Management Interface (gNMI) وNETCONF وRESTCONF.
مستوى التحكم: هنا تعمل البروتوكولات الموزعة التي تحدد إعادة توجيه الحزم في الشبكة، كجداول إعادة التوجيه في الطبقة الثانية والثالثة. أمثلة على بروتوكولات مستوى التحكم: OSPF وIS-IS وBGP. يمكن رصد هذه المستويات عبر تقنيات كـPing وTraceroute، أو بروتوكولات القياس عن بُعد كـBMP.
مستوى إعادة التوجيه: هنا تتحرك الحزم (مثلاً واجهات الشبكة)، وهو الأكثر تطلباً من حيث حجم البيانات وسرعتها. طبيعياً، عند رصده، من الضروري أيضاً عدم التأثير على الهدف الأساسي للمستوى وهو إعادة توجيه الحزم. في هذه المجموعة، أدوات كـTcpDump وIPFIX وsFlow وNetflow وCisco SLA وPSAMP وeBPF.
البيانات الخارجية: تشمل هذه الفئة كل ما ليس خاصاً بأجهزة الشبكة. على سبيل المثال، معلومات مزود الدائرة وجهة الاتصال لواجهة معينة، القادمة من نظام إدارة أصول خارجي أو مستشعرات إنترنت الأشياء الفيزيائية.

flowchart TB
    subgraph جهاز/خدمة الشبكة
        direction TB
        A[المستوى الإداري]
        B[مستوى التحكم]
        C[مستوى إعادة التوجيه]
        A --> B
        B --> C
    end

    D[البيانات الخارجية]

الشكل 2: نطاق المجمِّع.

توقف عن كشط مخرجات Command Line Interface (CLI). أعلم أنك تفعل ذلك. كلنا فعلناه. لكن هذا عام 2026 وكل مورد رئيسي يدعم الآن قياساً عن بُعد حقيقياً.

كشط CLI هش (يغير الموردون تنسيق المخرجات)، بطيء (كشط وتحليل النص مكلف)، غير موثوق (مهلة أوامر عشوائية)، ويتوسع بشكل سيئ. إن كان جهازك قديماً جداً لدرجة أنه يحتوي CLI فقط، إما استبدله أو اقبل أن لديك رصداً محدوداً. لا تبنِ كامل مجموعة مراقبتك حول المقام المشترك الأدنى.

في الواقع، يعود الأمر إلى سؤالين أساسيين حول ما تجمعه:

ما تجمعه: مقاييس؟ سجلات؟ سجلات تدفق؟ لكل منها نماذج بيانات مختلفة. SNMP له MIBs، المعدات الحديثة تتحدث gNMI، التطبيقات تستخدم OpenTelemetry. الحلم هو معيار عالمي يتيح لك ربط البيانات عبر كل شيء، لكن هذا غير موجود بعد. لذا قد تحتاج بناء طبقة ترجمتك الخاصة التي تحوّل كل هذه التنسيقات المختلفة إلى شيء متسق (وهو ما تفعله طبقة المعالجة التالية).
كيف تحصل عليه: أي بروتوكول؟ SNMP قديم لكن مستقر، gNMI حديث ويدفع إليك البيانات باستمرار، IPFIX يلتقط ما يتدفق فعلاً. يتفاوت الأمر بحسب ما تحاول رصده.

يلخص هذا الجدول ما قد تجمعه والأدوات المتاحة:

نوع البيانات	البروتوكولات / طرق الجمع	ملاحظات / أمثلة
المقاييس	Simple Network Management Protocol (SNMP)، كشط Hypertext Transfer Protocol (HTTP)، استطلاع Command Line Interface (CLI)، OpenTelemetry (OpenTelemetry Protocol (OTLP))، القياس عن بُعد بالبث (gRPC Network Management Interface (gNMI))	مقاييس الأجهزة والمضيفات والتطبيقات
السجلات	OpenTelemetry (OTLP)، تذييل الملفات، syslog	سجلات التطبيقات والنظام والسجلات المنظمة
التتبعات	OpenTelemetry (OTLP)	التتبع الموزع عبر الخدمات
تدفقات الشبكة	NetFlow، IPFIX	تدفقات حركة المرور، تحليل المصدر/الوجهة
خاصة بالبروتوكول	BMP، BGP، ARP، OSPF	مراقبة BGP (BMP)، جداول ARP وBGP وOSPF
التقاط الحزم	PCAP (libpcap)، SPAN / TAP	فحص الحزم الكامل، التشخيص العميق

الجدول 1: البيانات والبروتوكولات للجمع.

للحصول على فهم أعمق للخيارات المختلفة، راجع كتاب Modern Network Observability.

ينطبق جمع بيانات الشبكة على مراكز البيانات وأعمدة فقرية لمزودي الإنترنت وخدمات شبكة السحابة وواجهات Linux kernel أو الحزم الخام. يعتمد الأمر على بيئتك.

المفتاح: قبل تحديد ما تجمعه، ابدأ بالمشكلة التي تحاول حلها. يقود ذلك القرار كل شيء آخر. هل تكتشف تشبع الواجهة؟ تراقب تقارب BGP؟ تتتبع حركة مرور DDoS؟ مشكلتك تحدد ما تحتاجه من بيانات وعلى أي فترات.

لزيادة تكرار البيانات المجموعة (مفيد في بعض الحالات) أو لتوحيد طرق الجمع، إليك أنماطاً اكتسبت تبنياً متزايداً مؤخراً:

القياس عن بُعد بالبث المباشر

تدفع الأجهزة البيانات باستمرار باستخدام نماذج YANG. تُعدّ اشتراكات وتتدفق البيانات في الوقت الفعلي. نكهتان:

الاتصال الوارد (Dial-In): يطلب المجمِّع من الجهاز البدء في البث (المجمِّع يبادر).
الاتصال الصادر (Dial-Out): الجهاز مُهيَّأ مسبقاً للبث إليك (الجهاز يبادر).

زمن استجابة أقل بكثير من الاستطلاع، والجهاز يبقى في تحكم التدفق.

flowchart TB
    A[المجمِّع]
    B[الجهاز]
    A -.->|الاتصال الوارد| B
    B -->|البث المباشر| A
    B -.->|الاتصال الصادر| A

الشكل 3: القياس عن بُعد بالبث المباشر.

مقاييس مكشوفة عبر Hypertext Transfer Protocol (HTTP)

كشط Hypertext Transfer Protocol (HTTP) (مقاييس قائمة على السحب) بسيط ويتوسع جيداً. يفعل Simple Network Management Protocol (SNMP) هذا، لكن أنظمة تشغيل الشبكة تكشف المقاييس بشكل متزايد مباشرةً عبر Hypertext Transfer Protocol (HTTP) بتنسيق Prometheus. أسهل لـCollectorات في الاستهلاك، لا حاجة لتحليل Simple Network Management Protocol (SNMP) Management Information Base (MIB) خاص. SONiC وCumulus وArista EOS وغيرها تكشف المقاييس بهذه الطريقة.

المورد / نظام التشغيل	نوع المقياس	مثال المقياس
SONiC	حركة مرور الواجهة	`sonic_interface_rx_bytes_total{interface="Ethernet32"} 1.234e+12`
NVIDIA Cumulus	حركة مرور الواجهة	`node_network_receive_bytes_total{device="swp1"} 9.21e+10`
Arista EOS	حركة مرور الواجهة	`arista_interface_in_octets_total{interface="Ethernet1"} 8.3e+11`

الجدول 2: المقاييس المكشوفة عبر HTTP.

يوفر نهج الكشط زمن استجابة منخفضاً ومقاييس قريبة من الوقت الفعلي، وتسميات غنية، وجمعاً قائماً على السحب (تحكم مركزي في المعدل/المهلة)، يتواصل جيداً مع رصد السحابة واسع النطاق.

OpenTelemetry

OpenTelemetry هو معيار وحزمة أدوات محايدة للمورد لجمع بيانات القياس عن بُعد ومعالجتها وتصديرها. فكّر فيها كلغة قياس عن بُعد مشتركة وخط أنابيب يوحّد المقاييس والسجلات والتتبعات عبر الشبكات والأنظمة والتطبيقات.

لا تحل محل بروتوكولات الشبكة كـSNMP وNetFlow وgNMI وBMP. بدلاً من ذلك، توحّد كيفية تمثيل القياس عن بُعد ونقله بعد الجمع.

في مراقبة الشبكة التقليدية، نماذج البيانات متنوعة وتستخدم مخططات وتسمية خاصة بالمورد، مما يجعل الربط عبر الطبقات (الشبكة ↔ النظام ↔ التطبيق) صعباً. في المقابل، تساعد OpenTelemetry بتوفير:

نموذج بيانات مشترك للمقاييس والسجلات والتتبعات
بروتوكول نقل معياري (OpenTelemetry Protocol (OTLP))، عبر gRPC Remote Procedure Call (gRPC) أو Hypertext Transfer Protocol (HTTP)
خط أنابيب معالجة واحد لأنواع إشارات متعددة

Grafana Alloy أو Telegraf أمثلة على Collector يُطبِّق OpenTelemetry Protocol (OTLP). يجمع البيانات من مُصدِّرين مختلفين ويُصدِّر إلى backends مختلفة كالمقاييس (Time Series Database (TSDB)s متوافقة مع Prometheus) والسجلات (Loki، Elasticsearch، ClickHouse) والتتبعات (Tempo، Jaeger).

وهذا يقودنا إلى اعتبار أخير حول البنية المشتركة للمجمِّعات الحديثة القابلة للتوصيل، بمراحل الإدخال والمعالج والإخراج. على سبيل المثال، في Telegraf، OTLP خيار لـإضافة الإخراج.

OpenTelemetry كخيار معماري

تبني OpenTelemetry ليس مجرد قرار أدوات: إنه قرار معماري حول كيفية توحيد خط أنابيب الرصد الشامل. الاختيار بين نهجين:

أصيل بالبروتوكول: كل نوع إشارة يسافر عبر بروتوكوله الأصلي من البداية إلى النهاية (gNMI إلى Prometheus، syslog إلى Elasticsearch، NetFlow إلى ClickHouse). كل خط أنابيب محسَّن لإشارته. التكلفة هي خطوط أنابيب مستقلة متعددة بلا نموذج بيانات مشترك، مما يجعل الربط عبر أنواع الإشارات مكلفاً.

أصيل بـOTel: تُحوَّل الإشارات إلى OpenTelemetry Protocol (OTLP) مبكراً قدر الإمكان وتتدفق عبر خط أنابيب واحد إلى backend موحَّد. الربط عبر المقاييس والسجلات والتتبعات طبيعي لأنها تشترك في نموذج بيانات. التكلفة هي أن دعم OTel في أجهزة الشبكة لا يزال في طور النضج: معظم الموردين لا يُصدِّرون OTLP بشكل أصيل، مما يتطلب طبقة محوّل (gNMI إلى OTel، SNMP إلى OTel) تُضيف تعقيداً تشغيلياً.

التوصية العملية لبيئات أتمتة الشبكة اليوم: تبنَّ OTel للإشارات المجاورة للتطبيقات حيث يكون دعم الموردين قوياً (قياس عن بُعد لمنصة الأتمتة، صحة الخدمة، سجلات التطبيقات المنظمة)، واستمر مع خطوط أنابيب أصيلة بالبروتوكول لقياس الشبكة التقليدي عن بُعد (استطلاع SNMP، بث gNMI) حتى ينضج دعم OTel على جانب الأجهزة. صمِّم خط الأنابيب لاستيعاب كلا النهجين جنباً إلى جنب بدلاً من إرغام توحيد مبكر يتطلب محوّلات لكل جهاز شبكة.

الاتجاه واضح: ستصبح OpenTelemetry في نهاية المطاف المعيار لجميع بيانات الرصد الشامل. البدء بها لمنصة الأتمتة ذاتها (مراقبة ذاتية الفصل 5) هو خطوة أولى منخفضة المخاطر تبني الألفة قبل توسيعها إلى أجهزة الشبكة.

بنية المجمِّع

بشكل مبسَّط، يمكن تقسيم كل مجمِّع إلى ثلاثة أجزاء (أحياناً تكون قابلة للتوصيل وأحياناً مُضمَّنة).

flowchart LR
    A[المدخل] --> B[المعالج] --> C[المخرج]

الشكل 4: بنية المجمِّع.

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

توجد مجمِّعات كثيرة (لكل منها قدرات مختلفة) كـTelegraf وGrafana Alloy وgNMIc وPMACCT وgoflow وغيرها، لكنها تستخدم بنية مماثلة. لذا عند الاختيار (أحياناً قد تحتاج عدة منها)، تعامل كما يلي:

قدرات الجهاز، ما البروتوكولات التي تدعمها أجهزتك؟
حجم البيانات، الحجم الكبير يحتاج بثاً؛ الحجم المنخفض يمكن الاستطلاع.
متطلبات زمن الاستجابة، قريب من الوقت الفعلي مقابل فترات تقليدية.
مهارات الفريق وملاءمة النظام البيئي مع backend.

جميع حلول رصد الشبكة “الكاملة” كـSuzieq وKentik وغيرها تُطبِّق أيضاً مجمِّعاً مدمجاً لبيانات الرصد المشمولة.

بعد جمع البيانات، الخطوة التالية التي قُدِّمت هي المعالج الذي يتعامل مع البيانات في مراحل مختلفة من خط الأنابيب.

6.2.3. المعالج#

البيانات الخام من المجمِّعات فوضوية. تُصدِّر أجهزة مختلفة المقاييس بشكل مختلف، والسجلات نص غير منظم، والقيم قد تكون بوحدات مختلفة. تُنظِّف طبقة المعالج هذا وتجعله مفيداً.

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

فيما يلي إجراءات المعالجة الشائعة التي تنطبق على خطوط أنابيب الرصد الشامل.

6.2.3.1. التوحيد/التحويل#

تأتي البيانات بتنسيقات مختلفة. ترسل Arista المقاييس بطريقة، وCisco بطريقة أخرى، والـsyslog نص، وNetFlow ثنائي. يترجم التوحيد كل هذا إلى تنسيق مشترك حتى لا يضطر backend الخاص بك إلى فهم 50 لهجة مختلفة.

البنية

تُصدِّر الأجهزة البيانات بطرق تنطوي على معنى بالنسبة لها. مهمتك ترجمة ذلك إلى تنسيق يناسب التحليل:

قائم على السجل:

Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

إلى

{
"timestamp": "2025-03-18T14:22:11Z",
"level": "INFO",
"device": "leaf01",
"component": "interface",
"event": "oper_state_change",
"interface": "swp1",
"previous_state": "UP",
"current_state": "DOWN"
}

قائم على المقياس: <اسم المقياس>{<تسميات>} <قيمة>

interface_admin_state{hostname="leaf01", ifname="swp1"} 1
interface_oper_state{hostname="leaf01", ifname="swp1"} 0
interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

قائم على الجدول: تُنظِّم بعض الأدوات (مثل Suzieq) البيانات في طرق عرض حالة جدولية مفهرسة زمنياً:

| hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
|----------|--------|------------|-----------|-------|----------|-----------|-----------|
| leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
| leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

إعادة التسمية والمواءمة

تصف مصادر القياس عن بُعد المختلفة المفهوم ذاته بأسماء ومسارات واصطلاحات تسمية مختلفة. على سبيل المثال:

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

يوائم التوحيد هذه في نموذج متسق، بما يشمل اسم الكائن وإعادة تسمية التسمية والقيمة (باستخدام تحويل وحدة موحَّد):

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. الإثراء#

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

ثمة نهجان رئيسيان للإثراء:

توسيع البيانات إضافة بيانات وصفية أو تسميات إضافية إلى البيانات المرصودة لتكملتها. يمكن أن تكون هذه البيانات ثابتة (مثل org=my-company) لتمييز جميع بياناتك، أو ديناميكية بناءً على سياق الجمع (مثل collector_id=1234)، أو ديناميكية بناءً على البيانات المرصودة ذاتها (مثل، بالنظر إلى hostname=rtr-1، إنشاء تسمية location=BCN-01 بالربط مع مصدر الحقيقة).
```
intf_oper_state{
    name="swp1", 
    device="leaf01",
    role="leaf",
    location="BCN0001"
} 1
```
إنشاء بيانات جديدة باتباع نمط “مقاييس المعلومات” في نظام Prometheus البيئي، يمكننا توليد مقاييس لا تمثل الحالة الفعلية بل الحالة المقصودة. هذه المقاييس مفيدة في مراحل لاحقة من خط أنابيب الرصد لإضافة أبعاد أكثر للتحليل، كما ستكتشف في قسم التنبيه.
```
device_info{
    name="leaf1",
    role="leaf",
    vendor="arista",
    model="7050SX3",
    platform="eos",
    os_version="4.29.2F",
    location="BCN0001",
    rack="AB1",
    rack_unit="U32",
    environment="prod"
} 1
```
مقاييس المعلومات نوع فضولي من البيانات لا تحمل البيانات ذات الصلة في القيمة (مثل الـ1 في المقاييس السابقة) بل في التسميات. تتيح هذه الحيلة إعادة استخدام Time Series Database (TSDB) التي لا تدعم بعض أنواع القيم (كالسلاسل النصية).

كلا النهجين يُضيفان تسميات وسياقاً. ذلك قوي للتنبيهات والتحليل. لكن ثمة تكلفة للتفكير فيها:

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

6.2.3.3. التحويل / الاشتقاق / التجميع#

خذ المقاييس الخام واشتق منها مقاييس جديدة. مثال: دمج جميع حركة مرور إدخال الواجهة من مفاتيح الطبقة الأساسية والعمود الفقري في مقياس واحد “عرض نطاق ترددي الشبكة المستخدَم” للاتجاهات. تجمع البيانات الموجودة للإجابة عن أسئلة أكبر أو تغذية لوحات المعلومات. تُسمي Prometheus هذا “قواعد التسجيل.”

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

في النظام البيئي لـPrometheus، يُعرف هذا بـقواعد التسجيل (recording rules).

وظيفة معالجة أخرى لتقليل كمية البيانات هي التجميع، بتقليص الأبعاد المعدَّلة للاستخدام النهائي للبيانات. على سبيل المثال، تلخيص معلومات الواجهة لكل جهاز، أو تلخيص معلومات الجهاز لكل موقع. إنشاء حسابات المعدل من مقاييس العداد، أو تجميع المدرج التكراري، يمكن أن يكون مفيداً لكثير من التحليلات.

6.2.3.4. التصفية#

أسقط الزائد مبكراً. ليس كل سطر سجل يستحق التخزين. لا كل مقياس واجهة مهم (ربما لا تهتم بواجهات loopback). كلما صفّيت مبكراً، كلما أهدرت أقل في التخزين والمعالجة. القوائم البيضاء (احتفظ فقط بهذا) أأمن من القوائم السوداء (أسقط ذاك).

6.2.3.5. أخذ العينات / التقليص#

حتى بعد التصفية، قد يبقى الحجم مرتفعاً جداً. قلِّص. اعتمد أخذ عينات احتمالي (“احتفظ بـ10% من هذه الطلبات”)، ركِّز على أعلى K مقياساً (“خزِّن فقط أكثر 100 واجهة ازدحاماً”)، أو حدِّد معدلاً لكل مصدر (“بحد أقصى 1000 مقياس لكل جهاز”). مع تقادم البيانات في قاعدة بياناتك، أدمجها (دقة 5 ثوانٍ تصبح متوسطات 5 دقائق) لتوفير المساحة.

أخيراً، يمكن تشغيل جميع هذه المعالجات في مراحل مختلفة من خط أنابيب الرصد الشامل، اعتماداً على حالة الاستخدام:

المجمِّع: الأفضل للتوحيد الخفيف المبكر والتصفية
معالج مخصص: مطلوب على نطاق واسع للإثراء الديناميكي والتحويلات المعقدة
طبقة الحفظ: مناسبة لقواعد التسجيل والتدمير على المدى الطويل (يجب دائماً حدوث التوحيد قبل هذا)
طبقة التنبيه: تشتق الأحداث من البيانات المخزنة وتطبق منطق الأعمال

في الواقع العملي، تُوزِّع خطوط أنابيب الرصد الفعّالة المعالجة عبر الطبقات، اعتماداً على الأدوات والنطاق والقيود التشغيلية.

6.2.4. التوزيع#

خطوط الأنابيب الخطية البسيطة (مجمِّع ← معالج ← قاعدة بيانات) لا تتوسع. إذا تباطأت قاعدة البيانات، يتراكم المجمِّع. إذا احتجت ترقية المعالج، توقف الجمع. كل شيء مترابط وهش.

هنا يأتي دور وسطاء الرسائل.

وسطاء الرسائل كـApache Kafka أو NATS تجلس في المنتصف. المنتجون (المجمِّعات، الأجهزة) ينشرون في مواضيع. المستهلكون (المعالجات، قواعد البيانات، التنبيه) يسحبون بوتيرتهم الخاصة. مفصولة تماماً.

المزايا:

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

راجع الفصل 11 لمزيد من أنماط التوسع والموثوقية.

6.2.5. الحفظ#

حالما تُعالَج البيانات، تحتاج مكاناً تعيش فيه. تخزن طبقة قاعدة البيانات جميع بيانات الرصد الشامل. تحتاج التعامل مع أحجام ضخمة ودعم استعلامات سريعة وإبقاء التكاليف معقولة.

قواعد البيانات الجيدة للرصد الشامل تشترك في سمات مشتركة:

وعي بالوقت: البيانات مُختومة بطابع زمني بطبيعتها. قواعد البيانات مُحسَّنة لاستعلامات النطاق والحسابات ذات النافذة الزمنية.
إنتاجية كتابة عالية: استيعاب مستمر للمقاييس. قواعد البيانات تتعامل معه دون تباطؤ.
متعددة الأبعاد: المقاييس تحمل تسميات (الجهاز، الواجهة، الموقع). الاستعلام والتجميع بكفاءة.
استعلامات مرنة: تحتاج لغات تعبيرية (PromQL، LogQL) لاستكشاف البيانات دون مخططات معرَّفة مسبقاً.
إدارة دورة الحياة: التخزين ينمو بسرعة. دعم الاحتفاظ والتخفيض والحذف للتحكم في التكاليف.
مرونة المخطط: مقاييس جديدة تظهر باستمرار. قواعد البيانات تتعامل مع التطور دون ترحيلات مكلفة.

أي أنواع قواعد البيانات تنجح؟

لا توجد قاعدة بيانات واحدة تتعامل مع جميع أعباء الرصد الشامل بشكل مثالي، ومن يقول غير ذلك يبيع شيئاً. إليك ما ينجح فعلاً:

قواعد بيانات السلاسل الزمنية (Time Series Database (TSDB)): هنا تبدأ. فازت Prometheus في حرب المقاييس. أصبح نموذج بياناتها (مقاييس بتسميات) المعيار الواقعي، وPromQL لغة الاستعلام التي يعرفها الجميع. استخدم Prometheus إن كانت لديك أقل من 100 مليون سلسلة نشطة. وراء ذلك، انظر إلى VictoriaMetrics (متوافقة مع Prometheus، تتوسع بشكل أفضل، تستخدم ذاكرة أقل). InfluxDB مقبولة لكن ترخيصها يتغير باستمرار. تجنب الحلول الخاصة بالمورد ما لم تكن مرتبطاً بنظامه البيئي.
قواعد البيانات العمودية: ClickHouse ملكة هنا. سريعة بشكل لافت لتجميع السجلات وتحليل التدفق. إذا احتجت الاستعلام عبر مليارات الصفوف للإبلاغ أو التحليل التاريخي، هذه هي أداتك. InfluxDB v3 تحاول المنافسة لكن ClickHouse تتمتع بسنوات من التصليب. ملفات Parquet تعمل لأعباء التحليلات حيث لا تحتاج كتابات في الوقت الفعلي (كما تفعل Suzieq).
قواعد البيانات للبحث النصي: Elasticsearch إن اضطررت، لكن بصراحة، البدائل الحديثة كـLoki (من Grafana) أبسط وأرخص في التشغيل. Splunk رائع إن كان شخص آخر يدفع تكلفته. السر القذر: معظم الفرق تُفرط في الاستثمار في البحث في السجلات وتُقلِّل من الاستثمار في التسجيل المنظَّم الذي سيجعل البحث غير ضروري.

توصيتي: ابدأ بـPrometheus (أو ما شابهه) للمقاييس، وLoki (أو ما شابهه) للسجلات. أضف ClickHouse (أو ما شابهه) حين تحتاج تحليلاً تاريخياً جدياً. هذه المجموعة ستصلك إلى نطاق ضخم قبل أن تحتاج شيئاً أكثر تطوراً.

هذا التصنيف ليس مطلقاً؛ معظم الأدوات لها تصنيف أساسي ثم تُطبِّق بعض خصائص الأخرى (خاصةً السلاسل الزمنية).

مفهومان مهمان عند تصميم التخزين: الرتبة العددية (كم قيمة فريدة يمكن أن تأخذها التسمية) والأبعادية (كم تسمية يحمل مقياس واحد). تسميات ذات رتبة عددية عالية مضروبة في أبعاد كثيرة = انفجار في البيانات المخزنة وتباطؤ في الاستعلامات. هذا أحد أكبر التحديات في الرصد الشامل. راجع الفصل 11 لاعتبارات التوسع العميقة.

لكل قاعدة بيانات خصائصها التي يجب تعيينها لحالات الاستخدام التي تحتاج حلها. على سبيل المثال، تستخدم Suzieq حلاً عمودياً (ملفات Apache Parquet) لأن الأسئلة التي تحاول الإجابة عنها علائقية وليست زمنية. مثال: “أي مسارات موجودة على الأعمدة الفقرية لكن ليس على جميع الأوراق؟”

المتطلبات:
- التصفية عبر سمات كثيرة
- مقارنة الصفوف عبر الأجهزة
- ضم جداول (الواجهات، الجيران، المسارات)
- النظر إلى الحالة في نقطة زمنية (ليس التطور التاريخي)
الحل: هذا ما صُمِّم من أجله حل التحليل العمودي. يمكن لـTime Series Database (TSDB) المساعدة في التحقق من عدد المسارات، لكن لتحديد المسارات المفقودة ستتطلب تسميات كثيرة، وهو ليس قوتها الرئيسية.

بعد جميع إدارة البيانات، تبقى خطوتان أخيرتان:

إنشاء أحداث لاستخدام أتمتة أخرى بها أو تدخل بشري: التنبيه
تصور البيانات لتوفير معلومات لاتخاذ القرار: التصور

6.2.6. التنبيه#

التنبيهات تحوّل البيانات إلى إجراء. هدفك: إرسالها إلى الأتمتة. إشعار البشر حين لا تستطيع الأتمتة إصلاحها.

تمر التنبيهات بمراحل:

الاكتشاف: إيجاد خطأ ما في البيانات.
المعالجة: الإثراء بالسياق. هل هو حرج؟ ثانوي؟ إنذار كاذب؟ ربط التنبيهات ذات الصلة لتقليل الضوضاء.
التوجيه: الإرسال إلى التنسيق (تشغيل سير العمل)، أو الفرق (Slack)، أو إدارة الحوادث (PagerDuty).
التصعيد: إن فشلت الأتمتة، يتولى البشر.

flowchart LR
    A[الاكتشاف] --> B[المعالج] --> C[التوجيه] --> D[التصعيد]

الشكل 5: مراحل التنبيه.

الصعب ليس إعداد التنبيهات. إنه منع إجهاد التنبيهات. رأيت مراكز عمليات شبكة مع 10,000 تنبيه نشط لا ينظر إليها أحد. عند تلك النقطة، لا يوجد رصد، بل ضجيج مكلف.

إليك كيف تُصلح ذلك فعلاً:

وجِّه 95% من التنبيهات إلى الأتمتة، لا البشر. إن رأى إنسان تنبيهاً، فلأن الأتمتة حاولت وفشلت. تذبذب واجهة؟ تتحقق الأتمتة مما إذا كانت صيانة، تُعيد تشغيل البصريات، تفتح تذكرة مع المورد. يُنبَّه الإنسان فقط إن لم تستطع الأتمتة حله.
تخلَّص من الحدود الثابتة. تنبيهات “المعالج > 80%” عديمة الفائدة. قد يكون 80% طبيعياً لذاك الجهاز. استخدم خطوطاً أساسية ديناميكية: نبِّه حين ينحرف شيء عن نمطه التاريخي، لا عن رقم اعتباطي.
جمِّع التنبيهات ذات الصلة. حين يتعطل مفتاح أساسي، ستتلقى 500 تنبيه من الأجهزة اللاحقة. أظهر واحداً: “مفتاح أساسي معطوب، 500 جهاز متأثر.” لا 500 تنبيه فردي.
اشترط دليل إجراءات لكل تنبيه. إن لم تستطع كتابة ما يجب فعله حين يتلقى أحد التنبيه، احذف التنبيه. بجدية. إن كان الإجراء هو “تحقق”، فهذا ليس إجراءً، بل إهدار للوقت.
قِس جودة التنبيه. تتبع معدلات الإنذارات الكاذبة. أي تنبيه بنسبة إنذارات كاذبة تتجاوز 10% يُصلَح أو يُحذف. تتبع الوقت حتى الإقرار. إن بقيت التنبيهات دون إقرار لساعات، فهي ليست مهمة بما يكفي للوجود.

الهدف ليس “رصد شامل.” الهدف هو “إشعار البشر فقط بما يحتاج بشراً لإصلاحه.”

6.2.6.1. دور الذكاء الاصطناعي وAIOps في الرصد الشامل#

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

ما ينجح فعلاً:

اكتشاف الشذوذ: التعلم الآلي أفضل حقاً من الحدود الثابتة في تعلم “الطبيعي” لكل جهاز. قد يكون 85% للمعالج جيداً للجهاز A، وكارثة للجهاز B. يكتشف التعلم الآلي ذلك تلقائياً. هذا معيار الآن، لا سحر.
ربط التنبيهات: حين تتعطل 50 شيئاً في آنٍ واحد، يمكن للتعلم الآلي تجميعها والاقتراح “المفتاح الأساسي على الأرجح السبب الجذري.” يوفر ساعات من التشخيص. لكنك لا تزال تحتاج بشراً للتحقق، لأن التعلم الآلي يُخطئ في 20% من الأحيان.
توقع الطاقة: التعلم الآلي جيد في “بناءً على الاتجاهات، سيصل هذا الرابط إلى التشبع في 6 أسابيع.” أفضل من البشر الذين يحدّقون في الرسوم البيانية. لا يزال يحتاج حكماً بشرياً حول ما إذا كان الاهتمام يستحق.

ما يُبالَغ في تقديمه:

تحليل السبب الجذري التلقائي: كل مورد يعد بذلك. لا أحد يُقدِّم بشكل موثوق. ستحصل على اقتراحات، أحياناً جيدة، لكن “الذكاء الاصطناعي شخّص وأصلح المشكلة” تسويق بنسبة 95% وأمثلة انتقائية بنسبة 5%.
الشبكات ذاتية الإصلاح: يمكن للأتمتة إصلاح مشكلات معروفة بحلول معروفة. هذا ليس ذكاءً اصطناعياً، بل هندسة جيدة. “الإصلاح الذاتي” الحقيقي لمشكلات جديدة غير موجود بعد. حين يُقدِّم الموردون عروضاً توضيحية، اطلب منهم إظهار حالات الفشل.
“AIOps يستبدل مركز عمليات الشبكة”: لا. AIOps يساعد مركز عمليات الشبكة على أن يكون أكثر فاعلية. الحكم البشري والسياق التجاري والقدرة على التعامل مع الحالات الحافة؟ لا يزال ذلك بشراً.

خلاصة: استخدم التعلم الآلي لاكتشاف الشذوذ وترتيب التنبيهات. كن متشككاً في كل شيء آخر حتى تختبره على شبكتك الفعلية، لا في عرض توضيحي من المورد.

6.2.6.2. واجهة التنبيه-إلى-إجراء#

التنبيه الذي يقرأه إنسان هو إشعار. التنبيه الذي تستهلكه الأتمتة هو عقد. لهذين المستهلكين متطلبات مختلفة، وخلطهما أحد أكثر أسباب فشل خطوط أنابيب التنبيه شيوعاً عند حد المنسِّق.

حين يكون التنبيه موجَّهاً للأتمتة، يجب أن تكون حمولته قابلة للاستهلاك آلياً دون تحليل. يعني ذلك بيانات منظمة، لا سطر موضوع يمكن للبشر قراءته. كحد أدنى، يجب أن تتضمن حمولة التنبيه المخصص للأتمتة:

هوية الجهاز: معرّف قانوني يتطابق مع سجل مصدر الحقيقة بدقة (لا اسم مضيف قد يختلف بين DNS والـCMDB)
فئة التنبيه: نوع ثابت ومُعدَّد يمكن للمنسِّق التوجيه بناءً عليه (لا وصف نصي حر يتغير حين يُعدِّل أحد قاعدة التنبيه)
الخطورة: تعداد محدد، لا قيمة حد عددي
الطابع الزمني: وقت الحدث بتنسيق UTC ISO 8601، لا وقت تسليم الإشعار
السياق ذو الصلة: المقياس أو الحالة المحددة التي أشعلت التنبيه، في حقل يمكن للمنسِّق قراءته مباشرةً (مثل "interface": "Ethernet0/1"، لا مضمناً في سلسلة الرسالة)
أثر المصدر: رابط أو مرجع يعود إلى الحدث الخام في نظام الرصد الشامل، حتى يتمكن المنسِّق من إعادة الاستعلام عن سياق إضافي

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

حدِّد هذا العقد قبل بناء قواعد التنبيه، لا بعده. كُتّاب قواعد التنبيه الذين يكتبون للقراءة البشرية ينتجون رسائل يصعب أتمتتها. كُتّاب قواعد التنبيه الذين يكتبون للجمهورين معاً ينتجون رسائل لا تخدم أياً منهما جيداً. الحل الأنظف هو مسارا توجيه متوازيان: تنسيق تنبيه للبشر (Slack، PagerDuty)، وآخر للأتمتة (قائمة رسائل، نقطة نهاية webhook). كلاهما مُشغَّل بنفس قاعدة الاكتشاف؛ قوالب حمولة مختلفة لمستهلكين مختلفين.

6.2.7. التصور#

الهدف: يجب أن توفر جميع البيانات المرصودة قيمة لمتخذي القرار، لذا يجب أن يُجيب التصور الموجَّه للمستخدم على احتياجاته.

الكتلة الأخيرة هي طبقة لوحات المعلومات/التقارير. دعني أكون صريحاً: معظم لوحات المعلومات رديئة. إما مقاييس تجميلية تجعل المسؤولين يشعرون بالرضا (“وقت تشغيل 99.99%!”) أو تقيء بيانات (50 رسماً لكل شاشة، لا أحد يعرف ما تعنيه أي منها).

إليك كيف تبني لوحات معلومات تساعد فعلاً:

ابنِ للقرارات، لا للزينة. كل عنصر تحكم يجب أن يُجيب عن سؤال محدد أو يُشغِّل إجراءً محدداً. إن نظر أحد إلى رسم بياني ولا يعرف ما يفعله به، احذف الرسم البياني.
أظهر المشكلات، لا مجرد البيانات. إشارات أخضر/أصفر/أحمر تتفوق على الأرقام الخام. “استخدام الواجهة: 45%” عديم الفائدة. “استخدام الواجهة: طبيعي” أو “استخدام الواجهة: تحذير، يتجه نحو التشبع” قابل للتنفيذ.
التعمق الهرمي يتفوق على لوحة معلومات كبيرة واحدة. ابدأ بملخص صحة شامل (“3 مواقع تواجه مشكلات”). انقر موقعاً لرؤية صحة الجهاز. انقر جهازاً لرؤية الواجهات. خمس لوحات معلومات مركزة تتفوق على كارثة واحدة مزدحمة.
طابق الجمهور. يحتاج موظفو مركز العمليات حالة تشغيلية في الوقت الفعلي وتعمقاً. يحتاج المديرون ملخصات الاتجاهات والتأثير التجاري. يحتاج المهندسون وصولاً للبيانات الخام وواجهات استعلام. لوحة معلومات واحدة تحاول خدمة الجميع لا تخدم أحداً.
اجعلها تفاعلية أو لا تهتم. لوحات المعلومات الثابتة تشيخ بشكل سيئ. دع الناس يصفّون ويقرّبون ويضبطون النطاقات الزمنية. ادعم التحقيق، لا مجرد عرض صور جميلة.

وهنا الرأي الجريء: معظم الفرق لديها لوحات معلومات كثيرة جداً. رأيت مؤسسات مع أكثر من 200 لوحة معلومات حيث ينظر كل شخص إلى 2 منها. احذف لوحات المعلومات التي لا يستخدمها أحد. إن لم ينظر إليها أحد لمدة 3 أشهر، فهي لا تهم.

حد التصور/العرض

يقع التصور عند حد معماري يستحق معالجته مباشرةً بدلاً من تركه كحاشية سفلية. طبقة العرض (الفصل 8) مسؤولة عن الواجهات الموجَّهة للمستخدم: التحكم في الوصول وبوابات الخدمة الذاتية وتكامل ITSM وتصميم تجربة المستخدم لكيفية طلب الناس المعلومات واستهلاكها. تصور بيانات الرصد الشامل ينتمي هنا في الفصل 6 لأن قرارات التصميم مدفوعة كلياً بالبيانات: أي مقاييس متاحة، وكيف يُهيكَل التنبيه، وما مسارات التعمق التي تدعمها طبقة الحفظ. لا يمكنك تصميم لوحة معلومات رصد فعّالة دون فهم نموذج البيانات خلفها.

التمييز المهم عملياً: لوحات المعلومات المبنية مباشرةً على بيانات الرصد للقرارات التشغيلية (ما يحدث الآن، هل هذه الخدمة سليمة) هي اهتمام بالرصد الشامل. كيف تُعرض تلك اللوحات ذاتها للمستخدمين غير التقنيين، أو مضمَّنة في بوابة خدمة ذاتية، أو مدمجة مع سير عمل إدارة التغيير هو اهتمام بالعرض. يعود الفصل 8 إلى هذه الأدوات من منظور الوصول وسير العمل. معظم أدوات التصور (Grafana هي الأكثر شيوعاً) تطمس هذا الخط بالقيام بالأمرين معاً، وهو ما يجعل الفصل يبدو اصطناعياً. إنه ليس كذلك. الاهتمامات مختلفة حقاً حتى حين تخدم نفس الأداة الاثنين.

القواعد الأساسية:

الوضوح: سهل الفهم. كل عنصر له غرض.
الصلة: أظهر فقط البيانات التي تدعم القرارات. الضجيج يقتل الفهم.
موجَّه للمستخدم: ابنِ لجمهورك. يحتاج موظفو مركز العمليات والمديرون رؤى مختلفة.
تفاعلي: دع الناس يتعمقون ويقرّبون ويضبطون الوقت. ادعم التحقيق.
هرمي: نظرة عامة شاملة أولاً، ثم التعمق. لوحات معلومات مركزة كثيرة تتفوق على لوحة معلومات واحدة مزدحمة.

flowchart TD
    A[نظرة عامة شاملة] --> B[ملخص الموقع] --> C[ملخص الجهاز] --> D[تفاصيل الجهاز] --> E[تفاصيل الواجهة]

الشكل 6: التعمق الهرمي.

في كتاب Modern Network Observability، الفصل 11 (“تطبيق بيانات الرصد الشامل”) يمكنك إيجاد تفاصيل أكثر بكثير لهيكلة لوحات المعلومات.

ضع في اعتبارك أن هذه الكتلة مرتبطة ارتباطاً وثيقاً بتصور المستخدم، لذا لا تنس مقابلتهم وإشراكهم في العملية.

6.2.8. رصد نظام الأتمتة#

معظم الفرق تبني رصداً للشبكة. لا تكاد أي منها تبني رصداً لنظام الأتمتة ذاته. هذه نقطة عمياء مهمة: حين يتعطل خط أنابيب الأتمتة، كثيراً ما يكون الفشل صامتاً. لا تنبيه يُطلق، لأن النظام المسؤول عن توليد التنبيهات قد يكون هو الذي توقف عن العمل.

دليل إجراءات يخرج بالحالة 0 بعد النشر على صفر أجهزة لا يولد خطأً. مثيل Telegraf يتوقف بصمت عن استطلاع بروتوكول خاص بمورد لا يولد تنبيه بيانات مفقودة ما لم تُعدَّ قياساً خاصاً لذلك. وظيفة مزامنة مصدر الحقيقة تفشل في الساعة 2 صباحاً وتترك الجرد قديماً بـ12 ساعة ستُسبب لكل تنفيذ لاحق العمل على قوائم أجهزة قديمة، ولن يُشير شيء إلى حدوث ذلك.

ما تراقبه في منصة الأتمتة

طبقة التنفيذ (AWX، Ansible):
- معدل نجاح الوظائف بمرور الوقت: معدل فشل يرتفع ببطء هو تحذير مبكر بأن شيئاً يتدهور
- مدة التنفيذ: وظيفة تستغرق عادةً 4 دقائق وتأخذ 40 دقيقة تُشير إلى مشكلة في المنصة أو الشبكة أو كليهما
- وظائف عالقة في حالة الانتظار أو التشغيل لفترة تتجاوز نافذتها المتوقعة
- تكرار التراجع: معدل تراجع متصاعد يعني عادةً أن بيانات النوايا أو القوالب بها عيب
- الأجهزة المُوصَلة لكل وظيفة مقارنةً بالمتوقعة: نشر يُلامس 10 أجهزة بدلاً من 800 ربما فشل بصمت في مزامنة جرده دون خطأ
طبقة مصدر الحقيقة:
- وقت استجابة الـAPI ومعدل الأخطاء: API مصدر حقيقة بطيء سيوقف كل وظيفة تنفيذ تستعلمه
- صحة وظيفة المزامنة لكل مصدر: آخر وقت مزامنة ناجحة، عدد الفشل المتتالي
- اكتمال البيانات: كم سجل جهاز يفتقر إلى حقول إلزامية يعتمد عليها التنفيذ
طبقة الجمع:
- آخر طابع زمني لجمع ناجح لكل جهاز: جهاز لم يُستطلَع في ثلاث فترات متتالية هو نقطة عمياء فعلية في الرصد
- تأخر الجمع عبر الأسطول: إن كان متوسط عمر البيانات يتصاعد، فالمجمِّع يتأخر
- دورات الاستطلاع الفائتة لكل بروتوكول: يجب إحصاء أخطاء SNMP وانقطاعات اشتراك gNMI والتنبيه عنها بشكل منفصل

مشكلة الفشل الصامت

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

يعني ذلك إضافة مقاييس نتائج إلى وظائف التنفيذ: عداد للأجهزة التي تم تهيئتها بنجاح، مقياس للأجهزة التي تطلبت تراجعاً، وفحص يتأكد أن الوظيفة لامست على الأقل N أجهزة قبل تصنيفها ناجحة.

التوصية المعمارية

راقب منصة الأتمتة في مجموعة رصد منفصلة وصغيرة لا تعتمد على نظام الرصد الشامل الأساسي الذي تدعمه. إن توقف مثيل Prometheus الرئيسي، فلا يجب أن يتوقف التنبيه لخط أنابيب الأتمتة معه. مجموعة ثانوية خفيفة (أو خدمة تنبيه SaaS) تغطي فقط صحة مكونات الأتمتة الأساسية (AWX، Telegraf، API مصدر الحقيقة، وظائف المزامنة) توفر شبكة أمان لا يستطيع نظام الرصد الشامل الأساسي توفيرها لنفسه.

يرتبط هذا مباشرةً بالفصل 7 (التنسيق): على المنسِّق السليم الإبلاغ عن حالته التشغيلية ذاتها كاهتمام من الدرجة الأولى. إن لم يكن يمكن رصد المنسِّق، لا يمكن رصد الأتمتة التي ينسّقها.

6.3. مثال تطبيقي#

يُوضح هذا القسم كيف تتضافر وظائف الرصد الشامل من خلال حالة استخدام عملية باستخدام مجموعة Telegraf وPrometheus وGrafana وأدوات أخرى.

هذا ليس توصية بأدوات على الإطلاق، لكن لأنها مبنية بالكامل على مكونات مفتوحة المصدر، يمكنك تجربتها.

6.3.1. حالة الاستخدام: التحقق من النشر المستمر والرصد الجاري لخدمة حرم جامعي#

نواصل مع شبكة الحرم الجامعي من الفصل 5. تم نشر خدمة VLAN الجديدة عبر المفاتيح المستهدفة في building-b بواسطة كتلة التنفيذ. الآن يتولى الرصد الشامل: أولاً للتحقق من نجاح النشر فعلياً من منظور حالة الشبكة، ثم لمراقبة صحة الخدمة بشكل مستمر عبر الحرم الجامعي بأكمله.

السيناريو: بعد نشر قطاع خدمة VLAN جديد عبر حوالي 800 مفتاح حرم جامعي من Cisco وArista وHPE، يحتاج فريق العمليات التأكيد من أن الخدمة نشطة ومتسقة على جميع الأجهزة المستهدفة، اكتشاف الانجراف في التهيئة إذا فقد مفتاح الـVLAN، ومراقبة صحة حركة مرور الخدمة بمرور الوقت، دون فحوصات يدوية لكل جهاز.

المتطلبات:

التحقق من أن عضوية VLAN نشطة ومتسقة عبر جميع المفاتيح المستهدفة بعد النشر
التنبيه على انجراف التهيئة: VLAN مفقود من مفتاح، تغييرات غير متوقعة في عضوية الـtrunk
مراقبة صحة حركة مرور الخدمة: مستويات الاستخدام ومعدلات الأخطاء لكل منفذ وصول
اكتشاف الارتفاعات المفاجئة في حركة المرور (>50% تغيير) التي قد تشير إلى تدفقات موجَّهة بشكل خاطئ
الحفاظ على 30 يوماً من البيانات بدقة 30 ثانية للامتثال وتخطيط الطاقة
التكامل مع Nautobot لجرد الأجهزة وبيانات نوايا VLAN
تشغيل سير عمل التنسيق للمعالجة الآلية حين يُكتشف الانجراف

6.3.2. بنية الحل#

قبل بدء تحليل الحل، من المهم تقدير حجم السيناريو. مع حوالي 800 مفتاح حرم جامعي × 48 منفذاً × 8 مقاييس = حوالي 307 ألف سلسلة زمنية نشطة. هذا في متناول ما يمكن لعقدة Prometheus واحدة التعامل معه (مريح حتى حوالي 1 مليون سلسلة)، لكن طبقة المجمِّع تحتاج عدة مثيلات Telegraf لتوزيع حمل الاستطلاع عبر 800 جهاز بفترات 30 ثانية.

مبررات اختيار المكونات:

Telegraf اختير كمجمِّع لدعمه متعدد البروتوكولات (SNMP للأجهزة القديمة HPE وCisco القديمة، gNMI لـArista وCisco الأحدث)، نظامه البيئي الواسع من الإضافات، والمعالجات المدمجة لتوحيد البيانات. على نطاق 800 جهاز، سيكون مثيل Telegraf واحد مجهَداً بفترات استطلاع 30 ثانية، لذا يُنشَر مثيلان أو ثلاثة مع تنسيق Consul للأهداف التي يملكها كل منها.
Prometheus يخدم كطبقة حفظ، محسَّنة لبيانات السلاسل الزمنية مع لغة استعلام PromQL القوية لشروط التنبيه المعقدة. بـ32 ألف سلسلة، يعمل داخل منطقة ارتياحه مع تكامل أصيل مع Alertmanager.
Grafana توفر تصوراً بدعم متعدد مصادر البيانات، تستعلم كلاً من مقاييس Prometheus وبيانات Nautobot الوصفية في آنٍ واحد لإنشاء لوحات معلومات غنية بالسياق مُصمَّمة لجمهور مختلف (مركز العمليات، تخطيط الطاقة، الإدارة).

البنية المعمارية

على مستوى عالٍ، يصوّر الشكل التالي المكونات الرئيسية وأدوارها:

flowchart TB
    subgraph Sources["مصادر البيانات"]
        NB[Nautobot<br/>مصدر الحقيقة]
        SW[أجهزة الشبكة<br/>SNMP/gNMI]
    end

    subgraph Collection["طبقة الجمع"]
        T[Telegraf<br/>المجمِّعات]
        SD[Consul<br/>اكتشاف الخدمات]
    end

    subgraph Storage["التخزين"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["التنبيه"]
        AM[Alertmanager<br/>التوجيه]
    end

    subgraph Presentation["التصور"]
        G[Grafana<br/>لوحات المعلومات]
    end

    subgraph Integration["الأنظمة الخارجية"]
        ORCH[المنسِّق<br/>الأتمتة]
        SLACK[Slack<br/>الإشعارات]
    end

    NB -->|جرد الأجهزة| SD
    SD -->|أهداف ديناميكية| T
    SW -->|المقاييس| T
    T -->|نشر HTTP| P
    P -->|قواعد التنبيه| AM
    P <-->|الاستعلامات| G
    NB -->|البيانات الوصفية| G
    AM -->|Webhook| ORCH
    AM -->|التنبيهات| SLACK

الشكل 7: مثال حل الرصد الشامل.

تُغطى بنية الحل المبسَّطة هذه بشكل موسع في كتاب Modern Network Observability. إن أردت نهجاً عملياً مع سيناريو مختبر للاختبار، جرّبه.

6.3.3. تدفق التطبيق#

تكامل الجرد: يخدم Nautobot كمصدر الحقيقة الوحيد، يحدد الأجهزة المراد رصدها مع ملفات تعريف الرصد وبيانات اعتماد SNMP. تُحدِّث خدمة مزامنة خفيفة (مثل سكريبت Python يستخدم webhooks) بشكل مستمر سجل خدمات Consul بمعلومات الجهاز، مما يتيح الاكتشاف الديناميكي من المجمِّع.

جمع البيانات: يستخدم Telegraf Consul للاكتشاف الديناميكي للخدمات، يستطلع SNMP تلقائياً من الأجهزة حين تظهر في Nautobot. يوحِّد معالجات Telegraf ويُثري البيانات (تحويل رموز الحالة إلى تسميات، إعادة تسمية الحقول إلى أسماء معيارية، وإضافة معلومات سياقية من Nautobot) ويكشف المقاييس بتنسيق Prometheus على نقطة نهاية HTTP.

الحفظ والتحليل: تكشط Prometheus نقاط نهاية Telegraf باستخدام اكتشاف خدمات Consul، تخزن المقاييس في قاعدة بياناتها للسلاسل الزمنية. قواعد التسجيل تُحسب مسبقاً نسب استخدام الواجهة ومعدلات النطاق الترددي لتحسين أداء الاستعلام.

منطق التنبيه: تحدد قواعد التنبيه في Prometheus الشروط (مثلاً استخدام الواجهة >80% لمدة 5 دقائق، ارتفاعات حركة المرور >50% زيادة). حين تتطابق الشروط، يتولى Alertmanager التوجيه، وتذهب التنبيهات الحرجة بتسميات automation: enabled إلى webhook المنسِّق، وتُوجَّه الأخرى إلى Slack أو PagerDuty بناءً على الخطورة.

التصور: توفر لوحات معلومات Grafana رؤى متعددة: اتجاهات النطاق الترددي على مستوى الشبكة، أعلى الواجهات تشبعاً، تعمق لكل جهاز مع خرائط حرارية للواجهة. المتغيرات القالبية تتيح التصفية حسب الموقع أو الدور أو الجهاز. تستعلم لوحات المعلومات كلاً من Prometheus (المقاييس) وNautobot (البيانات الوصفية للجهاز) للإثراء السياقي.

الأتمتة ذات الحلقة المغلقة: حين تنطلق تنبيهات التشبع الحرجة، يرسل Alertmanager webhooks إلى منصة التنسيق التي تُشغِّل سير عمل هندسة حركة المرور الآلية لإعادة توزيع الحمل عبر المسارات المتاحة. نغطي هذا المكوّن في الفصل 7.

6.3.4. ملخص الحل#

الفوائد التشغيلية:

تقليل جهد المراقبة اليدوية من خلال تكامل مصدر الحقيقة
اكتشاف استباقي للمشكلات بزمن استجابة أقل من دقيقة
معالجة ذات حلقة مغلقة تُقلص متوسط وقت الاسترداد من ساعات إلى دقائق
سياق غني يجمع المقاييس مع بيانات الجرد

اعتبارات التوسع:

تتعامل البنية الحالية مع حوالي 800 مفتاح حرم جامعي باستخدام 2-3 مثيلات Telegraf موزعة خلف Consul؛ إضافة مبانٍ أو أجهزة أكثر يعني إضافة مثيلات مجمِّع أكثر، لا إعادة هيكلة
طاقة Prometheus كافية بحوالي 307 ألف سلسلة مع مجال للنمو؛ عقدة واحدة تتعامل مع حتى حوالي 1 مليون سلسلة قبل الحاجة إلى الاتحاد أو backend موزَّع

يُغلق هذا التمرين التطبيقي الموجز هذا الفصل الذي يُعرِّف الأهداف والوظائف الأساسية للرصد الشامل ضمن بنية أتمتة الشبكة.

6.4. الملخص#

يمتد الرصد الشامل في أتمتة الشبكة إلى ما هو أبعد بكثير من المراقبة التقليدية، ليوفر الأساس المعماري لفهم سلوك الشبكة واكتشاف المشكلات استباقياً وتمكين المعالجة الآلية على نطاق واسع. مبني على سبعة أهداف أساسية، من الاكتشاف الآلي بأقل جهد بشري إلى التحليل المتطور القريب من الوقت الفعلي والتصورات الموجهة للمستخدم، يُحوِّل الرصد الشامل كيفية استجابة المؤسسات لأحداث الشبكة بالتحول من التشخيص التفاعلي إلى العمليات الاستباقية المدفوعة بالبيانات.

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

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

الرصد الشامل ليس أداة واحدة بل نمط معماري متسق. يعتمد النجاح على التعامل معه كنظام، حيث يقود الجرد الجمع، والجمع يُمكِّن المعالجة، والمعالجة تُغذِّي التوزيع، والتوزيع يتصل بالحفظ، والحفظ يُعلم التنبيه، والتنبيه يقود في نهاية المطاف التصور والاستجابة الآلية. بتصميم كل مكوّن وكيفية تفاعله بعناية، يمكن للمؤسسات بناء أنظمة رصد تتوسع مع شبكاتها وتتكامل مع البروتوكولات الحديثة كـOpenTelemetry وgNMI، وتُحوِّل الرؤية التشغيلية إلى ذكاء قابل للتنفيذ يُشغِّل الأتمتة ذات الحلقة المغلقة.

المراجع والقراءات الإضافية#

Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): نهج عملي باستخدام أدوات مفتوحة المصدر كـTelegraf وPrometheus وGrafana

💬 Found something to improve? Send feedback for this chapter