خواندن ۸ دقیقه·۲ ماه پیش

در مسیر Observability، تمپو (قسمت نهم)

در ادامه‌ی پست‌های قبلی تو این پست داریم می‌ریم ابزار Grafana Tempo رو یکم بررسی کنیم و ببینیم چه کمکی به ما می‌کننه.

خب یه مروری کنیم پست‌های قبلی رو:

دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
خودکارش کن، مشکلاتت حل می‌شه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.
در مسیر دواپس این‌بار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویس‌هامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیس‌ها و تجربیات خودم رو گفتم.
تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.
در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.
در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.
در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.
مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپن‌تله‌متری دادیم.
در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.
در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

استک grafana tempo:

چیه و چه کمکی بهمون می‌کنه

یه ابزار اپن سورس برای استفاده به عنوان بک اند tracing حتی توی حجم های بالا، که توزیع شده هست و کار باهاش راحته. توی طراحی گرافانا تمپو افیشنت بودن در نظر گرفته شده و برای کار کردن فقط نیاز به یک آبجکت استورج داره. کاملا با گرافانا و میمیر و پرومتئوس و لوکی سازگاره و میتونید اونو با پروتکل های اپن سورس ترسینگ مثل Jaeger و Zipkin و OpenTelemetry استفاده کنید.

حالا trace اصلا چی هست؟ تریس یه جورایی بهمون مسیر کامل یک درخواست یا یک اکشن که سمت سیستم ما اومده و بین نود های مختلف چرخیده رو نشون میده، مخصوصا برای سیستم های توزیع شده و سیستم های کانتینری و ساختار های میکروسرویسی. تریس بهمون کمک میکنه تا بهتر نحوه عملکرد سیستم و ارتباط اجزاش رو ببینیم و راحت تر بتونیم bottleneck ها و مشکلات ارتباطی بین میکروسرویس هارو رفع کنیم.

تریس ها ترکیب شده‌ی یک یا چنتا span هستن.

به یه دونه واحد کاری توی یک تریس که یک زمان استارت نسبت یه شروع تریس داره و مدتی طول میکشه و یه اسم اجرایی داره میگیم span. معمولا span ها یه رفرنس به span والدشون دارن ( به جز اولین span توی یک تریس) و ممکنه که یه سری اتریبیوت به صورت key/value داشته باشن مثلا متد HTTP که اون span داره یا متادیتایی که اون span رو به یه سری sub-span لینک میکنه و …

کامپوننت‌های استک tempo

Client instrumentation:

توی پایپ لاین ترسینگ همونطور که توی دیاگرام میبینید بلاک اول اینسترومنت هست.
کلاینت نیازمند یک ابزار یا سیستم مرتبط با برنامه‌نویسی و توسعه نرم‌افزار هست که برای ردیابی و پیگیری عملکرد برنامه‌های توزیع‌شده ازش استفاده کنه. وقتی یک برنامه یا سیستم نرم‌افزاری به چندین قسمت یا سرویس مختلف تقسیم می‌شود که روی سرورها یا دستگاه‌های مختلفی در شبکه اجرا می‌شوند، ممکن است برای ردیابی و پیگیری عملکرد و رفتار این بخش‌ها نیاز به یک سیستم یا ابزار داشته باشید که امکان ثبت و نمایش جریان فعالیت‌ها و تراکنش‌ها در سراسر این اجزا را فراهم کند. که فریم ورک های مختلف برای استک های نرم افزاری مختلف وجود دارن تا این کار رو برامون انجام بدن مثلا OpenTelemetry واسه اکثر استک های معروف فریم ورک های خوبی رو داره.

Agent

حالا که تریس از اپلیکیشن در اومده باید یکی اونو بفرسته به استوریج بک اند و میتونید یه پایپ لاین درست کنید که span هارو از اپلیکیشنتون استخراج کنه و اونا رو بافر کنه و بفرسته به بک اند استورج که معمولا برای پیاده سازی های حساس‌تر که پایداری بیشتری نیاز دارن این کار و میکنن و در حالت عادی اکثر کلاینت‌ها قابلیت اینکه مستقیم بفرستن سمت تمپو رو دارن.

Tempo

بک اند ما تمپو هست که کار باهاش راحته و میتونه اسکیل بشه و ازش برای ذخیره و کوئری زدن روی تریس ها استفاده میکنیم.

Grafana

و نهایتا برای نمایش تریس ها گرافانا دیتا سورس تمپو رو به صورت built-in داره و میتونیم ازش استفاده کنیم برای کوئری زدن به تمپو و نمایش تریس ها.

دیزاین و کامپوننت‌‌های داخلی

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

Distributor

دیستریبیوتر span ها رو با فرمت های مختلف میگیره و اونا رو route میکنه سمت ingester ها با استفاه از هش کردن traceID و hash ring.

Ingester

اینجستر تریس ها رو به بلاک تبدیل میکنه و ایندکس و bloom فیلتر میسازه و بعدش اون رو به به بک اند میفرسته.

Query Frontend

مسئولیت شارد کردن فضای سرچ برای کوئری های که میان رو بر عهده داره.

Querier

مسئولیت پیدا کردن traceid درخواست ها توی اینجستر یا استورج بک اند با این کامپوننت هست.

Compactor

وظیفه این کامپوننت حرکت دادن بلاک ها به فضای ذخیره سازی و برگرداندن اونها هست با هدف کم کردن تعداد بلاک ها و بهینه تر کردن فضای ذخیره سازی و کارایی سیستم.

Metrics generator

کامپوننت اختیاری هست که متریک ها رو به metric-generator میفرسته که میتونید در موردش بیشتر بخونید.

توضیح اجمالی Jaeger

جَگِر یه پلتفرم برای tracing هست که Uber Technologies اونو ارائه داده که باهاش میتونید workflow هاتون رو مانیتور کنید و اونها رو ترابل شوت کنید. ابزارهای دیگه ای مثل M3 که دیتابیس تایم‌سریز هست برای پلتفرم متریک توسط همین کمپانی توسعه داده شده که میتونید در موردش بخونید. به کمک Jaeger میشه bottleneck های پرفورمنس رو شناسایی کرد و به کمک ترس ریشه مشکل رو پیدا کرد. در ادامه لیستی از فیچرهای این ابزار رو براتون میذارم: