مسیر Observability (قسمت اول)

تو این مستند در مورد Observability می‌خوام صحبت کنم، که قسمت مهمی از مسیر دواپس‌مون هست و از این پست مسیرش رو استارت میزنیم و سعی میکنم قدم به قدم با هم پیش بریم و چیزای بیشتری رو با هم یاد بگیریم.

چی هست و چرا لازمه؟

کلا توی دنیای 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 میریم و اونا رو با هم بررسی می‌کنیم.

مراقب خودتون باشید.