लोड बैलेंसर, गेटवे या पहली सेवा द्वारा एज पर एक रिक्वेस्ट आईडी जनरेट की जाती है और X-Request-Id जैसे रिस्पॉन्स हेडर में वापस भेजी जाती है। उस रिक्वेस्ट को हैंडल करते समय लिखी गई प्रत्येक लॉग लाइन में यह आईडी होती है, और जब रिक्वेस्ट अन्य सेवाओं तक पहुंचती है तो यह आईडी उसके साथ जाती है, ताकि बाद में पूरे पथ को फिर से जोड़ा जा सके।
क्लाइंट्स को रिपोर्ट की गई किसी भी त्रुटि के साथ आईडी लॉग करनी चाहिए और इसे बग रिपोर्ट में शामिल करना चाहिए; इससे सपोर्ट टीम कुछ ही सेकंड में सर्वर-साइड लॉग्स का सटीक डेटा ढूंढ सकती है। W3C ट्रेस कॉन्टेक्स्ट (ट्रेसपैरेंट हेडर) जैसे डिस्ट्रीब्यूटेड ट्रेसिंग स्टैंडर्ड्स इसी विचार को औपचारिक रूप देते हैं और टाइमिंग के लिए पैरेंट और चाइल्ड स्पैन जोड़ते हैं।
लॉग में अनुरोध खोजने के लिए टाइमस्टैम्प और एंडपॉइंट ही काफी होते हैं। व्यस्त सिस्टम पर प्रति सेकंड हजारों समान कॉल होते हैं। आईडी के बिना, "it failed around 10:42" एक खोज है, न कि खोज परिणाम।
लाइव बैकएंड प्रत्येक प्रतिक्रिया पर एक X-Request-Id हेडर सेट करता है और JSON बॉडी में उसी requestId को शामिल करता है - जिसमें इसकी 500 त्रुटियां भी शामिल हैं, जहां यह एकमात्र विवरण है जिसे यह उजागर करता है।
सभी शब्द · परीक्षण तकनीकें · सभी 39 मॉक REST API
आखरी अपडेट