Önemli Bağlantılar
*Service Health Panosu şu anda yalnızca Enterprise API müşterileri için kullanılabilir.
Doğru Varsayılanlarla Başlayın
Service Health panosunu açtığınızda, varsayılan olarak şunlar seçilidir:
Tüm projeler
Son 30 gün
Saatlik çözünürlük
Bu görünüm yalnızca genel bir yönelim için faydalıdır. Anlamlı sorun giderme her zaman filtreleme gerektirir.
İncelemeye Başlamadan Önce Filtreleyin
Doğru filtreleme en önemli adımdır. Yanlış yorumların çoğu modellerin, katmanların veya projelerin karıştırılmasından kaynaklanır.
Modele Göre Filtreleyin (Bir Seferde Bir Tane)
Her zaman tek bir modele filtreleyin.
Neden:
Düşük trafikli modellerdeki sorunlar daha yüksek hacimli trafik tarafından gizlenebilir
Yüksek hacimli modeller, yerel sorunları genel bir sorun gibi gösterebilir
Farklı modellerin farklı performans hedefleri vardır
Not: Birden fazla model seçmek bunları birleştirir; aralarında geçiş yapmaz.
Hizmet Katmanına Göre Filtreleyin
Birden fazla katman kullanıyorsanız (standard, priority, scale), her zaman incelediğiniz katmana filtreleyin.
Neden:
Katmanların performans özellikleri farklıdır
Priority ve scale katmanlarının tanımlı SLA’leri vardır
Katmanları karıştırmak ücretli katman performansını belirsizleştirir
Bu, özellikle gecikme analizi için önemlidir.
Projeye Göre Filtreleyin
Service Health varsayılan olarak tüm projeleri gösterir.
Sorun giderme için, sorunun gözlemlendiği proje(ler)e filtreleyin.
Neden:
Tek bir yüksek hacimli proje metriklere hakim olabilir
Etkilenen daha küçük projeler ilgisiz trafik nedeniyle maskelenebilir
Sorunun gerçekten kuruluş genelinde olduğuna inanmadığınız sürece yalnızca "Tüm projeler" seçili kalsın.
Hataları Giderme
HTTP Requests Görünümünü Kullanın
Hataları incelemek için:
Modele ve katmana göre filtreleyin
Uptime görünümünden HTTP Requests görünümüne geçmek için HTTP Requests sekmesine tıklayın
Bu görünüm, HTTP durum koduna göre toplam istekleri ve hata sayılarını gösterir. Ayrıntılı ani artışları veya değişiklikleri belirlemek için dakika düzeyinde çözünürlüğe yakınlaştırın.
Hata Sayılarını Değil, Hata Oranlarını Yorumlayın
Bazı hatalar her üretim sisteminde beklenir. Ham toplamlar yerine hata yüzdesine odaklanın.
Toplam hacminiz ne kadar büyükse, hata oranı son derece düşük olsa bile potansiyel hata sayısı da o kadar büyük olur.
Hatalar Service Health’te Görünmüyorsa
İstemci tarafında hatalar görüyorsanız ancak Service Health’te karşılık gelen veri yoksa:
İstekler büyük olasılıkla OpenAI’ye ulaşmamıştır
Sorun genellikle yukarı akıştadır (zaman aşımları, proxy’ler, ağ)
Bu durum, agresif istemci tarafı zaman aşımlarında yaygındır.
Gecikme Sorunlarını Giderme
Gecikme analizi, tanımlı SLA’lere sahip olan priority ve scale katmanlarında en anlamlıdır. Standard katmanı daha geniş gecikme değişkenliği gösterebilir ve garantili gecikmeye sahip değildir.
Temel Metrikler
Bu metriklerin her birini görüntülemek için ilgili sekmeye tıklayın:
Token Hızı
Saniyede üretilen token sayısı.
Komut boyutundan bağımsızdır.
İstek Süresi
Toplam istek süresi.
Çıktı boyutu ve akıl yürütmeden güçlü biçimde etkilenir.
İlk Token’a Kadar Geçen Süre (TTFT)
İlk token üretilene kadar geçen süre.
Önbelleğe alınmamış giriş komutu boyutu ve akıl yürütmeden güçlü biçimde etkilenir.
Her zaman P50 / P75 / P95 yüzdelik dilimlerini inceleyin. Ortalamalar gerçek kullanıcı etkisini gizleyebilir.
6. Gecikmeyi Token Kullanımıyla İlişkilendirme
Service Health, davranışın ne zaman değiştiğini gösterir. Usage verileri ise nedenini açıklamaya yardımcı olur.
Usage panosunda, Service Health Panosundaki görünümünüzle ilgili verilere baktığınızdan emin olmak için aşağıdakileri yapın:
Filtreleyin: aynı proje ve model için
Uygunsa hizmet katmanına göre gruplandırın
Gecikmeyi en güçlü şekilde etkileyen çıktı token’larına odaklanın
Daha derin analiz için Activity Data’yı dışa aktarın ve zaman içinde istek başına token sayısını inceleyin.
7. Destekle Paylaşılması Gerekenler (Gerekirse)
Destek ile iletişime geçerseniz şunları ekleyin:
Etkilenen Org ID’leri (bu önemlidir)
Etkilenen uç noktalar (Chat Completions, Responses vb.) (bu önemlidir)
Etkilenen modeller (bu önemlidir)
Bu, scale veya priority katmanında mı? (bu önemlidir)
Gecikme veya hata için saat dilimiyle birlikte zaman aralıkları (bu önemlidir)
İlgili x-request-id veya X-Client-Request-Id (çoğu zaman önemlidir; mümkünse ekleyin)
Sağlanan isteklerin saat dilimiyle birlikte zaman damgaları (veya en azından tarih)
Gecikme - yavaş istek örnekleri paylaşıyorsanız, sizin tarafınızda ne kadar sürdüğünü paylaşın. İdeal olarak ayrıca isteğin ne zaman gönderildiğine ve ne zaman alındığına ilişkin zaman damgalarını da ekleyin.
Hatalar - lütfen başarısız/hata veren isteklerin yaklaşık yüzdesini, yanıt kod(lar)ını, hata mesaj(lar)ını ve hata yanıtının alınmasının ne kadar sürdüğünü paylaşın
İsteklerle ilgili proje kimliği
Bu durum veri saklama ve işleme konumu gereksinimleri taleplerini etkiliyor mu? Evetse hangilerini?
Gördüğünüz eğilimlerin açıklamaları
Hatalar: Başarısız/hata veren isteklerin yaklaşık yüzdesi
Gecikme: Hangi yüzdelik dilimler etkileniyor (p50 / p90 / p95 / p99) ve bunlar müşterinin temel düzeyine göre ne kadar yüksek
Her ikisi de: Hata veya gecikme verilerinin ekran görüntüleri ya da tablosu (Hata oranlarının veya gecikmenin beklenenden yüksek olduğunu nasıl belirlediniz?)
Yaygın Sorun Giderme Senaryoları
Zaman Aşımları Oluşuyor Ama Service Health Normal Görünüyor
Olası neden: isteklerin OpenAI’ye ulaşmadan önce zaman aşımına uğraması.
Kontrol edin:
İstemci veya proxy zaman aşımı ayarları
Yerel ağ veya yük dengeleyici değişiklikleri
Service Health panosunda 499 hatalarının varlığı (bunlar kendi sistemlerinizde 5xx hataları olarak görünebilir).
Bir Dağıtım Olmadan Gecikme Arttı
Olası neden: çıktı token boyutu veya akıl yürütme kullanımı arttı ve\veya trafik hizmet katmanları arasında kaydı
Kontrol edin:
Usage panosunda istek başına ortalama çıktı token sayısı (verilerin indirilmesini ve çıktı token’larının toplam isteklere bölünmesini gerektirir).
Service Health panosunda İstek Süresi ve TTFT yüzdelik dilimleri.
Priority veya Scale Katmanı Yavaş Görünüyor
Olası neden: metrikler katmanlar arasında karışıyor (yani standard katmanı trafiği ücretli katman performansını maskeliyor)
Kontrol edin:
Filtrelerin tek bir katman ve modelle sınırlandırılmış olması
Katmanlar arasında token hızı karşılaştırması
5XX Hatalarında Ani Artış
Muhtemel neden: trafiğin küçük bir yüzdesini etkileyen geçici arızalar.
Kontrol edin:
Hata oranı yüzdesi
Trafik hacminin aynı anda değişip değişmediği
Sorun Yalnızca Bir Projeyi Etkiliyor
Muhtemel neden: projeye özgü yapılandırma veya kullanım deseni.
Kontrol edin:
Proje düzeyinde filtreleme
Etkilenmeyen projelerle karşılaştırma
Son Çıkarımlar
Metrikleri yorumlamadan önce modele, katmana ve ilgili olduğunda projeye göre filtreleyin
Gecikme analizi için ortalamaları değil, yüzdelik dilimleri kullanın
Küçük hata oranları beklenir
Eksik veriler genellikle yukarı akış sorunlarını gösterir
Usage verileri gecikmenin neden değiştiğini açıklamaya yardımcı olabilir; Service Health ise ne zaman değiştiğini göstermeye yardımcı olur