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.
Mag-filter ayon sa Antas ng Serbisyo
Kung gumagamit ka ng higit sa isang tier (standard, priority, scale), palaging mag-filter sa tier na sinisiyasat mo.
Bakit:
May magkakaibang katangian ng performance ang mga tier
May tinukoy na SLA ang mga tier na priority at scale
Natatakpan ng paghahalo ng mga tier ang performance ng paid tier
Lalo itong mahalaga para sa pagsusuri ng latency.
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 ng Latency
Pinakamakabuluhan ang pagsusuri ng latency sa mga tier na priority at scale, na may mga tinukoy na SLA. Maaaring magpakita ang standard tier ng mas malawak na pagbabago sa latency, at wala itong garantisadong latency.
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 nasa Antas ng Scale o Priority ito (mahalaga)
Mga hanay ng oras na may timezone para sa latency o mga error (mahalaga)
Kaugnay na x-request-id o X-Client-Request-Id, kung available
Mga timestamp na may timezone, o kahit ang petsa lang, para sa mga request na ibibigay mo
Kung available, isama rin ang:
Project ID na nauugnay sa mga request
Kung apektado ang mga request sa lokasyon ng data, at alin ang mga iyon
Mga paglalarawan ng mga trend na nakikita mo
Para sa uri ng isyu, isama ang:
Mga Error: Tinatayang porsiyento ng mga request na nagfa-fail o nagkaka-error, response codes, error messages, at kung gaano katagal bago matanggap ang error response.
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 send at receive timestamps.
Pareho: Mga screenshot o table ng data ng error o latency, kasama 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 Priority o Antas ng Scale
Posibleng sanhi: magkakahalo ang mga metric sa iba’t ibang tier, kaya natatakpan ng standard-tier traffic ang performance ng paid tier.
Suriin:
Limitado ang mga filter sa iisang tier at modelo.
Paghahambing ng bilis ng token sa pagitan ng mga tier.
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.