ယခု DevOps ၏ ခေါင်းစဉ်သည် ဖောင်းပွနေပါသည်။ စဉ်ဆက်မပြတ် ပေါင်းစပ်ခြင်းနှင့် ပေးပို့ခြင်း ပိုက်လိုင်း CI/CD လူတိုင်းက အဲဒါကို အကောင်အထည်ဖော်နေကြတယ်။ သို့သော် အများစုသည် CI/CD ပိုက်လိုင်း၏ အဆင့်အမျိုးမျိုးတွင် သတင်းအချက်အလက်စနစ်များ၏ ယုံကြည်စိတ်ချရမှုကို သေချာစေရန်အတွက် အမြဲဂရုမစိုက်ကြပါ။ ဤဆောင်းပါးတွင် ဆော့ဖ်ဝဲအရည်အသွေးစစ်ဆေးမှုများကို အလိုအလျောက်ပြုလုပ်ခြင်းနှင့် ၎င်း၏ "ကိုယ်တိုင်ကုသခြင်း" အတွက် ဖြစ်နိုင်ခြေရှိသော အခြေအနေများကို အကောင်အထည်ဖော်ရာတွင် ကျွန်ုပ်၏အတွေ့အကြုံအကြောင်း ပြောပြလိုပါသည်။

အရင်းအမြစ်

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

ဖောက်သည်များနှင့် စကားစမြည်ပြောဆိုမှု အများအပြား၏ ရလဒ်များအပေါ် အခြေခံ၍ ထုတ်ဝေမှု အရည်အသွေး ထိန်းချုပ်မှု၊ အက်ပ်လီကေးရှင်း၏ ယုံကြည်စိတ်ချရမှု ပြဿနာနှင့် ၎င်း၏ "မိမိကိုယ်ကို ကုသခြင်း" ၏ ဖြစ်နိုင်ခြေ (ဥပမာ၊ တည်ငြိမ်သောဗားရှင်းသို့ ပြန်လည်ရောက်ရှိခြင်း) CI ၏ အဆင့်အမျိုးမျိုးတွင်၊ /CD ပိုက်လိုင်းသည် စိတ်လှုပ်ရှားစရာအကောင်းဆုံးနှင့် သက်ဆိုင်ရာအကြောင်းအရာများထဲမှ တစ်ခုဖြစ်သည်။

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

"ပြဿနာဖွဲ့စည်းခြင်း"

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

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

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

လုပ်ငန်းတာဝန်ကို အစိတ်အပိုင်းနှစ်ခုအဖြစ် ပိုင်းခြားထားသည်။

• စမ်းသပ်သည့်အဆင့်တွင် စည်းဝေးပွဲများ၏ အရည်အသွေးထိန်းချုပ်မှု (အရည်အသွေးနိမ့်သော စည်းဝေးပွဲများကို ဖမ်းယူသည့် လုပ်ငန်းစဉ်ကို အလိုအလျောက်ဖြစ်စေရန်);
• ထုတ်လုပ်မှုပတ်ဝန်းကျင်ရှိ ဆော့ဖ်ဝဲအရည်အသွေးထိန်းချုပ်မှု (ပြဿနာများကို အလိုအလျောက်ထောက်လှမ်းခြင်းအတွက် ယန္တရားများနှင့် ၎င်းတို့ကိုယ်တိုင် ကုသရန်အတွက် ဖြစ်နိုင်ခြေရှိသော အခြေအနေများ)။

တိုင်းတာမှုများကို စောင့်ကြည့်ခြင်းနှင့် စုဆောင်းခြင်းအတွက် ကိရိယာ

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

မက်ထရစ်များကို စုဆောင်းရန်၊ သင်သည် မတူညီသော စနစ်များ (Prometheus၊ ELK Stack၊ Zabbix စသည်) ကို အသုံးပြု၍ ရနိုင်သော်လည်း၊ ကျွန်ုပ်၏ အမြင်အရ၊ APM အတန်းအစား ဖြေရှင်းချက်များသည် ဤအလုပ်များအတွက် အသင့်တော်ဆုံးဖြစ်သည် (လျှောက်လွှာစွမ်းဆောင်ရည်စောင့်ကြည့်လေ့လာရေး) သင့်ဘ၀ကို များစွာရိုးရှင်းစေနိုင်သည်။

ပံ့ပိုးရေးဝန်ဆောင်မှုတွင် ကျွန်ုပ်၏အလုပ်တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ Dynatrace မှ APM အတန်းဖြေရှင်းချက်ကို အသုံးပြု၍ အလားတူပရောဂျက်တစ်ခုကို စတင်လုပ်ဆောင်ခဲ့သည်။ ယခု၊ ပေါင်းစည်းမှုတစ်ခုအတွက် အလုပ်လုပ်ရင်း စောင့်ကြည့်ရေးစနစ်များ စျေးကွက်ကို ကောင်းစွာသိပါသည်။ ကျွန်ုပ်၏ပုဂ္ဂလဓိဋ္ဌာန်အမြင်- Dynatrace သည် ထိုကဲ့သို့သောပြဿနာများကိုဖြေရှင်းရန်အတွက် အကောင်းဆုံးဖြစ်သည်။
Dynatrace သည် အသုံးပြုသူလုပ်ဆောင်မှုတိုင်း၏ အလျားလိုက်မြင်ကွင်းကို ကုဒ်လုပ်ဆောင်မှုအဆင့်အထိ အသေးစိတ်အဆင့်တွင် ပံ့ပိုးပေးပါသည်။ ဝဘ်နှင့် မိုဘိုင်းအက်ပ်ပလီကေးရှင်းများ၏ ရှေ့ဆုံးအဆင့်များ၊ back-end အပလီကေးရှင်းဆာဗာများ၊ ဒေတာဘေ့စ်သို့ သီးခြားခေါ်ဆိုမှုတစ်ခုအထိ ပေါင်းစပ်ဘတ်စ်ကားများအထိ သင်ခြေရာခံနိုင်သည်။

အရင်းအမြစ်. စနစ်အစိတ်အပိုင်းများကြားတွင် မှီခိုမှုအားလုံးကို အလိုအလျောက်တည်ဆောက်ခြင်း။

အရင်းအမြစ်. အလိုအလျောက် ထောက်လှမ်းခြင်းနှင့် ဝန်ဆောင်မှု လည်ပတ်မှုလမ်းကြောင်းကို တည်ဆောက်ခြင်း။

ကျွန်ုပ်တို့သည် အမျိုးမျိုးသော automation tools များနှင့် ပေါင်းစည်းရန် လိုအပ်ကြောင်းကိုလည်း သတိရပါ။ ဤနေရာတွင် ဖြေရှင်းချက်တွင် အမျိုးမျိုးသော မက်ထရစ်များနှင့် ဖြစ်ရပ်များကို ပေးပို့လက်ခံရန် ခွင့်ပြုသည့် အဆင်ပြေသော API တစ်ခုရှိသည်။

ထို့နောက် Dynatrace စနစ်ကို အသုံးပြု၍ ဤပြဿနာများကို ဖြေရှင်းနည်းကို ပိုမိုအသေးစိတ်လေ့လာကြည့်ကြပါစို့။

လုပ်ငန်းတာဝန် 1. စမ်းသပ်အဆင့်တွင် စည်းဝေးပွဲများ၏ အရည်အသွေးထိန်းချုပ်မှုကို အလိုအလျောက်လုပ်ဆောင်ခြင်း။

ပထမစိန်ခေါ်မှုမှာ အပလီကေးရှင်းပေးပို့သည့်ပိုက်လိုင်းတွင် ပြဿနာများကို တတ်နိုင်သမျှ စောစီးစွာရှာဖွေရန်ဖြစ်သည်။ "ကောင်းသော" ကုဒ်တည်ဆောက်မှုများသာ ထုတ်လုပ်ရေးသို့ ရောက်ရှိသင့်သည်။ ထိုသို့လုပ်ဆောင်ရန်၊ စမ်းသပ်ဆဲအဆင့်တွင် သင့်ပိုက်လိုင်းသည် သင့်ဝန်ဆောင်မှုများ၏ အရည်အသွေးကို စစ်ဆေးရန် နောက်ထပ်မော်နီတာများ ပါဝင်သင့်သည်။

၎င်းကို အကောင်အထည်ဖော်ပုံနှင့် ဤလုပ်ငန်းစဉ်ကို အလိုအလျောက်လုပ်နည်းကို အဆင့်ဆင့်ကြည့်ရှုကြပါစို့။

အရင်းအမြစ်

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

1. စောင့်ကြည့်ရေးစနစ် (အေးဂျင့်များတပ်ဆင်ခြင်း)၊
2. သင့်ဆော့ဖ်ဝဲလ်၏ အရည်အသွေးကို အကဲဖြတ်ခြင်း (မက်ထရစ်များနှင့် အဆင့်သတ်မှတ်ချက်တန်ဖိုးများ) နှင့် ၎င်းတို့အား စောင့်ကြည့်ရေးစနစ်သို့ လွှဲပြောင်းခြင်းအတွက် ဖြစ်ရပ်များကို ဖော်ထုတ်ခြင်း၊
3. ဝန်နှင့်စွမ်းဆောင်ရည်စမ်းသပ်မှုများ၊
4. စောင့်ကြည့်ရေးစနစ်တွင် စွမ်းဆောင်ရည်နှင့် ရရှိနိုင်သော အချက်အလက်များကို စုဆောင်းခြင်း၊
5. စောင့်ကြည့်ရေးစနစ်မှ CI/CD စနစ်သို့ ဆော့ဖ်ဝဲအရည်အသွေး အကဲဖြတ်ခြင်းဖြစ်ရပ်များအပေါ် အခြေခံ၍ စမ်းသပ်ဒေတာကို လွှဲပြောင်းခြင်း။ စည်းဝေးများကို အလိုအလျောက် ခွဲခြမ်းစိတ်ဖြာခြင်း။

အဆင့် ၁။ စောင့်ကြည့်ရေးစနစ်ကို ဖြန့်ကျက်ခြင်း။

ပထမဦးစွာ သင်သည် သင်၏စမ်းသပ်ပတ်ဝန်းကျင်တွင် အေးဂျင့်များကို ထည့်သွင်းရန် လိုအပ်သည်။ တစ်ချိန်တည်းမှာပင်၊ Dynatrace ဖြေရှင်းချက်တွင် ကောင်းမွန်သောအင်္ဂါရပ်တစ်ခုပါရှိသည် - ၎င်းသည် OS စံနမူနာတစ်ခု (Windows၊ Linux၊ AIX) တွင် ထည့်သွင်းထားသည့် universal agent OneAgent ကို အသုံးပြု၍ သင့်ဝန်ဆောင်မှုများကို အလိုအလျောက်သိရှိနိုင်ပြီး ၎င်းတို့အပေါ် စောင့်ကြည့်စစ်ဆေးသည့်ဒေတာကို စတင်စုဆောင်းပါသည်။ လုပ်ငန်းစဉ်တစ်ခုစီအတွက် သီးခြားအေးဂျင့်ကို သင်သတ်မှတ်ရန် မလိုအပ်ပါ။ အခြေအနေသည် cloud နှင့် container platform များအတွက် အလားတူဖြစ်လိမ့်မည်။ တစ်ချိန်တည်းတွင်၊ သင်သည် အေးဂျင့်တပ်ဆင်ခြင်းလုပ်ငန်းစဉ်ကို အလိုအလျောက်လုပ်ဆောင်နိုင်သည်။ Dynatrace သည် "အခြေခံအဆောက်အဦများကဲ့သို့ကုဒ်" အယူအဆနှင့် လုံးဝကိုက်ညီသည် (ကုဒ် သို့မဟုတ် IaC အဖြစ် အခြေခံအဆောက်အဦ): နာမည်ကြီး ပလက်ဖောင်းအားလုံးအတွက် အဆင်သင့်လုပ်ထားသော script များနှင့် လမ်းညွှန်ချက်များ ရှိပါသည်။ သင်သည် သင်၏ဝန်ဆောင်မှု၏ဖွဲ့စည်းပုံပုံစံတွင် အေးဂျင့်ကို မြှုပ်နှံထားပြီး ၎င်းကိုအသုံးပြုသည့်အခါတွင် အလုပ်လုပ်ပြီးသားအေးဂျင့်နှင့်အတူ ဝန်ဆောင်မှုအသစ်တစ်ခု ချက်ချင်းရရှိမည်ဖြစ်သည်။

အဆင့် 2- သင့်ဆော့ဖ်ဝဲအရည်အသွေးဖြစ်ရပ်များကို သတ်မှတ်ပါ။

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

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

DevOps အဖွဲ့မှ အလိုအလျောက်စနစ်နှင့် အသုံးပြုရလွယ်ကူစေရန်အတွက် "Monitoring as Code" ၏ အယူအဆ ပေါ်လာပါသည်။ ကျွန်တော်ဆိုလိုတာက developer/tester က software quality assurance metrics တွေကို သတ်မှတ်ပေးတဲ့ ရိုးရှင်းတဲ့ JSON ဖိုင်ကို ရေးနိုင်တယ်ဆိုတာပါပဲ။

ထိုကဲ့သို့သော JSON ဖိုင်၏ ဥပမာကို ကြည့်ကြပါစို့။ Dynatrace API မှ အရာဝတ္ထုများကို သော့/တန်ဖိုးအတွဲများအဖြစ် အသုံးပြုသည် (API ဖော်ပြချက်ကို ဤနေရာတွင် တွေ့နိုင်သည် Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ဖိုင်သည် အချိန်စီးရီး အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ၏ array တစ်ခုဖြစ်သည်-

• timeseriesId – ဥပမာအားဖြင့်၊ တုံ့ပြန်မှုအချိန်၊ အမှားအယွင်းအရေအတွက်၊ အသုံးပြုထားသည့် Memory စသည်တို့ကို စစ်ဆေးထားသည့် မက်ထရစ်၊  
• ပေါင်းစည်းခြင်း - ကျွန်ုပ်တို့၏အခြေအနေတွင် avg မက်ထရစ်များ စုစည်းမှုအဆင့်၊ သို့သော် သင်လိုအပ်သောမည်သည့်အရာကိုမဆို (avg၊ min၊ max, sum, count, percentile);
• တဂ်များ – စောင့်ကြည့်ရေးစနစ်ရှိ အရာဝတ္ထုတဂ်၊ သို့မဟုတ် တိကျသော အရာဝတ္ထုသတ်မှတ်မှုတစ်ခုကို သင်သတ်မှတ်နိုင်သည်။
• ပြင်းထန်ပြီး သတိပေးချက် – ဤအညွှန်းများသည် ကျွန်ုပ်တို့၏ မက်ထရစ်များ၏ အတိုင်းအတာတန်ဖိုးများကို ထိန်းညှိပေးသည်၊ အကယ်၍ စမ်းသပ်မှုတန်ဖိုးသည် ပြင်းထန်သည့်အဆင့်ထက်ကျော်လွန်ပါက၊ ကျွန်ုပ်တို့၏တည်ဆောက်မှုသည် မအောင်မြင်ကြောင်း မှတ်သားထားသည်။

အောက်ပါပုံသည် ထိုသို့သော အတိုင်းအတာများကို အသုံးပြုခြင်း၏ ဥပမာကို ပြထားသည်။

အရင်းအမြစ်

အဆင့် 3- Load မျိုးဆက်

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှု၏ အရည်အသွေးအဆင့်များကို ဆုံးဖြတ်ပြီးသည်နှင့်၊ ကျွန်ုပ်တို့သည် စမ်းသပ်မှုတစ်ခုပြုလုပ်ရန် လိုအပ်ပါသည်။ Jmeter၊ Selenium၊ Neotys၊ Gatling အစရှိတဲ့ သင်နှစ်သက်တဲ့ စမ်းသပ်ကိရိယာတွေကို သုံးနိုင်ပါတယ်။

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

အောက်ဖော်ပြပါပုံသည် အပိုဆောင်းခေါင်းစီး X-Dynatrace-Test ကိုအသုံးပြု၍ ဤစမ်းသပ်မှုသည် လှည်းထဲသို့ ပစ္စည်းတစ်ခုထည့်ခြင်း၏လုပ်ဆောင်မှုကို စမ်းသပ်ခြင်းနှင့်သက်ဆိုင်ကြောင်း ကျွန်ုပ်တို့ညွှန်ပြသည့် ဥပမာတစ်ခုပြသည်။

အရင်းအမြစ်

သင် load test တစ်ခုစီကို လုပ်ဆောင်သောအခါ၊ သင်သည် CI/CD ဆာဗာမှ Event API ကို အသုံးပြု၍ Dynatrace သို့ ဆက်စပ်အချက်အလက်များ ထပ်မံပေးပို့ပါသည်။ ဤနည်းအားဖြင့်၊ စနစ်သည် မတူညီသော စမ်းသပ်မှုများအကြား ခွဲခြားနိုင်သည်။

အရင်းအမြစ်. ဝန်စမ်းသပ်ခြင်းစတင်ခြင်းအကြောင်း စောင့်ကြည့်ရေးစနစ်တွင် ဖြစ်ရပ်

အဆင့် ၄-၅။ စွမ်းဆောင်ရည်ဒေတာကို စုဆောင်းပြီး CI/CD စနစ်သို့ ဒေတာလွှဲပြောင်းပါ။

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

စောင့်ကြည့်ရေးစနစ်သို့ ပေးပို့ရန်အတွက် CI/CD ဆာဗာတွင် ထုတ်လုပ်ထားသော ဆော့ဖ်ဝဲများ၏ အရည်အသွေးကို စစ်ဆေးရန် လိုအပ်သည့် ဖြစ်ရပ်

ကျွန်ုပ်တို့၏ဥပမာတွင်၊ အရည်အသွေးစစ်ဆေးခြင်းဖြစ်ရပ်ဟုခေါ်သည်။ perfSigDynatrace အစီရင်ခံစာ (စွမ်းဆောင်ရည်_လက်မှတ်) - ဒါကအဆင်သင့်ပါပဲ။ ပလပ်ဂင် T-Systems Multimedia Solutions မှ အမျိုးသားများ ဖန်တီးထားသည့် Jenkins နှင့် ပေါင်းစည်းရန်အတွက်။ စမ်းသပ်မိတ်ဆက်ပွဲတစ်ခုစီတွင် ဝန်ဆောင်မှု၊ တည်ဆောက်မှုနံပါတ်နှင့် စမ်းသပ်ချိန်တို့အကြောင်း အချက်အလက်များ ပါရှိသည်။ ပလပ်အင်သည် တည်ဆောက်ချိန်အတွင်း စွမ်းဆောင်ရည်တန်ဖိုးများကို စုဆောင်းကာ ၎င်းတို့ကို အကဲဖြတ်ကာ ရလဒ်အား ယခင်တည်ဆောက်မှုများနှင့် လုပ်ဆောင်မှုမရှိသော လိုအပ်ချက်များနှင့် နှိုင်းယှဉ်ပါသည်။

တည်ဆောက်မှု အရည်အသွေး စစ်ဆေးခြင်း စတင်ခြင်းအကြောင်း စောင့်ကြည့်ရေးစနစ်တွင် ဖြစ်ရပ်။ အရင်းအမြစ်

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

CI/CD ဆာဗာရှိ စည်းဝေးပွဲများဆိုင်ရာ ကိန်းဂဏာန်းရလဒ်။ အရင်းအမြစ်

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

CI/CD ဆာဗာရှိ စည်းဝေးပွဲများဆိုင်ရာ အသေးစိတ်အချက်အလက်များကို ကြည့်ပါ။ အရင်းအမြစ်

စည်းဝေးပွဲနှစ်ခု၏ အသေးစိတ် နှိုင်းယှဉ်ချက်

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

Dynatrace ရှိ တည်ဆောက်ကိန်းဂဏန်းများကို နှိုင်းယှဉ်ခြင်း။ အရင်းအမြစ်
 
တွေ့ရှိချက်များ

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

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

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

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

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

ကုဒ်အဖြစ် အလိုအလျောက်ပြင်ပါ။

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

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

၎င်းကို သင်စဉ်းစားပါက၊ မိမိကိုယ်ကို ကုစားနိုင်သော အပလီကေးရှင်း စွမ်းဆောင်ရည်အတွက် လုပ်ငန်းစဉ်များ အကောင်အထည်ဖော်ရာတွင် လွန်စွာရှုပ်ထွေးမှု မရှိပါ။ သင်သည် သင့်စီမံခန့်ခွဲသူများ၏ သိပြီးသား အလုပ်အခြေအနေများကို ကုဒ်စခရစ်ပုံစံ (“ကုဒ်အဖြစ် အလိုအလျောက် ပြင်ဆင်ခြင်း” အယူအဆ) ကို တင်ပြရန် လိုအပ်ပါသည်။ သီးခြားကိစ္စတစ်ခုစီအတွက် သင်ကြိုတင်ရေးသားထားသည့်၊ အလိုအလျောက် ပြုပြင်သည့် Script များသည် ပြဿနာ၏ မူလဇစ်မြစ်ကို ဖယ်ရှားရန် ရည်ရွယ်သင့်သည်။ အဖြစ်အပျက်တစ်ခုကို တုံ့ပြန်ရန် မှန်ကန်သော လုပ်ဆောင်ချက်များကို သင်ကိုယ်တိုင် ဆုံးဖြတ်ပါ။

သင့်စောင့်ကြည့်ရေးစနစ်မှ မည်သည့်မက်ထရစ်သည်မဆို ဇာတ်ညွှန်းကိုဖွင့်ရန် အစပျိုးမှုတစ်ခုအဖြစ် လုပ်ဆောင်နိုင်သည်၊ အဓိကအချက်မှာ အကျိုးဖြစ်ထွန်းသောပတ်ဝန်းကျင်တွင် မှားယွင်းသောအပြုသဘောများမလိုချင်သောကြောင့် ဤမက်ထရစ်များသည် အရာအားလုံးမကောင်းကြောင်း တိကျစွာဆုံးဖြတ်ရန်ဖြစ်သည်။

မည်သည့်စနစ် သို့မဟုတ် စနစ်အစုံကိုမဆို သုံးနိုင်သည်- Prometheus၊ ELK Stack၊ Zabbix စသည်ဖြင့်။ သို့သော် APM ဖြေရှင်းချက်အပေါ် အခြေခံ၍ ဥပမာအချို့ကို ကျွန်ုပ်ပေးပါမည်။ (Dynatrace သည် သင့်ဘဝပိုမိုလွယ်ကူစေမည့် ဥပမာတစ်ခုဖြစ်သည်)။

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

• အသုံးပြုသူအဆင့် (ဘရောက်ဆာများ၊ မိုဘိုင်းအက်ပလီကေးရှင်းများ၊ IoT စက်ပစ္စည်းများ၊ အသုံးပြုသူအပြုအမူ၊ ပြောင်းလဲခြင်း စသည်)။
• ဝန်ဆောင်မှုနှင့် လုပ်ငန်းဆောင်ရွက်မှုအဆင့် (စွမ်းဆောင်ရည်၊ ရရှိနိုင်မှု၊ အမှားအယွင်းများ စသည်)၊
• အပလီကေးရှင်းအခြေခံအဆောက်အအုံအဆင့် (အိမ်ရှင် OS မက်ထရစ်များ၊ JMX၊ MQ၊ ဝဘ်ဆာဗာ၊ စသည်)။
• ပလက်ဖောင်းအဆင့် (virtualization၊ cloud၊ container စသည်ဖြင့်)။

Dynatrace ရှိ အဆင့်များကို စောင့်ကြည့်ခြင်း။ အရင်းအမြစ်

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

အောက်တွင် Ansible နှင့် ဆက်ဆံခြင်းအတွက် ဥပမာတစ်ခုဖြစ်သည်။

အရင်းအမြစ်

အောက်တွင် ကျွန်ုပ်သည် မည်သည့် automation အမျိုးအစားကို လုပ်ဆောင်နိုင်သည်ကို ဥပမာအနည်းငယ်ပေးပါမည်။ ၎င်းသည် အမှုကိစ္စများ၏ တစ်စိတ်တစ်ပိုင်းမျှသာဖြစ်သည်၊ သင့်ပတ်ဝန်းကျင်ရှိ ၎င်းတို့၏စာရင်းကို သင်၏စိတ်ကူးစိတ်သန်းနှင့် သင်၏စောင့်ကြည့်ရေးကိရိယာများ၏ စွမ်းရည်များဖြင့်သာ ကန့်သတ်ထားနိုင်သည်။

1. မကောင်းသော ဖြန့်ကျက်ခြင်း – ဗားရှင်း ပြန်လှည့်ခြင်း။

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

အောက်ပါပုံတွင် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကို အကောင်အထည်ဖော်သည့်အချိန်၌ သိသိသာသာ ခုန်တက်သွားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ ဤခုန်ခြင်း၏အစသည် လျှောက်လွှာသို့ ဖြန့်ကျက်ချိန်နှင့် တိုက်ဆိုင်နေသည်။ ကျွန်ုပ်တို့သည် ဤအချက်အလက်အားလုံးကို အလိုအလျောက်စနစ်သို့ ဖြစ်ရပ်များအဖြစ် ပေးပို့ပါသည်။ ကျွန်ုပ်တို့သတ်မှတ်ထားသောအချိန်ပြီးနောက် ဝန်ဆောင်မှု၏စွမ်းဆောင်ရည်သည် ပုံမှန်ပြန်မဖြစ်ပါက၊ ဗားရှင်းဟောင်းသို့ ပြန်ပြောင်းပေးသည့် script ကို အလိုအလျောက်ခေါ်ပါသည်။

ဖြန့်ကျက်ပြီးနောက် လုပ်ငန်းဆောင်ရွက်မှုစွမ်းဆောင်ရည် ကျဆင်းခြင်း။ အရင်းအမြစ်

2. အရင်းအမြစ်ကို 100% တွင်တင်ခြင်း - လမ်းကြောင်းတင်ခြင်းတွင် node တစ်ခုထည့်ပါ။

အောက်ပါဥပမာတွင်၊ စောင့်ကြည့်ရေးစနစ်သည် အစိတ်အပိုင်းများထဲမှတစ်ခုသည် 100% CPU load ကို တွေ့ကြုံနေရကြောင်း ဆုံးဖြတ်သည်။

CPU load 100%
 
ဤဖြစ်ရပ်အတွက် ဖြစ်နိုင်ချေ အမျိုးမျိုးသော အခြေအနေများ ရှိပါသည်။ ဥပမာအားဖြင့်၊ စောင့်ကြည့်ရေးစနစ်သည် ဝန်ဆောင်မှုတွင် ဝန်တိုးလာခြင်းနှင့် အရင်းအမြစ်များ ကင်းမဲ့ခြင်းရှိမရှိကိုလည်း စစ်ဆေးပါသည်။ သို့ဆိုလျှင်၊ လမ်းကြောင်းပေါ်တွင် node တစ်ခုကို အလိုအလျောက်ထည့်သွင်းပေးသည့် script တစ်ခုအား လုပ်ဆောင်ပြီး စနစ်တစ်ခုလုံး၏ လုပ်ဆောင်နိုင်စွမ်းကို ပြန်လည်ရရှိစေသည်။

အဖြစ်အပျက်တစ်ခုပြီးနောက် အတိုင်းအတာ

3. ဟာ့ဒ်ဒရိုက်တွင် နေရာလွတ်မရှိခြင်း - ဒစ်ခ်သန့်ရှင်းရေး

လူများစွာသည် ဤလုပ်ငန်းစဉ်များကို အလိုအလျောက်လုပ်ဆောင်နေပြီဟု ကျွန်ုပ်ထင်ပါသည်။ APM ကိုအသုံးပြုခြင်းဖြင့်၊ သင်သည် disk subsystem ရှိနေရာလွတ်ကိုလည်းစောင့်ကြည့်နိုင်သည်။ နေရာလွတ်မရှိခြင်း သို့မဟုတ် ဒစ်ခ်သည် နှေးကွေးစွာလည်ပတ်နေပါက၊ ၎င်းကို ရှင်းလင်းရန် သို့မဟုတ် နေရာထည့်ရန် script တစ်ခုကို ကျွန်ုပ်တို့ခေါ်ဆိုပါသည်။

Disc load 100%
 
4. အသုံးပြုသူ လုပ်ဆောင်ချက် နည်းပါးခြင်း သို့မဟုတ် ပြောင်းလဲခြင်း နည်းပါးခြင်း - အပြာနှင့် အစိမ်းရောင် အကိုင်းအခက်များကြား ပြောင်းခြင်း။

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

ဆော့ဖ်ဝဲလ်အကိုင်းအခက်များအကြား ပြောင်းပြီးနောက် ကူးပြောင်းမှုနှုန်း ကျဆင်းသွားသည်။ အရင်းအမြစ်

အလိုအလျောက် ပြဿနာရှာဖွေခြင်းအတွက် ယန္တရားများ

နောက်ဆုံးအနေနဲ့၊ ငါ Dynatrace ကို ဘာကြောင့် အများဆုံးကြိုက်သလဲဆိုတဲ့ နောက်ထပ် ဥပမာတစ်ခုကို ပြောပြမယ်။

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

Dynatrace တွင် စိတ်၀င်စားစရာကောင်းသော built-in ဉာဏ်ရည်တုကိရိယာများ ရှိပြီး၊ မမှန်မကန် မက်ထရစ်များ (baselining) ကို ဆုံးဖြတ်ခြင်းနှင့် အစိတ်အပိုင်းအားလုံးကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုမြေပုံကို တည်ဆောက်ခြင်း၊ တစ်ခုနှင့်တစ်ခု အဖြစ်အပျက်များကို နှိုင်းယှဉ်ခြင်းနှင့် ဆက်စပ်ခြင်း၊ သင့်ဝန်ဆောင်မှု၏ လုပ်ဆောင်မှုတွင် ကွဲလွဲချက်များကို ဆုံးဖြတ်ပြီး အသေးစိတ်ဖော်ပြခြင်းများအတွက် အခြေခံ၍ လုပ်ဆောင်သည့် စိတ်ဝင်စားစရာကောင်းသော built-in ဥာဏ်ရည်တုကိရိယာများ ပါရှိသည်။ ပြဿနာတစ်ခုစီနှင့် မူလအကြောင်းအရင်းဆိုင်ရာ အချက်အလက်

အစိတ်အပိုင်းများကြားတွင် မှီခိုမှုကို အလိုအလျောက် ပိုင်းခြားစိတ်ဖြာခြင်းဖြင့်၊ Dynatrace သည် ပြဿနာရှိသော ဝန်ဆောင်မှုသည် မူလဇစ်မြစ် ဟုတ်မဟုတ်သာမက အခြားဝန်ဆောင်မှုများအပေါ် ၎င်း၏ မှီခိုမှုကိုလည်း ဆုံးဖြတ်ပေးပါသည်။ အောက်ဖော်ပြပါ ဥပမာတွင်၊ Dynatrace သည် အရောင်းအ၀ယ်လုပ်ဆောင်မှုအတွင်း ဝန်ဆောင်မှုတစ်ခုစီ၏ ကျန်းမာရေးကို အလိုအလျောက် စောင့်ကြည့်စစ်ဆေးပြီး Golang ဝန်ဆောင်မှုကို မူလအကြောင်းအရင်းအဖြစ် ခွဲခြားသတ်မှတ်သည်။

ရှုံးနိမ့်မှု၏ မူလဇစ်မြစ်ကို ဆုံးဖြတ်ခြင်း၏ ဥပမာတစ်ခု။ အရင်းအမြစ်

အောက်ဖော်ပြပါပုံသည် အဖြစ်အပျက်တစ်ခု စတင်ချိန်မှစ၍ သင့်လျှောက်လွှာနှင့် ပြဿနာများကို စောင့်ကြည့်စစ်ဆေးသည့် လုပ်ငန်းစဉ်ကို ပြသထားသည်။

၎င်းတို့ပေါ်ရှိ အစိတ်အပိုင်းများနှင့် အဖြစ်အပျက်အားလုံးကို ပြသခြင်းဖြင့် ပေါ်ပေါက်လာသော ပြဿနာတစ်ရပ်ကို ပုံဖော်ခြင်း။

စောင့်ကြည့်ရေးစနစ်သည် ပေါ်ပေါက်လာသော ပြဿနာနှင့် ပတ်သက်သည့် အဖြစ်အပျက်များ၏ အပြည့်အစုံ အချိန်ဇယားကို စုဆောင်းထားသည်။ အချိန်ဇယားအောက်ရှိ ပြတင်းပေါက်တွင် အစိတ်အပိုင်းတစ်ခုစီရှိ အဓိကဖြစ်ရပ်များအားလုံးကို ကျွန်ုပ်တို့တွေ့မြင်ရသည်။ ဤဖြစ်ရပ်များအပေါ် အခြေခံ၍ သင်သည် ကုဒ်စခရစ်ပုံစံဖြင့် အလိုအလျောက် ပြင်ခြင်းအတွက် လုပ်ထုံးလုပ်နည်းများကို သတ်မှတ်နိုင်သည်။

ထို့အပြင်၊ စောင့်ကြည့်ရေးစနစ်အား Service Desk သို့မဟုတ် bug tracker နှင့် ပေါင်းစည်းရန် သင့်ကို အကြံပြုပါသည်။ ပြဿနာတစ်ခုဖြစ်ပွားသောအခါ၊ ထုတ်လုပ်သူများသည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်ရှိ ကုဒ်အဆင့်တွင် ခွဲခြမ်းစိတ်ဖြာရန် ပြည့်စုံသောအချက်အလက်ကို အမြန်ရရှိကြသည်။

ကောက်ချက်

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

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

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

အရင်းအမြစ်

source: www.habr.com