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

एक सेकेन्डमा सकिने फेरि जडानले क्लाइन्ट छिटो छ भनी बताउँछ। टनेल बन्द हुँदा केही भाग्यो कि भन्ने भने बताउँदैन। एक मिनेट लाग्ने फेरि जडानले क्लाइन्ट सुस्त छ भनी बताउँछ, र अन्तरालमा सिधा ट्राफिकलाई अनुमति थियो कि भन्ने पनि बताउँदैन। यी दुई मापन हुन्, र पहिलो मात्र रिपोर्ट गर्ने किल स्विच परीक्षणले स्विच परीक्षण गरेको छैन।

दुई अवलोकन, दुई छुट्टै निर्णय

उपलब्धताको प्रश्न सरल छ: टनेल फेरि कहिले प्रयोगयोग्य भयो, र त्यहाँ पुग्न संरक्षित अनुप्रयोगलाई नयाँ जडान चाहियो कि। लागू गर्ने प्रश्न भिन्न छ: संरक्षण खसेको क्षणदेखि फर्किएको क्षणसम्म कुन प्याकेटले मेसिन छोडे।

तिनलाई छुट्टै अभिलेखले जवाफ दिनुहोस्। एउटा लाइनले अन्तराल निश्चित संख्याका सेकेन्ड रह्यो भन्छ। अर्को लाइनले त्यो अन्तरालमा असंरक्षित अनुरोध सफल भयो कि भन्छ। तिनलाई एउटै पास वा फेलमा मिलाउँदा सबैभन्दा महत्त्वपूर्ण अवस्था लुक्छ: चुहावटसहितको छिटो फेरि जडान।

समय मापन गर्न सकिने प्रोब बनाउनुहोस्

यस्तो अनुरोध प्रयोग गर्नुहोस् जो हानिकारक छैन, सस्तो छ र टनेलको आफ्नै नियन्त्रण च्यानलबाट स्वतन्त्र छ। तलको लूपले प्रति सेकेन्ड एक पटक टाइमस्ट्याम्प, 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'

सकेटको सुरु समय विच्छेदको टाइमस्ट्याम्पसँग तुलना गर्नुहोस्। अवरोधभन्दा पुरानो जडान चुहावटको होइन, सकेट पुनःप्रयोगको प्रमाण हो, र यसलाई असफलता भनी रिपोर्ट गर्दा अर्को व्यक्ति नभएको बग खोज्न पठाइन्छ।

नतिजा अपडेटपछि टिक्ने स्वरूपमा नोट गर्नुहोस्

ट्रिगर, सेकेन्डमा अन्तराल, कुनै अवरुद्ध नभएको अनुरोध सफल भयो कि, नाम विश्लेषण सफल भयो कि, र क्लाइन्ट तथा अपरेटिङ सिस्टमका संस्करण लेख्नुहोस्। पाँच तथ्यको यो समूह संस्करणहरूबीच तुलना गर्न सकिन्छ, जो एक गद्य अनुच्छेदले गर्न सक्दैन।

क्लाइन्ट अपडेट वा प्रोफाइल परिवर्तनपछि त्यही परीक्षण फेरि चलाउनुहोस्, किनकि अवरोध व्यवहार कार्यान्वयनको विवरण हो र त्यो सर्छ। अभिलेखको उद्देश्य घटना बन्नुअघि सर्ने कुरा थाहा पाउनु हो, क्लाइन्टलाई एक पटक प्रमाणित गर्नु होइन।