Tautan Penting
*Dashboard Service Health saat ini hanya tersedia untuk pelanggan Enterprise API.
Mulai dengan Default yang Tepat
Saat Anda membuka dashboard Service Health, default-nya adalah:
Semua project
30 hari terakhir
Resolusi per jam
Tampilan ini hanya berguna untuk orientasi. Pemecahan masalah yang bermakna selalu memerlukan pemfilteran.
Filter Sebelum Menyelidiki
Pemfilteran yang benar adalah langkah terpenting. Sebagian besar salah tafsir berasal dari mencampurkan model, tier, atau project.
Filter berdasarkan Model (Satu per Satu)
Selalu filter ke satu model saja.
Mengapa:
Masalah pada model dengan traffic rendah dapat tertutupi oleh traffic dengan volume lebih tinggi
Model dengan volume tinggi dapat membuat masalah lokal terlihat global
Model yang berbeda memiliki target performa yang berbeda
Catatan: memilih beberapa model akan menggabungkannya—bukan beralih di antaranya.
Filter berdasarkan Service Tier
Jika Anda menggunakan lebih dari satu tier (standard, priority, scale), selalu filter ke tier yang sedang Anda selidiki.
Mengapa:
Tier memiliki karakteristik performa yang berbeda
Tier priority dan scale memiliki SLA yang ditetapkan
Mencampurkan tier mengaburkan performa tier berbayar
Ini sangat penting khususnya untuk analisis latensi.
Filter berdasarkan Project
Secara default, Service Health menampilkan semua project.
Untuk pemecahan masalah, filter ke project tempat masalah diamati.
Mengapa:
Satu project dengan volume tinggi dapat mendominasi metrik
Project terdampak yang lebih kecil dapat tertutupi oleh traffic yang tidak terkait
Biarkan "Semua project" tetap dipilih hanya jika Anda yakin masalahnya benar-benar terjadi di seluruh organisasi.
Pemecahan Masalah Error
Gunakan Tampilan HTTP Requests
Untuk menyelidiki error:
Filter berdasarkan model dan tier
Untuk beralih dari Uptime ke HTTP Requests, klik tab HTTP Requests
Tampilan ini menampilkan total request dan jumlah error berdasarkan kode status HTTP. Perbesar ke resolusi per menit untuk mengidentifikasi lonjakan atau perubahan yang lebih rinci.
Tafsirkan Tingkat Error, Bukan Jumlahnya
Beberapa error memang wajar terjadi di sistem produksi mana pun. Fokuslah pada persentase error, bukan total mentah.
Semakin besar total volume Anda, semakin besar pula potensi jumlah error bahkan dengan tingkat error yang sangat rendah.
Saat Error Tidak Muncul di Service Health
Jika Anda melihat error di sisi klien tetapi tidak ada data yang sesuai di Service Health:
Request kemungkinan tidak mencapai OpenAI
Masalahnya biasanya berada di upstream (timeout, proxy, jaringan)
Ini umum terjadi dengan timeout sisi klien yang agresif.
Pemecahan Masalah Latensi
Analisis latensi paling bermakna pada tier priority dan scale, yang memiliki SLA yang ditetapkan. Tier standard dapat menunjukkan variasi latensi yang lebih luas, dan tidak memiliki latensi yang dijamin.
Metrik Utama
Untuk melihat masing-masing metrik ini klik tab yang relevan:
Kecepatan Token
Token yang dihasilkan per detik.
Tidak bergantung pada ukuran prompt.
Waktu Request
Durasi total request.
Sangat dipengaruhi oleh ukuran output dan penalaran.
Time to First Token (TTFT)
Waktu hingga token pertama dihasilkan.
Sangat dipengaruhi oleh ukuran prompt input yang tidak di-cache dan penalaran.
Selalu tinjau persentil P50 / P75 / P95. Rata-rata dapat menyembunyikan dampak pada pengguna nyata.
6. Mengorelasikan Latensi dengan Penggunaan Token
Service Health menunjukkan kapan perilaku berubah. Data Usage membantu menjelaskan mengapa.
Di dashboard Usage, lakukan hal berikut untuk memastikan Anda melihat data yang relevan dengan tampilan Anda di Dashboard Service Health:
Filter ke project dan model yang sama
Kelompokkan berdasarkan service tier jika berlaku
Fokus pada token output, yang paling kuat memengaruhi latensi
Untuk analisis yang lebih mendalam, ekspor Data Aktivitas dan periksa token per request dari waktu ke waktu.
7. Apa yang Perlu Dibagikan ke Support (Jika Diperlukan)
Jika Anda menghubungi support, sertakan:
Org ID yang terdampak (ini penting)
Endpoint yang terdampak (Chat Completions, Responses, dll.) (ini penting)
Model yang terdampak (ini penting)
Apakah ini terjadi pada tier scale atau priority? (ini penting)
Rentang waktu dengan zona waktu untuk latensi atau error (ini penting)
x-request-id atau X-Client-Request-Id yang relevan (sering kali penting; sertakan jika memungkinkan)
Timestamp dengan zona waktu (atau setidaknya tanggal) dari request yang diberikan
Latensi - jika membagikan contoh request yang lambat, bagikan berapa lama waktu yang dibutuhkan di sisi Anda. Idealnya sertakan juga timestamp saat request dikirim dan saat diterima.
Error - harap bagikan perkiraan persentase request yang gagal/error, kode respons, pesan error, dan berapa lama waktu yang dibutuhkan untuk mendapatkan respons error
ID project yang terkait dengan request
Apakah ini memengaruhi request residensi data? Jika ya, yang mana?
Deskripsi tren yang Anda lihat
Error: Perkiraan % request yang gagal/error
Latensi: Persentil mana yang terdampak (p50 / p90 / p95 / p99), dan seberapa tinggi dibandingkan baseline pelanggan
Keduanya: Screenshot atau tabel data error atau latensi (Bagaimana Anda menentukan bahwa tingkat error atau latensi lebih tinggi dari yang diharapkan?)
Skenario Pemecahan Masalah Umum
Timeout Terjadi tetapi Service Health Terlihat Normal
Kemungkinan penyebab: request mengalami timeout sebelum mencapai OpenAI.
Periksa:
Pengaturan timeout klien atau proxy
Perubahan jaringan lokal atau load balancer
Keberadaan error 499 di dashboard Service Health (ini mungkin muncul sebagai error 5xx di sistem Anda sendiri).
Latensi Meningkat Tanpa Deployment
Kemungkinan penyebab: ukuran token output atau penggunaan penalaran meningkat dan\atau traffic bergeser antar service tier
Periksa:
Rata-rata token output per request di dashboard Usage (memerlukan pengunduhan data dan membagi token output dengan total request).
Persentil Request Time dan TTFT di dashboard Service Health.
Tier Priority atau Scale Terlihat Lambat
Kemungkinan penyebab: metrik tercampur antar tier (artinya traffic tier standard menutupi performa tier berbayar)
Periksa:
Filter dibatasi ke satu tier dan model
Perbandingan kecepatan token antar tier
Lonjakan Error 5XX
Kemungkinan penyebab: kegagalan sementara yang memengaruhi sebagian kecil traffic.
Periksa:
Persentase tingkat error
Apakah volume traffic berubah pada saat yang sama
Masalah Hanya Memengaruhi Satu Project
Kemungkinan penyebab: konfigurasi atau pola penggunaan spesifik project.
Periksa:
Pemfilteran tingkat project
Perbandingan dengan project yang tidak terdampak
Kesimpulan Akhir
Filter berdasarkan model, tier, dan jika relevan project sebelum menafsirkan metrik
Gunakan persentil, bukan rata-rata, untuk analisis latensi
Tingkat error kecil adalah hal yang wajar
Data yang hilang biasanya menunjukkan masalah upstream
Data Usage dapat membantu menjelaskan mengapa latensi berubah; Service Health membantu menunjukkan kapan