အရေးကြီးသောလင့်ခ်များ
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ် (လက်ရှိတွင် Enterprise API သုံးစွဲသူများအတွက်သာ ရနိုင်သည်)
မှန်ကန်သော မူရင်းဆက်တင်များဖြင့် စတင်ပါ
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ်ကို ဖွင့်သောအခါ ၎င်း၏ မူရင်းမှာ:
ပရောဂျက်အားလုံး
နောက်ဆုံး ၃၀ ရက်
နာရီအလိုက် resolution
ဤမြင်ကွင်းသည် လမ်းညွှန်အမြင်အတွက်သာ အသုံးဝင်သည်။ အဓိပ္ပာယ်ရှိသော ပြဿနာဖြေရှင်းမှုအတွက် စစ်ထုတ်ခြင်း အမြဲလိုအပ်သည်။
စုံစမ်းစစ်ဆေးမီ စစ်ထုတ်ပါ
မှန်ကန်စွာ စစ်ထုတ်ခြင်းသည် အရေးအကြီးဆုံးအဆင့်ဖြစ်သည်။ အနက်ဖွင့်မှားမှုအများစုသည် မော်ဒယ်များ၊ အဆင့်များ သို့မဟုတ် ပရောဂျက်များကို ရောနှောခြင်းမှ ဖြစ်ပေါ်သည်။
မော်ဒယ်အလိုက် စစ်ထုတ်ပါ (တစ်ကြိမ်လျှင် တစ်ခု)
မော်ဒယ်တစ်ခုထဲသို့ အမြဲ စစ်ထုတ်ပါ။
အကြောင်းရင်း:
ယာဉ်အသွားအလာနည်းသော မော်ဒယ်များရှိ ပြဿနာများကို ပမာဏပိုများသော ယာဉ်အသွားအလာက ဖုံးကွယ်နိုင်သည်
ပမာဏများသော မော်ဒယ်များသည် ဒေသတွင်းပြဿနာများကို အဖွဲ့အစည်းတစ်ခုလုံးဆိုင်ရာ ပြဿနာများပုံစံ ဖြစ်စေနိုင်သည်
မော်ဒယ်အသီးသီးတွင် စွမ်းဆောင်ရည် ရည်မှန်းချက်များ ကွဲပြားသည်
မှတ်ချက်: မော်ဒယ်များစွာကို ရွေးချယ်ခြင်းသည် ၎င်းတို့ကို စုစည်းပေးခြင်းသာဖြစ်ပြီး ၎င်းတို့အကြား ပြောင်းလဲပေးခြင်း မဟုတ်ပါ။
ဝန်ဆောင်မှုအဆင့်အလိုက် စစ်ထုတ်ပါ
အဆင့်တစ်ခုထက်ပို၍ အသုံးပြုပါက (standard၊ priority၊ scale) သင်စုံစမ်းနေသော အဆင့်သို့ အမြဲ စစ်ထုတ်ပါ။
အကြောင်းရင်း:
အဆင့်များတွင် စွမ်းဆောင်ရည် လက္ခဏာများ ကွဲပြားသည်
Priority နှင့် scale အဆင့်များတွင် သတ်မှတ်ထားသော SLA များ ရှိသည်
အဆင့်များကို ရောနှောခြင်းက ပေးချေထားသောအဆင့်၏ စွမ်းဆောင်ရည်ကို မရှင်းလင်းစေသည်
ဤသည်မှာ latency ခွဲခြမ်းစိတ်ဖြာမှုအတွက် အထူးအရေးကြီးသည်။
ပရောဂျက်အလိုက် စစ်ထုတ်ပါ
မူရင်းအနေဖြင့် 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 များတွင် အဖြစ်များသည်။
Latency ပြဿနာဖြေရှင်းခြင်း
Latency ခွဲခြမ်းစိတ်ဖြာမှုသည် SLA များ သတ်မှတ်ထားသော priority နှင့် scale အဆင့်များတွင် အဓိပ္ပာယ်အရှိဆုံးဖြစ်သည်။ စံအဆင့်တွင် latency ပြောင်းလဲမှု ပိုကျယ်ပြန့်စွာ ပြနိုင်ပြီး latency အာမခံချက် မရှိပါ။
အဓိက မက်ထရစ်များ
မက်ထရစ်တစ်ခုစီကို ကြည့်ရန် သက်ဆိုင်ရာ တက်ဘ်ကို နှိပ်ပါ:
တိုကင်အလျင်: တစ်စက္ကန့်လျှင် ထုတ်ပေးသော တိုကင်များ; တုံ့ပြန်ညွှန်ကြားချက် အရွယ်အစားနှင့် မသက်ဆိုင်ပါ။
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 လုပ်ပြီး အချိန်အလိုက် တောင်းဆိုမှုတစ်ခုလျှင် တိုကင်များကို စစ်ဆေးပါ။
၇။ Support နှင့် မျှဝေရမည့်အရာများ (လိုအပ်ပါက)
Support ကို ဆက်သွယ်ပါက အောက်ပါတို့ကို ထည့်သွင်းပါ:
သက်ရောက်ခံရသော Org IDs (အရေးကြီး)
Chat Completions သို့မဟုတ် Responses ကဲ့သို့သော သက်ရောက်ခံရသော အဆုံးမှတ်များ (အရေးကြီး)
သက်ရောက်ခံရသော မော်ဒယ်များ (အရေးကြီး)
ဤသည်မှာ Scale သို့မဟုတ် Priority အဆင့်တွင် ဖြစ်/မဖြစ် (အရေးကြီး)
Latency သို့မဟုတ် အမှားများအတွက် အချိန်ဇုန်ပါဝင်သော အချိန်အပိုင်းအခြားများ (အရေးကြီး)
ရနိုင်ပါက သက်ဆိုင်ရာ x-request-id သို့မဟုတ် X-Client-Request-Id
သင်ပေးပို့သည့် တောင်းဆိုမှုများအတွက် အချိန်ဇုန်ပါဝင်သော timestamp များ၊ သို့မဟုတ် အနည်းဆုံး ရက်စွဲ
ရနိုင်ပါက ထပ်မံထည့်သွင်းရန်:
တောင်းဆိုမှုများနှင့် သက်ဆိုင်သော Project ID
ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာ တောင်းဆိုမှုများ သက်ရောက်ခံရခြင်း ရှိ/မရှိနှင့် မည်သည့်တောင်းဆိုမှုများ ဖြစ်သည်ကို
သင်မြင်နေရသော လမ်းကြောင်းပြောင်းလဲမှုများ၏ ဖော်ပြချက်များ
ပြဿနာအမျိုးအစားအတွက် ထည့်သွင်းရန်:
အမှားများ: မအောင်မြင်သော သို့မဟုတ် အမှားဖြစ်သော တောင်းဆိုမှုများ၏ ခန့်မှန်း ရာခိုင်နှုန်း၊ response code များ၊ error message များနှင့် error response ရရှိရန် ကြာချိန်။
Latency: သက်ရောက်ခံရသော ရာခိုင်နှုန်းတန်ဖိုးများ (P50 / P90 / P95 / P99)၊ ၎င်းတို့သည် customer ၏ baseline နှင့် နှိုင်းယှဉ်လျှင် မည်မျှမြင့်သည်၊ နှင့် ပေးပို့ချိန်/လက်ခံချိန် timestamp များပါသော နှေးကွေးသော တောင်းဆိုမှု ဥပမာများ။
နှစ်မျိုးလုံး: အမှား သို့မဟုတ် latency ဒေတာ၏ screenshot များ သို့မဟုတ် ဇယားတစ်ခု၊ ထို့အပြင် အမှားနှုန်းများ သို့မဟုတ် latency သည် မျှော်လင့်ထားသည်ထက် မြင့်နေကြောင်း သင်မည်သို့ သတ်မှတ်ခဲ့သည်။
အဖြစ်များသော ပြဿနာဖြေရှင်းမှု အခြေအနေများ
Timeouts ဖြစ်သော်လည်း Service Health သည် ပုံမှန်ပုံရခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း: တောင်းဆိုမှုများသည် OpenAI သို့ မရောက်မီ timeout ဖြစ်နေသည်။
စစ်ဆေးရန်:
Client သို့မဟုတ် proxy timeout ဆက်တင်များ
ဒေသတွင်း ကွန်ရက် သို့မဟုတ် load balancer ပြောင်းလဲမှုများ
Service Health dashboard တွင် 499 အမှားများ ရှိခြင်း (သင့်ကိုယ်ပိုင်စနစ်များတွင် ၎င်းတို့သည် 5xx အမှားများအဖြစ် ပေါ်လာနိုင်သည်)။
ဖြန့်ချိမှုမရှိဘဲ Latency မြင့်တက်ခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း: output တိုကင်အရွယ်အစား သို့မဟုတ် ကျိုးကြောင်းသင့်လျော်စွာ စဉ်းစားပေးသော အသုံးပြုမှု တိုးလာပြီး/သို့မဟုတ် ယာဉ်အသွားအလာသည် ဝန်ဆောင်မှုအဆင့်များအကြား ရွှေ့ပြောင်းသွားသည်။
စစ်ဆေးရန်:
အသုံးပြုမှု ဒက်ရှ်ဘုတ်ရှိ တောင်းဆိုမှုတစ်ခုလျှင် ပျမ်းမျှ output တိုကင်များ (ဒေတာကို ဒေါင်းလုဒ်လုပ်ပြီး output တိုကင်များကို စုစုပေါင်း တောင်းဆိုမှုများဖြင့် စားရန် လိုအပ်သည်)။
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ်ရှိ Request Time နှင့် TTFT ရာခိုင်နှုန်းတန်ဖိုးများ။
Priority သို့မဟုတ် Scale အဆင့် နှေးကွေးနေပုံရခြင်း
ဖြစ်နိုင်သော အကြောင်းရင်း: မက်ထရစ်များကို အဆင့်များအကြား ရောနှောထားသဖြင့် စံအဆင့် ယာဉ်အသွားအလာက ပေးချေထားသောအဆင့်၏ စွမ်းဆောင်ရည်ကို ဖုံးကွယ်နေသည်။
စစ်ဆေးရန်:
စစ်ထုတ်မှုများကို အဆင့်တစ်ခုနှင့် မော်ဒယ်တစ်ခုထဲသာ ကန့်သတ်ထားသည်။
အဆင့်များအကြား တိုကင်အလျင် နှိုင်းယှဉ်မှု။
5XX အမှားများ ရုတ်တရက်မြင့်တက်ခြင်း
ဖြစ်နိုင်ခြေရှိသော အကြောင်းရင်း: ယာဉ်အသွားအလာ အနည်းငယ်ကို သက်ရောက်သော ယာယီချို့ယွင်းမှုများ။
စစ်ဆေးရန်:
အမှားနှုန်း ရာခိုင်နှုန်း
တစ်ချိန်တည်းတွင် ယာဉ်အသွားအလာ ပမာဏ ပြောင်းလဲခဲ့ခြင်း ရှိ/မရှိ
ပြဿနာသည် ပရောဂျက်တစ်ခုတည်းကိုသာ သက်ရောက်ခြင်း
ဖြစ်နိုင်ခြေရှိသော အကြောင်းရင်း: ပရောဂျက်အလိုက် ဖွဲ့စည်းမှု သို့မဟုတ် အသုံးပြုမှုပုံစံ။
စစ်ဆေးရန်:
ပရောဂျက်အဆင့် စစ်ထုတ်ခြင်း
မသက်ရောက်သော ပရောဂျက်များနှင့် နှိုင်းယှဉ်ခြင်း
နောက်ဆုံး မှတ်သားစရာများ
မက်ထရစ်များကို အနက်မဖွင့်မီ သက်ဆိုင်သည့်နေရာတွင် မော်ဒယ်၊ အဆင့်နှင့် ပရောဂျက်အလိုက် စစ်ထုတ်ပါ။
Latency ခွဲခြမ်းစိတ်ဖြာမှုအတွက် ပျမ်းမျှတန်ဖိုးများမဟုတ်ဘဲ ရာခိုင်နှုန်းတန်ဖိုးများကို အသုံးပြုပါ။
အမှားနှုန်းအနည်းငယ် ရှိခြင်းသည် မျှော်လင့်ထားသည့်အရာဖြစ်သည်။
ဒေတာပျောက်နေခြင်းသည် ပုံမှန်အားဖြင့် upstream ပြဿနာများကို ညွှန်ပြသည်။
အသုံးပြုမှုဒေတာသည် latency ဘာကြောင့် ပြောင်းလဲခဲ့သည်ကို ရှင်းပြရာတွင် ကူညီနိုင်သည်; ဝန်ဆောင်မှုကျန်းမာရေးက အပြုအမူ ဘယ်အချိန် ပြောင်းလဲခဲ့သည်ကို ပြသည်။