مراقبة السجلات (Logs) وتحليل الأخطاء (journalctl, /var/log)

يا هلا بالشباب! اليوم بنتكلم عن موضوع مهم جداً لأي مهندس أنظمة لينكس: مراقبة السجلات (Logs) وتحليل الأخطاء. هذي مهارة أساسية عشان تعرف إيش قاعد يصير بسيرفراتك وتكتشف المشاكل قبل ما تكبر.

ليش السجلات مهمة أساساً؟

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

دليل السجلات الكلاسيكي: /var/log

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

أشهر ملفات السجلات اللي لازم تعرفها:

  • syslog أو messages: السجلات العامة للنظام، وفيها كل شيء تقريباً من رسائل النواة، الخدمات، والأجهزة.
  • auth.log (أو secure في Red Hat/CentOS): سجلات المصادقة، يعني مين حاول يسجل دخول، نجح ولا فشل، محاولات SSH، وغيرها. مهم جداً للأمان.
  • kern.log: سجلات النواة (Kernel)، تشوف فيها مشاكل الهاردوير، تعريفات الأجهزة، وأي شيء يتعلق بالنواة مباشرة.
  • dmesg: يعرض لك رسائل النواة من بداية تشغيل النظام. مفيد جداً لما يكون عندك مشاكل في الهاردوير عند الإقلاع.
  • سجلات التطبيقات: كل تطبيق أو خدمة ممكن يكون لها ملف سجل خاص فيها داخل /var/log أو في دليل فرعي (مثل /var/log/apache2/ أو /var/log/mysql/).

كيف تشوف هذي الملفات؟

بسيطة، تستخدم أوامر الطرفية المعروفة:

  • للعرض السريع: cat /var/log/syslog
  • لمتابعة آخر الأحداث (مهم جداً للمراقبة الحية): tail -f /var/log/auth.log
  • للبحث عن كلمات معينة (مثلاً كلمة "error"): grep "error" /var/log/syslog
  • لو الملف كبير وتبغى تشوفه بصفحات: less /var/log/kern.log

ملاحظة: ملفات السجلات ممكن تكبر بسرعة وتستهلك مساحة القرص. عشان كذا، فيه خدمة اسمها logrotate تقوم بتدوير السجلات (archiving) وحذف القديم منها بشكل دوري. تأكد إنها شغالة ومضبوطة عندك.

عالم الـ journalctl: سجلات Systemd

مع ظهور systemd، تغيرت طريقة إدارة السجلات بشكل كبير. الآن، معظم السجلات يتم تجميعها بواسطة خدمة journald ويمكنك الوصول إليها عبر الأمر journalctl. ميزة journalctl إنها تجمع سجلات من مصادر مختلفة (النواة، الخدمات، التطبيقات) وتخزنها بشكل منظم ومفهرس، وتوفر لك أدوات قوية للبحث والتصفية.

أوامر journalctl الأساسية:

  • عرض كل السجلات (من الأقدم للأحدث): journalctl (بيفتح لك بـ less)
  • عرض آخر السجلات فقط: journalctl -n 20 (يعرض آخر 20 سطر)
  • متابعة السجلات في الوقت الفعلي (مثل tail -f): journalctl -f
  • عرض سجلات خدمة معينة (مثلاً Apache): journalctl -u apache2.service
  • عرض سجلات خدمة معينة ومتابعتها: journalctl -u nginx.service -f
  • عرض سجلات من وقت معين: journalctl --since "2023-01-01 10:00:00"
  • عرض سجلات خلال فترة زمنية: journalctl --since "1 hour ago" --until "now"
  • تصفية حسب الأولوية (Priority):
    • 0: emerg (نظام لا يعمل)
    • 1: alert (يجب اتخاذ إجراء فوري)
    • 2: crit (حالة حرجة)
    • 3: err (خطأ)
    • 4: warning (تحذير)
    • 5: notice (حدث طبيعي ولكن مهم)
    • 6: info (معلومات عامة)
    • 7: debug (للتصحيح)

    مثال: journalctl -p err -b (يعرض الأخطاء فقط في الإقلاع الحالي)

  • عرض سجلات الإقلاع الحالي: journalctl -b
  • عرض كل الإقلاعات السابقة: journalctl --list-boots ثم journalctl -b -1 (للإقلاع السابق)

نصيحة: بشكل افتراضي، سجلات journalctl ممكن تكون غير دائمة (volatile)، يعني تنحذف بعد إعادة التشغيل. عشان تخليها دائمة، تحتاج تسوي دليل /var/log/journal وتعدل إعدادات journald. ابحث عن "journalctl persistent storage" لو احتجتها.

تحليل الأخطاء: كيف تكتشف المشكلة؟

طيب، الحين عرفت كيف تشوف السجلات. لكن كيف تستخدمها عشان تحلل المشاكل؟

خطوات عملية:

  1. حدد المشكلة: إيش اللي مو شغال؟ متى بدأ؟ هل هو تطبيق معين، خدمة، أو النظام كله؟
  2. حدد السجلات ذات الصلة:
    • لو المشكلة في المصادقة (دخول المستخدمين): auth.log أو journalctl -u ssh.service
    • لو المشكلة في الويب سيرفر: سجلات Apache/Nginx في /var/log أو journalctl -u apache2.service
    • لو المشكلة في النواة أو الهاردوير: kern.log أو dmesg أو journalctl -p err -b
    • لو المشكلة في خدمة معينة: journalctl -u اسم_الخدمة
  3. ابحث عن كلمات مفتاحية:
    • error
    • failed
    • warning
    • permission denied
    • fatal
    • اسم التطبيق أو الخدمة اللي فيها المشكلة.

    استخدم grep مع /var/log أو تصفية journalctl.

    grep -i "error|failed" /var/log/syslog
journalctl -u myapp.service -p err --since "yesterday"
  4. قارن الأحداث: هل فيه أحداث ثانية صارت بنفس الوقت اللي بدأت فيه المشكلة؟ ممكن يكون فيه خدمة ثانية تعتمد عليها فشلت، أو تحديث تسبب في المشكلة.
  5. تتبع التسلسل الزمني: سجلات journalctl ممتازة لهذي النقطة لأنها تعرض الأحداث بترتيب زمني دقيق.

تذكر، تحليل السجلات مهارة تتطور مع الممارسة. كل ما تعاملت مع مشاكل أكثر، كل ما صرت أسرع في تحديد موقع المشكلة وحلها. بالتوفيق يا مهندسين!