‼️اگر علاقه مند به کار در 💢سنگاپور 💢هستید.
✔️1_بدون هیچ هزینه استخدامی
✔️2-کمک هزینه جابه جا
✔️3-مصاحبه کاری سریع
✔️4-پروسه ویزا در سه هفته

🔴استخدام متخصصین حوزه «آی-تی» و 《برنامه نویسان》 در یک شرکت معتبر تکنولوژی واقع در سنگاپور با بیش از 50 شعبه معتبر در کشورهای آسیای شرقی

senior React Frontend Software Engineer:
https://bit.ly/3a1QDZP
#ES6 #React #Redux #Webpack #JavaScript
Senior Android Engineer
https://bit.ly/36bl6lh
#Android #UI #CCD #Espresso #Bitrise #Firebase
Golang Backend Software Engineer
https://bit.ly/3asiO4n
#SQL #Hexagonal_Architecture #SOLID #Go #Elasticsearch #Microservice_Architecture #Redis #PHP #Symphony2 #AMQP
Senior iOS Engineer
https://bit.ly/368yBSI
#Firebase #Multithreaded_Programming #Core-Graphics #ObjectiveC #CICD #Travis_CI #Xcode #Bitrise #Swift #Fastlane #Testing
more info about Singapore positions at ananasjob international :
https://bit.ly/2PKfSIv



#oversea #سنگاپور #android #singapore


➖➖➖➖➖
🌐 @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

آیا elk یک log management هست یا ابزار مانیتورینگ ؟

پاسخ هردو


در دنیای امروز که سیستم‌ها پیچیده، توزیع‌شده و اغلب مبتنی بر ابر و راهکارهای cloud-native و Microservices هستند، سازمان‌ها بیش از هر زمان دیگری به ابزارهایی برای جمع‌آوری، تحلیل و نظارت بر داده‌ها نیاز دارند. یعنی ورود به مفاهیم و ساختار های data driven.
در این مسیر، استک ELK به‌عنوان یکی از محبوب‌ترین راهکارها برای Log Management و حتی Monitoring / Observability شناخته می‌شود.

اما اگر عمیق تر نگاه کنیم آیا این ابزار صرفاً مدیریت لاگ انجام می‌دهد یا می‌تواند نقش مانیتورینگ را هم ایفا کند؟


در واقع ELK چیست؟

در حقیقت ELK مخفف سه مؤلفه اصلی است:

Elasticsearch → موتور جستجو و پایگاه داده NoSQL برای ذخیره‌سازی و ایندکس‌گذاری لاگ‌ها.

Logstash → ابزار پردازش داده‌ها (ETL) برای جمع‌آوری، فیلتر و انتقال داده.

Kibana → ابزار تجسم داده‌ها (Visualization) و ساخت داشبورد.


نکته : ما نود های مختلفی داریم برای data برای ذخیره‌سازی داکیومنت هاذو شارد ها .
نود master
نود ingest
نود cordinator
نود data که خود این نود هم شامل ساختار ilm هست که به hot 🔥, warm 🥵 , و cold 🥶 را شامل میشود و در ادامه repository برای ذخیره داده های قدیمی تر .

نکته : میتوان در کلاستر از logslash استفاده نکرد و از نود با وظیفه ingest استفاده کرد . البته این دو نود هر کدام نکته های باریک دارند .
بررسی ELK به‌عنوان Log Management :

در ابتدا ELK به‌عنوان یک Log Management Platform معرفی شد:

جمع‌آوری لاگ‌های سیستمی، اپلیکیشنی و شبکه‌ای

پردازش و نرمال‌سازی داده‌ها

ذخیره‌سازی در Elasticsearch

جستجو، تحلیل و ساخت گزارش در Kibana


به همین دلیل ELK معمولاً در کنار ابزارهایی مثل Splunk یا Graylog دسته‌بندی می‌شود.

بررسی ELK به‌عنوان ابزار Monitoring / Observability :

با گذشت زمان و توسعه‌ی ELK، قابلیت‌های آن گسترش یافت:

امکان تعریف Alerting و هشدار (با X-Pack یا Elastic Alerting)

داشبوردهای Real-Time در Kibana

پشتیبانی از APM (Application Performance Monitoring) و Metrics (از طریق Beats مثل Metricbeat)

استفاده در امنیت (Elastic SIEM)


بنابراین ELK از یک Log Management ساده فراتر رفت و به سمت یک پلتفرم Monitoring و حتی Observability حرکت کرد.


در واقع ELK در اصل یک Log Management Platform است.

اما در عمل، با اضافه شدن قابلیت‌های Dashboard، Alerting و APM، و ... به یک Monitoring و Observability Platform نیز تبدیل می‌شود.


بنابراین ELK را می‌توان هم به‌عنوان مدیریت لاگ و هم به‌عنوان ابزار مانیتورینگ در نظر گرفت؛ بسته به اینکه سازمان از آن در چه سطحی و با چه افزونه‌هایی استفاده کند.


#devops #linux #elk #elasticsearch




https://t.iss.one/unixmens

مفهوم Fleet در ELK چیست؟

در واقع Fleet یک ابزار مدیریتی در Elastic Stack است که برای مدیریت متمرکز Agentها طراحی شده.
در واقع، وقتی شما می‌خواهید روی سرورها، کلاینت‌ها یا کانتینرها داده (لاگ، متریک، امنیت، APM و غیره) جمع‌آوری کنی، باید Elastic Agent نصب بشه.
مدیریت دستی تعداد زیادی Agent (نصب، پیکربندی، به‌روزرسانی) سخت می‌شه.
اینجاست که Fleet وارد عمل میشه.

وظایف Fleet چیست ؟

1. مدیریت متمرکز Agentها

از طریق Kibana می‌تونی Agentها رو نصب، پیکربندی و مدیریت کنی.

نیازی نیست روی هر سرور جداگانه تغییرات اعمال کنی.



2. Policy Management

تعریف Policy (مثلاً جمع‌آوری لاگ‌های سیستم، متریک CPU و لاگ‌های Nginx).

این Policy به صورت خودکار روی Agentها اعمال میشه.



3. Data Ingestion ساده‌تر

در Fleet داده‌ها رو از طریق Elastic Agent به Elasticsearch می‌فرسته.

این داده‌ها می‌تونن شامل:

لاگ‌ها (Log Files)

و Metrics (سیستم و اپلیکیشن‌ها)

داده‌های امنیتی (Endpoint Security)

داده‌های APM

باشه .


4. Integration Hub

در Fleet یک Integration Hub وجود داره که ده‌ها Integration آماده برای سرویس‌ها (مثل MySQL, Nginx, Kubernetes, AWS) رو فراهم می‌کنه.

کافیه انتخابش کنیم تا Agent ها تنظیمات مربوطه رو اعمال کنن.



تفاوت Elastic Agent + Fleet با Beats

قبل از Elastic Agent، باید از Filebeat، Metricbeat، Packetbeat و … جداگانه استفاده می‌کردیم.

هر کدوم نصب و تنظیم خودشون رو داشتن.

الان Elastic Agent اومده و همه رو یکپارچه کرده.

و Fleet هم مدیریت مرکزی همین Agentهاست.


مزایای Fleet

مدیریت ساده در مقیاس بالا (ده‌ها یا صدها سرور)

پشتیبانی از Integrationهای آماده

امکان امنیت مرکزی برای Agentها (از طریق Kibana)

جایگزینی مدرن برای Beats

مناسب برای محیط‌های Cloud و Kubernetes خلاصه:
در واقع Fleet یک کنسول مدیریتی متمرکز در Kibana است که برای مدیریت Elastic Agentها استفاده می‌شود.
این ابزار فرآیند نصب، پیکربندی، به‌روزرسانی و مدیریت Policy را ساده می‌کند و عملاً نسل جدید مدیریت داده در ELK به شمار می‌آید.


#elk #linux #security #elasticsearch #kibana


unixmens

https://t.iss.one/unixmens

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

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



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


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





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


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

#yashar_esmaildokht

https://t.iss.one/unixmens