કિલ સ્વિચ પરીક્ષણ: ફક્ત ફરી જોડાણ નહીં, અંતરાલ માપો

એક સેકન્ડમાં પૂરું થતું ફરી જોડાણ કહે છે કે ક્લાયન્ટ ઝડપી છે. તે નથી કહેતું કે ટનલ બંધ હતી ત્યારે કંઈ ભાગી ગયું કે નહીં. એક મિનિટ લેતું ફરી જોડાણ કહે છે કે ક્લાયન્ટ ધીમો છે, અને તોપણ નથી કહેતું કે અંતરાલમાં સીધો ટ્રાફિક મંજૂર હતો કે નહીં. આ બે માપ છે, અને જે કિલ સ્વિચ પરીક્ષણ ફક્ત પ્રથમની જાણ કરે છે તેણે સ્વિચનું પરીક્ષણ કર્યું નથી.

બે નિરીક્ષણ, બે અલગ ચુકાદા

ઉપલબ્ધતાનો પ્રશ્ન સરળ છે: ટનલ ફરી ક્યારે વાપરી શકાય તેવી બની, અને ત્યાં પહોંચવા માટે સુરક્ષિત એપ્લિકેશનને નવું જોડાણ જોઈતું હતું કે નહીં. અમલીકરણનો પ્રશ્ન અલગ છે: સુરક્ષા પડી તે ક્ષણથી પાછી આવી તે ક્ષણ સુધી કયા પેકેટ મશીનમાંથી નીકળ્યા.

અલગ રેકોર્ડ સાથે તેમના જવાબ આપો. એક લીટી કહે છે કે અંતરાલ ચોક્કસ સંખ્યાની સેકન્ડ ચાલ્યું. બીજી લીટી કહે છે કે તે અંતરાલ દરમિયાન કોઈ અસુરક્ષિત વિનંતી સફળ થઈ કે નહીં. તેમને એક જ પાસ કે ફેલમાં ભેગા કરવાથી સૌથી મહત્ત્વનો કિસ્સો છૂપાઈ જાય છે: લીક સાથેનું ઝડપી ફરી જોડાણ.

એવી પ્રોબ બનાવો જેનો સમય માપી શકાય

એવી વિનંતી વાપરો જે હાનિકારક નથી, સસ્તી છે અને ટનલની પોતાની નિયંત્રણ ચેનલથી સ્વતંત્ર છે. નીચેનું લૂપ સેકન્ડમાં એક વાર ટાઇમસ્ટેમ્પ, 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'

સોકેટનો શરૂ થવાનો સમય ડિસ્કનેક્શનના ટાઇમસ્ટેમ્પ સાથે સરખાવો. ખામીથી જૂનું જોડાણ સોકેટના પુનર્વપરનો પુરાવો છે, લીકનો નહીં, અને તેને નિષ્ફળતા તરીકે જાણ કરવાથી આગળની વ્યક્તિ એવી બગ શોધવા જાય છે જે અસ્તિત્વમાં નથી.

પરિણામ એવા સ્વરૂપમાં નોંધો જે અપડેટ પછી ટકી રહે

ટ્રિગર, સેકન્ડમાં અંતરાલ, કોઈ અવરોધિત ન હોય તેવી વિનંતી સફળ થઈ કે નહીં, નામ ઉકેલ સફળ થયો કે નહીં, અને ક્લાયન્ટ તથા ઓપરેટિંગ સિસ્ટમની આવૃત્તિઓ લખો. પાંચ તથ્યોનો આ સમૂહ આવૃત્તિઓ વચ્ચે સરખાવી શકાય છે, જે એક ગદ્ય ફકરો કરી શકતો નથી.

ક્લાયન્ટ અપડેટ અથવા પ્રોફાઇલ ફેરફાર પછી એ જ પરીક્ષણ ફરી ચલાવો, કારણ કે અવરોધ વર્તન અમલીકરણની વિગત છે અને તે ખસે છે. રેકોર્ડનો હેતુ ઘટના બનતા પહેલાં ખસેડવાનું ધ્યાનમાં લેવું છે, ક્લાયન્ટને એક વાર પ્રમાણિત કરવો નહીં.