Jaeger روی ClickHouse سوار شد
خلاصهٔ کامل‌تر
Mahad Zaryab، یکی از نگهدارنده‌های Jaeger، تو بلاگ CNCF نوشته که پشتیبانی از ClickHouse سال‌ها جزو درخواست‌های تکراری کاربرها بوده و حالا با Jaeger v2.18.0 اضافه شده. Jaeger یه پلتفرم تریسینگ توزیع‌شده‌ست که مسیر یه درخواست رو بین سرویس‌های مختلف دنبال می‌کنه تا گلوگاه تأخیر و ریشهٔ خطا معلوم بشه و زمان رفع مشکل (MTTR) پایین بیاد.
به گفتهٔ نویسنده، معماری ClickHouse انگار برای تله‌متری ساخته شده: یه دیتابیس ستونی OLAP که هم جریان نوشتن سنگین رو قورت می‌ده و هم تجمیع‌های تحلیلی رو تو چند میلی‌ثانیه جواب می‌ده. دیتای تریس هم ذاتاً تکراریه — یه اسم سرویس مثل payment-gateway صدها هزار بار تکرار میشه — و چیدمان ستونی همین تکرار رو راحت فشرده می‌کنه. قبلاً Cassandra و Elasticsearch این نقش رو داشتن، ولی سربار ایندکس و هزینهٔ عملیاتی‌شون بالا بود.
سخت‌ترین بخش کار طراحی اسکیما بوده. تو ClickHouse کلید اصلی یه قید یکتایی نیست؛ ترتیب چیدمان روی دیسک رو تعیین می‌کنه و یه ایندکس پراکنده می‌سازه، پس پرتأثیرترین تصمیم اسکیماست. تیم به جای مرتب‌سازی بر اساس trace_id، ترکیب service_name و name و start_time رو انتخاب کرده تا فیلترهای سرویس و عملیات و بازهٔ زمانی مستقیم از ایندکس استفاده کنن.
نویسنده می‌گه این انتخاب از یه معاملهٔ نامتقارن میاد: با مرتب‌سازی بر اساس trace_id، خوندن یه تریس حدود ۲۷ میلی‌ثانیه طول می‌کشید ولی جست‌وجو حدود ۸۸۰ میلی‌ثانیه. با اسکیمای جدید، خوندن تریس رفته روی حدود ۱۰۰ میلی‌ثانیه — کندتر، ولی هنوز کاملاً تعاملی — و در عوض جست‌وجوی چندفیلتری اومده حدود ۱۴۰ میلی‌ثانیه. برای جبران هم یه ایندکس bloom filter روی trace_id و یه materialized view از بازهٔ زمانی هر تریس اضافه شده.
Jaeger v2 مدل دادهٔ OpenTelemetry رو پذیرفته، پس تگ‌ها دیگه فقط رشته نیستن و می‌تونن Bool، Int64، Float64 یا String باشن و تو پنج سطح resource، scope، span، event و link بیان. اسکیما برای هر نوع ستون Nested جدا داره و یه جدول attribute_metadata نگه می‌داره تا موقع کوئری معلوم بشه هر کلید تو کدوم نوع و کدوم سطح دیده شده. نکته اینه که فیلتر روی اتریبیوت به‌تنهایی گرونه و بهتره با سرویس و عملیات و زمان ترکیب بشه.
بنچمارک روی ۱۰ میلیون اسپن از ۱ میلیون تریس و روی یه نود تکی انجام شده: ingest بالای ۵۰ هزار اسپن در ثانیه، فشرده‌سازی ۸.۶ برابر روی جدول اسپن‌ها و کاهش حجم از حدود ۶ گیبی‌بایت به حدود ۷۲۲ مبی‌بایت. نویسنده تأکید می‌کنه این عددها رو باید تو بستر همون بنچمارک خوند. این نسخه متدهای بومی SPM هم داره، یعنی تأخیر و نرخ فراخوانی و نرخ خطای هر سرویس مستقیم از همون اسپن‌ها حساب میشه. پشتیبانی ClickHouse فعلاً آلفاست.
نکات کلیدی:
- بک‌اند ClickHouse از Jaeger v2.18.0 به شکل آلفا در دسترسه
- فشرده‌سازی ۸.۶ برابری روی جدول اسپن‌ها: ~۶ گیبی‌بایت به ~۷۲۲ مبی‌بایت
- ingest بالای ۵۰ هزار اسپن بر ثانیه، خوندن تریس ~۱۰۰ و جست‌وجوی چندفیلتری ~۱۴۰ میلی‌ثانیه
- کلید اصلی روی service_name و name و start_time، به‌علاوهٔ ایندکس bloom filter روی trace_id
- متریک‌های SPM مستقیم از اسپن‌ها حساب می‌شن، بدون پایپ‌لاین متریک جداگانه
