فهرست مطالب این مقاله:
تجهیزات شبکه از پروتکل Syslog برای ارسال پیغام رخدادهای خود به یک سرور گیرنده‌ی پیغام استفاده می‌کنند؛ در این مطلب به بررسی پروتکل Syslog و مفاهیم مرتبط با آن به طور کامل پرداخته شده است.
تجهیزات شبکه از پروتکل Syslog برای ارسال پیغام رخداد های خود به یک سرور گیرنده پیغام که اصطلاحا Syslog Server نامیده می شود استفاده می کنند. این پروتکل توسط بسیاری از انواع تجهیزات شبکه مانند سوئیچ ها، روترها و فایروال ها پشتیبانی می شود. تجهیزات شبکه می توانند به گونه ای تنظیم شوند تا رخداد های مختلفی را با ارسال پیغام Syslog اطلاع رسانی کنند، برای مثال یک روتر ممکن است هر بار که یک کاربر به کنسول آن وارد شد پیغام Syslog ارسال کند، و یک وب سرور زمانی که رخداد access-denied روی داد، پیغام Syslog ارسال کند.
بیشتر تجهیزات شبکه مانند سوئیچ ها و روتر ها می توانند پیغام Syslog ارسال کنند، علاوه بر اینها، همه سیستم عامل های مبتنی بر Unix و همه انواع سیستم عامل های Linux از Syslog به عنوان روش اصلی مدیریت لاگ استفاده می کنند. بسیاری از برنامه های کاربردی و سرویس ها مانند Oracle و Apache نیز از این پروتکل پشتیبانی می کنند، پس اگر در شبکه شما هر یک از موارد فوق وجود دارد، به کارگیری یک نرم افزار پیشرفته مانیتورینگ لاگ مانند زیر سیستم مانیتورینگ لاگ بینا یک امر حیاتی است.
تفاوت Syslog با SNMP در مانیتورینگ
با استفاده از SNMP می توان از تجهیزات شبکه اطلاعات عملکردی را فراخوانی کرد که این عملیات معمولا به صورت متوالی و طبق یک زمانبندی صورت می پذیرد، در این حالت نرم افزار مانیتورینگ در فواصل زمانی کوتاه یک درخواست به دستگاه ارسال کرده و اطلاعاتی مانند فضای دیسک و یا میزان حافظه آزاد را میپرسد، و دستگاه نیز داده های درخواست شده را ارائه می دهد.
دریافت چنین اطاعاتی با Syslog امکان پذیر نیست، و تجهیزات شبکه طبق تنظیماتی که بر روی آنها انجام شده، در زمان وقوع رخدادهای بخصوصی با استفاده از پیغام های Syslog موضوع را اطلاع رسانی می کنند. در واقع نرم افزار مانیتورینگ درخواستی ارسال نمی کند و این خود تجهیزات هستند که در مواقع لازم پیغام ارسال می کنند.
اجزاء یک Syslog Server پیشرفته
استفاده از Syslog روشی مناسب برای جمع آوری و متمرکز سازی لاگ ها از همه تجهیزات شبکه است، به طور معمول همه سرورهای Syslog دارای چند جزء اصلی هستند:
- Syslog Listener: یک Syslog Server باید بتواند پیغام های سیسلاگ را از طریق شبکه دریافت کند، بنابراین در این سیستم ها یک پروسه همیشه برای دریافت پیغام های سیسلاگ گوش فرا می دهد. پیغام های Syslog به طور پیش فرض بر روی پورت 514 و پروتکل UDP ارسال می شوند، پس از آنجایی که از پروتکل UDP استفاده می شود، گارانتی برای تحویل پیغام به مقصد وجود ندارد. به همین دلیل هم برخی از تجهیزات از پروتکل TCP و پورت 1468 برای اطمینان از دریافت پیغام های Syslog استفاده می کنند.
- A Database: در شبکه های بزرگ حجم زیادی از لاگ تولید می شود، لذا نرم افزار های Syslog Server پیشرفته از یک پایگاه داده متمرکز برای نگه داری لاگ ها و دسترسی سریع به لاگ های ذخیره شده استفاده می کنند.
- Management and Filtering Mechanism: به دلیل آنکه در بیشتر مواقع حجم لاگ های دریافتی در یک شبکه زیاد است، جستجو و یافتن یک لاگ بخصوص ممکن است بسیار طاقت فرسا باشد. بنابراین نرم افزار های پیشرفته مانیتورینگ لاگ مانند سیستم مانیتورینگ بینا، امکانات مفیدی را در اختیار شما قرار می دهند تا در کوتاه ترین زمان به اطلاعات مورد نظر خود دسترسی پیدا کنید.
- Alerting Module: یک Syslog Server خوب دارای امکاناتی برای ارسال اخطار به مسئولان شبکه است، تا طبق تنظیمات انجام شده، در صورت دریافت پیغام های با اهمیت با ارسال اخطار افراد مسئول را از موضوع با خبر سازد.
آشنایی با ساختار پیغام های Syslog
سایز هر پیغام Syslog میتواند حداکثر 1024 بایت باشد، و دارای اطلاعات زیر است:
- Facility
- Severity
- Hostname
- Timestamp
- Message
داشتن درک مناسبی از هر یک از این پارامتر ها شما را در راه اندازی و استفاده از نرم افزارهای مانیتورینگ Syslog کمک می کند، در ادامه هر یک از این پارامتر ها را معرفی می کنیم:
شبکه و سرور های خود را زیر نظر بگیرید و بلادرنگ از رخداد ها آگاه شوید.
Facility
یکی از پارامتر های پیغام Syslog به نام Facility، تعیین می کند که لاگ توسط چه نوع سرویس یا نرم افزاری ایجاد شده است. برای مثال بیشتر تجهیزات Cisco از مقدارLocal7 استفاده می کنند. به صورت استاندارد مقدار Facility می تواند یکی از موارد جدول زیر باشد:
| Facility Description | Keyword | Facility Number |
| kernel messages | kern | 0 |
| user-level messages | user | 1 |
| mail system | 2 | |
| system daemons | daemon | 3 |
| security/authorization messages | auth | 4 |
| messages generated internally by syslogd | syslog | 5 |
| line printer subsystem | lpr | 6 |
| network news subsystem | news | 7 |
| UUCP subsystem | uucp | 8 |
| clock daemon | 9 | |
| security/authorization messages | authpriv | 10 |
| FTP daemon | ftp | 11 |
| NTP subsystem | —- | 12 |
| log audit | —– | 13 |
| log alert | —– | 14 |
| clock daemon | cron | 15 |
| local use 0 (local0) | local0 | 16 |
| local use 1 (local1) | local1 | 17 |
| local use 2 (local2) | local2 | 18 |
| local use 3 (local3) | local3 | 19 |
| local use 4 (local4) | local4 | 20 |
| local use 5 (local5) | local5 | 21 |
| local use 6 (local6) | local6 | 22 |
| local use 7 (local7) | local7 | 23 |
Severity
این پارامتر شدت یا به عبارتی اهمیت پیغام Syslog را نشان می دهد، بنابراین در زمان تعریف قواعد Syslog در نرم افزار مانیتورینگ بینا می توانید از این پارامتر برای تعیین بازخورد بینا در زمان دریافت پیغام ها استفاده کنید، به طور استاندارد مقدار Severity می تواند یکی از موارد جدول زیر باشد:
| General Description | Description | Keyword | Severity | Code |
| A “panic” condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call. | System is unusable. | emerg (panic) | Emergency | 0 |
| Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection. | Action must be taken immediately. | alert | Alert | 1 |
| Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection. | Critical conditions. | crit | Critical | 2 |
| Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time. | Error conditions. | err (error) | Error | 3 |
| Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full – each item must be resolved within a given time. | Warning conditions. | Warning(Warn) | Warning | 4 |
| Events that are unusual but not error conditions – might be summarized in an email to developers or admins to spot potential problems – no immediate action required. | Normal but significant condition. | notice | Notice | 5 |
| Normal operational messages – may be harvested for reporting, measuring throughput, etc. – no action required. | Informational messages. | informational | Informational | 6 |
| Info useful to developers for debugging the application, not useful during operations. | Debug-level messages. | debug | Debug | 7 |
برای درک بهتر هر یک از موارد به توضیحات ستون آخر دقت کنید. برای مثال در خصوص تجهیزات Cisco به طور کلی از Severity ها به روش ذیل استفاده می شود:
از سطح Emergency تا سطح Warning برای ارسال پیغام های مربوط به موضوعات سخت افزاری و نرم افزاری استفاده می شود، برای اطلاع رسانی هنگام Restart شدن دستگاه و یا تغییر وضعیت اینترفیس ها (up / down) از سطح Notice استفاده می شود، رویداد Reload با سطح Informational ارسال می شود، و خروجی دستورات debug با سطح debug ارسال می شود.
Hostname
نام و یا آدرس IP سیستم ارسال کننده پیغام Syslog.
Timestamp
زمان ایجاد پیغام Syslog.
Message
متن پیغام Syslog که معمولا توضیحاتی در خصوص رخداد مربوطه ارائه می کند.
نکات مهم
به عنوان یک مدیر فناوری اطلاعات و یا راهبر شبکه باید از یک راهکار پیشرفته برای مانیتورینگ یکپارچه و همیشگی لاگ های شبکه اطمینان استفاده کنید.
یکی از چالش های اساسی در مانیتورینگ لاگ، حجم زیاد داده های ورودی است که در بسیاری از موارد ضروری نیستند، پس هنگام پیکربندی تجهیزات شبکه فقط برای رخداد های حیاتی ارسال پیغام Syslog را فعال کنید.
سوالات متداول
- تفاوت Syslog با SNMP در مانیتورینگ چیست؟
با استفاده از SNMP می توان از تجهیزات شبکه اطلاعات عملکردی را فراخوانی کرد که این عملیات معمولا به صورت متوالی و طبق یک زمانبندی صورت می پذیرد، در این حالت نرم افزار مانیتورینگ در فواصل زمانی کوتاه یک درخواست به دستگاه ارسال کرده و اطلاعاتی مانند فضای دیسک و یا میزان حافظه آزاد را میپرسد، و دستگاه نیز داده های درخواست شده را ارائه می دهد. - ساختار پیغام های Syslog چیست؟
Facility – Severity – Hostname – Timestamp – Message
