كيف نجعل تنبيهات المراقبة مفيدة؟ التفعيل والاستعادة والتسليم في Fleetd

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

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

تتناول المقالة الخامسة Fleetd v0.3.0. بعد نشر العميل على Linux وOpenWrt، نتابع كيف يصبح التقرير تنبيهًا، وكيف يُرسل ثم يُغلق.

ماذا يعني التنبيه؟

يفحص Fleetd انقطاع التقارير والمعالج والذاكرة ومساحة القرص وinode والخدمات الفاشلة والحاويات غير السليمة وعمر مصافحة WireGuard. أما تغير عنوان الاتصال فهو حدث منفصل لمرة واحدة.

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

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

فصل الارتفاع العابر عن الحمل المستمر

العتبة الافتراضية للمعالج والذاكرة 90%، ونافذة الاستمرار خمس دقائق:

alerts:
  offline: 40s
  cpu_percent: 90
  mem_percent: 90
  sustain: 5m
  disk_percent: 90
  inode_percent: 90
  wg_handshake: 5m

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

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

يأخذ Fleetd أقل قيمة من عينات المعالج والذاكرة الحديثة. إذا تجاوز الحد الأدنى العتبة، فقد تجاوزتها جميع العينات المستلمة. لا يستخدم المتوسط ولا يعد التجاوزات المتفرقة. القيمة المساوية لـ90% ليست أعلى من 90%.

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

تُحسب الذاكرة من الإجمالي ناقص MemAvailable مقسومًا على الإجمالي. لا تُعتبر كل ذاكرة التخزين المؤقت في Linux غير متاحة، والتنبيه لا يشخّص تسرب ذاكرة في التطبيق.

عدم الاتصال يعني توقف وصول التقارير

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

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

الجهاز الموافق عليه الذي لم يرسل أي تقرير لا يُعد حادثة انقطاع. وبعد بدء الخادم تُمنح مهلة offline + 15s، أي نحو خمس وخمسين ثانية افتراضيًا، قبل إنشاء تنبيهات انقطاع جديدة لإتاحة إعادة الاتصال.

لذلك يجب التأكد من التقرير الأول عند التسجيل. وإذا توقف خادم Fleetd نفسه فلن يقيّم أو يرسل بريدًا؛ تحتاج مراقبة نظام المراقبة إلى فحص خارجي مستقل.

فقدان الاتصال لا يعني زوال العطل السابق

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

يحافظ Fleetd على التنبيهات المفتوحة للجهاز المنقطع، ولا يفتح أو يغلق حالات أخرى اعتمادًا على بياناته القديمة. ويضيف الانقطاع عندما تسمح الشروط ومهلة بدء الخادم.

عند عودة التقارير يُستأنف التقييم. قد يُغلق الانقطاع ويبقى تنبيه القرص؛ عودة الاتصال لا تفرّغ المساحة.

للمؤشرات البطيئة مقياس زمني مختلف

تُجمع الأقراص والخدمات والحاويات وWireGuard عادةً كل ست جولات، أي نحو دقيقة. التقييم كل خمس ثوانٍ لا يحوّلها إلى بيانات جديدة كل خمس ثوانٍ.

الفحص	شرطه الحالي
مساحة القرص	تجاوز نسبة استخدام نقطة التركيب للعتبة
inode	تجاوز نسبة inode المستخدمة للعتبة
الخدمات	ورود وحدة systemd فاشلة
الحاويات	restarting أو unhealthy أو خروج غير صفري
WireGuard	تجاوز عمر مصافحة طرف سبق أن اتصل للحد

لا يستخدم القرص وinode نافذة المعالج ذات الخمس دقائق، بل آخر تقرير بطيء محفوظ. وفحص inode مستقل لأن مساحة بالبايت قد تبقى مع عدم القدرة على إنشاء ملفات جديدة.

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

يفحص WireGuard الأطراف ذات مصافحة سابقة ويتجاوز التي لم تصافح مطلقًا. يُقارن وقت تقرير العميل بوقت المصافحة، لتجنب مزج ساعة الخادم. العمر الكبير قرينة وليس اختبار اتصال كاملًا. افهم الحركة وإعداد keepalive قبل استخدامه مع الأطراف المتقطعة. يعطّل wg_handshake: 0 القاعدة على مستوى الخادم؛ لا توجد هنا استثناءات لكل طرف.

الإغلاق يعني أن القاعدة لم تعد متحققة

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

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

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

لا يميز التنفيذ كاملًا بين فحص ناجح وسليم وفحص غير متاح لكل جامع. لذلك لا يُعد السجل المغلق دليلًا مستقلًا على تعافي الخدمة الفعلية. وكما سبق، جمع الخدمات الفاشلة يعتمد على systemd، وليس فحصًا كاملًا لصحة procd في OpenWrt.

منع التكرار لا يضمن التسليم

لا ينشئ Fleetd سجلًا ورسالة فتح جديدين كل خمس ثوانٍ للمشكلة المستمرة نفسها. عند زوال الشرط ينشئ تغير استعادة، وتُجمع تغيرات الفتح والإغلاق في التقييم الواحد في رسالة واحدة.

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

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

منع التكرار يقلل الضجيج لكنه لا يعوض التسليم الموثوق أو التذكير أو تأكيد المسؤول أو التصعيد.

البريد قناة إخراج وليس السجل الوحيد

يرسل SMTP إلى المستلمين المحددين. عند غياب المضيف أو المستلمين تُكتب الإشعارات في السجل وتبقى الحالات مرئية في اللوحة. يختار language: zh الصينية لتنبيهات الخادم وبريده، بينما لغة الواجهة اختيار منفصل في المتصفح.

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

تغير عنوان اتصال موجود حدث لمرة واحدة، وليس عطلًا ينتظر عودة عنوان IP السابق؛ قد يكون مجرد تغير مخرج الشبكة.

اختبر سلسلة التنبيه كاملة

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

السيناريو	ما ينبغي ملاحظته
ارتفاع قصير للمعالج	عينة مرتفعة واحدة لا تكفي لتنبيه مستمر
بيانات اختبار مرتفعة مستمرة	فتح واحد عند تحقق التغطية دون تكرار الفتح
توقف التقارير أثناء عطل	إبقاء العطل وإضافة الانقطاع عند تحقق شروطه
عودة التقارير مع بقاء العطل	إغلاق الانقطاع وإبقاء المشكلة الأصلية
SMTP غير متاح	سجل وخطأ إرسال دون افتراض إعادة المحاولة
الجامع غير متاح	فحص أثر غياب البيانات في الإغلاق

يمكن استخدام بيانات مضبوطة في بيئة معزولة للتحقق من النوافذ والعتبات. لا حاجة لملء قسم الجذر في الإنتاج أو قطع الموجّه الذي يحمل الدخول البعيد.

تغطي الاختبارات الحالية بعض القواعد البطيئة: الأقراص والخروج الطبيعي وغير الطبيعي للحاويات وشروط WireGuard. ويوجد اختبار متكامل لتقرير ينتج تنبيه قرص. لكنها لا تثبت تغطية كل انتقالات الحالة وتسليم البريد.

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