سرویس syslog در لینوکس


سرویس syslog در لینوکس

معرفی سرویس rsyslog

معرفی Syslog:

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

با اطلاعات کسب شده از این طریقمی توان  بررسی روند عملکرد یک نرم افزار ، عیب یابی سیستم (troubleshot)، ثبت وقایع امنیتی، مدیریت سیستم و تحلیل و آنالیز آن ها پرداخت.

Syslog دارای پیام هایی به شرح زیر می باشد.

  • Facility
  • Severity
  • message

Facility:

کدی است که بیانگر نوع برنامه ای که در حال لاگ کردن پیام ها است. رفتار با facility  ها می تواند متفاوت نیز باشد.

لیستی از facility ها به شرح زیر می باشد:

 

Facility Keyword Description
0 kern Kernel messages
1 user User level message
2 mail System daemon
3 daemon System daemons
4 auth Security messages
5 syslog Syslog Internal message
6 lpr Line printer subsystem
7 news Network news subsystem
8 uucp UUCP subsystem
9 cron Clock daemon
10 authpriv Security/auth message
11 ftp For ftp daemon
12 ntp For ntp subsystem
13 security Log audit
14 consol Log alert
15 Solaris-cron Scheduling daemon
16-23 Local0 – local7 For Local use

Severity:

هر پیام ثبت شده در syslog  باید دارای یک severity level یا اولویت (priority) باشد تا درجه اهمیت پیام را مشخص نماید، serenity های موجود به شرح جدول زیر می باشند:

Severity code Description
0 Emerg یا Emergency( سیستم غیر قابل استفاده می باشد)
1 Alert: (شرایطی به وجود آمده است و نیاز با اقدامی سریع می باشد.)
2 Crit یا Critical:(شرایط بحرانی )
3 Err یا Error: (خطایی به وجود آمده است)
4 Warning:(هشداری ایجاد شده است)
5 Notice: (شرایط طبیعی است اما شرط یا شرایطی مصداق پیدا کرده اند)
6 Info یا Information: (پیام هایی صرفا با جنبه اطلاعات)
7 Debug: (پیام هایی با جنبه عیب یابی سیستم)

 

در syslog  هر چقدر که مثدار عددی severity بالاتر رود، درجه اهمیت و اولویت آن نیز بالاتر میرود.

Message:

که پیام اصلی است که به عنوان لاگ ذخیره میشود که شامل تاریخ وساعت در ابتدای آن، نام سرور، پردازشی که پیام را ایجاد کرده است و در نهایت متن پیام میباشد.

خط زیر یک نمونه از پیام های ایجاد شده توسط kernel  می باشد.

Jan  5 08:55:20 server1 kernel: e1000: ens37 NIC Link is Down

Syslog میتواند به صورت لوکال یا به صورت متمرکز و مرکزی عمل کند. در حالتت لوکال، برنامه ها پیام های خود را به سرویس لوکال syslog  ارسال میکنند و این سرویس بر اساس تنظیماتی که برای آن در فایل /etc/syslog.conf  انجام شده است با پیام ها بر خورد میکند.

در روش متمرکز، سروری به عنوان سرور مرکزی لاگ وظیفه دریاف لاگ از سایر سرور ها و ذخیره سازی آنها را بر اساس تنظیمات انجام شده در /etc/syslog.conf  ذخیره می نماید. در سایر سرور ها که می بایست اگ خود را به سرور مرکزی ارسال نمایند، هر برنامه پیام خود را به syslog  لوکال خود ارسال میکند و پیام درفایت شده بر اساس تنظیمات انجام شده برای سرویس لوکال، به سمت سرور مرکزی هدایت خواهد شد.

تنظیمات syslog:

در فایل پیکربندی syslog  در هر دو مدل پیاده سازی، هر خط بیانگر یک یا چند selector وaction  می باشد. قسمت selector  بیانگر facility وpriority می باشد.

به عنوان مثال در خط زیر mail.info به عنوان selector و /var/log/mail.log بیانگر Action  مربوطه می باشد و بدین معنی میباشد که لاگ های دیافت شده از سرویس mail ( یا همان facility2)  و با severity برابر با 6 را در فایل /var/log/mail.log ذخیره نماید.

mail.info /var/log/mail.log

استفاده از “*” در Selector  به معنی any می باشد.  به عنوان نمونه در مثال های زیر نمونه اول بیانگر این است که لاگ های دریافت شده از mail با هر اولویتی که دریافت شد در مسیر اشاره شده ذحیره گردد. و یا در در مثال دوم عنوان میشود که از هر سرویسی اگر پیامی با درجه اولیت warning دریافت شد در فایل /var/log/warning.log ذخیر گردند.

mail.* /var/log/mail.log
*.warning /var/log/warning.log

نکته مهم:

در تعریف selector نقشی به نام modifier  نیز وجود دارد که با علامت “=”  یا “!” استفاده میشود. در صورتی که در تعریف selector و در قسمت severity از modifier استفاده نشود، به آن  priority  و priority های مهم تر از آن اشاره میکند، در واقع mail.warning  یعنی هر پیامی با اولویت warning و بالاتر از آن (err، crit، alert و emergency). در صورتی که بخواهیم صرفا یک severity خاص را معرفی کنیم میبایست از modifier  “=” را به صورت زیر استفاده کنیم.

mail.=notice /var/log/messages

در صورتی که بخواهیم پیام هایی با اولویت کمتر لاگ شوند از فرمت زیر استفاده میشود که به معنی هر لاگی غیر از لاگ هایی با اولیوت notice و بالاتر خواهد بود.

mail.!notice /var/log/messages

و در صورتی که بخواهیم هر اولویتی به جز یک مورد خاص را لاگ کنیم نیز از فرمت زیر استفاده خواهد شد.

mail.!=debug /var/log/service.log

که بیان گر این است که هر پیامی با هر اولویتی به جز debug در مسیر اشاره شده لاگ شود.

در صورتی که قصد داشته باشیم تا پیام را به remote server  یا log server ارسال کنیم میتوانیم به صورت زیر Action را تعریف نمائیم.

*.emerg @logserver.testdomain.ir
*.emerg @172.16.15.14

در خط بالا علامت @ بیانگر ارسال بر روی پروتکل  UDP و @@  بیانگر ارسال از طریق پروتکل  TCP خواهد بود.

در centos  به صورت پیش فرض از rsyslog  جهت ثبت وقایع استفاده میشود. این سرویس به صورت modular  طراحی شده است و برخی از علکرد های آن را میتوان از طریق فراخوانی این ماژول ها استفاده کرد. برخی از این ماژول ها به صورت یش فرض در سرویس  شروع به کار سرویس load  می شوند و نیازی به فراخوانی آنها به صورت مستقل نیست. برخی از تنظیمات این سرویس به شرح زیر می باشند:

  • Imuxsock: ماژولی است امکان لاگ کردن پیام ها به صورت لوکال را از طریق ابزاری مانند logger فراهم می سازد.
  • Imjournal: ماژولی است که در سیستم عامل های مبتنی بر system امکان دسترسی سرویس به imjournal را فراهم میکند.
  • ActionFileDefaultTemplate: مشخص کننده این است که به صورت پیشفرض از کدام template برای فرمت دهی لاگ ها استفاده کند. به صورت پیشفرض این سرویس از فرمت استاندارد استفاده میکند و در صورتی که قصد داشته باشیم از فرمت دلخواه استفاده کنیم می بایست ابتدا template متناسب را ایجاد کرده و به این پارامتر معرفی نمائیم.
  • ActionFileEnableSync: دارای مقادیر on یا off می باشد و به این معنی می باشد که هر بار write های انجام شده را با فایل مربوطه در دیسک sync نماید. این عمل در تعداد عملیات های زیاد نوشتن میتواند کارایی سیستم را کاهش دهد.

Forwarding rules:

همانطور که پیش تر اشاره شد، میتوان لاگ ها را در سروری مرکزی نیز ذخیره نمود. برای این کار علاوه بر این که سرور مبدا می بایست پیام ها را به سرور مقصد ارسال کند، می بایست سرور مقصد برای پذیرش لاگ از سایر سرویس ها پیکربندی شده باشد. در سمت ارسال کننده یا مبدا، برای ارسال  پیام ها به سروری دیگر، یابد از forwarding rule  ها استفاده نمود. میتوان برای پیام های مختلف، Severity های مختف rule  های متنوعی ایجاد نمود.

در زیر یک نمونه از forwarding rule ها آورده شده است. باید توجه داشت که کل مجموعه زیر به عنوان یک rule  درنظر گرفته می شود. در صورتی که قصد داشته باشیم rule  های بیشتری ایجاد نمائیم باید کل بلاک زیر مجددا در فایل کانفیگ تکرار شوند.

$ActionQueueFileName fwhamed1 
$ActionQueueMaxDiskSpace 1g   
$ActionQueueSaveOnShutdown on 
$ActionQueueType LinkedList   
$ActionResumeRetryCount -1    
*.* @@remote-host:514

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

  • ActionQueueFileName: نامی یکتا برای فایل spool متعلق به این rule می باشد.
  • ActionQueueMaxDiskSpace: جداکثر فضایی که فایل spool میتواند در دیسک اشغال کند را مشخص می نماید.
  • ActionQueueSaveOnShutdown: در هنگام shutdown پیام ها را جهت ارسال در آینده در دیسک ذخیره کند.
  • ActionQueueType: متد و الگورتیم مدیریت صف پیام ها را مشخص میکند.
  • ActionResumeRetryCount: بیانگر این است که در صورتی که سرور مقصد از دسترس خارج شد، چه میزان تلاش برای اتصال به آن صورت پذیرد. مقدار -1 به معنی بی نهایت می باشد.

سخن آخر:

در سیستم های کامپیوتری فعالیت ها و اتفاقات زیادی در حال رخ دادن هستند. اطلاعات گرد آوری شده از عملکرد سیستم عامل، عملکرد کاربران، عملکرد سرویس ها، اتصالات برقرار شده از طریق شبکه و … همه و همه میتوانندبیانگر وضعیتی از سیستم باشند. با استفاده از اطلاعاتی که از این طریق syslog جمع آوری می شود می توان علاوه بر آگاهی از وضعیت سرورها و سرویس ها در صورت مشاهده وضعیت نامتعارف براساس اطلاعات دریافتی اقدام متناسب را لحاظ کرد. همچنین میتوان برای ذخیره سازی سوابق، آنالیز و تحلیل و مهمتر از همه troubleshooting  سرویس ها نیز از داده های جمع آوری شده استفاده نمود.

 


دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *