الخلاصة

  • في الخط الزمني التوضيحي، يستمر انقطاع الرابط 14 ثانية، ثم تمر 23 دقيقة حتى أول شكوى و67 دقيقة أخرى من البحث عن السبب؛ المسار كله تقديره 90 دقيقة.
  • يجمع الاقتراح سجلات الموجهات وبيانات الجلسات في نقطة واحدة لدى مزود الخدمة، ويتيح للنموذج سؤال البيانات؛ هدف 18 دقيقة لم يُختبر ميدانياً.

في الخط الزمني التوضيحي، يستمر انقطاع الرابط 14 ثانية. تظهر أول شكوى بعد 23 دقيقة. ثم يقضي فريق الشبكة 67 دقيقة أخرى في البحث عن السبب. العطل قصير، لكن الفريق قد ينتظر ساعة ونصف ليعرف ما حدث.

عرض Joaquín Tadeo Riedmaier وSantiago Agustín Zualet هذا المثال في جلسة مجموعة قياس الإنترنت IMWG ضمن LACNIC 46 · LACNOG 2026 في مندوزا. وهما من كلية الهندسة في جامعة ميسيونس الوطنية. تصف الشرائح التسعين دقيقة بأنها تقدير معتاد لحادث حرج، وتوضح أن الأوقات افتراضية؛ فلا تعرض سجل حادث حقيقي. يقترح المتحدثان جمع الأدلة قبل أن يبدأ الفني البحث. يرسل النظام أحداث الموجهات إلى نقطة محلية، ثم يربط قياسات الواجهات وحالة المشتركين بموقع العطل في الطوبولوجيا.

تصل الأحداث عبر مسارين. الأول هو syslog عبر UDP. ينقل تغير حالة الوصلة والأخطاء وتذبذب الاتصال وانقطاعات PPPoE/RADIUS. والثاني واجهة REST في RouterOS v7. تقرأ حركة كل واجهة أو VLAN، والأخطاء والحزم المتروكة، واستخدام المعالج والذاكرة، وجداول ARP وتتبع الاتصالات. وتضيف RADIUS حالة الجلسات النشطة لكل NAS. عند جمع هذه البيانات، يمكن للفني معرفة ما إذا كانت واجهة متقطعة قد أسقطت جلسات محددة.

يضع التصميم نقطة الجمع داخل شبكة مزود الخدمة، في حاوية Docker. يستقبل Django سجلات syslog ويقرأ من الواجهة. ينظف Python البيانات ويوحد صيغها ويحذف التكرار ويطبق العتبات. وتحفظ PostgreSQL عروضاً مسطحة للاستعلام. بعد ذلك يحول نموذج لغوي محلي سؤال الفني إلى استعلام SELECT للقراءة فقط. تذكر الشرائح تجربة على جهاز بذاكرة 32 غيغابايت. لكنها لا تحدد النموذج أو حمل الاختبار أو زمن الإجابة.

يعرض مثال الشاشة سؤالاً عن الموجهات التي سجلت انقطاعات خلال أربع ساعات. تذكر الإجابة سبع حالات على ether2 في NAS 6 وتأثر 23 جلسة PPPoE. وتصف الشريحة المثال بأنه توضيحي. في شريحة أخرى، تتزامن أربعة مصادر عند 12:04، ثم يظهر احتمال عطل مادي في الوصلة. بيانات هذا السيناريو محاكاة، والاستنتاج ليس نتيجة قياس. العرض يوضح شكل الإجابة المطلوبة، لا حادثاً حقيقياً عالجه النظام.

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

تعرض الشرائح 90 دقيقة كتقدير و18 دقيقة كأثر متوقع. لكنها لا تذكر عدد الحوادث لدى مزود خدمة أو فترة أخذ القياسات أو أوقات التشخيص قبل التجربة وبعدها. ولا تعرض معدل الإنذارات الكاذبة أو طريقة حساب هدف ≥95٪. سجل تجريبي يربط هذه المؤشرات بكل حادث قد يغير الحكم.

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

المصادر: البرنامج الرسمي لـ LACNIC 46؛ عرض IMWG الأصلي.