مانیتورینگ سایت از چند موقعیت جغرافیایی؛ تشخیص قطعی منطقه‌ای

وب‌سایت از داخل دیتاسنتر تهران سالم است و مانیتور داخلی HTTP 200 نشان می‌دهد، اما مشتریان یک کشور دیگر نمی‌توانند صفحه را باز کنند. آیا سایت واقعاً قطع شده است؟ اگر فقط از همان دیتاسنتر بررسی کنید، نتیجه «سالم» گمراه‌کننده است؛ اگر فقط از یک Probe خارجی بسنجید، خطای همان شبکه می‌تواند قطعی کاذب بسازد. مانیتورینگ سایت از چند موقعیت جغرافیایی برای حل این اختلاف طراحی می‌شود: سلامت یک سرویس را از چند مسیر مستقل اندازه می‌گیرد و مشخص می‌کند مشکل جهانی، منطقه‌ای یا مخصوص یک نقطه اندازه‌گیری است.

این مقاله یک راهنمای عملی برای طراحی سامانه پایش چندموقعیتی است؛ از انتخاب Probe و ساختن آزمون مشترک تا منطق Quorum، تشخیص DNS و Routing، تفکیک Latency و طراحی Alert. اگر دنبال نقشه کلی قطعی سایت و ابزارهای خط فرمان هستید، راهنمای چرا سایت برای بعضی کاربران باز نمی‌شود؟ نقطه شروع است. اینجا تمرکز روی طراحی و اعتبارسنجی شواهد از چند نقطه مستقل است.

مانیتورینگ چندموقعیتی سایت دقیقاً چه چیزی را ثابت می‌کند؟

هر Probe از یک شبکه و موقعیت مشخص، درخواست قابل اندازه‌گیری به سرویس می‌فرستد. اگر از سه موقعیت مستقل، دو مورد موفق و یکی ناموفق باشد، نتیجه معتبر «اختلاف دسترس‌پذیری بین مسیرها» است؛ نه لزوماً «سایت برای همه کاربران آن منطقه قطع است». هر Probe تنها نماینده مسیر خودش و همان زمان است. حتی Probeهای دو کشور ممکن است از شبکه یا Provider مشترک عبور کنند و استقلال ظاهری داشته باشند.

الگوی مشاهده	تفسیر اولیه	چه چیزی باید بررسی شود؟
همه Probeها ناموفق‌اند	احتمال قطعی گسترده یا خرابی Origin	سلامت Backend، DNS و CDN مشترک
یک Probe خطا می‌دهد و بقیه سالم‌اند	احتمال اختلال مسیر یا خطای Probe	شبکه مبدأ، DNS Resolver و تکرار آزمون
فقط چند شبکه در یک منطقه مشکل دارند	احتمال Routing یا محدودیت منطقه‌ای	ASN، IPv4/IPv6، CDN Edge و سیاست دسترسی
همه HTTP 200 می‌دهند ولی p95 کند است	افت عملکرد بدون قطعی کامل	TTFB، TLS، انتقال محتوا و برنامه
یک منطقه 403 می‌گیرد و بقیه 200	ممکن است سیاست WAF یا مجوز متفاوت باشد	قانون Edge، Rate Limit و احراز دسترسی

HTTP 403 با Timeout یا خطای TLS یکسان نیست. همچنین پاسخ 200 از CDN ممکن است یک صفحه قدیمی کش‌شده باشد؛ برای سرویس مهم، آزمون‌های خواندنی و احراز صلاحیت‌شده از API یا Health Endpoint باید جدا تعریف شوند.

چند Probe کافی است و چه موقعیت‌هایی را انتخاب کنیم؟

یک طرح اولیه می‌تواند سه تا پنج Probe روی شبکه‌های مستقل در مناطق کاربران اصلی داشته باشد. تعداد بیشتر به‌خودی‌خود کیفیت را بالا نمی‌برد؛ Probeهای متعدد روی یک Provider مشترک می‌توانند همه با یک حادثه شبکه خراب شوند. برای هر Probe، کشور یا شهر، ASN و شرکت ارائه‌دهنده شبکه، نسخه IP و Resolver DNS را ثبت کنید.

کاربر ایرانی را از کدام مسیرها نمایندگی کنیم؟

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

چرا Probeهای یک دیتاسنتر مستقل محسوب نمی‌شوند؟

اگر هر سه Probe از یک Transit یا زیرساخت DNS مشترک استفاده کنند، خرابی همان وابستگی می‌تواند نتیجه «سه رأی منفی» بسازد؛ درحالی‌که کاربران مسیرهای دیگر مشکلی ندارند. استقلال باید در سطح شبکه، Resolver و مسیر واقعی باشد. هنگام انتخاب Anbieter، حتماً وابستگی‌های مشترک را مستند کنید.

طراحی آزمون یکسان: HTTP، DNS، TLS و مسیر شبکه

برای مقایسه نتیجه‌ها، URL، متد، Timeout، Redirect Policy، User Agent و انتظار محتوایی Probeها باید همسان باشد. اگر یک Probe صفحه اصلی را GET کند و دیگری Endpoint نیازمند Login را بررسی کند، اختلاف نتیجه ارزش تشخیصی ندارد. زمان‌ها را با ساعت هماهنگ و شناسه مشترک Test Run ذخیره کنید.

آزمون HTTP بدون عملیات مخرب چگونه باشد؟

Probe نباید فرم پرداخت واقعی، ثبت سفارش یا ارسال پیام انجام دهد. برای بررسی ساده، یک Endpoint خواندنی با Status و پاسخ قابل پیش‌بینی انتخاب کنید. مثال زیر برای هر نقطه باید با تنظیمات یکسان اجرا شود:

curl -sS -L --max-time 10 -o /dev/null \
  -w 'status=%{http_code} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/health

همه زمان‌ها به ثانیه‌اند و برخی نقاط عطف مانند time_appconnect مقدار تجمعی تا پایان TLS هستند؛ برای به‌دست‌آوردن مدت خود TLS باید زمان‌های مربوط را از هم کم کرد. همچنین اگر پروکسی فعال باشد، متریک‌ها مسیر Proxy را نشان می‌دهند. از آدرس واقعی و مجاز خودتان استفاده کنید و نتیجه را با برچسب Probe ذخیره کنید.

DNS را از پاسخ نهایی جدا ثبت کنید

ممکن است Resolverهای مختلف به IPهای متفاوت CDN برسند یا در یک منطقه پاسخ NXDOMAIN مشاهده شود. برای تحلیل، نام دامنه، Resolver، رکورد A/AAAA، TTL مشاهده‌شده و IP مقصد را ثبت کنید. dig روی بعضی میزبان‌ها نصب نیست؛ اگر وجود دارد می‌توان وضعیت را خواند:

dig +time=2 +tries=1 example.com A
dig +time=2 +tries=1 example.com AAAA

باید IPv4 و IPv6 را مستقل بسنجید؛ خرابی تنها AAAA ممکن است روی بخشی از کاربران اثر بگذارد. برای تست واقعی TLS نیز نام میزبان و SNI باید حفظ شود؛ جایگزینی صرف IP در URL می‌تواند نتیجه گواهی را اشتباه کند.

Quorum و تأیید مجدد چگونه هشدار کاذب را کاهش می‌دهد؟

Quorum یعنی برای اعلام حادثه، تعداد مشخصی از Probeهای واجد شرایط باید در بازه مشخص خطای مشابه ببینند. مثلاً برای سه Probe مستقل، سیاست اولیه می‌تواند «دو Probe از سه Probe در دو اجرای متوالی ناموفق باشند» باشد. این تنها مثال طراحی است؛ برای سرویس حساس یا خطاهای منطقه‌ای، به سیاست متفاوت نیاز دارید.

راهبرد هشدار	مزیت	خطر
هر خطای یک Probe = حادثه سراسری	حساسیت زیاد	هشدار کاذب بالا
اکثریت Probeها در دو دوره	مقاومت بهتر به خطای نقطه‌ای	ممکن است خرابی واقعی فقط یک منطقه را پنهان کند
دو لایه: قطعی گسترده و هشدار منطقه‌ای	تفکیک شدت و دامنه آسیب	نیاز به Runbook و برچسب منطقه
تأیید از نقطه دوم پس از شکست	کاهش نویز با هزینه کمتر	تأخیر اندک در شناسایی

بهتر است «Incident Global» و «Incident Regional» جدا باشند. اگر Probe ایران ناموفق و دو Probe خارجی سالم‌اند، ممکن است همان اختلال برای کاربران داخل کشور بسیار جدی باشد؛ رأی اکثریت خارجی نباید آن را نادیده بگیرد.

چگونه قطعی واقعی را از خرابی خود Probe تشخیص دهیم؟

Probe نیز ممکن است به دلیل خطای سیستم‌عامل، DNS محلی، تمام‌شدن سهمیه یا تأخیر زمان‌بندی خراب شود. بنابراین سلامت خود Probe باید با Heartbeat، ظرفیت و زمان اجرای آزمون جدا مانیتور شود. اگر Probe در زمان مشخص هیچ نتیجه‌ای گزارش نکرد، وضعیت «نامعلوم» دقیق‌تر از «سرویس قطع» یا «سرویس سالم» است.

در گزارش هر آزمون، خطا را به دسته‌های DNS، TCP، TLS، HTTP Status، Timeouts و پاسخ محتوایی تقسیم کنید. اگر یک Probe ۵۰۲ و دیگری ۲۰۰ می‌دهد، احتمال مسیر CDN یا Backend متفاوت مطرح است؛ اما بدون IP، Host و زمان دقیق، علت قطعی معلوم نمی‌شود.

Latency بین مناطق را چگونه درست مقایسه کنیم؟

فاصله شبکه و مسیر Routing روی RTT اثر دارد. بنابراین طبیعی است Probe دورتر زمان TCP بیشتری داشته باشد. بهتر است متریک‌هایی مانند DNS Lookup، TCP Connect، TLS Handshake، TTFB و Total Duration را جدا ثبت کنید. مقایسه TTFB بدون درنظرگرفتن تفاوت جغرافیایی ممکن است خطای تحلیل بسازد.

برای هر منطقه یک Baseline جدا بسازید؛ سپس افزایش غیرعادی نسبت به همان Baseline را بررسی کنید. مثلاً اگر زمان پاسخ معمول یک نقطه ۱۵۰ میلی‌ثانیه است و ناگهان به ۹۰۰ می‌رسد، تغییر مهم‌تر از مقایسه خام آن با نقطه‌ای است که معمولاً ۴۰۰ میلی‌ثانیه پاسخ می‌گیرد. این اعداد مثال فرضی هستند، نه داده واقعی شبکه یا محصول آوازتک.

Routing، CDN و Anycast چطور نتایج را متفاوت می‌کنند؟

شبکه تحویل محتوا ممکن است برای دو Probe با یک دامنه، IP یا Edge متفاوت انتخاب کند. Anycast نیز می‌تواند کاربر را از مسیرهای متفاوت به مقصد یکسان منطقی برساند. اختلال یک Edge یا مسیر BGP ممکن است فقط بخشی از مناطق را تحت تأثیر قرار دهد، درحالی‌که Origin سالم است. هنگام Incident، تغییرات DNS، مقصد اتصال، زمان TLS و در صورت داشتن مجوز و ابزار، Traceroute را با داده قبلی مقایسه کنید.

Traceroute همه Hopهای واقعی را همیشه نشان نمی‌دهد و برخی Routerها پاسخ ICMP را محدود می‌کنند. تفاوت یا ستاره‌دار بودن چند Hop به‌تنهایی علت اختلال نیست. اگر HTTP 403 فقط در یک منطقه ظاهر شده، علاوه بر Routing ممکن است قانون WAF، Geo Rule یا Rate Limiter موجب آن باشد.

یک سناریوی عیب‌یابی: فقط کاربران موبایل یک منطقه خطا دارند

فرض کنید Probe خارجی و Probe دیتاسنتر داخلی سالم‌اند، اما Probe یک اپراتور موبایل داخلی خطای Timeout نشان می‌دهد. نخست تکرار آزمون، سلامت همان Probe و پاسخ A/AAAA را بررسی کنید. سپس نتیجه IPv4 و IPv6، زمان TCP و TLS و IP مقصد را جدا ثبت کنید. اگر قطعی فقط روی IPv6 رخ می‌دهد، اشتباه است که صرفاً CPU Origin را افزایش دهیم.

1. همان درخواست خواندنی را دو بار در بازه کوتاه از سه نقطه مستقل اجرا کنید.
2. کد خطا، زمان DNS/TCP/TLS و IP مقصد را کنار هم قرار دهید.
3. سلامت Probe و تفاوت Resolverها را کنترل کنید.
4. یک نقطه دوم از همان گروه کاربری، در صورت دسترس‌بودن، برای تأیید منطقه‌ای انتخاب کنید.
5. اگر شواهد مشترک‌اند، Incident منطقه‌ای بسازید و آن را با قطعی سراسری یکی نکنید.
6. پس از اصلاح شبکه یا تنظیم CDN، Recovery را از مسیرهای آسیب‌دیده تأیید کنید.

این روند به تغییر تنظیمات Production نیاز ندارد؛ آزمون‌های خارجی باید Rate Limit مشخص، داده غیرحساس و حجم کم داشته باشند. اگر به تجهیزات یا سرویس شخص ثالث دسترسی ندارید، Probe بدون مجوز اجرا نکنید.

چگونه خروجی مانیتورینگ چندموقعیتی را قابل اعتماد کنیم؟

برای هر رویداد حداقل زمان UTC، شناسه Probe، Region، ASN، نسخه IP، نام Resolver، URL یا Service ID، کد خطا، مدت درخواست و تعداد تکرار را ثبت کنید. Raw Logها نباید شامل Cookie، Token یا اطلاعات شخصی کاربران باشند. برای گزارش نهایی، درصد موفقیت هر منطقه و فاصله زمان شروع تا پایان Incident را از داده واقعی محاسبه کنید.

شاخص Availability در یک نقطه را با Availability جهانی یا تجربه تمام کاربران مساوی فرض نکنید. اگر Probe در هر دقیقه یک بار اجرا می‌شود، قطع کوتاه‌تر از دوره نمونه‌گیری ممکن است دیده نشود. تعریف SLO باید نوع نمونه‌گیری، دامنه کاربران و خطای اندازه‌گیری را روشن کند.

ساخت پایش چندنقطه‌ای با ابزارهای متن‌باز یا سرویس آماده

رویکرد	مزیت	نیاز عملیاتی
چند اجرای curl در VPSهای مستقل	کنترل کامل آزمون و منطقه	زمان‌بندی، ذخیره تاریخچه و اعلان را خودتان می‌سازید
Prometheus Blackbox Exporter	Probeهای HTTP، DNS و TCP با متریک‌های قابل کوئری	استقرار Collector/Probe و مراقبت از امنیت و منابع
سامانه مدیریت‌شده Uptime چندمنطقه‌ای	Probe و Alert متمرکز در صورت پشتیبانی سرویس	بررسی تنوع شبکه، SLA و هزینه
Network Check در Avaztek Monitoring	پایش و گزارش اتصال در کنار سلامت سرور	تعداد و موقعیت واقعی Probeها باید جدا تأیید شود

برای پیاده‌سازی فنی HTTP و DNS Probe به مخزن رسمی Prometheus Blackbox Exporter مراجعه کنید. اجرای یک Exporter روی یک VPS، به‌خودی‌خود مانیتورینگ چندموقعیتی نیست؛ برای چند مسیر باید Probe یا اجرای مستقل را در شبکه‌های متفاوت قرار دهید.

Avaztek Monitoring در این معماری چه نقشی دارد؟

Avaztek Monitoring طبق مستندات محصول، بخش Network Check، Latency، پایش SSL و سرویس‌ها و امکانات هشدار و Recovery دارد. این داده‌ها برای مقایسه وضعیت شبکه با سلامت منابع سرور مفیدند. اما در بررسی فعلی کد و مستندات، وجود Probeهای واقعاً مستقل در چند کشور برای این سامانه تأیید نشد؛ بنابراین نباید فرض کرد نصب سامانه به‌تنهایی پایش چندجغرافیایی را فعال می‌کند.

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

پرسش‌های متداول مانیتورینگ سایت از چند موقعیت

چرا سایت فقط برای کاربران یک کشور باز نمی‌شود؟

اختلال DNS، Routing، Edge CDN، IPv6 یا سیاست دسترسی منطقه‌ای ممکن است عامل باشد. نتیجه از یک Probe به‌تنهایی علت را ثابت نمی‌کند؛ مسیرها و کدهای خطا را جدا بررسی کنید.

برای مانیتورینگ چندموقعیتی چند Probe کافی است؟

وابسته به کاربران و ریسک سرویس است. سه تا پنج نقطه مستقل می‌تواند شروعی مناسب باشد، اما تنوع ASN و شبکه از تعداد خام Probe مهم‌تر است.

اگر دو Probe سالم و یکی خراب باشد، سایت سالم است؟

ممکن است سرویس برای بخشی از کاربران واقعاً قطع باشد. وضعیت را «اختلال منطقه‌ای یا خطای Probe در حال بررسی» گزارش کنید و به اکثریت به‌عنوان اثبات سلامت همه کاربران تکیه نکنید.

آیا HTTP 200 از چند کشور به معنی سلامت کامل سایت است؟

خیر. Cache، مسیر ورود کاربر و APIهای کاربردی ممکن است جدا مشکل داشته باشند. از Endpoint غیرمخرب نماینده تجربه کاربر و بررسی محتوایی مناسب استفاده کنید.

چطور False Positive هشدار سایت را کم کنیم؟

سلامت خود Probe را بسنجید، خطا را از نقطه دوم تأیید کنید و هشدار سراسری را از خطای منطقه‌ای جدا نگه دارید. فاصله نمونه‌گیری و قانون Recovery را نیز مشخص کنید.

آیا Avaztek Monitoring اکنون Probe در چند کشور دارد؟

در مستندات و کد بررسی‌شده، Network Check و Latency وجود دارند ولی چندموقعیتی‌بودن Probeها تأیید نشده است. برای نیاز قطعی به این قابلیت، از امکانات فعلی سرویس اطلاع بگیرید و در صورت نیاز ابزار چندنقطه‌ای مکمل انتخاب کنید.

جمع‌بندی: تفاوت منطقه‌ای را به جای اعلام قطعی سراسری نشان دهید

مانیتورینگ از چند موقعیت زمانی مؤثر است که نقاط واقعاً مستقل باشند، آزمون یکسان اجرا شود و نتیجه‌ها با منطق Quorum و وضعیت هر منطقه تفسیر شوند. برای پایش پایه شبکه، SSL و سلامت سرور، Avaztek Monitoring قابل بررسی است؛ راهکار چندجغرافیایی واقعی را باید براساس تعداد و محل Probeهای تأییدشده طراحی کرد.