إذا كانت البروكسي تُستخدم في الإنتاج - لعمليات التحليل، أو أتمتة حسابات وسائل التواصل الاجتماعي، أو إدارة حسابات متعددة على نطاق واسع - فإن اللحظة ستأتي عاجلاً أو آجلاً عندما يتوقف "يبدو أنه يعمل" عن كونه إجابة كافية. نحن بحاجة إلى الأرقام: كم عدد الطلبات التي تفشل مع خطأ، وكم زادت فترة التأخير بعد تغيير مجموعة IP، وهل تم استنفاد حد حركة المرور لدى المزود. نستعرض 7 مقاييس يجب جمعها في Prometheus وعرضها في Grafana لرؤية المشكلات قبل أن يلاحظها المستخدمون أو الحسابات المحظورة.
لماذا يجب مراقبة البروكسي في الإنتاج
البروكسي ليست بنية تحتية ثابتة مثل الخادم ذو IP ثابت. إنها مجموعة عناوين تتغير باستمرار، وسلوكها يعتمد على المزود، الحمل، المنطقة، وحتى وقت اليوم. بدون مراقبة، ستكتشف المشكلة فقط عندما يتوقف محلل Wildberries أو Ozon عن تقديم البيانات، أو عندما يقوم حساب Facebook Ads بحظر الحساب، أو عندما يبدأ سكربت الأتمتة في Instagram بإظهار كابتشا.
مهمة المراقبة هي تحويل "هناك شيء غير صحيح" من شعور ذاتي إلى أرقام محددة: نسبة الأخطاء زادت من 2% إلى 15% خلال الساعة الماضية، ومتوسط التأخير زاد ثلاث مرات، وحركة المرور عبر بروكسي واحد تجاوزت الحد. هذا يسمح بالاستجابة قبل أن تصبح المشكلة حرجة - من خلال التبديل تلقائيًا إلى مجموعة أخرى، أو استبدال المزود، أو تقليل تكرار الطلبات.
لجمع المقاييس، نستخدم مجموعة Prometheus (تخزين السلاسل الزمنية) + Grafana (العرض والتنبيهات). هذه هي مجموعة قياسية في DevOps، والتي تتكامل بسهولة مع أي لغة - Python، Node.js، Go. أدناه - أمثلة على Python باستخدام مكتبة prometheus_client، ولكن المبدأ عالمي.
المقياس 1: معدل النجاح - نسبة الطلبات الناجحة
هذه هي المقياس الأساسي الذي يشير أولاً إلى المشكلات مع مجموعة البروكسي. يتم حسابه كنسبة الطلبات التي تحمل رمز الاستجابة 200-299 إلى العدد الإجمالي للطلبات خلال فترة زمنية. عادة ما يعني انخفاض معدل النجاح تحت 90% أن جزءًا من IP في المجموعة محظور من قبل الموقع المستهدف أو أن المزود يقدم عناوين غير مستقرة.
مثال على الأداة في Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'إجمالي الطلبات عبر البروكسي',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # نقطة النهاية لجمع Prometheus
استعلام PromQL لحساب معدل النجاح خلال آخر 5 دقائق:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
إذا كنت تعمل مع عدة أنواع من البروكسي في نفس الوقت - على سبيل المثال، بروكسي سكنية لوسائل التواصل الاجتماعي وبروكسي مراكز البيانات لعمليات التحليل - فمن المنطقي تقسيم معدل النجاح حسب العلامة proxy_pool لرؤية أي مجموعة تتدهور.
المقياس 2: التأخير - زمن الاستجابة
التأخير يظهر مدى سرعة استجابة البروكسي. غالبًا ما يسبق الارتفاع الحاد في التأخير انخفاض معدل النجاح - يكون المزود مثقلاً، أو أن IP قريب من الحظر ويبدأ الخادم المستهدف في إبطاء الاستجابات عمدًا. من المهم جمع التأخير ليس فقط كمتوسط، ولكن أيضًا كالنسب المئوية - p50، p95، p99، حيث أن المتوسط يخفي التأخيرات الطرفية التي تعيق العمل فعليًا.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'مدة الطلب عبر البروكسي',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
استعلام PromQL للتأخير p95:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
بالنسبة للمهام التي تكون فيها السرعة حرجة - على سبيل المثال، عند أتمتة إعلانات TikTok، حيث تزيد كل ثانية في تحميل الصفحة من خطر انتهاء المهلة في متصفح مضاد للكشف - من الأفضل إعداد تنبيه على p95 أعلى من 3-4 ثوانٍ.
المقياس 3: معدل الأخطاء حسب أنواع الأخطاء
لا يكفي مجرد النجاح/الفشل للتشخيص. يجب فصل الأخطاء حسب الأنواع: 407 (يتطلب مصادقة البروكسي) تعني وجود مشكلة في المصادقة، 429 (طلبات كثيرة جدًا) تعني تجاوز حد الطلبات، انتهاء المهلة يعني مشكلة في الشبكة، 403 تعني الحظر بسبب حماية مكافحة الروبوتات للموقع المستهدف. كل نوع من الأخطاء يتطلب استجابة مختلفة.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'أخطاء البروكسي حسب النوع',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
جدول الأخطاء الشائعة وأسبابها:
| الرمز/النوع | السبب المحتمل | ما يجب التحقق منه |
|---|---|---|
| 407 | بيانات اعتماد غير صحيحة أو جلسة منتهية | اسم المستخدم/كلمة المرور للبروكسي، تنسيق سلسلة الاتصال |
| 429 | تجاوز حد الطلبات على IP | تكرار الطلبات، حجم المجموعة |
| 403 | حماية مكافحة الروبوتات للموقع المستهدف | User-Agent، بصمة، نوع البروكسي |
| timeout | تحميل زائد للمزود أو الشبكة | الحمل على المجموعة، إعدادات انتهاء المهلة للعميل |
المقياس 4: سرعة التدوير ومدة حياة IP
إذا كنت تستخدم بروكسي دوارة، فمن المهم معرفة مدى تكرار تغيير IP وكم عدد الطلبات التي يمكن أن تمر قبل أن "تحترق" (تحظرها الموقع المستهدف). هذه المقياس حرج بشكل خاص لإدارة الحسابات المتعددة - على سبيل المثال، عند إنشاء حسابات إعلانات Facebook عبر Dolphin Anty أو AdsPower، حيث يمكن أن تؤدي التغييرات المبكرة في IP إلى قطع الجلسة وتفعيل فحص الأمان.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'مدة حياة IP قبل التدوير',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'عدد الطلبات التي مرت قبل حظر IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
بالنسبة للبروكسي المحمولة، يتصرف هذا المقياس بشكل مختلف عن البروكسي السكنية - التدوير عبر تغيير محطة قاعدة المشغل يعطي IP "أنظف" مع احتمال أقل للحظر. إذا كانت مهمتك هي أتمتة وسائل التواصل الاجتماعي مع حساسية عالية للحظر، فمن الأفضل مقارنة مؤشرات مدة حياة IP بين البروكسي المحمولة والسكنية بناءً على بيانات حقيقية من لوحة المعلومات الخاصة بك، بدلاً من الاعتماد على التوصيات العامة.
المقياس 5: عرض النطاق الترددي - استهلاك حركة المرور
يتم احتساب معظم خطط البروكسي بناءً على حجم حركة المرور، وليس عدد الطلبات. بدون مراقبة، من السهل أن تفوت اللحظة التي يكون فيها الحد قريبًا من الانتهاء - خاصة إذا كانت المهمة تشمل تحميل الصور أو الفيديو، مثل عند تحليل بطاقات المنتجات في Wildberries مع عدد كبير من الصور.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'حركة المرور المستهلكة عبر البروكسي',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
من المفيد في لوحة معلومات Grafana بناء قيمة حركة المرور ليس كقيمة مطلقة، ولكن كسرعة استهلاكها (rate) - يساعد ذلك في التنبؤ بموعد انتهاء الحد، والتخطيط مسبقًا للشراء أو التبديل إلى مجموعة أخرى.
المقياس 6: التوزيع الجغرافي والتوافق مع المنطقة
بالنسبة للمسوقين الذين يختبرون الإعلانات من دول مختلفة، وللوسطاء الذين يعملون مع الاستهداف الجغرافي في Google Ads أو TikTok Ads، من الضروري أن يتوافق IP فعليًا مع المنطقة المعلنة. يمكن أن تؤدي خطأ في الجغرافيا إلى عرض الإعلانات لجمهور غير صحيح أو حظر الحساب بسبب عدم توافق إعدادات الجغرافيا.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'حالات عدم تطابق الجغرافيا المعلنة والفعلية',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
يُوصى بالتحقق من الجغرافيا ليس في كل طلب (هذا مكلف من حيث حركة المرور والوقت)، ولكن بشكل دوري - مرة واحدة في الساعة على عينة من IP من المجموعة، كافية للحصول على ثقة إحصائية.
المقياس 7: الاتصالات المتزامنة - الجلسات المتوازية
عدد الاتصالات المتزامنة عبر البروكسي يظهر الحمل الفعلي على المجموعة. إذا كانت الجلسات المتوازية أكثر من عدد IP في المجموعة التي يمكنها المعالجة دون تدهور، فإن ذلك يؤدي مباشرة إلى زيادة التأخير ومعدل الأخطاء من النقاط السابقة. هذه المقياس مهمة بشكل خاص عند التوسع - عندما تزيد وكالة وسائل التواصل الاجتماعي عدد الحسابات النشطة في نفس الوقت من 10 إلى 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'الاتصالات النشطة الحالية عبر البروكسي',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
مقارنة هذه المقياس مع معدل الأخطاء على نفس الرسم البياني في Grafana ستظهر بسرعة العلاقة: بمجرد أن يتجاوز عدد الجلسات المتوازية حدًا معينًا، تبدأ الأخطاء في الزيادة بشكل غير خطي.
إعداد لوحة المعلومات في Grafana: خطوة بخطوة
بعد أن تم تجهيز المقاييس وجمعها بواسطة Prometheus، يجب عرض البيانات في Grafana. خطوات العمل:
- أضف Prometheus كمصدر بيانات: Configuration → Data Sources → Add data source → Prometheus، وحدد عنوان URL لخادم Prometheus الخاص بك (عادةً
http://localhost:9090). - أنشئ لوحة معلومات جديدة: Create → Dashboard → Add new panel.
- للوحة معدل النجاح، استخدم استعلام PromQL من قسم المقياس 1، نوع العرض - Gauge أو Time series.
- للتأخير، أنشئ لوحة من نوع Heatmap، لرؤية توزيع p50/p95/p99 عبر الزمن.
- للمعدل الأخطاء، قم ببناء مخطط شريطي مكدس مع تقسيم حسب العلامة
error_type- هذا سيظهر بوضوح أي نوع من الأخطاء هو السائد. - أضف متغير لوحة المعلومات (Dashboard Settings → Variables) لـ
proxy_pool، للتبديل بين المجموعات دون إنشاء لوحات معلومات منفصلة. - احفظ لوحة المعلومات واضبط التحديث التلقائي كل 30 ثانية للمراقبة القريبة من الوقت الحقيقي.
يمكن تصدير JSON للوحة المعلومات الجاهزة عبر Share → Export → Save to file وإعادة استخدامها لمجموعات بروكسي مختلفة - سكنية، محمولة ومراكز بيانات، مع تغيير قيمة المتغير فقط.
التنبيهات: متى يجب اتخاذ الإجراءات
لوحة المعلومات غير مفيدة إذا لم ينظر إليها أحد في وقت الحادث. لذلك، من الضروري إعداد التنبيهات في Grafana (Alerting → Alert rules) مع القيم الحدية التالية، التي تم اختيارها لمعظم سيناريوهات الإنتاج:
| المقياس | حد التنبيه | الإجراء |
|---|---|---|
| معدل النجاح | أقل من 85% خلال 5 دقائق | تحقق من المجموعة، التبديل إلى الاحتياطي |
| p95 تأخير | أكثر من 5 ثوانٍ | تقليل التوازي، تحقق من المزود |
| معدل 429 | أكثر من 10% من الطلبات | تقليل تكرار الطلبات، زيادة مجموعة IP |
| معدل عرض النطاق الترددي | توقع نفاد الحد خلال 24 ساعة | شراء المزيد من حركة المرور أو تحسين الطلبات |
من الأفضل توجيه التنبيهات إلى Telegram أو Slack عبر webhook - فهذا يضمن استجابة فورية، بدلاً من التحقق من لوحة المعلومات مرة واحدة في اليوم.
الخاتمة
توفر سبع مقاييس - معدل النجاح، التأخير، معدل الأخطاء حسب الأنواع، مدة حياة IP، حركة المرور، التوافق الجغرافي والتزامن في الاتصالات - صورة كاملة عن صحة بنية البروكسي في الإنتاج. مجموعة Prometheus + Grafana لا تسمح فقط بتوثيق المشكلة بعد حدوثها، بل رؤية الاتجاهات والاستجابة قبل أن يؤدي تدهور المجموعة إلى حظر الحسابات أو توقف عمليات التحليل.
يؤثر اختيار نوع البروكسي مباشرة على المقاييس التي ستكون ذات أولوية: بالنسبة للمهام ذات الحساسية العالية للحظر، مثل إدارة الحسابات المتعددة في Instagram أو TikTok، من الأفضل مراقبة مدة حياة IP ومعدل النجاح أولاً، باستخدام بروكسي سكنية لتحقيق أقصى قدر من التشابه مع حركة المرور الحقيقية للمستخدمين. بالنسبة للمهام التي تكون فيها السرعة والحجم مهمة - مثل التحليل الجماعي لـ Ozon، Avito أو Yandex.Market - تبرز التأخيرات وعرض النطاق الترددي، وغالبًا ما تعمل بروكسي مراكز البيانات بشكل أكثر فعالية بفضل سعة التحميل الأعلى.