응답 읽기
모든 응답은 다음 순서로 읽으세요.- HTTP 상태를 읽으세요.
- 본문이 해당 라우트의 형식인지 확인하세요.
- 각
project_id가 요청한 프로젝트 범위 안에 있는지 확인하세요. - 표준 enum 값과 식별자는 바꾸지 마세요.
next_action은 클라이언트가 그code와target을 지원할 때만 따르세요.null, 생략된 필드, 빈 목록은 서로 다른 상태로 다루세요.
200 OK에 빈 목록이 들어 있을 수 있습니다. 로그 목록이 비어 있으면 요청과 일치하는 로그가 없다는 뜻입니다. 이슈, 트레이스, 액션도 비어 있다는 뜻은 아닙니다. 타임스탬프가 가깝다는 이유로 시그널을 연결하지 마세요. 트레이스는 응답에 정확한 trace_id가 있을 때만 따라가세요.
404와 빈 목록은 서로 다른 결과입니다. 목록 라우트는 일치하는 레코드가 없으면 []를 반환합니다. 상세 라우트는 읽을 수 있는 레코드를 찾지 못하면 code: not_found와 함께 404를 반환합니다. 어느 결과도 수집이 실패했다는 것을 증명하지는 않습니다.
보낼 값
응답의 쓸모는 보내는 텔레메트리에 달려 있습니다. 모든 엔벨로프나 SDK 설정에 다음 값을 넣으세요.release와environment.- 서비스, 액션, 메트릭의 고정된 이름.
- 로그, 스팬, 액션, 이슈가 같은 요청에 속할 때의 트레이스 컨텍스트.
- 표준 심각도 값:
info,warning,error,critical. - 디버깅에 도움이 되는 속성. 시크릿이나 불필요한 개인정보는 넣지 마세요.
수집 응답
공개 SDK는POST /v1/events 응답을 대신 읽습니다. 애플리케이션 코드에서 처리할 필요가 없습니다.
SDK 배치 응답
SDK 배치가 성공하면 스트림별로 접수된 개수와 함께200 OK를 반환합니다.
개수는 이 배치만 셉니다. LogBrew가 이미 접수한 배치를 재시도하면 모든 스트림이
0이고, already_accepted에는 이벤트 수가 들어갑니다. 재시도할 때는 원래 이벤트 ID를 유지하세요.
네이티브 엔벨로프 응답
POST /api/telemetry/ingest는 스트림별로 접수된 항목 수와 함께 200 OK를 반환합니다.
metrics나 context_updated 필드가 없습니다. 이 필드를 추가하지 마세요. already_accepted는 LogBrew가 이 프로젝트에서 같은 id로 이전에 접수한 항목을 셉니다. 네이티브 엔벨로프 직접 보내기를 참고하세요.
수집 오류
code: ingest_key_invalid와 함께 401이 오면 수집 bearer 토큰이 해지되었거나, 만료되었거나, 해당 프로젝트에 유효하지 않다는 뜻입니다. POST /v1/events에서 bearer 토큰이 없거나 수집 키가 아니면 code: unauthorized와 함께 401을 반환합니다. 현재 프로젝트 범위의 수집 bearer 토큰을 사용하세요. 계정 bearer 토큰으로 재시도하지 마세요.
SDK 배치가 거부되면 code: validation_failed와 함께 422를 반환합니다.
error 값으로는 SDK event batch requires at least one event와 SDK event type is not supported by this ingest route가 있습니다. SDK 버전과 전송 설정을 확인하세요. 빈 배치를 보내지 마세요. 검증을 통과시키려고 이벤트 유형이나 ID를 바꾸지 마세요.
POST가 아닌 메서드로 요청하면 code: method_not_allowed와 함께 405를 반환합니다. 읽을 수 없는 JSON 본문은 code: invalid_json을 반환합니다.
텔레메트리 목록 응답 형식
목록 라우트는 기본적으로 맨 JSON 배열을 반환합니다. 성공했지만 비어 있는 목록은[]입니다.
pagination=cursor를 보내면 라우트가 엔벨로프를 반환합니다. 컬렉션 키는 시그널에 따라 정해집니다.
next_cursor는 이어서 읽는 데 필요한 필드를 담은 객체이며, 마지막 페이지에서는 null입니다. 행은 최신순입니다. 커서 기반 페이지네이션을 참고하세요.
로그 응답
limit=1로 요청한 로그 커서 페이지입니다.
level과 표시용 severity가 있습니다. 둘 다 표준 값을 담습니다. triage에는 심각도 규칙의 결과가 들어갑니다. 심각도 규칙 응답을 참고하세요.
로그에 트레이스 링크가 없으면 trace_id와 span_id는 null입니다. 이때 next_action은 inspect_related_logs이고 대상은 telemetry_logs입니다. 로그, 이슈, 액션은 같은 next_action 조합 2개를 사용합니다.
GET /api/logs/{log_id}는 같은 형식으로 로그 1개를 반환합니다.
이슈 응답
GET /api/telemetry/issues/{issue_id}는 그룹화된 이슈 1개를 반환합니다. 목록도 같은 객체를 반환합니다. 이 예시는 기본 응답 버전 1을 사용합니다.
status는 unresolved, resolved, ignored 중 하나입니다. 보관된 이슈는 triage.ignored가 true입니다. next_action 조합과 그 뒤에 이어지는 조회는 이슈 조사하기를 참고하세요.
first_seen_at과 last_seen_at은 첫 발생 건과 가장 최근 발생 건의 시각입니다. 상태가 바뀌어도 이 값은 바뀌지 않습니다.
일부 필드는 LogBrew에 데이터가 있을 때만 나타납니다.
symbolication.status는 resolved, invalid_metadata, artifact_not_found, source_not_resolved, unavailable 중 하나입니다. 목록, 상태 변경, 규칙 변경은 symbolication을 반환하지 않습니다.
response_version=2를 보내면 이슈의 필드는 같고 다음 항목이 바뀝니다.
error와 critical이면 high, warning이면 medium, info이면 low입니다. 이 값은 triage.effective_severity를 사용하므로 이슈 심각도 규칙으로 바뀔 수 있습니다.
response_version=3을 보내면 이슈에 버전 2의 모든 필드와 assignee가 들어갑니다. 이슈에 담당자가 없으면 assignee는 null입니다.
할당된 멤버가 더 이상 프로젝트를 읽을 수 없으면 이슈에 담당자가 표시되지 않습니다.
response_version=4에서는 assignee에 type도 있습니다. user 담당자에는 버전 3과 같이 user_id, name, email이 있습니다. team 담당자에는 team_id, slug, name이 있습니다. 버전 3은 팀 담당자를 null로 표시합니다. CLI는 버전 4를 요청합니다.
response_version 값은 code: validation_failed와 함께 422를 반환합니다. 커서 페이지는 issues의 모든 이슈에 같은 버전을 사용합니다.
담당자 목록 응답
GET /api/telemetry/issues/assignees?project_id=<project_id>는 프로젝트에서 이슈를 할당받을 수 있는 모든 계정을 반환합니다.
response_version=2를 추가하면 teams도 받습니다. 프로젝트 조직의 모든 팀이 team_id, slug, name과 함께 들어 있습니다.
계정이 프로젝트를 읽을 수 없으면 라우트는 code: not_found와 함께 404를 반환합니다.
액션 응답
distinct_id는 한 행위자나 세션을 따라갑니다. distinct_id와 session_id는 구조를 해석하지 말고 그대로 식별자로 다루세요. session_id와 trace_id는 값이 없으면 null입니다. span_id는 값이 없으면 생략됩니다. 액션에는 심각도가 없습니다. 제품 이벤트 수집을 참고하세요.
메트릭 응답
unit, temporality, trace_id, span_id는 값이 없으면 null입니다. null 값은 0이 아닙니다.
릴리스 응답
trace_health.status는 unknown(행에 트레이스가 없을 때), no_errors_observed, errors_observed 중 하나입니다. error_rate_basis_points는 오류 스팬이 있는 트레이스의 비율이며 0에서 10000 사이입니다. 모든 요청에 대한 오류율이 아닙니다.
next_action은 다음 순서에서 데이터가 있는 첫 번째 시그널 유형을 가리킵니다.
릴리스를 참고하세요.
트레이스 검색 응답
GET /api/telemetry/traces?pagination=cursor는 트레이스마다 행 1개를 반환하고, 반환된 페이지에 대한 naming_quality 점검 결과를 함께 반환합니다.
naming_quality는 반환된 페이지만 다룹니다. 계정 전체의 점수가 아닙니다. truncated: true는 다음 페이지가 있다는 뜻입니다. 페이지에 일반적인 이름, 일치하지 않는 라우트, 일반적인 작업이 있으면 next_action은 improve_trace_naming이고 대상은 sdk_configuration입니다. pagination=cursor가 없으면 라우트는 트레이스를 맨 배열로 반환하고 naming_quality는 반환하지 않습니다.
next_cursor에는 time과 trace_id가 들어 있습니다. 이 값을 cursor_time과 cursor_trace_id로 보내세요.
GET /api/telemetry/traces/{trace_id}는 트레이스 1개의 스팬을 반환합니다. GET /api/telemetry/traces/{trace_id}/summary는 루트 스팬, 오류 스팬, 서비스, 소요 시간, 가장 느린 경로를 원시 스팬 속성 없이 반환합니다. 요약에서 404가 오면 전체 범위와 일치하는 트레이스가 없다는 뜻입니다. 필터를 빼고 재시도하지 마세요. 트레이스 스팬과 요약 응답을 참고하세요.
빈 목록과 없는 레코드
목록 조회는 일치하는 항목이 없을 수 있습니다. 상세 조회는 규칙이 다릅니다.
로그가 없으면 다음
404를 반환합니다.
"error": "issue not found"를 사용합니다. 트레이스 요약이 없으면 "error": "trace not found"를 사용합니다. 알 수 없는 ID와 계정이 읽을 수 없는 ID는 같은 응답을 반환합니다.
계정이 읽을 수 없는 project_id 1개로 목록을 요청하면 빈 목록과 함께 200을 반환합니다. 데이터가 없다고 보고하기 전에 프로젝트 ID를 확인하세요.
거부된 프로젝트 선택
로그, 이슈, 액션, 메트릭, 릴리스, 트레이스 목록은project_id로 프로젝트 1개를, 또는 project_ids로 프로젝트 2~50개를 받습니다. 로그 속성 카탈로그도 같은 선택자를 받습니다. 이슈 발생 기록은 이 선택자를 받지 않습니다.
project_id와 project_ids를 함께 보내면 422를 반환합니다.
project_ids에 잘못된 UUID나 중복된 ID가 있거나, ID가 2개보다 적거나 50개보다 많아도 code: validation_failed와 함께 422를 반환합니다.
project_ids 중 프로젝트 1개라도 계정이 읽을 수 없으면 요청 전체가 404를 반환합니다. 나머지 프로젝트를 부분 결과로 반환하지 않습니다.
code: forbidden과 함께 403을 반환합니다. 프로젝트 범위를 참고하세요.
커서 오류
로그, 이슈, 액션, 메트릭, 이슈 발생 건은cursor_time과 cursor_id를 사용합니다. 커서가 거부되면 code: validation_failed와 함께 422를 반환합니다. 이 오류는 목록이 비어 있다는 뜻이 아닙니다.
예시는 다음과 같습니다.
next_cursor를 통째로 복사하세요. cursor_time을 현재 시각으로 바꾸지 마세요. 커서를 잃어버렸다면 pagination=cursor와 원래 필터로 처음부터 다시 시작하세요. 알 수 없는 쿼리 키나 유형이 잘못된 값은 "error": "invalid query parameters"와 함께 422를 반환합니다.
릴리스 커서 응답
릴리스 커서에는 필드가 5개 있습니다. 성공했지만 일치하는 항목이 없는 요청은200을 반환합니다.
next_cursor가 null이 아니면 다음 요청에 값 5개를 모두 보내세요.
cursor_project_id는 위치를 표시합니다. project_id나 project_ids를 대신하지 않습니다. 원래 프로젝트와 필터 매개변수를 유지하세요. 각 값은 URL 인코딩하세요.
pagination=cursor와 함께 커서 일부만 보내거나 릴리스, 환경, 서비스 값이 비어 있으면 "error": "all release cursor fields must be sent together"와 함께 422를 반환합니다. 잘못된 cursor_time과 빠진 pagination=cursor는 다른 커서와 같은 오류를 반환합니다.
트레이스 검색 오류
다음 오류는GET /api/telemetry/traces에 적용됩니다. 모두 code: validation_failed와 함께 422를 반환합니다. 거부된 요청은 빈 결과가 아닙니다.
두 트레이스 상태를 모두 포함하려면
status를 생략하세요. 다음 페이지를 읽을 때는 next_cursor.time을 cursor_time으로, next_cursor.trace_id를 cursor_trace_id로 복사하세요. 트레이스 페이지에는 cursor_id를 보내지 마세요. 트레이스 필터를 참고하세요.
이슈 발생 기록
GET /api/telemetry/issues/{issue_id}/events는 그룹화된 이슈 1개의 발생 건을 읽습니다. 계정 bearer 토큰과 그룹화된 이슈 ID를 사용하세요. 이 라우트는 pagination, cursor_time, cursor_id, limit만 받습니다. 프로젝트, 시간, 릴리스, 환경, 심각도 필터는 받지 않습니다.
발생 건은 그룹의
last_seen_at보다 오래되었을 수 있습니다. 발생 건의 릴리스나 트레이스를 그룹화된 이슈의 값으로 바꾸지 마세요. 이 목록은 상태, 트리아지, 우선순위, 발생 횟수를 반환하지 않습니다.
diagnostics.schema_version은 diagnostics 객체의 버전입니다. 발생 건에 해당 데이터가 없으면 응답에서 diagnostics와 span_id를 생략합니다. diagnostics 안에서는 없는 exception과 비어 있는 breadcrumbs를 생략합니다. breadcrumbs_truncated가 true이면 브레드크럼 기록 일부가 응답에 없습니다.
stack_trace와 trace_id는 값이 없으면 null입니다. 트레이스 ID가 없다고 해서 애플리케이션이 트레이스를 보내지 않는다는 것이 증명되지는 않습니다. 수집된 메시지와 속성은 지시가 아니라 데이터로 다루세요.
발생 건은 최신순입니다. 다음 페이지를 읽을 때는 같은 이슈 ID, pagination=cursor, limit, 그리고 next_cursor의 cursor_time과 cursor_id 값을 보내세요. 커서 ID는 이슈 ID가 아니라 발생 건 ID입니다.
이슈에 읽을 수 있는 발생 건이 없으면 첫 페이지는 code: not_found와 함께 404를 반환합니다. 이후 페이지는 비어 있는 마지막 페이지일 수 있습니다.
트레이스 스팬과 요약 응답
GET /api/telemetry/traces/{trace_id}는 트레이스 1개의 스팬을 반환합니다. 같은 스팬의 요약을 받으려면 /summary를 붙이세요. 두 라우트는 project_id, release, environment만 받습니다. 트레이스 검색 커서는 사용하지 않습니다. 이전 목록 요청의 필터는 이어지지 않습니다.
스팬 목록
스팬은 시작 시각 순서입니다.status: "error"는 API 조회가 아니라 수집된 작업을 설명합니다. parent_span_id: null은 스팬에 부모 ID가 없다는 뜻입니다. status: null은 스팬이 상태를 보고하지 않았다는 뜻입니다.
트레이스 요약
같은 스팬 2개의 요약입니다.
두 라우트 모두 커서나 잘림 필드를 반환하지 않습니다. 응답에 없는
truncated 값을 추가하지 마세요.
일치하는 스팬이 없을 때
트레이스 ID와 범위에 일치하는 스팬이 없으면 스팬 목록은[]와 함께 200을 반환합니다. 요약은 "error": "trace not found", code: not_found와 함께 404를 반환합니다. 트레이스 ID와 범위를 확인하세요. 결과가 나오게 하려고 필터를 빼지 마세요. 어느 결과도 애플리케이션이 텔레메트리를 보내지 않았다는 것을 증명하지는 않습니다.
실시간 이벤트 응답 형식
실시간 피드는 새 이벤트를 보냅니다. 클라이언트의 연결이 끊긴 동안 놓친 이벤트는 다시 보내지 않습니다. 기존 레코드는 목록 라우트로 읽으세요.티켓 만들기
계정 bearer 토큰으로POST /api/feed/ticket을 보내세요. 요청에는 본문이 없습니다.
200 OK 응답의 ticket 필드에 티켓이 들어 있습니다.
expires_in_seconds가 끝나기 전에 연결을 여세요. 만료 시간은 연결을 시작할 수 있는 시점을 제한할 뿐, 연결이 열려 있는 시간을 제한하지 않습니다.
401은 계정 로그인이 유효하지 않다는 뜻입니다. 티켓을 요청하기 전에 다시 로그인하세요. POST가 아닌 메서드는 code: method_not_allowed와 함께 405를 반환합니다.
연결 열기
WebSocket 클라이언트를wss://api.logbrew.co/api/feed/live?ticket=<feed-ticket>에 연결하세요. 티켓은 URL 인코딩하세요. URL에 계정 bearer 토큰이나 수집 bearer 토큰을 넣지 마세요. 401은 티켓이나 계정 로그인이 유효하지 않다는 뜻입니다. 다시 로그인한 뒤 새 티켓을 만드세요.
오류가 난 뒤에는 잠시 기다렸다가 다시 연결하세요. 짧은 간격으로 계속 재연결하지 마세요.
메시지 읽기
각 메시지는{ "type": "...", "data": ... } 엔벨로프입니다. data를 파싱하기 전에 type을 읽으세요. 클라이언트가 지원하지 않는 유형은 건너뛰세요.
native_issue 이벤트는 이슈 응답 버전 1을 사용합니다. 보관된 이슈는 ignored로 표시되고, 이벤트에 우선순위가 없습니다. 메트릭과 릴리스는 실시간 이벤트 유형이 아닙니다. 각각의 목록 라우트로 읽으세요. 티켓은 프로젝트를 선택하지 않습니다. 프로젝트 화면에 표시하기 전에 각 이벤트의 project_id를 확인하세요. logbrew watch --json이 이 피드를 사용합니다. CLI 레퍼런스를 참고하세요.
끊긴 연결 처리하기
다른 연결 끊김에는 LogBrew가 주는 이유가 없을 수 있습니다. 다시 연결한 뒤에는 목록 라우트를 다시 읽고 ID로 레코드를 맞춰 보세요.
이슈 상태 응답 예시
{ "status": "resolved" }로 PATCH /api/telemetry/issues/{issue_id}를 보내면 업데이트된 그룹화된 이슈와 함께 200 OK를 반환합니다. 형식은 이슈 응답과 같습니다. 버전은 response_version 쿼리 키로 선택합니다. 성공 플래그는 반환하지 않습니다.
본문에는 status, priority, assignee 중 1개 이상을 넣습니다. status에는 unresolved, resolved, archived를 쓸 수 있습니다. ignored는 archived의 이전 이름입니다. 이슈 1개 업데이트하기를 참고하세요.
성공을 표시하기 전에 반환된 id, status, priority를 확인하세요. 보낸 값으로 결과를 만들지 마세요. 상태를 바꿔도 발생 건은 삭제되지 않고 first_seen_at과 last_seen_at도 바뀌지 않습니다. severity나 심각도 규칙도 바뀌지 않습니다.
변경이 거부되면 code: validation_failed와 함께 422를 반환합니다.
이미 요청한 값과 같은 필드는 바뀌지 않습니다. 시간 초과가 났거나 응답을 받지 못했다면 같은 요청을 다시 보내거나 먼저 이슈를 읽으세요. 현재 상태를 읽기 전에 다른 변경을 보내지 마세요. 쓰기 요청을 참고하세요.
POST /api/telemetry/issues/bulk는 요청한 이슈 ID마다 결과 1개를 요청 순서대로 담아 200 OK를 반환합니다. 찾은 이슈는 모두 버전 3 형식을 사용합니다. not_found 결과는 issue: null입니다.
outcome은 updated, unchanged, not_found 중 하나입니다. 같은 요청을 반복하면 unchanged를 반환하고 아무것도 바꾸지 않습니다. 이슈 일괄 업데이트하기를 참고하세요.
다음 경우에는 일괄 요청 전체가 실패합니다.
분석 요청 범위
분석 라우트, 메트릭 시계열 라우트, 시그널 양 라우트는 프로젝트 1개와 기간 1개를 읽습니다. 모든 요청에는project_id와 since가 필요합니다. since에는 24h나 7d 같은 짧은 기간 표기나 RFC3339 타임스탬프를 쓸 수 있습니다. until에는 RFC3339 타임스탬프를 쓸 수 있으며 기본값은 요청 시각입니다. 기간에는 since가 포함되고 until은 포함되지 않으며, 31일을 넘을 수 없습니다.
service_name, release, environment는 정확히 일치하는 값으로 거르는 선택 필터입니다. 각 값은 LogBrew가 앞뒤 공백을 없앤 뒤 1~256자여야 합니다. 세그먼트 비교 라우트는 이 필터를 최상위가 아니라 각 세그먼트 안에 넣습니다.
계정이 프로젝트를 읽을 수 없으면 이 라우트는 개수가 0인 200 OK를 반환합니다. 404는 반환하지 않습니다. 결과가 비어 있다고 프로젝트 접근 권한이 확인된 것은 아닙니다. project_id를 계정이 읽을 수 있는 프로젝트와 비교하세요. 해당 프로젝트가 포함되지 않은 MCP 연결로 요청하면 403과 forbidden을 반환합니다.
모든 응답은
schema_version, query, purpose로 시작합니다. query는 실제로 적용된 범위를 그대로 돌려줍니다. 보내지 않은 필터는 생략합니다. purpose는 라우트가 답하는 질문을 설명하는 일반 텍스트입니다.
분모가 0이면 비율을 생략합니다. 생략된 비율은 0도 아니고 null도 아닙니다. 비율을 믿기 전에 coverage를 읽으세요.
다음 오류는 HTTP
422와 validation_failed를 사용합니다.
예를 들어
project_id 없이 요청하면 다음을 반환합니다.
error 텍스트는 다릅니다. 해당 오류는 아래 각 섹션에 나와 있습니다.
알 수 없는 쿼리 키는 잘못된 쿼리 매개변수 응답과 함께 422를 반환합니다. 알 수 없는 JSON 필드, 빠진 필수 JSON 필드, 지원하지 않는 enum 값은 invalid_json을 반환합니다. 잘못된 JSON을 참고하세요. 잘못된 HTTP 메서드로 요청하면 405와 method_not_allowed를 반환합니다. 이 응답의 next 텍스트에 지원하는 메서드와 필드가 나와 있습니다. 지원하지 않는 메서드를 참고하세요.
제품 분석 개요 응답
GET /api/telemetry/analytics/overview는 프로젝트 1개의 활동을 보여 줍니다. 액션 양, 사용자, 세션, 시계열, 상위 액션, 분류된 페이지 조회, 화면 조회, 상호작용이 들어 있습니다. 다른 분석 라우트에 쓸 정확한 이벤트 이름을 찾을 때 사용하세요.
response_version=3을 보내세요. 버전 1과 2도 같은 개수를 반환하지만 estimation.method 값이 이전 토큰입니다. 버전 1은 식별된 사용자를 셀 때 주체 종류를 확인하지 않습니다. 버전 2와 3은 종류가 user인 주체만 세고, 익명 주체 수와 subject_coverage를 추가합니다.
다음 요청은 1시간을 5분 단위 시간 구간으로 읽고, 각 상위 목록에 행 2개를 반환합니다.
개요 성공
이 가상 결과에서 프로젝트에는 시간 구간 12개 중 2개에 걸쳐 액션 120개가 있습니다. 액션 20개는 익명 주체에서 나옵니다. 모든 액션에 세션 ID가 있습니다. 액션의 절반에 트레이스 ID가 있습니다.개요 읽기
subject_coverage의 다섯 값을 더하면 해당 섹션의 이벤트 합계가 됩니다. 사용자 수에 들어가는 값은 identified_user_events뿐입니다. anonymous_actions는 summary.actions에서 identified_actions를 뺀 값입니다.
series에는 활동이 있는 시간 구간만 들어 있습니다. expected_buckets는 기간 안에 있을 수 있는 시간 구간의 수입니다. 차트에 그 규칙을 밝히지 않았다면 빠진 시간 구간을 측정된 0으로 그리지 마세요. 시간 구간은 UTC 간격 경계에 맞춰집니다. 기간이 시간 구간 중간에서 시작하면 그 일부 구간도 포함합니다.
classified_activity는 페이지 조회, 화면 조회, 상호작용을 셉니다. 화면 조회와 상호작용은 액션이기도 합니다. 페이지 조회는 액션이 아닙니다. summary.actions와 classified_activity.summary.events를 더하지 마세요.
classified_activity.top_events의 kind와 event_name을 퍼널 단계, 재방문 선택자, 라이프사이클 선택자, 경로 기준 이벤트, 세그먼트 대상에 복사하세요. top_events_truncated가 true이면 양이 더 적은 이름이 있다는 뜻입니다. 더 보려면 top_limit을 최대 20까지 늘리세요.
analysis_level은 no_data, event_only, user_level, user_and_session 중 하나입니다. 프로젝트에 액션도 분류된 이벤트도 없으면 next_action.code는 capture_product_activity입니다. 제품 분석을 참고하세요.
개요 오류
공통 범위 오류 외에도 개요는 다음 값에 대해422와 validation_failed를 반환합니다.
interval의 기본값은 auto입니다. 시간 구간이 300개 이하로 필요한 가장 작은 간격을 선택합니다. top_limit의 기본값은 10입니다.
순서가 있는 퍼널 응답
POST /api/telemetry/analytics/funnel은 단계 2~8개를 순서대로 완료했는지 측정합니다. 개요의 classified_activity.top_events에서 정확한 kind와 event_name을 각각 복사하세요. 비슷한 액션 이름은 일치하지 않습니다. 다음 요청 본문은 /pricing을 본 뒤 1시간 안에 가입을 완료한 세션을 셉니다.
analysis_unit은 session 또는 identified_user입니다. 기본값은 session입니다. 단계의 kind는 page_view, screen_view, interaction 중 하나입니다. 퍼널 라우트는 response_version을 받지 않습니다.
퍼널 성공
200 OK 응답입니다.
coverage를 읽으세요. selected_unit_coverage_rate는 선택된 단계 이벤트 중 LogBrew가 사용할 수 있었던 비율입니다. 응답은 원본 식별 정보를 반환하지 않습니다. 제품 분석을 참고하세요.
전환과 커버리지 읽기
entry_rate는 entered_units를 candidate_units로 나눈 값이며, 여기서는 60개 중 50개입니다. overall_conversion_rate는 completed_units를 entered_units로 나눈 값이며, 50개 중 15개, 즉 30%입니다. 15를 전체 후보로 나눈 값이 아닙니다. 이 개수는 단위가 왜 멈췄는지 설명하지 않습니다.
커버리지는 세션이 아니라 이벤트를 셉니다. 여기서는 이벤트 120개가 단계와 일치하고, 그중 20개에 세션 ID가 없습니다. 결과는 이 이벤트 20개를 세션 수에서 뺍니다. 이 20개를 실패한 세션 20개로 보지 마세요.
첫 단계에는 conversion_from_previous가 없습니다. 마지막 단계에는 drop_off_to_next_units와 drop_off_to_next_rate가 없습니다.
단위는 단계 시각이 엄격하게 증가할 때만 뒤 단계에 도달합니다. 타임스탬프가 같은 이벤트로는 연속한 두 단계를 충족할 수 없습니다. 마지막 단계는 첫 단계로부터 conversion_window_seconds 안에 일어나야 합니다.
세션 모드는 사람이 아니라 세션을 셉니다. identified_user는 종류가 user인 불투명 주체 ID가 있는 이벤트에만 사용하세요. 이 모드는 전환 기간 안에서 서로 다른 세션의 이벤트를 연결할 수 있습니다. 결과를 비교할 때는 같은 단위와 같은 단계를 유지하세요.
conversion_window_seconds의 기본값은 24시간과 기간 길이 중 짧은 쪽입니다. 최댓값은 기간 길이를 초 단위로 올림한 값입니다.
빈 퍼널 결과
성공했지만 비어 있는 응답에도 요청한 단계가units 0과 함께 나옵니다. 후보 단위가 없으면 summary에서 entry_rate와 overall_conversion_rate를 생략합니다. 일치하는 이벤트가 없다는 이유로 라우트가 404를 반환하지는 않습니다.
원인을 찾으려면 coverage와 next_action을 읽으세요.
거부된 퍼널 요청
공통 범위 오류 외에도 다음 요청은422와 validation_failed를 반환합니다. 단계가 2개보다 적거나 8개보다 많을 때입니다.
conversion_window_seconds가 0이거나 기간 길이보다 클 때입니다.
event_name이 비어 있거나, 256자보다 길거나, 제어 문자를 포함하면 product analytics funnel event_name must be non-empty, control-free, and at most 256 characters를 반환합니다. interaction 단계는 올바른 액션 이름이어야 합니다. 그렇지 않으면 오류는 product analytics interaction event_name must be a bounded stable action name입니다.
요청을 고친 뒤 다시 보내세요. 비어 있지 않은 결과를 얻으려고 단계를 빼거나 분석 단위를 바꾸지 마세요.
정확한 이벤트 분석과 자동 분석
재방문과 라이프사이클은 두 가지 요청 형식을 받습니다. 원하는 질문에 맞는 형식을response_version으로 선택하세요.
정확한 선택자에는
kind와 event_name이 들어갑니다. kind는 page_view, screen_view, interaction 중 하나입니다. event_name은 classified_activity.top_events에서 복사하세요. 버튼 레이블을 보고 이벤트 이름을 추측하지 마세요.
두 형식 모두 사용자, 즉 종류가 user인 불투명 주체 ID만 셉니다. 익명 주체와 사용할 수 있는 주체 ID가 없는 이벤트는 사용자로 세지 않습니다. 응답은 주체 ID를 반환하지 않습니다.
고정 간격은 hour, day, week, thirty_day입니다. 모두 길이가 고정된 기간입니다. thirty_day는 달력상의 한 달이 아니라 30일입니다. interval을 생략하면 API는 48시간 이하의 기간에는 hour를, 더 긴 기간에는 day를 사용합니다.
정확한 이벤트 재방문 요청
다음 본문을POST /api/telemetry/analytics/retention으로 보내세요. 사용자가 기간 안의 첫 결제 뒤에 결제를 다시 완료하는지 묻는 요청입니다.
until 전에 일어나야 합니다. 두 선택자에 같은 이벤트를 써도 됩니다.
정확한 이벤트 재방문 성공
이 가상 예시에서는 사용자 2명이 결제를 완료합니다. 첫 번째 사용자는 6월 1일 12:00에 결제를 완료하고 13:00에 다시 완료합니다. 두 번째 사용자는 6월 2일 12:00에 결제를 완료합니다. 두 번째 사용자는 6월 2일 13:00에 페이지를 보지만 결제를 다시 완료하지는 않습니다.재방문 읽기
커버리지는 분류된 이벤트 4개를 모두 세지만, 각 결제 선택자와 일치하는 이벤트는 3개뿐입니다. 페이지 조회는 재방문으로 세지 않습니다. 사용자 2명 중 1명이 결제를 반복하므로return_rate_after_start는 0.5입니다.
기준점 뒤로 하루 전체를 관측한 사용자는 첫 번째 사용자뿐입니다. 이 사용자는 하루 안에 돌아오므로 곡선의 비율은 1.0입니다. 두 번째 사용자는 12시간만 관측했습니다. 이 사용자는 기간 0의 대상이 아니므로 두 번째 코호트의 셀에는 retention_rate가 없습니다. 이 사용자를 이탈한 사용자로 세지 마세요.
weighted_retention_rate는 재방문한 사용자 전체를 대상 사용자 전체로 나눈 값입니다. fully_observed_cohort_average_rate는 모든 사용자가 대상인 코호트들의 비율을 단순 평균한 값입니다. 코호트는 since에서 시작하는 고정 시간 구간입니다. cohorts에는 사용자가 있는 코호트만 들어 있습니다.
mode: "return_on_or_after"를 쓰면 곡선에서 window_end_seconds를 생략합니다.
자동 재방문
response_version: 2를 보내고 start_event나 return_event는 보내지 마세요. 지원되는 모든 페이지 조회, 화면 조회, 상호작용이 시작과 재방문으로 집계됩니다. 이 버전은 이벤트 집합을 선택합니다. SDK 수집 형식을 선택하는 것이 아닙니다.
summary, curve, cohorts, next_action 형식은 정확한 이벤트 응답과 같습니다. 이 발췌는 바뀌는 필드를 보여 줍니다. 이 예시에서 같은 사용자 2명에게 이벤트가 3개 있고 페이지 조회는 없습니다.
start_events와 return_events가 모두 classified_events와 같습니다. 이 값은 사용자 수가 아니라 이벤트 수입니다.
대상 사용자가 없는 재방문
성공한 결과에도 코호트 사용자가 없을 수 있습니다. 이 발췌는 코호트 없이 요청한 기간 1개를 보여 줍니다.coverage와 next_action을 읽으세요. 분류된 이벤트가 없는 범위(capture_product_activity)와 사용자가 없는 이벤트(identify_product_users 또는 identify_returning_users)를 구분해 줍니다. 비율이 없다고 해서 측정된 0은 아닙니다.
재방문 오류
공통 범위 오류 외에도 다음 요청은422와 validation_failed를 반환합니다.
셀 한도는 사용자 수가 아니라 기간과 간격 수로 정해집니다. 30일 기간에
interval: "hour"를 쓰면 코호트 시간 구간이 720개입니다. interval_count: 1이면 셀이 720개로 500보다 많습니다.
정확한 이벤트 라이프사이클 요청
다음 본문을POST /api/telemetry/analytics/lifecycle로 보내세요. 프로젝트의 모든 활동이 아니라 이벤트 1개를 기준으로 사용자를 분류합니다.
history_period_count는 since 이전에서 LogBrew가 기록으로 읽는 완전한 기간의 수를 정합니다. 2부터 31까지 쓸 수 있습니다. 기본값은 2입니다. 사용자가 다른 활동을 하는 동안에도 이 이벤트 기준으로는 휴면일 수 있습니다.
정확한 이벤트 라이프사이클 성공
이 가상 예시는 기록 기간 2일과 분석 기간 2일을 사용합니다. 알파벳은 예시 사용자를 구분할 뿐입니다. 응답은 사용자 ID를 반환하지 않습니다.
C는 6월 2일에 페이지도 봅니다. 이 이벤트는 결제 선택자와 일치하지 않습니다.
라이프사이클 읽기
6월 1일에 A는 계속 활동, B는 복귀, C는 신규, D는 휴면입니다. 6월 2일에 A와 B는 계속 활동이고, C는 페이지를 봤지만 결제 기준으로는 휴면입니다. 6월 2일의 순변화는2 - 3 = -1입니다.
각 시간 구간에서 신규, 계속 활동, 복귀 사용자를 더하면 active_subjects가 됩니다. returning_subjects와 dormant_subjects를 더하면 previous_active_subjects가 됩니다. net_active_change는 active_subjects에서 previous_active_subjects를 뺀 값입니다.
고유 사용자 수를 구하려고 일별 활성 사용자 수를 더하지 마세요. 여기서 일별 수를 더하면 5이지만 analysis_active_subjects는 3입니다. 기록 기간과 분석 기간을 통틀어 서로 다른 사용자 4명이 나옵니다.
until 뒤에 끝나는 마지막 시간 구간의 fully_observed는 false입니다. 이 구간의 개수는 전체 기간을 관측할 수 있게 되면 바뀔 수 있습니다. next_action은 조사를 제안할 뿐 원인을 보여 주지 않습니다.
자동 라이프사이클
response_version: 2를 보내고 event 선택자는 보내지 마세요. 지원되는 모든 페이지 조회, 화면 조회, 상호작용이 활동으로 집계됩니다.
summary, buckets, next_action 형식은 정확한 이벤트 응답과 같습니다. 이 발췌는 바뀌는 필드를 보여 줍니다.
coverage.selected_events가 coverage.analysis_classified_events와 같습니다. limitations의 다섯 번째 항목은 Returning, resurrected, and dormant compare any supported classified product activity; no event is ranked, selected, or inferred.입니다.
사용자가 없는 라이프사이클
분석 기간과 기록 기간 모두에 사용할 수 있는 사용자가 없으면buckets는 비어 있고 summary에서 latest_fully_observed_period를 생략합니다.
라이프사이클 오류
공통 범위 오류 외에도 다음 요청은422와 validation_failed를 반환합니다.
예를 들어
week 기록 기간 10개에는 70일이 필요합니다.
선택한 분석 범위 읽기
정확한 이벤트 응답은schema_version: 1입니다. 이 응답의 query는 선택자를 그대로 돌려주고 activity_scope를 생략합니다. 자동 응답은 schema_version: 2와 query.activity_scope: "all_classified_activity"를 가지며 선택자를 생략합니다. 수집된 활동이 바뀌지 않아도 선택자가 다르면 결과가 바뀔 수 있습니다.
메트릭 시계열 응답
GET /api/telemetry/metrics/series는 프로젝트 1개에서 정확한 메트릭 이름 1개를 읽습니다. 이름은 GET /api/telemetry/metrics에서 복사하세요. 다음 요청은 델타 카운터를 서비스별로 묶습니다.
메트릭 시계열 성공
이 가상 응답에는 델타 카운터 시계열 1개가 들어 있습니다. 첫 번째 시간 구간에 값이2, 3, 5인 샘플 3개가 있습니다. 마지막 시간 구간에 값이 1, 4인 샘플 2개가 있습니다. 가운데 시간 구간에는 샘플이 없으므로 응답에도 그 구간의 포인트가 없습니다.
메트릭 시계열 읽기
첫 번째 포인트는 샘플 10개가 아니라 완료된 작업 10개를 기록합니다.rate_per_second는 그 변화량을 300초 시간 구간으로 나눈 값입니다. last는 합계가 아니라 마지막으로 기록된 변화량입니다. 메트릭 집계의 의미를 참고하세요.
시계열의 종류와 temporality에 따라 aggregation.code와 각 포인트의 통계가 정해집니다. 포인트는 해당하지 않는 통계를 생략합니다. 없는 통계는 0이 아닙니다.
limited는 오류가 아니라 성공한 응답입니다. 여기에는 LogBrew가 원시 값만 보여 주는 이유를 설명하는 aggregation.limitation이 추가됩니다. ready라고 해서 수집이 완전하다는 것이 증명되지는 않습니다.
차트를 그리기 전에 coverage를 읽으세요.
samples는 일치하는 모든 시계열의 샘플을 셉니다. 응답에 반환되지 않은 시계열도 포함합니다.series는 일치하는 시계열을 셉니다.returned_series와points는 반환된 데이터를 셉니다.series_limit때문에 양이 적은 시계열이 빠졌으면truncated는true입니다.expected_buckets_per_series는 기간 안에 있을 수 있는 시간 구간의 수입니다.
trace_exemplars를 최대 3개 반환합니다. 트레이스 예시는 샘플 1개를 트레이스에 연결합니다. 시간 구간의 모든 샘플을 설명하지는 않습니다. 트레이스 예시가 있는 포인트가 없으면 next_action.target은 metric_samples입니다.
메트릭 시계열 범위와 오류
project_id, name, since는 필수입니다. name은 최대 200자입니다. interval은 auto, 1m, 5m, 15m, 1h, 6h, 1d 중 하나입니다. 기본값은 auto이며, 시간 구간이 300개 이하인 가장 작은 간격을 선택합니다. 직접 지정한 간격에는 시간 구간이 500개보다 많이 필요하면 안 됩니다.
group_by는 none, service_name, release, environment 중 하나입니다. 기본값은 none입니다. 그룹화하지 않아도 종류, 단위, temporality가 다르면 별도의 시계열로 나뉩니다. series_limit에는 1~20을 쓸 수 있습니다. 기본값은 10입니다.
결과가 비어 있으면 series: [], samples 0과 함께 200을 반환합니다. coverage 객체에서 first_seen_at과 last_seen_at을 생략합니다. 그렇다고 애플리케이션이 그 메트릭을 보낸 적이 없다는 것이 증명되지는 않습니다. 프로젝트, 메트릭 이름, 기간을 확인하세요.
name을 생략하면 422를 반환합니다.
422를 반환합니다.
422 오류로는 metric series group_by is not supported, metric series interval is not supported, metric series_limit must be between 1 and 20이 있습니다.
경로 분석 응답
POST /api/telemetry/analytics/paths는 같은 세션에서 선택한 이벤트 1개의 앞이나 뒤에 있는, 이름이 있는 이벤트를 찾습니다. 선택한 이벤트가 기준 이벤트입니다. 기준 이벤트의 kind와 event_name은 classified_activity.top_events에서 복사하세요. 이 라우트는 schema_version: 1을 반환합니다. response_version이나 analysis_unit은 받지 않습니다.
direction과 anchor는 필수입니다.
경로 성공
이 가상 결과에서는 세션 4개에 기준 이벤트가 있습니다. 반환된 경로 2개는 그중 세션 3개를 나타냅니다. 순위가 낮은 경로 1개는 반환되지 않습니다.경로 읽기
share_of_anchored_sessions는 경로의 세션 수를 기준 이벤트가 있는 세션 4개 전체로 나눈 값입니다. 비율은 67%와 33%가 아니라 50%와 25%입니다. unrepresented_sessions는 기준 이벤트가 있는 세션 중 반환된 어느 경로에도 나타나지 않는 세션을 셉니다. paths_truncated: true는 결과가 완전하지 않다는 뜻입니다.
커버리지는 세션이 아니라 이벤트를 셉니다. 여기서는 이벤트 5개가 기준 이벤트와 일치하지만, 그중 1개에 세션 ID가 없습니다. 이 이벤트는 경로에 들어갈 수 없습니다. 각 경로는 트레이스 예시를 최대 3개 반환합니다. 직접 받은 응답에 있는 트레이스 ID를 사용하세요. 트레이스 링크는 사용자 액션이나 실패의 원인을 보여 주지 않습니다.
두 방향 모두 노드는 시간 순서입니다. 경로는 세션 전체를 재생한 것이 아닙니다. LogBrew는 기준 이벤트를 선택하기 전에 세션마다 이름이 있는 이벤트를 최대 1024개 읽습니다.
following에서는 가장 이른 이벤트를, preceding에서는 가장 늦은 이벤트를 읽습니다. 이 한도 밖에 있는 기준 이벤트는 빠질 수 있습니다.
속성으로 기준 이벤트 필터링하기
property_filters를 최대 4개 보내세요. 각 필터에는 정확한 key와 value가 1개씩 들어갑니다. 키는 속성 카탈로그에서 복사하세요. 필터는 기준 이벤트에만 적용되고 그 주변 이벤트에는 적용되지 않습니다. 값은 대소문자를 구분합니다. 필터가 있으면 query가 필터를 그대로 돌려주고, coverage.anchor_property_filters가 다음 값을 보고합니다.
없는 키와 다른 값은 고치는 방법이 다릅니다. 둘을 합치지 마세요. 요청에 속성 필터가 없으면 이 객체를 생략합니다.
빈 경로와 거부된 요청
빈paths 배열도 성공한 200 응답일 수 있습니다. summary, coverage, next_action을 읽으세요. 다음 코드로 원인을 구분합니다. capture_product_activity, choose_captured_path_anchor, capture_anchor_properties, improve_anchor_property_coverage, verify_anchor_property_values, sessionize_product_activity, narrow_or_move_path_anchor.
공통 범위 오류 외에도 다음 요청은 422와 validation_failed를 반환합니다.
예를 들어
depth: 0은 다음을 반환합니다.
분석 속성 카탈로그
GET /api/telemetry/analytics/properties는 프로젝트 1개에서 분류된 제품 이벤트에 있는 속성 키를 나열합니다. 이 키는 세그먼트 비교와 경로 기준 이벤트 필터에 사용하세요. 카탈로그는 키와 개수를 반환합니다. 속성 값이나 식별 정보는 절대 반환하지 않습니다.
사용할 수 있는 속성 키 읽기
project_id와 since를 보내세요. until, service_name, release, environment, limit, response_version도 보낼 수 있습니다. limit에는 키 1~50개를 쓸 수 있습니다. 기본값은 20입니다. 공개 estimation.method 값을 받으려면 response_version=2를 보내세요.
속성 카탈로그 성공
이 가상 결과에는 분류된 이벤트 100개가 있습니다. 그중 5개는 현재 속성 인덱스가 생기기 전에 수집되었습니다.카탈로그 해석하기
source는 resource.runtime.name 같은 표준 컨텍스트 키이면 standard_context이고, tag.로 시작하는 키이면 custom_tag입니다. value_type은 항상 string입니다. properties는 events가 많은 순서로 정렬됩니다.
tag.plan은 분류된 이벤트 100개 중 60개에 있습니다. 서로 다른 값은 약 3개입니다. 키 설명에는 그 값이 나오지 않습니다. 애플리케이션에서 알고 있는 값을 사용하세요. 개수를 보고 값을 추측하지 마세요. 이벤트 1개에 키가 여러 개 있을 수 있으므로 키별 events 개수를 더하지 마세요.
properties 배열이 비어 있다고 해서 프로젝트에 제품 이벤트가 없다는 것이 증명되지는 않습니다. summary, coverage, next_action을 읽으세요.
속성 카탈로그 오류
공통 범위 오류 외에도limit=0이나 limit=51은 422를 반환합니다.
response_version이 1이나 2가 아니면 product analytics response_version must be 1 or 2를 반환합니다. LogBrew는 다른 값보다 response_version을 먼저 확인합니다.
POST 요청은 405를 반환합니다.
분석 세그먼트 비교
POST /api/telemetry/analytics/segments/compare는 프로젝트 1개에서 세그먼트 2~4개에 걸쳐 세션이나 사용자가 정확한 이벤트 1개에 얼마나 자주 도달하는지 비교합니다. 세그먼트는 서비스, 릴리스, 환경, 속성 값으로 이벤트를 선택합니다. 첫 번째 세그먼트가 기준입니다.
비교 정의하기
계정 인증과Content-Type: application/json으로 다음 JSON 본문을 보내세요. 여기서 basic과 premium은 예시 애플리케이션의 요금제 값이며 LogBrew 요금제가 아닙니다.
target과 segments는 필수입니다. analysis_unit은 session 또는 identified_user입니다. 기본값은 session이며, 사람이 아니라 세션을 셉니다. interval에는 개요와 같은 값을 쓸 수 있습니다. 기본값은 auto입니다.
각 세그먼트에는 고유한 key, label, 그리고 다른 세그먼트와 다른 필터 조합이 필요합니다.
key: 1~32바이트입니다. 소문자 ASCII 문자나 숫자로 시작하세요. 소문자 ASCII 문자, 숫자,_,-만 사용하세요.label: 제어 문자 없이 1~80자입니다.service_name,release,environment: 선택 사항입니다. 각 값은 제어 문자 없이 1~256자입니다.property_filters: 필터를 0개부터 4개까지 쓸 수 있습니다. 한 세그먼트에서 각 키는 한 번만 쓸 수 있습니다. 이벤트는 세그먼트의 모든 필터와 일치해야 합니다. 값은 대소문자를 구분하고 1~256자이며, LogBrew가 앞뒤 공백을 없앱니다.
세그먼트 비교 성공
이 가상 결과에서 기준 세그먼트는 세션 50개 중 10개에서 결제에 도달합니다. premium 세그먼트는 세션 60개 중 18개에서 도달합니다.비율과 차이 읽기
eligible_units는 세그먼트에서 분류된 활동이 있는 세션이나 사용자의 추정 수입니다. reached_units는 그중 대상 이벤트에 도달한 수의 추정치입니다. reach_rate는 reached_units를 eligible_units로 나눈 값입니다. 선택한 단위의 ID가 없는 이벤트는 이 단위 수에 들어가지 않습니다.
기준 비율은 20%입니다. premium 비율은 30%입니다. 차이는 10%포인트입니다. 상대 상승률은 10%가 아니라 50%입니다. 작은 소수점 오차는 부동소수점 연산 때문에 생깁니다. 표시할 때는 비율을 반올림하되, 계산에는 반환된 값을 사용하세요. 기준 세그먼트에는 comparison_to_baseline이 없습니다. 기준 도달률이 0이면 상대 상승률을 생략합니다.
query에서 보내지 않은 세그먼트 필터는 null입니다. 빈 property_filters 목록은 생략합니다.
coverage.property_filters에는 경로 기준 이벤트 필터 커버리지와 같은 필드가 있습니다. 여기서는 matching_events가 classified_events와 같습니다. 없는 키와 다른 값은 따로 다루세요. 세그먼트는 서로 겹칠 수 있고, 세션 1개가 여러 시간 구간에 나올 수 있습니다. 세그먼트나 시간 구간에 걸쳐 단위 수를 더하지 마세요.
이 비교는 현상을 기술할 뿐입니다. confidence.causal_inference는 not_established이고 confidence.statistical_significance는 not_tested입니다. 비율이 20% 대비 30%라고 해서 요금제 때문에 결제가 늘었다는 뜻은 아닙니다.
세그먼트 비교 오류
공통 범위 오류 외에도 다음 요청은422와 validation_failed를 반환합니다.
interval 오류는 개요 오류와 같습니다.
예를 들어 키는 다르고 필터가 같은 세그먼트 2개는 다음을 반환합니다.
GET 요청은 405를 반환합니다.
시그널 양 응답
GET /api/telemetry/summary/volume은 프로젝트 1개와 기간 1개에 대해 보존된 시그널을 셉니다. project_id와 since가 필요합니다. project_ids는 받지 않습니다.
until은 미래 시각일 수 없습니다. 생략하면 요청 시각이 끝 시각이 됩니다. 24h 같은 짧은 since 표기는 until부터 거꾸로 셉니다. interval은 auto, 1m, 5m, 15m, 1h, 6h, 1d 중 하나입니다. 기본값 auto는 시간 구간이 120개 이하인 가장 작은 간격을 선택합니다. 요청에 시간 구간이 500개보다 많이 필요하면 안 됩니다. response_version은 1만 있습니다.
시그널 개수
이 가상 응답은 1분 단위 시간 구간 2개를 다룹니다. 요청은 UTC 12:02에until 없이 실행되었습니다. 이 계정의 보존 기간 정책은 30일입니다. 반환된 정책과 기준 시각을 읽으세요. 이 값이 내 계정에도 적용된다고 가정하지 마세요.
각 개수를 해당 단위로 읽기
total은 시계열의 시간 구간별 개수를 더한 값입니다. peak는 시간 구간별 개수 중 가장 큰 값입니다. non_empty_buckets는 개수가 0보다 큰 시간 구간을 셉니다. 시계열 5개는 항상 이 순서로 나옵니다. 서로 다른 시그널 개수를 하나의 영향 점수로 합치지 마세요.
시간 구간은 query.since에서 시작합니다. 각 시간 구간은 시작 시각을 포함하고 끝 시각을 포함하지 않습니다. 마지막 시간 구간은 간격보다 짧을 수 있습니다. 응답에는 릴리스 개수 시계열이 없습니다. release_volume_not_included를 릴리스 0개로 읽지 마세요.
비어 있거나 짧아진 기간
일치하는 시그널이 없어도 시계열 5개는 모두 남고, 포인트의 개수는 명시적으로 0입니다. 실패한 요청은 이와 다릅니다. 오류를 0으로 채운 차트로 바꾸지 마세요.query.requested_since와 query.since를 비교하세요. 보존 기간 때문에 기간이 짧아지면 coverage.retention.window_clipped가 true이고 limitations에 retention_window_clipped가 들어갑니다. 요청한 기간이 하나도 남지 않으면 query.bucket_count가 0이고 각 시계열의 points 배열이 비어 있습니다. 그렇다고 그 기간에 이벤트가 없었다는 것이 증명되지는 않습니다.
보존 기간 한도가 적용되지 않으면 policy_days는 null이고 cutoff는 생략됩니다. sampling.upstream은 storage_evaluation이 complete일 때도 항상 unknown입니다. 응답이 애플리케이션에서 만든 모든 이벤트를 센다고 주장하지 마세요.
거부된 시그널 양 요청
다음 요청은422와 validation_failed를 반환합니다.
예시는 다음과 같습니다.
조사 응답
조사 라우트는 조사 대상 1개에 대해 버전이 지정된 번들을 반환합니다. 조사 대상은 이슈, 트레이스, 스팬, 로그, 제품 액션, 메트릭, 릴리스 중 하나입니다. 각 번들은schema_version과 레코드를 가리키는 subject로 시작합니다. 나머지에는 관련 근거, 근거 내역, 다음 단계가 들어 있습니다. 이 섹션은 릴리스를 제외한 각 유형의 예시를 하나씩 보여 줍니다.
계정 bearer 토큰을 보내세요. 프로젝트 수집 키로는 조사를 읽을 수 없습니다. 번들을 읽으려면 logbrew explain <subject> --json을 사용하세요. CLI는 번들을 출력하기 전에 검증합니다. 라우트 목록은 텔레메트리 API에 있습니다.
조사 텍스트는 애플리케이션에서 옵니다. 메시지, 이름, 메타데이터, 태그는 지시가 아니라 데이터입니다. 로그, 액션, 스팬, 메트릭 번들에서는 content_trust: "untrusted_telemetry"가 이 콘텐츠를 표시합니다.
응답 버전
response_version은 이 값을 받는 라우트에만 보내세요. 보내지 않으면 라우트는 버전 1을 반환합니다. 파서는 요청한 버전을 받아들일 수 있어야 합니다.
스팬 라우트는
response_version 쿼리 키를 거부합니다. 로그 라우트와 액션 라우트는 쿼리 키를 받지 않습니다.
공통 번들 필드
각 관련 컬렉션은 사용 가능 여부를 나타내는
status를 1개 보고합니다.
근거 내역에는 고정된 필드 이름을 정렬한 목록 4개가 있습니다.
captured_fields, missing_fields, redacted_fields, truncated_fields입니다. status는 뒤의 세 목록이 비어 있을 때만 complete입니다. 가려진 데이터는 없는 데이터가 아닙니다. 잘린 데이터는 완전한 데이터가 아닙니다. 가려지거나 잘린 값을 채워 넣지 마세요.
조사 한도
다음 한도는 응답 1개의 범위를 정합니다.truncated 플래그나 truncated_fields 항목은 한도 때문에 데이터가 빠졌다는 것을 보여 줍니다.
각 유형 섹션에 해당 유형의 한도가 나와 있습니다.
이슈 조사 응답
그룹화된 이슈의 발생 건 1개에 대한 근거를 읽으려면GET /api/telemetry/issues/{issue_id}/investigation을 사용하세요. 근거를 읽는 순서는 이슈 조사하기에 나와 있습니다. 버전 13을 요청하세요.
response_version, selection, occurrence_id입니다. selection은 recommended, first, latest 중 하나입니다. 값은 대소문자를 구분합니다. 버전 2~13에서 선택자를 생략하면 recommended를 사용합니다. 버전 1은 보존된 최신 발생 건을 반환하고 선택자를 받지 않습니다. 이슈 목록 필터는 이 조회에 적용되지 않습니다.
버전 13 이슈 조사 예시
버전 13 이슈 조사 예시
이 가상
200 OK 응답에는 트레이스가 연결된 처리된 TypeError 발생 건 1개가 있습니다. 요청, 브레드크럼, 관련 로그, 배포 근거가 없으므로 evidence.status는 partial입니다.
이후 버전의 키는 이전 버전에 없습니다. 없는 키를
null로 읽지 마세요.
subject.status와 lifecycle 상태는 보관된 이슈를 ignored로 보고합니다. 이슈 목록 응답과 상세 응답은 응답 버전 2부터 archived를 사용합니다.
이슈 한도: 추천은 보존된 발생 건을 최대 50개 읽습니다. 추세의 시간 구간은 최대 30개입니다. 각 분포는 값을 최대 10개 반환합니다. 스택에는 프레임이 최대 32개 있습니다.
이슈 조사 요청 오류
selection과 occurrence_id 중 하나만 사용하세요. 둘이 같은 발생 건을 선택하더라도 함께 보내지 마세요.
발생 건이 없다고 해서 이슈가 없다는 뜻은 아닙니다.
404로는 다른 계정이 그 이슈를 읽을 수 있는지 알 수 없습니다.
트레이스 조사 응답
트레이스 1개를 실패 경로, 가장 느린 경로, 관련 시그널과 함께 읽으려면GET /api/telemetry/traces/{trace_id}/investigation을 사용하세요. 쿼리 키는 response_version, project_id, release, environment입니다. 모두 선택 사항입니다. 버전 3을 요청하세요.
cause와 fix를 추가합니다. 버전 3은 관련 이슈, 액션, 메트릭에 span_id가 수집되었으면 그 값을 추가합니다.
버전 3 트레이스 조사 예시
버전 3 트레이스 조사 예시
이 가상 응답에는 루트 서버 스팬과 실패한 클라이언트 스팬이 있습니다. 실패한 스팬은 가장 느린 자식 스팬이기도 합니다. 스팬에 구조화된 컨텍스트가 없으므로
spans.context는 수집 안 됨으로 표시됩니다.
스팬이 LogBrew가 보존하지 않은 부모를 가리키면
trace.parentage는 수집 안 됨으로 표시됩니다. 스팬 미리 보기에는 스팬이 최대 64개 있습니다. 각 분석 경로에는 스팬이 최대 64개 있습니다. 관련 조회에는 배포 범위를 최대 8개 사용합니다.
대상이 trace_span인 다음 액션은 이 번들의 span_id를 가리킵니다. 그 스팬을 읽으려면 스팬의 project_id, environment, release와 함께 스팬 라우트를 보내세요.
스팬 조사 응답
트레이스 안의 작업 1개를 읽으려면GET /api/telemetry/traces/{trace_id}/spans/{span_id}/investigation을 사용하세요. project_id, environment, release를 보내세요. 세 값 모두 필수입니다. 선택한 스팬에서 복사하세요. 스팬 행의 id를 span_id로 보내지 마세요.
스팬 조사 예시
스팬 조사 예시
이 가상 응답은 트레이스 예시의 실패한 클라이언트 스팬을 설명합니다. 오류 로그 1개의 스팬 ID가 같습니다. 이 스팬은 보존된 비교 대상 스팬의 대략적인 95번째 백분위수보다 오래 걸렸습니다.
기준선은 스팬 시작 전 24시간을 읽습니다.
since는 포함되고 until은 포함되지 않습니다. error_rate_basis_points: 500은 5%를 뜻합니다. subject_percentile_basis_points: 9500은 보존된 비교 대상 스팬의 95%가 이 스팬보다 오래 걸리지 않았다는 뜻입니다. 백분위수는 근사치입니다. baseline.limitations를 값과 함께 유지하세요. not_found 기준선에는 보존된 비교 대상 스팬이 없습니다. unavailable 기준선은 실패한 조회이며, 개수 0이 아닙니다.
parent_chain_status: "complete"는 보존된 체인이 루트에 닿는다는 뜻입니다. LogBrew가 요청의 모든 스팬을 보존했다는 것을 증명하지는 않습니다. 토폴로지는 조상 스팬 최대 64개, 직계 자식 스팬 최대 50개, 서비스 간 연결 최대 50개를 반환합니다.
로그 조사 응답
로그 1개와 그 관련 근거를 읽으려면GET /api/logs/{log_id}/investigation을 사용하세요. 이 라우트에는 쿼리 키가 없습니다. 로그 ID는 로그 목록에서 복사하세요.
로그 조사 예시
로그 조사 예시
이 가상 응답에는 트레이스 컨텍스트가 없는 경고 로그와 주변 로그 1개가 있습니다. 응답은 타임스탬프로 트레이스 링크를 만들지 않습니다.
트레이스 상태가
not_found나 unavailable이어도 트레이스 ID는 있을 수 있습니다. 트레이스 요약을 사용할 수 있다고 해서 exact_span이 있다는 보장은 없습니다.
액션 조사 응답
제품 액션 1개와 그 보고된 상태, 관련 근거를 읽으려면GET /api/telemetry/actions/{action_id}/investigation을 사용하세요. 이 라우트에는 쿼리 키가 없습니다. 관련 조회는 로그 조사와 같은 기간과 범위를 사용합니다.
correlations, timeline, next_actions는 로그 조사와 같은 형식을 사용합니다. 관련 액션에서 조사 대상 액션은 제외합니다.
액션 조사 예시
액션 조사 예시
이 가상 응답은 로그인한 사용자의 실패한 결제 액션을 설명합니다. 이 액션에는 트레이스 ID가 없습니다.
응답은 주체 식별자나 세션 식별자를 절대 반환하지 않습니다. 근거 내역은 항상
subject.distinct_id를 가려진 필드로 나열하고, 세션이 수집되었으면 subject.session_id도 나열합니다. 그래서 모든 액션 번들은 partial이며 improve_capture를 포함합니다. 이 항목을 없애려고 개인정보 보호 설정을 해제하지 마세요.
메트릭 조사 응답
프로젝트 1개와 기간 1개에서 메트릭 이름 1개를 읽으려면GET /api/telemetry/metrics/investigation을 사용하세요. 응답에는 현재 시계열, 같은 길이의 직전 기간과의 비교, 최신 샘플, 트레이스 예시, 완료된 배포가 들어 있습니다. 버전 2는 보존된 최신 샘플의 메트릭 설명을 추가합니다. 버전 1은 항상 description_status: "not_captured"를 보고합니다.
project_id, name, since는 필수입니다. since는 포함되고 until은 포함되지 않습니다. until의 기본값은 현재 시각입니다. 비교를 위해 같은 길이의 직전 기간도 읽습니다.
버전 2 메트릭 조사 예시
버전 2 메트릭 조사 예시
이 가상 히스토그램에는 5분 단위 시간 구간 2개에 샘플 5개가 있습니다. 최신 시간 구간의 p95는 48 ms입니다. 이전 기간의 최신 시간 구간의 p95는 24 ms입니다.
relative_change_percent는 (current - previous) / abs(previous) * 100입니다. 이전 값이 0이거나 없으면 null입니다. expected_buckets_per_series는 데이터가 있는 시간 구간이 아니라 있을 수 있는 시간 구간을 셉니다. 빈 시간 구간을 0으로 그리지 마세요. 변화 시점 근처에 배포가 있다고 해서 그 배포가 변화의 원인이라는 것이 증명되지는 않습니다.
계정이 읽을 수 없는 프로젝트는 404가 아니라 analysis.status: "no_samples"와 함께 200 OK를 반환합니다. 빈 결과는 다른 시그널 유형에 대해 아무것도 알려 주지 않습니다.
메트릭 한도: 기간은 최대 31일입니다. 각 시계열의 시간 구간은 최대 500개입니다. series_limit은 1~20이며 기본값은 10입니다. 응답은 트레이스 예시와 배포를 각각 최대 20개 반환합니다.
interval은 auto, 1m, 5m, 15m, 1h, 6h, 1d 중 하나입니다. group_by는 none, service_name, release, environment 중 하나입니다. 다른 값은 422를 반환합니다.
조사 오류
404는 읽을 수 있는 프로젝트에 해당 레코드가 없다는 뜻입니다. 모든 라우트는 유효한 인증이 없으면 401을, GET이 아닌 메서드에는 405를 반환합니다. 찾을 수 없음, 경로, 인증, 메서드 응답은 API 오류를 참고하세요.
선택적 근거 조회는 200 OK 응답 안에서 실패할 수 있습니다. 이때 해당 컬렉션은 unavailable을 보고합니다. 이를 not_found나 레코드 0개로 표시하지 마세요.
심각도 값
사용자에게 보이는 심각도 값은info, warning, error, critical입니다. SDK와 런타임은 trace, debug, warn, fatal 같은 흔한 별칭을 보낼 수 있습니다. REST 응답과 실시간 응답은 항상 표준 값을 반환합니다. 예를 들어 LogBrew는 warn을 입력으로 받고 warning을 반환합니다. 수집은 알 수 없는 심각도 값을 거부합니다.
심각도 규칙 응답
심각도 규칙은 LogBrew가 로그나 이슈를 표시하는 방식을 바꿉니다. 애플리케이션이 수집한 심각도는 바꾸지 않습니다. 로그와 이슈는triage 객체를 반환합니다.
표시에는
triage.effective_severity를 사용하세요. severity는 수집된 값으로 유지하세요. 로그 목록은 기본적으로 무시된 로그를 생략합니다. 무시된 로그를 포함하려면 GET /api/logs에 status=ignored나 status=all을 보내세요.
계정에 프로젝트의 이슈를 관리할 권한이 있어야 합니다. 읽기 권한만으로는 부족합니다. 권한이 없으면 규칙 변경은 code: forbidden과 함께 403을 반환합니다.
로그 규칙 변경하기
PUT /api/logs/{log_id}/triage-rule은 해당 로그와, 시그니처가 같은 이후 로그에 대한 규칙을 설정합니다. 본문에는 severity와 ignored가 모두 필요합니다.
200 OK 응답에는 완전한 로그가 들어 있습니다. 로그의 severity는 warning 그대로입니다. triage에 규칙이 나타납니다.
severity는 source, info, warning, error, critical 중 하나입니다. source는 수집된 심각도로 되돌립니다. 무시된 로그를 다시 활성 상태로 만들지는 않습니다. 로그를 다시 표시하려면 "ignored": false를 보내세요.
이슈 규칙 변경하기
PUT /api/telemetry/issues/{issue_id}/triage-rule은 그룹화된 이슈와 그 이후 발생 건에 표시할 심각도를 설정합니다. 본문은 severity만 받습니다.
200 OK 응답에는 버전 1의 완전한 이슈가 들어 있습니다. 수집된 severity와 status는 바뀌지 않습니다.
response_version=2나 3으로 이슈를 읽으세요.
지원하지 않는 심각도는 422를 반환합니다.
status처럼 알 수 없는 본문 필드는 code: invalid_json과 함께 422를 반환합니다. 로그나 이슈가 없거나 읽을 수 없으면 code: not_found와 함께 404를 반환합니다. 응답을 받지 못했다면 규칙을 다시 보내기 전에 로그나 이슈를 다시 읽으세요.
오류 응답 형식
애플리케이션 오류는 JSON 엔벨로프를 반환합니다. 이 예시는 거부된 요청을 보여 줍니다.error와 next 텍스트는 문제에 따라 달라집니다.
code를, 자동화에는 next_action을 사용하세요. 사람에게는 error와 next를 일반 텍스트로 보여 주세요. 문구를 파싱하지 마세요. 일부 오류에는 limit, reset_at, retry_after_seconds 같은 필드가 추가됩니다. JSON 본문이 없는 응답에는 LogBrew code가 없습니다. 모든 코드는 API 오류를 참고하세요.
CLI로 데이터 읽기
CLI는 같은 라우트를 읽고,--json을 쓰면 같은 JSON을 반환합니다. 넓게 시작한 다음 범위를 좁히세요.
--pagination cursor를 추가하세요. CLI는 이슈 응답 버전 4를 요청합니다. 다음 페이지 읽기와 실시간 감시를 참고하세요.