നിങ്ങളുടെ ടണൽ പ്രോസസ്സ് പ്രവർത്തിക്കുമ്പോഴും സംരക്ഷിത കണക്ഷൻ ഉപയോഗശൂന്യമായിരിക്കാം, പരാജയപ്പെടുന്ന ഒരു വെബ് പേജ് ടണൽ പൊട്ടി എന്നതിന് തെളിവല്ല. ഒരു പ്രോബ് എല്ലാത്തിനും പകരം നിൽക്കുമ്പോൾ, റീസ്റ്റാർട്ട് നയം തെറ്റായ ഘടകം റീസ്റ്റാർട്ട് ചെയ്ത് അതിനെ ഓട്ടോമേഷൻ എന്ന് വിളിക്കുന്നു. താഴെയുള്ള ഓരോ പരിശോധനയും അത് നിരീക്ഷിക്കുന്ന പാളി, അതിന്റെ പരാജയം പ്രേരിപ്പിക്കുന്ന പ്രവർത്തനം, പ്രവർത്തനം ഫലിച്ചു എന്ന തെളിവ് എന്നിവ പറയുന്നു. അവസാന ഘട്ടം ഈ മുഴുവൻ ഗണത്തെ രാത്രി മൂന്ന് മണിക്ക് ആർക്കെങ്കിലും പിന്തുടരാവുന്ന ഒരു പേജാക്കി മാറ്റുന്നു.

ഘട്ടം 1: ഓരോ പരിശോധനയും നിരീക്ഷിക്കുന്ന പാളി പേരിടുക

അവയിൽ ഏതെങ്കിലും എഴുതുന്നതിന് മുൻപ് ഓരോ പ്രോബിനും യഥാർത്ഥത്തിൽ എന്ത് കാണാനാകും എന്ന് ചോദിക്കുക. ജീവനക്ഷമത ഡീമൺ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, ഹാൻഡ്ഷേക്കോ പിയർ ലിസ്റ്റോ ബന്ധം നിലനിൽക്കുന്നു എന്ന് തെളിയിക്കുന്നു, റൂട്ട് ചെയ്ത അഭ്യർത്ഥന ഡെലിവറി തെളിയിക്കുന്നു, തിരച്ചിൽ പരിഹാരം തെളിയിക്കുന്നു. അവ കൃത്യമായി ആ ക്രമത്തിൽ പരാജയപ്പെടുന്നു, അവയിൽ ഒന്നും അടുത്തതിനെ സൂചിപ്പിക്കുന്നില്ല. പച്ച പ്രോസസ്സ് പരിശോധന മരിച്ച ടണലിന് അരികിൽ നിൽക്കുന്നത് സാധാരണ കേസാണ്, വൈരുദ്ധ്യമല്ല.

നാല് പരിശോധനകളും ആ ക്രമത്തിൽ എഴുതുക, ഓരോന്നിനും കൃത്യമായ കമാൻഡും പ്രതീക്ഷിത ഔട്ട്പുട്ടും സഹിതം. പ്രതീക്ഷിത ഔട്ട്പുട്ട് പറയാനാകാത്ത പ്രോബിനെ അലേർട്ട് കാണുന്ന ഓരോ ഓപ്പറേറ്ററും വ്യത്യസ്തമായി വായിക്കും. അതേ പട്ടിക റൺബുക്കിൽ മാത്രമല്ല, അലേർട്ട് ടെക്സ്റ്റിലും ഇടുക, രാത്രി വിളിച്ചുണർത്തപ്പെട്ടയാൾ ലക്ഷണത്തിന് മുൻപ് പാളിയെ കാണാൻ. ഓരോ കമാൻഡും അത് പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിൽ പകർത്താൻ തയ്യാറായി സൂക്ഷിക്കുക.

തുടർന്ന് അപ്ലിക്കേഷൻ പരിശോധന അഞ്ചാമത്തെ, വേറിട്ട ഇനമായി ചേർക്കുക. അക്കൗണ്ട് സേവനം നിലച്ച പേജ് ടണൽ റീസ്റ്റാർട്ട് ചെയ്യുന്നതിന് ന്യായമല്ല.

ഘട്ടം 2: ഓരോ പരാജയത്തെയും ഒരു പ്രവർത്തനവുമായി ബന്ധിപ്പിക്കുക

ഓരോ പരിശോധനയ്ക്കും എന്ത് റീസ്റ്റാർട്ട് ചെയ്യും, എന്ത് തടയപ്പെട്ടിരിക്കും, എന്ത് ഒരു മനുഷ്യനെ വിളിക്കും എന്ന് തീരുമാനിക്കുക. ടണൽ പാളിയുടെ പരാജയം ടണൽ റീസ്റ്റാർട്ട് ചെയ്യുന്നതിന് ന്യായമാകാം; റിസോൾവറിന്റെ പരാജയം ക്ലയന്റിലെ DNS സംയോജനത്തിലേക്ക് ചൂണ്ടുന്നു; അപ്ലിക്കേഷൻ പാളിയുടെ പരാജയം ടണലിനെ ഏതാണ്ട് ഒരിക്കലും തൊടരുത്.

പരാജയം എന്ത് ചെയ്യരുത് എന്ന് പറയുക, കാരണം അപകടകരമായ സ്ഥിരമൂല്യങ്ങൾ അനുവദിക്കുന്നവയാണ്. അനാരോഗ്യകരമായ അവസ്ഥ ഒരിക്കലും നേരിട്ടുള്ള അപ്ലിക്കേഷൻ ട്രാഫിക്കിന് അനുമതിയാകരുത്, കാരണം ടണലിനെ നിശബ്ദമായി ഒഴിവാക്കുന്ന ഫോൾബാക്ക് ടണൽ ഉള്ളതിന്റെ കാരണം നീക്കിക്കളയുന്നു. പ്രവർത്തനങ്ങളും ചുരുക്കുക: ഒരു ലക്ഷ്യസ്ഥാനം മന്ദഗതിയിലായതിനാൽ പങ്കിട്ട ഘടകം റീസ്റ്റാർട്ട് ചെയ്യുന്നത് പ്രാദേശിക പ്രശ്നത്തെ മുഴുവൻ കൂട്ടത്തിന്റെയും പ്രശ്നമാക്കുന്നു. അത് കാരണം കണ്ടെത്താൻ ആവശ്യമായ തെളിവും നശിപ്പിക്കുന്നു.

ഘട്ടം 3: പ്രോബുകളെ നിരുപദ്രവവും വിലകുറഞ്ഞതുമായി സൂക്ഷിക്കുക

ചെറിയ, വായന-മാത്രം അഭ്യർത്ഥനകൾ ഉപയോഗിക്കുക: ഒരു സ്റ്റാറ്റിക് വിഭവം, സ്വന്തം ആശ്രിതത്വം റിപ്പോർട്ട് ചെയ്യുന്ന ആരോഗ്യ എൻഡ്പോയിന്റ്, അല്ലെങ്കിൽ നിങ്ങൾ നിയന്ത്രിക്കുന്ന പോർട്ടിലേക്കുള്ള TCP കണക്ഷൻ. ക്രെഡൻഷ്യലുകൾ, സ്വകാര്യ ബ്രൗസിംഗ്, ഓരോ ഇടവേളയിലും അവസ്ഥ മാറ്റുന്ന എന്തും ഒഴിവാക്കുക, കാരണം എഴുതുന്ന പ്രോബ് ഷെഡ്യൂൾ ചെയ്ത ലോഡ് ടെസ്റ്റാണ്.

ഓരോ പ്രോബിനും ലക്ഷ്യസ്ഥാനം, റൂട്ട് പ്രതീക്ഷ, കാലപരിധി എന്നിവ രേഖപ്പെടുത്തുക. റൂട്ട് പ്രതീക്ഷ ആളുകൾ വിട്ടുപോകുന്ന ഫീൽഡാണ്, പിന്നീട് അലേർട്ട് വായിക്കുമ്പോൾ ടണൽ പരാജയത്തെ റൂട്ടിംഗ് പിശകിൽ നിന്ന് വേർതിരിക്കുന്നത് അതാണ്. ഇടവേളയും പരാജയ പരിധിയും നിങ്ങൾ വാഗ്ദാനം ചെയ്യുന്ന വീണ്ടെടുപ്പ് സമയത്തിൽ നിന്ന് കണക്കാക്കുക, കാലപരിധി ഇടവേളയേക്കാൾ ചെറുതായി സൂക്ഷിക്കുക. അടുത്തത് തുടങ്ങുമ്പോൾ ഇപ്പോഴും പ്രവർത്തിക്കുന്ന പ്രോബ് ഒരു പരാജയം രണ്ടുവട്ടം റിപ്പോർട്ട് ചെയ്ത് മിന്നലിന് സമാനമായി കാണപ്പെടുന്നു.

ഘട്ടം 4: ഓരോ പാളിയും തകർത്ത് ശരിയായ പ്രോബ് ചുവക്കുന്നത് കാണുക

ടണൽ പ്രോസസ്സ് നിർത്തി, DNS ഇപ്പോഴും കാഷെയിൽ നിന്ന് ഉത്തരം നൽകാമ്പോൾ പ്രോസസ്സ് പരിശോധന പരാജയപ്പെടുന്നു എന്ന് ഉറപ്പാക്കുക. ഒരു റൂട്ട് മാറ്റി, പ്രോസസ്സും ഹാൻഡ്ഷേക്കും ആരോഗ്യകരമായിരിക്കെ റൂട്ട് ചെയ്ത അഭ്യർത്ഥന പരാജയപ്പെടുന്നു എന്ന് ഉറപ്പാക്കുക. DNS മാത്രം തകർത്ത്, അപ്ലിക്കേഷൻ പരിശോധന ടണൽ പിശകിന് പകരം പരിഹാരം റിപ്പോർട്ട് ചെയ്യുന്നു എന്ന് ഉറപ്പാക്കുക. രണ്ട് പ്രോബുകൾ എപ്പോഴും ഒരുമിച്ച് നീങ്ങുന്നുവെങ്കിൽ, നിങ്ങൾ കരുതുന്നതിലും കുറവ് പരിശോധനകളാണുള്ളത്.

അതേ അച്ചടക്കത്തോടെ വീണ്ടെടുപ്പിന്റെ ദിശ പരീക്ഷിക്കുക. പാളി പുനഃസ്ഥാപിച്ച ശേഷം പ്രോബ് കൈകൊണ്ട് റീസ്റ്റാർട്ട് ഇല്ലാതെ മായണം, പ്രവർത്തനം പിന്നിൽ ഒരു ബൈപ്പാസും വിടരുത്. പച്ച അവസ്ഥയിൽ വിശ്വസിക്കുന്നതിന് മുൻപ് ഒരു പൂർണ്ണ ചംക്രമണം നിരീക്ഷിക്കുക, കാരണം കൈകൊണ്ട് മാത്രം മായുന്ന പ്രോബ് പൊട്ടിയ വീണ്ടെടുപ്പ് പാത മറയ്ക്കുന്നു.

ഘട്ടം 5: റൺബുക്ക് അലേർട്ട് ചൂണ്ടുന്നിടത്ത് വയ്ക്കുക

അഞ്ച് വരികളുള്ള ഒരു പേജ് മുഴുവൻ രൂപകൽപ്പനയും വഹിക്കുന്നു: പാളി, കമാൻഡ്, പ്രതീക്ഷിത ഫലം, പരാജയത്തിൽ പ്രവർത്തനം, ഉടമ. ഓരോ പ്രോബിനെക്കുറിച്ചും അത് ബോധപൂർവ്വം പരിശോധിക്കാത്തതിനെക്കുറിച്ച് ഒരു വരി ചേർക്കുക. ആ വരിയാണ് അടുത്തയാളെ എല്ലാം അളക്കുകയും ഒന്നും വേർതിരിക്കാതിരിക്കുകയും ചെയ്യുന്ന ആറാമത്തെ പരിശോധന ചേർക്കുന്നതിൽ നിന്ന് തടയുന്നത്. അലേർട്ട് ടെക്സ്റ്റിൽ നിന്ന് പേജ് ലിങ്ക് ചെയ്യുക, അല്ലെങ്കിൽ സംഭവം സജീവമായിരിക്കുമ്പോൾ ആരും അത് തുറക്കില്ല.

കണ്ടെയ്നർ വിന്യാസങ്ങളിൽ, ആശ്രിതത്വ വ്യവസ്ഥ സ്റ്റാർട്ടപ്പിനെ രൂപപ്പെടുത്തുന്നു, അതിൽ കൂടുതലൊന്നുമല്ല. Compose സ്റ്റാർട്ടപ്പ് ക്രമവും ആരോഗ്യ വ്യവസ്ഥയും ഡോക്യുമെന്റേഷൻ സേവനങ്ങൾ ആരംഭിക്കുന്ന ക്രമം തയ്യാറെടുപ്പ് എങ്ങനെ നിർണ്ണയിക്കുന്നു എന്ന് വിവരിക്കുന്നു; അതിൽ ഒന്നും പിന്നീട് എഗ്രെസ് നയം നടപ്പാക്കുന്നില്ല, ടണൽ വീഴുമ്പോൾ ഒന്നും അടഞ്ഞ് പരാജയപ്പെടുന്നുമില്ല. തുടർച്ചയായ നിർവ്വഹണത്തിന് സ്വന്തം നയവും സ്വന്തം പ്രോബും വേണം, അതേ പേജിൽ എഴുതേണ്ടതാണ്.

ശരിയായ പാളി വീണ്ടെടുക്കുകയും ലഭ്യമല്ലാത്ത ഒരു വെബ്സൈറ്റിനെ പൊട്ടിയ ടണലായി ആരും വായിക്കാതിരിക്കുകയും ചെയ്യുമ്പോൾ റൺബുക്ക് പൂർണ്ണമാകുന്നു. അത് ടണലിനെയല്ല, ഡോക്യുമെന്റിനെ പരീക്ഷിക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ