एक प्रॉक्सी आपका IP-जाँच पृष्ठ लाता है पर आपके एप्लिकेशन को जिस API की आवश्यकता है वहाँ विफल हो जाता है। उसे “स्वस्थ” या “मृत” कहने से सबसे उपयोगी तथ्य खो जाता है: दोनों अनुरोध अलग थे।

एंडपॉइंट के लिए एक परिवहन-व्यापी रिकॉर्ड से शुरू करें। क्या आप उसके श्रोता तक पहुँच सकते हैं और आवश्यक प्रॉक्सी वार्ता पूरी कर सकते हैं? गंतव्य-विशिष्ट अवलोकनों को उस रिकॉर्ड के बगल में रखें, उस पर फिर से न लिखें।

अवलोकनजाँच का दायरा
प्रॉक्सी श्रोता कनेक्शन अस्वीकार करता हैएंडपॉइंट और वहाँ तक का मार्ग
प्रॉक्सी एक गंतव्य पोर्ट अस्वीकार करता हैउस गंतव्य के लिए अनुमत ऑपरेशन
एक वेबसाइट खाता त्रुटि लौटाती हैगंतव्य एप्लिकेशन और क्रेडेंशियल
बड़ी प्रतिक्रियाएँ अटकती हैं, छोटी पूरी होती हैंस्थानांतरण कार्यभार और समय-सीमा नीति

एक HTTP प्रतिक्रिया सिद्ध कर सकती है कि किसी अनुरोध पथ ने कुछ लौटाया, फिर भी एप्लिकेशन के लिए वह अनुपयोगी रह सकता है। परिवहन सफलता, HTTP स्थिति और अपेक्षित सामग्री को अलग परिणामों के रूप में रखें।

यदि कोई गंतव्य बार-बार विफल होता है, तो उस एंडपॉइंट-और-गंतव्य जोड़ी को रोकें या जाँचें। हर असंबंधित कार्य के लिए प्रॉक्सी अक्षम करना उपयोगी क्षमता गँवा सकता है। इसके विपरीत, वैश्विक कनेक्शन विफलता एक वेबसाइट के अलग रिकॉर्ड के पीछे छिपी नहीं रहनी चाहिए।

एक व्यावहारिक स्वास्थ्य कुंजी में प्रॉक्सी पहचानकर्ता, गंतव्य सेवा और ऑपरेशन प्रकार शामिल हो सकते हैं। पूरे क्रेडेंशियल-वाहक URL या हर अनोखे संसाधन पथ को लगातार बढ़ती कुंजी के रूप में उपयोग करने से बचें। केवल वहीं समूह बनाएँ जहाँ समूहन अगले अनुरोध के बारे में सार्थक पूर्वानुमान देता है।

उद्देश्य बेहतर रूटिंग साक्ष्य है, हरे बैज का बड़ा संग्रह नहीं। स्वास्थ्य परिणाम को बताना चाहिए कि क्या प्रयास किया गया, कब, और उसने वास्तव में क्या सिद्ध किया।

संबंधित लेख