تو این مستند در مورد Observability میخوام صحبت کنم، که قسمت مهمی از مسیر دواپسمون هست و از این پست مسیرش رو استارت میزنیم و سعی میکنم قدم به قدم با هم پیش بریم و چیزای بیشتری رو با هم یاد بگیریم.
خب یه مروری کنیم پستهای قبلی رو:
دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمهدستی واسه تستهامون داشته باشیم.
کامپوننتهای کوبر ( قسمت سوم ) توی این پست کامپوننتهای مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
ورکلودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورکلود کوبر رو بررسی کردیم.
اگه لازم شد کوبر خودش گنده میشه! ( قسمت ششم ) توی این پست در مورد سه نوع ورکلود مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.
نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.
استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.
پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع probe ها توی کوبرنتیز توضیح دادیم.
پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفتهتری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.
اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبههای مختلف امنیت در کوبرنتیز توضیح دادیم.
کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.
دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روشهای مختلفی که داره توضیح دادیم و همچنین تفاوت روشهای مختلف تقسیم منابع در کلاسترها را بررسی کردیم.
مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالشهای مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.
هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگیها و کاربردهاش توضیح دادیم.
سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.
نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.
نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.
نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راهاندازی کنیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
چی هست و چرا لازمه؟
کلا توی دنیای IT و Cloud Computing به توانایی اندازهگیری وضعیت و شرایط کنونی یک سیستم بر اساس دیتایی که تولید میکنه مثل لاگ و متریک و تریس، Observability میگیم. ما با استفاده از Observability میتونیم به شهود برسیم و ببینیم که چهخبره و یا بهتر بگم قراره چه خبر بشه. میتونیم به خوبی بررسی کنیم و از احتمالات و اتفاقات پیشرو جلوگیری کنیم.
هدف آبزرویبیلتی این هست که بدونیم توی محیط های عملیاتی ما چه اتفاقی در عمل داره میافته و بتونیم مشکلات احتمالی رو زودتر تشخیص بدیم تا سیستممون رو کارآمدتر و قابل اطمینانتر کنیم و مشتریهای خوشحال تری داشته باشیم 🙂 در کنار اینکه خودمون هم آسایش و آرامش بهتری خواهیم داشت.
اهمیت آبزرویبیلیتی اینه که بهمون کمک میکنه تا توی سیستم های توزیع شده و بزرگ هم بتونیم بفهمیم که چه خبره، چی کند شده، چی نیاز به بهبود داره یا اصلا بهمون آلرت بده که کجا یه اتفاق بدی افتاده و باید سریعتر قبل اینه مشتری بهمون بگه، خودمون برای اون مشکل کاری کنیم و … .
من میگم Observability یه جورایی چشم و گوش ما توی زیرساختمون هست 🙂 و کمک میکنه که به شهود و بصیرت نسبت به سیستمها و سامانههایی که داریم برسیم. البته این بصیرت با اون بصیرت فرق داره ولی به هر حال میفهمیم که چند چندیم و چی کار باید بکنیم.
چه مزایایی داره و چه کمکی به ما میکنه؟
بهمون کمک میکنه تا تجربه کاربری بهتری رو به مشتری بدیم.
تو کاهش هزینه هامون بهمون کمک میکنه.
توی آنالیز کردن بیزنس مون و توی بحثهای مدیریتی دیتایی که میده بهمون کمک میکنه.
کارایی و پرفورمنس تیم هامون رو بالاتر میبره.
بهمون کمک میکنه تا سریعتر محصولمون رو به مشتری برسونیم یا اصطلاحا تایم تو مارکت رو کم میکنه.
به سوالاتمون در مورد وضعیت و اتفاقات سیستمهامون جواب میده.
توی مانیتور کردن پرفورمنس اپلیکیشن و زیرساختمون کمک میکنه. حالا چه روی ابر باشیم یا سرور خودمون یا از کوبر استفاده کنیم، فرقی نمیکنه.
چطوری یه سیستم رو Observable کنیم؟
اصول Observability:
Metrics:
متریکها دیتا و مقادیری هستن که به صورت اعداد و ارقام محاسبه شده یا تجمیع شده در یک بازه زمانی، اونها رو نشون میدیم. متریک میتونه از سورسهای مختلفی مثل زیرساخت، هاست هامون، سرویسهای داخلی و خارجی یا پلتفرم کلاد بیاد. متریکها همون مواردی هستن که توی مانیتورینگ اونارو رصد میکنیم.
Traces:
توی تریس ما یه درخواست یا ترنزکشن که سمت سرویس مون میاد رو با دیتیل در لول کد حتی، دنبال میکنیم که به چه شکل توی اپلیکیشن ما مسیرش رو طی میکنه و چجوری سرویسهای ما به هم وصل میشن تا بهش پاسخ بدن. به یه زبان دیگه وقتی یه درخواست به پاسخ میرسه چه اتفاقی تو سیستم میافته.
Logs:
لاگها رکوردهای متنی هستن از اتفاقهایی که توی یک بازه زمانی مشخص توی سیستم ما افتاده، که حالا میتونن به صورت ساختارمند باشن یا اینکه ساختار خاصی هم نداشته باشن. لاگ باید از همهی محیطها به اندازه جمعآوری و نگهداری بشه. تفکیک نویز از اطلاعات توی لاگ اهمیت داره و دستهبندی لاگ هم مساله مهمی هست.
یک نکتهی خیلی مهم:
همونقدر که کم داشتن و نداشتن لاگ و متریک بده، زیاد داشتنش هم خیلی میتونه بد باشه. یعنی چی این حرف؟ ببین شما لاگ و متریک ایجاد میکنید اگر کم باشه تو شهود شما تاثیر داره و دید کمتری به سیستم دارید ولی اگر زیاد هم باشه و کارایی نداشته باشه فقط هزینه براتون ایجاد میکنه. یعنی کلی متریک و لاگ دارید که حجم زیادی گرفته و کاربردی هم نیست و همین براتون خیلی هزینه ایجاد میکنه. برای همین باید تو متریک و لاگ یکم وسواس داشته باشید که چیز اضافی جمعآوری نکنید که حتما براتون هزینهی زیادی در بلندمدت ایجاد میکنه.
فرق Observability و Monitoring چیه؟
توی مانیتورینگ یه سیستم یه سری متریک از سیستم رو میبینیم و اصطلاحا اونو مانیتور میکنیم اما توی آبزرویبیلیتی ما کاری میکنیم که سیستم خودش رو برای ما واضح کنه! تا ما رفتار سیستم رو فارغ از خروجی سیستم و اینکه چطور داره کار میکنه، ببینیم و نحوهی چرخش اطلاعات توی سیستم رو کامل متوجه بشیم. آبزرویبیلیتی به ما کمک میکنه که بتونیم بپرسیم که چرا کار نمیکنه، در حالی که مانیتورینگ فقط بهمون میگه که الان کار نمیکنه! حواستون باشه که این دوتا جایگزین هم نیستن و مکمل هم هستن. یه جورایی مانیتورینگ جزوی از Observability هست.
از چه سورسهایی میتونیم دیتا جمع کنیم؟
یه لیست براتون میذارم که بخشی از چیزایی که میتونیم دیتای اون هارو برای آبزرویبیلیتی جمع کنیم، ببینید.
Network flow data
Virtual servers – VC Logs, ESXi Logs, etc.
Cloud services – AWS data sources such as EC2, EMR, S3, etc.
Docker – logging driver, syslog, apps logs, etc.
Containers & MSAs – container and microservices logs, container metrics and events, etc.
Third-party services – SaaS, FaaS, Serverless, etc.
Control systems – vCenter, Swarm, Kubennetes, etc.
Dev automation – Jenkins, Sonarcube
Infra orchestration – Chef, Puppet, Ansible
Signals for security analytics – DLP, device telemetry, metadata
Signals from mobile devices – product adoption, users and clients, feature adoption, etc.
Metrics for business analytics – app data, HTTP events, SFA/CRM
Signals from social sentiment analytics – analyzing tweets over time
Customer experience analytics – app logs, business process logs, call detail records, etc.
Analytics for service intelligence – ER visits, treatment wait time, RXs, etc.
Message buses and middleware
بر اساس کتاب sre گوگل بهترین استکها و ابزارهای پیشنهادی شامل موارد زیر است:
Jaeger for Tracing
ELK or EFK Stack for Logging
Prometheus Stack for Monitoring
Grafana for Visualizing
در ادامه برخی از استکها که تو زمینهی Observability مطرح هستن رو باهم بررسی میکنیم.
استک Open Telemetry:
چیه و چرا لازمه:
به صورت اختصار بهش OTel میگن. ابزار OTel یک فریم ورک متن باز هست که به دولوپرها و افراد زیرساخت کمک میکنه تا بینش بهتری نسبت به پرفورمنس و رفتار اپلیکیشن داشته باشن.
اپن تلهمتری سعی کرده که یک استاندارد رو برای ابزارهای جمع آوری متریکها و تریس کردن سیستم و مانیتورینگ ارائه بده. اپن تلهمتری توی دنیای مدرن نرم افزارها که به صورت میکروسرویس و ساختارهای توزیع شده هست، نقش مهمی به صورت ارائه یک ساختار متحد و یکپارچهی استاندارد برای Observability توی زبانها و فریم ورکها و استکهای نرم افزاری مختلف، بازی کنه.
دیزاین:
این ابزار به گونهای طراحی شده است که ماژولار، توسعهپذیر، و vendor-agnostic باشد و به کاربران این امکان رو میده تا کامپوننتها و اکسپورترهایی رو انتخاب کنند که به با نیازهاشون مطابقت دارند. OpenTelemetry مجموعهای از API (Application Programming Interface) ها و ( SDK ( Software Development Kit ها را برای برنامهها و جمع آوری دادههای تلهمتری تعریف می کند. این دیزاین قابلیت همکاری میان ابزارها و پلتفرمهای مانیتورینگ مختلف رو ارتقا میده و اکوسیستمی پر جنب و جوش از پلاگینها رو میتونه داشته باشه.
کامپوننتها
SDK & API:
اپن تلهمتری با استفاده از SDK ها کتابخانهها و api هایی رو برای برنامههای مختلف ایجاد میکنه که بتونن متریکها و تریس و اطلاعاتشون رو بهتر استخراج کنن.
Instrumentation libraries:
کتابخانههای از قبل آماده شدهای برای فریم ورکها و استکهای مختلف نرم افزاری که کپچر کردن دیتای تلهمتری رو آسونتر میکنه و حتی بدون نیاز به چنج دستی گاها این کار رو ممکن میکنه.
Collector:
کالکتور کامپوننتی هست که دیتای تلهمتری رو از برنامهها میگیره و اونو پردازش میکنه و برای فرستادن به سیستمهای بک اندی Observability مثل سیستم های لاگینگ، مانیتورینگ و آنالیز آمادهاش میکنه. برخی از ویژگیهای کالکتور شامل موارد زیر هست:
Protocol Agnostic
Data Processing
Plug-in Architecture
Scalability and Reliability
Exporter:
مسئولیت فرستادن دیتای کالکتور به سیستم های بیرونی و استورج ها با اکسپورتر هست. اپن تلهمتری از رنج وسیعی از اکسپورترها پشتیبانی میکنه که Jaeger و Zipkin و حضرت Prometheus جزو اونا هستن.
Context Propagation:
کانتکست یه آبجکت هست شامل اطلاعاتی که بین سرویس ها فرستاده و دریافت میشه و پروپگیشن به مکانیزم جابجا شدن کانتکستها بین سرویسهای سیستم گفته میشه. اپن تلهمتری امکان کورلیشن بین سیگنالها و کانتکست هارو فراهم میکنه.
به نظرم این استک در آینده خیلی حرف برای گفتن داره و خیلی بیشتر ازش خواهیم شنید.
این میشه شروع مسیر Observability ، تو پستهای بعدی به سراغ استکهای دیگه مانیتورینگ و Observability میریم و اونا رو با هم بررسی میکنیم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
