apache web server error logs یا خطای لاگ های سرور آپاچی

برای مدیریت موثر یه وب سرور، لازمه در مورد فعالیت و عملکرد سرور و همچنین هر مشکلی که وجود داره بازخورد بگیرین. سرور Apache HTTP قابلیت ورود به سیستم بسیار جامع و انعطاف پذیری رو فراهم می‌کنه. مقاله امروز ما هم نحوه پیکربندی قابلیت‌های ورود به سیستم و البته apache web server error logs و چگونگی درک این مطالب رو بهتون نشون میده.

هشدار امنیتی

هرکسی که بتونه در فهرست دایرکتوری که Apache در حال نوشتن یه پرونده ورود به سیستم است، بنویسه، مطمئناً می‌تونه به uid که سرور از اون شروع میشه هم دسترسی پیدا کنه، که البته به طور معمول Root است. بدون این که از عواقب این کار آگاهی داشته باشین، به افراد اجازه ندین که به پوشه‌ای که لاگ های مربوط در اون ذخیره شده دسترسی داشته باشن.

علاوه بر این، پرونده‌های گزارش ممکنه حاوی اطلاعاتی باشن که مستقیماً توسط مشتری و بدون فرار ارائه میشن. بنابراین، برای کلاینت‌های مخرب امکان وارد کردن نویسه‌های کنترل در پرونده‌های ورود به سیستم وجود داره، پس باید در برخورد با لاگ های خام دقت بیشتری بشه.

apache web server error logs

گزارش خطای لاگ های سرور آپاچی ، که نام و مکان اون با دستورالعمل ErrorLog تنظیم شده، مهمترین پرونده ورود به سیستم است. این دستور العمل دقیقاً همون جاییه که Apache httpd اطلاعات تشخیصی رو برای شما ارسال می‌کنه و هر خطایی رو که در پردازش درخواست‌ها با اون روبرو میشه، ثبت می‌کنه. اینجا اولین جاییه که موقع برخوردن به یه مشکلی باید برید سراغش، چون که غالباً در اون جزئیاتی از اشتباهِ رخ داده و نحوه رفع اون وجود داره.

گزارش خطا معمولاً در پرونده‌ای نوشته میشه (به طور معمول error_log در سیستم های unix و error.log در ویندوز و OS / 2). در سیستم‌های یونیکس این امکان نیز وجود داره که سرور خطاهایی رو به syslog ارسال کنه یا اونها رو به یه برنامه انتقال بده.

قالب گزارش خطا نسبتاً آزاد و توصیفی است. اما در بیشتر موارد برای apache web server error logs اطلاعات خاصی وجود داره. به عنوان مثال، در اینجا یه پیام معمولی وجود داره:

            [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

                            

اولین مورد در قسمت ورود به سیستم تاریخ و زمان پیام است. ورودی دوم شدت خطای گزارش شده رو لیست می‌کنه. از دستورالعمل LogLevel برای کنترل انواع خطاهایی که با محدود کردن سطح شدت به گزارش خطا ارسال میشن، استفاده میشه. ورودی سوم آدرس IP مشتری رو میده که خطا رو ایجاد کرده. فراتر از اینها، خود پیام است که در این حالت نشون میده، سرور برای رد دسترسی مشتری پیکربندی شده. سرور مسیر file-system (برخلاف مسیر وب) سند درخواستی رو گزارش می‌کنه.

پیام‌های خیلی مختلفی می‌تونن در گزارش ارور لاگ های سرور آپاچی ظاهر بشن. اکثر اونها شبیه نمونه بالا هستن. گزارش خطا همچنین شامل خروجی اشکال زدایی از اسکریپت های CGI خواهد بود. هر اطلاعاتی که توسط اسکریپت CGI برای stderr نوشته شده باشه مستقیماً در گزارش خطا کپی میشه.

با افزودن یا حذف اطلاعات امکان شخصی سازی خطای لاگ وجود نداره. با این حال، ورودی های لاگ به سیستم خطا که با درخواست‌های خاصی سروکار دارن، با ورودی های مربوطه در access log ارتباط دارن. به عنوان مثال، ورودی مثال بالا مربوط به یه ورودی لاگ کردن به سیستم با کد وضعیت ۴۰۳ است. از اونجایی که امکان شخصی سازی ورود به سیستم وجود داره، می‌تونین با استفاده از اون پرونده ورود اطلاعات بیشتری در مورد شرایط خطا بدست بیارین.

در حین آزمایش، کنترل دائم خطای لاگ برای هر گونه مشکلی مفیده. در سیستم های یونیکس می‌تونین این کار رو با استفاده از مورد زیر انجام بدین:

            tail -f error_log

                            

لاگ سیستم در apache web server error logs

لاگ دسترسی سرور، کلیه درخواست‌های پردازش شده توسط سرور رو ثبت می‌کنه. مکان و محتوای ورودی دسترسی توسط دستورالعمل CustomLog کنترل میشه. از دستورالعمل LogFormat میشه برای ساده سازی انتخاب محتویات لاگ های مربوط استفاده کرد. این بخش نحوه پیکربندی سرور برای ثبت اطلاعات در گزارش دسترسی رو شرح میده.

البته، ذخیره سازی اطلاعات در log access تنها شروع مدیریت log است. گام بعدی تجزیه و تحلیل این اطلاعات برای تولید آماری مفیده. تجزیه و تحلیل ورود به سیستم به طور کلی از بحث این مقاله خارجه و خیلی هم مفصل و طولانیه و در واقع بخشی از کار خود سرور وب هم نیست.

نسخه‌های مختلف Apache httpd از ماژول‌ها و دستورالعمل‌های دیگه‌ای برای کنترل ورود به سیستم دسترسی استفاده کردن، از جمله mod_log_referer ، mod_log_agent و دستورالعمل TransferLog. بخشنامه CustomLog اکنون عملکرد کلیه بخشنامه‌های قدیمی رو در بر می‌گیره.

قالب لاگ سیستم کاملاً قابل تنظیمه. قالب با استفاده از رشته فرمتی مشخص میشه که شباهت زیادی به یه رشته فرمت (C-style printf(1 داره.

فرمت لاگ مشترک

یه پیکربندی معمولی برای ورود به سیستم ممکنه به صورت زیر باشه:

            LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

                            

این مورد یه nickname common رو تعریف می‌کنه و اون رو با یه رشته فرمت log خاص مرتبط میکنه. رشته قالب از دستورالعمل‌های درصدی تشکیل شده و هر کدوم از اونها به سرور میگن که اطلاعات خاصی رو وارد کنه. نویسه‌های لفظی هم ممکنه در رشته قالب قرار بگیرن و مستقیماً در خروجی گزارش کپی بشن. برای جلوگیری از apache web server error logs باید از کاراکتر نقل قول (“) باید با قرار دادن یه اسلش قبل از اون استفاده کرد تا از تفسیر اون به عنوان پایان رشته قالب جلوگیری بشه. رشته فرمت ممکنه حاوی نویسه‌های کنترل ویژه ” \ n “برای خط جدید و “\ t” برای برگه باشه.

دایرکتوری CustomLog با استفاده از Nickname تعریف شده، یه پرونده ثبت جدید ایجاد میکنه. نام پرونده ورود به سیستم مربوط به ServerRoot است مگر این که با یه اسلش آغاز بشه.

با پیکربندی فوق، لاگ های سیستم رو با فرمت معروف به (Format Log Format (CLF می‌نویسه. این قالب استاندارد رو میشه توسط وب سرورهای مختلف تولید کرد و توسط بسیاری از برنامه‌های تجزیه و تحلیل ورود به سیستم خوند. ورودی های پرونده لاگ سیستم تولید شده در CLF چیزی شبیه به مورد زیره:

در بخش زیر، هر قسمت از لاگ سیستم در رابطه با مشکل لاگ های سرور آپاچی شرح داده شده:

۱۲۷.۰.۰.۱ (%h):

این آدرس IP سرویس گیرنده (میزبان از راه دور) است که درخواست رو به سرور داده. اگه HostnameLookups روی On تنظیم شده باشه، سرور سعی می‌کنه نام میزبان رو تعیین کنه و به جای آدرس IP وارد کنه. اما خب این پیکربندی توصیه نمی‌شه؛ چون که می‌تونه سرعت سرور رو به میزان قابل توجهی کاهش بده. در عوض، بهتره برای تعیین نام میزبان از پردازنده ورود به سیستم log مثل logresolve استفاده کنین. آدرس IP گزارش شده در اینجا لزوماً آدرس دستگاهی نیست که برای کاربر ست شده، اگه یه سرور پروکسی بین کاربر و سرور وجود داشته باشه، این آدرس به جای دستگاه اصلی، آدرس پروکسی خواهد بود.

– (%l):

«hyphen یا همون خط تیره» در خروجی نشون میده که اطلاعات درخواستی در دسترس نیست. در این حالت، اطلاعاتی که در دسترس نیست هویت RFC 1413 کاربر است که توسط identd در دستگاه کاربر تعیین میشه. این اطلاعات خیلی قابل اعتماد نیستن و تقریباً هرگز نباید استفاده بشن مگه در شبکه‌های داخلی اون هم با کنترل دقیق!! Apache httpd حتی برای تعیین این اطلاعات تلاش هم نمیکنه مگه این که IdentityCheck روی On تنظیم شده باشه.

(frank (%u:

این مورد سند کاربر متقاضی است که توسط احراز هویت HTTP تعیین شده. همون مقدار معمولاً در متغیر محیط REMOTE_USER برای اسکریپت های CGI ارائه میشه. اگه کد وضعیت درخواست (به زیر مراجعه کنید) ۴۰۱ است، بنابراین به این مقدار نباید اعتماد کرد؛ چون که کاربر هنوز احراز هویت نشده. اگه سند با رمز عبور محافظت نشه، این ورودی دقیقاً مانند مورد قبلی “-” خواهد بود.

[۱۰/Oct/2000:13:55:36 -0700] (%t):

زمانی که سرور پردازش درخواست رو به پایان می‌رسونه، فرمت اون شبیه زیره:

            [day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit

                            

با تعیین format} t}% در رشته فرمت log، جایی که قالب مثل (strftime (3 از کتابخانه استاندارد C است، میشه زمان رو در قالب دیگه‌ای نشون داد.

(“GET /apache_pb.gif HTTP/1.0″ (\”%r\”:

خط درخواست از مشتری در بین دو تا نقل قول آورده شده. خط درخواست حاوی اطلاعات مفیدی برای خطای لاگ های سرور آپاچی است. اول از همه، روشی که مشتری استفاده میکنه GET است. دوم، مشتری از منبع /apache_pb.gif درخواست میکنه و سوم، مشتری از پروتکل HTTP / 1.0 استفاده میکنه. همچنین امکان ثبت یک یا چند قسمت از خط درخواست به طور مستقل وجود داره. به عنوان مثال، رشته قالب “٪ m٪ U٪ q٪ H” روش، مسیر، query-string و پروتکل رو ثبت می‌کنه و نتیجه اون دقیقاً همان خروجی “٪ r” است.

۲۰۰ (٪> s):

این کد وضعیتیه که سرور برای کاربر ارسال می‌کنه. این دسته از اطلاعات در apache web server error logs خیلی ارزشمندن، چون که نشون میدن که آیا این درخواست منجر به پاسخ موفقیت آمیز (شروع کدها از ۲)، تغییر مسیر (شروع کدها از ۳)، خطای ناشی از مشتری (کدهای آغاز شده در ۴) یا خطا در سرور (کدها از ۵ شروع میشن) شده یا خیر. لیست کامل کدهای وضعیت ممکن رو میشه در مشخصات HTTP (بخش ۱۰ RFC2616) پیدا کرد.

۲۳۲۶ (٪ b):

آخرین ورودی اندازه شیء returned یا برگشت داده شده به کاربر رو نشون میده، یادتون باشه که این مورد شامل سربرگ‌های پاسخ نیست. اگه هیچ محتوایی به مشتری بازگردانده نشه، این مقدار “-” خواهد بود. برای ورود “۰” بدون محتوا، به جای اون از٪ B استفاده کنین.

فرمت لاگ ترکیبی

رشته فرمت دیگه‌ای که معمولاً مورد استفاده قرار می‌گیره، Combined Log Format نامیده میشه که به صورت زیر قابل استفاده است:

            LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/acces_log combined
                            

این قالب با اضافه شدن دو قسمت دیگه دقیقاً همون قالب Log مشترک میشه. هر یک از قسمت‌های اضافی از راهنمای درصد (Percent-directive) ٪ {header} i استفاده میکنه، جایی که هدر می‌تونه هر سرصفحه درخواست HTTP باشه. ورود به سیستم در این قالب به شرح زیر است:

زمینه‌های اضافی عبارتند از:

سربرگ Referer” (sic) HTTP” درخواست میکنه. این مورد به سایت اطلاع میده که گزارش کلاینت از کجا ارجاع شده. (این صفحه باید صفحه‌ای باشه که به /apache_pb.gif پیوند داره یا شامل اون میشه).

لاگ دسترسی چندگانه

مورد بعدی برای بررسی خطای لاگ های سرور آپاچی لاگ دسترسی چندگانه است که به راحتی می‌تونه با تعیین چندین دستورالعمل CustomLog در پرونده پیکربندی ایجاد بشه. به عنوان مثال، دستورالعمل‌های زیر سه تا لاگ دسترسی ایجاد می‌کنن. مورد اول شامل اطلاعات اساسی CLF است، در حالی که مورد دوم و سوم حاوی اطلاعات مرجع و مرورگر هستن. دو خط CustomLog آخر نشون میده که چطوری میشه از تأثیرات دستورالعمل های ReferLog و AgentLog تقلید کرد.

            LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"
                            

این مثال همچنین نشون میده که لازم نیست Nickname با دستورالعمل LogFormat تعریف بشه. درعوض، قالب گزارش می‌تونه مستقیماً در بخشنامه CustomLog مشخص بشه.

لاگینگ شرطی (Conditional Loging)

مورد بعدی در بررسی apache web server error logs لاگینگ های شرطی هستن. گاهی اوقات کار راحتیه که برخی از ورودی ها رو از لاگ سیستم بر اساس مشخصات درخواست مشتری حذف کنین. این امر با کمک متغیرهای محیطی به راحتی تحقق پیدا می‌کنه. ابتدا باید یه متغیر محیطی تنظیم بشه تا نشون بده که درخواست از شرایط خاصی برخورداره. این کار معمولاً با SetEnvIf انجام میشه. سپس بند env = دستورالعمل CustomLog برای اضافه کردن یا حذف درخواست‌ها در جایی که متغیر محیطی تنظیم شده، استفاده میشه. به چند نمونه زیر دقت کنین:

            # Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog
                            

یه مثال دیگه اگه بخوایم بزنیم، درخواست های لاگینگ از انگلیسی زبانان به یه پرونده لاگ سیستم، و غیرانگلیسی زبانان به یه پرونده لاگ سیستم دیگه، در نظر بگیرین:

درسته که نشون دادیم که لاگ سیستم شرطی بسیار قدرتمند و انعطاف پذیره، اما این تنها راه کنترل محتوای لاگ ها نیست. پرونده‌های لاگ سیستم وقتی مفید هستن که شامل یه رکورد کامل از فعالیت سرور باشن. معمولاً کار راحتیه که پرونده‌های ورود به سیستم رو پس از پردازش برای حذف درخواست‌هایی که نمی‌خواین بررسی کنین، پس پردازش کنین.