Ihiwalay ang mga pagsusuri sa kalusugan ng VPN sa mga pagsusuri sa kalusugan ng aplikasyon

Maaaring tumatakbo ang proseso ng iyong tunel habang hindi magamit ang protektadong koneksiyon, at ang pahinang web na nabigo ay hindi patunay na nasira ang tunel. Kapag isang probe ang kumakatawan sa lahat, ang patakaran sa muling pagpapatakbo ay nagpapatakbo muli ng maling bahagi at tinatawag itong automatasyon. Pinapangalanan ng bawat pagsusuri sa ibaba ang patong na sinusubaybayan nito, ang aksiyon na pinupukaw ng pagpalya nito, at ang patunay na gumana ang aksiyon. Ginagawang isang pahina ng huling hakbang ang buong set na masusundan ng sinuman sa ikatlo ng madaling-araw.

Hakbang 1: pangalanan ang patong na sinusubaybayan ng bawat pagsusuri

Itanong kung ano ang talagang nakikita ng bawat probe bago isulat ang alinman sa mga ito. Pinatutunayan ng buhay na tumatakbo ang daemon, pinatutunayan ng pagkakamay o listahan ng mga kapantay na may relasyon, pinatutunayan ng rutadong kahilingan ang paghahatid, at pinatutunayan ng paghahanap ang resolusyon. Nabibigo sila sa ganoong pagkakasunod-sunod, at wala sa kanila ang nangangahulugan ng susunod. Isang berdeng pagsusuri ng proseso sa tabi ng patay na tunel ang normal na kaso, hindi kontradiksiyon.

Isulat ang apat na pagsusuri sa ganoong pagkakasunod-sunod, kasama ang eksaktong utos at inaasahang output para sa bawat isa. Ang probe na hindi mo maipahayag ang inaasahang output ay babasahin nang iba ng bawat operator na makakita ng alerto. Ilagay ang parehong listahan sa teksto ng alerto, hindi lamang sa runbook, upang ang taong ginising sa gabi ay makasalubong ang patong bago ang sintomas. Panatilihing nakahanda sa pagkopya ang bawat utos sa host na nagpapatakbo nito.

Pagkatapos idagdag ang pagsusuri ng aplikasyon bilang ikalimang, hiwalay na aytem. Ang pahinang bumagsak ang serbisyo ng account ay hindi makatarungan para sa muling pagpapatakbo ng tunel.

Hakbang 2: iugnay ang bawat pagpalya sa isang aksiyon

Para sa bawat pagsusuri, magpasya kung ano ang muling magpapatakbo, ano ang mananatiling nakaharang, at ano ang tatawag ng tao. Ang pagpalya ng patong ng tunel ay maaaring makatarungan para sa muling pagpapatakbo ng tunel; ang pagpalya ng resolver ay tumuturo sa integrasyon ng DNS sa kliyente; ang pagpalya ng patong ng aplikasyon ay halos hindi dapat humipo sa tunel.

Sabihin kung ano ang hindi dapat gawin ng pagpalya, dahil ang mapanganib na default ay ang nagpapahintulot. Ang hindi malusog na estado ay hindi dapat maging pahintulot para sa direktang trapiko ng aplikasyon, dahil ang fallback na tahimik na lumalampas sa tunel ay nag-aalis ng dahilan kung bakit may tunel. Paliliitin din ang mga aksiyon: ang muling pagpapatakbo ng pinagsasaluhang bahagi dahil mabagal ang isang destinasyon ay ginagawang problema ng buong flota ang lokal na problema. Sinisira rin nito ang ebidensiyang kailangan mo upang mahanap ang sanhi.

Hakbang 3: panatilihing walang pinsala at mura ang mga probe

Gumamit ng maliliit na kahilingang pa-read lamang: isang estatistikong mapagkukunan, isang dulo ng kalusugan na nag-uulat ng sariling dependency, o koneksiyong TCP sa port na kontrolado mo. Iwasan ang mga kredensiyal, pribadong pag-browse at anumang nagbabago ng estado sa bawat agwat, dahil ang probe na nagsusulat ay isang pagsubok ng karga ayon sa iskedyul.

Itala ang destinasyon, ang inaasahan sa ruta at ang timeout para sa bawat probe. Ang inaasahan sa ruta ang patlang na iniiwan ng mga tao, at iyon ang naghihiwalay ng pagpalya ng tunel sa pagkakamali sa routing kapag binasa mo ang alerto mamaya. Kunin ang agwat at ang hangganan ng pagpalya mula sa oras ng pagbawi na ipinapangako mo, at panatilihing mas maikli ang timeout kaysa agwat. Ang probe na tumatakbo pa kapag nagsimula ang susunod ay nag-uulat ng isang pagpalya nang dalawang beses at mukhang pagkurap.

Hakbang 4: basagin ang bawat patong at tingnan kung pumupula ang tamang probe

Ihinto ang proseso ng tunel at kumpirmahing nabigo ang pagsusuri ng proseso habang maaaring sumagot pa ang DNS mula sa cache. Baguhin ang isang ruta at kumpirmahing nabigo ang rutadong kahilingan habang nananatiling malusog ang proseso at pagkakamay. Basagin lamang ang DNS at kumpirmahing nag-uulat ang pagsusuri ng aplikasyon ng resolusyon sa halip na error ng tunel. Kung laging magkasabay gumalaw ang dalawang probe, mas kaunti ang pagsusuri mo kaysa inaakala mo.

Subukan ang direksiyon ng pagbawi sa parehong disiplina. Matapos ibalik ang patong, dapat linisin ng probe nang walang manu-manong muling pagpapatakbo, at ang aksiyong na-trigger ay hindi dapat mag-iwan ng anumang paglampas. Panoorin ang isang buong siklo bago magtiwala sa berdeng estado, dahil ang probe na nalilinis lamang sa kamay ay nagtatago ng sirang landas ng pagbawi.

Hakbang 5: ilagay ang runbook kung saan itinuturo ng alerto

Isang pahina na may limang hanay ang nagdadala ng buong disenyo: patong, utos, inaasahang resulta, aksiyon kapag nabigo, may-ari. Magdagdag ng isang hanay para sa bawat probe tungkol sa sadyang hindi nito sinusubukan. Ang hanay na iyon ang pumipigil sa susunod na tao na magdagdag ng ikaanim na pagsusuri na sumusukat sa lahat at walang hinihiwalay. I-link ang pahina mula sa teksto ng alerto, kung hindi ay walang magbubukas nito habang aktibo ang insidente.

Sa mga deployment ng container, hinuhubog ng kondisyon ng dependency ang pagsisimula at wala nang iba. Pagkakasunod-sunod ng pagsisimula at kondisyon ng kalusugan ng Compose dokumentasyon ay naglalarawan kung paano tinutukoy ng pagiging handa ang pagkakasunod-sunod ng pagsisimula ng mga serbisyo; wala sa mga ito ang nagpapatupad ng patakaran sa paglabas pagkatapos, at wala sa mga ito ang nabibigo nang sarado kapag bumagsak ang tunel. Ang tuloy-tuloy na pagpapatupad ay nangangailangan ng sariling patakaran at sariling probe, na nakasulat sa parehong pahina.

Kumpleto ang runbook kapag naibalik ang tamang patong nang walang sinumang nagbabasa ng hindi available na website bilang sirang tunel. Sinusubukan niyon ang dokumento, hindi ang tunel.