အရေးကြီးသောလင့်ခ်များ
ဝန်ဆောင်မှုကျန်းမာရေး ဒက်ရှ်ဘုတ် (လက်ရှိတွင် 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 ရာခိုင်နှုန်းတန်ဖိုးများကို အမြဲ ပြန်လည်သုံးသပ်ပါ။ ပျမ်းမျှတန်ဖိုးများသည် တကယ့်အသုံးပြုသူအပေါ် သက်ရောက်မှုကို ဖုံးကွယ်နိုင်သည်။
တုံ့ပြန်မှုကြာချိန်နှင့် တိုကင်အသုံးပြုမှု ဆက်နွှယ်ပုံကို လေ့လာခြင်း
ဝန်ဆောင်မှုအခြေအနေက လုပ်ဆောင်ပုံ ဘယ်အချိန်မှာ ပြောင်းလဲခဲ့သည်ကို ပြသသည်။ အသုံးပြုမှုဒေတာက ဘာကြောင့် ပြောင်းလဲခဲ့သည်ကို ရှင်းပြရာတွင် အထောက်အကူပြုသည်။
ဝန်ဆောင်မှုအခြေအနေ ဒက်ရှ်ဘုတ်တွင် သင်ကြည့်နေသည့်အရာနှင့် သက်ဆိုင်သောဒေတာကို ကြည့်ရှုနိုင်ရန် အသုံးပြုမှု ဒက်ရှ်ဘုတ်တွင် အောက်ပါတို့ကို လုပ်ဆောင်ပါ။
တူညီသော ပရောဂျက်နှင့် မော်ဒယ်ကိုသာ ပြသရန် စစ်ထုတ်ပါ။
သက်ဆိုင်ပါက ဝန်ဆောင်မှုအဆင့်အလိုက် အုပ်စုဖွဲ့ပါ။
တုံ့ပြန်မှုကြာချိန်အပေါ် အများဆုံး သက်ရောက်သည့် အထွက်တိုကင်များကို အဓိကထား ကြည့်ရှုပါ။
ပိုမိုအသေးစိတ် ဆန်းစစ်ရန် လုပ်ဆောင်ချက်ဒေတာကို ထုတ်ယူပြီး တောင်းဆိုချက်တစ်ခုစီအတွက် တိုကင်အရေအတွက် အချိန်နှင့်အမျှ ပြောင်းလဲပုံကို စစ်ဆေးပါ။
အကူအညီပေးရေးအဖွဲ့ထံ မျှဝေရမည့်အချက်များ (လိုအပ်ပါက)
အကူအညီပေးရေးအဖွဲ့ထံ ဆက်သွယ်လျှင် အောက်ပါတို့ကို ထည့်သွင်းပေးပါ။
ပြဿနာသက်ရောက်နေသော အဖွဲ့အစည်း ID များ (အရေးကြီး)
Chat Completions သို့မဟုတ် Responses ကဲ့သို့ ပြဿနာသက်ရောက်နေသော endpoint များ (အရေးကြီး)
ပြဿနာသက်ရောက်နေသော မော်ဒယ်များ (အရေးကြီး)
အမြန်မုဒ် သို့မဟုတ် Scale အဆင့်တွင် ဖြစ်ပွားနေခြင်း ရှိ၊ မရှိ (အရေးကြီး)
တုံ့ပြန်မှုကြာချိန် သို့မဟုတ် အမှားများနှင့်ပတ်သက်သည့် အချိန်အပိုင်းအခြားများနှင့် အချိန်ဇုန် (အရေးကြီး)
ရရှိနိုင်ပါက သက်ဆိုင်ရာ x-request-id သို့မဟုတ် X-Client-Request-Id
သင်ပေးပို့သော တောင်းဆိုချက်များ၏ အချိန်မှတ်တမ်းများနှင့် အချိန်ဇုန်၊ သို့မဟုတ် အနည်းဆုံး ရက်စွဲ
ရရှိနိုင်ပါက အောက်ပါတို့ကိုလည်း ထည့်သွင်းပေးပါ။
တောင်းဆိုချက်များနှင့် သက်ဆိုင်သော ပရောဂျက် ID
ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာ သတ်မှတ်ထားသော တောင်းဆိုချက်များအပေါ် ပြဿနာသက်ရောက်မှု ရှိ၊ မရှိနှင့် မည်သည့်တောင်းဆိုချက်များအပေါ် သက်ရောက်နေသည်ဆိုသော အချက်အလက်
သင်တွေ့ရှိနေသည့် ပြောင်းလဲမှုလမ်းကြောင်းများအကြောင်း ဖော်ပြချက်
ပြဿနာအမျိုးအစားအလိုက် အောက်ပါတို့ကို ထည့်သွင်းပေးပါ။
အမှားများအတွက်- မအောင်မြင်သော သို့မဟုတ် အမှားဖြစ်ပွားသော တောင်းဆိုချက်များ၏ ခန့်မှန်းရာခိုင်နှုန်း၊ တုံ့ပြန်မှုကုဒ်များ၊ အမှားမက်ဆေ့ချ်များနှင့် အမှားတုံ့ပြန်ချက်ကို လက်ခံရရှိသည်အထိ ကြာမြင့်ချိန်။
တုံ့ပြန်မှုကြာချိန်အတွက်- မည်သည့် ရာခိုင်နှုန်းအဆင့်တန်ဖိုးများ (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 ဘာကြောင့် ပြောင်းလဲခဲ့သည်ကို ရှင်းပြရာတွင် ကူညီနိုင်သည်; ဝန်ဆောင်မှုကျန်းမာရေးက အပြုအမူ ဘယ်အချိန် ပြောင်းလဲခဲ့သည်ကို ပြသည်။