티켓 만들기
CLI에서 다음을 실행하세요.source를 cli로 설정합니다. --diagnostics는 바이너리 이름, CLI 버전, 운영체제, 아키텍처만 추가합니다. 모든 플래그를 보려면 logbrew support --help를 실행하세요.
CLI는 티켓을 만들 때 재시도 키를 보내지 않습니다. 결과가 불확실하면 명령어를 다시 실행하기 전에 logbrew support list --json을 실행하세요. 그렇지 않으면 티켓이 2개 생길 수 있습니다.
API에서는 source, category, title, description과 함께 POST /api/support/tickets를 보내세요. 재시도를 안전하게 하려면 보고서마다 재시도 키를 한 번 만들고 Idempotency-Key 헤더로 보내세요. 이 예시는 가상의 값을 사용합니다.
Idempotency-Key 헤더는 선택 사항입니다. 헤더 없이 요청을 반복하면 티켓이 하나 더 생길 수 있습니다.
선택 필드는 project_id, environment, runtime, framework, sdk_package, sdk_version, release, trace_id, event_id, diagnostics입니다. 특정 프로젝트와 관련 없는 문제라면 project_id를 빼세요. project_id는 내 계정의 활성 프로젝트를 가리켜야 합니다.
요청에 성공하면 HTTP
200이 반환됩니다.
sup_으로 시작합니다. next는 사람에게 보여 주는 안내로, next_action은 프로그램 제어에 사용하세요.
프로젝트를 삭제하려면 프로젝트 설정이나 logbrew projects delete를 사용하세요. 지원 티켓으로 프로젝트 삭제를 요청하지 마세요.
쓸모 있는 보고서 쓰기
- 티켓 1개에는 문제를 1개만 보고하세요.
- 가장 가까운
category를 고르세요. 맞는 카테고리가 없을 때만other를 쓰세요. title에는 증상 1개와 문제가 생긴 곳 1개를 적으세요.description에는 단계를 적고, 그다음 예상 결과와 실제 결과를 적으세요.- 프로젝트, 릴리스, 트레이스, 이벤트 ID는 같은 실패를 가리킬 때만 추가하세요.
diagnostics에는 다음 키를 사용하세요.
diagnostics는 마스킹을 마친 뒤 최대 16KB인 JSON 객체입니다. 키 이름이 자격 증명, 세션, 이메일 주소를 가리키면 LogBrew는 값을 [redacted]로 바꿉니다. 자격 증명, URL, 로컬 경로처럼 보이는 텍스트도 바꿉니다. 또한 긴 문자열을 줄이고, 중첩 깊이, 키, 목록 항목 수를 제한합니다. 이 마스킹에 의존하지 마세요. 요청을 보내기 전에 개인정보를 지우세요.
티켓 추적하기
목록은
project_id, status, source, category, release, limit을 받습니다. limit의 기본값은 100이고 최대값은 500입니다. 커서 기반 페이지네이션을 쓰려면 pagination=cursor를 보내세요. 다음 페이지부터는 같은 필터를 반복하고, next_cursor의 cursor_time과 cursor_id를 보내세요. 커서 ID는 sup_ 티켓 ID입니다. next_cursor가 null이면 멈추세요. CLI는 --project, --status, --source, --category, --release, --limit, --pagination, --cursor-time, --cursor-id 플래그를 사용합니다.
상태 값은 open, routed, in_progress, waiting_on_user, resolved, closed입니다. 직접 설정할 수 있는 값은 open과 closed뿐입니다. 닫기나 다시 열기 요청을 반복해도 아무것도 바뀌지 않고 성공으로 처리되므로, 같은 요청을 그대로 재시도할 수 있습니다. 반환된 상태와 next_action을 따르세요.
요청받은 컨텍스트 추가하기
티켓에서 컨텍스트를 요청하면 답장하세요. 이런 티켓은 상태가waiting_on_user이고 next_action.code가 provide_context입니다.
context와 선택 사항인 diagnostics가 들어갑니다. context 텍스트는 1자에서 4,000자여야 합니다. context에 자격 증명, URL, 호스트 이름, 로컬 경로를 넣지 마세요. API는 이런 텍스트를 422로 거부합니다. Idempotency-Key 헤더로 재시도 키를 보내세요. 컨텍스트 경로에는 이 헤더가 필요합니다. 키는 공백 없이, 눈에 보이는 ASCII 문자 1자에서 128자로 이루어집니다. 답장마다 새 키를 쓰세요. 같은 답장을 재시도할 때만 키를 다시 쓰세요.
API는 티켓이 open, routed, in_progress, waiting_on_user 상태일 때 컨텍스트를 받습니다. 티켓 상태 하나당 답장 1개를 받습니다. 답장한 뒤에는 상태가 바뀔 때까지 기다렸다가 컨텍스트를 더 보내세요. waiting_on_user 티켓에 답장하면 티켓이 open이 됩니다. 이 변경을 가정하지 말고 반환된 status를 읽으세요.
답장에 성공하면 ticket_id, context_id, status, created_at, next, next_action이 반환됩니다. context_id는 ctx_로 시작합니다. 이후 요청에 답하기 전에 티켓을 다시 읽으세요.
GET /api/support/tickets/{ticket_id}/context는 가장 최근 컨텍스트 항목 20개를 오래된 순서로 반환합니다. 각 항목에는 context_id, context, diagnostics, created_at이 있습니다. 이 목록에는 커서가 없습니다.
resolved 또는 closed 티켓에 답장하면 code: "validation_failed"와 함께 422가 반환됩니다. 사용자가 그 지원 요청을 이어 가고 싶을 때만 티켓을 다시 여세요. next_action은 에이전트에게 계정 상태를 바꿀 권한을 주지 않습니다.
오류에서 복구하기
오류 응답에는
error, code, next, next_action이 들어 있습니다. API 오류를 참고하세요.
