Важни връзки
*Таблото Service Health в момента е достъпно само за Enterprise API клиенти.
Започнете с правилните настройки по подразбиране
Когато отворите таблото Service Health, по подразбиране то е настроено на:
Всички проекти
Последните 30 дни
Почасова резолюция
Този изглед е полезен само за ориентация. Смисленото отстраняване на проблеми винаги изисква филтриране.
Филтрирайте, преди да анализирате
Правилното филтриране е най-важната стъпка. Повечето погрешни тълкувания идват от смесване на модели, нива или проекти.
Филтриране по модел (по един наведнъж)
Винаги филтрирайте до един модел.
Защо:
Проблеми при модели с нисък трафик могат да бъдат скрити от по-голям обем трафик
Модели с голям обем трафик могат да накарат локални проблеми да изглеждат глобални
Различните модели имат различни цели за производителност
Забележка: изборът на няколко модела ги агрегира — не превключва между тях.
Филтриране по ниво на услугата
Ако използвате повече от едно ниво (standard, priority, scale), винаги филтрирайте до нивото, което разследвате.
Защо:
Нивата имат различни характеристики на производителност
Нивата priority и scale имат дефинирани SLA
Смесването на нива затруднява преценката на производителността на платените нива
Това е особено важно за анализа на латентността.
Филтриране по проект
По подразбиране Service Health показва всички проекти.
За отстраняване на проблеми филтрирайте до проекта(ите), в който е наблюдаван проблемът.
Защо:
Един проект с голям обем трафик може да доминира метриките
По-малки засегнати проекти могат да бъдат прикрити от несвързан трафик
Оставяйте избрано „Всички проекти“ само ако смятате, че проблемът наистина е за цялата организация.
Отстраняване на грешки
Използвайте изгледа HTTP Requests
За да анализирате грешки:
Филтрирайте по модел и ниво
За да превключите от Uptime към HTTP Requests, щракнете върху раздела HTTP Requests
Този изглед показва общия брой заявки и броя грешки по HTTP код на състоянието. Увеличете до резолюция на ниво минута, за да откриете детайлни пикове или промени.
Тълкувайте честотата на грешките, а не броя им
Някои грешки са очаквани във всяка производствена система. Фокусирайте се върху процента на грешките, а не върху суровите общи стойности.
Колкото по-голям е общият ви обем, толкова по-голям може да е броят на грешките дори при изключително ниска честота на грешки.
Когато грешките липсват в Service Health
Ако виждате грешки от страна на клиента, но няма съответстващи данни в Service Health:
Заявките вероятно не са достигнали до OpenAI
Проблемът обикновено е нагоре по веригата (timeouts, proxies, networking)
Това е често срещано при агресивни таймаути от страна на клиента.
Отстраняване на проблеми с латентността
Анализът на латентността е най-смислен при priority и scale нива, които имат дефинирани SLA. Standard нивото може да показва по-големи вариации в латентността и няма гарантирана латентност.
Ключови метрики
За да видите всяка от тези метрики, щракнете върху съответния раздел:
Token Velocity
Генерирани токени за секунда.
Независимо от размера на подканата.
Request Time
Обща продължителност на заявката.
Силно се влияе от размера на изхода и структуриранoто анализиране.
Time to First Token (TTFT)
Време до генерирането на първия токен.
Силно се влияе от размера на некешираната входна подкана и структурираното анализиране.
Винаги преглеждайте персентилите P50 / P75 / P95. Средните стойности могат да скрият въздействието върху реалните потребители.
6. Свързване на латентността с използването на токени
Service Health показва кога се е променило поведението. Данните за Usage помагат да се обясни защо.
В таблото Usage направете следното, за да сте сигурни, че разглеждате данни, които са релевантни за изгледа ви в таблото Service Health:
Филтрирайте по същия проект, модел
Групирайте по ниво на услугата ако е приложимо
Фокусирайте се върху изходните токени, които влияят най-силно на латентността
За по-задълбочен анализ експортирайте Activity Data и разгледайте токените на заявка във времето.
7. Какво да споделите с поддръжката (ако е необходимо)
Ако се свържете с поддръжката, включете:
Засегнати Org ID (това е важно)
Засегнати крайни точки (Chat Completions, Responses и др.) (това е важно)
Засегнати модели (това е важно)
Това на scale или priority ниво ли е? (това е важно)
Времеви диапазони с часова зона за латентността или грешката (това е важно)
Съответният x-request-id или X-Client-Request-Id (често е важно; включете го, ако е възможно)
Времеви отпечатъци с часова зона (или поне датата) на предоставените заявки
Латентност - ако споделяте примери за бавни заявки, споделете колко време е отнело от ваша страна. В идеалния случай включете и времевите отпечатъци за това кога заявката е била изпратена и кога е била получена.
Грешки - моля, споделете приблизителния процент на неуспешните/грешащи заявки, кода(овете) на отговора, съобщението(ята) за грешка и колко време е отнело получаването на отговора с грешка
Project id, свързан със заявките
Това засяга ли заявки за местонахождение на данните? Ако да, кои?
Описания на тенденциите, които виждате
Грешки: Приблизителен % на неуспешните/грешащи заявки
Латентност: Кои персентили са засегнати (p50 / p90 / p95 / p99) и колко високи са в сравнение с базовото ниво на клиента
И двете: Екранни снимки или таблица с данни за грешки или латентност (Как определихте, че честотата на грешките или латентността е по-висока от очакваното?)
Често срещани сценарии за отстраняване на проблеми
Възникват таймаути, но Service Health изглежда нормално
Възможна причина: заявките изтичат по време, преди да достигнат до OpenAI.
Проверете:
Настройките за таймаут на клиента или проксито
Промени в локалната мрежа или в load balancer
Наличие на грешки 499 в таблото Service Health (те може да се показват като 5xx грешки във вашите собствени системи).
Латентността се е увеличила без deployment
Възможна причина: размерът на изходните токени или използването на структурирано анализиране се е увеличило и\или трафикът се е прехвърлил между нивата на услугата
Проверете:
Средния брой изходни токени на заявка в таблото Usage (изисква изтегляне на данни и разделяне на изходните токени на общия брой заявки).
Персентилите за Request Time и TTFT в таблото Service Health.
Priority или Scale нивото изглежда бавно
Възможна причина: метриките са смесени между нивата (което означава, че трафикът от standard нивото прикрива производителността на платените нива)
Проверете:
Филтрите са ограничени до едно ниво и един модел
Сравнение на скоростта на токените между нивата
Скок в 5XX грешки
Вероятна причина: временни откази, засягащи малък процент от трафика.
Проверете:
Процента на честотата на грешките
Дали обемът на трафика се е променил по същото време
Проблемът засяга само един проект
Вероятна причина: специфична за проекта конфигурация или модел на използване.
Проверете:
Филтриране на ниво проект
Сравнение с незасегнати проекти
Финални изводи
Филтрирайте по модел, ниво и, когато е релевантно, проект преди да тълкувате метриките
Използвайте персентили, а не средни стойности, за анализ на латентността
Малки честоти на грешки са очаквани
Липсващите данни обикновено показват проблеми нагоре по веригата
Данните за Usage могат да помогнат да се обясни защо се е променила латентността; Service Health помага да покаже кога