Mahahalagang Link
Dashboard ng Kalusugan ng Serbisyo (kasalukuyang available lang sa mga customer ng Enterprise API)
Magsimula sa Tamang Mga Default
Kapag binuksan mo ang dashboard ng Kalusugan ng Serbisyo, ang mga default nito ay:
Lahat ng proyekto
Huling 30 araw
Orasang resolusyon
Kapaki-pakinabang lang ang view na ito para sa oryentasyon. Palaging nangangailangan ng pag-filter ang makabuluhang troubleshooting.
Mag-filter Bago Magsiyasat
Ang tamang pag-filter ang pinakamahalagang hakbang. Karamihan ng maling interpretasyon ay mula sa paghahalo ng mga modelo, tier, o proyekto.
Mag-filter ayon sa Modelo (Isa-isa)
Palaging mag-filter sa iisang modelo.
Bakit:
Maaaring maitago ng mas mataas na volume ng traffic ang mga isyu sa mga modelong mababa ang traffic
Maaaring magmukhang global ang mga localized na isyu dahil sa mga modelong mataas ang volume
May magkakaibang layunin sa performance ang iba’t ibang modelo
Tandaan: kapag pumili ng maraming modelo, pinagsasama-sama ang mga ito—hindi ito nagpapalipat-lipat sa kanila.
I-filter ayon sa Antas ng Serbisyo
Kung gumagamit ka ng higit sa isang antas (standard, Fast mode (dating Priority processing), Antas ng Scale), palaging i-filter ayon sa antas na sinisiyasat mo.
Bakit:
Magkakaiba ang mga katangian ng performance ng bawat antas
May mga itinakdang SLA ang Fast mode at Antas ng Scale
Natatakpan ng pagsasama-sama ng mga antas ang performance ng antas na may bayad
Mahalaga ito lalo na sa pagsusuri ng latency.
Para sa mga kasalukuyang modelo, lumalabas pa rin bilang priority sa dashboard ng Usage ang trapiko ng Fast mode.
Mag-filter ayon sa Proyekto
Bilang default, ipinapakita ng Kalusugan ng Serbisyo ang lahat ng proyekto.
Para sa troubleshooting, mag-filter sa (mga) proyektong pinag-obserbahan ng isyu.
Bakit:
Maaaring mangibabaw sa mga metric ang isang proyektong mataas ang volume.
Maaaring matakpan ng walang-kaugnayang traffic ang mas maliliit na apektadong proyekto.
Iwanang nakapili lang ang "Lahat ng proyekto" kung naniniwala kang tunay na saklaw ng buong organisasyon ang isyu.
Pag-troubleshoot ng mga Error
Gamitin ang View ng mga HTTP Request
Para siyasatin ang mga error:
Mag-filter ayon sa modelo at antas ng serbisyo.
Buksan ang tab na Mga HTTP Request sa halip na tab na Uptime.
Ipinapakita ng view na ito ang kabuuang requests at bilang ng error ayon sa HTTP status code. Mag-zoom sa resolusyong pang-minuto para matukoy ang mga granular na spike o pagbabago.
Bigyang-kahulugan ang mga Rate ng Error, Hindi ang Bilang
Inaasahan ang ilang error sa anumang production system. Magpokus sa porsiyento ng error, hindi sa mga raw na kabuuan.
Habang mas malaki ang kabuuang volume mo, mas malaki rin ang potensyal na bilang ng error kahit napakababa ng rate ng error.
Kapag Nawawala ang mga Error sa Kalusugan ng Serbisyo
Kung nakakakita ka ng mga error sa client side pero walang katumbas na data sa Kalusugan ng Serbisyo:
Malamang na hindi nakarating ang mga request sa OpenAI.
Karaniwang upstream ang isyu (timeouts, proxies, networking).
Karaniwan ito sa agresibong client-side timeouts.
Pag-troubleshoot sa Latency
Pinakamakabuluhan ang pagsusuri ng latency sa Fast mode at Antas ng Scale, na may mga itinakdang SLA. Maaaring mas malaki ang pagkakaiba-iba ng latency sa standard na antas, at hindi ginagarantiyahan ang latency nito.
Mahahalagang Metric
Para tingnan ang bawat metric, i-click ang kaugnay na tab:
Bilis ng Token: Mga token na nagagawa bawat segundo; hindi nakadepende sa laki ng prompt.
Oras ng Request: Kabuuang tagal ng request; lubhang naaapektuhan ng laki ng output at pangangatwiran.
Oras hanggang Unang Token (TTFT): Oras bago mabuo ang unang token; lubhang naaapektuhan ng laki ng hindi naka-cache na input prompt at pangangatwiran.
Palaging suriin ang mga percentile na P50 / P75 / P95. Maaaring maitago ng mga average ang epekto sa totoong user.
6. Pag-uugnay ng Latency sa Paggamit ng Token
Ipinapakita ng Kalusugan ng Serbisyo kung kailan nagbago ang behavior. Nakakatulong ang data ng Paggamit na ipaliwanag kung bakit.
Sa dashboard ng Paggamit, gawin ang sumusunod para matiyak na tinitingnan mo ang data na may kaugnayan sa iyong view sa Dashboard ng Kalusugan ng Serbisyo:
Mag-filter sa parehong proyekto at modelo.
I-group ayon sa antas ng serbisyo, kung naaangkop.
Magpokus sa mga output token, na pinakamatinding nakakaapekto sa latency.
Para sa mas malalim na pagsusuri, i-export ang Activity Data at suriin ang mga token bawat request sa paglipas ng panahon.
7. Ano ang Ibabahagi sa Support (Kung Kailangan)
Kung makikipag-ugnayan ka sa support, isama ang:
Mga apektadong Org ID (mahalaga)
Mga apektadong endpoint, gaya ng Chat Completions o Responses (mahalaga)
Mga apektadong modelo (mahalaga)
Kung nangyayari ito sa Fast mode o Antas ng Scale (mahalaga)
Mga saklaw ng oras na may timezone para sa latency o mga error (mahalaga)
Nauugnay na x-request-id o X-Client-Request-Id, kung mayroon
Mga timestamp na may timezone, o kahit ang petsa man lang, para sa mga request na ibibigay mo
Kung mayroon, isama rin ang:
Project ID na nauugnay sa mga request
Kung aling mga request sa lokasyon ng data ang apektado
Mga paglalarawan ng mga trend na nakikita mo
Para sa uri ng isyu, isama ang:
Mga error: Tinatayang porsyento ng mga request na nabibigo o nagkaka-error, mga response code, mensahe ng error, at kung gaano katagal bago natanggap ang tugon ng error.
Latency: Aling mga percentile ang apektado (P50 / P90 / P95 / P99), gaano kataas ang mga ito kumpara sa baseline ng customer, at mga halimbawa ng mababagal na request na may mga timestamp ng pagpapadala at pagtanggap.
Pareho: Mga screenshot o talahanayan ng data ng error o latency, pati kung paano mo natukoy na mas mataas kaysa inaasahan ang mga rate ng error o latency.
Mga Karaniwang Scenario sa Troubleshooting
May mga Timeout pero Mukhang Normal ang Kalusugan ng Serbisyo
Posibleng sanhi: nagta-timeout ang mga request bago makarating sa OpenAI.
Suriin:
Mga setting ng timeout ng client o proxy
Mga pagbabago sa lokal na network o load balancer
Pagkakaroon ng 499 errors sa dashboard ng Kalusugan ng Serbisyo (maaaring lumabas ang mga ito bilang 5xx errors sa sarili mong mga system).
Tumaas ang Latency Nang Walang Deployment
Posibleng sanhi: tumaas ang laki ng output token o paggamit ng pangangatwiran at/o lumipat ang traffic sa pagitan ng mga antas ng serbisyo.
Suriin:
Average na output token bawat request sa dashboard ng Paggamit (kailangang i-download ang data at hatiin ang output tokens sa kabuuang requests).
Mga percentile ng Request Time at TTFT sa dashboard ng Kalusugan ng Serbisyo.
Mukhang Mabagal ang Fast mode o Antas ng Scale
Posibleng dahilan: pinagsama-sama ang mga sukatan mula sa iba't ibang antas, kaya natatakpan ng trapiko sa standard na antas ang performance ng antas na may bayad.
Suriin:
Nak限定 ang mga filter sa iisang antas at modelo.
Paghahambing ng bilis ng token sa pagitan ng mga antas.
Pagtaas ng mga 5XX Error
Malamang na sanhi: mga pansamantalang failure na nakakaapekto sa maliit na porsiyento ng traffic.
Suriin:
Porsiyento ng rate ng error
Kung nagbago ang dami ng traffic sa parehong oras
Isang Proyekto Lang ang Apektado ng Isyu
Malamang na sanhi: configuration o pattern ng paggamit na partikular sa proyekto.
Suriin:
Pag-filter sa antas ng proyekto
Paghahambing sa mga proyektong hindi apektado
Mga Panghuling Punto
Mag-filter ayon sa modelo, tier, at proyekto kung may kaugnayan bago bigyang-kahulugan ang mga metric.
Gumamit ng percentiles, hindi averages, para sa pagsusuri ng latency.
Inaasahan ang maliliit na rate ng error.
Karaniwang nagpapahiwatig ng upstream issues ang nawawalang data.
Makakatulong ang data ng Paggamit na ipaliwanag kung bakit nagbago ang latency; ipinapakita ng Kalusugan ng Serbisyo kung kailan nagbago ang behavior.