प्रॉक्सी आरोग्य: तुम्ही कोणती वेबसाइट आणि कोणते ऑपरेशन तपासले?
पुनर्वापरयोग्य प्रॉक्सी पूल राखताना सामान्य प्रॉक्सी पोहोचक्षमता गंतव्य-विशिष्ट अपयशांपासून वेगळी करा.
प्रॉक्सी तुमचे IP-तपासणी पृष्ठ आणते पण तुमच्या अनुप्रयोगाला आवश्यक असलेल्या API वर अपयशी होते. त्याला “निरोगी” किंवा “मृत” म्हणणे सर्वात उपयुक्त तथ्य गमावते: दोन्ही विनंत्या वेगळ्या होत्या.
एंडपॉइंटसाठी वाहतूक-व्यापी नोंदीपासून सुरुवात करा. तुम्ही त्याच्या श्रोत्यापर्यंत पोहोचू शकता आणि आवश्यक प्रॉक्सी वाटाघाटी पूर्ण करू शकता का? गंतव्य-विशिष्ट निरीक्षणे त्या नोंदीवर पुन्हा न लिहिता त्याच्या शेजारी ठेवा.
| निरीक्षण | तपासण्याची व्याप्ती |
|---|---|
| प्रॉक्सी श्रोता जोडण्या नाकारतो | एंडपॉइंट आणि तिथपर्यंतचा मार्ग |
| प्रॉक्सी एक गंतव्य पोर्ट नाकारतो | त्या गंतव्यासाठी परवानगी असलेले ऑपरेशन |
| एक वेबसाइट खाते त्रुटी परत करते | गंतव्य अनुप्रयोग आणि क्रेडेन्शियल्स |
| मोठे प्रतिसाद अडकतात, लहान पूर्ण होतात | हस्तांतरण कार्यभार आणि कालबाह्यता धोरण |
HTTP प्रतिसाद हे सिद्ध करू शकतो की विनंती मार्गाने काहीतरी परत केले आणि तरीही ते अनुप्रयोगासाठी निरुपयोगी राहू शकते. वाहतूक यश, HTTP स्थिती आणि अपेक्षित सामग्री स्वतंत्र परिणाम म्हणून ठेवा.
एखादे गंतव्य सतत अपयशी ठरत असेल, तर ती एंडपॉइंट-आणि-गंतव्य जोडी थांबवा किंवा तपासा. प्रत्येक असंबंधित कामासाठी प्रॉक्सी अक्षम केल्यास उपयुक्त क्षमता वाया जाऊ शकते. उलटपक्षी, जागतिक जोडणी अपयश एका वेबसाइटच्या वेगळ्या नोंदीमागे लपून राहू नये.
व्यावहारिक आरोग्य किल्लीमध्ये प्रॉक्सी ओळख, गंतव्य सेवा आणि ऑपरेशन प्रकार समाविष्ट असू शकतो. संपूर्ण क्रेडेन्शियल-वाहक URL किंवा प्रत्येक अद्वितीय संसाधन मार्ग सतत वाढणारी किल्ली म्हणून वापरणे टाळा. फक्त तिथेच गट करा जिथे गट करणे पुढील विनंतीबद्दल अर्थपूर्ण अंदाज देते.
उद्देश चांगले राउटिंग पुरावे आहे, हिरव्या बॅजचा मोठा संग्रह नाही. आरोग्य परिणामाने सांगावे की काय प्रयत्न केले, केव्हा, आणि त्याने प्रत्यक्षात काय सिद्ध केले.