بازگشت به کتابخانهکتابخانه17.8Case Study: سیستم مانیتورینگ متریک (Datadog)
طراحی سیستم نرم‌افزاری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 17.8فصل ۱۷Case Study های تکمیلی

Case Study: سیستم مانیتورینگ متریک (Datadog)

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

مسئله: سامانه‌ای بساز که میلیون‌ها متریک در ثانیه از هزاران سرور جمع کند، نگه دارد، کوئری کند و رویش هشدار بگذارد — Datadog/Prometheus خودت. (حالا که درس ۵۰ مصرفش را می‌دانی، بسازش.)

۱-۲) نیازمندی و تخمین

  • FR: دریافت متریک (push/pull)، ذخیره سری زمانی، کوئری و داشبورد، هشدار.
  • NFR: نوشتن سنگینِ دائمی، خواندن نوسانی (هنگام حادثه همه داشبورد باز می‌کنند!)، retention ماه‌ها با granularity نزولی.
  • تخمین: 10K میزبان × 100 متریک × هر 10s ≈ 100K نقطه/s فقط برای یک مشتری — ضربدر cardinality (درس ۵۰) یعنی طراحی برای انفجار.

۳) طراحی — دیتابیس سری زمانی

چرا نه Postgres؟ الگوی نوشتن: الحاقی، حجیم، تقریباً بدون آپدیت؛ الگوی خواندن: بازه‌ای روی یک سری. پاسخ: TSDB با LSM (درس ۱۲ — نوشتن سنگین را می‌بلعد)، داده هر سری به‌ترتیب زمان کنار هم روی دیسک (خواندن بازه‌ای = sequential)، و فشرده‌سازی دلتا: زمان‌ها و مقدارهای متوالی شبیه‌اند؛ XOR/دلتا هر نقطه را به چند بیت می‌رساند (همین ترفند Gorilla فیسبوک — ۱۲ برابر فشردگی).

DIAGRAMجریان متریک
Agent — جمع‌کننده لبه
Kafka — بافر
Ingest — ولیدیشن/نرمال
TSDB — shard بر سری
Query/Alert — خواندن
  • بافر اجباری: موج حادثه = موج متریک؛ Kafka بین agent و ingest نباید بگذارد همین‌جا سیستم مانیتورینگ هم بمیرد — سیستمی که برای دیدن حادثه ساخته‌ای نباید اولین قربانی حادثه باشد.
  • Shard بر اساس نام متریک + برچسب‌ها (هش سری)؛ یک سری همیشه به یک گره می‌رود تا بازه‌خوانی محلی بماند.
  • Downsampling: داده خام ۱۰ ثانیه‌ای یک هفته، بعد تجمیع دقیقه‌ای یک ماه، بعد ساعتی یک سال — نگه‌داشتن همیشگیِ دقت کامل، پول سوزاندن است.
  • Push یا Pull؟ Prometheus کشش (pull) می‌کشد (ساده، کشف سرویس‌محور)؛ Datadog/agent push می‌کند (بهتر برای ephemeral و فایروال). هیبرید هم رایج است.

۴) عمق و گلوگاه

  • خواندن نوسانی: داشبوردها را query cache و pre-aggregation کن؛ تجمیع‌های رایج (avg per node per min) از قبل محاسبه شود.
  • هشدار نباید کوئری سنگین هم‌زمان بزند: ارزیابی قوانین روی جریان (streaming eval) یا کوئری سبک دوره‌ای با کش.
  • خودِ سیستم مانیتورینگ هم SLO می‌خواهد — و باید با حداقل وابستگی به همان زیرساختی که رصدش می‌کند زنده بماند (monitoring the monitoring).

به زبان ساده

سیستم مانیتورینگ یعنی دیتابیس سری‌زمانی: نوشتن سیلابی با LSM می‌بلعد، داده هر متریک کنار هم روی دیسک است و دقت داده قدیمی به‌تدریج کم می‌شود (downsampling).

مثال واقعی

مثل دفتر ثبت دمای بیمار: هفته اخیر هر ۱۰ دقیقه، ماه قبل هر ساعت، سال قبل فقط روزانه — چون کسی دمای دقیقه‌به‌دقیقه سال پیش را نمی‌خواهد.

دانش‌سنجی

آزمون درس

۳ Q
01
چرا LSM برای TSDB از B+Tree بهتر است؟
02
چرا Kafka بین agent و storage حیاتی است؟
03
Downsampling چه مصالحه‌ای است؟