پیکربندی و اجرا کردن توسط داکر برای سه پلتفرم
grafana,telegraf,influxdb

که با اجرا کردن اون میتونید راحت هر سه تا پلتفرم و اپلیکیشن رو راحت و یکجا بالا بیارید

تنظیمات و‌توضیحات مربوط به nginx رو هم براتون گذاشتم

https://github.com/CodeCrafters-ir/sysadmin_monitoring

#devops
#monitoring


@code_crafters

برای بررسی لاگ‌ها در سرور معمولا دو ابزار قدرتمند وجود دارد grafana loki و ELK

در ریپوی مربوط به grafana که در گیتهاب کانال با عنوان sysadmin_monitoring موجود می باشد، loki رو داکرایز کردیم و با ابزارهای دیگه و پلتفرم‌های دیگه میتونید بالا بیارید

در این ریپو هم ELK رو داکرایز و کانفیگ کردم
که با کلون کردنش میتونید ازش استفاده کنید یک فایل زیپ شده هم برای تمرین و تست گذاشتم براتون

خب بین دو پلتفرم loki و ELK کدوم رو اسفاده کنیم؟؟؟
پلتفرم loki برای پروژه‌های متوسط و سرورهای معمولی مناسب هست ELK هم برای سیستم‌های بزرگ و معمولا میکروسرویسی

خود ELK مخفف elastic logstash kibana هستش

لینک ریپو رو در زیر براتون گذاشتم

https://github.com/CodeCrafters-ir/ELK.git


#devops
#monitoring

@code_crafters

#مقیاس_پذیری و چالش های آن - پارت 1
Horizontal & Vertical #Scaling ⚖️

زمانی که فرآیند تولید نرم افزار به مرحله Production می‌رسد و اپلیکیشن روی سرور می‌رود، چالش‌ها و مخاطرات جدیدی برای صاحبان آن ایجاد می‌شود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا می‌کند.
زمانی فرا می‌رسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی می‌رسد که سیستم نمی‌تواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرم‌افزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)

بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به‌ مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها،‌ مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.

یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.

فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس‌ و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.

به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.

علاوه بر همزمانی، حفظ یکپارچگی داده ها و جلوگیری از بروز رفتارهای نادرست در سیستم بسیار مهم است.

در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.

بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems

#مهندسی_نرم‌افزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure

@csharpfriends @Code_Crafters

در DevOps، مفهوم "ناک" (NOC: Network Operations Center) به تیم یا مرکزی اشاره دارد که وظیفه نظارت، مدیریت و رفع مشکلات زیرساخت‌های شبکه و سرویس‌های یک سازمان را دارد. ناک‌ها به بررسی و پاسخ‌دهی به حوادث و رخدادهای مختلف در سیستم‌ها و شبکه‌ها می‌پردازند تا اطمینان حاصل شود که سرویس‌ها به درستی کار می‌کنند و در صورت بروز هرگونه مشکل، سریعاً حل می‌شوند.

درجه‌بندی ناک‌ها در دواپس به سطح خدمات و مهارت‌های فنی تیم‌های ناک بستگی دارد. برخی از سطوح و تقسیم‌بندی‌های معمول عبارتند از:

1. ناک سطح 1 (L1 یا Frontline Support):
- این تیم اولین نقطه تماس برای مشکلات گزارش‌شده است.
- وظایف اصلی این سطح شامل نظارت بر سیستم‌ها و شبکه، بررسی اولیه مشکلات، و حل مسائل ساده و روزمره است.
- معمولاً مشکلاتی مانند ری‌استارت سرویس‌ها، بررسی لاگ‌های پایه، یا پیکربندی‌های ابتدایی در این سطح حل می‌شوند.
- اگر مشکلی در این سطح حل نشود، به سطح بعدی منتقل می‌شود.

2. ناک سطح 2 (L2 یا Advanced Support):
- این سطح با تخصص بیشتری در ارتباط با مشکلات فنی درگیر است.
- مشکلات پیچیده‌تر که نیاز به تجزیه و تحلیل بیشتر دارند (مانند بررسی عمقی لاگ‌ها، کار با ابزارهای پیشرفته‌تری مانند مانیتورینگ‌های پیچیده‌تر) به این تیم ارجاع داده می‌شود.
-در L2 همچنین ممکن است با مسائل زیرساختی یا تنظیمات شبکه‌ای پیچیده‌تر مانند مشکلات سرورهای مجازی یا کلاسترهای Kubernetes سر و کار داشته باشد.
- در صورت عدم توانایی حل مشکل در این سطح، مشکل به L3 ارجاع می‌شود.

3. ناک سطح 3 (L3 یا Expert Support):
- این تیم از متخصصان بسیار ماهر و دارای تجربه‌های پیشرفته در زمینه دواپس و شبکه تشکیل شده است.
- مشکلاتی که در سطوح پایین‌تر حل نشده‌اند یا نیاز به تغییرات ساختاری، تنظیمات بسیار پیچیده و یا کدنویسی دارند، در این سطح رسیدگی می‌شوند.
- تیم‌های L3 ممکن است با مهندسان نرم‌افزار، توسعه‌دهندگان، یا تیم‌های معماری زیرساخت برای حل مشکلات به صورت مستقیم کار کنند.
- در این سطح، مسائل ممکن است به راهکارهای دائمی، اصلاحات سیستمی یا تغییرات در کد پایه نیاز داشته باشند.

4. ناک سطح 4 (L4 یا External Vendor Support):
- در برخی موارد نادر، مشکلات ممکن است خارج از کنترل داخلی سازمان باشد و نیاز به همکاری با تأمین‌کنندگان خارجی (مانند سرویس‌دهندگان ابری یا تولیدکنندگان نرم‌افزار) داشته باشد.
- این سطح به مواردی می‌پردازد که نیاز به پشتیبانی فنی از سوی شرکت‌های تأمین‌کننده یا شرکای تجاری دارند.

این درجه‌بندی‌ها به تیم‌های DevOps کمک می‌کند تا با تقسیم وظایف و مدیریت کارآمدتر، بهترین پاسخ را به مشکلات بدهند و از پایداری و کیفیت سرویس‌ها اطمینان حاصل کنند.

#devops
#k8s

@code_crafters