Ufuatiliaji uliosambazwa: tulifanya yote vibaya

Kumbuka. tafsiri.: Mwandishi wa nyenzo hii ni Cindy Sridharan, mhandisi wa imgix ambaye ni mtaalamu wa ukuzaji wa API na, haswa, upimaji wa huduma ndogo. Katika nyenzo hii, anashiriki maono yake ya kina ya shida za sasa katika uwanja wa ufuatiliaji uliosambazwa, ambapo, kwa maoni yake, kuna ukosefu wa zana bora za kutatua shida kubwa.

[Mchoro umechukuliwa kutoka nyenzo nyingine kuhusu ufuatiliaji uliosambazwa.]

Inaaminika kuwa ufuatiliaji uliosambazwa vigumu kutekeleza, na kurudi juu yake mbaya zaidi. Kuna sababu nyingi kwa nini ufuatiliaji unatatizika, mara nyingi hutaja kazi inayohusika katika kusanidi kila sehemu ya mfumo ili kusambaza vichwa vinavyofaa kwa kila ombi. Ingawa tatizo hili lipo, haliwezi kutatuliwa kwa vyovyote vile. Kwa njia, haielezi kwa nini watengenezaji hawapendi sana kufuatilia (hata wakati tayari inafanya kazi).

Changamoto kuu ya ufuatiliaji uliosambazwa sio kukusanya data, kusawazisha miundo ya kusambaza na kuwasilisha matokeo, au kubainisha lini, wapi na jinsi ya kuiga. Sijaribu kufikiria yasiyo na maana "shida za ufahamu" hizi, kwa kweli, ni muhimu sana za kiufundi na (ikiwa tunazingatia kweli Open Source) viwango na itifaki) changamoto za kisiasa zinazohitaji kutatuliwa ili matatizo haya yaweze kutatuliwa.

Walakini, ikiwa tunafikiria kuwa shida hizi zote zimetatuliwa, kuna uwezekano mkubwa kwamba hakuna kitakachobadilika sana katika suala la uzoefu wa mtumiaji wa mwisho. Kufuatilia kunaweza bado kusiwe na matumizi ya vitendo katika hali za kawaida za utatuzi-hata baada ya kutumwa.

Ufuatiliaji tofauti kama huo

Ufuatiliaji uliosambazwa unajumuisha vipengele kadhaa tofauti:

• kuandaa programu na vifaa vya kati na zana za kudhibiti;
• uhamishaji wa muktadha uliosambazwa;
• mkusanyiko wa athari;
• uhifadhi wa kufuatilia;
• uchimbaji wao na taswira.

Mazungumzo mengi juu ya ufuatiliaji uliosambazwa huelekea kuchukulia kama aina ya operesheni isiyo ya kawaida ambayo kusudi lake kuu ni kusaidia kugundua mfumo kikamilifu. Hii ni kwa kiasi kikubwa kutokana na jinsi mawazo kuhusu ufuatiliaji uliosambazwa yameundwa kihistoria. KATIKA maingizo ya blogu, iliyofanywa wakati vyanzo vya Zipkin vilifunguliwa, ilitajwa kuwa [Zipkin] hufanya Twitter iwe haraka. Matoleo ya kwanza ya kibiashara ya ufuatiliaji pia yalikuzwa kama Zana za APM.

Kumbuka. tafsiri.: Ili kurahisisha maandishi zaidi kueleweka, hebu tufafanue istilahi mbili za msingi kulingana na Nyaraka za mradi wa OpenTracing:

• Span - kipengele cha msingi cha ufuatiliaji uliosambazwa. Ni maelezo ya mtiririko fulani wa kazi (kwa mfano, hoja ya hifadhidata) yenye jina, saa za kuanza na kumaliza, lebo, kumbukumbu na muktadha.
• Spans kwa kawaida huwa na viungo vya spans nyingine, kuruhusu span nyingi kuunganishwa katika Fuatilia - taswira ya maisha ya ombi linaposonga kupitia mfumo uliosambazwa.

Ufuatiliaji una data muhimu sana ambayo inaweza kusaidia kwa kazi kama vile majaribio ya uzalishaji, majaribio ya kurejesha maafa, majaribio ya sindano ya makosa, n.k. Kwa kweli, kampuni zingine tayari hutumia ufuatiliaji kwa madhumuni sawa. Hebu tuanze na uhamishaji wa muktadha wa ulimwengu wote ina matumizi mengine kando na kusongesha spans kwenye mfumo wa uhifadhi:

• Kwa mfano, Uber hutumia kufuatilia matokeo ili kutofautisha trafiki ya majaribio na trafiki ya uzalishaji.
• Facebook hutumia kufuatilia data kwa uchanganuzi muhimu wa njia na kwa kubadili trafiki wakati wa majaribio ya mara kwa mara ya uokoaji wa maafa.
• Pia mtandao wa kijamii inatumika Madaftari ya Jupyter ambayo huruhusu wasanidi programu kuendesha maswali kiholela kwenye matokeo ya ufuatiliaji.
• Wafuasi LFI (Sindano ya Kushindwa Inayoendeshwa na Ukoo) kutumia athari zilizosambazwa kwa majaribio na sindano ya makosa.

Hakuna chaguo kati ya zilizoorodheshwa hapo juu zinazotumika kabisa kwa hali hii utatuzi, wakati ambapo mhandisi anajaribu kutatua tatizo kwa kuangalia ufuatiliaji.

Wakati inakuja bado hufikia hati ya utatuzi, kiolesura cha msingi kinabaki kuwa mchoro traceview (ingawa wengine pia huiita "Chati ya Gantt" au "mchoro wa maporomoko ya maji") Chini ya traceview я namaanisha nafasi zote na metadata inayoandamana ambayo kwa pamoja huunda ufuatiliaji. Kila mfumo wa ufuatiliaji wa chanzo huria, pamoja na kila suluhisho la ufuatiliaji wa kibiashara, hutoa a traceview kiolesura cha mtumiaji cha kuibua, kufafanua na kuchuja athari.

Shida na mifumo yote ya ufuatiliaji ambayo nimeona hadi sasa ni kwamba matokeo taswira (kufuatilia) karibu kabisa huonyesha vipengele vya mchakato wa kizazi cha ufuatiliaji. Hata wakati taswira mbadala zinapendekezwa: ramani za joto, topolojia za huduma, historia za muda, bado mwishowe zinakuja chini. traceview.

Hapo zamani I alilalamika kwamba "ubunifu" mwingi katika ufuatiliaji wa UI/UX unaonekana kuwa mdogo kuwasha metadata ya ziada katika ufuatiliaji, kuwekeza ndani yao habari kwa ukarimu wa juu (kadinali wa juu) au kutoa uwezo wa kuchimba chini katika nafasi maalum au kuendesha hoja inter- na intra-trace... Ambayo traceview inabakia kuwa zana kuu ya taswira. Maadamu hali hii inaendelea, ufuatiliaji uliosambazwa (bora zaidi) utachukua nafasi ya 4 kama zana ya utatuzi, baada ya vipimo, kumbukumbu na ufuatiliaji wa rafu, na mbaya zaidi itageuka kuwa upotezaji wa pesa na wakati.

Tatizo na traceview

Kusudi traceview - toa picha kamili ya uhamishaji wa ombi moja kwa vipengele vyote vya mfumo uliosambazwa ambao unahusiana nao. Mifumo mingine ya hali ya juu zaidi ya kufuatilia hukuruhusu kujichimbia katika nafasi za kibinafsi na kutazama uchanganuzi wa muda ndani mchakato mmoja (wakati spans ina mipaka ya kazi).

Msingi wa msingi wa usanifu wa huduma ndogo ni wazo kwamba muundo wa shirika unakua na mahitaji ya kampuni. Wafuasi wa huduma ndogo ndogo wanasema kuwa kusambaza kazi mbalimbali za biashara katika huduma za kibinafsi huruhusu timu ndogo za maendeleo zinazojiendesha kudhibiti mzunguko mzima wa maisha wa huduma hizo, kuwapa uwezo wa kujitegemea kujenga, kupima na kusambaza huduma hizo. Hata hivyo, hasara ya usambazaji huu ni kupoteza taarifa kuhusu jinsi kila huduma inavyoingiliana na wengine. Katika hali kama hizi, madai yaliyosambazwa ya kufuatilia kuwa chombo cha lazima kwa utatuzi mwingiliano mgumu kati ya huduma.

Kama kweli mfumo mgumu sana uliosambazwa, basi hakuna hata mtu mmoja anayeweza kuiweka kichwani mwake kamili picha. Kwa kweli, kuendeleza chombo kulingana na dhana kwamba inawezekana hata ni kitu cha kupinga muundo (njia isiyofaa na isiyozalisha). Kwa kweli, utatuzi unahitaji zana inayosaidia punguza eneo lako la utafutaji, ili wahandisi waweze kuzingatia kitengo kidogo cha vipimo (huduma/watumiaji/wapangishi, n.k.) muhimu kwa hali ya tatizo inayozingatiwa. Wakati wa kuamua sababu ya kutofaulu, wahandisi hawatakiwi kuelewa kilichotokea wakati wa huduma zote mara moja, kwa kuwa hitaji kama hilo lingepingana na wazo la usanifu wa huduma ndogo.

Hata hivyo, traceview ni yaani Hii. Ndiyo, baadhi ya mifumo ya ufuatiliaji hutoa ufuatilizi uliobanwa wakati idadi ya nafasi katika ufuatiliaji ni kubwa sana hivi kwamba haiwezi kuonyeshwa katika taswira moja. Walakini, kwa sababu ya idadi kubwa ya habari iliyomo hata kwenye taswira iliyovuliwa, wahandisi bado kulazimishwa "ipepete", ukipunguza uteuzi kwa seti ya huduma ambazo ni vyanzo vya shida. Kwa bahati mbaya, katika uwanja huu, mashine ni kasi zaidi kuliko wanadamu, hazipatikani na makosa, na matokeo yao yanaweza kurudiwa zaidi.

Sababu nyingine nadhani traceview sio sawa ni kwa sababu sio nzuri kwa utatuzi unaoendeshwa na nadharia. Katika msingi wake, debugging ni ya kurudia mchakato unaoanza na hypothesis, ikifuatiwa na uthibitishaji wa uchunguzi mbalimbali na ukweli uliopatikana kutoka kwa mfumo pamoja na vekta tofauti, hitimisho / ujumla na tathmini zaidi ya ukweli wa hypothesis.

Fursa haraka na kwa bei nafuu kupima hypotheses na kuboresha mtindo wa kiakili ipasavyo ni Jiwe la pembeni utatuzi Chombo chochote cha kurekebisha kinapaswa kuwa mwingiliano na punguza nafasi ya utaftaji au, katika kesi ya uwongo, ruhusu mtumiaji kurudi nyuma na kuzingatia eneo tofauti la mfumo. Chombo kamili kitafanya hivi kwa vitendo, mara moja ikivutia umakini wa mtumiaji kwa maeneo ya shida yanayoweza kutokea.

Ole, traceview haiwezi kuitwa chombo kilicho na kiolesura cha maingiliano. Bora unayoweza kutumaini unapoitumia ni kutafuta chanzo cha kuongezeka kwa latency na kuangalia lebo zote zinazowezekana na kumbukumbu zinazohusiana nayo. Hii haimsaidii mhandisi kutambua mifumo katika trafiki, kama vile mahususi ya usambaaji wa kuchelewa, au tambua uwiano kati ya vipimo tofauti. Uchambuzi wa jumla wa ufuatiliaji inaweza kusaidia kuzunguka baadhi ya shida hizi. Kweli, kuna mifano uchanganuzi uliofaulu kwa kutumia ujifunzaji wa mashine ili kubaini vipindi visivyo vya kawaida na kutambua kikundi kidogo cha lebo ambacho kinaweza kuhusishwa na tabia isiyo ya kawaida. Hata hivyo, bado sijaona taswira za kuvutia za ujifunzaji wa mashine au matokeo ya uchimbaji wa data yanayotumika kwa vipindi ambavyo ni tofauti sana na muhtasari wa ufuatiliaji au DAG (grafu ya acyclic iliyoelekezwa).

Spans ni kiwango cha chini sana

Tatizo la msingi la traceview ni hilo vipindi ni mambo ya awali ya kiwango cha chini sana kwa uchanganuzi wa muda wa kusubiri na uchanganuzi wa sababu kuu. Ni kama kuchanganua amri za kichakataji binafsi ili kujaribu kusuluhisha hali isiyofuata kanuni, ukijua kwamba kuna zana za kiwango cha juu zaidi kama vile nyuma ambazo zinafaa zaidi kufanya kazi nazo.

Zaidi ya hayo, nitachukua uhuru wa kudai yafuatayo: kwa hakika, hatuhitaji picha kamili ilitokea wakati wa mzunguko wa maisha wa ombi, ambao unawakilishwa na zana za kisasa za kufuatilia. Badala yake, aina fulani ya uondoaji wa kiwango cha juu inahitajika ambayo ina habari kuhusu nini imeenda vibaya (sawa na nyuma), pamoja na muktadha fulani. Badala ya kutazama wimbo mzima, napendelea kuuona sehemu ya, ambapo jambo la kuvutia au lisilo la kawaida hutokea. Hivi sasa, utafutaji unafanywa kwa mikono: mhandisi hupokea ufuatiliaji na anachambua kwa uhuru nafasi katika kutafuta kitu cha kuvutia. Mtazamo wa watu wanaotazama kwa upana katika athari za mtu binafsi kwa matumaini ya kugundua shughuli zinazotiliwa shaka haupunguzi hata kidogo (haswa inapobidi kuelewa metadata yote iliyosimbwa katika vipindi tofauti, kama vile kitambulisho cha span, jina la njia ya RPC, muda wa muda. 'a, kumbukumbu, vitambulisho, nk).

Njia mbadala za kufuatilia

Ufuatiliaji ni muhimu zaidi wakati unaweza kuonyeshwa kwa njia ambayo hutoa maarifa yasiyo ya kawaida kuhusu kile kinachotokea katika sehemu zilizounganishwa za mfumo. Hadi hii itatokea, mchakato wa kurekebisha kwa kiasi kikubwa unabaki ajizi na inategemea uwezo wa mtumiaji wa kutambua uwiano sahihi, kuangalia sehemu zinazofaa za mfumo, au kuweka vipande vya fumbo pamoja - kinyume na chombo, kumsaidia mtumiaji kuunda dhana hizi.

Mimi si mbunifu wa kuona au mtaalamu wa UX, lakini katika sehemu inayofuata ninataka kushiriki mawazo machache kuhusu jinsi taswira hizi zinaweza kuonekana.

Kuzingatia huduma maalum

Wakati ambapo tasnia inaunganisha karibu mawazo SLO (malengo ya kiwango cha huduma) na SLI (viashiria vya kiwango cha huduma), inaonekana ni sawa kwamba timu binafsi zinapaswa kuweka kipaumbele ili kuhakikisha huduma zao zinawiana na malengo haya. Inafuata hiyo inayolenga huduma taswira inafaa zaidi kwa timu kama hizo.

Ufuatiliaji, haswa bila sampuli, ni hazina ya habari kuhusu kila sehemu ya mfumo uliosambazwa. Habari hii inaweza kulishwa kwa processor ya ujanja ambayo itawapa watumiaji inayolenga huduma matokeo yanaweza kutambuliwa mapema - hata kabla ya mtumiaji kuangalia athari:

1. Michoro ya ucheleweshaji wa usambazaji kwa maombi maarufu tu (maombi ya nje);
2. Michoro ya usambazaji wa ucheleweshaji kwa kesi wakati malengo ya huduma ya SLO hayajafikiwa;
3. Lebo "za kawaida", "kuvutia" na "ajabu" katika maswali ambayo mara nyingi zaidi hurudiwa;
4. Uchanganuzi wa kusubiri kwa kesi ambapo utegemezi huduma hazifikii malengo yao ya SLO;
5. Uchanganuzi wa kusubiri kwa huduma mbalimbali za mkondo.

Baadhi ya maswali haya hayajibiwi kwa vipimo vilivyojengewa ndani, na hivyo kuwalazimu watumiaji kuchunguza muda. Kwa hivyo, tuna utaratibu wa uhasama sana wa watumiaji.

Hii inazua swali: vipi kuhusu mwingiliano changamano kati ya huduma mbalimbali zinazodhibitiwa na timu tofauti? Sivyo traceview haifikiriwi kuwa chombo kinachofaa zaidi cha kuangazia hali kama hiyo?

Wasanidi programu wa simu, wamiliki wa huduma zisizo na uraia, wamiliki wa huduma za hali ya juu zinazodhibitiwa (kama hifadhidata) na wamiliki wa mifumo wanaweza kupendezwa na jambo lingine. uwasilishaji mfumo wa kusambazwa; traceview ni suluhisho la jumla kwa mahitaji haya tofauti kimsingi. Hata katika usanifu wa microservice ngumu sana, wamiliki wa huduma hawana haja ya ujuzi wa kina wa huduma zaidi ya mbili au tatu za mto na chini. Kimsingi, katika hali nyingi, watumiaji wanahitaji tu kujibu maswali kuhusu seti ndogo ya huduma.

Ni kama kuangalia kitengo kidogo cha huduma kupitia kioo cha kukuza kwa ajili ya kukichunguza. Hii itamruhusu mtumiaji kuuliza maswali muhimu zaidi kuhusu mwingiliano changamano kati ya huduma hizi na utegemezi wao wa haraka. Hii ni sawa na kurudi nyuma katika ulimwengu wa huduma, ambapo mhandisi anajua kwamba makosa, na pia ana ufahamu fulani wa kile kinachotokea katika huduma zinazozunguka kuelewa kwa nini.

Mbinu ninayokuza ni kinyume kabisa cha mbinu ya juu-chini, inayotegemea traceview, ambapo uchanganuzi huanza na ufuatiliaji mzima kisha hatua kwa hatua hufanya kazi hadi kwa misururu mahususi. Kinyume chake, mbinu ya kwenda chini huanza kwa kuchanganua eneo dogo lililo karibu na sababu inayowezekana ya tukio, na kisha kupanua nafasi ya utafutaji inavyohitajika (pamoja na uwezekano wa kuleta timu nyingine kuchanganua anuwai pana ya huduma). Njia ya pili inafaa zaidi kwa kupima haraka nadharia za awali. Mara tu matokeo halisi yanapatikana, itawezekana kuendelea na uchambuzi unaozingatia zaidi na wa kina.

Kujenga topolojia

Mionekano mahususi ya huduma inaweza kuwa muhimu sana ikiwa mtumiaji anajua nini huduma au kikundi cha huduma kinawajibika kwa kuongeza muda wa kusubiri au kusababisha makosa. Hata hivyo, katika mfumo mgumu, kutambua huduma inayokosea inaweza kuwa kazi isiyo ya kawaida wakati wa kushindwa, hasa ikiwa hakuna ujumbe wa makosa uliripotiwa kutoka kwa huduma.

Kuunda topolojia ya huduma inaweza kuwa msaada mkubwa katika kubaini ni huduma gani inakabiliwa na ongezeko la viwango vya makosa au ongezeko la muda wa kusubiri ambalo linasababisha huduma kuharibika. Ninapozungumza juu ya kujenga topolojia, simaanishi ramani ya huduma, kuonyesha kila huduma inayopatikana kwenye mfumo na inayojulikana kwa kazi yake ramani za usanifu katika sura ya nyota ya kifo. Mtazamo huu sio bora kuliko traceview kulingana na grafu ya acyclic iliyoelekezwa. Badala yake ningependa kuona topolojia ya huduma inayozalishwa kwa nguvu, kulingana na sifa fulani kama vile kiwango cha makosa, muda wa majibu, au kigezo chochote kilichobainishwa na mtumiaji ambacho husaidia kufafanua hali hiyo kwa huduma mahususi zinazotiliwa shaka.

Hebu tuchukue mfano. Wacha tufikirie tovuti ya habari dhahania. Huduma ya ukurasa wa nyumbani (ukurasa wa mbele) hubadilishana data na Redis, pamoja na huduma ya mapendekezo, na huduma ya utangazaji na huduma ya video. Huduma ya video inachukua video kutoka S3 na metadata kutoka DynamoDB. Huduma ya mapendekezo hupokea metadata kutoka DynamoDB, hupakia data kutoka kwa Redis na MySQL, na kuandika ujumbe kwa Kafka. Huduma ya utangazaji hupokea data kutoka kwa MySQL na huandika ujumbe kwa Kafka.

Ifuatayo ni uwakilishi wa kimkakati wa topolojia hii (programu nyingi za uelekezaji wa kibiashara huunda topolojia). Inaweza kuwa muhimu ikiwa unahitaji kuelewa utegemezi wa huduma. Hata hivyo, wakati utatuzi, wakati huduma fulani (sema, huduma ya video) inaonyesha kuongezeka kwa muda wa majibu, topolojia hiyo haifai sana.

Mchoro wa huduma wa tovuti dhahania ya habari

Mchoro hapa chini ungefaa zaidi. Kuna tatizo na huduma (video) iliyoonyeshwa katikati kabisa. Mtumiaji hugundua mara moja. Kutokana na taswira hii, inakuwa wazi kuwa huduma ya video inafanya kazi kwa njia isiyo ya kawaida kutokana na ongezeko la muda wa majibu ya S3, ambayo huathiri kasi ya upakiaji wa sehemu ya ukurasa kuu.

Topolojia inayobadilika inayoonyesha huduma "za kuvutia" pekee

Topolojia zinazozalishwa kwa nguvu zinaweza kuwa na ufanisi zaidi kuliko ramani za huduma tuli, hasa katika miundo nyumbufu, ya kuongeza kiotomatiki. Uwezo wa kulinganisha na kulinganisha topolojia za huduma huruhusu mtumiaji kuuliza maswali muhimu zaidi. Maswali sahihi zaidi kuhusu mfumo yana uwezekano mkubwa wa kusababisha ufahamu bora wa jinsi mfumo unavyofanya kazi.

Onyesho la kulinganisha

Taswira nyingine muhimu itakuwa onyesho linganishi. Hivi sasa athari hazifai sana kwa ulinganisho wa kando, kwa hivyo kulinganisha ni kawaida vipindi. Na wazo kuu la kifungu hiki ni kwamba spans ni ya kiwango cha chini sana ili kutoa habari muhimu zaidi kutoka kwa matokeo ya ufuatiliaji.

Kulinganisha athari mbili hakuhitaji taswira mpya kimsingi. Kwa kweli, kitu kama histogram inayowakilisha taarifa sawa na traceview inatosha. Kwa kushangaza, hata njia hii rahisi inaweza kuleta matunda mengi zaidi kuliko kusoma tu athari mbili tofauti. Hata nguvu zaidi itakuwa uwezekano taswira kulinganisha kwa athari Kwa ujumla. Itakuwa muhimu sana kuona jinsi mabadiliko ya usanidi wa hifadhidata uliotumwa hivi majuzi ili kuwezesha GC (ukusanyaji wa takataka) huathiri muda wa majibu wa huduma ya mkondo kwa kiwango cha saa kadhaa. Ikiwa kile ninachoelezea hapa kinasikika kama uchambuzi wa A/B wa athari za mabadiliko ya miundombinu katika huduma nyingi kwa kutumia matokeo ya ufuatiliaji, basi hauko mbali sana na ukweli.

Hitimisho

Siulizi umuhimu wa ufuatiliaji wenyewe. Ninaamini kwa dhati kuwa hakuna njia nyingine ya kukusanya data tajiri, ya sababu na ya muktadha kama ile iliyomo katika ufuatiliaji. Walakini, ninaamini pia kuwa suluhisho zote za kufuata hutumia data hii kwa ufanisi sana. Maadamu zana za ufuatiliaji zinasalia kukwama kwenye uwakilishi wa traceview, zitakuwa na kikomo katika uwezo wao wa kutumia vyema taarifa muhimu inayoweza kutolewa kutoka kwa data iliyo katika ufuatiliaji. Kwa kuongeza, kuna hatari ya kuendeleza zaidi interface isiyo ya kirafiki na isiyofaa kabisa ya kuona ambayo itapunguza sana uwezo wa mtumiaji wa kutatua makosa katika programu.

Kutatua mifumo changamano, hata kwa zana za hivi punde, ni ngumu sana. Vyombo vinapaswa kumsaidia msanidi programu kuunda na kujaribu nadharia, kutoa kikamilifu habari muhimu, kutambua wauzaji wa nje na vipengele vya kuzingatia katika usambazaji wa ucheleweshaji. Ili kufuatilia ili kuwa zana ya chaguo la wasanidi programu wakati wa kutatua hitilafu za uzalishaji au kutatua matatizo ambayo yanahusisha huduma nyingi, miingiliano ya awali ya mtumiaji na taswira inahitajika ambayo inalingana zaidi na muundo wa kiakili wa wasanidi programu wanaounda na kuendesha huduma hizo.

Itachukua juhudi kubwa ya kiakili kuunda mfumo ambao utawakilisha ishara mbalimbali zinazopatikana katika matokeo ya ufuatiliaji kwa njia ambayo imeboreshwa kwa urahisi wa uchanganuzi na uelekezaji. Unahitaji kufikiria kuhusu jinsi ya kuondoa topolojia ya mfumo wakati wa utatuzi kwa njia ambayo humsaidia mtumiaji kushinda maeneo yasiyoonekana bila kuangalia alama za mtu binafsi au upana.

Tunahitaji uwezo mzuri wa uondoaji na kuweka tabaka (haswa katika UI). Zile ambazo zinaweza kutoshea vizuri katika mchakato wa utatuzi unaoendeshwa na dhana ambapo unaweza kuuliza maswali mara kwa mara na kujaribu dhahania. Havitatatua kiotomatiki matatizo yote ya uangalizi, lakini vitasaidia watumiaji kunoa angavu yao na kutunga maswali mahiri. Natoa wito kwa mbinu ya kufikiria zaidi na bunifu ya taswira. Kuna matarajio ya kweli hapa ya kupanua upeo.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «programu-jalizi ya kubectl-debug ya utatuzi katika maganda ya Kubernetes";
• «Microservices: Ukubwa ni muhimu, hata kama una Kubernetes";
• «Ufuatiliaji na Kubernetes (hakiki na ripoti ya video)'.

Chanzo: mapenzi.com