در دنیای پردازش ، Syslog استانداردی برای Message Logging است. همچنین logfile ، به فایلی گفته می شود که رویدادهای رخ داده در یک سیستم عامل یا نرم افزاری که اجرا می شود و همچنین پیام های بین کاربران را در یک نرم افزار ارتباطی ، ذخیره می کند. Logging نیز به معنای عمل نگه داری یک Log است. در ساده ترین حالت ، این پیغام ها در یک logfile واحد ذخیره می شوند. همان طور که گفته شد ، Syslog یک پروتکل استاندارد است ، بنابراین برای آن RFC تعریف شده است و شماره RFC آن ۵۴۲۴ می باشد. https://tools.ietf.org/html/rfc5424
در بسیاری از دیوایس ها و سیستم عامل ها و نرم افزارهایی که روزانه با آن ها سر و کار داریم ممکن است جهت ثبت رخدادها از پروتکل Syslog به عنوان استاندارد استفاده شده باشد. مانند : روترها ، پرینترها ، دریافت کننده های پیغام یا Message Receivers و … در نتیجه استفاده از یک استاندارد مشخص می توان Logging Data را از سیستم های متفاوت در یک Repository مرکزی گرد هم آورد که به این ترتیب مدیریت و بررسی آن ها آسان گردد.
اجزای سازنده Syslog
اطلاعاتی که توسط یک سازنده Syslog message تولید می شود شامل facility code و severity level است. همچنین اجزایی مانند Process ID سازنده یا Originator ، یک timestamp و آی پی یا آدرس دیوایس نیز برای گیرنده Syslog ارسال می گردد. Facility code به منظور شناسایی نوع برنامه ای که پیغام Log را ذخیره کرده است استفاده می شود. بنابراین با پیغام هایی که Facility Code های مختلفی دارند ، متفاوت برخورد می شود. Facility Code ها نیز در RFC 3164 به آدرس https://tools.ietf.org/html/rfc3164 تعریف شده اند. برای نمونه ، Facility Code صفر ( ۰ ) مربوط به پیغام های Log تولید شده در Kernel می باشد. یا Facility Code دو ( ۲ ) مربوط به لاگ های سیستم Mail می باشد.
در RFC 3164 به غیر از Facility Code ها لیستی از Severity level های متفاوت نیز وجود دارد. همان طور که می دانید Severity level تعیین کننده درجه اهمیت هر Log است. برای مثال درجه Emergency با ارزش صفر بالاترین سطح اهمیت را دارد و به معنای غیر قابل استفاده شدن سیستم می باشد و مشخص است که این لاگ هیچ گاه توسط برنامه ها ( Applications ) تولید نمی شود. باز هم به عنوان نمونه ، درجه Alert با ارزش ۱ ( هرچه ارزش عددی کم تر باشد ، اهمیت لاگ بالاتر است ) مربوط به لاگ رخدادی است که باید خیلی سریع ، رفع شود : مانند قطع شدن ارتباط با ISP اصلی در روترها که جز Alert ها محسوب می شود.
معماری Syslog :
معماری Syslog بسیار ساده است. همان طور که در تصویر مشاهده می کنید دیوایس ها یا برنامه های مختلف Syslog Messages را به سرور Syslog به عنوان یک Central Repository ارسال می کنند. Syslog Server نیز هشدارها را برای مدیران ارسال می کند و Administrator ها نیز در جهت رفع مشکلات گزارش شده عمل می کنند.
چالش های Syslog
اولین ایرادی که ممکن است بتوانید از Syslog بگیرید این است که این پروتکل اصولی را برای فرمت پیغام های خطایی که ارسال می کند به عنوان مرجع ندارد. بنابراین توسعه دهندگان در این خصوص به صورت سلیقه ای عمل می کنند. برای مثال برخی توسعه دهندگان پیغام را با جزئیات و حتی روش تصحیح آن ذکر می کنند و برخی دیگر اهمیتی به خوانایی آن نمی دهند و کاربر مجبور به خواندن داکیومنت های مربوط به نحوه تشخیص علت پیغام خطای آن Developer خاص است.
ایراد دوم استفاده Syslog از پروتکل UDP است. از آن جایی که UDP پروتکلی Connectionless می باشد بنابراین هیچ تاییدیه ای مبنی بر دریافت پیغام توسط Syslog Server به فرستنده پیغام ارسال نمی گردد و در نتیجه گارانتی جهت اطمینان از رسیدن همه پیغام های خطا وجود ندارد و ادمینی که از Syslog Server استفاده می کند ممکن است که بعضی از Log ها را از دست بدهد.
و ایراد آخر اینکه Syslog Message ها Authentication ندارند. در نتیجه می توانید تصور کنید که یک هکر قادر خواهد بود پیغام های Syslog جعلی برای شما ارسال نماید و یا مسائل امنیتی دیگری به وجود آورد.
سازگاری
از جمله نرم افزارهای مانیتورینگی که با Syslog سازگاری دارند می توان از OPManager شرکت ManageEngine’s ، SolarWinds Orion NPM و OpenNMS نام برد. در آینده در مقاله های جداگانه به بررسی کاربر Syslogو نحوه استفاده و Config آن VMware خواهیم پرداخت.
منابع :
