قراءة journalctl في Linux: كيف تفرق بين تسلسل الأحداث والسبب الحقيقي للعطل؟

المشكلة ليست نقص السجلات بل طريقة تفسيرها

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

ابدأ بوصف العرض دون افتراض السبب

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

تحقق من الساعة وال ـ boot قبل البحث

قد تعرض السجلات أوقاتًا محلية بينما يستخدم نظام المراقبة UTC، وقد يؤدي اختلاف المنطقة الزمنية إلى مطابقة أحداث لا علاقة بينها. استخدم journalctl --list-boots لرؤية الإقلاعات المسجلة، ثم journalctl -b لفحص الإقلاع الحالي، أو -b -1 للإقلاع السابق إن كان محفوظًا. لا تفترض وجود كل السجلات التاريخية؛ إعدادات الاحتفاظ ومساحة القرص وطبيعة التخزين تحدد المتاح. سجّل إن كانت الساعة قد تغيرت أو جرى تصحيحها عبر NTP. إذا لم تتفق الساعات بين الخادم وقاعدة البيانات والوكيل العكسي، فوحّدها قبل بناء خط زمني سببي.

ابنِ نافذة زمنية قصيرة قابلة للتوسيع

ابدأ بأوامر مثل journalctl --since '2026-10-29 12:00:00' --until '2026-10-29 12:10:00' مع مراعاة المنطقة الزمنية التي يستخدمها النظام. نافذة قصيرة تقلل الضوضاء، لكن تضييقها أكثر من اللازم قد يخفي السبب الذي سبق العرض بدقائق. وسّع البحث تدريجيًا إلى نصف ساعة ثم ساعة إذا لم تجد مقدمات منطقية. احفظ الاستعلام نفسه في تقرير الحادثة، لا مجرد لقطة شاشة لثلاثة أسطر. عند مشاركة السجلات احذف الرموز السرية وعناوين العملاء والبيانات الحساسة دون إزالة توقيتات ضرورية لفهم التسلسل.

الفلترة بحسب الوحدة ليست كل الحقيقة

يمكن استخدام journalctl -u اسم-الخدمة.service لتجميع رسائل وحدة systemd، مع أن بعض رسائل النواة أو الوكيل العكسي أو قاعدة البيانات لن تظهر ضمن الوحدة نفسها. إذا كانت الخدمة لا تستجيب، اقرأ رسائلها ثم راجع الوحدات المجاورة ومؤشرات النظام وقت المشكلة. لا تساوِ بين «لا توجد رسالة خطأ داخل الوحدة» و«الخدمة سليمة»؛ قد تكون العملية معلقة دون كتابة سجل. وبالعكس، قد تسجل الخدمة خطأ عابرًا ثم تعالجه تلقائيًا. اربط الرسائل بحالة الخدمة الفعلية وبالمقاييس الخارجية، مثل نجاح الطلبات وزمن الاستجابة.

الأولوية severity لا تساوي شدة الحادث

يتيح journalctl -p مستويات أولوية للرسائل، لكن درجة الأولوية يحددها البرنامج أو طبقة التسجيل وقد لا تعكس الأثر الحقيقي. قد تكون رسالة warning متكررة غير مؤثرة، بينما يظهر فقد البيانات في تطبيق ضعيف التسجيل كرسالة info. ابدأ بالعرض الذي يهم المستخدم ثم استخدم مستويات الأولوية لتقليل الضوضاء، لا لإثبات السبب. عند مقارنة رسالتين، اسأل: هل سبقتا العطل؟ هل تكررتا في التشغيل السليم؟ هل تؤثران على المسار نفسه؟ وهل توجد آلية تقنية معقولة تربطهما؟ مجرد التزامن الزمني شرط مساعد، وليس برهانًا كافيًا.

استخدم معرف العملية بحذر

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

قارن بين الحوادث والظروف السليمة

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

OOM وعمليات القتل وإعادة التشغيل

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

الفرق بين الارتباط والتجربة القابلة للدحض

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

جدول أدلة يمنع القفز إلى الاستنتاج

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

احتفاظ السجلات والتدوير والخصوصية

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

مصادر موثوقة وروابط داخلية

راجع صفحة journalctl الرسمية من مشروع systemd على https://www.freedesktop.org/software/systemd/man/latest/journalctl.html وصفحة journald.co nf على https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html لفهم الحقول والاحتفاظ وحدود الفلترة. للموضوع القريب اقرأ «إدارة خدمات systemd في Linux مع سجلات واضحة» داخل إيجي تاج على /ar/articles/ إدارة-خدمات-systemd- في-linux- مع-سجلات-واضحة-topic-20261016-02 . ولضغط الذاكرة راجع «نفاد الذاكرة في خوادم Node.js» ضمن قسم السحابة والاستضافة. لا تستبدل الوثائق الخاصة بإصدار توزيعتك بصفحة عامة إذا اختلفت الخيارات أو طريقة تسجيل الخدمات. تجنب نقل أسرار السجل إلى أدوات خارجية دون مراجعة.

خطوات ختامية قابلة للتطبيق

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