중요 링크
*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에 도달하지 못했을 가능성이 높습니다.
문제는 보통 업스트림(타임아웃, 프록시, 네트워킹)에 있습니다.
이는 클라이언트 측 타임아웃이 공격적으로 설정된 경우 흔히 발생합니다.
지연 시간 문제 해결
지연 시간 분석은 정의된 SLA가 있는 priority 및 scale 티어에서 가장 의미가 있습니다. standard 티어는 지연 시간 변동 폭이 더 클 수 있으며, 지연 시간이 보장되지 않습니다.
주요 지표
각 지표를 보려면 관련 탭을 클릭하세요.
토큰 속도
초당 생성되는 토큰 수.
프롬프트 크기와 무관합니다.
요청 시간
총 요청 지속 시간.
출력 크기와 추론의 영향을 크게 받습니다.
첫 토큰까지 걸리는 시간(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(대개 중요하므로 가능하면 포함)
제공한 요청의 타임스탬프와 타임존(또는 최소한 날짜)
지연 시간 - 느린 요청의 예를 공유하는 경우, 사용자 측에서 얼마나 오래 걸렸는지 공유하세요. 가능하다면 요청이 전송된 시각과 수신된 시각의 타임스탬프도 포함하세요.
오류 - 실패/오류가 발생한 요청의 대략적인 비율, 응답 코드, 오류 메시지, 그리고 오류 응답을 받기까지 걸린 시간을 공유해 주세요.
요청과 관련된 프로젝트 id
데이터 레지던시 요청에 영향이 있나요? 그렇다면 어떤 요청인가요?
관찰 중인 추세에 대한 설명
오류: 실패/오류가 발생한 요청의 대략적인 %
지연 시간: 어떤 백분위수(p50 / p90 / p95 / p99)가 영향을 받는지, 그리고 고객의 기준선과 비교해 얼마나 높은지
둘 다: 오류 또는 지연 시간 데이터의 스크린샷이나 표(오류율 또는 지연 시간이 예상보다 높다고 어떻게 판단했나요?)
일반적인 문제 해결 시나리오
타임아웃이 발생하지만 Service Health는 정상으로 보이는 경우
가능한 원인: 요청이 OpenAI에 도달하기 전에 타임아웃되고 있습니다.
확인 사항:
클라이언트 또는 프록시 타임아웃 설정
로컬 네트워크 또는 로드 밸런서 변경
Service Health 대시보드에 499 오류가 있는지 여부(자체 시스템에서는 5xx 오류로 표시될 수 있음)
배포 없이 지연 시간이 증가한 경우
가능한 원인: 출력 토큰 크기 또는 추론 사용량이 증가했거나 서비스 티어 간 트래픽이 이동했습니다.
확인 사항:
Usage 대시보드에서 요청당 평균 출력 토큰 수(데이터를 다운로드한 후 출력 토큰을 총 요청 수로 나누어야 함)
Service Health 대시보드의 Request Time 및 TTFT 백분위수
Priority 또는 Scale 티어가 느리게 보이는 경우
가능한 원인: 지표가 티어 전반에 걸쳐 섞여 있습니다(즉, standard 티어 트래픽이 유료 티어 성능을 가리고 있음).
확인 사항:
필터가 단일 티어와 모델로 제한되어 있는지
티어 간 토큰 속도 비교
5XX 오류 급증
가능성 높은 원인: 트래픽의 일부 비율에 영향을 주는 일시적 장애.
확인 사항:
오류율 비율
같은 시점에 트래픽 볼륨이 변했는지 여부
문제가 한 프로젝트에만 영향을 미치는 경우
가능성 높은 원인: 프로젝트별 구성 또는 사용 패턴.
확인 사항:
프로젝트 수준 필터링
영향받지 않은 프로젝트와의 비교
최종 핵심 사항
지표를 해석하기 전에 모델, 티어, 그리고 관련이 있는 경우 프로젝트 별로 필터링하세요.
지연 시간 분석에는 평균이 아니라 백분위수를 사용하세요.
작은 오류율은 예상 가능한 범위입니다.
누락된 데이터는 보통 업스트림 문제를 나타냅니다.
Usage 데이터는 지연 시간이 왜 변했는지 설명하는 데 도움이 되고, Service Health는 언제 변했는지를 보여줍니다.