پیاده سازی مفهوم DevOps با OpenShift :

برای بسیاری از سازمان ها، بخش بزرگی از درخواست DevOps، اتوماسیون نرم افزاری است که با استفاده از تکنیک های زیرساختی قابل پیاذه سازی است این کتاب ارائه دهنده ها، معماران، و مهندسین مابقی را با یک گزینه عملی تر ارائه می دهد. شما خواهید آموخت که چگونه یک رویکرد کانتینر از OpenShift می تواند به تیم شما کمک کند تا از طریق نمایه خدمات خود از زیرساخت IT به نرم افزارهای با کیفیت برسید .
🌈🌈🌈سه کارشناس OpenShift در Red Hat توضیح می دهند که چگونه نرم افزار Docker و مدیر خوشه ای Kubernetas را با ابزار توسعه و عملیاتی OpenShift پیکربندی کنید. کشف این که چگونه این پلتفرم مدیریت ظرفیت زیرساختی-اگنوستیک میتواند به شرکتها کمک کند تا به ناحیه تاریک که در آن زیرساختها به عنوان کد پایان مییابد و برنامه های کاربردی از آن شروع شود کمک کند.
در این کتاب می خوانید :
دیدگاه برنامه کاربردی برای اتوماسیون را بدست آورید و درک کنید که چرا مهم است
پیاده سازی خطوط یکپارچه پیوسته با قابلیت Jenkins OpenShift
کاوش مکانیزم برای جداسازی و مدیریت پیکربندی از نرم افزار زمان اجرا استاتیک
یاد بگیرید چگونه با استفاده از قابلیت Open-Shift سفارشی کنید
و ...

درباره نویسندگان
استفانو پیکززینی

استفانو پیکززینی پلت فرم Red Hat را به عنوان یک راه حل سرویس (PaaS) در سراسر استرالیا و نیوزلند هدایت می کند. او متخصص در پلت فرم کانتینر OpenShift Red Hat است.
مایک هپبورن

مایک هپبورن، متخصص موضوع ANZ PaaS در Red Hat، زمینه ای در معماری نرم افزار و ادغام و عملیات میان افزار دارد.
نوئل اوکانر

نوئل اوکانر مشاور و معمار اصلی در Red Hat است. او دارای تجربه گسترده ای در پیشبرد و ارائه پروژه های کلیدی مشتری برای مشتریان Red Hat در سراسر اروپا و مناطق آسیا اقیانوس آرام است.
https://www.dropbox.com/s/sy3iaoh65qke54c/Devops_With_Openshift.pdf?dl=0
#openshift #container #linux #devops @unixmens

سریعتر با #DevOps نوآوری کنید

سازمان های فناوری اطلاعات باید با انعطاف پذیری مواجه شوند و با یکدیگر همکاری کنند تا بتوانند در ارتباط باشند استفاده از فناوری اطلاعات، انتظارات مشتری را تغییر داده است و فناوری اطلاعات باید فرهنگ و فرآیندهای خود را با هم تطبیق دهد تا سریعا برنامه ها و ویژگی های خود را ارائه دهند.

با یک استراتژی کامل DevOps، سازمان ها می توانند تغییرات فرهنگی، فرآیند و پلت فرم مورد نیاز برای پاسخگویی به خواسته های جدید را آغاز کنند. نتیجه یک سازمان فناوری اطلاعات است که می تواند نوآوری کسب و کار را سریعتر ارائه دهد.


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

در واقع devops زیرساخت نیست چیزی نیست که deploy کرده و فراموش کنید.

کلید موفقیت اعتماد است ، فراتر از آن، اجرای DevOps نیازمند تغییر فرایندها و ادغام ابزارهای مناسب است. بسته به سازمان شما، این سفر می تواند چالش برانگیز باشد، اما بازده بسیار زیاد است.
#linux #DevOps #devops @unixmens

#devops @unixmens

#داستان موفقیت :
صنعت: حمل و نقل
منطقه: EMEA
دفتر مرکزی: آمستردام، هلند
اندازه شرکت: 2،093 کارمند در خدمت 63،6 میلیون مسافر در سال
فرودگاه آمستردام Schiphol، فرودگاه چهارم شلوغ اروپا، خواستار بهبود تجربه مسافرتی خود و تبدیل شدن به بهترین فرودگاه دیجیتال شد. برای حمایت از این تغییر، تصمیم گرفت تا چندین سیستم فناوری اطلاعات خود را به ابر تبدیل کند تا انعطاف پذیر، امن و کارآمدتر شود. Schiphol تصمیم به راه حل Red Hat® برای محیط جدید ابر هیبریدی خود کرد که به تیم IT کمک می کند تا به سرعت و به طور موثر خدمات جدید مشتری را گسترش و گسترش دهد.
در واقع Schiphol قصد دارد تا سال 2019 به عنوان اولین فرودگاه دیجیتال تبدیل شود و می خواهد از تجربیات مسافرتی برای مسافران، بهبود هزینه های عملیاتی و همکاری با شرکت های هواپیمایی و سایر سهامداران استفاده کند. Schiphol برای حمایت از هدف خود تصمیم گرفت که برخی از سیستم ها را به یک زیرساخت مدرن و مبتنی بر ابر مجهز کند. "ماخیل آلبرز، هماهنگ کننده برنامه های کاربردی ارشد کاربردی در فرودگاه اسمیتپول، فرودگاه آمستردام، گفت:" ما قادر به مقیاس پذیری کافی از زیرساخت موجود در زیرساختمان نبودیم، بنابراین ما می خواستیم ببینیم چگونه یک ابر ابر شرکتی کمک می کند. "

راه حل: مهاجرت به یک پلت فرم ابر منبع باز

در Schiphol تصمیم به استفاده از بستر کانتینر OpenShift Red Hat برای پلت فرم ابر خود، و همچنین دیگر محصولات Red Hat برای ذخیره سازی، مدیریت، برنامه نویسی API (API) توسعه و مدیریت و ادغام. "در Schiphol، ابتدا و برای اولین بار به نرم افزار منبع باز نگاه می کنیم، که با پشتیبانی می شود. این الزامات Red Hat را در فرآیند جستجو ما قرار می دهد.
صحبت های Schiphol ؛؛ما می توانیم نسخه اجتماعی منبع باز را انتخاب کنیم، اما ما می خواهیم پشتیبانی داشته باشیم، بنابراین نسخه Red Hat را انتخاب کردیم."؛؛
#devops #linux #redhat @unixmens

#داستان موفقیت 2 :
صنعت: مهمانداری
منطقه: شمال امریکا
دفتر مرکزی: دالاس، تگزاس، ایالات متحده
اندازه شرکت: بیش از 900 محل کسب و کار چیلی
درباره شرکت
در واقع Brinker International، Inc.، شرکت Grill & Bar چیلی و ایتالیایی Little Maggiano، در زمینه غذا های استثنایی با تجربه های مهمان نوآورانه دیجیتال تمرکز دارد. Brinker می خواست برای مهمانان خود در برنامه تلفن همراه خود، وب سایت، کیوسک های در رستوران و رستوران ها و غذا های مهماندار آشپزخانه ارائه دهد. با استفاده از راه حل های Red Hat ® ، برینکر یک محیط تجارت الکترونیک را برای پشتیبانی از توسعه سریع و استقرار، مقیاس برای رفع نیازهای ترافیکی و حفاظت از اطلاعات مهمان ایجاد کرد.
برینکر تصمیم به استفاده از فناوری منبع باز با استفاده از نوآوری و انعطاف پذیری لازم داشت. او پلت فرم Red Hat را به عنوان پایه و اساس تجارت الکترونیک جدید خود انتخاب کرده است، که همچنین خدمات جدید دیجیتال Chili را میزبانی می کند. Brinker راه حل Red Hat را برای ذخیره سازی، مدیریت و تجزیه و تحلیل داده ها ادغام کرد. Patra مدیر عامل برینکر می گوید : "ما یک فروشگاه با پلت فرم بسته برای 40 سال بوده ایم." "اما برای این پروژه، ما نمی خواستیم به یک تکنولوژی وابسته باشیم، بنابراین ما شروع به نگاه کردن به منبع باز کردیم. توسعه بسیار نوآورانه در جوامع منبع باز وجود دارد. "

راه حل :
“Red Hat’s software-defined storage solutions
Red Hat Gluster and Red Hat Enterprise Linux
container
#devops #redhat #linux @unixmens

سعی می کنم شرکت ها و بیزینس هایی که از اپن سورس بیزینسش هاشون را سریعتر و قدرتمند تر کردن را معرفی کنم // برای دلگرمی بنده برای این مسیر لطفا کانال را برای دوستان خود معرفی کنید / / با تشکر
با احترامات فراوان
یاشار اسمعیل دخت

کانالی در حوزه اپن سورس ، گنو/لینوکس ، امنیت و ... دوست داشتین عضو بشین یا به دیگران معرفی کنید
@unixmens

انشالا در آینده خواهان ایجاد پادکست برای معرفی متن باز و راهکارهای مبتنی بر أن برای نمونه : راهکار های redhat , ununtu , oracle و ... و دیدی دیگر برای جامعه هستم // معرفی کاربرد تکنولوژیک و چگونگی بهتر کردن جوامع با آن ابزارها // در اینجا سعی میکنم بصورت مشاوره راهکار مبتی بر متن باز را ارایه بدم // که حمایت های شما و فیدبک شما این را ه را برای من آسان تر میکنه // لطفا فید بک های خودتان را برای من ارسال کنید اگر حتی فقط ارسال emoji باشه // این کار باعث میشه بدونم پیغام من به شما عزیزان رسیده .

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

آیا تمایل برای ایجاد پادکست برای مفاهیم گفته شده دارید

بلی – 50
👍👍👍👍👍👍👍 89%

خیر – 6
👍 11%

👥 56 people voted so far.

سوال #چالشی :
ما خواهان محاسبه زمان بوت چند سرور هستیم ٫ چگونه میتوان زمان دقیق فرایند ها را بصورت گرافیکی ایجاد نمود و فهمید برای مثال : سرویس sendmail چقدر زمان برده است برای بوت شدن ؟

پاسخ های خود را میتوانید به @yashar_esmaildokht بفرستید
#چالش @unixmens

#پاسخ : bootchart
البته با systemd-analyse فقط در سیستم هایی که از سیستم دی استفاده میکنند اطلاعات میتوان کسب کرد

سوال #چالشی :
چگونه میتوان فهمید پروسس فلان چقدر io مصرف میکند ؟
یا برنامه هایی که بیشترین io مصرف میکنند شماره پروسس های آن ها را در آورد .
نکته : اطلاعات ۱ روز را بدست آورد


پاسخ های خود را میتوانید به @yashar_esmaildokht بفرستید
#چالش @unixmens

یکی از ویژگی های گنو/لینوکس مفهوم لاگ های آن است // ساختار لاگ در لینوکس و سیستم های یونیکس بیس سرویس بیس می باشد یعنی قابلیت ایجاد یک لاگ سرور بصورت کلاسترینگ
در واقع rsyslogd یک دمون برای این منظور می باشد //
اولین پروژه ای که در حوزه Log Manager معرفی شد syslog نام داشت که در سال 1980 شروع شد. این پروژه در واقع پروژه اصلی و هسته اصلی شکل گیری پروتکل syslog بود. در این زمان syslog یک پروتکل بسیار ساده است و هیچ قابلیت خارق العاده ای در آن وجود ندارد و در واقع یک Collector ساده است. در ابتدای پروژه syslog فقط از پروتکل UDP پشتیبانی می کرد که هیچ گارانتی و تضمینی برای رسیدن بسته های اطلاعات از مبدا به مقصد را به کاربر نمی داد. Syslog در واقع log manager پیشفرض اکثر توزیع های سیستم عامل لینوکس است و بعضا آن را به عنوان syslogd هم می شناسند. این پروتکل بسیار ساده و انعطاف ناپذیر بود. اما در سال 1998 پروژه جدیدتری به نام syslog-ng معرفی شد که مکمل syslog بود ، این پروژه جدید قابلیت ها و امکانات جدیدی به syslog قدیمی اضافه کرد که مهمترین های آنها به شرح زیر می باشند :

قابلیت فیلتر کردن محتوای syslog message ها
قابلیت log برداری مستقیم داخل یک پایگاه داده
امکان استفاده از پروتکل های TCP برای انتقال
امکان رمزنگاری TLS در انتقال داده ها

اما در سال 2004 نسل بعدی syslog معرفی شد که به عنوان rsyslog معروف است ،این نسخه پیشرفته syslog و syslog-ng بود و قابلیت هیا زیادی را پشتیبانی می کرد ، جالب اینجاست بدانید که محتویات فایل syslog.conf عینا اگر در فایلrsyslog.conf اگر قرار بگیرند کار می کنند و فایل تنظیمات آنها یکسان است. rsyslog هم موارد زیر را به پروتکل قبلی اضافه کرد :

پشتیبانی از پروتکل RELP
پشتیبانی از عملیات های Buffer شده
امکان اعمال محدودیت های آدرس IP برای Source و پورت
امکان وارد کردن ماژول های نرم افزاری

خوب امروزه می توانیم ادعا کنیم که سه پروژه فعال در حوزه مدیریت log در سیستم عامل ها وجود دارد که همزمان در حال فعالیت هستند و فقط نسخه های مختلفی دارند. امروزه شما حق انتخاب دارید و می توانید با استفاده از موارد گفته شده پروتکل و پروژه مورد نظر خودتان را انتخاب و از آن استفاده کنید تنظیمات این پروژه ها بسیار ساده و بعضا بسیار شبیه به هم هستند و فقط برخی قسمت های کوچک تفاوت هایی دارد ، در آزمون بین المللی LPIC1 با اینکه rsyslog در اکثر توزیع های لینوکس استفاده می شود همچنان سئوالات از تنظیمات syslog سرور مطرح می شوند.

مکانیزم کاری تمامی Log Manager ها یکسان است ، آنها از همه مواردی که برای آنها تعیین می شود در محل مورد نظر لاگ برداری می کنند ، ما نوع لاگ ها را با مفهومی به نام facility مشخص می کنیم که در هر سه نسخه تقریبا یکسان است و به یک شکل تعریف می شود ، برای مثال تمامی لاگهای سرویس های ایمیل توسط facility ای به همین نام برداشته می شود ، قسمت بعدی مشترک در بین این log manager ها قسمت severity level یا priority است که اولویت و درجه اهمیت یک log را مشخص می کند که در برخی نسخه ها بصورت عدد و در برخی بصورت کلمات نمایش داده می شود ، برای مثال عدد 0 یعنی مشکل با درجه بالا ( والا ... دقیقا اگر چنین عددی در priority های syslog دیدید یعنی فاجعه داشتید ) و عدد 7 یعنی بیخیال مشکلی نیست برای اینکه دیدم بیکاری برات پیام دادم. در نهایت قسمت سوم از هر مجموعه log manager محل ارسال و ذخیره لاگ است که هم می تواند یک دایرکتوری بصورت local باشد و هم اینکه تمامی موارد به یک syslog server تحت شبکه می تواند ارسال شود
در محیط های واقعی ما از ابزارهای مانیتورینگ تخصصی برای جمع آوری Syslog ها استفاده می کنیم که مدیریت آنها را بسیار ساده می کنند از جمله آنها می توانیم به ManageEngine OPManager ، Solarwinds Orion NPM و OpenNMS و log analytics و piwiki و ... اشاره کرد .
که در پست های بعدی به آن ها اشاره خواهم نمود
#linux #log #rsylog @unixmens

بصورت معمول اجزای تشکیل دهنده syslog سرور که معمولا در اکثر سیستم ها مشترک هستند به شرح زیر می باشند :

مفهوم Syslog Listener : یک Syslog Server به این نیاز دارد که پیام هایی که تحت شبکه ارسال می شوند را به درستی دریافت کند. فرآیند Listener اطلاعات مربوط به log های Syslog را بر روی پورت شماره 514 که بصورت UDP هم هست و در شبکه ارسال می شوند را دریافت می کند در واقع می توان از Listener به عنوان دریافت کننده پیام های Syslog در شبکه نام برد. همانطور که می دانید بسته های اطلاعاتی UDP و البته پیام هایی که بصورت UDP ارسال می شوند هیچ تضمینی ندارند که قطعا به مقصد می رسند و acknowledge یا تاییده دریافت شدن در مقصد را نیز دریافت نمی کنند ، بنابراین به این موضوع توجه کنید که برخی از تجهیزات شبکه برای اینکه مطمئن شوند اطلاعات Syslog آنها به درستی به مقصد می رسند به جای استفاده کردن از 514 UDP از پورت 1468 TCP استفاده می کنند . برای راه اندازی یک syslog server حتما توجه کنید که دستگاه یا سیستم عامل مورد نظر از چه شماره پورتی و بصورت UDP یا TCP اطلاعاتش را منتقل می کند تا این پورت ها در فایروال های شبکه باز شوند.
مفهوم Database یا پایگاه داده Syslog : درست است که اطلاعات مربوط به لاگهای هر سیستم با توجه به ماهیت text آنها کم به نظر می رسد اما زمانیکه در خصوص شبکه های بسیار بزرگ و تعداد تجهیزات زیاد صحبت می کنیم حجم این داده ها می تواند بسیار بسیار زیاد شود. Syslog سرورهای معمولی دارای پایگاه داده یا Database نیستند و نمی توانند این حجم اطلاعات را درون خودشان بصورت ساختارمند نگهداری کنند اما Syslog سرورهای قدرتمند برای نگهداری این حجم از داده برای خودشان دارای یک Database می باشند.
نرم افزار مدیریت و فیلترینگ : با توجه به اینکه ممکن است مقادیر بسیار زیادی از داده ها در دیتابیس Syslog Server ذخیره شده باشد ، پیدا کردن یک log خاص در بین این همه داده کار بسیار طاقت فرسا و خسته کننده ای خواهد بود. راهکار این مشکل استفاده از یک Syslog سرور است که توانایی مرتب سازی و البته فیلتر کردن log ها را داشته باشد و بتواند بر اساس نیاز شما بر روی لاگها جستجو انجام بدهد. یک Syslog سرور بایستی بتواند در موارد تعریف شده و در صورت بروز مشکل Alert یا اخطار تولید کند و این Alert بر اساس لاگهایی که مدیر شبکه تعریف می کند تهیه و ارسال می شوند ، Alert و Notification جزء جدانشدنی Syslog سرور هستند. این موارد به مدیر شبکه کمک می کنند تا در صورت بروز مشکل بلافاصله بتواند به آن رسیدگی کند.
#linux #log #syslog #rsylog @unixmens

بصورت مفصل در خصوص ساختار syslog و همچنین نسخه های مختلفی syslog صحبت کردیم و اشاره کردیم که ساختار syslog تغییر نکرده است و مفاهیم facility و priority همانی هست که بوده است و تغییر نکرده است اما امروزه به جای استفاده از syslog از rsyslog استفاده می شود و در اکثر توزیع های لینوکس شما دیگر چیزی به نام syslog را مشاهده نمی کنید. امروز می خواهیم به شما نحوه فعال کردن و استفاده از rsyslog برای ارسال کردن log ها به یک سرور دیگر و یا دریافت کردن log از سرورهای دیگر را آموزش بدهیم که ما آن را به عنوان remote logging می شناسیم.
هم در لینوکس های خانواده RedHat و هم در توزیع های Debian قابل استفاده است هر چند در نسخه های مختلف ممکن است کمی تفاوت داشته باشد به هر حال مواردی که امروز آموزش می بینیم به شرح زیر می باشد :

چگونه با استفاده از rsyslog قابلیت remote logging را فعال کنیم ؟
چگونه به سیستم عامل بگوییم که remote syslog message ها را دریافت و قبول کنند ؟
چگونه با استفاده از rsyslog برای یک سیستم دیگر در شبکه syslog ارسال کنیم ؟

خوب قبل از اینکه کاری کنید بایستی مطمئن بشوید که شما rsyslog را روی سیستم نصب شده دارید برای اینکار در سیستم عامل های خانواده RedHat دستور زیر را وارد کنید :

# yum install rsyslog

خوب در مرحله اول ما بایستی به rsyslog بگوییم که بتوان remote log ها را با استفاده از پورت TCP قبول کند و به همین دلیل بایستی فایل تنظیمات rsyslog به آدرس etc/rsyslog.conf/ را باز می کنیم و به دنبال مقادیر زیر می گردیم و آنها را از حالت comment خارج می کنیم ، اگر مقادیر زیر وجود ندارند بایستی بصورت دستی در فایل مربوطه وارد شوند که اینکار معمولا در توزیع های قدیمی تر خانواده RedHat نیاز است :

$ModLoad imtcp
$InputTCPServerRun 514

خوب بعد از اینکه تغییرات بالا را در فایل rsyslog.conf ذخیره کردیم از فایل خارج شده و سرویس rsyslog را با استفاده از دستور زیر restart می کنیم :

[root@server1 ~]# service rsyslog restart

در توزیع های قدیمی تر لینوکس ابتدا بایستی سرویس syslog را stop کرده و سپس مطابق دستور زیر سرویس rsyslog را restart کنید :

[root@server1 ~]# service syslog stop
[root@server1 ~]# service rsyslog restart

خوب تا اینجا rsyslog server ما فعال شده و قابلیت دریافت rsyslog message ها بر روی پورت TCP را دارد ، اما ما باید تنظیماتی را بر روی کلاینت هایی که قرار هست rsyslog message بفرستند هم انجام بدهیم تا پیام های خودشان را به سمت سرور ارسال کنند ، برای اینکار شما مجددا اینبار روی لینوکس کلاینتی که دارید بایستی همان فایل rsyslog.conf که در مسیر قبلی قرار دارد را باز کرده و در انتهای فایل خطوط زیر را وارد کنید :

# remote host is: name/ip:port, e.g. 172.20.16.1:514, port optional
#*.* @remote-host:514
*.* @@10.10.10.1:514

خوب دستور بالا به این شکل تحلیل می شود که هر نوع facility با هر نوع priority رو برای آدرس IP به شماره 10.10.10.1 روی پورت 514 از نوع TCP ارسال کن ، دقت کنید که نماد @@ یعنی TCP در اینجا و اگر یک @ باشد یعنی UDP که در ادامه در این خصوص آموزش می دهیم ، اگر قرار هست که فقط یک نوع خاص از facility ها را منتقل کنید دستور به شکل زیر وارد می شود :

*.info @@10.10.10.1:514

دستور بالا تمامی facility ها را به همراه priority حالت info و بالاتر را برای ادرس IP تعریف شده ارسال می کنند ، بعد از انجام شدن تغییرات ذکر شده بایستی مجددا سرویس rsyslog را در کامپیوتر کلاینت restart کنیم ، برای اینکار دستور زیر را وارد می کنیم :

[root@server2 ~]# service rsyslog restart

در توزیع های قدیمی تر لینوکس ابتدا بایستی سرویس syslog را stop کرده و سپس مطابق دستور زیر سرویس rsyslog را restart کنید :

[root@server1 ~]# service syslog stop
[root@server1 ~]# service rsyslog restart

خوب در حال حاضر هر syslog message ای بر روی server1 ما ایجاد شود در قالب TCP به server2 ارسال خواهد شد و server2 هم پذیرای این مسئله خواهد بود ، اما همیشه پیام های ما TCP نیستند و ما می توانیم پیام های UDP نیز ارسال کنیم ، برای اینکه کاری کنیم که پیام های UDP نیز ارسال و دریافت شوند مجددا بر روی server2 وارد شده و فایل rsyslog.conf را باز می کنیم اینبار دنیال مقادیر زیر می گردیم و آنها را از حالت Comment خارج می کنیم :

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

بعد از اینکه تغییرات بالا را ذخیره کردیم از فایل مورد نظر خارج شده و سرویس rsyslog را یکبار restart می کنیم :

[root@server1 ~]# service rsyslog restart

خوب حالا از server2 خارج شده و روی سرور کلاینت یا server1 می رویم و مجددا فایل rsyslog.conf را باز می کنیم و مقادیر زیر را در انتهای فایل وارد می کنیم :

# remote host is: name/ip:port, e.g. 172.16.1.1:514, port optional
#*.* @remote-host:514
*.* @10.10.10.1:514

خوب دستور بالا به این شکل تحلیل می شود که هر نوع facility با هر نوع priority رو برای آدرس IP به شماره 10.10.10.1 روی پورت 514 از نوع UDP ارسال کن ، دقت کنید که نماد @ یعنی TCP در اینجا و اگر دو @@ باشد یعنی TCP ، اگر قرار هست که فقط یک نوع خاص از facility ها را منتقل کنید دستور به شکل زیر وارد می شود :

*.info @10.10.10.1:514

دستور بالا تمامی facility ها را به همراه priority حالت info و بالاتر را برای ادرس IP تعریف شده ارسال می کنند ، بعد از انجام شدن تغییرات ذکر شده بایستی مجددا سرویس rsyslog را در کامپیوتر کلاینت restart کنیم ، برای اینکار دستور زیر را وارد می کنیم :

[root@server2 ~]# service rsyslog restart

خوب حالا کار ما تقریبا تمام شده است ، ما کاری کردیم که هر نوع syslog message ای از هر نوع facility و با هر درجه priority از server1 به سمت server2 منتقل شود. حالا نوبت آن است که اینها را تست کنیم ، برای تیت کردن تنظیمات ما از server1 با استفاده از دستور logger می توانیم بصورت دستی ثبت log کنیم که در server2 ثبت خواهند شد ، به دستور پایین دقت کنید :

[root@server1 ~]# logger This is www.tst.com

حالا بر روی server2 که rsyslog server ما هست وارد قسمت messages در مسیر زیر می شویم و پیام بالا را مشاهده می کنیم :

[root@server2 ~]# tail /var/log/messages
Dec 25 00:00:01 server2 root: This is www.tst.com

خوب همانطور که مشاهده می کنید log ها به سمت سرور مورد نظر ارسال شده اند ، دقت کنید که محل قرارگیری log ها در سرور syslog بستگی به نوع log دارد ، طبیعی است که در این شرایط خاص log های ما در قسمت messages قرار خواهد گرفت. شما زمانیکه از یک روتر استفاده می کنید و اندازه حافظه داخلی آن کم است می توانید از syslog برای لاگ برداری استفاده کنید
#linux #log #syslog #rsylog @unixmens

نکته : rsyslog نسخه ویندوزی هم دارد که میتوانید در سیستم های ویندوزی نصب کنید
https://www.rsyslog.com/windows-agent/event-log-format-windows-agent/
https://www.winsyslog.com/
#log #syslog #rsylog @unixmens

نکته : خود وبسایت rsyslog بخشی برای ایجاد ساختار کانفیق rsyslog بصورت ویزاردی دارد
https://www.rsyslog.com/rsyslog-configuration-builder/
#log #syslog #rsylog @unixmens

#linux #log #syslog #rsylog @unixmens

نکته : پلاگین های مربوط به rsyslog را می توانید از این بخش استفاده کنید :
https://www.rsyslog.com/plugins/
#linux #log #syslog #rsylog @unixmens