किल स्विच चाचणी: फक्त पुन्हा जोडणी नाही, अंतर मोजा

एका सेकंदात पूर्ण होणारी पुन्हा जोडणी सांगते की क्लायंट वेगवान आहे. टनेल बंद असताना काही सुटले का हे ती सांगत नाही. एक मिनिट लागणारी पुन्हा जोडणी सांगते की क्लायंट संथ आहे, आणि अंतरात थेट रहदारीला परवानगी होती का हे तरीही सांगत नाही. ही दोन मापे आहेत, आणि फक्त पहिल्याची नोंद करणारी किल स्विच चाचणी स्विचची चाचणी केलेली नाही.

दोन निरीक्षणे, दोन वेगळे निवाडे

उपलब्धतेचा प्रश्न सोपा आहे: टनेल पुन्हा कधी वापरण्यायोग्य झाले, आणि तिथवर पोहोचण्यासाठी संरक्षित अनुप्रयोगाला नवीन जोडणी लागली का. अंमलबजावणीचा प्रश्न वेगळा आहे: संरक्षण पडल्याच्या क्षणापासून ते परत आल्याच्या क्षणापर्यंत कोणती पॅकेट मशीनमधून बाहेर पडली.

त्यांना वेगळ्या नोंदींनी उत्तर द्या. एक ओळ सांगते की अंतर ठराविक सेकंद टिकले. दुसरी ओळ सांगते की त्या अंतरात संरक्षण नसलेली विनंती यशस्वी झाली का. त्यांना एकाच पास किंवा फेलमध्ये एकत्र केल्यास सर्वात महत्त्वाची स्थिती लपते: गळतीसह वेगवान पुन्हा जोडणी.

वेळ मोजता येणारी प्रोब तयार करा

अशी विनंती वापरा जी हानीकारक नाही, स्वस्त आहे आणि टनेलच्या स्वतःच्या नियंत्रण चॅनेलपासून स्वतंत्र आहे. खालील लूप दर सेकंदाला एकदा टाइमस्टॅम्प, HTTP स्थिती आणि गेलेला वेळ छापतो, आणि अडकून राहण्याऐवजी मोठ्याने अयशस्वी होतो:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

फक्त स्थिती नाही, curl चे एक्झिट कोड वाचा. 28 म्हणजे विनंतीची वेळ संपली, अवरोधित मार्ग असाच दिसतो. 6 म्हणजे नाव विश्लेषण अयशस्वी झाले, हा वेगळा शोध आहे आणि बहुतेक वेळा अधिक मनोरंजक. अंतरात कमी गेलेल्या वेळेसह 200 म्हणजे रहदारीला बाहेर जाऊ दिले.

आउटपुट फाइलमध्ये लिहा आणि ठेवा. टर्मिनलचा स्क्रोलबॅक पुरावा नाही, आणि मनोरंजक भाग सहसा मधल्या तीन ओळी असतात.

खरे अपयश घडवा, नीटनेटके नाही

क्लायंटच्या स्वतःच्या मेनूमधून डिस्कनेक्ट करणे सहकार्य मार्गाची चाचणी करते, जिथे क्लायंटकडे त्याचे अवरोध नियम बसवण्याची वेळ असते. त्याऐवजी प्रक्रिया मारा, किंवा खालची लिंक तोडा, मग खरे अपयश ज्या मार्गाने जाते त्याची चाचणी होते.

प्रत्येक ट्रिगर वेगळ्या कोड मार्गाचा सराव करतो. सर्व्हर बाजूचा व्यत्यय, स्थानिक लिंकची हानी आणि क्लायंट क्रॅश प्रत्येकी वेगळी स्थिती मागे ठेवू शकतात, आणि त्यातील एक शेवटी भेटणारी स्थिती असण्याची शक्यता आहे. प्रोब किमान दोन ट्रिगरवर चालवा आणि निकाल ट्रिगरनुसार लेबल करा.

परवानगी दिलेली रहदारी कशी दिसते हे लॉगमध्ये पाहा

अंतरात 200 किंवा वेगवान जोडणी अपयश म्हणजे गळती, ती कोणत्याही दिशेने असो. संपूर्ण अंतरात वेळ संपणे हा अवरोध धोरणाचा अपेक्षित आकार आहे. जोडण्या अयशस्वी होत असताना नाव विश्लेषण यशस्वी होणे म्हणजे रिझॉल्व्हर अजून पोहोचण्यायोग्य आहे, ही दुसऱ्या प्रकारची गळती.

सध्याच्या सॉकेटला काळजी लागते. प्रोग्राम डिस्कनेक्टपूर्वी उघडलेली जोडणी वापरत राहू शकतो, त्यामुळे जिवंत दिसणारी रहदारी नवीन मार्गाला परवानगी होती हे सिद्ध करू शकत नाही. सॉकेट यादी दाखवते की जोडणी घटनेपूर्वीची आहे का:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

सॉकेटची सुरुवात वेळ डिस्कनेक्टच्या टाइमस्टॅम्पशी तुलना करा. व्यत्ययापेक्षा जुनी जोडणी सॉकेटच्या पुनर्वापराचा पुरावा आहे, गळतीचा नाही, आणि ती अपयश म्हणून नोंदवल्यास पुढच्या व्यक्तीला नसलेली बग शोधायला पाठवले जाते.

निकाल अशा स्वरूपात नोंदवा जो अद्यतनानंतर टिकतो

ट्रिगर, सेकंदांतील अंतर, काही अवरोधित नसलेली विनंती यशस्वी झाली का, नाव विश्लेषण यशस्वी झाले का, आणि क्लायंट व ऑपरेटिंग सिस्टमच्या आवृत्त्या लिहा. पाच तथ्यांचा हा संच आवृत्त्यांमध्ये तुलनीय आहे, जे एक गद्य परिच्छेद करू शकत नाही.

क्लायंट अद्यतन किंवा प्रोफाइल बदलानंतर तीच चाचणी पुन्हा चालवा, कारण अवरोध वर्तन हे अंमलबजावणीचे तपशील आहे आणि ते सरकते. नोंदीचा उद्देश घटना होण्यापूर्वी सरकणे लक्षात घेणे आहे, क्लायंट एकदा प्रमाणित करणे नाही.