تصویر محمدعلی اکبری

در برنامه نویسی و کار با نرم افزارها زیاد اتفاق می‌افتد که فکر می‌کنیم همه‌ی کار را به درستی انجام داده‌ایم اما در نهایت چیزی بجز یک WSOD دریافت نکرده‌ایم.

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

با معلوماتی که تا الان داشتم فکر می‌کردم قرار است اتفاق x بی‌افتد اما اتفاق y افتاد، چرا؟ ایول پس قراره یه تجربه جدید کسب کنم و یه موضوع جدید یاد بگیرم.

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

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

بگذارید بیشتر توضیح دهم. یک وبسایت را در نظر بگیرید. این وبسایت با زبان PHP نوشته شده است، از پایگاه داده MariaDB استفاده می‌کند. بر روی سیستم عامل CentOS و روی وب سرور Nginx نصب شده و برای بهینه سازی سرعت از کشینگ memcache و پروکسی معکوس varnish استفاده می‌کند. ارسال ایمیل را از طریق نرم افزار sendmail انجام می‌دهد و ....

این پشته نرم افزاری (Stack) ممکن است بیشتر از اینها باشد و از تعداد بیشتری نرم افزار تشکیل شده باشد، در نهایت نرم افزار برای اینکه به درستی کار کند نیاز دارد کل سیستم به درستی کار کند.

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

در این شرایط ممکن است شواهدی وجود داشته باشند که خیلی سریع با توجه به تجربه قبلی که داشته اید، مشکل را پیدا کرده و حل کنید. اما گاهی هیچ ایده ای نداریم که مشکل کجاست؟

در اینجا باید به فایل های log رجوع کنیم. هر نرم افزار قابلیت پیکربندی برای تولید log از رویدادهای داخلی خود را دارد. این log ها در سطوح مختلفی قابل تولید هستند. به عنوان مثال میتوانیم php را طوری پیکربندی کنیم تا اطلاعات مربوط به debug شامل تمامی رویدادهای داخلی و محتوای stack (ترتیب اجرای توابع و متدهای داخلی) خود را در فایل log قرار دهد.

در اینجا باید این چرخه را تا رفع مشکل طی کنیم:

  1. پیکربندی نرم افزارها برای تولید فایل log مناسب و شناسایی محل فایل log تولید شده
  2. بررسی خط به خط فایل log و پیدا کردن مشکل یا رویدادهای مشکوک
  3. مطالعه و جستجو در مورد اطلاعاتی که در مرحله قبل پیدا کرده ایم و اعمال برخی تغییرات در پیکربندی نرم افزارها یا تغییرات در کد نرم افزار
  4. مشاهده مجدد خروجی، طی کردن چرخه از ابتدا تا رسیدن به خروجی مطلوب

بیشتر با فایل های log و نحوه بررسی آنها آشنا شویم

در لینوکس فایل های log معمولا در مسیر /var/log قرار دارند مگر آنکه در پیکربندی نرم افزار مکان دیگری برای تولید آن تعیین شده باشد. برخی نرم افزار ها  نیز برای خطاها، دسترسی ها و رویدادهای داخلی فایل های log جداگانه ای تولید می‌کنند.

در سیستم خودم به مسیر /var/log میرم و با دستور ll وضعیت فایل های log را بررسی میکنم:

[email protected][/var/log]# ll
total 444708
drwxr-xr-x. 11 root   root        4096 Mar 30 21:52 ./
drwxr-xr-x. 24 root   root        4096 Mar 28 09:48 ../
-rw-r--r--   1 root   root        4878 Mar 28 09:47 boot.log
-rw-------   1 root   root     2643812 Mar 30 22:38 cron
drwx------  26 root   root        4096 Mar 30 22:35 dcpumon/
-rw-r--r--.  1 root   root     9347504 Mar 30 21:28 lastlog
-rw-------   1 root   root      498308 Mar 30 22:35 maillog
-rw-r--r--   1 root   root           0 Mar 30 21:59 memcached
-rw-------   1 root   root      686671 Mar 30 22:34 messages
drwxr-xr-x   2 munin  munin       4096 Feb 22 12:40 munin/
drwxr-xr-x   2 mysql  mysql       4096 Feb 22 09:41 mysql/
-rw-r-----   1 mysql  root       17977 May 21  2014 mysqld.log
drwxr-xr-x.  2 ntp    ntp         4096 Mar 16 15:53 ntpstats/
drwxr-xr-x.  2 root   root        4096 May  6  2014 prelink/
drwxr-xr-x.  2 root   root        4096 Mar 30 00:00 sa/
-rw-------   1 root   root     5609490 Mar 30 22:29 secure
-rw-------   1 root   root           0 Mar 29 03:08 spooler
-rw-------   1 root   root        5052 Mar 28 03:11 yum.log

فرض کنید روی memcache و mysql متمرکز شده ام و میدانم مشکل از این نرم‌افزارهاست. حالا با دستور tail -f یا less +F این فایل‌ها را بررسی می‌کنم. با استفاده از این دستورات می‌توانیم آخرین ورودی‌های فایل log را مشاهده کنیم. البته برای دیدن یک فایل log استفاده از less بهتر از tail است، اما برای بررسی چند فایل log شاید همان tail بهتر باشد.

[email protected][/var/log]# tail -f memcached mysqld.log
==> memcached <==
...
==> mysqld.log <==
...

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

 

برچسب ها: 

افزودن نظر جدید