یکی از ویژگی های گنو/لینوکس مفهوم لاگ های آن است // ساختار لاگ در لینوکس و سیستم های یونیکس بیس سرویس بیس می باشد یعنی قابلیت ایجاد یک لاگ سرور بصورت کلاسترینگ
در واقع 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

خوب حالا از 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

نکته : با استفاده از log analyzer میتوانید rsyslog را بصورت تحت وب استفاده کنید
https://loganalyzer.adiscon.com/
#linux #log #syslog #rsylog #loganalyzer @unixmens

#linux #log #syslog #rsylog #loganalyzer @unixmens

استخدام کارشناس DevOps


حداقل سابقه کار
کمتر از سه سال
حقوق
حقوق از ۱۲,۰۰۰,۰۰۰ تومان

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



توانمندی در حوزه Dev/Ops,Sys/Ops


· تسلط بر سیستم عامل لینوکس


· مسلط به Docker, Kubernetes و Swarm


· تسلط به پیاده سازی CI/CD مانند Jenkins، Travis-CI، TeamCity و Git


· تجربه در پیکربندی IIS، Nginx و Apache


· داشتن دانش و توانایی در پیکره‌بندی بهینه پایگاه داده و نگهداری آن مانند: SQLServer، Redis، MongoDB و ...


· آشنا با Bash/ Python


· آشنا با ابزارهای لاگ گیری مانند ELK


· آشنا با تکنولوژی های میکرو سرویس مانند RabbitMQ، Kafka و ...


· آشنا با Monitoring Tools


· آشنا به پیاده سازی روش های Backup


· توانایی در آنالیز ریسک و ارائه راهکارهای کاهش و مدیریت ریسک


· درک قوی از مفاهیم بنیادی شبکه، TCP/IP و سرویس‌های وابسته‌ی به آن


· تجربه کاری با فایروال‏های نرم ‏افزاری و سخت افزاری


· توانایی اسکریپت ‌نویسی جهت خودکار‌سازی وظایف بر بسترهای لینوکس


توانمندی های فردی


· روحیه‌ی اشتراک‌گذاری دانش، تعامل، مستند سازی، مسئولیت پذیری و کار تیمی


· تسلط به زبان انگلیسی


· روحیه تحقیق و بروز کردن دانش فردی در حوزه های تخصصی


· روحیه یادگیری مداوم


مهارتهای امتیازی


· آشنایی با ابزارها و راهکارها در زمینه کلان‌ داده مثل Hadoop, MapReduce, Redis, Kafka, Zookeeper


· تجربه پیاده سازی برنامه‌های Micro Service


· تجربه پیاده سازی برنامه با معماری DDD


· تجربه قابل توجه در کار با سیستم‌های لینوکسی و اسکریپت نویسی


· آشنایی با بسترهای راه‌اندازی Docker, Kubernetes


· آشنایی با فریم وورک WSO2


· آشنایی با مفاهیم توسعه چابک به ویژه اسکرام


توضیحات:


امکان نوع همکاری بصورت تمام وقت (حضوری یا دورکاری)، نیمه وقت و پروژه ای میسر است.


نیروهای تمام وقت بصورت حضوری یا دورکاری بیمه کامل خواهند شد.


شروع پروژه از فروردین ماه 1400 خواهد بود.


محل شرکت میدان هفت تیر است.


بعد از ارسال رزومه، از طرف شرکت با شما تماس گرفته خواهد شد و جهت مصاحبه دعوت به عمل خواهد آمد.



معرفی شرکت
حوزه فعالیت شرکت در طراحی و توسعه سامانه های عمومی و تخصصی مخابرات حوزه تلکام می باشد.

https://www.karashap.ir/


#jobs #linux #devops #monitoring #backup #sys_admin #log

@unixmens

در مورد Zen Discovery باید گفت که یک ماژول هماهنگ‌سازی کلاستر (Cluster Coordination Module) است که سه وظیفه اصلی دارد:

کشف نودها (Node Discovery)
پیدا کردن سایر نودها و ساختن یک View کامل از کلاستر.

انتخاب Master (Master Election)
تضمین اینکه در هر لحظه فقط یک Master فعال وجود دارد.

انتشار وضعیت کلاستر (Cluster State Publishing)
همگام‌سازی وضعیت بین همه نودها.

ا Zen چیست؟

در Elasticsearch، Zen Discovery مکانیزم اصلی برای:

پیدا کردن نودها (Node Discovery)

هماهنگی بین آن‌ها

انتخاب Master Node

حفظ سازگاری کلاستر

در نسخه‌های قدیمی (تا ۶.x) این مکانیزم Zen1 نام داشت. از Elasticsearch 7.x به بعد، Zen2 معرفی شد.
2. چرا Zen2 ایجاد شد؟

مشکل Zen1:

فرآیند انتخاب Master طولانی و پرخطا بود.

در شرایطی که بخشی از کلاستر قطع می‌شد، Split-Brain (دو Master همزمان) رخ می‌داد.

مدیریت Quorum (اکثریت نودها) سخت و مستعد مشکل بود.

بهبودهای Zen2:

پروتکل هماهنگ‌سازی جدید برای انتخاب سریع‌تر و امن‌تر Master.

جلوگیری قطعی از Split-Brain با استفاده از Voting Configuration.

ا Bootstrap Process شفاف و امن برای شروع کلاستر.

3. معماری Zen2

ا Zen2 در سه بخش اصلی کار می‌کند:

Discovery

پیدا کردن نودها با مکانیزم‌هایی مثل unicast, cloud, یا file-based.

همه نودها یکدیگر را می‌شناسند و وضعیت را به‌روز می‌کنند.

Master Election

ا استفاده از Voting Configuration (مجموعه نودهایی که حق رأی دارند).

ا برای انتخاب Master نیاز به Quorum (اکثریت) است.
مثلا اگر ۳ نود Master-eligible داشته باشیم → حداقل ۲ نود باید توافق کنند.

Cluster State Publishing

ا Master انتخاب‌شده تغییرات Cluster State را به همه نودها ارسال می‌کند.

ا State شامل اطلاعات شاردها، ایندکس‌ها، تنظیمات و وضعیت نودهاست.

مزایای Zen2

ایمنی در برابر Split-Brain
چون هیچ Master جدیدی بدون Quorum شکل نمی‌گیرد.

سرعت بالاتر انتخاب Master
حتی در شرایط قطعی شبکه.

Bootstrap امن
باید لیستی از نودهای Master-eligible اولیه مشخص شود تا کلاستر به‌درستی شروع کند:

cluster.initial_master_nodes:
- node1
- node2
- node3

ا Voting Configuration خودکار
وقتی نود اضافه یا حذف می‌شود، سیستم Voting به‌روزرسانی می‌شود.

ا Zen2 در OpenSearch

ا چون OpenSearch از Elasticsearch 7.10 فورک شده، Zen2 همان ساختار را حفظ کرده.

ا در نسخه‌های جدید OpenSearch، Zen2 با بهبودهای جزئی و ثبات بیشتر نگهداری می‌شود، ولی اساس کار یکسان است.
نکته مهم طراحی

همیشه تعداد نودهای Master-eligible را فرد (Odd Number) انتخاب کنید تا Quorum بهینه باشد.

برای تحمل خرابی، حداقل ۳ نود Master-eligible نیاز دارید.

در محیط‌های Multi-DC باید مراقب Latency و Quorum باشید.


نسخه‌های Zen

ا Zen1 (تا ES 6.x): مکانیزم قدیمی با مشکلات Split-brain و انتخاب Master کند.

ا Zen2 (از ES 7.x و OpenSearch): بازطراحی کامل برای سرعت، پایداری، و جلوگیری کامل از Split-brain.
معماری Zen Discovery (Zen2)

مراحل بوت‌استرپ (Bootstrap Process)

وقتی کلاستر برای اولین بار راه‌اندازی می‌شود:

باید مشخص کنید کدام نودها Master-eligible هستند:

cluster.initial_master_nodes:
- node1
- node2
- node3

این لیست فقط اولین بار استفاده می‌شود تا Voting Configuration اولیه ساخته شود.

3.2. Node Discovery

Zen از Transport Layer (TCP) استفاده می‌کند تا نودها را پیدا کند.

متدهای رایج:

unicast → با لیست IP/hostname مشخص

Cloud plugins (AWS, Azure, GCP)

File-based seed hosts

پارامتر اصلی:

discovery.seed_hosts:
- node1:9300
- node2:9300

Master Election

الگوریتم انتخاب Master در Zen2 بر اساس Voting Quorum است:

فقط نودهای Master-eligible حق رأی دارند.

یک Master جدید فقط وقتی انتخاب می‌شود که اکثریت (Quorum) در دسترس باشد.

جلوگیری از Split-brain:

اگر Quorum برقرار نباشد، هیچ Master جدیدی انتخاب نمی‌شود.

پارامترهای مهم:

discovery.type: zen
node.master: true
node.data: false

3.4. Cluster State Publishing

وقتی Master انتخاب شد:

تغییرات (مثل اضافه شدن ایندکس یا شارد) در Cluster State ثبت می‌شود.

Cluster State به صورت atomic و versioned به همه نودها ارسال می‌شود.

هر نود فقط آخرین Cluster State معتبر را نگه می‌دارد.


#elasticsearch #log #linux #zen #clustering #elk

@unixmens

بررسی نرخ مربوط به داده و فرمول اختصاص محاسبه تقریبی رم

نسبت به نرخ داده در elasticsearch



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


امید هست ، مورد استفاده ، جامعه It , devops , bigdata کشور قرار گیرد .





پذیرای هرگونه از پیشنهادات و نظرات و انتقادات شما عزیزان میباشم .


#data #elk #elasticsearch #linux #bigdata #log #etl

#yashar_esmaildokht

https://t.iss.one/unixmens