إذا كانت مراقبة واجهة برمجة التطبيقات الخاصة بك تعمل على خادم في مركز بيانات واحد، فإنك ترى فقط جزءًا من الصورة. قد يتلقى مستخدم من البرازيل خطأ 500، بينما يظهر لوحة التحكم الخاصة بك في موسكو حالة خضراء "كل شيء يعمل". دعونا نستعرض 5 مقاييس للتوفر لا يمكن قياسها دون طلب عبر IP خارجي حقيقي من دولة أخرى، وكيفية القيام بذلك دون بنية تحتية معقدة.
لماذا المراقبة المحلية مضللة
تقوم معظم الفرق بإعداد مراقبة واجهة برمجة التطبيقات عبر UptimeRobot أو Pingdom أو سكريبت cron خاص بها، الذي يتصل بالنقطة النهائية مرة واحدة في الدقيقة. المشكلة هي أن هذه الطلبات تأتي تقريبًا دائمًا من منطقة أو منطقتين - عادةً من الولايات المتحدة أو أوروبا، حيث توجد خوادم خدمات المراقبة. إذا كانت جمهورك في الهند أو البرازيل أو جنوب شرق آسيا، قد يقوم مقدمو الخدمة المحليون بقطع حركة المرور، وقد تكون عقدة CDN مزدحمة، وقد يتم حل DNS إلى IP قديم.
سيناريو شائع آخر هو geo-blocking على مستوى CDN أو WAF (Cloudflare، Akamai). بعض قواعد الأمان تحظر نطاقات كاملة من IP من دول معينة، وواجهة برمجة التطبيقات الخاصة بك غير متاحة فعليًا لجزء من المستخدمين، على الرغم من أن كل شيء يعمل بشكل مثالي من IP المكتبي الخاص بك. لا يمكن تشخيص هذه المشكلات إذا تم الاختبار فقط من نقطة واحدة.
السيناريو الثالث هو توزيع الحمل عبر Anycast أو حواف CDN الإقليمية. قد يصل الطلب من ألمانيا إلى عقدة واحدة، بينما يصل الطلب من سنغافورة إلى عقدة مختلفة تمامًا، مع إصدار مختلف من الذاكرة المؤقتة أو التكوين. الفرق في سلوك واجهة برمجة التطبيقات بين المناطق ليس نظرية، بل هو ما تواجهه الفرق بانتظام، حيث يكون المستخدمون موزعين حول العالم.
5 مقاييس للتوفر مرئية فقط عبر IP خارجي
فيما يلي خمس مقاييس تُظهر الصورة الحقيقية للتوفر فقط عندما يتم تنفيذ الطلب من عنوان IP موجود فعليًا في الدولة المستهدفة أو على الأقل يتم توجيهه عبر شبكتها.
1. زمن الاستجابة (Latency / RTT)
زمن الرحلة ذهابًا وإيابًا - هو الوقت من إرسال الطلب إلى استلام أول حزمة من الاستجابة. من خادم واحد في أوروبا، قد تكون التأخير إلى واجهة برمجة التطبيقات الخاصة بك 20 مللي ثانية، بينما ينتظر المستخدم من جنوب شرق آسيا 400-600 مللي ثانية بسبب المسافة الجغرافية وعدد العقد الوسيطة (hops). إذا لم يتم قياس زمن الاستجابة من مناطق مختلفة، فمن السهل أن تفوت اللحظة التي يصبح فيها الخدمة غير قابلة للاستخدام تقريبًا لجزء من الجمهور - وهو أمر حرج بشكل خاص لواجهات برمجة التطبيقات المرتبطة بالعمليات الفورية: المزايدة في الإعلانات، الدردشات، المعاملات المالية.
2. TTFB (Time To First Byte)
TTFB يُظهر كم من الوقت يستغرق الخادم لمعالجة الطلب قبل بدء إرسال الاستجابة. تعتمد هذه المقياس ليس فقط على الشبكة، ولكن أيضًا على العقدة التي تخدم المنطقة المحددة من CDN أو موازن الحمل. كثيرًا ما يحدث أن خادم الحافة في دولة واحدة يقوم بتخزين الاستجابة ويقدمها في 50 مللي ثانية، بينما في دولة أخرى، يصل الطلب كل مرة إلى خادم الأصل ويتم معالجته من جديد، مما يستغرق 800 مللي ثانية أو أكثر. الفرق في TTFB بين المناطق هو علامة مؤكدة على وجود مشكلات في تكوين CDN أو تغطية غير كافية لعقد الحافة.
3. زمن حل DNS
حل DNS هو مصدر منفصل للتأخيرات والأخطاء، والذي يعتمد بالكامل على محلل DNS المحلي للمستخدم. إذا كان لديك GeoDNS مُعد (سجلات A مختلفة حسب منطقة الطلب)، فإن خطأ في التكوين قد يؤدي إلى أن يتم حل المستخدمين من دولة واحدة إلى مركز بيانات في قارة أخرى - مع تأخير كبير. يمكن رؤية هذه المشكلة فقط عند طلب حل DNS من IP حقيقي من الدولة المستهدفة، حيث سيتم دائمًا حل الاختبار المحلي "بشكل صحيح" بالنسبة لموقعك الجغرافي الخاص.
4. نسبة الطلبات الناجحة (Uptime) حسب المناطق
توفر 99.9% من وقت التشغيل على لوحة التحكم للمراقبة، التي تتصل من نقطة واحدة، لا تضمن 99.9% للمستخدمين في دولة أخرى. قد يواجه مقدمو الخدمة المحليون مشاكل في الربط بشكل خاص مع مزود الاستضافة الخاص بك، مما يؤدي إلى أن بعض الطلبات من الدولة X ستفشل بسبب انتهاء المهلة، بينما لا يلاحظ بقية العالم المشكلة على الإطلاق. لرؤية وقت التشغيل الحقيقي، يجب حساب الطلبات الناجحة وغير الناجحة بشكل منفصل لكل منطقة، وليس بشكل تجميعي.
5. اختلافات في المحتوى وأكواد الحالة (geo-blocking والتخصيص)
المقياس الخامس ليس عن السرعة، بل عن المحتوى نفسه للاستجابة. قد تقوم واجهة برمجة التطبيقات بإرجاع 403 محظور لدول معينة بسبب قواعد WAF، أو إرجاع مجموعة بيانات مختصرة بسبب قيود الترخيص، أو عرض إصدار مختلف من المحتوى بسبب اختبارات A/B المرتبطة بالجغرافيا. إذا تم اختبار واجهة برمجة التطبيقات فقط من IP الخاص بك، ستبقى هذه الاختلافات غير ملحوظة تمامًا - وهي غالبًا ما تكون السبب وراء الشكاوى من المستخدمين من مناطق معينة.
من المهم أن نفهم
تتطلب جميع المقاييس الخمسة طلبًا من IP يتم توجيهه فعليًا عبر شبكة الدولة المستهدفة. ستوفر VPN ذات خادم واحد في الدولة أو خادم سحابي في نفس المنطقة صورة تقريبية، لكنها لن تُظهر كيف يرى الخدمة المستخدم النهائي مع مزود معين وطرق الوصول إلى واجهة برمجة التطبيقات الخاصة بك.
كيفية إعداد المراقبة من دول مختلفة
منطق الإعداد بسيط: تقوم بإرسال نفس الطلب HTTP إلى واجهة برمجة التطبيقات الخاصة بك من عدة نقاط في نفس الوقت، وتسجيل جميع المقاييس الخمسة ومقارنة النتائج. خطوة بخطوة، يبدو الأمر كالتالي:
- قم بإعداد قائمة بالدول ذات الأولوية - عادةً ما تكون هذه هي أفضل 5 دول من حيث حجم الحركة أو الإيرادات.
- لكل دولة، قم بإعداد نقطة خروج مع IP حقيقي من تلك الدولة (خادم بروكسي أو خادم فعلي).
- قم بإعداد سكريبت أو خدمة ترسل طلبًا متطابقًا عبر كل نقطة بفاصل زمني محدد (على سبيل المثال، مرة كل 5 دقائق).
- قم بتسجيل جميع 5 مقاييس بشكل منفصل لكل دولة في قاعدة بيانات أو نظام مقاييس (Grafana، Prometheus، ClickHouse).
- قم بإعداد تنبيهات عند انحراف المقاييس عن المستوى الأساسي - على سبيل المثال، إذا ارتفعت زمن الاستجابة من دولة معينة 3 مرات خلال ساعة.
النقطة الرئيسية هي بالضبط النقطة 2. بدون خروج حقيقي إلى الدولة المطلوبة، فإن جميع الخطوات الأخرى تكون بلا معنى، لأن المقاييس ستقيس ما يراه المستخدم، وليس ما يراه خادم المراقبة الخاص بك.
أي نوع من البروكسي يجب اختياره للمراقبة
لبناء مراقبة موزعة جغرافيًا، يتم استخدام خوادم البروكسي في الغالب - فهي أرخص وأسرع من استئجار خوادم فعلية أو VPS في كل دولة مطلوبة. يعتمد اختيار نوع البروكسي على ما تريد قياسه بالضبط.
| نوع البروكسي | متى تستخدمه | الميزات |
|---|---|---|
| بروكسي مراكز البيانات | التحقق الأساسي من التوفر وزمن الاستجابة، عندما لا تحتاج إلى محاكاة مستخدم حقيقي | سرعة عالية، تكلفة منخفضة، لكن IP سهل التعرف عليه كبروكسي مراكز البيانات - لا يصلح لاختبار geo-blocking حسب مقدمي الخدمة |
| بروكسي سكنية | التحقق مما يراه المستخدم الحقيقي مع مزود الخدمة المنزلي | IP ينتمي إلى مزودين حقيقيين في الدولة المحددة، يعكس بشكل أكثر دقة التوجيه وقواعد WAF |
| بروكسي موبايل | اختبار توفر واجهة برمجة التطبيقات للتطبيقات المحمولة وحركة المرور المحمولة | IP من شبكات مشغلي الهواتف المحمولة، يظهر التأخيرات والحظر المحدد لحركة المرور المحمولة |
إذا كانت واجهة برمجة التطبيقات الخاصة بك تخدم بشكل أساسي حركة مرور الويب من أجهزة الكمبيوتر والخوادم، فإن استخدام بروكسي مراكز البيانات يكفي لبناء مراقبة أساسية - فهي توفر سرعة مستقرة وزمن استجابة متوقع. لكن إذا كنت بحاجة إلى اختبار ما يواجهه المستخدم الحقيقي - بما في ذلك قواعد geo-blocking المعدة حسب ASN لمزود الخدمة - فمن الأفضل استخدام بروكسي سكنية، لأنها تتجه عبر شبكات مزودي الإنترنت العاديين في نفس الدولة. بالنسبة للتطبيقات المحمولة وSDK التي تقوم بإجراء طلبات إلى واجهة برمجة التطبيقات، من المنطقي إضافة اختبار عبر بروكسي موبايل، حيث أن مشغلي الهواتف المحمولة غالبًا ما يستخدمون NAT وقواعد توجيه خاصة بهم تختلف عن الإنترنت المنزلي.
سكريبت جاهز بلغة Python لجمع المقاييس
فيما يلي مثال مبسط لسكريبت يقوم بإرسال طلب عبر بروكسي في الدولة المحددة ويجمع أربعة من خمسة مقاييس (يجب مقارنة اختلافات المحتوى بشكل منفصل، من خلال مطابقة الاستجابات). يستخدم السكريبت مكتبة requests ووحدة socket لقياس زمن حل DNS.
import time
import socket
import requests
def measure_api(url, proxy, country_label):
hostname = url.split("//")[1].split("/")[0]
# 1. زمن حل DNS
dns_start = time.time()
try:
socket.gethostbyname(hostname)
except socket.gaierror:
pass
dns_time = time.time() - dns_start
proxies = {
"http": proxy,
"https": proxy,
}
try:
start = time.time()
response = requests.get(
url,
proxies=proxies,
timeout=10,
stream=True
)
ttfb = time.time() - start # TTFB تقريبي
full_load_time = time.time() - start
status_code = response.status_code
success = status_code == 200
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": round(ttfb * 1000, 2),
"total_time_ms": round(full_load_time * 1000, 2),
"status_code": status_code,
"success": success,
}
except requests.exceptions.RequestException as e:
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": None,
"total_time_ms": None,
"status_code": None,
"success": False,
"error": str(e),
}
return result
# مثال للاستخدام مع بروكسي من دول مختلفة
endpoints = [
{"label": "Germany", "proxy": "http://user:[email protected]:port"},
{"label": "Brazil", "proxy": "http://user:[email protected]:port"},
{"label": "Singapore", "proxy": "http://user:[email protected]:port"},
]
API_URL = "https://api.yourservice.com/health"
for ep in endpoints:
data = measure_api(API_URL, ep["proxy"], ep["label"])
print(data)
بالنسبة للإصدار الإنتاجي من هذا السكريبت، من الأفضل إضافة تسجيل النتائج في قاعدة بيانات (مثل ClickHouse أو InfluxDB)، والتصور عبر Grafana، والتنبيهات عبر بوت Telegram أو Slack-webhook عند تجاوز القيم الحدية. من الأفضل تشغيل السكريبت عبر cron أو جدولة المهام بفاصل زمني من 5 إلى 15 دقيقة لكل دولة.
إذا كنت بحاجة إلى تحقق سريع دون كتابة كود، يمكن تنفيذ طلب مماثل عبر cURL مع قياس الزمن:
curl -x http://user:[email protected]:port \
-o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
https://api.yourservice.com/healthكيفية تفسير النتائج
بعد جمع البيانات من جميع الدول لمدة أسبوع على الأقل، يظهر مستوى أساسي (baseline) لكل منطقة. بعد ذلك، يجب النظر ليس إلى الأرقام المطلقة، ولكن إلى الانحرافات عن هذا المستوى الأساسي. إذا كانت زمن الاستجابة من البرازيل ثابتة عند 350 مللي ثانية - فهذا طبيعي بالنسبة للجغرافيا، ويجب رفع الإنذار إذا ارتفع القيمة فجأة إلى 1500 مللي ثانية. بالمثل مع وقت التشغيل: 99.5% لمنطقة صعبة مع إنترنت غير مستقر قد تكون معيارًا مقبولًا، بينما الانخفاض إلى 95% هو بالفعل إشارة لمشكلة على جانب المزود أو CDN.
يجب إيلاء اهتمام خاص لأكواد الحالة 403 و451 - فهي تشير تقريبًا دائمًا إلى geo-blocking من جانب WAF أو CDN، وليس إلى مشكلة في واجهة برمجة التطبيقات نفسها. إذا ظهرت هذه الأكواد فقط من دولة معينة وفقط عند استخدام بروكسي من نوع معين (مثل مراكز البيانات)، فقد يعني ذلك أن الحظر تم إعداده بناءً على "IP يبدو كأنه من مركز بيانات"، وليس بناءً على الموقع الجغرافي الحقيقي - في هذه الحالة، سيوفر الاختبار مع بروكسي سكنية صورة أكثر دقة.
الخدمات الجاهزة مقابل الحلول المكتوبة يدويًا
إذا كنت لا ترغب في دعم سكريبت خاص بك، هناك خدمات جاهزة للمراقبة الاصطناعية في السوق مع نقاط وجود في دول مختلفة: Pingdom، Uptrends، Site24x7، Checkly. إنها تخلصك من الحاجة إلى إعداد البنية التحتية، لكنها عادةً ما تكون محدودة بمجموعة ثابتة من المواقع ولا توفر مرونة في اختيار نوع IP (سكني، موبايل، مركز بيانات) لاختبار معين.
توفر الحلول المكتوبة يدويًا باستخدام البروكسي مزيدًا من التحكم: يمكنك اختبار الدول التي تهم عملك، والتبديل بين أنواع IP لتشخيص مشكلات معينة (مثل geo-blocking حسب ASN) ودمج المقاييس مباشرة في نظام المراقبة الخاص بك دون وسطاء غير ضروريين. الجمع بين كلا النهجين هو توازن معقول: خدمات جاهزة لمراقبة SLA الأساسية، وسكريبت خاص بالبروكسي لتشخيص المشكلات في مناطق معينة.
الخاتمة
تُظهر المراقبة المحلية من نقطة واحدة فقط جزءًا من الحقيقة حول توفر واجهة برمجة التطبيقات. لرؤية الصورة الحقيقية، يجب قياس زمن الاستجابة، TTFB، زمن حل DNS، وقت التشغيل والاختلافات في المحتوى بشكل منفصل لكل دولة - ويجب القيام بذلك عبر IP يتم توجيهه فعليًا عبر شبكة المنطقة المستهدفة. بدون ذلك، من السهل أن تفوت مشكلة تعيق جزءًا من المستخدمين عن استخدام الخدمة، بينما تظهر لوحة التحكم "كل شيء أخضر".
لبناء مثل هذه المراقبة، تعتبر البروكسي السكنية هي الأنسب إذا كان من المهم رؤية ما يراه المستخدم الحقيقي مع الإنترنت المنزلي في دولة معينة. بالنسبة للاختبارات الأساسية الأرخص والأسرع، يمكن استخدام بروكسي مراكز البيانات، ولتشخيص المشكلات لدى الجمهور المحمول، يجب إضافة اختبار عبر بروكسي موبايل. يوفر هذا النهج المدمج صورة كاملة عن كيفية ظهور واجهة برمجة التطبيقات الخاصة بك من أي نقطة في العالم، وليس فقط من الخادم الذي تم نشره عليه.