အရေးကြီးသောလင့်ခ်များ
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ် (လက်ရှိတွင် Enterprise API သုံးစွဲသူများအတွက်သာ ရနိုင်သည်)
မှန်ကန်သော မူရင်းဆက်တင်များဖြင့် စတင်ပါ
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ်ကို ဖွင့်သောအခါ ၎င်း၏ မူရင်းမှာ:
ပရောဂျက်အားလုံး
နောက်ဆုံး ၃၀ ရက်
နာရီအလိုက် resolution
ဤမြင်ကွင်းသည် လမ်းညွှန်အမြင်အတွက်သာ အသုံးဝင်သည်။ အဓိပ္ပာယ်ရှိသော ပြဿနာဖြေရှင်းမှုအတွက် စစ်ထုတ်ခြင်း အမြဲလိုအပ်သည်။
စုံစမ်းစစ်ဆေးမီ စစ်ထုတ်ပါ
မှန်ကန်စွာ စစ်ထုတ်ခြင်းသည် အရေးအကြီးဆုံးအဆင့်ဖြစ်သည်။ အနက်ဖွင့်မှားမှုအများစုသည် မော်ဒယ်များ၊ အဆင့်များ သို့မဟုတ် ပရောဂျက်များကို ရောနှောခြင်းမှ ဖြစ်ပေါ်သည်။
မော်ဒယ်အလိုက် စစ်ထုတ်ပါ (တစ်ကြိမ်လျှင် တစ်ခု)
မော်ဒယ်တစ်ခုထဲသို့ အမြဲ စစ်ထုတ်ပါ။
အကြောင်းရင်း:
ယာဉ်အသွားအလာနည်းသော မော်ဒယ်များရှိ ပြဿနာများကို ပမာဏပိုများသော ယာဉ်အသွားအလာက ဖုံးကွယ်နိုင်သည်
ပမာဏများသော မော်ဒယ်များသည် ဒေသတွင်းပြဿနာများကို အဖွဲ့အစည်းတစ်ခုလုံးဆိုင်ရာ ပြဿနာများပုံစံ ဖြစ်စေနိုင်သည်
မော်ဒယ်အသီးသီးတွင် စွမ်းဆောင်ရည် ရည်မှန်းချက်များ ကွဲပြားသည်
မှတ်ချက်: မော်ဒယ်များစွာကို ရွေးချယ်ခြင်းသည် ၎င်းတို့ကို စုစည်းပေးခြင်းသာဖြစ်ပြီး ၎င်းတို့အကြား ပြောင်းလဲပေးခြင်း မဟုတ်ပါ။
ဝန်ဆောင်မှုအဆင့်အလိုက် စစ်ထုတ်ခြင်း
အဆင့်တစ်ခုထက်ပို၍ အသုံးပြုပါက (စံအဆင့်၊ အမြန်မုဒ် (ယခင် Priority processing)၊ Scale အဆင့်) စုံစမ်းနေသည့်အဆင့်ကိုသာ အမြဲစစ်ထုတ်ပါ။
အကြောင်းရင်း-
အဆင့်တစ်ခုစီ၏ စွမ်းဆောင်ရည် လက္ခဏာများ မတူညီပါ
အမြန်မုဒ်နှင့် Scale အဆင့်တွင် SLA များ သတ်မှတ်ထားပါသည်
အဆင့်များ ရောနှောထားခြင်းက အခပေးအဆင့်၏ စွမ်းဆောင်ရည်ကို ဖုံးကွယ်စေသည်
တုံ့ပြန်ချိန်ကြာမြင့်မှုကို ခွဲခြမ်းစိတ်ဖြာရာတွင် ၎င်းသည် အထူးအရေးကြီးသည်။
လက်ရှိ မော်ဒယ်များအတွက် အမြန်မုဒ် အသွားအလာကို Usage ဒက်ရှ်ဘုတ်တွင် priority အဖြစ် ဆက်လက်ဖော်ပြထားသည်။
ပရောဂျက်အလိုက် စစ်ထုတ်ပါ
မူရင်းအနေဖြင့် Service Health သည် ပရောဂျက်အားလုံးကို ပြသည်။
ပြဿနာဖြေရှင်းရန် ပြဿနာကို တွေ့ရှိခဲ့သော ပရောဂျက်(များ)သို့ စစ်ထုတ်ပါ။
အကြောင်းရင်း:
ပမာဏများသော ပရောဂျက်တစ်ခုသည် မက်ထရစ်များကို လွှမ်းမိုးနိုင်သည်။
သက်ရောက်မှုရှိသော ပိုသေးငယ်သော ပရောဂျက်များကို မသက်ဆိုင်သော ယာဉ်အသွားအလာက ဖုံးကွယ်နိုင်သည်။
ပြဿနာသည် အမှန်တကယ် အဖွဲ့အစည်းတစ်ခုလုံးကို သက်ရောက်သည်ဟု ယုံကြည်မှသာ “ပရောဂျက်အားလုံး” ကို ရွေးချယ်ထားပါ။
အမှားများကို ပြဿနာဖြေရှင်းခြင်း
HTTP Requests မြင်ကွင်းကို အသုံးပြုပါ
အမှားများကို စုံစမ်းရန်:
မော်ဒယ်နှင့် ဝန်ဆောင်မှုအဆင့်အလိုက် စစ်ထုတ်ပါ။
Uptime တက်ဘ်အစား HTTP Requests တက်ဘ်ကို ဖွင့်ပါ။
ဤမြင်ကွင်းသည် စုစုပေါင်း တောင်းဆိုမှုများနှင့် HTTP status code အလိုက် အမှားအရေအတွက်များကို ပြသည်။ အသေးစိတ် spike များ သို့မဟုတ် ပြောင်းလဲမှုများကို ဖော်ထုတ်ရန် မိနစ်အဆင့် resolution သို့ ချဲ့ကြည့်ပါ။
အရေအတွက်မဟုတ်ဘဲ အမှားနှုန်းများကို အနက်ဖွင့်ပါ
ထုတ်လုပ်မှုစနစ်တိုင်းတွင် အချို့အမှားများ ဖြစ်နိုင်သည်ဟု မျှော်လင့်ရသည်။ အကြမ်းဖျင်း စုစုပေါင်းအရေအတွက်မဟုတ်ဘဲ အမှား ရာခိုင်နှုန်းကို အာရုံစိုက်ပါ။
သင့်စုစုပေါင်းပမာဏ ပိုကြီးလေလေ၊ အမှားနှုန်း အလွန်နည်းနေရင်တောင် ဖြစ်နိုင်သော အမှားအရေအတွက် ပိုများလေလေ ဖြစ်သည်။
Service Health တွင် အမှားများ မတွေ့ရသည့်အခါ
client-side အမှားများကို မြင်ရသော်လည်း Service Health တွင် သက်ဆိုင်ရာ ဒေတာ မရှိပါက:
တောင်းဆိုမှုများသည် OpenAI သို့ မရောက်ရှိနိုင်ခဲ့ခြင်း ဖြစ်နိုင်သည်။
ပြဿနာသည် ပုံမှန်အားဖြင့် upstream တွင် ဖြစ်သည် (timeouts၊ proxies၊ networking)။
ဤသည်မှာ တင်းကျပ်သော client-side timeout များတွင် အဖြစ်များသည်။
တုံ့ပြန်ချိန်ကြာမြင့်မှု ပြဿနာဖြေရှင်းခြင်း
တုံ့ပြန်ချိန်ကြာမြင့်မှုကို ခွဲခြမ်းစိတ်ဖြာခြင်းသည် SLA သတ်မှတ်ထားသော အမြန်မုဒ်နှင့် Scale အဆင့်တို့တွင် အဓိပ္ပာယ်အရှိဆုံး ဖြစ်သည်။ စံအဆင့်တွင် တုံ့ပြန်ချိန် ပိုမိုကွာခြားနိုင်ပြီး တုံ့ပြန်ချိန်အတွက် အာမခံချက် မရှိပါ။
အဓိက မက်ထရစ်များ
မက်ထရစ်တစ်ခုစီကို ကြည့်ရန် သက်ဆိုင်ရာ တက်ဘ်ကို နှိပ်ပါ:
တိုကင်အလျင်: တစ်စက္ကန့်လျှင် ထုတ်ပေးသော တိုကင်များ; တုံ့ပြန်ညွှန်ကြားချက် အရွယ်အစားနှင့် မသက်ဆိုင်ပါ။
Request Time: စုစုပေါင်း တောင်းဆိုမှုကြာချိန်; output အရွယ်အစားနှင့် ကျိုးကြောင်းသင့်လျော်စွာ စဉ်းစားပေးသော အရာတို့ကြောင့် အလွန်သက်ရောက်မှုရှိသည်။
Time to First Token (TTFT): ပထမဆုံး တိုကင် ထုတ်ပေးသည်အထိ ကြာချိန်; cache မလုပ်ထားသော input တုံ့ပြန်ညွှန်ကြားချက် အရွယ်အစားနှင့် ကျိုးကြောင်းသင့်လျော်စွာ စဉ်းစားပေးသော အရာတို့ကြောင့် အလွန်သက်ရောက်မှုရှိသည်။
P50 / P75 / P95 ရာခိုင်နှုန်းတန်ဖိုးများကို အမြဲ ပြန်လည်သုံးသပ်ပါ။ ပျမ်းမျှတန်ဖိုးများသည် တကယ့်အသုံးပြုသူအပေါ် သက်ရောက်မှုကို ဖုံးကွယ်နိုင်သည်။
၆။ Latency ကို တိုကင်အသုံးပြုမှုနှင့် ဆက်စပ်ကြည့်ခြင်း
Service Health သည် အပြုအမူ ဘယ်အချိန် ပြောင်းလဲခဲ့သည်ကို ပြသည်။ အသုံးပြုမှုဒေတာသည် ဘာကြောင့် ဖြစ်သည်ကို ရှင်းပြရာတွင် ကူညီသည်။
Service Health Dashboard ရှိ သင့်မြင်ကွင်းနှင့် သက်ဆိုင်သော ဒေတာကို ကြည့်နေကြောင်း သေချာစေရန် Usage dashboard တွင် အောက်ပါတို့ကို လုပ်ဆောင်ပါ:
တူညီသော ပရောဂျက်နှင့် မော်ဒယ်သို့ စစ်ထုတ်ပါ။
သက်ဆိုင်ပါက ဝန်ဆောင်မှုအဆင့်အလိုက် အုပ်စုဖွဲ့ပါ။
Latency ကို အပြင်းထန်ဆုံး သက်ရောက်စေသော output တိုကင်များကို အာရုံစိုက်ပါ။
ပိုမိုနက်ရှိုင်းသော ခွဲခြမ်းစိတ်ဖြာမှုအတွက် Activity Data ကို export လုပ်ပြီး အချိန်အလိုက် တောင်းဆိုမှုတစ်ခုလျှင် တိုကင်များကို စစ်ဆေးပါ။
၇။ လိုအပ်ပါက ပံ့ပိုးကူညီရေးအဖွဲ့ထံ မျှဝေရမည့်အချက်များ
ပံ့ပိုးကူညီရေးအဖွဲ့ကို ဆက်သွယ်ပါက အောက်ပါတို့ကို ထည့်သွင်းပေးပါ-
ထိခိုက်နေသော Org ID များ (အရေးကြီးသည်)
Chat Completions သို့မဟုတ် Responses ကဲ့သို့ ထိခိုက်နေသော endpoint များ (အရေးကြီးသည်)
ထိခိုက်နေသော မော်ဒယ်များ (အရေးကြီးသည်)
အမြန်မုဒ် သို့မဟုတ် Scale အဆင့်တွင် ဖြစ်ပွားနေခြင်း ဟုတ်၊ မဟုတ် (အရေးကြီးသည်)
တုံ့ပြန်ချိန်ကြာမြင့်မှု သို့မဟုတ် အမှားများအတွက် အချိန်ဇုန်ပါသော အချိန်အပိုင်းအခြားများ (အရေးကြီးသည်)
ရရှိနိုင်ပါက သက်ဆိုင်ရာ x-request-id သို့မဟုတ် X-Client-Request-Id
ပေးပို့သည့် တောင်းဆိုချက်များအတွက် အချိန်ဇုန်ပါသော အချိန်မှတ်တမ်းများ သို့မဟုတ် အနည်းဆုံး ရက်စွဲ
ရရှိနိုင်ပါက အောက်ပါတို့ကိုလည်း ထည့်သွင်းပေးပါ-
တောင်းဆိုချက်များနှင့် သက်ဆိုင်သော Project ID
ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာဆိုင်ရာ တောင်းဆိုချက်များ ထိခိုက်မှု ရှိ၊ မရှိနှင့် မည်သည့်တောင်းဆိုချက်များ ထိခိုက်နေသည်ဆိုသည်
သင်တွေ့နေရသော အခြေအနေပြောင်းလဲမှုများ၏ ဖော်ပြချက်များ
ပြဿနာအမျိုးအစားအလိုက် အောက်ပါတို့ကို ထည့်သွင်းပေးပါ-
အမှားများ- မအောင်မြင်သော သို့မဟုတ် အမှားဖြစ်သော တောင်းဆိုချက်များ၏ ခန့်မှန်းရာခိုင်နှုန်း၊ တုံ့ပြန်မှုကုဒ်များ၊ အမှားမက်ဆေ့ချ်များနှင့် အမှားတုံ့ပြန်မှုကို ရရှိရန် ကြာချိန်။
တုံ့ပြန်ချိန်ကြာမြင့်မှု- ထိခိုက်နေသော percentile များ (P50 / P90 / P95 / P99)၊ သုံးစွဲသူ၏ ပုံမှန်အခြေအနေနှင့် နှိုင်းယှဉ်ပါက မည်မျှမြင့်မားနေသည်ဆိုသည်နှင့် ပေးပို့၊ လက်ခံ အချိန်မှတ်တမ်းများပါသော နှေးကွေးသည့် တောင်းဆိုချက် နမူနာများ။
နှစ်မျိုးလုံး- အမှား သို့မဟုတ် တုံ့ပြန်ချိန်ကြာမြင့်မှု ဒေတာ၏ ဖန်သားပြင်ဓာတ်ပုံများ သို့မဟုတ် ဇယားတစ်ခုအပြင် အမှားနှုန်း သို့မဟုတ် တုံ့ပြန်ချိန်သည် မျှော်မှန်းထားသည်ထက် ပိုမြင့်ကြောင်း သင်ဆုံးဖြတ်ခဲ့ပုံ။
အဖြစ်များသော ပြဿနာဖြေရှင်းမှု အခြေအနေများ
Timeouts ဖြစ်သော်လည်း Service Health သည် ပုံမှန်ပုံရခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း: တောင်းဆိုမှုများသည် OpenAI သို့ မရောက်မီ timeout ဖြစ်နေသည်။
စစ်ဆေးရန်:
Client သို့မဟုတ် proxy timeout ဆက်တင်များ
ဒေသတွင်း ကွန်ရက် သို့မဟုတ် load balancer ပြောင်းလဲမှုများ
Service Health dashboard တွင် 499 အမှားများ ရှိခြင်း (သင့်ကိုယ်ပိုင်စနစ်များတွင် ၎င်းတို့သည် 5xx အမှားများအဖြစ် ပေါ်လာနိုင်သည်)။
ဖြန့်ချိမှုမရှိဘဲ Latency မြင့်တက်ခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း: output တိုကင်အရွယ်အစား သို့မဟုတ် ကျိုးကြောင်းသင့်လျော်စွာ စဉ်းစားပေးသော အသုံးပြုမှု တိုးလာပြီး/သို့မဟုတ် ယာဉ်အသွားအလာသည် ဝန်ဆောင်မှုအဆင့်များအကြား ရွှေ့ပြောင်းသွားသည်။
စစ်ဆေးရန်:
အသုံးပြုမှု ဒက်ရှ်ဘုတ်ရှိ တောင်းဆိုမှုတစ်ခုလျှင် ပျမ်းမျှ output တိုကင်များ (ဒေတာကို ဒေါင်းလုဒ်လုပ်ပြီး output တိုကင်များကို စုစုပေါင်း တောင်းဆိုမှုများဖြင့် စားရန် လိုအပ်သည်)။
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ်ရှိ Request Time နှင့် TTFT ရာခိုင်နှုန်းတန်ဖိုးများ။
အမြန်မုဒ် သို့မဟုတ် Scale အဆင့် နှေးနေခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း- အဆင့်များ၏ တိုင်းတာချက်များ ရောနှောနေသဖြင့် စံအဆင့်အသွားအလာက အခပေးအဆင့်၏ စွမ်းဆောင်ရည်ကို ဖုံးကွယ်နေခြင်း ဖြစ်နိုင်သည်။
စစ်ဆေးရန်-
စစ်ထုတ်မှုများကို အဆင့်တစ်ခုနှင့် မော်ဒယ်တစ်ခုတည်းအတွက် ကန့်သတ်ထားခြင်း ရှိ၊ မရှိ။
အဆင့်များအကြား တိုကင် ထုတ်ပေးနှုန်း နှိုင်းယှဉ်ချက်။
5XX အမှားများ ရုတ်တရက်မြင့်တက်ခြင်း
ဖြစ်နိုင်ခြေရှိသော အကြောင်းရင်း: ယာဉ်အသွားအလာ အနည်းငယ်ကို သက်ရောက်သော ယာယီချို့ယွင်းမှုများ။
စစ်ဆေးရန်:
အမှားနှုန်း ရာခိုင်နှုန်း
တစ်ချိန်တည်းတွင် ယာဉ်အသွားအလာ ပမာဏ ပြောင်းလဲခဲ့ခြင်း ရှိ/မရှိ
ပြဿနာသည် ပရောဂျက်တစ်ခုတည်းကိုသာ သက်ရောက်ခြင်း
ဖြစ်နိုင်ခြေရှိသော အကြောင်းရင်း: ပရောဂျက်အလိုက် ဖွဲ့စည်းမှု သို့မဟုတ် အသုံးပြုမှုပုံစံ။
စစ်ဆေးရန်:
ပရောဂျက်အဆင့် စစ်ထုတ်ခြင်း
မသက်ရောက်သော ပရောဂျက်များနှင့် နှိုင်းယှဉ်ခြင်း
နောက်ဆုံး မှတ်သားစရာများ
မက်ထရစ်များကို အနက်မဖွင့်မီ သက်ဆိုင်သည့်နေရာတွင် မော်ဒယ်၊ အဆင့်နှင့် ပရောဂျက်အလိုက် စစ်ထုတ်ပါ။
Latency ခွဲခြမ်းစိတ်ဖြာမှုအတွက် ပျမ်းမျှတန်ဖိုးများမဟုတ်ဘဲ ရာခိုင်နှုန်းတန်ဖိုးများကို အသုံးပြုပါ။
အမှားနှုန်းအနည်းငယ် ရှိခြင်းသည် မျှော်လင့်ထားသည့်အရာဖြစ်သည်။
ဒေတာပျောက်နေခြင်းသည် ပုံမှန်အားဖြင့် upstream ပြဿနာများကို ညွှန်ပြသည်။
အသုံးပြုမှုဒေတာသည် latency ဘာကြောင့် ပြောင်းလဲခဲ့သည်ကို ရှင်းပြရာတွင် ကူညီနိုင်သည်; ဝန်ဆောင်မှုကျန်းမာရေးက အပြုအမူ ဘယ်အချိန် ပြောင်းလဲခဲ့သည်ကို ပြသည်။