الخلاصة

  • تصف timeQuality الاختيارية معرفة المصدر بالمنطقة الزمنية والمزامنة والانحراف المتوقع؛ ولا تختبر ساعة المصدر من جهة المستقبِل.
  • تمثل syncAccuracy الحد الأقصى الذي يتوقعه المصدر للانحراف بين فترات المزامنة. وتعتمد قيمتها على موثوقية مصدر الوقت وضبط المشغّل له.

ماذا يبقى من سياق الوقت في السجل المؤرشف؟

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

تحدد الفقرة 6.2.3 صيغة TIMESTAMP باستخدام شكل مقيد من RFC 3339، وتوصي بالكسور العشرية عندما تسمح دقة الساعة وأداؤها. أما الفقرة 7.1 فتسمح للمصدر بوصف تصوره لوقت النظام. هذا وصف صادر عن النظام نفسه، وليس اختباراً يجريه جامع السجلات بعد وصول الرسالة. لذلك ينبغي عدم مساواة طابع زمني صحيح نحوياً بقياس موثوق بشكل مستقل.

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

ثلاثة حقول، وثلاثة أنواع من المعرفة

يبين tzKnown ما إذا كان المصدر يعرف معلومات المنطقة الزمنية التي يستخدمها. ولا يعني ذلك أن القيمة يجب أن تظهر بالتوقيت المحلي؛ فالملحق يوضح أن المنطقة قد تكون معروفة حتى عندما تُكتب الطوابع الزمنية بصيغة UTC مع Z. ومن ثم لا يثبت UTC وحده صحة إعداد المنطقة. ويوصي الملحق A.7 بإعداد متحفظ، ويشير إلى أن ضبط المشغّل أو تحققه يمكن أن يبرر إعلان أن المنطقة معروفة.

أما isSynced فيعبر عما إذا كان المصدر يعتبر نفسه متزامناً مع مصدر خارجي موثوق، مثل NTP. قراءة المستقبِل لهذا الحقل لا تستعلم عن خادم NTP ولا تتحقق من عمله. بل تنقل قيمة وضعها المصدر.

ويعبر syncAccuracy عن أقصى عدد من الميكروثواني يتوقع المصدر أن تنحرف به ساعته بين فترتي مزامنة. يجب ألا يظهر هذا الحقل عندما تكون قيمة isSynced صفراً. يستخدم مثال RFC 5424 قيمة 60,000,000 ميكروثانية، أي دقيقة واحدة، ليبين أن وقتاً مسجلاً عند 09:00 قد يقع ضمن المجال من 08:59 إلى 09:01. إنها حدود متوقعة يعلنها المصدر، لا نتيجة جهاز قياس مستقل.

توصي المواصفة بإرسال هذه القيمة فقط عندما يعرف المصدر موثوقية مصدر الوقت فعلاً. ويذكر الملحق أن هذه المعرفة تأتي عادة من إعداد المشغّل، ويحذر من إعطاء انطباع زائف بالدقة. وتحدد المواصفة أيضاً تفسيراً للمستقبِل: إذا كانت isSynced="1" موجودة وغابت syncAccuracy، فيجوز للجامع أو المرحّل افتراض أن الوقت دقيق بما يكفي لاعتباره صحيحاً. يشرح ذلك كيف يمكن للمستقبِل قراءة الرسالة؛ لكنه لا يثبت سلامة المصدر.

المحافظة على الدليل عبر سلسلة السجلات

يسجل دليل IANA لمعاملات Syslog العناصر الأربعة باعتبارها اختيارية. لذلك يجب أن تتعامل منصات الجمع مع الرسائل التي تحملها والرسائل التي لا تحملها. غيابها ليس برهاناً على خطأ الساعة، لكنه يقلل ما يستطيع المستقبِل استنتاجه من الرسالة نفسها.

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

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

الإفادة ليست تحققاً

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

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

المصادر