دليل مبسط لفهم سجلات النظام Syslogs في لينكس

توكلت العملية syslog إدارة السجلات لفترة طويلة من الزمن، بحيث كانت تُجمّع رسائل السجلات المُرسلة من قبل إجرائيات النظام والتطبيقات إلى الجهاز الزائف ‎/dev/log، ثم تعيد توجيهها إلى ملفات السجل النصية المناسبة ضمن المجلد /var/log/‏‏، ويستدل syslogd على الملف الوجهة للسجلات من خلال البيانات الوصفية ضمن ترويسات الرسائل القادمة نفسها، والتي تتضمن معلومات إضافية أيضًا كالعلامة الزمنية للرسالة ومصدرها وأولويتها.

ومع أن أغلب السجلات كانت تُعالج باستخدام systemd، لكن مؤخرًا أصبح المدير الرئيسي لها هو journald، والذي يتم التحكم به عن طريق الأمر الخاص journalctl، ولكنه لم يستبدل سجلات syslogd كليًا ولازال بالإمكان رؤية ملفات السجلات تلك ضمن المجلد /var/log/، وسنركز في هذا المقال فقط على systemd.

حفظ السجلات باستخدام syslogd

تضاف كل السجلات المُولّدة من قبل الأحداث في نظام syslogd إلى الملف ‎/var/log/syslog، وقد تُرسل أيضًا إلى ملف واحد أو عدة ملفات ضمن نفس المجلد بحسب خصائصها، حيث يعتمد نظام syslogd على محتوى ملف الإعدادات ‎50-default.conf الموجود ضمن المجلد /etc/rsyslog.d/ لتحديد طريقة توزيع تلك الرسائل.

يوضح المثال التالي محتوى ملف الإعداد ‎50-default.conf حيث ستُكتب رسائل السجل المتعلقة بالأعمال المجدولة cron ضمن الملف cron.log، وتخبر علامة النجمة ("*") نظام syslogd بأن يرسل كل السجلات بمختلف مستويات أولويتها إلى الملف المذكور، وذلك على عكس تحديد مستوى معين للرسائل الواجب إرسالها، كتحديد مستوى رسائل الخطأ err أو مستوى حالات انهيار النظام emerg:

cron.*     /var/log/cron.log

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

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

إدارة ملفات السجل بواسطة syslogd

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

ولتوضيح كيف يتم تدوير سجلات النظام يمكننا عرض بعض الملفات ضمن المجلد /var/log/، حيث سنلاحظ وجود ملف السجل auth.log الخاص بعمليات الاستيثاق على سبيل المثال بثلاث صيغ مختلفة وهي:

• auth.log وهي نسخة ملف السجلات الفعال حالًيا الذي تُكتب ضمنه رسائل الاستيثاق الجديدة.
• auth.log.1 آخر ملف تم تدويره وأصبح خارج الخدمة، ويبقى دون ضغط لتسهيل عملية استخدامه عند الضرورة.
• auth.log.2.gz مجموعة سجلات قديمة، ومضغوطة لتوفير المساحة كما يُلاحظ من الامتداد ‎.gz في نهاية اسم الملف.

عند قدوم موعد تدوير السجلات بعد 7 أيام، ستنفذ الخطوات التالية:

1. يُعاد تسمية الملف auth.log.2.gz ليصبح auth.log.3.gz
2. يُضغط الملف auth.log.1 ويعاد تسميته ليصبح auth.log.2.gz
3. يُعاد تسمية الملف الفعال الحالي auth.log ليصبح auth.log.1
4. يُنشئ ملف جديد لاستقبال السجلات الجديدة بالاسم auth.log.

يمكن التحكم بمدة التدوير الافتراضية للسجلات من خلال ملف الإعداد ‎/etc/logrotate.conf، يوضح المحتوى التالي للملف ضبط عملية التدوير لتكون أسبوعية، وحذف السجلات التي يمضي عليها مدة أربعة أسابيع:

# تدوير السجلات أسبوعيًا
weekly
# إبقاء سجلات آخر 4 أسابيع
rotate 4
# إنشاء ملف سجلات فارغ جديد بعد تدوير السجلات القديمة
create
# تضع الحزم معلومات تدوير السجلات ضمن المجلد التالي
include /etc/logrotate.

يحوي المجلد /etc/logrotate.d/ أيضًا على ملفات إعدادات مخصصة لإدارة عملية تدوير السجلات لخدمات وتطبيقات معينة، وبتنفيذ أمر عرض محتويات ذلك المجلد سنجد الملفات التالية:

$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgrade

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

قراءة ملفات سجلات syslog

البحث يدويًا ضمن ملفات سجلات غير مجدي، فقد تحوي تلك الملفات على الملايين من الأسطر، لذا يجب تجنب الاستعانة بالأمر cat نهائيًا، فهو سيطبع فقط الآلاف من تلك الأسطر على الشاشة ولن نتمكن من قراءتها، يمكن الاستعانة بالأمر grep بدلًا منه لتصفية النص ضمن تلك الملفات، ويمكن الاستفادة من الأمر tail -f لمعاينة الأسطر الأخيرة من الملف مع تغييراتها بالوقت الحقيقي، وبدمجه مع الأمر grep يمكن تصفية الأحداث التي تهمنا منها فقط.

نضطر أحيانًا لمعاينة محتوى ملفات السجل القديمة المضغوطة، يمكن فك ضغط تلك الملفات واستخدام الأمر grepمع less أو أوامر أخرى مشابهة له للوصول للسجلات المطلوبة، لكن الطريقة الأفضل تكون باستخدام بعض الأوامر التي تبدأ بالحرف z كالأمر zcat و zless وغيرها، بحيث تسمح لنا تلك الأوامر بالتعامل مع الملفات المضغوطة مباشرةً دون الحاجة لفك ضغطها أولًا.

مثال عملي على تحليل السجلات

كمثال يمكننا البحث عن محاولات تسجيل الدخول الفاشلة ضمن ملف السجلات الخاص بعمليات الاستيثاق auth.log، فنبحث ضمنه عن الكلمة "failure" ليظهر لنا الأسطر التي تحتوي على جملة فشل الاستيثاق "authentication failure"، نستفيد من تلك العملية للتحقق من محاولات اختراق لحسابات عبر المحاولات المتكررة الفاشلة لتخمين كلمة السر لها، بحيث يدل تكرار المحاولات على وجود محاولة للاختراق، مع تجاهل المحاولات الفاشلة القليلة التي تظهر كمرة واحدة أو مرتين التي قد تحدث مع مستخدم حقيقي عند نسيانه لكلمة السر:

$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failure

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

logger "Authentication failure"

طريقة أخرى تكون بتوليد سجلات حقيقية عبر محاولة تسجيل الدخول بكلمة سر خاطئة عمدًا، لكن المعلومات التي استخرجناها تدل فقط على حدوث عملية تسجيل دخول فاشلة، ولا تخبرنا بأي معلومات مفيدة أخرى عن سياق ذلك الحدث، كالحساب الذي جرت عليه محاولة تسجيل الدخول الفاشلة، لكن يمكننا توسيع النتائج التي يٌظهرها الأمر grep لتشمل بعض الأسطر قبل وبعد سطر النتيجة، المثال التالي يطبع لنا نتائج البحث إضافةً إلى الأسطر حولها، نلاحظ ظهور معلومات مفيدة، كاسم الحساب david وهو الذي نفذ محاولة تسجيل دخول فاشل باستخدام الأمر su إلى الحساب ‎:studio

$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by david

ختامًا

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

ترجمة -وبتصرف- للمقال Beginner's Guide to Syslogs in Linux لفئة من المؤلفين.

اقرأ أيضًا

• أهم 20 أمرا في نظام التشغيل لينكس لجميع المستخدمين
• مرجع إلى أشهر أوامر لينكس
• كيف تستعرض وتدير سجلات لينكس على أوبنتو وCentOS