البحث في الموقع

شهدت السنوات الأخيرة انتقال توزيعات لينِكس على نحو متزايد من أنظمة init الأخرى إلى systemd، تُوفِّر مجموعة أدوات systemd نموذج init مرن وسريع لإدارة الجهاز بشكل كامل من الإقلاع boot فصاعدًا. سنقوم في هذا الدرس بالمرور بشكل سريع على أهم الأوامر التي نحتاج معرفتها لإدارة خادوم يحتوي على systemd، ينبغي أن يعمل هذا على أي خادوم يُطبِّق systemd (أي إصدار نظام تشغيل يساوي أو أعلى من Ubuntu 15.04, Debian 8, CentOS 7, Fedora 15). فلنبدأ الآن. إدارة الوحدة بشكل أساسي Basic Unit Management الشيء الأساسي الذي يديره systemd ويعمل عليه هو الوحدة “unit”، يُمكن أن تكون الوحدات من عدّة أنواع، ولكن النّوع الأشيع هو الخدمة service (يتبيّن ذلك من ملف الوحدة الذي ينتهي بـ .service)، ولإدارة الخدمات على خادوم يحتوي systemd فإنّ أداتنا الرئيسيّة هي الأمر systemctl. تمتلك جميع أوامر نظام init الاعتياديّة إجراءات مُكافِئة مع الأمر systemctl، سنستخدم الوحدة nginx.service للتوضيح (يجب علينا تثبيت Nginx باستخدام مُدير الحِزَم للحصول على ملف الخدمة هذا). نستطيع على سبيل المثال تشغيل الخدمة بكتابة ما يلي: sudo systemctl start nginx.service نستطيع إيقافها مرّة أخرى بكتابة: sudo systemctl stop nginx.service ولإعادة تشغيل الخدمة نكتب: sudo systemctl restart nginx.service ولمحاولة إعادة تحميل reload الخدمة بدون مقاطعة الوظيفة الطبيعيّة نكتب ما يلي: sudo systemctl reload nginx.service تمكين أو تعطيل الوحدات لا يتم بشكل افتراضي تشغيل معظم ملفّات وحدات systemd تلقائيًّا عند الإقلاع، ولإعداد هذه الوظيفة نحتاج لتمكين “enable” الوحدة، والذي يقوم بتعليقها بخطافة hook إلى هدف “target” إقلاع مُعيَّن ممّا يُسبِّب تحفيز تشغيلها عند بدء تشغيل الهدف. لتمكين خدمة من البدء تلقائيًّا عند الإقلاع نكتب: sudo systemctl enable nginx.service إن كُنّا نرغب بتعطيل الخدمة مرّة أخرى نكتب: sudo systemctl disable nginx.service الحصول على لمحة عامة عن حالة النظام هناك قدر كبير من المعلومات التي يمكننا استخلاصها من خادوم systemd للحصول على لمحة عامّة عن حالة النّظام. على سبيل المثال للحصول على كافّة ملفّات الوحدات التي يعرضها systemd على أنّها نشطة “active” نكتب ما يلي (نستطيع فعليًّا ألّا نكتب list-units لأنّه سلوك systemctl الافتراضي): systemctl list-units ولعرض جميع الوحدات التي قام systemd بتحميلها أو حاول تحميلها إلى الذّاكرة بما في ذلك الخدمات غير النشطة حاليًّا نُضيف المحوِّل switch الذي يُدعى all--: systemctl list-units --all لعرض جميع الوحدات المُثبَّتة على النّظام بما في ذلك الوحدات التي لم يحاول systemd أن يُحمّلها إلى الذاكرة نكتب: systemctl list-unit-files عرض معلومات السجل Log الأساسية يجمع ويدير المُكوِّن في systemd الذي يُدعى journald المُدخلات اليوميّة journal entries من كافّة أجزاء النّظام. وهي بالأساس معلومات السّجلات من التطبيقات والنواة kernel. ولمشاهدة جميع مُدخلات السّجلات بدءًا من المُدخَل الأقدم نكتب: journalctl سيظهر لنا هذا افتراضيًّا المُدخلات من الإقلاعات السّابقة والحاليّة إن تمّ إعداد journald ليحفظ سجلّات records الإقلاع السّابق، تُمكِّن بعض التوزيعات هذا الأمر افتراضيًّا بينما لا تقوم توزيعات أخرى بتمكينه (ولتمكينه إمّا نُحرِّر الملف etc/systemd/journald.conf/ ونُعيِّن الخيار Storage= إلى مستمر "persistent" أو نُنشِئ الدّليل persistent بكتابة sudo mkdir -p /var/log/journal). إن كُنّا نرغب برؤية المُدخلات اليوميّة فقط من الإقلاع الحالي نُضيف العَلَم b-: journalctl -b ولمشاهدة رسائل النواة فقط، مثل تلك التي تكون ممثلة عادةً بواسطة dmesg، نستطيع استخدام العَلَم k-: journalctl -k مرةً أخرى، نستطيع تحديد الأمر السّابق ليكون فقط للإقلاع الحالي بإضافة العَلَم b-: journalctl -k -b الاستعلام عن سجلات وحالات الوحدة بينما تُمكّننا الأوامر السّابقة من الوصول إلى الحالة العامّة للنظام، فنستطيع أيضًا الحصول على معلومات حول حالة الوحدات بشكلٍ فردي. يُستخدم الخيار status مع الأمر systemctl للحصول على لمحة عامّة عن الحالة الحاليّة للوحدة، يُظهر لنا هذا الأمر إذا ما كانت الوحدة نشطة، معلومات حول العمليّة process، وآخر المُدخلات اليوميّة: systemctl status nginx.service لمشاهدة كافّة المُدخلات اليوميّة للوحدة التي نسأل عنها نضيف الخيار –u مع اسم الوحدة إلى الأمر journalctl: journalctl -u nginx.service ونستطيع كالعادة تحديد المُدخلات للإقلاع الحالي فقط بإضافة العَلَم b-: journalctl -b -u nginx.service فحص الوحدات وملفات الوحدات نعرف حتى الآن كيفيّة تعديل حالة وحدة ما بواسطة تشغيلها أو إيقافها، ونعلم كيف نشاهد معلومات اليوميّات journal والحالة لأخذ فكرة عمّا يحدث مع العمليّة، ومع ذلك لم نتعلّم كيفيّة فحص inspect جوانب أخرى للوحدات وملفّات الوحدات. يحتوي ملف الوحدة المُعامِلات parameters التي يستخدمها systemd لإدارة وتشغيل الوحدة، ولمشاهدة المحتويات الكاملة لملف الوحدة نكتب: systemctl cat nginx.service ولرؤية شجرة الاعتماديّات dependency tree لوحدة ما (والتي تحاول وحدات systemd تفعيلها عند بدء تشغيل الوحدة) نكتب: systemctl list-dependencies nginx.service يُظهر لنا هذا الأمر الوحدات المعتمدة مع توسيع expand الوحدات الهدف target بشكل تكراري recursively، ولتوسيع كافّة الوحدات المعتمدة بشكل تكراري نُمرِّر العَلَم all--: systemctl list-dependencies --all nginx.service وأخيرًا نستخدم الخيار show لمشاهدة التفاصيل ذات المستوى المُنخفض low-level لإعدادات الوحدة على النّظام: systemctl show nginx.service يُعطينا هذا الأمر قيمة كل مُعامِل تتم إدارته بواسطة systemd. تعديل ملفات الوحدة إن كُنّا نحتاج للقيام بتعديلات على ملف الوحدة فيسمح لنا systemd بالقيام بالتغييرات من خلال الأمر systemctl بنفسه بدون أن نضطر للذهاب إلى موقع الملف الفعلي على القرص. لإضافة مقطع snippet لملف الوحدة، والذي يُمكن استخدامه لإلحاق append أو تجاوز override إعدادات في ملف الوحدة الافتراضي، نستدعي ببساطة الخيار edit على الوحدة: sudo systemctl edit nginx.service وإن كُنّا نرغب بتعديل كامل محتوى ملف الوحدة بدلًا من إنشاء مقطع، نُمرَّر العَلَم --full: sudo systemctl edit --full nginx.service يجب بعد الانتهاء من تعديل ملف الوحدة إعادة تحميل العمليّة systemd نفسها لكي تلتقط تغييراتنا: sudo systemctl daemon-reload استخدام الأهداف targets (مستويات التشغيل Runlevels) ومن الوظائف الأخرى لنظام init نقل الخادوم نفسه بين حالات مختلفة، تُشير أنظمة init التقليديّة لهذا الأمر باسم مستويات التشغيل "runlevels" ممّا يسمح للنظام بأن يكون في مستوى تشغيل runlevel واحد فقط بنفس الوقت. يتم في systemd استخدام الأهداف targets بدلًا من ذلك، والتي هي بشكل أساسي نقاط تزامن يستطيع الخادوم استخدامها لنقل نفسه إلى حالة مُحدّدة، يُمكن أن يتم ربط الخدمة وملفّات الوحدة الأخرى إلى هدف، ويُمكن للأهداف المتعددة أن تكون نشطة في الوقت نفسه. ولرؤية كل الأهداف المتاحة على نظامنا نكتب: systemctl list-unit-files --type=target لمشاهدة الهدف الافتراضي الذي يحاول systemd الوصول إليه عند الإقلاع (والذي بدوره يقوم بتشغيل كافّة ملفّات الوحدة التي تُشكّل شجرة الاعتماديّات لهذا الهدف) نكتب: systemctl get-default نستطيع تغيير الهدف الافتراضي الذي سيتم استخدامه عند الإقلاع باستخدام الخيار set-default: sudo systemctl set-default multi-user.target نكتب ما يلي لكي نرى ما هي الوحدات المرتبطة بالهدف: systemctl list-dependencies multi-user.target يمكننا تعديل حالة النظام للانتقال بين الأهداف عن طريق الخيار isolate، سيقوم هذا بإيقاف تشغيل أيّة وحدات غير مرتبطة بالهدف المحدّد، ويجب أن نكون متأكدين من أنّ الهدف الذي نقوم بعزله isolate لا يوقف تشغيل أيّة خدمات أساسيّة: sudo systemctl isolate multi-user.target إيقاف تشغيل أو إعادة تشغيل الخادوم هنالك بعض الاختصارات المتاحة لبعض الحالات الرئيسيّة التي يستطيع النّظام الانتقال إليها، على سبيل المثال لإيقاف تشغيل خادومنا نكتب: sudo systemctl poweroff إن كُنّا بدلًا من ذلك نريد إعادة تشغيل النظام فبإمكاننا فعل ذلك بكتابة: sudo systemctl reboot نستطيع الإقلاع في وضع الإنقاذ rescue mode بكتابة: sudo systemctl rescue لاحظ أنّ معظم أنظمة التشغيل تقوم بتضمين كنيات aliases تقليديّة لهذه العمليّات بحيث أنّنا نستطيع ببساطة كتابة: sudo poweroff أو sudo reboot بدون systemctl، ومع ذلك ليس من المضمون أن يكون هذا مُعدًّا على كل الأنظمة. الخطوات التالية ينبغي أن نكون الآن قد تعلّمنا أساسيّات إدارة خادوم يستخدم systemd، ومع ذلك هناك المزيد لتعلمّه مع توسّع احتياجاتنا، توجد أدناه روابط دروس تحتوي معلومات أكثر تفصيلًا حول بعض المُكوّنات التي ناقشناها في هذا الدّرس: كيفيّة استخدام Systemctl لإدارة خدمات ووحدات Systemd. كيفيّة استخدام Journalctl لعرض سجلّات Systemd والتعامل معها. فهم وحدات وملفّات وحدات Systemd. نستطيع من خلال تعلّم كيفيّة الاستفادة من قوّة نظام init لدينا أن نتحكّم بحالة أجهزتنا وإدارة خدماتنا وعمليّاتنا بشكل أسهل. ترجمة -وبتصرّف- لـ Systemd Essentials: Working with Services, Units, and the Journal لصاحبه Justin Ellingwood.

يتوقف ووردبريس عن العمل في بعض الأحيان، فعند زيارة موقعك ستجد صفحة بيضاء فارغة والتي يشار إليها بـ "شاشة الموت البيضاء" ("white screen of death"). سيكون هذا الأمر محبطا للغاية وسيتسبب لك بمشاكل خاصةََ وأنك لا ترى أية أخطاء PHP تخبرك سبب المشكلة. يمكنك تخمين سبب المشكلة، لكن سيتطلب هذا وقتا طويلا، ولحسن الحظ، توجد خطوات يمكنك اتباعها لاكتشاف المشكلة بسرعة. في هذا الدرس، سنلقي نظرة على عملية اكتشاف أخطاء الشاشة البيضاء، والتي قد تتضمن بعضا من البرمجة أو استخدام الملحقات، وباتباع هذه الملاحظات، سيعود موقعك للعمل في وقت قصير للغاية. اكتشاف الأخطاء وإصلاحها عن طريق البرمجة إن ملف wp-config.php الموجود في مجلد الجذر لووردبريس هو مفتاح اكتشاف الخطأ في موقعك. كل ما تحتاجه هو إضافة بضعة أسطر برمجية لتشغيل وضع التنقيح (debugging) في موقعك. إن تشغيل وضع التنقيح سيعرض لك قائمة الأخطاء الحالية، إذا كان موقعك مثبّتًا محليا، ستحتاج إلى إضافة هذا السطر إلى ملف wp-config.php: define( 'WP_DEBUG', true ); ضعه فوق السطر التالي: /* That's all, stop editing! Happy blogging. */ إذا وجدت شيفرة WP_DEBUG موجودة في ملف wp-config.php، فقم ببساطة بجعلها true بدون علامات الاقتباس. إذا كنت على موقع حي (على الإنترنت)، لا تستخدم هذه الشيفرة البرمجية لأن جميع الأخطاء ستظهر في الصفحة الرئيسية لموقعك بالإضافة إلى مسار ملفاتك وجميع البيانات الأخرى الحساسة. وبدلا من ذلك توجد طريقة أخرى لتفعيل التنقيح على المواقع المباشرة والحد من رسائل الخطأ إلى ملف سجل خاص فقط. لتفعيل سجل الخطأ والتنقيح للمواقع الحية، أدخل الشيفرة البرمجية التالية إلى ملف wp-config.php فوق سطر Happy blogging: // Enable WP_DEBUG mode define('WP_DEBUG', true); // Enable Debug logging to the /wp-content/debug.log file define('WP_DEBUG_LOG', true); // Disable display of errors and warnings define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors',0); // Use dev versions of core JS and CSS files (only needed if you are modifying these core files) define('SCRIPT_DEBUG', true); إذا عدّلت أية ملفات جافاسكربت أو CSS قبل أن يعرض موقعك شاشة الموت البيضاء، فضمّن السطر الأخير في المثال أعلاه، أما إذا لم تقم بأية تعديلات من هذا النوع، فيمكنك ترك هذا السطر. لا تنس أنه إذا وجدت هذه الشيفرات البرمجية موجودة بالفعل، فقم ببساطة بتبديل القيم المنطقية (true/false) كما في المثال أعلاه. بمجرد أن تنتهي من ذلك، يمكنك التأكد من رسائل الخطأ في الواجهة الأمامية (front end) لموقعك للتثبيتات المحلية و في سجل الأخطاء في التثبيتات الحية والذي ستجده في wp-content/debug.log/ بين ملفات ووردبريس الخاصة بك. عندما تتحقق وتجد الخطأ، يمكنك البدء في إصلاحه. استكشاف الأخطاء وإصلاحها باستخدام ملحق توجد العديد من الملحقات التي يمكنها مساعدتك في اكتشاف وإصلاح أخطاء موقعك، فإذا كنت لا تزال تستطيع الوصول إلى لوحة التحكم الخاصة بإدارة الموقع، فيمكنك تثبيت ملحق لمساعدتك في معرفة الأخطاء. لتشغيل وضع التنقيح فقط، يمكنك استخدام ملحق Debug، أما لو أردت المزيد من الخيارات لاكتشاف وإصلاح الأخطاء فيمكنك استخدام ملحق Debug Bar. بالنسبة للنسخة مُتعدّدة المواقع من ووردبريس (Multisite installs)، يوجد ملحق مخصص للشبكات والمدراء الكبار للأنظمة لاكتشاف وإصلاح الأخطاء ويسمى بـ Debug This، ويحتوي هذا الملحق على تفاصيل أكثر من أي ملحقات تنقيح أخرى. هذه الملحقات الثلاثة موثوق بها ويتم تحديثها باستمرار لضمان الجودة والاستقرار، بمجرد اختيار واحدة، ثبّتها وابدأ في البحث عن الأخطاء التي تحتاج إلى إصلاح. التحقق من سجل الأخطاء في لوحة التحكم إذا كنت تستخدم cPanel، يمكنك التأكد من سجل الأخطاء بالنقر على زر Error Log الموجود في قسم Logs. إذا كنت تستخدم Plesk، فانقر على علامة تبويب Files الموجودة في أعلى الصفحة، ثم اختر السجلات في القائمة الموجودة على يسار الصفحة، ثم اختر error_log من القائمة. إذا كنت تستخدم نوعًا آخر من لوحات التحكم ولم تعرف كيف تصل إلى سجل الأخطاء، فتحقق من شركة الاستضافة أو ابحث في جوجل على الإجابة. نصائح أخرى مفيدة توجد أشياء أخرى يمكنها مساعدتك على تصحيح الوضع ومعرفة سبب المشكلة. عد إلى قالب Twenty Fifteen الافتراضي، فإذا اختفت الشاشة البيضاء وظهر موقعك فهذا معناه أن القالب الذي تستخدمه يحتوي على علل (bugs) أو أنه يتعارض مع واحدة من الملحقات التي تستخدمها. عطّل جميع الملحقات، فإذا عاد موقعك للعمل فابدأ بتفعيل الملحقات كلّ على حدة حتى تظهر الشاشة البيضاء، ففي تلك الحالة ستعرف أن الملحق الأخير يحتوي على علل. هل تستخدم ملحق للتخزين المؤقت؟ يمكنك تنظيف التخزين المؤقت لموقعك بشكل يدوي عن طريق الإعدادات، فووردبريس لا يأتي مع تخزين مؤقت بشكل افتراضي. تحقق من حد عرض الحزمة (bandwidth)، هل قمت بتجاوزه؟ فهذا قد يسبب خطأ الشاشة البيضاء، وإذا كان هذا هو السبب فيجب عليك التواصل مع موفّر الاستضافة. الخاتمة يعتبر خطأ الشاشة البيضاء من الأخطاء الصعبة خاصة عندما لا تواجه رسائل خطأ واضحة على الفور، لكن لحسن الحظ، هذه النصائح يمكنها مساعدتك على معرفة ذلك. هل واجهت شاشة الموت البيضاء سابقا؟ لا تتردد في إخبارنا عن تجربتك وتَعلّم من تجارب الآخرين في التعليقات في الأسفل. ترجمة -وبتصرف- للمقال: Troubleshooting White Screen of Death Errors in WordPress لصاحبه Jenni McKinnon.

إنّ السجلّات logs أمر ضروري لحل مشاكل تثبيت Redis، وقد تتساءل عن مكان تواجد هذه السجلّات أو عن المكان الذي يقوم Redis بتخزين السجلّات فيه على نظام Ubuntu. عند تثبيت Redis بالطريقة الافتراضية باستخدام apt-get على Ubuntu 14.04 فسيقوم Redis بإنشاء سجلّاته في المسار var/log/redis/redis-server.log/. لاستعراض آخر 10 أسطر في سجلّات redis، نقوم بتنفيذ الأمر التالي: $ sudo tail /var/log/redis/redis-server.log لاحظ في الأمر السابق استخدامنا لـ sudo نظرًا لأننا نحتاج لصلاحيات أعلى لنتمكن من قراءة سجلّات redis. أما في حال تثبيت Redis من ملفّات الشيفرة المصدرية على Ubuntu 14.04، فسيقوم بتخزين السجلّات في المسار var/log/redis_6379.log/. ولاستعراض آخر 10 أسطر نستخدم الأمر: $ sudo tail /var/log/redis_6379.log التحقق من السجلات المؤرشفة يقوم Redis بأرشفة ملفّات السجلّات القديمة، ولاستعراض قائمة الملفّات المتوفرة ننفذ الأمر: $ ls /var/log/redis فسيظهر الخرج بما يشبه التالي: redis-server.log redis-server.log.1.gz ولاستعراض آخر 10 أسطر من سجل مؤرشف نحتاج أولًا أن نقوم بفك ضغطه، ونستخدم gunzip لفك ضغط الملفات من نوع gz، كما في الأمر التالي: $ sudo gunzip /var/log/redis/redis-server.log.1.gz انتبه: يقوم gunzip بفك ضغط ملفات gz وحذف الملف الأساسي المضغوط، لذا إن كنت تريد المحافظة على الأرشيف المضغوط توفيرًا للمساحة واستعراض محتويات الملف المضغوط بشكل مؤقت فقم بنسخه إلى المسار المؤقت tmp/ وقم بفك ضغطه هناك. ومن ثم ننفذ الأمر tail مع الملف الذي نحصل عليه: $ sudo tail /var/log/redis/redis-server.log.1 البحث عن ملفات السجلات باستخدام أمر find إن لم تكن ملفّات السجلّات في المسارات المذكورة السابقة، فمن الممكن تنفيذ عملية بحث واسعة باستخدام الأمر find في المسار var/logs/ على الشكل التالي: $ find /var/log/* -name *redis* أو البحث في كامل النظام. قد تأخذ عملية البحث بهذا الشكل بعض الوقت إن كنت تملك الكثير من الملفّات، وقد تظهر لك بعض التحذيرات حول عدم كفاية الصلاحيات للبحث في بعض المسارات، وهذا أمر طبيعي، بالرغم من أنّنا نتجنب أسوأ مسارين للبحث فيهما وهما proc/ و sys/ باستعمال المعامل prune-. سيظهر تنفيذ الأمر التالي جميع الملفّات التي تحوي على كلمة redis في اسمه، بما في ذلك ملفات التثبيت: $ find / -path /sys -prune -o -path /proc -prune -o -name *redis* تحديد مسار تخزين السجلات في ملف إعدادات Redis نستطيع تغيير مسار تخزين ملفات السجلّات وذلك بتغيير المسار في ملف الإعدادات redis.conf، ويتواجد الملف غالبًا في المسار etc/redis/redis.conf/ نقوم بفتح الملف بمحرر نصوص مثل nano أو أي محرر آخر تفضّله: $ sudo nano /etc/redis/redis.conf ونبحث عن السطر الذي يبدأ بـ logfile ونقوم بتغيير المسار الذي يظهر فيه إلى المسار الجديد، كما بالإمكان تغيير اسم ملف السجل الأساسي: logfile /var/log/redis/redis-server.log التحقق من سجلات systemd باستخدام journalctl في Ubuntu 15.04 والإصدارات الأحدث منه قد نحتاج أن نتحقق من سجلّات Redis التي يقوم بالتقاطها سجل النظام systemd (يستخدم نظام Ubuntu 15.04 والأحدث منه سجل النظام systemd، بينما يستخدم Ubuntu 14.04 سجّلات Upstart بشكل افتراضي). الخلاصة لتتعلّم المزيد حول إعدادات Redis، يرجى قراءة هذا المقال حول إعداد عنقود Redis cluster. ترجمة -وبتصرّف- للمقال How To Find Redis Logs on Ubuntu لصاحبته Sharon Campbell.

يتناول هذا المقال كيفية تثبيت الإصدار 1.3 من برنامج Graylog (يُشار إليه أحيانا بـ Graylog2) وإعداده لتجميع سجلات نظام التشغيل Syslog في موضِع مركزي. Graylog هو أداة فعّالة لإدارة السجلات وتحليلها تُستخدم في حالات كثيرة من مراقبة Monitoring الدخول عبر SSH والأنشطة غير المعتادة إلى تنقيح Debugging التطبيقات. تعتمد الأداة على Elasticsearch، جافا وقاعدة بيانات MongoDB. يمكن استخدام Graylog لتجميع أنواع مختلفة من السجلات ومراقبتها، إلا أننا سنقتصر في هذا الدرس على تجميع سجلات النظام. مكونات Graylog توجد أربعة عناصر أساسية في Graylog: عُقد خادوم Graylog: تشتغل عاملا لاستقبال الرسائل ومعالجتها، كما أنها تتواصل مع بقية العناصر (غير عقد الخادوم). يعتمد أداء هذه العقد على قدرات معالج Processor الخادوم المضيف. عُقد Elasticsearch: تخزّن الرسائل والسجلات. يعتمد أداءها على الذاكرة الحية RAM وقدرة الأقراص على الإدخال/الإخراج. قاعدة بيانات MongoDB: تخزّن البيانات الوصفية Metadata؛ لا تُستحث كثيرا. واجهة المستخدم (صفحات ويب). إعداد Graylog القاعدي سننفذ في هذا الدرس إعدادا قاعديا لـGraylog توجد جميع العناصر فيه على نفس الخادوم. يُستحسن في بيئات الإنتاج الكبيرة أن يُضبط كل مكوِّن على خادوم منفصل لتحسين الأداء. المتطلبات ستحتاج من أجل تنفيذ الخطوات المشروحة في هذا الدرس إلى حساب إداري على خادوم أوبنتو 14.04 ذي ذاكرة عشوائية لا تقلّ عن 2GB. طريقة إعداد الحساب مشروحة في درس الإعداد الابتدائي لخادوم أوبنتو 14.04. إن كانت ذاكرة الوصول العشوائي لديك أقل من 2GB فلن تستطيع تشغيل جميع مكونات Graylog. نبدأ بتثبيت MongoDB. تثبيت MongoDB تثبيت MongoDB سهل وسريع. نفّذ الأمر التالي لاستيراد مفتاح GPG الخاص بـ MongoDB إلى apt: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 ثم أنشئ قائمة مصادر MongoDB بتنفيذ الأمر: echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list حدّث أرشيف الحزم: sudo apt-get update ثم نثبّت الإصدار المستقر Stable من MongoDB بتنفيذ الأمر: sudo apt-get install mongodb-org يجب أن تكون قاعدة بيانات MongoDB الآن جاهزة وتعمل على الخادوم. يمكنك التأكد من ذلك بتنفيذ الأمر: sudo service mongod status لتشغيل قاعدة البيانات (إن لم تشتغل لسبب ما): sudo service mongod start تثبيت Java يحتاج Elasticsearch لجافا حتى يعمل، لذا سنثبته. ينصح Elasticsearch بتثبيت Oracle Java 8، وهو ما سنفعله (على الرغم من ذلك، إلا أن Elasticsearch ينبغي أن يعمل دون مشاكل مع OpenJDK). أضف مستودع PPA الخاص بـ ـOracle Java إلى apt: sudo add-apt-repository ppa:webupd8team/java ثم حدّث قاعدة بيانات الحزم: sudo apt-get update نفذ أمر تثبيت Oracle Java 8 التالي (واقبل شروط الرخصة في النافذة المنبثقة): sudo apt-get install oracle-java8-installer بعد اكتمال تثبيت جافا يأتي دور Elasticsearch. تثبيت Elasticsearch نحتاج لإصدار من Elasticsearch سابق للإصدار 2.0 ليعمل معه Graylog، لذا سنثبّت الإصدار 1.7 من Elasticsearch. نستورد مفتاح GPG العمومي الخاص بـ ـElasticsearch إلى apt كما يلي: wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - قد تحتاج لإدخال كلمة السر الخاصة بالمستخدم الجذر. ثم أنشئ قائمة مورد لـ Elasticsearch: echo "deb http://packages.elastic.co/elasticsearch/1.7/debian stable main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.7.x.list نحدّث بيانات الحزم: sudo apt-get update ثم نثبت Elasticsearch: sudo apt-get -y install elasticsearch الخطوة الموالية هي إعداد Elasticsearch؛ افتح ملف التعديل: sudo vi /etc/elasticsearch/elasticsearch.yml ابحث عن فقرة cluster.name ثم انزع عنها علامة التعليق # وأبدل القيمة المبدئية بـ graylog-development (الاسم الذي اخترناه للعنقود Cluster. لا يمكن أن يكون لعنقودين في نفس الشبكة نفس الاسم): cluster.name: graylog-development يستعمل Elasticsearch المنفذ Port رقم 9200. سنمنع المتصلين من خارج الشبكة المحلية من الوصول إليه. اعثر على السطر الذي يحدّد المضيف على الشبكة network.host، أزل علامة التعليق وضع مكانها localhost (المضيف المحلي) كالتالي: network.host: localhost احفظ ملف elasticsearch.yml ثم أغلقه. أعد تشغيل Elasticsearch: sudo service elasticsearch restart نفذ الأمر التالي لتشغيل Elasticsearch مع بدء تشغيل النظام: sudo update-rc.d elasticsearch defaults 95 10 انتظر بضع لحظات ثم نفذ الأمر التالي للتأكد من أن Elasticsearch يعمل كما يرام: curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' تظهر نتيجة الأمر كالتالي: { "cluster_name" : "graylog-development", "status" : "green", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 1, "active_shards" : 1, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0 } تثبيت خادوم Graylog يمكننا الآن بعد تجهيز المتطلبات تثبيتُ برنامج Graylog. نبدأ بتثبيت خادوم Graylog. ننزل حزمة مستودع Graylog في المجلد الشخصي للمستخدم: cd ~ wget https://packages.graylog2.org/repo/packages/graylog-1.3-repository-ubuntu14.04_latest.deb ونثبتها: sudo dpkg -i graylog-1.3-repository-ubuntu14.04_latest.deb تضيف هذه الحزمة عند تثبيتها مستودع Graylog إلى قائمة المستودعات لدى النظام. قبل تثبيت حزمة خادوم Graylog نتأكد من أن apt-transport-https التي تمكّن من تنزيل حزم apt باتصال آمن مثبتة: sudo apt-get update sudo apt-get install apt-transport-https sudo apt-get install graylog-server سنستخدم حزمة pwgen لتوليد مفاتيح سرية لذا سنثبتها: sudo apt-get install pwgen سنحتاج لضبط كلمة سر مدير خادوم Graylog ومفتاحه الخاص. يُضبط المفتاح الخاص في ملف server.conf بتحديد قيمة معطى password_secret. يمكن توليد مفتاح عشوائي وإدراجه في إعداد Graylog عبر الأمرين التاليين: SECRET=$(pwgen -s 96 1) sudo -E sed -i -e 's/password_secret =.*/password_secret = '$SECRET'/' /etc/graylog/server/server.conf تُعيَّن كلمة سر المدير بإنشاء مجموع تحقق Checksum لكلمة السر المرغوبة ثم تحديد قيمة المعطى root_password_sha2 في ملف إعداد Graylog بمجموع التحقق المُنشأ. أنشئ مجموع التحقق الخاص بكلمة السر بتنفيذ الأمر أدناه مع إبدال password بكلمة السر التي ترغب فيها. يدرج أمر sed في السطر الثاني مجموع التحقق في ملف إعداد Graylog (يمكنك تنفيذ أمر shasum ثم إدراج النتيجة يدويا في الملف server.conf): PASSWORD=$(echo -n password | shasum -a 256 | awk '{print $1}') sudo -E sed -i -e 's/root_password_sha2 =.*/root_password_sha2 = '$PASSWORD'/' /etc/graylog/server/server.conf نفتح ملف server.conf لتحريره: sudo vi /etc/graylog/server/server.conf ستجد أن قيمتي المعطيين password_secret وroot_password_sha2 عبارة عن سلسلة محارف Strings عشوائية هي ناتج الأوامر أعلاه. نعيد تعيين قيمة المعطى rest_transport_uri التي هي وسيلة اتصال واجهة ويب Graylog بخادومه. بما أننا نثبت جميع العناصر على نفس الخادوم فسنحدّد القيمة 127.0.0.1 أو localhost. اعثُر على المعطى rest_transport_uri وعدّل قيمته لتصبح على النحو التالي (مع إزالة علامة التعليق أمام السطر #): rest_transport_uri = http://127.0.0.1:12900/ نغيّر قيمة معطى elasticsearch_shards إلى 1 نظرا لأن لدينا عامل Elasticsearch وحيدا وهو الخادوم: elasticsearch_shards = 1 ثم نغير قيمة المعطى elasticsearch_cluster_name إلى graylog-development (نفس الاسم الذي حددناه أعلاه لمعطى cluster.name): elasticsearch_cluster_name = graylog-development نزيل علامة التعليق من أمام السطرين التاليين لاستخدام اتصال من نوع unicast بدلا من multicast: elasticsearch_discovery_zen_ping_multicast_enabled = false elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300 احفظ الملف ثم أغلقه. خادوم Graylog الآن مضبوط وجاهز للعمل. نشغّل خادوم Graylog بتنفيذ الأمر التالي: sudo java -jar /usr/share/graylog-server/graylog.jar server تظهر في مخرجات الأمر العبارتان التاليتان دلالة على نجاح تشغيل خادوم Graylog: Started REST API at <http://127.0.0.1:12900/> Graylog server up and running الخطوة الموالية هي تثبيت واجهة ويب Graylog. تثبيت واجهة ويب Graylog ننفذ أمر التثبيت التالي للحصول على واجهة ويب Graylog: sudo apt-get install graylog-web الخطوة التالية هي إعداد المفتاح السري لواجهة الويب الذي يمثله معطى application.secret في ملف الإعداد web.conf. نطبق نفس الطريقة السابقة لتوليد مفتاح سري وإدراجه: SECRET=$(pwgen -s 96 1) sudo -E sed -i -e 's/application\.secret=""/application\.secret="'$SECRET'"/' /etc/graylog/web/web.conf افتح ملف إعداد واجهة الويب لتحريره: sudo vi /etc/graylog/web/web.conf نحتاج لتحديث ملف الإعداد لتحديد قيمة المعطى graylog2-server.uris التي هي قائمة من مسارات URI خاصة بخواديم Graylog. بما أن لدينا عقدة خادوم واحدة فيجب أن تطابق قيمة graylog2-server.uris قيمةَ المعطى rest_listen_uri في إعداد الخادوم (أي http://127.0.0.1:12900/): graylog2-server.uris="http://127.0.0.1:12900/" احفظ الملف ثم أغلقه. يجب نسخ ملف الإعداد إلى المسار /usr/share/graylog-web/conf/web.conf كالتالي: sudo cp /etc/graylog/web/web.conf /usr/share/graylog-web/conf/web.conf ننفذ الأمر التالي لتشغيل واجهة ويب Graylog: sudo /usr/share/graylog-web/bin/graylog-web-interface نستطيع الآن استخدام واجهة الويب، وهو ما سنفعله في الفقرات التالية. إعداد Graylog لاستقبال رسائل النظام Syslog أدخل عنوان الويب التالي إلى شريط العناوين في متصفحك المفضل: http://graylog_public_IP:9000/ يمثّل graylog_public_IP عنوان IP العمومي لخادومك. ستظهر لديك واجهة تطلب اسم المستخدم وكلمة السر. أدخل admin وكلمة السر التي اخترتها أثناء إعداد خادوم Graylog. ثم بعد الدخول الواجهة التالية: يوجد في أعلى الواجهة عدد يمثل إشعارا تظهر بعد النقر عليه رسالة تقول إن لديك عقدة نشطة لا تصلها أية مُدخَلات Inputs. فلنضف مدخلا لاستقبال رسائل سجل النظام عبر UDP. إنشاء مدخل لسجلات النظام عبر ميثاق UDP انقر على القائمة المنسدلة System (النظام) الموجودة في شريط القوائم العلوي واختر Inputs (مُدخلات) لإضافة مُدخَل يستقبل رسائل سجل النظام. اختر Syslog UDP من القائمة المنسدلة في الصفحة الجديدة ثم انقر على زر Launch new input (ابدأ المُدخَل الجديد). ستظهر نافذة منبثقة جديدة. أدخل البيانات التالية (أبدِل graylog_private_IP بعنوان IP الداخلي لخادومك): Title: syslog Port: 8514 Bind address: graylog_private_IP ثم انقر على زرّ Launch أسفل النافذة. ستجد أن مُدخلا جديدا باسم syslog يظهر في فقرة Local inputs؛ تظهر أولا لصيقة starting (في طور التشغيل) ثم بعد قليل تتحول إلى اللون الأخضر وعبارة running (يعمل)، قد تحتاج لإعادة تحميل الصفحة لتحديث الحالة. جهزنا خادوم Graylog لاستقبال رسائل من سجل النظام، بقي لنا ضبط الخادوم لإرسال سجلات النظام إلى Graylog. إعداد الخواديم لإرسال سجلات النظام إلى Graylog ينبغي تطبيق الخطوات التالية على الخواديم التي نريد مراقبتها. نبدأ بإنشاء ملف إعداد rsyslog في المجلد etc/rsyslog/، سنسميه 90-graylog.conf: sudo vi /etc/rsyslog.d/90-graylog.conf نضيف الأسطر التالية إلى الملف كي يبعث برسائل سجلات النظام إلى خادوم Graylog (أبدل graylog_private_IP بعنوان IP المحلي لخادوم Graylog): $template GRAYLOGRFC5424,"<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n" *.* @graylog_private_IP:8514;GRAYLOGRFC5424 احفظ الملف ثم أغلقه. سيُحمَّل هذا الملف مع تحميل إعداد rsyslog، تجب إعادة تحميل rsyslog من أجل اعتماده: sudo service rsyslog restart نعود، بعد إكمال إعداد rsyslog على جميع الخواديم التي نريد مراقبة سجلاتها إلى واجهة Graylog. عرض مصادر Graylog بالعودة إلى واجهة الويب، انقر قائمة Sources في الشريط العلوي. ستظهر أسفل الصفحة لائحة بجميع الخواديم التي أعددت عليها rsyslog لإرسال السجلات إلى Graylog، مع عدد الرسائل الواردة منها في المدة المحددة ضمن القائمة المنسدلة (ساعة مبدئيا). البحث في بيانات Graylog توفر واجهة Graylog إمكانية البحث في بيانات السجلات. تختلف البيانات المتوصَّل إليها حسب نشاط الخادوم، لذا امنح Graylog دقائق لجمع البيانات خصوصا إذا كان النشاط على الخادوم ضعيفا. في الصورة التوضيحية أدناه مثال للبحث عن DNS في البيانات التي جُمعت في آخر 15 دقيقة. تظهر الرسائل في أسفل الصفحة، ويمكن استخدامها للبحث عن مشاكل في الإعدادات ومن ثم إصلاحها. يتيح Graylog إمكانية حصْر البحث في الرسائل القادمة على خادوم واحد فقط في حالة إعداد Graylog لتجميع البيانات من أكثر من مصدر. يمكن أيضا حصر البحث في نطاق زمني محدّد. يفيد البحث قي بيانات Graylog كثيرا حيث يمكّنك مثلا من مراجعة سجلات خادوم أو خواديم بعد حدوث مشكل. تساعد السجلات المركزية في تشخيص الحوادث المترابطة، فأنت لا تحتاج لتسجيل الدخول إلى جميع الخواديم لعرض بيانات الأحداث. خاتمة لا تنحصر إمكانيات Graylog في تجميع بيانات سجل النظام بل يمكن استخدامه لمركزة سجلات مختلفة ومراقبة التطبيقات أو الأنظمة التي ترسلها. كما تمكن أيضا إعادة تهيئة السجلات المرسلة لاستخراج بيانات محدّدة منها. لا تتردد في استكشاف إمكانيات البرنامج. يُستحسن في بيئات العمل الكبيرة تثبيت عناصر Graylog وإعدادها على خوادم منفصلة لأداء أعلى. ترجمة -وبتصرف- لمقال How To Install Graylog 1.x on Ubuntu 14.04 لصاحبه Mitchell Anicas.

في كثير من الأحيان يحتاج مدراء أنظمة لينكس للإطلاع على ملفات السجلات (log files) للكشف عن الأخطاء والمشاكل، وهذا الأمر في الحقيقة يجب على أي مدير نظام القيام به. يستطيع نظام لينكس ومُختلف التطبيقات توليد مختلف أنواع الرسائل والتي يتم تسجيلها في ملفات السجلات المختلفة، ويستخدم نظام لينكس مجموعة من ملفات الإعدادات والمجلدات والبرامج والأوامر والعفاريت (daemons) لإنشاء وتخزين وحذف رسائل السجل. ولذلك فإن معرفة المكان الذي يحتفظ فيه النظام على ملفات السجلات وكيفية استخدام الأوامر المتعلقة به يمكن أن يساعدك على توفير وقتك الثمين أثناء استكشاف الأخطاء وإصلاحها. في هذا الدرس، سنلقي نظرة على مُختلف جوانب السّجلات وإدارتها على أنظمة لينكس ملاحظة: تم اختبار هذه الأوامر على أنظمة CentOS 6.4 و Ubuntu 12 و Debian 7. الموقع الافتراضي لملفات السجلات إن الموقع الافتراضي لملفات السجلات هو var/log/. يمكنك رؤية قائمة الملفات الموجودة في هذا المجلد عن طريق الأمر: ls -l /var/log هذه قائمة ملفات السجلات الموجودة في نظام CentOS الخاص بي: total 1472 -rw-------. 1 root root 4524 Nov 15 16:04 anaconda.ifcfg.log -rw-------. 1 root root 59041 Nov 15 16:04 anaconda.log -rw-------. 1 root root 42763 Nov 15 16:04 anaconda.program.log -rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log -rw-------. 1 root root 40669 Nov 15 16:04 anaconda.syslog -rw-------. 1 root root 57061 Nov 15 16:04 anaconda.xlog -rw-------. 1 root root 1829 Nov 15 16:04 anaconda.yum.log drwxr-x---. 2 root root 4096 Nov 15 16:11 audit -rw-r--r-- 1 root root 2252 Dec 9 10:27 boot.log -rw------- 1 root utmp 384 Dec 9 10:31 btmp -rw-------. 1 root utmp 1920 Nov 28 09:28 btmp-20131202 drwxr-xr-x 2 root root 4096 Nov 29 15:47 ConsoleKit -rw------- 1 root root 2288 Dec 9 11:01 cron -rw-------. 1 root root 8809 Dec 2 17:09 cron-20131202 -rw-r--r-- 1 root root 21510 Dec 9 10:27 dmesg -rw-r--r-- 1 root root 21351 Dec 6 16:37 dmesg.old -rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log -rw-r--r--. 1 root root 146876 Dec 9 10:44 lastlog -rw------- 1 root root 950 Dec 9 10:27 maillog -rw-------. 1 root root 4609 Dec 2 17:00 maillog-20131202 -rw------- 1 root root 123174 Dec 9 10:27 messages -rw-------. 1 root root 458481 Dec 2 17:00 messages-20131202 -rw------- 1 root root 2644 Dec 9 10:44 secure -rw-------. 1 root root 15984 Dec 2 17:00 secure-20131202 -rw------- 1 root root 0 Dec 2 17:09 spooler -rw-------. 1 root root 0 Nov 15 16:02 spooler-20131202 -rw-------. 1 root root 0 Nov 15 16:02 tallylog -rw-rw-r--. 1 root utmp 89856 Dec 9 10:44 wtmp -rw------- 1 root root 3778 Dec 6 16:48 yum.log عرض محتويات ملف السجل هذه قائمة من ملفات السجلات الشائعة التي يمكن أن تجدها في مجلد /var/log/: wtmp utmp dmesg messages maillog أو mail.log spooler auth.log أو secure إن ملفات wtmp و utmp تتبع تسجيل دخول وخروج المستخدمين ولا يمكنك عرض محتويات هذه الملفات باستخدام الأمر cat أو ما شابه، فهنالك أوامر خاصة لفعل ذلك. سوف نتعلم في هذا الدرس بعضا من هذه الأوامر. لتعرف من الذي سجّل دخوله حاليا في خادوم لينكس يمكنك بسهولة استخدام الأمر who، وهذا الأمر يحصل على بياناته من ملف var/run/utmp/ (لأنظمة CentOS وDebian) أو من ملف run/utmp/ (لأنظمة أوبنتو). هذا مثال من نظام CentOS: who root tty1 2013-12-09 10:44 root pts/0 2013-12-09 10:29 (10.0.2.2) sysadmin pts/1 2013-12-09 10:31 (10.0.2.2) joeblog pts/2 2013-12-09 10:39 (10.0.2.2) في هذه الحالة بالذات، أنا المستخدم الوحيد للنظام ولقد شغّلت الخادوم من Oracle VirtualBox ومن ثم استطعت الوصول إليه كمستخدم جذر من الطرفية من جلسة SSH، أما بالنسبة للمستخدميْن الآخريْن (sysadmin وjoebolg) فهم أيضا فتحا جلسات لهما على النظام. الأمر last يخبرنا بتاريخ تسجيل الدخول للمستخدمين: last | grep sysadmin sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31 still logged in sysadmin pts/0 10.0.2.2 Fri Nov 29 15:42 - crash (00:01) sysadmin pts/0 10.0.2.2 Thu Nov 28 17:06 - 17:13 (00:06) sysadmin pts/0 10.0.2.2 Thu Nov 28 16:17 - 17:05 (00:48) sysadmin pts/0 10.0.2.2 Thu Nov 28 09:29 - crash (06:04) sysadmin pts/0 10.0.2.2 Wed Nov 27 16:37 - down (00:29) sysadmin tty1 Wed Nov 27 14:05 - down (00:36) sysadmin tty1 Wed Nov 27 13:49 - 14:04 (00:15) في هذا المثال، أحاول إيجاد تاريخ تسجيل الدخول لمستخدم sysadmin، وكما ترى، فهنالك أمثلة لبضعة حالات توقّف فيها النظام. لتعرف متى كانت آخر مرة تم إعادة تشغيل (reboot) النظام، يمكننا كتابة الأمر التالي: last reboot وستكون النتيجة مشابهة لهذه: reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10) reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot 2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 (05:29) reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36) reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34) reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53) ... ... wtmp begins Fri Nov 15 16:11:54 2013 وإذا أردت معرفة متى سجّل شخص معين دخوله آخر مرة إلى النظام، استخدم الأمر lastlog: lastlog في نظامي، ستكون النتيجة مشابهة لهذه: Username Port From Latest root tty1 Mon Dec 9 10:44:30 +1100 2013 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** sync **Never logged in** shutdown **Never logged in** halt **Never logged in** mail **Never logged in** uucp **Never logged in** operator **Never logged in** games **Never logged in** gopher **Never logged in** ftp **Never logged in** nobody **Never logged in** vcsa **Never logged in** saslauth **Never logged in** postfix **Never logged in** sshd **Never logged in** sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013 dbus **Never logged in** joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013 بالنسبة لبقية ملفات السجل النصية، يمكنك استخدام أوامر cat أو head أو tail لقراءة محتوياتها. في المثال بالأسفل، أحاول النظر إلى آخر 10 أسطر من ملف var/log/messages/ في نظام Debian: sudo tail /var/log/messages ستكون المخرجات كالآتي: Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6 Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810 Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 عفريت rsyslog في قلب آلية التّسجيل نجد عفريت rsyslog، وهذه الخدمة مسؤولة عن الاستماع إلى رسائل السجلات من مختلف أجزاء نظام لينكس ومن ثم توجيه الرسالة إلى ملف السجل الصحيح في مجلد var/log/ وكما يمكنها إعادة إرسال رسائل السجلات إلى خواديم لينكس آخرى. ملف إعدادات rsyslog يحصل عفريت rsyslog على إعداداته من ملف rsyslog.conf الموجود في مجلد etc/، ويعمل هذا الملف أساسا على اخبار عفريت rsyslog أين يحفظ رسائل السجلات، وهذه التعليمات تأتي من سلسلة أسطر متكونة من جزئين داخل الملف. يمكن إيجاد هذا الملف في rsyslog.d/50-default.conf في نظام أوبنتو. تتكون مجموعتا التعليمات من محدد (selector) وإجراء (action)، ويتم الفصل بين الجزئين بفراغ. يُحدد جزء "المحدد" مصدر وأهمية رسالة السجل وأما جزء "الإجراء" فيحتوي على ما يجب فعله مع تلك الرسالة. ينقسم جزء "المحدد" إلى جزئين مفصولين بنقطة .، ويسمى الجزء الأول بـ facility (جزء أصل الرسالة) وأما الثاني وهو الذي يأتي بعد النقطة فيسمى بـ priority (جزء درجة أهمية الرسالة) ومعا، أي جزئي facility/priority والإجراء يخبران rsyslog ماذا يفعل عندما يتم إنشاء رسالة تتطابق مع المعايير. هذا مقتطف من ملف rsyslog.conf على توزيعة CentOS: # rsyslog v5 configuration file ... ... # Include all config files in /etc/rsyslog.d/ IncludeConfig /etc/rsyslog.d/*.conf #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log ... ... لنفهم السطور السابقة، دعونا ننظر في أنواع المختلفة من المنشئات (facilities) التي يعترف بها نظام لينكس: auth أو authpriv: الرسائل التي تأتي من الأحداث المرتبطة بالأمن والتراخيص (authorization). kern: للرسائل القادمة من نواة لينكس. mail: للرسائل التي تم إنشاؤها من نظام الفرعي للبريد. cron: للرسائل المتعلقة بعفريت Cron. daemon: للرسائل القادمة من العفاريت. news: للرسائل القادم من النظام الفرعي لأخبار الشبكة. lpr: لرسائل السجل المتعلقة بالطباعة. user: لرسائل السجل القادمة من برامج المستخدم. من local0 إلى local7: محجوزة للاستخدام المحلي. وهذه قائمة من الأولويات بترتيب تصاعدي: debug: بيانات تنقيح البرامج. info: رسالة معلومات بسيطة - لا يلزم التدخل. notice: حالة قد تتطلب الاهتمام. warn: تحذير. err: خطأ. crit: حالة حرجة. alert: حالة تتطلب تدخلًا فوريًا. emerg: حالة طارئة مستعجلة. والآن دعونا ننظر إلى هذا السطر من الملف: cron.* /var/log/cron هذا السطر سيخبر عفريت rsyslog بحفظ جميع الرسائل من عفريت cron في ملف يدعى var/log/cron/، وأما رمز * بعد النقطة فيعني أن الرسائل من جميع الأولويات سيتم تسجيلها، وبالمثل فإذا تم وضع رمز * في المنشأ (facility) فذلك يعني لجميع المصادر. يمكن أن تكون المنشئات والأولويات مرتبطة بعدة طرق، ففي الشكل الافتراضي، عندما يكون هنالك أولوية واحد محددة بعد النقطة، فذلك يعني تحديد جميع الأحداث التي أولويتها أكبر أو تساوي تلك الأولوية، لذلك في الموجه التالي فإنه سيتم تسجيل جميع الرسائل القادمة من نظام الفرعي للبريد والتي تكون أولويتها من نوع تحذير فما فوق في ملف خاص داخل مجلد var/log/: mail.warn /var/log/mail.warn سيتم تسجيل جميع الرسائل التي تساوي أولويتها لـ "تحذير" فما فوق وتتُرك بقية الرسائل التي تكون أولويتها أقل من ذلك، أي أن الرسائل ذات أولوية err أو crit أو alert أو emerg لن يتم تسجيلها في الملف. إذا تم استخدام رمز المساواة = بعد النقطة فسيتم تسجيل فقط الأولوية المطابقة، أي أنه إذا أردت الحصول على رسائل info فقط القادمة من نظام الفرعي للرسائل، فإنك ستكتب شيء مشابه لهذا: mail.=info /var/log/mail.info مرة أخرى، إذا أردت الحصول على جميع الرسائل من نظام الفرعي للبريد ماعدا رسائل info، فإنك ستكتب شيئًا مشابهًا لهذا: mail.!info /var/log/mail.info أو هذا: mail.!=info /var/log/mail.info في الحالة الأولى، سيحتوي ملف mail.info على جميع الرسائل التي تملك أولوية أقل من info، وفي الحالة الثانية، سيحتوي هذا الملف على جميع الرسائل التي تملك أولوية أكبر من info. في حالة وجود أكثر من مَنشأ على نفس السطر فيجب الفصل بينها بواسطة فواصل، وفي حالة وجود مصادر متعددة (facility.priority) في نفس السطر فيجب الفصل بينها بواسطة الفاصلة المنقوطة. عندما يتم وضع علامة * لأحد الإجراءات فهذا يعني أن الإجراء لجميع المستخدمين. هذا السطر في ملف rsyslog.conf في نظام CentOS يخبرنا بهذا الشيء: # Everybody gets emergency messages *.emerg * حاول أن تعرف ماذا يقول ملف rsyslog.conf في نظام لينكس، فهذا مقتطف من خادوم نظام ديبيان الذي أعمل عليه: # /etc/rsyslog.conf Configuration file for rsyslog. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ... ... auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice كما ترى، يحفظ ديبيان جميع الرسائل ذات مستوى أمني/تراخيص في var/log/auth.log/ في حين أن CentOS يحفظها في var/log/secure/. إن إعدادات rsyslog يمكن أن تأتي من ملفات خاصة أخرى، هذه الملفات الخاصة موجودة في العادة في مجلدات مختلفة داخل مجلد etc/rsyslog.d/ ويحتوي ملف rsyslog.conf على جميع هذه المجلدات باستخدام موجه IncludeConfig$. هكذا يبدو شكلها في نظام أوبنتو: # Default logging rules can be found in /etc/rsyslog.d/50-default.conf .... .... $IncludeConfig /etc/rsyslog.d/*.conf تبدو المحتويات الموجودة في مجلد etc/rsyslog.d/ كالتالي: -rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf -rw-r--r-- 1 root root 252 Apr 11 2012 21-cloudinit.conf -rw-r--r-- 1 root root 1655 Mar 30 2012 50-default.conf لا يجب أن تكون وجهة رسائل السجل بالضرورة هي ملف السجل، فيمكن أن تُرسل الرسالة إلى طرفية المستخدم، وفي هذه الحالة، سيحتوي حقل الإجراء على اسم المستخدم، وإذا كنت تحتاج إلى إرسال الرسالة إلى أكثر من مستخدم واحد، فيجب فصل أسماء المستخدمين بفواصل وإذا أردت إرسالها لجميع المستخدمين فيمكنك وضع الرمز * في حقل الإجراء. بما أن عفريت rsyslog جزء من نظام تشغيل الشبكة، فلا يُمكنه حفظ السّجلات محليا فحسب، وإنما يمكنه أن يُرسلها إلى خواديم لينكس أخرى في الشبكة أو أن يُصبح مستودعًا لبقية الأنظمة. فالعفريت يستمع لرسائل السجل من منفذ UDP 514. المثال التالي سيُغير وجهة الرسائل الحرجة للنواة إلى خادوم يدعى texas. kern.crit @texas إنشاء واختبار رسائل سجل الخاصة بك حان الآن وقت إنشاء ملفات سجل خاصة بنا، ولتجربة هذا سنحتاج إلى التالي: إضافة مواصفات ملف السجل في ملف etc/rsyslog.conf/ إعادة تشغيل عفريت rsyslog تجربة الإعدادات باستخدام أداة logger في المثال التالي، أضفت سطرين جديدين إلى ملف rsyslog.conf التابع لنظام لينكس CentOS الخاص بي، وكما ترى، كل واحد منها قادم من منشأ يدعى local4 ولديهم أولويات مختلفة. vi /etc/rsyslog.conf .... .... # New lines added for testing log message generation local4.crit /var/log/local4crit.log local4.=info /var/log/local4info.log بعد ذلك، سيتم إعادة تحميل ملف الإعدادات عند إعادة تشغيل الخدمة: /etc/init.d/rsyslog restart Shutting down system logger: [ OK ] Starting system logger: [ OK ] الآن، تم استدعاء تطبيق التسجيل لإنشاء رسالة سجل: logger -p local4.info " This is a info message from local 4" الآن، عند النظر إلى مجلد var/log/ سوف تجد ملفين جديدين: ... ... -rw------- 1 root root 0 Dec 9 11:21 local4crit.log -rw------- 1 root root 72 Dec 9 11:22 local4info.log إن حجم ملف local4info.log لا يساوي صفر، لذلك عندما يتم فتحه، سأرى الرسالة التي تم تسجيلها: cat /var/log/local4info.log Dec 9 11:22:32 TestLinux root: This is a info message from local 4 تدوير ملفات السجل كلما زادت المعلومات المكتوبة في ملفات السجل ازداد حجمها، ومن الواضح أن هذا الأمر سيقلل من الأداء وستكون إدارة هذه الملفات عملية متعبة. لينكس يستخدم مفهوم "التدوير" لملفات السجل بدلا من تنظيفها أو حذفها، عندما يتم تدوير سجل معين، سيتم إنشاء ملف جديد وتغيير اسم الملف القديم وضغطه بشكل إختياري. يمكن لملف السجل أن يملك عدة نسخ قديمة لا تزال موجودة، وهذه الملفات قد تعود لفترات قديمة من الزمن وستكون كسجل متراكم، وعند إنشاء عدد معين من هذه المتراكمات سيتسبب السجل المُدوّر بحذف ملف السجل الأقدم . يتم تشغيل التدوير عن طريق أداة logrotate. ملف إعدادات logrotate يعتمد logrotate مثل rsyslog على ملف الإعدادات واسم هذا الملف هو logrotate.conf وهو موجود في etc/. هذا ما أراه في ملف logrotate.conf على خادوم ديبيان الخاص بي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # uncomment this if you want your log files compressed #compress # packages drop log rotation information into this directory include /etc/logrotate.d # no packages own wtmp, or btmp -- we'll rotate them here /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0660 root utmp rotate 1 } # system-specific logs may be configured here الأسطر مفهومة وتشرح نفسها بنفسها، بشكل افتراضي، ملفات السجل يتم تدويرها بشكل أسبوعي مع الإبقاء على أربع سجلات في وقت واحد، عندما يشتغل البرنامج سيتم إنشاء ملف سجل جديد وسيتم ضغط الملف القديم اختياريا. الاستثناء الوحيد هو في ملفات wtmp و btmp، فملفات wtmp تتبع تسجيلات الدخول للنظام وأما btmp فهي تتبع تسجيلات الدخول النظام الخاطئة، كلا هذين الملفين يتم تدوريهما كل شهر ولن يتم إرجاع أي خطأ إذا كان أحد الملفات السابقة لـ wtmp أو btmp غير موجود. يتم الاحتفاظ بملفات إعدادات التّدوير المخصصة في مجلد etc/logrotate.d/، وهذه أيضا يتم تضمينها في ملف logrotate.conf مع التوجيه. يعرض لي نظام ديبيان محتويات هذا المجلد: ls -l /etc/logrotate.d total 44 -rw-r--r-- 1 root root 173 Apr 15 2011 apt -rw-r--r-- 1 root root 79 Aug 12 2011 aptitude -rw-r--r-- 1 root root 135 Feb 24 2010 consolekit -rw-r--r-- 1 root root 248 Nov 28 2011 cups -rw-r--r-- 1 root root 232 Sep 19 2012 dpkg -rw-r--r-- 1 root root 146 May 12 2011 exim4-base -rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog -rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils -rw-r--r-- 1 root root 94 Aug 8 2010 ppp -rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog -rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades محتويات ملف rsyslog تظهر لك كيف يتم تدوير بعض ملفات السجل: cat /etc/logrotate.d/rsyslog /var/log/syslog { rotate 7 daily missingok notifempty delaycompress compress postrotate invoke-rc.d rsyslog reload > /dev/null endscript } /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate invoke-rc.d rsyslog reload > /dev/null endscript } كما ترى، إن ملف syslog ستتم إعادة تهيئته يوميا مع إبقاء ملفات السجل لمدة 7 أيام، أما بقية ملفات السجل فيتم تدويرها أسبوعيا. كما لا ننسى موجه postrotate فهو جدير بالذكر أيضا، فهذا الإجراء يحدد ماذا يحدث بعد الانتهاء من كامل عملية إعادة تدوير ملف السجل. تجربة التدوير يمكن أن يشتغل Logrotate يدويا لإعادة تدوير ملف أو أكثر، ولفعل ذلك، يمكننا ببساطة تحديد ملف الإعدادات الخاص بالأمر كمعامل لهذا الأمر. لنرى كيف يعمل، هذه قائمة جزئية من ملفات السجل موجود في مجلد var/log/ على الخادوم التجريبي CentOS الخاص بي: ls -l /var/log total 800 ... -rw------- 1 root root 359 Dec 17 18:25 maillog -rw-------. 1 root root 1830 Dec 16 16:35 maillog-20131216 -rw------- 1 root root 30554 Dec 17 18:25 messages -rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216 -rw------- 1 root root 591 Dec 17 18:28 secure -rw-------. 1 root root 4187 Dec 16 16:41 secure-20131216 ... ... سوف تبدو المحتويات الجزئية لملف logrotate.conf كالتالي: cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create ... ... بعد ذلك قمنا بتشغيل أمر logrotate: logrotate -fv /etc/logrotate.conf سيتم نقل الرسائل عند إنشاء الملفات الجديدة والتعامل مع الأخطاء. وعندما يتنهي كل هذا، سنحاول التأكد من ملفات mail وsecure و messages الجديدة: ls -l /var/log/mail* -rw------- 1 root root 0 Dec 17 18:34 /var/log/maillog -rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216 -rw------- 1 root root 359 Dec 17 18:25 /var/log/maillog-20131217 ls -l /var/log/messages* -rw------- 1 root root 148 Dec 17 18:34 /var/log/messages -rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216 -rw------- 1 root root 30554 Dec 17 18:25 /var/log/messages-20131217 ls -l /var/log/secure* -rw------- 1 root root 0 Dec 17 18:34 /var/log/secure -rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216 -rw------- 1 root root 591 Dec 17 18:28 /var/log/secure-20131217 كما ترى، تم إنشاء ملفات السجل الجديدة الثلاث، ملفات maillog و secure لاتزال فارغة، في حين أن ملف messages يملك بعض المعلومات. خاتمة نأمل أن يكون هذا الدرس قد أعطاك بعض الأفكار حول سجلات نظام لينكس، يمكنك أن تحاول وتجرب على خادومك التجريبي حتى تكون لديك فكرة أفضل، حالما تتعود على أماكن ملفات السجل وإعداداتها، استخدم معرفتك لدعم نظم الإنتاج الخاصة بك، وحينها، يمكنك إنشاء بعض الكُنيات aliases لتوفير بعض الوقت . ترجمة -وبتصرف- للمقال: How To View and Configure Linux Logs on Ubuntu and Centos لصاحبه Sadequl Hussain.

يمكننا الآن، بعد إكمال إعداد بيئة الإنتاج في الدرس السابق، البدء في إعداد نظام مركزي للسجلات؛ وهو وسيلة رائعة لجمع سجلات الخواديم ومعاينتها. لا يعدّ إعداد نظام سجلات دقيق، على العموم، في نفس أهمية توفر نظامي نسخ احتياطي ومراقبة فعالين؛ إلا أنه يمكن أن يكون مفيدا جدا عند البحث في اتجهات استخدام التطبيق أو أثناء محاولة تحديد المشاكل التي يعاني منها التطبيق. سنعد في هذا الدليل حزمة برامج ELK، ونعني بها Logstash، Elasticsearch وKibana؛ ثم نعد مختلف الخواديم المكونة لبيئة الإنتاج حتى ترسل السجلات المناسبة إلى خادوم السجلات. سنعد أيضا مُرشِحات Filters في Logstash من أجل تجزئة السجلات وهيكلتها وهو ما يسهِّل عملية البحث في السجلات وترشيحها ثم استخدام Kibana لمعاينتها. المتطلباتيجب، إن أردت الوصول إلى لوحة المراقبة عبر نطاق خاص مثل logging.example.com، إنشاء سجل من نوع A ضمن إعدادات النطاق يحيل إلى عنوان IP العمومي الخاص بخادوم السجلات. أو يمكنك بدلا من ذلك الوصول إلى لوحة التسجيلات باستخدام عنوان الخادوم العمومي. يُنصح بإعداد خادوم السجلات لاستخدام HTTPS وتقييد الوصول إليه بوضعه في شبكة خاصة افتراضية. تثبيت حزمة ELK على خادوم السجلاتاضبط حزمة ELK على خادوم السجلات باتباع خطوات درس كيف تثبت Logstash، Elasticsearch وKibana 4 على خادوم Ubuntu 14.04. تأكد من اتباع الخيار رقم 2 في فقرة توليد شهادات SSL. توقف عند الوصول إلى فقرة ضبط معيد توجيه Logstash. إعداد معيدي توجيه Logstash على العملاءاضبط معيد توجيه Logstash (مُرسِل للسجلات) على الخواديم العميلة (مثلا db1، app2، app1 وlb1) باتباع فقرة ضبط معيد توجيه Logstash في درس ELK. سيمكنك بعد إكمال الإعداد الدخولُ إلى Kibana عبر العنوان العمومي لخادوم السجلات وعرض سجلات النظام الخاصة بخواديمك. تحديد السجلات المراد جمعهاتتيح برامج ELK الكثير من السجلات لجمعها، حسب نوعية البرامج المثبتة على الخواديم وإعدادها. سنجمع، في مثالنا، السجلات التالية: سجل الاستعلامات Queries البطيئة في MySQL (الخادوم db1).سجلات الأخطاء والوصول في Apache (على الخادومين app1 وapp2).سجلات HAProxy (خادوم توزيع الحمل lb1).اخترنا هذه السجلات بالضبط لأن بإمكانها توفير معلومات مفيدة أثناء استكشاف الأخطاء وإصلاحها أو عند محاولة تحديد توجهات المستخدمين. يمكن أن يكون لدى خادومك سجلات أخرى مهمة، حسب إعداداتك. إعداد سجلات MySQLيحفظ MySQL الاستعلامات البطيئة في سجل على المسار var/log/mysql/mysql-slow/. يتضمن السجل الاستعلامات التي أخذت وقتا طويلا للتنفيذ؛ يمكن أن يساعد تحديد هذه الاستعلامات في تحسين التطبيق والبحث عن علله وإصلاحها. تفعيل تسجيل الاستعلامات البطيئة في MySQLتسجيل الاستعلامات البطيئة في MySQL غير مفعَّل في الإعدادات الافتراضية؛ لذا سنحتاج لتفعيله. افتح ملف إعدادات MySQL لتحريره: sudo nano /etc/mysql/my.cnfابحث عن التعليمة log_slow_queries وانزع علامة التعليق # الموجودة أمامها ليصبح السطر على النحو التالي: log_slow_queries = /var/log/mysql/mysql-slow.logاحفظ الملف ثم أغلقه. تجب إعادة تشغيل MySQL لاعتماد التغييرات: sudo service mysql restartسيبدأ MySQL الآن في تسجيل الاستعلامات التي تأخذ وقتا طويلا للتنفيذ. ملف السجل يوجد على المسار المحدّد في الإعداد. إرسال ملفات سجلات MySQLيجب إعداد معيد التوجيه في Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات. حرر ملف إعداد معيد التوجيه على خادوم قاعدة البيانات db1: sudo nano /etc/logstash-forwarder.confأضف الأسطر التالية في آخر فقرة files لإرسال الاستعلامات البطيئة إلى خادوم السجلات وتحديد نوع السجل ب mysql-slow , { "paths": [ "/var/log/mysql/mysql-slow.log" ], "fields": { "type": "mysql-slow" } } احفظ الملف ثم أغلقه. تعد التعليمات السابقة معيد توجيه Logstash لإرسال سجلات الاستعلامات البطيئة إلى خادوم السجلات وتعليمها بmysql-slow. سنستخدم نوع السجل لاحقا في الترشيح. أعد تشغيل معيد التوجيه للبدء في إرسال السجلات: sudo service logstash-forwarder restartمرماز Codec المدخلات متعددة الأسطرسنحتاج لتفعيل مرماز تعدد الأسطر في Logstash لمعالجة سجلات الاستعلامات البطيئة في MySQL التي تأتي على أسطر متعددة. افتح ملف الإعدادات الذي يعرِّف مدخل Lumberjack على خادوم logging: sudo nano /etc/logstash/conf.d/01-lumberjack-input.confأضف الأسطر التالية إلى تعريف lumberjack: codec => multiline { pattern => "^# User@Host:" negate => true what => previous }احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لاستخدام معالج السجلات متعددة الأسطر عند العثور على سجلات تحتوي على النمط Pattern المُحدَّد (أي تلك التي تبدأ ب # User@Host: ). في ما يلي سنضبط مرشح Logstash لسجلات MySQL. مرشح سجلات MySQLافتح ملفا جديدا على خادوم السجلات logging لإضافة مرشحات لسجل MySQL. سنسمي الملف 11-mysql.conf لكي يُقرأ بعد إعداد مدخلات Logstash (موجودة في ملف 01-lumberjack-input.conf): sudo nano /etc/logstash/conf.d/11-mysql.confأضف تعريف المرشح التالي: filter { # يسجل المستخدم واختياريا اسم المستضيف وعنوان IP if [type] == "mysql-slow" { grok { match => [ "message", "^# User@Host: %{USER:user}(?:\[[^\]]+\])?\s+@\s+%{HOST:host}?\s+\[%{IP:ip}?\]" ] } # يسجل مدة تنفيذ الاستعلام، مدة قفل السطر في قاعدة البيانات، الأسطر المُرجعة في النتيجة والأسطر المفحوصة. grok { match => [ "message", "^# Query_time: %{NUMBER:duration:float}\s+Lock_time: %{NUMBER:lock_wait:float} Rows_sent: %{NUMBER:results:int} \s*Rows_examined: %{NUMBER:scanned:int}"] } # يسجل وقت حدوث الاستعلام grok { match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ] } # يستخرج الوقت اعتمادا على وقت الاستعلام بدلا من وقت إدراج العنصر في السجلات date { match => [ "timestamp", "UNIX" ] } # يحذف حقل الختم الزمني من السجل نظرا لتسجيل وقت الحدث (الاستعلام) mutate { remove_field => "timestamp" } } } احفظ الملف ثم أغلقه. تعد التعليمات Logstash لترشيح السجلات من نوع mysql-slow باستخدام أنماط Grok المحددة في تعليمات match. راجع التعليقا فوق كل تعليمة لأخذ نبذة عن عملها. لكي تبدأ هذه المرشحات عملها يجب أن نعيد تشغيل Logstash: sudo service logstash restartيجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات MySQL المرشحة. سجلات Apacheتوجد سجلات Apache عادة على المسار var/log/apache2/ باسم access.log و error.log. يتيح لك جمع هذه السجلات معرفة عناوين IP التي تتصل بخواديمك، طلبات هذه العناوين ونوعية المتصفحات ونظم التشغيل المستخدمة في الاتصال؛ بالإضافة إلى الأخطاء التي يبلغ عنها Apache. إرسال سجلات Apacheنضبط معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم logging. نفذ الأمر التالي على كل واحد من خادومي التطبيق، app1 وapp2 لفتح ملف إعاد الخاص بمعيد توجيه Logstash: sudo nano /etc/logstash-forwarder.confأضف ما يلي ضمن فقؤة files تحت التعليمات الموجودة: , { "paths": [ "/var/log/apache2/access.log" ], "fields": { "type": "apache-access" } }, { "paths": [ "/var/log/apache2/error.log" ], "fields": { "type": "apache-error" } } احفظ الملف ثم أغلقه. تعد هذه التعليمات معيد توجيه Logstash لإرسال سجلات الوصول والأخطاء في Apache إلى خادوم السجلات، ثم تعليم كل سجل بنوعه (أي apache-access بالنسبة للوصول وapache-error بالنسبة للأخطاء). أعد تشغيل معيد التوجيه للبدء في إرسال السجلات: sudo service logstash-forwarder restartإذا تركنا الإعداد الحالي فستُظهر كل سجلات Apache عنوان IP الخاص لخادوم HAProxy بوصفه عنوان المصدر. يعود السبب في ذلك إلى أن الخادوم الوسيط lb1 هو الوسيلة الوحيدة للوصول إلى خواديم التطبيق من الإنترنت. يمكن تغيير هذا الأمر بإعداد الصيغة الافتراضية لسجل Apache بحيث يستخدم الرأسيات X-Forwarded-For التي يرسلها HAProxy. افتح ملف إعداد Apache على كل واحد من خادومي التطبيقات: sudo nano /etc/apache2/apache2.confابحث عن سطر يظهر على النحو التالي: [Label apache2.conf — Original "combined" LogFormat] LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined أبدل: h% ب%{X-Forwarded-For}i لكي تصبح هيئة السطر كالتالي: [Label apache2.conf — Updated "combined" LogFormat] LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined احفظ الملف ثم أغلقه. بهذا نكون أعددنا سجلات Apache لتضمين عنوان IP المصدر الفعلي بدلا من عنوان IP الخاص لخادوم توزيع الحمل. أعد تشغيل Apache لاعتماد التغييرات: sudo service apache2 restartنحن الآن جاهزون لإضافة مرشحات لسجلات Apache في Logstash. مرشحات سجلات MySQLننشئ ملف إعداد جديدا على خادوم السجلات logging من أجل إضافة مرشحات لسجل Apache إلى Logstash. سنسميه 12-apache.conf لكي يقرأه Logstash بعد ملف إعداد المُدخلات (أي ملف 01-lumberjack-input.conf): sudo nano /etc/logstash/conf.d/12-apache.confأضف تعريفات المرشحات التالية: filter { if [type] == "apache-access" { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } } } filter { if [type] == "apache-error" { grok { match => { "message" => "\[(?<timestamp>%{DAY:day} %{MONTH:month} %{MONTHDAY} %{TIME} %{YEAR})\] \[%{DATA:severity}\] \[pid %{NUMBER:pid}\] \[client %{IPORHOST:clientip}:%{POSINT:clientport}] %{GREEDYDATA:error_message}" } } } } احفظ الملف ثم أغلقه. تعد هذه التعليمات Logstash لاستخدام مرشحات Grok لتحليل سجلات الوصول والأخطاء في Apache. يعرف كل مرشح صيغة السجلات التي يتعامل معها ضمن تعليمة match الموجودة في المرشح الموافق لنوع السجل في الاسم. يُستخدم مرشح Grok يوفره Logstash لتحليل سجلات الوصول إلى Apache اعتمادا على الصيغة الافتراضية لهذه السجلات؛ بينما كتبنا مرشح Grok خاص لتحليل الصيغة الافتراضية لسجل الأخطاء في Apache. نعيد تشغيل Logstash لكي تبدأ المرشحات الجديدة عملها: sudo service logstash restartيجب التأكد في هذه المرحلة من أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. يجب أن تتأكد أيضا أن Kibana قادر على رؤية سجلات Apache المرشحة. سجلات HAProxyيسمح جمع سجلات موزع الحمل HAProxy (توجد عادة في الملف var/log/haproxy.log/) بمعرفة عناوين IP التي تتصل بخادوم توزيع الحمل، ماذا تطلب، خادوم التطبيق الذي يجيب على الطلب، ومعلومات مفصَّلة أخرى عن الاتصال. إرسال ملفات السجلات الخاصة بHAProxyنضبط معيد توجيه Logstash لإرسال سجلات HAProxy إلى خادوم السجلات بنفس طريقة الإعداد التي اتبعناها مع الخواديم السابقة. افتح الملف التالي على خادوم توزيع الحمل lb1: sudo nano /etc/logstash-forwarder.confأضف الأسطر التالية إلى فقرة files تحت التعليمات الموجودة سلف. ترسل التعليمات الجديدة سجلات HAProxy إلى خادوم Logstash وتحدد نوعها بـ haproxy-log. , { "paths": [ "/var/log/haproxy.log" ], "fields": { "type": "haproxy-log" } } احفظ الملف ثم أغلقه. تعد التعليمات أعلاه Logstash لإرسال سجلات HAProxy مع تحديد نوعها بhaproxy-log. يستخدَم النوع في ما بعد لترشيح السجلات. أعد تشغيل معيد توجيه في Logstash للبدء في إرسال السجلات: sudo service logstash-forwarder restartمرشح سجلات HAProxyافتح ملفا جديدا على خادوم logging لإضافة مرشح سجلات HAProxy إلى Logstash. سنسمي الملف الجديد 13-haproxy.conf: sudo nano /etc/logstash/conf.d/13-haproxy.confأضف تعريف المرشح التالي: filter { if [type] == "haproxy-log" { grok { match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{SYSLOGPROG}: %{IPORHOST:clientip}:%{POSINT:clientport} \[%{MONTHDAY}[./-]%{MONTH}[./-]%{YEAR}:%{TIME}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} "(%{WORD:http_verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version})|<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://))"'} } } } احفظ الملف ثم أغلقه. تعد التعليمة Logstash لترشيح السجلات من نوع haproxy-log باستخدام نمط Grok المعيَّن، والذي يحلل السجلات لمطابقتها مع الصيغة الافتراضية لسجلات HAProxy. أعد تشغيل Logstash لاعتماد المرشح: sudo service logstash restartيجب التأكد بعد تنفيذ الأمر أن Logstash يعمل بطريقة صحيحة؛ إذ أن أخطاء الإعداد قد تتسبب في إخفاق إعادة تشغيله. إعداد المعاينة باستخدام Kibanaيمكن البدء باستخدام Kibana لمعاينة السجلات التي جمعناها من مختلف الخواديم. يسعادك المقال التالي في البدء باستخدام Kibana: كيف تستخدم لوحات القيادة والمعاينة في Kibana بعد التأقلم مع Kibana جرب درس كيف تظهر مواقع المستخدمين على خريطة باستخدام GeoIP وELK لمعاينة أكثر تقدما. خاتمةإن اتبّعت الخطوات المشروحة في هذا الدليل فستحصل على بيئة إنتاج مثل تلك التي وصفناها في الجزء الأول نظرة عامة على إنشاء تطبيقات موجهة لبيئة الإنتاج من الدليل. ترجمة - وبتصرف - لمقال Building for Production: Web Applications — Centralized Logging لصاحبه Mitchell Anicas.