الخلاصة

  • جعلت RFC 1451 محطة SNMPv2 تؤدي دور المدير والوكيل معاً كي تقدم خدمة مراقبة لمحطات إدارة أخرى.
  • فصلت جداول Alarm وEvent وNotification بين أخذ العينة وتصنيف تجاوز العتبة وتعريف الحدث واختيار وجهة الإخطار.
  • حمل صف الإخطار عداد عمر خاصاً؛ إذا لم يُجدّد دُمّر الصف، من دون أن يعني ذلك زوال تعريف الإنذار أو الحدث.

مدير يقدّم خدمة لمدير آخر

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

حدد جدول Alarm المتغير والفاصل الزمني وطريقة أخذ العينة والعتبات. وربط جدول Event الشرط بنوع حدث وسجل تاريخاً محلياً. أما جدول Notification فاختار، لكل حدث وسياق وجهة، كيفية إرسال InformRequest. لم يكن إنشاء الصف الأول إنشاء تلقائياً للمسار كله.

القيمة تخص فترة اكتملت

في النمط المطلق تقارن قيمة نهاية الفترة بالعتبتين. وفي نمط الفرق تطرح قيمة نهاية الفترة السابقة من الحالية. لا يعرض snmpAlarmValue الفترة الجارية؛ بل لا يظهر إلا بعد اكتمالها ويمثل آخر فترة مغلقة.

كانت الرؤية دورية لا متصلة. قد ترتفع قيمة بين عينتين ثم تعود من دون أن تحفظها الآلية. واقترحت الوثيقة أسلوباً أدق لبعض فروق الحدود، لكنها لم تضمن تنفيذه في كل جهاز.

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

التفويض لا يوسّع حق القراءة

كان على استعلام أخذ العينة أن يستخدم سياقاً وزوجاً من الأطراف يملكان حق الوصول وفق النموذج الإداري في RFC 1445. لم يسمح جدول Alarm بالالتفاف على رؤية MIB. القدرة على طلب المراقبة ليست سلطة جديدة على المورد.

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

التباطؤ يحسب التحول لا البقاء

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

ومن ثم فإن بقاء القيمة عالية لا يساوي حدثاً صاعداً جديداً. يعتمد العداد على اتجاه الانتقال السابق وحالة الآلة. وللعينة الأولى بعد تنشيط الصف سياسة بدء مستقلة يمكن أن تسمح بحدث أولي.

قد تعبر القيمة العتبة ولا يوجد حدث

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

يحمل صف Event معرّف OID لنوع الحدث وعدد مرات التوليد وsysUpTime المحلي لآخر توليد. هذه ذاكرة لدى المنشئ، وليست سجلاً لدى المستقبل.

المطلوب من إعادة الإرسال ليس المنفذ دائماً

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

استندت العملية المعاصرة إلى InformRequest في RFC 1448. وتصف RFC 3416 لاحقاً InformRequest بأنه إخطار مؤكد، مع التنبيه إلى عدم وجود ضمان للتسليم. عند الوصول الصحيح تُعرض المحتويات على التطبيق المناسب ويصدر Response. هذا لا يثبت صحة الحالة ولا أن إنساناً قرأها أو عالجها.

تنتهي العلاقة بعد 86400 ثانية افتراضياً

ينقص snmpEventNotifyLifetime بالثواني. وعند الصفر تتحول حالة صف الإخطار إلى destroy. كان على محطة الإدارة التي تستخدم الصف أن تجدده دورياً كي يستمر تسليم الأحداث.

ينتهي هنا الربط بين حدث ووجهة بعينها. لا تنص الوثيقة على أن انقضاء Notification يحذف Alarm أو Event في الاتجاه العكسي. يمكن للمنشئ أن يستمر في القياس والعد بينما فقدت إحدى المحطات مسارها إليه.

صفة Historic لا تصف انتشاراً حقيقياً

يصنف السجل الرسمي RFC 1451 اليوم على أنها Historic. كما تقول فقرة الأمن في الوثيقة إن قضايا الأمن غير مناقشة. لا يجوز تحويل ذلك إلى قصة عن منتج أو نشر أو حماية فعلية.

فصلت RFC 3413 لاحقاً بين منشئ الإخطار ومستقبله والأهداف والمرشحات والوكلاء. تبيّن هذه الوثيقة حد التطور فقط، ولا تُقدّم بديلاً مباشراً ولا تُسند آليات 2002 إلى نص 1993.

المصادر