ဖြန့်ဝေထားသော ခြေရာခံခြင်း- ကျွန်ုပ်တို့အားလုံး မှားယွင်းစွာ လုပ်ခဲ့သည်။

မှတ်ချက်။ ဘာသာပြန်: ဤအကြောင်းအရာကို ရေးသားသူမှာ API ဖွံ့ဖြိုးတိုးတက်မှုနှင့် အထူးသဖြင့် microservice စမ်းသပ်ခြင်းတွင် အထူးပြုသော imgix မှ အင်ဂျင်နီယာတစ်ဦးဖြစ်သည်။ ဤအကြောင်းအရာတွင်၊ ဖြန့်ဝေမှုခြေရာခံခြင်းနယ်ပယ်တွင် လက်ရှိပြဿနာများနှင့်ပတ်သက်၍ သူမ၏အသေးစိတ်အမြင်ကို မျှဝေထားပြီး၊ သူမ၏အမြင်အရ၊ ပြဿနာများကိုဖြေရှင်းရန်အတွက် အမှန်တကယ်ထိရောက်သောကိရိယာများ နည်းပါးနေပါသည်။

[ပုံမှကူးယူဖော်ပြပါသည်။ အခြားပစ္စည်း ဖြန့်ဝေထားသော ခြေရာခံအကြောင်း။]

ထိုသို့ယုံကြည် ဖြန့်ဝေခြေရာခံ အကောင်အထည်ဖော်ရန် ခက်ခဲပြီး ၎င်းကို ပြန်လာနိုင်သည်။ သံသယဖြစ်စရာ အကောင်းဆုံးပါ။. ခြေရာခံခြင်းသည် ပြဿနာဖြစ်ရသည့် အကြောင်းရင်းများစွာ ရှိပြီး၊ တောင်းဆိုချက်တစ်ခုစီနှင့် သင့်လျော်သော ခေါင်းစီးများကို ပေးပို့ရန်အတွက် စနစ်အစိတ်အပိုင်းတစ်ခုစီကို ပြင်ဆင်သတ်မှတ်ရာတွင် ပါဝင်သည့် အလုပ်သမားကို ကိုးကားလေ့ရှိသည်။ ဒီပြဿနာရှိပေမယ့် ဖြတ်ကျော်လို့မရပါဘူး။ စကားမစပ်၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ခြေရာခံခြင်းကို အမှန်တကယ် မကြိုက်ကြသည် (၎င်းသည် လုပ်ဆောင်နေချိန်တွင်ပင်) အကြောင်းရင်းကို ရှင်းပြမထားပေ။

ဖြန့်ဝေခြေရာခံခြင်း၏ အဓိကစိန်ခေါ်မှုမှာ ဒေတာစုဆောင်းခြင်း၊ ရလဒ်များကို ဖြန့်ဝေခြင်းနှင့် တင်ပြခြင်းအတွက် စံသတ်မှတ်ခြင်းဖော်မတ်များ သို့မဟုတ် မည်သည့်အချိန်၊ နေရာ၊ မည်ကဲ့သို့ နမူနာယူရမည်ကို ဆုံးဖြတ်ခြင်းမဟုတ်ပါ။ စိတ်ကူးယဉ်ဖို့ မကြိုးစားပါဘူး။ အသေးအဖွဲ ဤ "နားလည်နိုင်မှုပြဿနာများ" သည် အမှန်တကယ်အားဖြင့် အလွန်အရေးကြီးသော နည်းပညာနှင့် (ကျွန်ုပ်တို့သည် အမှန်တကယ် Open Source ကို စဉ်းစားနေလျှင်)၊ စံနှုန်းများနှင့် ပရိုတိုကောများ၎) နိုင်ငံရေး စိန်ခေါ်မှုများကို ပြေလည်အောင် တွေးခေါ်နိုင်စေရန်အတွက် ကျော်လွှားရန် လိုအပ်ပါသည်။

သို့သော်လည်း ဤပြဿနာများအားလုံးကို ဖြေရှင်းပြီးကြောင်း ကျွန်ုပ်တို့ စိတ်ကူးကြည့်ပါက၊ မည်သည့်အရာမှ သိသိသာသာ ပြောင်းလဲလာမည်မဟုတ်ကြောင်း ဖြစ်နိုင်ခြေ မြင့်မားပါသည်။ အသုံးပြုသူအတွေ့အကြုံ. ခြေရာခံခြင်းကို အသုံးပြုပြီးသည့်တိုင် အသုံးအများဆုံး အမှားရှာပြင်သည့် အခြေအနေများတွင် လက်တွေ့အသုံးမ၀င်နိုင်ပါ။

အဲဒီလို မတူဘူး။

ဖြန့်ဝေထားသော ခြေရာခံခြင်းတွင် မတူညီသော အစိတ်အပိုင်းများစွာ ပါဝင်သည်-

• ထိန်းချုပ်ကိရိယာများဖြင့် အပလီကေးရှင်းများနှင့် အလယ်တန်းဆော့ဖ်ဝဲများကို တပ်ဆင်ခြင်း၊
• ဖြန့်ဝေထားသော အကြောင်းအရာ လွှဲပြောင်းမှု၊
• ခြေရာများစုဆောင်းခြင်း;
• ခြေရာခံသိုလှောင်မှု;
• ၎င်းတို့၏ ထုတ်ယူမှုနှင့် စိတ်ကူးပုံဖော်မှု။

ဖြန့်ဝေမှုခြေရာခံခြင်းအကြောင်း ပြောဆိုမှုအများအပြားသည် ၎င်းအား စနစ်တစ်ခုလုံးကို အပြည့်အဝရှာဖွေဖော်ထုတ်ရာတွင် ကူညီရန် ၎င်း၏တစ်ခုတည်းသောရည်ရွယ်ချက်မှာ ၎င်းကို မသေမချာလုပ်ဆောင်မှုတစ်မျိုးအဖြစ် သဘောထားလေ့ရှိသည်။ ဤသည်မှာ ဖြန့်ဝေမှု ခြေရာခံခြင်းဆိုင်ရာ အယူအဆများကို သမိုင်းကြောင်းအရ ဖွဲ့စည်းထားပုံကြောင့် ဖြစ်သည်။ IN ဘလော့ဂ်များZipkin အရင်းအမြစ်များကိုဖွင့်သောအခါတွင်ပြုလုပ်ခဲ့သည်၊ ၎င်းကိုဖော်ပြခဲ့သည်။ [Zipkin] သည် Twitter ကို ပိုမြန်စေသည်။. ခြေရာခံခြင်းအတွက် ပထမဆုံး စီးပွားဖြစ်ကမ်းလှမ်းမှုများကိုလည်း မြှင့်တင်ခဲ့သည်။ APM ကိရိယာများ.

မှတ်ချက်။ ဘာသာပြန်− နောက်ထပ်စာသားကို ပိုမိုနားလည်လွယ်စေရန်၊ အခြေခံအသုံးအနှုန်းများနှင့်အညီ ကျွန်ုပ်တို့ကို သတ်မှတ်ကြပါစို့ OpenTracing ပရောဂျက်စာရွက်စာတမ်း:

• span - ဖြန့်ဝေခြေရာခံခြင်း၏အခြေခံဒြပ်စင်။ ၎င်းသည် အမည်၊ စတင်ချိန်နှင့် ပြီးဆုံးချိန်၊ တဂ်များ၊ မှတ်တမ်းများနှင့် အကြောင်းအရာတစ်ခုပါရှိသော အချို့သော အလုပ်အသွားအလာ (ဥပမာ၊ ဒေတာဘေ့စ်မေးမြန်းမှု) ၏ ဖော်ပြချက်ဖြစ်သည်။
• spans များသည် ပုံမှန်အားဖြင့် အခြား spans များသို့ လင့်ခ်များ ပါ၀င်ပြီး spans များစွာကို ပေါင်းစပ်နိုင်စေပါသည်။ သဲလွန်စ — ဖြန့်ဝေမှုစနစ်ဖြင့် ရွေ့လျားနေသည့် တောင်းဆိုချက်တစ်ခု၏ အသက်ကို ပုံဖော်ခြင်း။

သဲလွန်စများသည် ထုတ်လုပ်မှုစမ်းသပ်ခြင်း၊ ဘေးဥပဒ်ပြန်လည်ရယူခြင်းစမ်းသပ်ခြင်း၊ အမှားအယွင်းပြုလုပ်ခြင်းစမ်းသပ်ခြင်းစသည့်အလုပ်များအတွက် ကူညီပေးနိုင်သည့် မယုံနိုင်လောက်အောင်တန်ဖိုးရှိသောဒေတာများပါရှိသည်။ တကယ်တော့၊ အချို့သောကုမ္ပဏီများသည် အလားတူရည်ရွယ်ချက်များအတွက် ခြေရာခံခြင်းကို အသုံးပြုနေပြီဖြစ်သည်။ စကြရအောင် universal context လွှဲပြောင်းခြင်း။ သိုလှောင်မှုစနစ်သို့ ရိုးရှင်းစွာ ရွှေ့ခြင်းမှတပါး အခြားအသုံးပြုမှုများ ရှိသည်-

• ဥပမာ Uber အသုံးပြုမှု စမ်းသပ်အသွားအလာနှင့် ထုတ်လုပ်မှုအသွားအလာတို့ကို ခွဲခြားရန် ခြေရာခံရလဒ်များ။
• Facebook က အသုံးပြုမှု အရေးကြီးသောလမ်းကြောင်းခွဲခြမ်းစိတ်ဖြာမှုအတွက်နှင့် ပုံမှန်ဘေးအန္တရာယ်ပြန်လည်ရယူခြင်းစမ်းသပ်မှုများအတွင်း အသွားအလာပြောင်းခြင်းအတွက် ခြေရာခံဒေတာ။
• လူမှုကွန်ရက်လည်းဖြစ်သည်။ အကျုံးဝင်သည်။ သဲလွန်စရလဒ်များပေါ်တွင် ဆော့ဖ်ဝဲရေးသားသူများကို မထင်သလိုမေးမြန်းမှုများကို လုပ်ဆောင်ခွင့်ပြုသည့် Jupyter မှတ်စုစာအုပ်များ။
• နောက်လိုက်များ LDFI (မျိုးရိုးကို တွန်းလှန်ခြင်း ပျက်ကွက်မှု) အသုံးပြုသည် Error ဆေးထိုးခြင်းဖြင့် စမ်းသပ်ရန်အတွက် ဖြန့်ဝေထားသော ခြေရာများ။

အထက်ဖော်ပြပါ ရွေးချယ်စရာများ သည် အခြေအနေနှင့် လုံး၀ မသက်ဆိုင်ပါ။ ဒီဘာဂ်အဲဒီအတောအတွင်း အင်ဂျင်နီယာက သဲလွန်စကို ကြည့်ခြင်းအားဖြင့် ပြဿနာကို ဖြေရှင်းဖို့ ကြိုးစားပါတယ်။

လာတဲ့အခါ သေး အမှားရှာပြင်ခြင်း script သို့ရောက်ရှိပြီး ပင်မအင်တာဖေ့စ်သည် ပုံကြမ်းတွင်ကျန်ရှိနေသည်။ ခြေရာခံကြည့်ရှုခြင်း။ (တချို့က ခေါ်ပေမယ့် "Gantt ဇယား" သို့မဟုတ် "ရေတံခွန်ပုံကြမ်း") အောက်မှာ ခြေရာခံကြည့်ရှုခြင်း။ я ကျွန်တော်ဆိုလိုသည်မှာ အပိုင်းအားလုံးနှင့် မက်တာဒေတာများကို စုစည်း၍ သဲလွန်စကို ဖန်တီးသည်။ open source ခြေရာခံစနစ်တိုင်းနှင့် စီးပွားဖြစ် ခြေရာခံခြင်းဖြေရှင်းချက်တိုင်း၊ ခြေရာခံကြည့်ရှုခြင်း။ သဲလွန်စများကို မြင်ယောင်ခြင်း၊ အသေးစိတ်ဖော်ပြခြင်းနှင့် စစ်ထုတ်ခြင်းအတွက် အသုံးပြုသူ အင်တာဖေ့စ်။

အခုထိတွေ့ဖူးတဲ့ ခြေရာခံစနစ်အားလုံးရဲ့ ပြဿနာက ရလဒ်ပါပဲ။ ပုံဖော်ခြင်း (ခြေရာခံကြည့်ခြင်း) ခြေရာခံ မျိုးဆက်ဖြစ်စဉ်၏ အင်္ဂါရပ်များကို လုံးဝနီးပါး ရောင်ပြန်ဟပ်သည်။ အစားထိုးမြင်ယောင်မှုပုံစံများကို အဆိုပြုထားသည့်တိုင်- အပူမြေပုံများ၊ ဝန်ဆောင်မှုဆိုင်ရာ topologies၊ latency histograms၊ ၎င်းတို့သည် နောက်ဆုံးတွင် ရှိနေသေးသည်။ ခြေရာခံကြည့်ရှုခြင်း။.

အရင်တုန်းက ငါ စောဒကတက်သည်။ UI/UX ခြေရာခံခြင်း "ဆန်းသစ်တီထွင်မှုများ" အများစုသည် ကန့်သတ်ထားပုံရသည်။ ဖွင့်နေသည်။ သဲလွန်စထဲတွင် ထပ်ဆင့် မက်တာဒေတာ၊ မြင့်မားသော ကာဒီနယ်လစ်ဖြင့် ၎င်းတို့ကို အချက်အလက်များ မြှုပ်နှံထားသည်။ (ကာဒီနီယမ်မြင့်) သို့မဟုတ် သတ်သတ်မှတ်မှတ် အပိုင်းများအတွင်း တူးဖော်ရန် သို့မဟုတ် စုံစမ်းမေးမြန်းမှုများကို လုပ်ဆောင်ရန် စွမ်းရည်ကို ပံ့ပိုးပေးခြင်း inter- နှင့် intra-trace... ဘယ်မှာလဲ ခြေရာခံကြည့်ရှုခြင်း။ ပင်မအမြင်အာရုံတူးလ်အဖြစ် ကျန်ရှိနေပါသည်။ ဤအခြေအနေမျိုး ဆက်လက်ရှိနေသရွေ့၊ ဖြန့်ဝေမှု ခြေရာခံခြင်း (အကောင်းဆုံး) သည် မက်ထရစ်များ၊ မှတ်တမ်းများနှင့် အစုလိုက်ခြေရာခံပြီးနောက် အဆင့် (၄) နေရာသို့ အမှားရှာပြင်ခြင်းကိရိယာအဖြစ် နံပါတ် (၄) နေရာသို့ ရောက်သွားမည်ဖြစ်ပြီး အဆိုးဆုံးမှာ ၎င်းသည် ငွေနှင့် အချိန်ကို ဖြုန်းတီးသွားမည်ဖြစ်သည်။

ခြေရာခံကြည့်ရှုမှု ပြဿနာ

ကြမ္မ ခြေရာခံကြည့်ရှုခြင်း။ — ၎င်းနှင့်သက်ဆိုင်သည့် ဖြန့်ဝေသည့်စနစ်၏ အစိတ်အပိုင်းအားလုံးတွင် တောင်းဆိုချက်တစ်ခု၏ ရွေ့လျားမှု၏ ပြီးပြည့်စုံသောပုံကို ပံ့ပိုးပါ။ အချို့သော ပိုမိုအဆင့်မြင့်သော ခြေရာခံစနစ်များသည် သင့်အား တစ်ဦးချင်းအပိုင်းများအတွင်း ပိုင်းဖြတ်ကာ အချိန်နှင့်အမျှ ပိုင်းခြားမှုကို ကြည့်ရှုနိုင်စေပါသည်။ အတွင်း လုပ်ငန်းစဉ်တစ်ခု (အလျားအနံများ အလုပ်လုပ်နိုင်သော နယ်နိမိတ်များ ရှိသောအခါ)။

microservices ဗိသုကာ၏အခြေခံအကျဆုံးအချက်မှာ အဖွဲ့အစည်း၏ဖွဲ့စည်းပုံသည် ကုမ္ပဏီ၏လိုအပ်ချက်များနှင့်အတူ ကြီးထွားလာစေရန် စိတ်ကူးဖြစ်သည်။ အသေးစားဝန်ဆောင်မှုများ၏ အဆိုပြုသူများသည် ဝန်ဆောင်မှုတစ်ခုချင်းစီသို့ လုပ်ငန်းတာဝန်အမျိုးမျိုးကို ခွဲဝေပေးခြင်းသည် အသေးစား၊ ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များအား ယင်းဝန်ဆောင်မှုများ၏ ဘဝသံသရာတစ်ခုလုံးကို ထိန်းချုပ်နိုင်စေကာ ၎င်းတို့အား လွတ်လပ်စွာတည်ဆောက်ခြင်း၊ စမ်းသပ်ခြင်းနှင့် အသုံးချခြင်းတို့ကို လုပ်ဆောင်နိုင်စေသည်ဟု ငြင်းခုံကြသည်။ သို့သော်၊ ဤဖြန့်ဖြူးမှု၏အားနည်းချက်မှာ ဝန်ဆောင်မှုတစ်ခုစီသည် အခြားသူများနှင့် မည်သို့အပြန်အလှန်တုံ့ပြန်ပုံနှင့်ပတ်သက်သော အချက်အလက်ဆုံးရှုံးမှုဖြစ်သည်။ ထိုသို့သောအခြေအနေများတွင်၊ ဖြန့်ဝေခြေရာခံခြင်းသည် မရှိမဖြစ်လိုအပ်သောကိရိယာတစ်ခုဖြစ်သည်ဟု ဆိုကြသည်။ ဒီဘာဂ် ဝန်ဆောင်မှုများကြားတွင် ရှုပ်ထွေးသော အပြန်အလှန်ဆက်သွယ်မှုများ။

တကယ်ဆိုရင် သိသိသာသာ ရှုပ်ထွေးသော ဖြန့်ဝေမှုစနစ်သို့ဖြစ်လျှင် လူတစ်ဦးတစ်ယောက်မျှ သူ့ခေါင်းထဲတွင် မထားနိုင်ပေ။ ပြည့်စုံ ပုံ တကယ်တော့၊ ဖြစ်နိုင်ချေရှိသည်ဟူသောယူဆချက်အပေါ်အခြေခံသည့်ကိရိယာကိုတီထွင်ခြင်းသည်ဆန့်ကျင်ဘက်ပုံစံ (ထိရောက်မှုမရှိသောနှင့်အကျိုးမရှိသောချဉ်းကပ်မှု) တစ်ခုဖြစ်သည်။ အကောင်းဆုံးကတော့၊ အမှားရှာပြင်ခြင်းက ကူညီပေးတဲ့ ကိရိယာတစ်ခု လိုအပ်တယ်။ သင်၏ရှာဖွေမှုဧရိယာကို ကျဉ်းမြောင်းစေသည်။သို့မှသာ အင်ဂျင်နီယာများသည် ထည့်သွင်းစဉ်းစားနေသည့် ပြဿနာနှင့် သက်ဆိုင်သည့် အတိုင်းအတာ (ဝန်ဆောင်မှုများ/အသုံးပြုသူများ/အိမ်ရှင်များ စသည်) ကို အာရုံစိုက်နိုင်မည်ဖြစ်သည်။ ပျက်ကွက်ရခြင်းအကြောင်းရင်းကို ဆုံးဖြတ်ရာတွင် အင်ဂျင်နီယာများသည် အဆိုပါကာလအတွင်း ဖြစ်ပျက်ခဲ့သည်များကို နားလည်ရန် မလိုအပ်ပါ။ ဝန်ဆောင်မှုအားလုံးကို တစ်ပြိုင်နက်ထိုသို့သော လိုအပ်ချက်သည် မိုက်ခရိုဆားဗစ်ဗိသုကာ၏ အယူအဆကို ဆန့်ကျင်နေသောကြောင့် ဖြစ်သည်။

သို့သော် traceview သည် အမည်ရ ဒီ. ဟုတ်ပါသည်၊ အချို့သော ခြေရာခံစနစ်များသည် trace ရှိ spans အရေအတွက် အလွန်ကြီးမားသောအခါ ၎င်းတို့ကို မြင်သာသည့်ပုံဖော်ချက်တစ်ခုတွင် မပြသနိုင်ဘဲ ဖိသိပ်ထားသည့် ခြေရာခံကြည့်ရှုမှုများကို ပံ့ပိုးပေးပါသည်။ သို့သော် ထိုကဲ့သို့ ချွတ်ခြုံကျနေသည့် စိတ်ကူးပုံဖော်မှုတွင်ပင် ပါ၀င်သော အချက်အလက် အများအပြားကြောင့် အင်ဂျင်နီယာများသည် ငြိမ်နေသေးသည်။ အတင်းအကြပ် ၎င်းကို "ခွဲထုတ်ပါ"၊ ရွေးချယ်မှုကို ပြဿနာများ၏ရင်းမြစ်ဖြစ်သော ဝန်ဆောင်မှုအစုတစ်ခုသို့ ကိုယ်တိုင်ကျဉ်းမြောင်းစေသည်။ ကံမကောင်းစွာဖြင့်၊ ဤနယ်ပယ်တွင် စက်များသည် လူသားများထက် များစွာမြန်သည်၊ အမှားအယွင်းများ ဖြစ်နိုင်ခြေနည်းပြီး ၎င်းတို့၏ ရလဒ်များသည် ထပ်ခါတလဲလဲ ဖြစ်နိုင်သည်။

traceview မှားနေသည်ဟု ကျွန်တော်ထင်သည့် နောက်အကြောင်းရင်းတစ်ခုမှာ ၎င်းသည် သီအိုရီမောင်းနှင်သော အမှားရှာပြင်ခြင်းအတွက် မကောင်းသောကြောင့်ဖြစ်သည်။ ၎င်း၏အဓိကမှာ၊ အမှားရှာပြင်ခြင်းဖြစ်ပါသည်။ ထပ်ခါထပ်ခါ အယူအဆတစ်ခုဖြင့် စတင်သည့် လုပ်ငန်းစဉ်တစ်ခု၊ ထို့နောက်တွင် မတူညီသော vector များတစ်လျှောက် စနစ်မှရရှိသော အမျိုးမျိုးသော ရှုမြင်သုံးသပ်မှုများနှင့် အချက်အလက်များကို စိစစ်ခြင်း၊ ကောက်ချက်ချခြင်း/အထွေထွေ ဖော်ထုတ်ခြင်းနှင့် ယူဆချက်၏အမှန်တရားကို ထပ်မံအကဲဖြတ်ခြင်းများ ပြုလုပ်သည်။

အခွင့်အရေး မြန်ဆန်ပြီး စျေးပေါတယ်။ အယူအဆများကို စမ်းသပ်ခြင်းနှင့် စိတ်ပိုင်းဆိုင်ရာ စံနမူနာများနှင့်အညီ တိုးတက်စေခြင်း ဖြစ်ပါ သည်။ အုတ်မြစ် အမှားရှာခြင်း။ မည်သည့် debugging tool ရှိသင့်သည်။ အပြန်အလှန်အကျိုးပြုသော ရှာဖွေမှုနေရာအား ကျဉ်းမြောင်းစေခြင်း သို့မဟုတ် မှားယွင်းသောဦးတည်ချက်တစ်ခုအတွက် အသုံးပြုသူကို ပြန်သွားကာ စနစ်၏ မတူညီသောဧရိယာကို အာရုံစိုက်ခွင့်ပြုပါ။ ပြီးပြည့်စုံတဲ့ tool က ဒါကိုလုပ်ပါလိမ့်မယ်။ တက်ကြွစွာဖြစ်နိုင်ချေရှိသော ပြဿနာဧရိယာများဆီသို့ သုံးစွဲသူ၏အာရုံကို ချက်ချင်းဆွဲသွင်းပါ။

ဖြစ်ချင်တော့၊ ခြေရာခံကြည့်ရှုခြင်း။ အပြန်အလှန်အကျိုးပြုသော အင်တာဖေ့စ်ပါသည့် ကိရိယာတစ်ခုဟု ခေါ်၍မရပါ။ ၎င်းကိုအသုံးပြုသည့်အခါ သင်မျှော်လင့်နိုင်သည့် အကောင်းဆုံးမှာ ကြာမြင့်ချိန်၏ ရင်းမြစ်အချို့ကို ရှာဖွေပြီး ၎င်းနှင့် ဆက်စပ်နေသည့် ဖြစ်နိုင်သည့် တဂ်များနှင့် မှတ်တမ်းအားလုံးကို ကြည့်ရှုရန်ဖြစ်သည်။ ဒါက အင်ဂျင်နီယာကို ဖော်ထုတ်ဖို့ မကူညီပါဘူး။ ပုံစံများ နှောင့်နှေးမှု၏ သီးခြားခွဲဝေမှုကဲ့သို့သော အသွားအလာတွင်၊ သို့မဟုတ် မတူညီသော တိုင်းတာမှုများအကြား ဆက်စပ်မှုများကို ရှာဖွေပါ။ ယေဘုယျခြေရာခံ ခွဲခြမ်းစိတ်ဖြာခြင်း။ ဤပြဿနာများထဲမှ အချို့ကို ကူညီဖြေရှင်းပေးနိုင်သည်။ တကယ်လား၊ ဥပမာတွေရှိတယ်။ မှားယွင်းသောအကွာအဝေးများကိုခွဲခြားသတ်မှတ်ရန်နှင့် ပုံမှန်မဟုတ်သောအပြုအမူများနှင့်ဆက်စပ်နိုင်သည့် တဂ်အခွဲများကိုခွဲခြားသတ်မှတ်ရန် စက်သင်ယူမှုကိုအသုံးပြု၍ အောင်မြင်သောခွဲခြမ်းစိတ်ဖြာခြင်း။ သို့သော်လည်း၊ ခြေရာခံကြည့်ရှုခြင်း သို့မဟုတ် DAG (ညွှန်ကြား acyclic ဂရပ်ဖစ်) နှင့် သိသိသာသာကွာခြားသည့် အပိုင်းများတွင် အသုံးပြုသည့် စက်သင်ယူမှု သို့မဟုတ် ဒေတာတူးဖော်ခြင်းဆိုင်ရာ တွေ့ရှိချက်များကို ဆွဲဆောင်နိုင်သော ပုံရိပ်ယောင်များကို ကျွန်ုပ်မတွေ့ရသေးပါ။

အတိုင်းအတာများသည် အဆင့်နိမ့်လွန်းသည်။

ခြေရာခံကြည့်ခြင်း၏ အခြေခံပြဿနာမှာ ထိုသို့ဖြစ်သည်။ spans latency analysis နှင့် root cause analysis နှစ်ခုစလုံးအတွက် အဆင့်နိမ့်သော primitives များဖြစ်သည်။ ၎င်းသည် ခြွင်းချက်တစ်ခုအား ဖြေရှင်းရန် ကြိုးစားရန် ပရိုဆက်ဆာတစ်ခုချင်းစီ၏ အမိန့်များကို ခွဲခြမ်းစိပ်ဖြာခြင်းနှင့် လုပ်ဆောင်ရန် ပိုမိုအဆင်ပြေသည့် backtrace ကဲ့သို့သော အဆင့်မြင့် ကိရိယာများ ရှိကြောင်း သိထားခြင်းဖြစ်သည်။

ထို့အပြင်၊ အောက်ပါတို့ကို အခိုင်အမာပြောဆိုခြင်း၏ လွတ်လပ်ခွင့်ကို ကျွန်ုပ်ယူပါမည်- အကောင်းဆုံးအားဖြင့်၊ ကျွန်ုပ်တို့ မလိုအပ်ပါ။ ပုံအပြည့်အစုံ ခေတ်မီခြေရာခံကိရိယာများဖြင့် ကိုယ်စားပြုသည့် တောင်းဆိုမှုဘဝစက်ဝန်းအတွင်း ဖြစ်ပေါ်ခဲ့သည်။ ယင်းအစား၊ မည်သည့်အရာနှင့် ပတ်သက်သည့် အချက်အလက်များပါ၀င်သော အဆင့်မြင့်အဆင့် abstraction ပုံစံအချို့ လိုအပ်ပါသည်။ မှားသွားသည်။ အကြောင်းအရာအချို့နှင့်အတူ (backtrace နှင့်ဆင်တူသည်)။ လမ်းကြောင်းတစ်ခုလုံးကို ကြည့်မယ့်အစား အဲဒါကို ကြည့်ရတာ ပိုကြိုက်တယ်။ အပိုင်းစိတ်ဝင်စားစရာ သို့မဟုတ် ထူးထူးခြားခြား တစ်စုံတစ်ရာ ဖြစ်ပေါ်လာသည့်နေရာ။ လက်ရှိတွင်၊ ရှာဖွေမှုကို ကိုယ်တိုင်လုပ်ဆောင်သည်- အင်ဂျင်နီယာသည် သဲလွန်စကို လက်ခံရရှိပြီး စိတ်ဝင်စားစရာကောင်းသောအရာကို ရှာဖွေရန်အတွက် အပိုင်းများကို သီးခြားခွဲခြမ်းစိတ်ဖြာသည်။ သံသယဖြစ်ဖွယ် လုပ်ဆောင်ချက်ကို ထောက်လှမ်းရန် မျှော်လင့်ချက်ဖြင့် တစ်ဦးချင်းစီ ခြေရာများကို စိုက်ကြည့်နေသော လူများ၏ ချဉ်းကပ်မှုသည် အတိုင်းအတာ လုံးဝ အတိုင်းအတာ မဟုတ်ပါ (အထူးသဖြင့် ၎င်းတို့သည် မတူညီသော span ID ကဲ့သို့သော span ID၊ RPC နည်းလမ်းအမည်၊ span ကြာချိန်ကဲ့သို့ ကွဲပြားသော ကုဒ်လုပ်ထားသော metadata အားလုံးကို နားလည်သဘောပေါက်ရန် လိုအပ်သောအခါ၊ a, logs, tags, etc.)။

ခြေရာခံကြည့်ရှုရန် အခြားရွေးချယ်စရာများ

စနစ်၏ အပြန်အလှန်ဆက်နွယ်နေသော အစိတ်အပိုင်းများတွင် ဖြစ်ပျက်နေသည့်အရာများကို အသေးအဖွဲမဟုတ်သော ထိုးထွင်းသိမြင်မှုကို ပေးသည့်နည်းဖြင့် ၎င်းတို့ကို မြင်သာအောင် မြင်နိုင်သည့်အခါ ခြေရာခံရလဒ်များကို အသုံးဝင်ဆုံးဖြစ်သည်။ ဒီလိုမဖြစ်လာခင်အထိ၊ အမှားရှာပြင်တဲ့ လုပ်ငန်းစဉ်က အများကြီးကျန်ပါသေးတယ်။ အစွမ်းသတ္တိ မှန်ကန်သောဆက်စပ်မှုများကို သတိပြုမိရန်၊ စနစ်၏ မှန်ကန်သောအစိတ်အပိုင်းများကို စစ်ဆေးရန် သို့မဟုတ် ပဟေဠိအပိုင်းများကို ပေါင်းစည်းရန် အသုံးပြုသူ၏စွမ်းရည်အပေါ် မူတည်သည် - ဆန့်ကျင်ဘက်ဖြစ်သည်။ တူရိယာသုံးစွဲသူအား ဤယူဆချက်များကို ပုံဖော်ရာတွင် ကူညီပေးသည်။

ကျွန်ုပ်သည် ရုပ်မြင်သံကြားဒီဇိုင်နာ သို့မဟုတ် UX အထူးကျွမ်းကျင်သူမဟုတ်ပါ၊ သို့သော် နောက်အပိုင်းတွင် ဤမြင်ယောင်ပုံဖော်မှုများသည် မည်သို့မည်ပုံဖြစ်နိုင်သည်နှင့်ပတ်သက်၍ အကြံဥာဏ်အနည်းငယ်ကို ကျွန်ုပ်မျှဝေလိုပါသည်။

သီးသန့်ဝန်ဆောင်မှုများကို အာရုံစိုက်ပါ။

စက်မှုလုပ်ငန်းသည် စိတ်ကူးစိတ်သန်းများ စုစည်းနေသည့်အချိန်ဖြစ်သည်။ SLO (ဝန်ဆောင်မှုအဆင့်ရည်မှန်းချက်များ) နှင့် SLI (ဝန်ဆောင်မှုအဆင့်ညွှန်းကိန်းများ)အဖွဲ့များသည် ၎င်းတို့၏ဝန်ဆောင်မှုများသည် ဤပန်းတိုင်များနှင့်ကိုက်ညီမှုရှိမရှိကို ဦးစားပေးသင့်သည်ဟု ထင်မြင်ယူဆပါသည်။ အဲဒါကို လိုက်နာတယ်။ ဝန်ဆောင်မှုကို ဦးတည်သည်။ စိတ်ကူးပုံဖော်ခြင်းသည် ထိုကဲ့သို့သောအသင်းများအတွက် အသင့်တော်ဆုံးဖြစ်သည်။

အထူးသဖြင့် နမူနာမယူဘဲ ခြေရာခံများသည် ဖြန့်ဝေမှုစနစ်တစ်ခုစီ၏ အစိတ်အပိုင်းတစ်ခုစီ၏ အချက်အလက်များ၏ ရတနာသိုက်ဖြစ်သည်။ ဤအချက်အလက်ကို သုံးစွဲသူများအား ထောက်ပံ့ပေးမည့် လိမ္မာပါးနပ်သော ပရိုဆက်ဆာထံ ပေးပို့နိုင်ပါသည်။ ဝန်ဆောင်မှုကို ဦးတည်သည်။ တွေ့ရှိချက်။ ၎င်းတို့ကို အသုံးပြုသူက ခြေရာများကို မကြည့်ရှုမီတွင်ပင် ၎င်းတို့ကို ကြိုတင်ဖော်ထုတ်နိုင်သည်-

1. အလွန်ထင်ရှားသော တောင်းဆိုမှုများအတွက်သာ latency ဖြန့်ဖြူးမှု ပုံများ (ပို၍တောင်းဆိုမှုများ);
2. ဝန်ဆောင်မှု SLO ပန်းတိုင်များ မအောင်မြင်သောအခါ ကိစ္စများအတွက် နှောင့်နှေးမှု ဖြန့်ဝေမှု ပုံကြမ်းများ၊
3. မကြာခဏမေးလေ့ရှိသောမေးခွန်းများတွင် "အများအားဖြင့်" "စိတ်ဝင်စားစရာ" နှင့် "ထူးဆန်း" တဂ်များ ထပ်ခါထပ်ခါ;
4. Latency breakdown သည် မည်သည့်နေရာတွင်ရှိသနည်း။ ပေါ် မူတည်. ဝန်ဆောင်မှုများသည် ၎င်းတို့၏ SLO ပန်းတိုင်များကို မအောင်မြင်နိုင်ပါ။
5. အမျိုးမျိုးသော downstream ဝန်ဆောင်မှုများအတွက် latency ခွဲခြမ်းစိတ်ဖြာခြင်း။

ဤမေးခွန်းများထဲမှ အချို့သည် အတိုင်းအတာများကို စိစစ်ရန် သုံးစွဲသူများကို ခိုင်းစေသော built-in မက်ထရစ်များဖြင့် ရိုးရှင်းစွာ အဖြေမပေးနိုင်ပါ။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့တွင် အလွန်အမင်း အသုံးပြုသူ-ရန်လိုသော ယန္တရားတစ်ခုရှိသည်။

ယင်းက မေးခွန်းထုတ်သည်- မတူညီသောအဖွဲ့များက ထိန်းချုပ်ထားသော မတူကွဲပြားသောဝန်ဆောင်မှုများကြားတွင် ရှုပ်ထွေးသောအပြန်အလှန်တုံ့ပြန်မှုများကကော။ မဟုတ်လား။ ခြေရာခံကြည့်ရှုခြင်း။ ထိုသို့သော အခြေအနေများကို မီးမောင်းထိုးပြရန် အသင့်တော်ဆုံး ကိရိယာဟု မယူဆဘူးလား။

မိုဘိုင်းဆော့ဖ်ဝဲရေးသားသူများ၊ နိုင်ငံမဲ့ဝန်ဆောင်မှုများ ပိုင်ရှင်များ၊ စီမံခန့်ခွဲထားသော နိုင်ငံပိုင်ဝန်ဆောင်မှုများ (ဒေတာဘေ့စ်များကဲ့သို့) ပိုင်ရှင်များနှင့် ပလပ်ဖောင်းပိုင်ရှင်များသည် အခြားအရာတစ်ခုခုကို စိတ်ဝင်စားနိုင်သည် တင်ပြချက် ဖြန့်ဝေစနစ်; ခြေရာခံကြည့်ရှုခြင်း။ ဤအခြေခံ ကွဲပြားသော လိုအပ်ချက်များအတွက် အဖြေသည် ယေဘုယျဆန်လွန်းသည်။ အလွန်ရှုပ်ထွေးသော မိုက်ခရိုဆားဗစ်ဗိသုကာတွင်ပင်၊ ဝန်ဆောင်မှုပိုင်ရှင်များသည် အထက်ပိုင်းနှင့် အောက်ပိုင်း ဝန်ဆောင်မှုနှစ်ခု သို့မဟုတ် သုံးခုထက်ပိုသော နက်နဲသောအသိပညာကို မလိုအပ်ပါ။ အခြေခံအားဖြင့်၊ အခြေအနေအများစုတွင် သုံးစွဲသူများနှင့် ပတ်သက်သည့် မေးခွန်းများကိုသာ ဖြေရန် လိုအပ်ပါသည်။ အကန့်အသတ်ရှိသော ဝန်ဆောင်မှုများ.

၎င်းသည် ၎င်းကို စိစစ်ရန်အလို့ငှာ ၎င်းကို စိစစ်ရန်အတွက် မှန်ဘီလူးဖြင့် သေးငယ်သော ဝန်ဆောင်မှုများ၏ အစုအဝေးကို ကြည့်ရသလိုပင်။ ၎င်းသည် အသုံးပြုသူအား ဤဝန်ဆောင်မှုများကြားတွင် ရှုပ်ထွေးသောအပြန်အလှန်တုံ့ပြန်မှုများနှင့် ၎င်းတို့၏ချက်ချင်းမှီခိုမှုများနှင့် ပတ်သက်၍ ပိုမိုပြင်းထန်သောမေးခွန်းများကို မေးမြန်းနိုင်စေမည်ဖြစ်သည်။ ၎င်းသည် အင်ဂျင်နီယာမှ သိရှိသည့် ဝန်ဆောင်မှုလောကရှိ backtrace နှင့် ဆင်တူသည်။ ထို မှားယွင်းနေပြီး နားလည်ရန် အနီးနားရှိ ဝန်ဆောင်မှုများတွင် ဖြစ်ပျက်နေသည့် နားလည်မှုအချို့လည်းရှိသည်။ ဘာကွောငျ့.

ငါမြှင့်တင်ပေးသည့်ချဉ်းကပ်မှုမှာ ခွဲခြမ်းစိတ်ဖြာမှုတစ်ခုလုံးကို ခြေရာခံခြင်းမှအစပြုကာ တစ်ဦးချင်းအစီအစဥ်များအထိ ဖြည်းဖြည်းချင်းလုပ်ဆောင်သည့်အပေါ်မှအောက်သို့၊ ခြေရာခံကြည့်ရှုမှုအခြေခံချဉ်းကပ်မှု၏ ဆန့်ကျင်ဘက်ဖြစ်သည်။ ဆန့်ကျင်ဘက်အားဖြင့်၊ အောက်ခြေမှချဉ်းကပ်မှုတစ်ခုသည် အဖြစ်အပျက်ဖြစ်နိုင်ချေနှင့် နီးစပ်သည့် ဧရိယာငယ်တစ်ခုကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် အစပြုကာ လိုအပ်သလို ရှာဖွေရန်နေရာကို ချဲ့ထွင်သည် (ပိုမိုကျယ်ပြန့်သော ဝန်ဆောင်မှုများကို ခွဲခြမ်းစိတ်ဖြာရန် အခြားအဖွဲ့များကို ခေါ်ယူနိုင်သည့် အလားအလာနှင့်အတူ)။ ဒုတိယနည်းလမ်းသည် ကနဦးယူဆချက်များကို လျင်မြန်စွာစမ်းသပ်ရန်အတွက် ပိုမိုကောင်းမွန်ပါသည်။ ခိုင်မာသောရလဒ်များရရှိပြီးသည်နှင့် ပိုမိုအာရုံစိုက်ပြီး အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာမှုဆီသို့ ဆက်လက်လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

topology တည်ဆောက်ခြင်း။

အသုံးပြုသူသိပါက ဝန်ဆောင်မှုဆိုင်ရာ သီးသန့်ကြည့်ရှုမှုများသည် မယုံနိုင်လောက်အောင် အသုံးဝင်ပါသည်။ အရာ ဝန်ဆောင်မှုတစ်ခု သို့မဟုတ် ဝန်ဆောင်မှုအုပ်စုတစ်ခုသည် အချိန်ကြာမြင့်မှု တိုးလာစေရန် သို့မဟုတ် အမှားအယွင်းများဖြစ်စေရန်အတွက် တာဝန်ရှိပါသည်။ သို့ရာတွင်၊ ရှုပ်ထွေးသောစနစ်တစ်ခုတွင်၊ အထူးသဖြင့် ဝန်ဆောင်မှုများမှ အမှားအယွင်းမက်ဆေ့ချ်များကို အစီရင်ခံခြင်းမရှိပါက ပျက်ကွက်စဉ်အတွင်း အသေးအဖွဲမဟုတ်သော အလုပ်ဖြစ်နိုင်သည်။

ဝန်ဆောင်မှု topology တစ်ခုကို တည်ဆောက်ခြင်းသည် မည်သည့်ဝန်ဆောင်မှုတွင် မှားယွင်းမှုနှုန်းများ မြင့်တက်နေခြင်း သို့မဟုတ် ဝန်ဆောင်မှုကို သိသိသာသာ ကျဆင်းသွားစေသည့် latency တိုးလာခြင်းကို ရှာဖွေရာတွင် ကြီးမားသောအကူအညီဖြစ်နိုင်ပါသည်။ topology တစ်ခုတည်ဆောက်ခြင်းအကြောင်းပြောသောအခါ၊ ကျွန်တော် မဆိုလိုပါ။ ဝန်ဆောင်မှုမြေပုံစနစ်တွင်ရရှိနိုင်သောဝန်ဆောင်မှုတိုင်းကိုပြသပြီး၎င်း၏လူသိများသည်။ မရဏကြယ်ပုံသဏ္ဍာန်ရှိသော ဗိသုကာလက်ရာမြေပုံများ. ဤမြင်ကွင်းသည် ညွှန်ကြားထားသည့် acyclic ဂရပ်ဖစ်ပေါ်အခြေခံ၍ ခြေရာခံကြည့်ရှုခြင်းထက် ပိုကောင်းမည်မဟုတ်ပါ။ အဲဒီ့အစား မြင်ချင်ပါတယ်။ ဒိုင်းနမစ်ဖြင့် ထုတ်ပေးသော ဝန်ဆောင်မှု topologyအမှားအယွင်းနှုန်း၊ တုံ့ပြန်မှုအချိန် သို့မဟုတ် သံသယဖြစ်ဖွယ်ဝန်ဆောင်မှုများဖြင့် အခြေအနေကို ရှင်းလင်းရန် ကူညီပေးသည့် အသုံးပြုသူသတ်မှတ်ထားသော ကန့်သတ်ဘောင်များကဲ့သို့သော အရည်အချင်းအချို့အပေါ် အခြေခံထားသည်။

ဥပမာတစ်ခုယူကြည့်ရအောင်။ အယောင်ဆောင်သော သတင်းဆိုဒ်တစ်ခုကို စိတ်ကူးကြည့်ကြပါစို့။ ပင်မစာမျက်နှာဝန်ဆောင်မှု (ရှေ့စာမျက်နှာ) ကြော်ငြာဝန်ဆောင်မှုနှင့် ဗီဒီယိုဝန်ဆောင်မှုဖြင့် အကြံပြုချက်ဝန်ဆောင်မှုဖြင့် ဒေတာဖလှယ်သည်။ ဗီဒီယိုဝန်ဆောင်မှုသည် S3 မှ ဗီဒီယိုများနှင့် DynamoDB မှ မက်တာဒေတာကို ယူသည်။ အကြံပြုချက် ဝန်ဆောင်မှုသည် DynamoDB မှ မက်တာဒေတာကို လက်ခံရရှိပြီး Redis နှင့် MySQL မှ ဒေတာများကို ရယူပြီး Kafka သို့ မက်ဆေ့ချ်များ ရေးပေးသည်။ ကြော်ငြာဝန်ဆောင်မှုသည် MySQL မှဒေတာကိုလက်ခံရရှိပြီး Kafka သို့ မက်ဆေ့ချ်များရေးသားသည်။

အောက်တွင် ဤ topology ၏ ဇယားကွက်ကို ကိုယ်စားပြုသည် (လုပ်ငန်းသုံးလမ်းကြောင်းပြပရိုဂရမ်များစွာသည် topology ကိုတည်ဆောက်သည်)။ ဝန်ဆောင်မှု မှီခိုမှုကို နားလည်ရန် လိုအပ်ပါက ၎င်းသည် အသုံးဝင်နိုင်သည်။ သို့သော် ဒီဘာဂ်ဝန်ဆောင်မှုတစ်ခု (ဆိုပါစို့ ဗီဒီယို ဝန်ဆောင်မှုတစ်ခု) သည် တုံ့ပြန်မှုအချိန် တိုးလာသောအခါ၊ ထိုသို့သော topology သည် အလွန်အသုံးမဝင်ပါ။

ဟန်ချက်ညီသော သတင်းဆိုက်တစ်ခု၏ ဝန်ဆောင်မှုပုံကြမ်း

အောက်ဖော်ပြပါ ပုံသည် ပိုသင့်တော်ပါသည်။ ဝန်ဆောင်မှုတွင် ပြဿနာရှိနေသည်။ (ဗီဒီယို) အလယ်ဗဟိုတွင် ပုံဖော်ထားသည်။ သုံးစွဲသူက ချက်ချင်း သတိထားမိတယ်။ ဤမြင်ယောင်မှုမှ၊ ပင်မစာမျက်နှာ၏ loading speed ကိုသက်ရောက်သည့် S3 တုံ့ပြန်မှုအချိန်တိုးလာခြင်းကြောင့် ဗီဒီယိုဝန်ဆောင်မှုသည် ပုံမှန်မဟုတ်စွာ အလုပ်လုပ်နေကြောင်း ရှင်းရှင်းလင်းလင်းဖြစ်လာသည်။

"စိတ်ဝင်စားစရာ" ဝန်ဆောင်မှုများကိုသာ ပြသသည့် ဒိုင်းနမစ် topology

အထူးသဖြင့် ပျော့ပျောင်းသော၊ အလိုအလျောက်စကေးချသည့် အခြေခံအဆောက်အအုံများတွင် တည်ငြိမ်သောဝန်ဆောင်မှုမြေပုံများထက် ဒိုင်းနမစ်ဖြင့်ထုတ်လုပ်ထားသော topologies များသည် ပိုမိုထိရောက်နိုင်သည်။ ဝန်ဆောင်မှု topologies များကို နှိုင်းယှဉ်ခြင်းနှင့် ဆန့်ကျင်ဘက်ပြုနိုင်စွမ်းသည် သုံးစွဲသူအား ပိုမိုသက်ဆိုင်ရာမေးခွန်းများကို မေးနိုင်စေပါသည်။ စနစ်နှင့်ပတ်သက်သော ပိုမိုတိကျသောမေးခွန်းများသည် စနစ်၏အလုပ်လုပ်ပုံကို ပိုမိုနားလည်သဘောပေါက်ရန် အလားအလာပိုများပါသည်။

နှိုင်းယှဉ်ပြသမှု

နောက်ထပ်အသုံးဝင်သော စိတ်ကူးပုံဖော်မှုမှာ နှိုင်းယှဉ်ပြသမှုတစ်ခုဖြစ်သည်။ လောလောဆယ် ခြေရာခံများသည် ဘေးချင်းကပ် နှိုင်းယှဉ်မှုများအတွက် အလွန်သင့်လျော်ခြင်းမရှိပါ၊ ထို့ကြောင့် နှိုင်းယှဉ်မှုများသည် အများအားဖြင့်ဖြစ်သည်။ spans. ထို့အပြင် ဤဆောင်းပါး၏ အဓိက အယူအဆမှာ ခြေရာခံ ရလဒ်များမှ တန်ဖိုးအရှိဆုံး အချက်အလက်များကို ထုတ်ယူရန် အပိုင်းများသည် အလွန်နိမ့်ပါးလွန်းသည်ဟု အတိအကျ အတိအကျပင် ဖြစ်သည်။

ခြေရာနှစ်ချောင်းကို နှိုင်းယှဉ်ခြင်းသည် အခြေခံအားဖြင့် အမြင်အာရုံအသစ်များ မလိုအပ်ပါ။ တကယ်တော့၊ ခြေရာခံကြည့်ခြင်းကဲ့သို့ တူညီသော အချက်အလက်ကို ကိုယ်စားပြုသည့် ဟစ်စတိုဂရမ်ကဲ့သို့ အရာတစ်ခုသည် လုံလောက်ပါသည်။ အံ့သြစရာကောင်းတာက၊ ဒီရိုးရှင်းတဲ့နည်းလမ်းက ခြေရာနှစ်ခုကို သီးခြားစီလေ့လာရုံထက် အသီးအနှံတွေ အများကြီးယူဆောင်လာနိုင်ပါတယ်။ ဖြစ်နိုင်ခြေက ပိုလို့တောင် အားကောင်းလာလိမ့်မယ်။ မြင်ယောင် ခြေရာများကို နှိုင်းယှဉ်ခြင်း။ စုစုပေါင်း. GC (အမှိုက်စုဆောင်းခြင်း) ကိုဖွင့်ရန် မကြာသေးမီက အသုံးပြုထားသည့် ဒေတာဘေ့စ်ဖွဲ့စည်းပုံပြောင်းလဲမှုသည် ရေအောက်ဝန်ဆောင်မှုတစ်ခု၏ တုံ့ပြန်မှုအချိန်နာရီများစွာအပေါ် သက်ရောက်မှုရှိပုံကို ကြည့်ရှုရန် အလွန်အသုံးဝင်မည်ဖြစ်သည်။ ဤနေရာတွင် ကျွန်ုပ်ဖော်ပြသည့်အရာသည် အခြေခံအဆောက်အအုံ ပြောင်းလဲမှုများ၏ အကျိုးသက်ရောက်မှုကို A/B ခွဲခြမ်းစိတ်ဖြာမှုတစ်ခုကဲ့သို့ အသံဖြစ်လျှင် ဝန်ဆောင်မှုများစွာတွင် ခြေရာခံရလဒ်များကို အသုံးပြု၍ သင်သည် အမှန်တရားနှင့် သိပ်မဝေးပါ။

ကောက်ချက်

ခြေရာခံခြင်း၏ အသုံးဝင်မှုကို ကျွန်တော်ကိုယ်တိုင် မေးခွန်းထုတ်မနေပါ။ ကြွယ်ဝသော၊ အကြောင်းအရင်းနှင့် လမ်းကြောင်းတစ်ခုတွင်ပါရှိသော အကြောင်းအရာများကဲ့သို့ ကြွယ်ဝသော၊ အကြောင်းရင်းနှင့် ဆက်စပ်အချက်အလက်များကို စုဆောင်းရန်အတွက် အခြားနည်းလမ်းမရှိဟု ကျွန်ုပ် ရိုးသားစွာ ယုံကြည်ပါသည်။ သို့သော်၊ ခြေရာခံခြင်းဖြေရှင်းချက်အားလုံးသည် ဤဒေတာကို အလွန်ထိရောက်မှုမရှိစွာ အသုံးပြုသည်ဟုလည်း ကျွန်ုပ်ယုံကြည်ပါသည်။ ခြေရာခံကိရိယာများသည် ခြေရာခံကြည့်ရှုခြင်းကိုယ်စားပြုမှုတွင် ကပ်နေသရွေ့၊ ၎င်းတို့သည် ခြေရာခံပါရှိသည့်ဒေတာများမှ ထုတ်ယူနိုင်သည့် အဖိုးတန်အချက်အလက်များကို အများဆုံးပြုလုပ်နိုင်မှုတွင် ၎င်းတို့၏စွမ်းရည်ကို ကန့်သတ်ထားမည်ဖြစ်သည်။ ထို့အပြင်၊ အသုံးပြုသူ၏အပလီကေးရှင်းအတွင်းရှိအမှားအယွင်းများကိုဖြေရှင်းနိုင်စွမ်းကိုပြင်းထန်စွာကန့်သတ်မည့်လုံးဝဖော်ရွေမှုမရှိသောနှင့်နားလည်သဘောမကျသောအမြင်အာရုံမျက်နှာပြင်ကိုထပ်မံဖန်တီးရန်အန္တရာယ်ရှိသည်။

နောက်ဆုံးပေါ်ကိရိယာများဖြင့်ပင် ရှုပ်ထွေးသောစနစ်များကို အမှားရှာခြင်းသည် မယုံနိုင်လောက်အောင် ခက်ခဲသည်။ Tools များသည် developer မှ hypothesis တစ်ခုကို ပုံဖော်ရန်နှင့် စမ်းသပ်ရန် ကူညီပေးသင့်သည်၊ တက်ကြွစွာ ဆောင်ရွက်ပေးသည်။ နှောင့်နှေးမှုများ ဖြန့်ဝေမှုတွင် သက်ဆိုင်ရာ အချက်အလက်များ၊ ထုတ်လုပ်မှု ချို့ယွင်းချက်များကို ဖြေရှင်းခြင်း သို့မဟုတ် ဝန်ဆောင်မှုများစွာပါဝင်သည့် ပြဿနာများကို ဖြေရှင်းရာတွင် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအတွက် ရွေးချယ်စရာကိရိယာဖြစ်လာစေရန် ခြေရာခံခြင်းအတွက်၊ ထိုဝန်ဆောင်မှုများကို ဖန်တီးလုပ်ဆောင်သော developer များ၏ စိတ်ပိုင်းဆိုင်ရာပုံစံနှင့် ပိုမိုကိုက်ညီသော မူလအသုံးပြုသူ အင်တာဖေ့စ်များနှင့် အမြင်အာရုံပုံဖော်မှုများ လိုအပ်ပါသည်။

ခွဲခြမ်းစိတ်ဖြာမှု လွယ်ကူစေရန်နှင့် ကောက်ချက်ချနိုင်စေရန် အကောင်းဆုံးနည်းလမ်းဖြင့် ခြေရာခံရလဒ်များတွင် ရရှိနိုင်သည့် အမျိုးမျိုးသော အချက်ပြမှုများကို ကိုယ်စားပြုမည့် စနစ်တစ်ခုကို ဒီဇိုင်းရေးဆွဲရန် သိသာထင်ရှားသော စိတ်ပိုင်းဆိုင်ရာ အားထုတ်မှု လိုအပ်မည်ဖြစ်သည်။ အသုံးပြုသူသည် ခြေရာခံများ သို့မဟုတ် အပိုင်းများကို မကြည့်ဘဲ မျက်မမြင်အစက်အပြောက်များကို ကျော်လွှားနိုင်ရန် ကူညီပေးသည့် နည်းလမ်းဖြင့် အမှားရှာပြင်နေစဉ်အတွင်း စနစ် topology ကို မည်ကဲ့သို့ စိတ်ကူးပုံဖော်ရမည်ကို စဉ်းစားရန် လိုအပ်သည်။

ကျွန်ုပ်တို့သည် ကောင်းမွန်သော abstraction နှင့် layering စွမ်းရည်များ (အထူးသဖြင့် UI တွင်) လိုအပ်ပါသည်။ မေးခွန်းများကို ထပ်ခါတလဲလဲ မေးနိုင်ပြီး သီအိုရီများကို စမ်းသပ်နိုင်သည့် သီအိုရီကို မောင်းနှင်သည့် အမှားရှာခြင်း လုပ်ငန်းစဉ်တွင် ကောင်းစွာ အံဝင်ခွင်ကျဖြစ်စေမည့် အရာများ။ ၎င်းတို့သည် မြင်နိုင်စွမ်းရှိမှုပြဿနာအားလုံးကို အလိုအလျောက်ဖြေရှင်းပေးမည်မဟုတ်သော်လည်း သုံးစွဲသူများက ၎င်းတို့၏ ပင်ကိုယ်ဥာဏ်ကို ထက်မြက်စေပြီး ပိုမိုထက်မြက်သောမေးခွန်းများကို ပုံဖော်ပေးမည်ဖြစ်သည်။ စိတ်ကူးပုံဖော်ခြင်းအတွက် ပိုမိုစဉ်းစားတွေးခေါ်ပြီး ဆန်းသစ်သောချဉ်းကပ်မှုတစ်ခုကို တောင်းဆိုပါသည်။ ဤနေရာ၌ မိုးကုပ်စက်ဝိုင်းများချဲ့ထွင်ရန် အမှန်တကယ်အလားအလာရှိပါသည်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Kubernetes pods များတွင် အမှားရှာပြင်ခြင်းအတွက် kubectl-debug ပလပ်အင်";
• «Microservices- သင့်တွင် Kubernetes ရှိလျှင်ပင် အရွယ်အစားသည် အရေးကြီးသည်။";
• «စောင့်ကြည့်ခြင်းနှင့် Kubernetes (ပြန်လည်သုံးသပ်ခြင်းနှင့် ဗီဒီယိုအစီရင်ခံစာ)"။

source: www.habr.com