بازگشت به کتابخانهکتابخانه15.3Observability عمیق: OpenTelemetry ،Cardinality و Sampling
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 15.3فصل ۱۵SaaS ،SRE ،امنیت و شبکه پیشرفته

Observability عمیق: OpenTelemetry ،Cardinality و Sampling

  • ~۱۳ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

فصل ۶ سه ستون (Logs/Metrics/Traces) را شناخت. در مقیاس، مشکل جدیدی ظاهر می‌شود: داده رصدی خودش به هیولای هزینه و نویز تبدیل می‌شود. این درس درباره مهار همان هیولاست.

OpenTelemetry: یک استاندارد برای همه

OTel استاندارد باز تولید و انتقال telemetry است: SDK درون سرویس‌ها trace/metric/log را با یک مدل واحد (و context مشترک) می‌سازد و Collector آن را می‌گیرد، غنی/فیلتر می‌کند و به هر backend (Prometheus ،Jaeger ،Tempo ،…) می‌فرستد. نکته معماری: instrumentation را از انتخاب vendor جدا می‌کند — یک‌بار بنویس، مقصد را عوض کن. Trace context (traceparent) باید روی HTTP ،gRPC و حتی پیام‌های Kafka عبور داده شود وگرنه زنجیره در مرز صف می‌گسرد.

Cardinality: قاتل خاموش متریک‌ها

  • هر ترکیب یکتا از label ها یک time-series جدید می‌سازد: http_requests{path="/u/8123"} با user_id در label یعنی میلیون‌ها سری — Prometheus را می‌کشد و صورت‌حساب را منفجر می‌کند.
  • قانون: label ها باید کم‌کاردینالیته باشند (endpoint ،method ،status)؛ شناسه‌های پرتعداد (user ،order ،session) جایشان در trace و log است.
  • Histogram ها bucket بگیر که p99 را بفهمی، نه رزولوشن بی‌نهایت: برای تأخیر API بازه‌های 5ms تا 10s لگاریتمی کافی است.

Sampling: همه trace ها را نگه نمی‌داریم

استراتژیروشبها
Head-basedدر ابتدای درخواست تصمیم (مثلاً ۱٪)ارزان؛ ولی trace های خطادارِ کمیاب را ممکن است نگه ندارد
Tail-basedکل trace جمع، بعد تصمیم: خطا/کند را نگه دارهوشمند و محبوب؛ نیازمند بافر و Collector قوی
Adaptiveنرخ sampling با حجم و خطا تطبیق یابدمتعادل‌ترین برای ترافیک متغیر

معماری لاگ

  • ELK (Elasticsearch): ایندکس کامل متن — جستجوی قوی، مصرف دیسک/حافظه بالا، گران در مقیاس.
  • Loki: فقط label ها ایندکس می‌شوند و محتوا فشرده خام می‌ماند — ارزان‌تر، برای «لاگ‌های یک سرویس در یک بازه» عالی، برای جستجوی آزاد متن ضعیف‌تر.
  • در مقیاس بزرگ: بافر Kafka جلوی لاگ‌پرداز تا موج خطا (که دقیقاً هنگام حادثه می‌آید!) زنجیره رصدی را هم نیاندازد.
  • Exemplar متریک را به trace وصل می‌کند: روی نمودار p99 کلیک کنی، به trace واقعی همان نقطه برسی — میان‌بر دیباگ.

به زبان ساده

رصدپذیری در مقیاس خودش یک سیستم بزرگ است: برچسب‌های متریک باید کم‌تعداد بمانند و همه traceها را نمی‌توان نگه داشت — نمونه‌برداری هوشمند لازم است.

مثال واقعی

مثل دوربین‌های فروشگاه بزرگ: همه لحظات با ۴K ضبط نمی‌شود (گران و بی‌مصرف)؛ وقتی اتفاقی می‌افتد، همان قطعه با کیفیت کامل نگه داشته می‌شود — tail-based sampling همین است.

دانش‌سنجی

آزمون درس

۴ Q
01
چرا user_id به‌عنوان label متریک ممنوع است؟
02
می‌خواهی trace های خطادار را ۱۰۰٪ داشته باشی ولی هزینه مهار شود. راه؟
03
trace در مرز Kafka گسسته شده. چه چیزی غایب است؟
04
مزیت معماری OTel Collector چیست؟