Tärkeät linkit
*Service Health -koontinäyttö on tällä hetkellä saatavilla vain Enterprise API -asiakkaille.
Aloita oikeilla oletusasetuksilla
Kun avaat Service Health -koontinäytön, oletusasetukset ovat:
Kaikki projektit
Viimeiset 30 päivää
Tuntikohtainen tarkkuus
Tämä näkymä on hyödyllinen vain yleiskuvan saamiseksi. Tarkka vianmääritys edellyttää aina suodatusta.
Suodata ennen tutkimista
Oikea suodatus on tärkein vaihe. Useimmat virhetulkinnat johtuvat mallien, tasojen tai projektien sekoittamisesta.
Suodata mallin mukaan (yksi kerrallaan)
Suodata aina yhteen malliin.
Miksi:
Vähäliikenteisten mallien ongelmat voivat jäädä suuremman liikennemäärän alle
Suuren liikennemäärän mallit voivat saada paikalliset ongelmat näyttämään yleisiltä
Eri malleilla on eri suorituskykytavoitteet
Huomaa: usean mallin valitseminen yhdistää ne — se ei vaihda niiden välillä.
Suodata palvelutason mukaan
Jos käytät useampaa kuin yhtä tasoa (standard, priority, scale), suodata aina tutkittavaan tasoon.
Miksi:
Tasoilla on erilaiset suorituskykyominaisuudet
Priority- ja scale-tasoilla on määritellyt SLA:t
Tasojen sekoittaminen peittää maksullisten tasojen suorituskyvyn
Tämä on erityisen tärkeää latenssianalyysissä.
Suodata projektin mukaan
Oletuksena Service Health näyttää kaikki projektit.
Vianmääritystä varten suodata niihin projekteihin, joissa ongelma havaittiin.
Miksi:
Yksi suuren liikennemäärän projekti voi hallita mittareita
Pienemmät projektit, joihin ongelma vaikuttaa, voivat peittyä muun liikenteen alle
Jätä vain "Kaikki projektit" valituksi, jos uskot ongelman koskevan todella koko organisaatiota.
Virheiden vianmääritys
Käytä HTTP Requests -näkymää
Virheiden tutkimiseksi:
Suodata mallin ja tason mukaan
Voit vaihtaa Uptime-näkymästä HTTP Requests -näkymään napsauttamalla HTTP Requests -välilehteä
Tämä näkymä näyttää pyyntöjen kokonaismäärän ja virheiden määrän HTTP-tilakoodeittain. Tarkenna minuutin tarkkuuteen tunnistaaksesi yksityiskohtaiset piikit tai muutokset.
Tulkitse virheprosentteja, älä määriä
Joissakin virheissä on odotettavaa missä tahansa tuotantojärjestelmässä. Keskity virheiden prosenttiosuuteen, älä raakoihin kokonaismääriin.
Mitä suurempi kokonaisvolyymisi on, sitä suurempi mahdollinen virheiden määrä on, vaikka virheaste olisi erittäin alhainen.
Kun virheitä ei näy Service Healthissä
Jos näet asiakaspuolen virheitä mutta Service Healthissä ei ole vastaavia tietoja:
Pyynnöt eivät todennäköisesti saavuttaneet OpenAI:ta
Ongelma on yleensä upstreamissa (aikakatkaisut, välityspalvelimet, verkko)
Tämä on yleistä aggressiivisten asiakaspuolen aikakatkaisujen yhteydessä.
Latenssin vianmääritys
Latenssianalyysi on merkityksellisintä priority- ja scale-tasoilla, joilla on määritellyt SLA:t. Standard-tasolla latenssi voi vaihdella enemmän, eikä sille taata latenssia.
Keskeiset mittarit
Näet kunkin näistä mittareista napsauttamalla asianmukaista välilehteä:
Token Velocity
Sekunnissa luodut tokenit.
Riippumaton kehotteen koosta.
Request Time
Pyynnön kokonaiskesto.
Vaikuttavat voimakkaasti tulosteen koko ja päättely.
Time to First Token (TTFT)
Aika ensimmäisen tokenin luomiseen.
Vaikuttavat voimakkaasti välimuistittoman syötekehotteen koko ja päättely.
Tarkista aina P50 / P75 / P95 -persentiilit. Keskiarvot voivat peittää todellisen vaikutuksen käyttäjiin.
6. Latenssin suhteuttaminen tokenien käyttöön
Service Health näyttää, milloin toiminta muuttui. Usage-tiedot auttavat selittämään, miksi.
Tee Usage-koontinäytössä seuraavat toimet varmistaaksesi, että tarkastelet Service Health -koontinäytön näkymän kannalta olennaisia tietoja:
Suodata samaan projektiin ja malliin
Ryhmittele palvelutason mukaan tarvittaessa
Keskity output tokeneihin, jotka vaikuttavat voimakkaimmin latenssiin
Syvempää analyysiä varten vie Activity Data ja tarkastele pyyntökohtaisten tokenien määrää ajan kuluessa.
7. Mitä jakaa tuelle (tarvittaessa)
Jos otat yhteyttä tukeen, liitä mukaan:
Vaikutuksen kohteena olevat Org ID:t (tämä on tärkeää)
Vaikutuksen kohteena olevat endpointit (Chat Completions, Responses jne.) (tämä on tärkeää)
Vaikutuksen kohteena olevat mallit (tämä on tärkeää)
Onko tämä scale- vai priority-tasolla? (tämä on tärkeää)
Aikavälit aikavyöhykkeineen latenssia tai virheitä varten (tämä on tärkeää)
Asiaankuuluvat x-request-id- tai X-Client-Request-Id-tunnukset (usein tärkeitä; liitä mukaan, jos mahdollista)
Aikaleimat aikavyöhykkeineen (tai ainakin päivämäärä) annetuista pyynnöistä
Latenssi – jos jaat esimerkkejä hitaista pyynnöistä, kerro kuinka kauan ne kestivät omalla puolellasi. Ihannetapauksessa liitä mukaan myös aikaleimat sille, milloin pyyntö lähetettiin ja milloin se vastaanotettiin.
Virheet – kerro arvio epäonnistuneiden/virheellisten pyyntöjen prosenttiosuudesta, vastauskoodi(t), virheilmoitus/virheilmoitukset ja kuinka kauan virhevastausta kesti saada
Pyyntöihin liittyvä project id
Vaikuttaako tämä tietojen sijaintipaikkaa koskeviin pyyntöihin? Jos kyllä, mihin niistä?
Kuvaukset havaitsemistasi trendeistä
Virheet: arvio epäonnistuneiden/virheellisten pyyntöjen prosenttiosuudesta
Latenssi: mihin persentiileihin vaikutus kohdistuu (p50 / p90 / p95 / p99) ja kuinka korkeita ne ovat verrattuna asiakkaan lähtötasoon
Molemmat: kuvakaappaukset tai taulukko virhe- tai latenssitiedoista (Miten määritit, että virheasteet tai latenssi ovat odotettua korkeampia?)
Yleisiä vianmääritystilanteita
Aikakatkaisuja esiintyy, mutta Service Health näyttää normaalilta
Mahdollinen syy: pyynnöt aikakatkaistaan ennen kuin ne saavuttavat OpenAI:n.
Tarkista:
Asiakkaan tai välityspalvelimen aikakatkaisuasetukset
Paikallisen verkon tai kuormantasaajan muutokset
499-virheiden esiintyminen Service Health -koontinäytössä (ne voivat näkyä omissa järjestelmissäsi 5xx-virheinä).
Latenssi kasvoi ilman käyttöönottoa
Mahdollinen syy: output-tokenien määrä tai päättelyn käyttö kasvoi ja\or liikenne siirtyi palvelutasojen välillä
Tarkista:
Keskimääräiset output-tokenit pyyntöä kohden Usage-koontinäytössä (edellyttää tietojen lataamista ja output-tokenien jakamista pyyntöjen kokonaismäärällä).
Request Time- ja TTFT-persentiilit Service Health -koontinäytössä.
Priority- tai Scale-taso näyttää hitaalta
Mahdollinen syy: mittarit ovat sekoittuneet tasojen välillä (eli standard-tason liikenne peittää maksullisten tasojen suorituskyvyn)
Tarkista:
Suodattimet on rajattu yhteen tasoon ja malliin
Token velocity -vertailu tasojen välillä
Piikki 5XX-virheissä
Todennäköinen syy: ohimenevät häiriöt, jotka vaikuttavat pieneen osaan liikenteestä.
Tarkista:
Virheprosentti
Muuttuiko liikennemäärä samaan aikaan
Ongelma vaikuttaa vain yhteen projektiin
Todennäköinen syy: projektikohtainen määritys tai käyttötapa.
Tarkista:
Projektitason suodatus
Vertailu projekteihin, joihin ongelma ei vaikuta
Lopulliset huomiot
Suodata mallin, tason ja tarvittaessa projektin mukaan ennen mittareiden tulkitsemista
Käytä latenssianalyysissä persentiilejä, älä keskiarvoja
Pienet virheasteet ovat odotettavissa
Puuttuvat tiedot viittaavat yleensä upstream-ongelmiin
Usage-tiedot voivat auttaa selittämään, miksi latenssi muuttui; Service Health auttaa näyttämään, milloin