7 प्रॉक्सी मीट्रिक्स ग्राफ़ाना और प्रोमेथियस के लिए प्रोडक्शन में

यदि प्रॉक्सी प्रोडक्शन में उपयोग की जाती हैं - डेटा पार्सिंग, SMM-खातों का स्वचालन या बड़े पैमाने पर मल्टी-खातों के लिए - तो एक न एक दिन ऐसा क्षण आता है जब "लगभग काम कर रहा है" पर्याप्त उत्तर नहीं होता। आंकड़ों की आवश्यकता होती है: कितने अनुरोध त्रुटि के साथ गिरते हैं, IP पूल बदलने के बाद विलंबता कितनी बढ़ गई है, क्या प्रदाता के पास ट्रैफ़िक की सीमा समाप्त नहीं हुई है। हम 7 मेट्रिक्स पर चर्चा करते हैं, जिन्हें Prometheus में एकत्र करना और Grafana में विज़ुअलाइज़ करना चाहिए, ताकि समस्याओं को उपयोगकर्ताओं या ब्लॉक किए गए खातों से पहले देखा जा सके।

प्रोडक्शन में प्रॉक्सी की निगरानी क्यों करें

प्रॉक्सी एक स्थिर अवसंरचना नहीं है जैसे कि एक निश्चित IP वाला सर्वर। यह एक लगातार बदलता हुआ पते का पूल है, जिसका व्यवहार प्रदाता, लोड, क्षेत्र और यहां तक कि दिन के समय पर निर्भर करता है। निगरानी के बिना, आप समस्या के बारे में केवल तब जानेंगे जब Wildberries या Ozon पार्सर डेटा देना बंद कर देता है, Facebook Ads विज्ञापन खाता खाता ब्लॉक कर देता है, या Instagram स्वचालन स्क्रिप्ट कैप्चा में गिरने लगती है।

निगरानी का कार्य "कुछ ठीक नहीं है" को विशिष्ट आंकड़ों में बदलना है: पिछले घंटे में त्रुटियों का अनुपात 2% से 15% तक बढ़ गया, औसत विलंबता तीन गुना बढ़ गई, एक प्रॉक्सी पर ट्रैफ़िक सीमा से अधिक हो गया। यह समस्या के गंभीर होने से पहले प्रतिक्रिया करने की अनुमति देता है - स्वचालित रूप से पूल स्विच करना, प्रदाता को बदलना या अनुरोधों की आवृत्ति को कम करना।

मेट्रिक्स को एकत्र करने के लिए हम Prometheus (समय श्रृंखला का भंडारण) + Grafana (विज़ुअलाइज़ेशन और अलर्ट) का संयोजन उपयोग करते हैं। यह DevOps में मानक स्टैक है, जो किसी भी भाषा के साथ आसानी से एकीकृत होता है - Python, Node.js, Go। नीचे - prometheus_client पुस्तकालय के साथ Python में उदाहरण, लेकिन सिद्धांत सार्वभौमिक है।

मेट्रिक 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 स्क्रैप के लिए एंडपॉइंट

पिछले 5 मिनटों में सफलता दर की गणना के लिए PromQL प्रश्न:

sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100

यदि आप एक साथ कई प्रकार की प्रॉक्सी के साथ काम कर रहे हैं - उदाहरण के लिए, रेसिडेंशियल प्रॉक्सी सोशल मीडिया के लिए और डेटा सेंटर प्रॉक्सी पार्सिंग के लिए - तो सफलता दर को proxy_pool लेबल के अनुसार विभाजित करना समझदारी है, ताकि यह देखा जा सके कि कौन सा पूल वास्तव में खराब हो रहा है।

मेट्रिक 2: विलंबता - उत्तर की देरी

विलंबता यह दिखाती है कि प्रॉक्सी कितनी तेजी से उत्तर देती है। विलंबता में अचानक वृद्धि अक्सर सफलता दर में गिरावट से पहले होती है - प्रदाता ओवरलोड होता है, या IP पहले से ही ब्लॉक के करीब है और लक्षित सर्वर जानबूझकर उत्तरों को धीमा करना शुरू कर देता है। विलंबता के लिए, केवल औसत मान को एकत्र करना महत्वपूर्ण नहीं है, बल्कि प्रतिशतiles - 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)

p95 विलंबता के लिए PromQL:

histogram_quantile(0.95,
  sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)

उन कार्यों के लिए जहां गति महत्वपूर्ण है - उदाहरण के लिए, TikTok Ads के स्वचालन में, जहां पृष्ठ लोड होने में हर सेकंड टाइमआउट के जोखिम को बढ़ाता है - 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	लक्षित साइट की एंटी-बॉट सुरक्षा	यूजर-एजेंट, फिंगरप्रिंट, प्रॉक्सी का प्रकार
timeout	प्रदाताओं या नेटवर्क का ओवरलोड	पूल पर लोड, क्लाइंट के टाइमआउट सेटिंग्स

मेट्रिक 4: रोटेशन की गति और IP की जीवितता

यदि आप घूर्णन प्रॉक्सी का उपयोग कर रहे हैं, तो यह जानना महत्वपूर्ण है कि IP कितनी बार बदलता है और कितने अनुरोधों को "जलने" (लक्षित साइट द्वारा प्रतिबंधित) से पहले गुजरने की अनुमति है। यह मेट्रिक विशेष रूप से मल्टी-खातों के लिए महत्वपूर्ण है - उदाहरण के लिए, Dolphin Anty या AdsPower के माध्यम से Facebook Ads खातों की खेती करते समय, जहां 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 देता है, जिसमें बैन होने की संभावना कम होती है। यदि आपका कार्य वास्तव में SMM स्वचालन है जिसमें बैन के प्रति उच्च संवेदनशीलता है, तो वास्तविक डेटा से अपने डैशबोर्ड में मोबाइल प्रॉक्सी और रेसिडेंशियल के बीच 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 बिना गिरावट के संभाल सकता है, तो यह सीधे पिछले बिंदुओं से विलंबता और त्रुटि दर में वृद्धि की ओर ले जाता है। यह मेट्रिक विशेष रूप से स्केलिंग के दौरान महत्वपूर्ण है - जब SMM एजेंसी ग्राहकों के साथ काम करने वाले खातों की संख्या को 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, अपने Prometheus सर्वर का URL निर्दिष्ट करें (आमतौर पर http://localhost:9090).
एक नया डैशबोर्ड बनाएं: Create → Dashboard → Add new panel.
सफलता दर के पैनल के लिए मेट्रिक 1 के अनुभाग से PromQL प्रश्न का उपयोग करें, विज़ुअलाइज़ेशन का प्रकार - Gauge या Time series।
विलंबता के लिए, p50/p95/p99 के वितरण को देखने के लिए Heatmap प्रकार के पैनल का निर्माण करें।
त्रुटि दर के लिए, error_type लेबल के अनुसार विभाजित Stacked Bar Chart बनाएं - यह स्पष्ट रूप से दिखाएगा कि कौन सा त्रुटि प्रकार प्रमुख है।
डैशबोर्ड के लिए एक चर जोड़ें (Dashboard Settings → Variables) proxy_pool के लिए, ताकि बिना अलग डैशबोर्ड बनाए पूलों के बीच स्विच किया जा सके।
डैशबोर्ड को सहेजें और 30 सेकंड में एक बार ऑटो-अपडेट करने के लिए सेट करें ताकि निकट-वास्तविक समय की निगरानी हो सके।

तैयार JSON डैशबोर्ड को Share → Export → Save to file के माध्यम से निर्यात किया जा सकता है और विभिन्न प्रॉक्सी पूलों - रेसिडेंशियल, मोबाइल और डेटा सेंटर के लिए पुनः उपयोग किया जा सकता है, केवल चर का मान बदलकर।

अलर्ट: कार्रवाई करने का समय कब है

डैशबोर्ड बेकार है, यदि कोई घटना के क्षण में उस पर नहीं देखता है। इसलिए Grafana में अलर्ट सेट करना महत्वपूर्ण है (Alerting → Alert rules) निम्नलिखित थ्रेशोल्ड मानों के साथ, जो अधिकांश प्रोडक्शन परिदृश्यों के लिए उपयुक्त हैं:

मेट्रिक	अलर्ट थ्रेशोल्ड	क्रिया
सफलता दर	5 मिनट में 85% से कम	पूल की जांच करें, बैकअप पर स्विच करें
p95 विलंबता	5 सेकंड से अधिक	समांतरता को कम करें, प्रदाता की जांच करें
दर 429	10% से अधिक अनुरोध	अनुरोधों की आवृत्ति को कम करें, IP पूल बढ़ाएं
बैंडविड्थ दर	24 घंटे में सीमा समाप्त होने का पूर्वानुमान	ट्रैफ़िक खरीदें या अनुरोधों को अनुकूलित करें

अलर्ट को Telegram या Slack में webhook के माध्यम से भेजना बेहतर है - यह तात्कालिक प्रतिक्रिया सुनिश्चित करता है, न कि दिन में एक बार डैशबोर्ड की जांच करने के लिए।

निष्कर्ष

सात मेट्रिक्स - सफलता दर, विलंबता, त्रुटि दर प्रकारों के अनुसार, IP की जीवितता, ट्रैफ़िक, भू-आवंटन और समवर्ती कनेक्शन - प्रोडक्शन में प्रॉक्सी अवसंरचना की स्वास्थ्य की पूरी तस्वीर प्रदान करते हैं। Prometheus + Grafana का संयोजन केवल समस्या को बाद में दर्ज करने की अनुमति नहीं देता, बल्कि प्रवृत्तियों को देखने और प्रतिक्रिया करने की अनुमति देता है इससे पहले कि पूल की गिरावट खातों के प्रतिबंध या पार्सिंग को रोक दे।

प्रॉक्सी के प्रकार का चयन सीधे इस पर प्रभाव डालता है कि कौन सी मेट्रिक्स प्राथमिकता में होंगी: उच्च बैन संवेदनशीलता वाले कार्यों के लिए, जैसे Instagram या TikTok में मल्टी-खातों का स्वचालन, IP की जीवितता और सफलता दर की निगरानी करना सबसे पहले होना चाहिए, रेसिडेंशियल प्रॉक्सी का उपयोग करते हुए उपयोगकर्ताओं के वास्तविक ट्रैफ़िक के साथ अधिकतम समानता के लिए। उन कार्यों के लिए जहां गति और मात्रा महत्वपूर्ण हैं - Ozon, Avito या Yandex.Market का बड़े पैमाने पर पार्सिंग - विलंबता और बैंडविड्थ प्राथमिकता में आते हैं, और यहां अक्सर डेटा सेंटर प्रॉक्सी अधिक उच्च थ्रूपुट के कारण अधिक प्रभावी होती हैं।