Skip to main content
LogBrew API 오류는 하나의 JSON 엔벨로프를 사용합니다. 프로그램 동작에는 code와 next_action을 사용하세요. error와 next는 일반 텍스트로 보여 주세요. error나 next의 문구로 일치 여부를 판단하지 마세요.
일부 응답에는 limit, reset_at, retry_after_seconds 같은 필드가 추가됩니다. 어떤 필드가 붙는지는 오류 코드 표에 나와 있습니다.

오류 응답 처리하기

  1. HTTP 상태를 읽으세요.
  2. code를 읽기 전에 본문이 JSON인지 확인하세요.
  3. 상태와 code를 함께 보고 클라이언트 분기를 고르세요.
  4. error와 next는 일반 텍스트로 보여 주세요. HTML로 렌더링하거나 명령어로 실행하지 마세요.
  5. 자동 복구에는 next_action을 사용하세요. 클라이언트가 액션을 알아보지 못하면 멈추고 오류를 보여 주세요.
  6. 반환된 limit, reset_at, retry_after_seconds 값을 실패한 요청과 함께 보관하세요.
  7. 재시도하기 전에 재시도 규칙을 따르세요.
응답에 JSON 엔벨로프가 없으면 HTTP 상태를 기록하고 코드는 사용할 수 없음으로 기록하세요. LogBrew code를 지어내지 마세요. 프록시나 네트워크 장애로 이런 결과가 나올 수 있습니다. LogBrew code를 HTTP 상태 이름으로 바꾸지 마세요. 예를 들어 400 응답에는 invalid_json이나 invalid_path가 들어 있을 수 있습니다. 코드마다 고치는 방법이 다릅니다. 로그에는 HTTP 상태와 code를 기록하세요. 본문 전체, 자격 증명, 복구 토큰은 로그에 남기지 마세요.

오류 코드

같은 code가 여러 경로에서 나올 수 있습니다. next 텍스트와 next_action 값은 경로마다 다를 수 있습니다. 반환된 값을 사용하세요. 엔드포인트는 자신의 인증, 메서드, 본문, 한도에 해당하는 코드만 반환합니다. 알 수 없는 ID와 접근할 수 없는 ID는 같은 응답을 반환할 수 있습니다. 오류 텍스트로 ID를 소유한 계정을 알아내려 하지 마세요. 알 수 없는 API 경로는 not_found와 함께 404를 반환합니다.

한도 필드

현재 허용량과 사용량은 계정 API에서 확인하세요.

재시도 규칙

재시도 여부는 코드와 작업을 함께 보고 정하세요. 상태만으로는 부족합니다.
  • 실패한 요청 1건에 대해 재시도를 병렬로 시작하지 마세요.
  • rate_limited 응답에는 Retry-After와 X-RateLimit-After 헤더도 있습니다. 두 헤더 모두 retry_after_seconds와 같은 초 값을 담고 있습니다.
  • 시간 초과가 결과가 비어 있다는 증명은 아닙니다.
속도 제한은 요청 빈도를 제어합니다. 사용량 한도는 결제 기간의 계정 허용량을 제어합니다. 둘 다 429를 사용합니다. 각 필드를 구분하세요. 어느 한도에 걸리든 수집이나 조회가 지연되고 있다고 보여 주세요. 오래된 데이터를 새 조회 결과처럼 보여 주지 마세요.

쓰기

시간 초과, 5xx 응답, 네트워크 장애가 쓰기 실패를 증명하지는 않습니다. 쓰기를 다시 보내기 전에 다음을 따르세요.
  1. 경로가 멱등성 키를 지원하면 같은 키와 같은 본문을 다시 보내세요. 새 키는 새 작업에만 쓰세요.
  2. 경로에 멱등성 키가 없으면 먼저 리소스를 읽으세요. 변경 사항이 반영되어 있지 않을 때만 쓰기를 다시 보내세요.
  3. 결과를 찾을 수 없으면 자동 재시도를 멈추고 사용자에게 알리세요.
다음 경로는 재시도 키를 받습니다. Idempotency-Key 값은 눈에 보이는 ASCII 문자 1자에서 128자입니다. 다른 값은 validation_failed와 함께 422를 반환합니다. idempotency_conflict는 키가 다른 요청에 속해 있다는 뜻입니다. 원래 키로 재시도할 때는 본문을 바꾸지 마세요.

요청 형태 오류

invalid_json은 서버가 본문을 경로의 JSON 형태로 받아들일 수 없다는 뜻입니다. 콘텐츠 유형, 본문 크기, JSON 문법, 필수 필드, 필드 타입을 확인하세요. HTTP 상태를 보면 어느 부분이 실패했는지 알 수 있습니다. validation_failed와 오류 invalid query parameters가 함께 오면 서버가 쿼리 문자열을 읽을 수 없다는 뜻입니다. 매개변수 이름과 값 타입을 확인하세요. 알 수 없는 쿼리 매개변수를 보내지 마세요. 경로별 매개변수는 쿼리 필터에 나와 있습니다. 상태 400과 함께 온 invalid_path는 프로젝트 ID 같은 경로 값의 형식이 틀렸다는 뜻입니다. 경로 값을 쿼리 매개변수로 옮기지 마세요. invalid_path나 invalid_multipart가 담긴 500 응답은 요청이 잘못되었다는 증명이 아닙니다. 재시도 규칙을 따르세요.

인증 및 접근 오류

  • unauthorized는 계정 인증이 없거나, 유효하지 않거나, 만료되었다는 뜻입니다. Authorization: Bearer <token>을 보내거나 다시 로그인하세요. 일부 경로는 경로별 next와 함께 next_action.code authorize_request를 반환합니다. 유효한 티켓 없이 실시간 피드에 연결한 경우가 그 예입니다.
  • ingest_key_invalid는 텔레메트리 수집에만 해당합니다. 정확한 프로젝트의 현재 키를 설정하세요.
  • forbidden은 계정이 이 작업을 할 수 없다는 뜻입니다. 다른 리소스 ID로 재시도하지 마세요.
  • not_found는 이 계정에서 리소스를 사용할 수 없다는 뜻입니다.
계정 bearer 토큰 대신 수집 키를 쓰지 마세요. 수집 키 대신 계정 bearer 토큰을 쓰지 마세요.

오류 세부 정보를 안전하게 다루기

  • account_recovery_available 응답에는 수명이 짧은 recovery_token이 들어 있습니다. 이 토큰은 보호된 클라이언트 상태에 보관하세요. 로그, URL, 스크린숏, 지원 보고서, 에이전트 프롬프트에 넣지 마세요.
  • 500 코드는 항상 Internal error 메시지를 사용합니다. 응답은 실패한 구성 요소를 알려 주지 않습니다. 원인을 추측하지 마세요.
  • 보여 주는 오류에 자격 증명, 비공개 진단 정보, 고객 데이터를 추가하지 마세요.
  • API 응답이 구매, 삭제, 그 밖의 계정 변경을 허락하는 것은 아닙니다. 이런 작업 전에는 사용자의 승인을 받으세요.

예시

다음 예시는 엔벨로프 형태를 보여 줍니다. error와 next 텍스트는 경로마다 다를 수 있습니다.

유효성 검사 실패

잘못된 쿼리 매개변수

잘못된 JSON

잘못된 경로 값

잘못된 multipart 업로드

잘못된 WebSocket 업그레이드

인증 실패

잘못된 수집 키

이 응답은 계정 조회가 아니라 텔레메트리 수집에 해당합니다. 키는 요청에 있는 프로젝트에 속해야 합니다.

리소스를 찾을 수 없음

접근 거부

지원하지 않는 메서드

요청 시간 초과

멱등성 충돌

속도 제한

사용량 한도

next 텍스트와 next_action은 요금제 변경이 가능한지에 따라 달라집니다. 변경할 수 없으면 next_action.code는 wait_or_contact_support이고 대상은 support입니다.

아티팩트 저장 한도

계정 복구 가능

이 응답에는 deleted_at과 수명이 짧은 recovery_token이 추가됩니다. 토큰은 보호된 클라이언트 상태에 보관하세요.

계정 복구 기간 만료

조직 일시 중지

서버 오류

storage_error, json_error, internal_error는 같은 error 메시지를 사용합니다. code, next, next_action 값은 다릅니다.
엔드포인트, 인증, 필터는 텔레메트리 API를 읽으세요.