VPN આરોગ્ય તપાસને એપ્લિકેશન આરોગ્ય તપાસથી અલગ કરો
ચાલતી ટનલ પ્રક્રિયા હોઈ શકે જ્યારે સુરક્ષિત જોડાણ નકામું હોય, અને સુરક્ષિત માર્ગ, DNS અને લક્ષ્ય સ્વતંત્ર રીતે નિષ્ફળ થઈ શકે. દરેક તપાસ તેનું સ્તર અને તે જે ક્રિયા શરૂ કરે છે તેનું નામ આપે.
તમારી ટનલ પ્રક્રિયા ચાલુ હોઈ શકે જ્યારે સુરક્ષિત જોડાણ નકામું હોય, અને નિષ્ફળ જતું વેબ પેજ એ ટનલ તૂટી ગયાનો પુરાવો નથી. જ્યારે એક પ્રોબ બધાનું પ્રતિનિધિત્વ કરે છે, ત્યારે રીસ્ટાર્ટ નીતિ ખોટા ઘટકને ફરી શરૂ કરે છે અને તેને ઓટોમેશન કહે છે. નીચેની દરેક તપાસ તે જે સ્તર નિરીક્ષણ કરે છે, તેની નિષ્ફળતા જે ક્રિયા શરૂ કરે છે, અને તે ક્રિયા કામ કરી તેનો પુરાવો નામ આપે છે. છેલ્લું પગલું આખા સમૂહને એવા પૃષ્ઠમાં ફેરવે છે જેને કોઈ રાત્રે ત્રણ વાગ્યે અનુસરી શકે.
પગલું 1: દરેક તપાસ જે સ્તર નિરીક્ષણ કરે છે તેનું નામ આપો
તેમાંથી કોઈપણ લખતા પહેલા પૂછો કે દરેક પ્રોબ ખરેખર શું જોઈ શકે છે. જીવંતતા સાબિત કરે છે કે ડીમન ચાલુ છે, હેન્ડશેક અથવા પીઅર યાદી સાબિત કરે છે કે સંબંધ અસ્તિત્વમાં છે, રાઉટ થયેલી વિનંતી ડિલિવરી સાબિત કરે છે, અને લુકઅપ રિઝોલ્યુશન સાબિત કરે છે. તેઓ તે જ ક્રમમાં નિષ્ફળ જાય છે, અને તેમાંથી કોઈ પણ આગળના સૂચિત નથી. એક લીલી પ્રક્રિયા તપાસ સાથે મૃત ટનલ સામાન્ય કેસ છે, વિરોધાભાસ નથી.
ચાર તપાસ તે ક્રમમાં લખો, દરેક માટે ચોક્કસ આદેશ અને અપેક્ષિત આઉટપુટ સાથે. જે પ્રોબનું અપેક્ષિત આઉટપુટ તમે કહી શકતા નથી, તેને અલર્ટ જોઈને દરેક ઓપરેટર અલગ રીતે વાંચશે. એ જ યાદી અલર્ટ ટેક્સ્ટમાં મૂકો, ફક્ત રનબુકમાં નહીં, જેથી રાત્રે જગાડાયેલ વ્યક્તિ લક્ષણ પહેલાં સ્તરને મળે. દરેક આદેશ તેને ચલાવતા હોસ્ટ પર કોપી-પેસ્ટ કરવા યોગ્ય રાખો.
પછી એપ્લિકેશન તપાસને પાંચમી, અલગ વસ્તુ તરીકે ઉમેરો. જે પૃષ્ઠની ખાતા સેવા બંધ છે તે ટનલ ફરી શરૂ કરવાનું વાજબીપણું આપતી નથી.
પગલું 2: દરેક નિષ્ફળતાને એક ક્રિયા સાથે જોડો
દરેક તપાસ માટે નક્કી કરો કે શું ફરી શરૂ થાય, શું અવરોધિત રહે અને શું માણસને બોલાવે. ટનલ સ્તરની નિષ્ફળતા ટનલ ફરી શરૂ કરવાનું વાજબીપણું આપી શકે; રિઝોલ્વર નિષ્ફળતા ક્લાયન્ટ પરના DNS એકીકરણ તરફ ઈશારો કરે છે; એપ્લિકેશન સ્તરની નિષ્ફળતાએ લગભગ ક્યારેય ટનલને સ્પર્શવું ન જોઈએ.
નિષ્ફળતાએ શું ન કરવું તે કહો, કારણ કે જોખમી ડિફોલ્ટ તેમને પરવાનગી આપતા હોય છે. અસ્વસ્થ સ્થિતિ ક્યારેય સીધા એપ્લિકેશન ટ્રાફિકની પરવાનગી ન બનવી જોઈએ, કારણ કે ટનલને શાંતિથી ટાળતો ફોલબેક ટનલના અસ્તિત્વનું કારણ દૂર કરે છે. ક્રિયાઓને પણ સાંકડી કરો: એક લક્ષ્ય ધીમું હોવાથી શેર કરેલ ઘટક ફરી શરૂ કરવું સ્થાનિક સમસ્યાને આખા કાફલાની સમસ્યા બનાવે છે. તે કારણ શોધવા માટે જરૂરી પુરાવો પણ નષ્ટ કરે છે.
પગલું 3: પ્રોબને નિરુપદ્રવ અને સસ્તા રાખો
નાની, ફક્ત-વાંચન વિનંતીઓ વાપરો: સ્થિર સંસાધન, તેની પોતાની નિર્ભરતા જણાવતું આરોગ્ય એન્ડપોઈન્ટ, અથવા તમે નિયંત્રિત કરો તે પોર્ટ પર TCP કનેક્શન. ઓળખપત્રો, ખાનગી બ્રાઉઝિંગ અને દરેક અંતરાલે સ્થિતિ બદલતું કંઈપણ ટાળો, કારણ કે લખતો પ્રોબ સમયપત્રક પ્રમાણેની લોડ કસોટી છે.
દરેક પ્રોબ માટે લક્ષ્ય, માર્ગ અપેક્ષા અને ટાઈમઆઉટ નોંધો. માર્ગ અપેક્ષા એ જ ક્ષેત્ર છે જે લોકો છોડી દે છે, અને તે જ ટનલ નિષ્ફળતાને રાઉટિંગ ભૂલથી અલગ પાડે છે જ્યારે તમે પછી અલર્ટ વાંચો. અંતરાલ અને નિષ્ફળતા થ્રેશોલ્ડ તમે વચન આપેલા પુનઃપ્રાપ્તિ સમયમાંથી મેળવો, અને ટાઈમઆઉટ અંતરાલ કરતાં ટૂંકો રાખો. જ્યારે આગલું શરૂ થાય ત્યારે પણ ચાલતું પ્રોબ એક નિષ્ફળતા બે વાર જણાવે છે અને ફ્લેપ જેવું લાગે છે.
પગલું 4: દરેક સ્તર તોડો અને જુઓ યોગ્ય પ્રોબ લાલ થાય છે
ટનલ પ્રક્રિયા બંધ કરો અને ખાતરી કરો કે પ્રક્રિયા તપાસ નિષ્ફળ જાય છે જ્યારે DNS કદાચ કેશમાંથી જવાબ આપી શકે. માર્ગ બદલો અને ખાતરી કરો કે રાઉટ થયેલી વિનંતી નિષ્ફળ જાય છે જ્યારે પ્રક્રિયા અને હેન્ડશેક સ્વસ્થ રહે છે. ફક્ત DNS તોડો અને ખાતરી કરો કે એપ્લિકેશન તપાસ ટનલ ભૂલને બદલે રિઝોલ્યુશન જણાવે છે. જો બે પ્રોબ હંમેશા સાથે ચાલે, તો તમારી પાસે વિચારો કરતાં ઓછી તપાસ છે.
એ જ શિસ્ત સાથે પુનઃપ્રાપ્તિની દિશા ચકાસો. સ્તર પુનઃસ્થાપિત કર્યા પછી પ્રોબને મેન્યુઅલ રીસ્ટાર્ટ વિના સાફ થવું જોઈએ, અને જે ક્રિયા ચાલુ થઈ તે પાછળ કોઈ બાયપાસ છોડવો ન જોઈએ. લીલી સ્થિતિ પર ભરોસો કરતા પહેલા એક પૂર્ણ ચક્ર જુઓ, કારણ કે ફક્ત હાથે સાફ થતો પ્રોબ તૂટેલો પુનઃપ્રાપ્તિ માર્ગ છુપાવે છે.
પગલું 5: રનબુકને જ્યાં અલર્ટ ઈશારો કરે ત્યાં મૂકો
પાંચ પંક્તિઓનું એક પૃષ્ઠ આખી રચના ધરાવે છે: સ્તર, આદેશ, અપેક્ષિત પરિણામ, નિષ્ફળતા પર ક્રિયા, માલિક. દરેક પ્રોબ વિશે એક લીટી ઉમેરો કે તે જાણી જોઈને શું ચકાસતું નથી. એ જ લીટી આગલી વ્યક્તિને છઠ્ઠી તપાસ ઉમેરતા રોકે છે જે બધું માપે છે અને કંઈ જ અલગ પાડતી નથી. અલર્ટ ટેક્સ્ટમાંથી પૃષ્ઠની લિંક આપો, નહીં તો ઘટના જીવંત હોય ત્યારે કોઈ તેને ખોલશે નહીં.
કન્ટેનર ડિપ્લોયમેન્ટમાં, નિર્ભરતા શરત ફક્ત સ્ટાર્ટઅપ ઘડે છે અને બીજું કંઈ નહીં. Compose સ્ટાર્ટઅપ ક્રમ અને આરોગ્ય શરત દસ્તાવેજીકરણ વર્ણવે છે કે તૈયારી સેવાઓ શરૂ થવાનો ક્રમ કેવી રીતે નક્કી કરે છે; તેમાંથી કંઈ પણ પછી એગ્રેસ નીતિ લાગુ કરતું નથી, અને તેમાંથી કંઈ પણ ટનલ પડે ત્યારે બંધ થઈને નિષ્ફળ થતું નથી. સતત અમલીકરણને તેની પોતાની નીતિ અને તેનો પોતાનો પ્રોબ જોઈએ, એ જ પૃષ્ઠ પર લખેલા.
રનબુક ત્યારે પૂર્ણ થાય છે જ્યારે યોગ્ય સ્તર પુનઃપ્રાપ્ત થાય અને કોઈ અનુપલબ્ધ વેબસાઈટને તૂટેલી ટનલ તરીકે ન વાંચે. તે દસ્તાવેજની કસોટી કરે છે, ટનલની નહીં.