مانیتورینگ متریک های دامنه: مانیتورینگ با قابلیت جدید CDN ابر آروان

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

همیشه لاگ‌های خام، منبعی برای عیب‌یابی‌های عمیق (Forensics) هستند، اما در عین حال، ingest کردن، پردازش و ذخیره‌سازی حجم بالای اون‌ها، بار عملیاتی و خب، هزینه مالی قابل توجهی داره.

ما توی تیم محصول CDN، پس از تعامل های متعدد با کاربران CDN تقریبا همین دغدغه رو متوجه شدیم.

یه لحظه: اصلا هدف از مانیتورینگ چی هست؟

ما به این نتیجه رسیدیم که هدف غایی مانیتورینگ میتونه این باشه که به سطح بالاتری از هرم دانش (DIKW) دست پیدا کنیم: یعنی داده‌های خام (Data) لاگ‌ها رو به اطلاعات (Information) قابل استفاده تبدیل کنیم و در نهایت از سیستم دانش (Knowledge) کسب کنیم. در نهایت به عنوان یه خبره سیستم میتونیم بگیم که به خرد (Wisdom) رسیدیم.

چالش به دست آوردن Information از Data: وقتی پردازش لاگ‌ها کنده و گرون در میاد

وقتی پای بازخوردهای مشتریان میشستیم، می فهمیدیم مشکل اصلی نبودن داده نیست؛ بلکه تاخیر و پیچیدگی توی استخراج اطلاعات کلیدی (Key Information) از دل اون‌هاست. چالش‌های اصلی که مشتریان میگفتن شامل این‌ها بودن:

هزینه و دردسر Pipeline داده: اینکه بخوایم یه Pipeline کامل (مثلاً CDN log -> Kafka -> Elastic) راه بندازیم فقط برای اینکه متریک ساده‌ای مثل «۱۰ IP با بیشترین درخواست» رو دربیاریم، مصداق بارز Over-Engineering برای یه نیاز ساده و تکراریه.
تاخیر توی Alert گرفتن: سیستم‌های مانیتورینگ مبتنی بر لاگ، ذاتاً برای هشدار دادن لحظه‌ای خیلی بهینه نیستن. تا لاگ‌ها ارسال، ایندکس و پردازش بشن، ممکنه چند دقیقه طلایی رو برای واکنش به یه حمله یا مشکل از دست بدیم.
جور نبودن فرمت‌ها: فرمت لاگ برای ذخیره کردن رویداد (Event) طراحی شده، ولی ابزارهای مانیتورینگ امروزی مثل Prometheus، با داده‌های سری زمانی (Time-Series) و متریک کار می‌کنن. تبدیل این دو به هم، همیشه یه لایه پردازشی اضافه لازم داره.

چرا پردازش رو ما انجام ندیم؟

اینجا بود که به یه Insight کلیدی رسیدیم: چرا پردازشی که برای همه‌ی مشتری‌ها یکسانه رو بندازیم روی دوش زیرساخت اون ها؟ ما می‌تونیم این پردازش اولیه رو همین‌جا، یعنی توی زیرساخت CDN و لبه شبکه (Edge)، قبل از اینکه داده به دست مشتری برسه انجام بدیم.

همین تغییر نگرش بود که باعث شد قابلیت «مانیتورینگ متریک‌های دامنه» یا Metric Exporter رو بسازیم. این قابلیت جایگزین ارسال لاگ نیست؛ ولی میتونه یه جریان داده‌ی موازی، سبک و آماده‌به‌مصرفه که مستقیم میره برای استک مانیتورینگ شما باشه. شما میتونید با انجام دادن چند تا مرحله ساده مانیتورینگ متریک های دامنه رو بالا بیارید. توضیحات رو بچه ها اینجا نوشتن:

https://git.arvancloud.ir/arvancloud/cdn/monitoring-template

چه متریک هایی رو میتونیم در اختیار شما قرار بدیم؟

در حال حاضر ما چهار دسته اصلی متریک را در اختیار شما قرار می‌دیم:

۱. متریک‌های دسترسی (Access Metrics) 📊

این دسته از متریک‌ها اطلاعات دقیقی درباره ترافیک ورودی، رفتار کاربران و وضعیت کش به شما می‌دهند.

ترافیک برتر: شناسایی ۱۰ IP، سرور کد (Server Code) و ASN برتر با بیشترین تعداد درخواست.
عملکرد کلی: مجموع تعداد کل درخواست‌ها، بایت‌های ارسالی و دریافتی، تفکیک شده بر اساس متد HTTP و نوع محتوا.
وضعیت کش (Cache): تعداد کل درخواست‌ها بر اساس وضعیت‌های Hit, Miss, Bypass.
عملکرد سرور اصلی: مدت زمان پردازش آخرین درخواست، زمان پاسخ‌دهی تجمیعی و تعداد استفاده از پورت‌های مختلف سرور.
اطلاعات کاربران: مشاهده تعداد بازدیدکنندگان یکتا و تفکیک تعداد درخواست‌ها بر اساس کشور.

۲. متریک‌های DNS 🌐

این متریک‌ها به شما دید کاملی از وضعیت درخواست‌های DNS دامنه‌تان می‌دهند.

محبوبیت رکوردها: نرخ درخواست بر اساس نوع رکوردهای DNS (مانند A, AAAA).
وضعیت پاسخ‌ها: تعداد کدهای وضعیت DNS برای شناسایی خطاها.
منابع درخواست: شناسایی ۱۰ ASN برتر که بیشترین کوئری را ارسال کرده‌اند.
پراکندگی جغرافیایی: مجموع درخواست‌های DNS بر اساس کشور.

۳. متریک‌های خطای سرور اصلی (Upstream Error Metrics) ⚠️

این دسته به شما کمک می‌کند تا مشکلات و خطاهای مربوط به سرورهای اصلی خود را به سرعت شناسایی و رفع کنید.

خطا بر اساس موقعیت: تعداد خطاها به تفکیک پاپ‌سایت‌های CDN.
خطا بر اساس منبع: شناسایی سرور اصلی (Upstream) و Origin که بیشترین خطا را داشته‌اند.
مسیرهای پر خطا: شناسایی ۱۰ URI (مسیر) که بیشترین خطا را در پاسخ‌های خود داشته‌اند.

۴. متریک‌های رویداد (Event Metrics) 🛡️

این متریک‌ها دید دقیقی از وقایع امنیتی و عملکرد قوانین تنظیم‌شده توسط شما ارائه می‌دهند.

امنیت TLS: شناسایی ۱۰ JA3 Fingerprint برتر در درخواست‌های HTTP.
عملکرد Rate Limit: تعداد درخواست‌های منطبق با هر قانون Rate Limit و اکشن‌های انجام‌شده (Block, Allow و...).
عملکرد فایروال: تعداد درخواست‌های منطبق با هر قانون فایروال و اکشن‌های اعمال‌شده (Deny, Challenge و...).
عملکرد قوانین صفحات (Page Rule): تعداد درخواست‌هایی که با قوانین صفحات شما منطبق بوده‌اند.
وضعیت مقابله با DDoS: تعداد اکشن‌ها و تصمیم‌های نهایی مرتبط با چالش‌های DDoS.

ما همیشه تو این داکیومنت لیست بروز شده همه متریک هارو قرار میدیم:

https://docs.arvancloud.ir/fa/cdn/analytics/metric-exporter

داشبورد گرافانا هم آماده کردیم

برای اینکه نخواید وقتتون رو روی درست کردن داشبورد بذارید، ما یه داشبورد آماده Grafana درست کردیم که فقط کافیه Import اش کنید و بلافاصله داده‌ها رو ببینید.

لینک داشبورد:

https://grafana.com/grafana/dashboards/22668-arvancloud-cdn-metrics/

نتیجه گیری: می‌شود از سادگی درهای مطلب باز کرد

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

خوشحالیم که بگم متریک اکسپورتر پس از 9 ماه به تازگی از مرحله آزمایشی (Beta) با موفقیت عبور کرده و به صورت عمومی در دسترس قرار گرفته. البته این تازه اول راهه و مسیر زیادی تا بلوغ کامل این سرویس داریم. با این حال در همین دوره کوتاه تعداد زیادی از پر ترافیک ترین سرویس های اکوسیستم از این قابلیت استفاده کردند و متریک اکسپورتر با پردازش موفق بیش از ۴۰ میلیارد لاگ و تبدیل آن‌ها به متریک‌های کاربردی، به خوبی امتحانش رو پس داد و ما را سربلند کرد.

ما باور داریم که توسعه‌ی محصول یه گفتگوی دوطرفه‌ست. شما چالش‌های استک‌تون رو به ما میگید و ما هم ابزارهایی رو لبه شبکه‌ (Edge) می‌سازیم که کمک‌تون کنه موثرتر حل‌شون کنید. قابلیت مانیتورینگ متریک‌ها شروع این مسیره و منتظر بازخوردهای شما هستیم تا بتونیم بهترش کنیم.