애플리케이션 로그가 보이지 않을 때 문제 해결하기

텔레메트리가 없거나, 불완전하거나, 너무 넓게 나올 때 이 페이지를 사용하세요. 먼저 접근 권한을 확인하세요. 그런 다음 원인을 찾는 동안 프로젝트, 서비스, 릴리스, 환경, 기간을 고정하세요.

에이전트 작업에서는 --json을 추가하세요. 검사에 실패하면 고정된 next 필드가 반환됩니다.

빠른 검사부터 시작하기

증상	첫 검사	다음 단계
CLI에 로그인되어 있지 않음	`logbrew status --json`	사람이 `logbrew login`을 실행합니다.
프로젝트가 보이지 않음	`logbrew projects --json`	프로젝트 목록에 있는 ID를 사용하세요.
설정 상태가 불분명함	`logbrew doctor --project "<project_id>" --json`	반환된 `next` 값을 따르세요.
로그가 비어 있음	정확한 프로젝트와 기간으로 로그를 읽으세요	다른 시그널 유형은 따로 확인하세요.
결과가 너무 넓음	프로젝트, 서비스, 릴리스, 환경 필터를 추가하세요	모든 읽기에서 같은 범위를 유지하세요.
트레이스가 없음	이슈 상세 정보를 읽으세요	응답에 트레이스 ID가 있을 때만 트레이스를 읽으세요.
JavaScript 프레임에 빌드된 코드가 보임	빌드와 소스맵 쌍을 확인하세요	JavaScript 소스맵을 따르세요.
MCP 에이전트가 프로젝트를 읽지 못함	승인된 프로젝트를 확인하세요	MCP 연결 문제를 따르세요.

첫 텔레메트리가 보이지 않을 때 복구하기

SDK 설정을 바꾸기 전에 다음 읽기 전용 명령어를 실행하세요.

logbrew version --json
logbrew status --json
logbrew projects --json
logbrew doctor --project "<project_id>" --json

logbrew doctor는 API 접근, 인증, 프로젝트, 수집 키, 설정, 텔레메트리, 로그 표시 여부를 검사합니다. 프로젝트를 바꾸지 않습니다. 전체 status와 각 검사 결과를 doctor 보고서에서 읽으세요. 종료 코드 0은 모든 검사를 통과했다는 뜻이 아닙니다.

doctor 상태	다음 단계
`needs_ingest_key`	프로젝트 범위의 수집 키를 만드세요. 수집 키 교체하기를 참고하세요.
`needs_setup`	SDK 설정을 완료하세요. SDK 연동을 참고하세요.
`needs_telemetry`	앱에서 안전한 테스트 이벤트 1개를 보낸 다음 doctor를 다시 실행하세요.
`ready`	최근 로그, 이슈, 릴리스, 트레이스를 읽으세요.

보고서의 상태는 auth_invalid, project_missing, api_unreachable, check_failed일 수도 있습니다. 각 상태의 다음 단계는 doctor 보고서에 나와 있습니다. 시그널 유형은 서로 별개이므로 ready 프로젝트에도 로그가 없을 수 있습니다. logs 검사는 empty 또는 unavailable일 수 있습니다. 로그 읽기에 실패한 것은 빈 결과와 다릅니다.

안전한 테스트 이벤트 1개 보내기

설치된 SDK로 고유한 메시지가 담긴 테스트 로그 1개를 보내세요. 토큰, 사용자 데이터, 요청 본문은 넣지 마세요. 프로젝트 ID, 서비스, 환경, 릴리스, UTC 시작 시각, SDK 버전을 기록하세요. 전송을 기다린 다음 같은 프로젝트에서 짧은 기간을 읽으세요. 전송이 대기 중인 동안에는 테스트 이벤트를 더 보내지 마세요.

보이지 않는 로그 찾기

먼저 작고 정확한 범위를 읽으세요.

logbrew read releases --project "<project_id>" --environment production --json
logbrew read logs --project "<project_id>" --environment production \
  --release checkout@1 --since 1h --limit 20 --json

다음 항목을 순서대로 확인하세요.

프로젝트 ID가 이벤트를 보낸 앱의 것입니다.
서비스, 릴리스, 환경이 대소문자와 공백까지 정확히 일치합니다.
기간에 이벤트 시각이 포함됩니다. LogBrew는 이벤트 시각을 UTC로 반환합니다. --until은 포함하지 않는 상한입니다.
검색 필터나 심각도 필터가 이벤트를 가리지 않습니다.
앱이 지금 읽는 시그널 유형을 보냈습니다. 로그를 보낸다고 이슈나 트레이스가 만들어지지는 않습니다.

그래도 이벤트가 보이지 않으면 필터를 하나씩 제거하세요.

프로젝트는 유지하고 기간을 넓히세요.
릴리스 필터를 제거하세요.
환경 필터를 제거하세요.
서비스 필터를 제거하세요.
검색 필터와 심각도 필터를 제거하세요.

이벤트가 나타나면 멈추세요. 마지막으로 제거한 필터가 앱 설정과 맞지 않는 것입니다. 설정된 프로젝트 대신 모든 프로젝트를 읽지 마세요.

결과	의미	다음 확인
한 프로젝트에 행이 없음	그 범위에 일치하는 항목이 없습니다	시각과 필터를 확인하세요.
로그는 있지만 이슈가 없음	필터와 일치하는, 그룹으로 묶인 오류가 없습니다	앱이 오류를 보냈는지 확인하세요.
트레이스가 없는 이슈	발생 건에 사용할 수 있는 트레이스 링크가 없습니다	이슈 조사 결과에서 트레이스 상태를 읽으세요.
릴리스는 있지만 로그가 없음	릴리스에 다른 시그널은 있지만 그 범위에 로그가 없습니다	`logbrew read releases`의 개수를 비교하세요. 같은 프로젝트에서 시그널 유형별로 읽으세요.
필터를 제거하자 이벤트가 나타남	그 필터가 이벤트를 제외했습니다	필터나 앱의 값을 고치세요.

결과 페이지 하나는 전체가 아닙니다. --pagination cursor를 쓴다면 반환된 next_cursor로 계속 읽고 같은 필터를 유지하세요. 커서 기반 페이지네이션을 참고하세요.

대시보드 화면 확인하기

대시보드는 각 목록의 스냅숏을 보여 줍니다. 로그 화면에서 실시간을 켜면 새 로그가 들어오는 대로 추가됩니다. 다른 화면은 실시간으로 업데이트되지 않습니다. 새 스냅숏을 보려면 페이지를 새로 고치세요. 오래된 스냅숏은 빈 결과와 다릅니다. LogBrew는 앱이 보내는 텔레메트리만 저장합니다. 전송 전에 자격 증명, 요청 본문, 쿼리 값, 개인정보를 제거하세요. 필드 선택은 수집 데이터 관리하기로 확인하세요.

이슈와 트레이스 확인하기

LogBrew가 반환한 이슈 ID나 트레이스 ID를 사용하세요. 직접 지어내지 마세요.

logbrew read issues --project "<project_id>" --environment production \
  --status unresolved --since 24h --json
logbrew read issue "<issue_id>" --json
logbrew read trace "<trace_id>" --project "<project_id>" --json
logbrew read logs --trace "<trace_id>" --project "<project_id>" --json

--status에는 unresolved, resolved, archived를 쓸 수 있습니다. ignored는 archived와 같은 이슈를 선택합니다. 이슈 상태와 트레이스 상태는 다릅니다. 트레이스 상태 값 not_linked, not_found, unavailable은 의미가 서로 다릅니다. 각 값은 이슈 조사하기를 참고하세요. 이슈를 해결, 보관, 다시 열기 전에 이슈와 로그를 읽으세요.

CLI 및 API 오류 처리하기

JSON 모드에서 CLI 오류에는 ok, error, message, next가 있습니다.

{
  "ok": false,
  "error": "not_logged_in",
  "message": "not logged in: run logbrew login",
  "next": "run logbrew login"
}

API가 오류를 반환하면 error는 api_error입니다. 오류에는 status(HTTP 상태), api_code(API code), api_error, api_next도 있습니다. rate_limited 오류에는 retry_after_seconds도 있습니다. CLI는 자동으로 재시도하지 않습니다.

상태 또는 오류	복구 방법
`not_logged_in` 또는 HTTP `401`	사람이 `logbrew login`을 실행합니다. 그런 다음 읽기를 다시 시도하세요.
HTTP `403`	프로젝트에 맞는 자격 증명을 사용하세요. 이슈를 변경하려면 프로젝트의 이슈 관리 권한도 필요합니다. 자격 증명 값을 보여 주지 마세요.
HTTP `404`	응답에서 받은 현재 프로젝트, 이슈, 트레이스 ID를 사용하세요.
HTTP `422`	표시된 필드를 고치세요.
`rate_limited`인 HTTP `429`	`retry_after_seconds`만큼 기다린 다음 한 번 다시 시도하세요.
다른 코드인 HTTP `429`	자동 재시도를 멈추세요. `api_next`를 따르세요.
HTTP `5xx`	기다렸다가 읽기를 한 번 다시 시도하고, 문제가 계속되면 신고하세요.

각 오류 코드는 API 오류를 참고하세요.

유출된 계정 보호하기

다른 사람이 계정 액세스 토큰, 리프레시 토큰, 세션 쿠키를 가지고 있을 수 있다면 모든 LogBrew 클라이언트에서 로그아웃하세요. 계정 전체 로그아웃 절차를 따르세요. 이 작업은 사람이 승인해야 합니다. logbrew logout과 브라우저 로그아웃은 클라이언트 1개만 종료하므로 충분하지 않습니다. 계정 전체 로그아웃은 그 전에 승인된 모든 MCP 연결도 중지합니다. 성공하면 각 클라이언트의 로컬 LogBrew 자격 증명을 지우고, 신뢰할 수 있는 클라이언트에서 다시 로그인하세요. MCP 클라이언트는 신뢰할 수 있다고 판단한 뒤에만 다시 승인하세요. 응답을 받지 못했다면 모든 클라이언트가 로그아웃되었다고 보고하지 말고, 요청을 자동으로 반복하지 마세요. 계정 전체 로그아웃은 프로젝트 수집 키를 교체하지 않습니다. 수집 키가 노출되었다면 수집 키를 교체하세요.

안전하게 문제 해결하기

CLI 읽기에는 계정 접근 자격 증명을 사용하세요. 프로젝트 범위의 수집 자격 증명은 SDK 쓰기에만 사용하세요. 명령어, 채팅, 지원 티켓에 토큰, 인증 헤더, 원본 로그, 고객 데이터, 요청 본문, 로컬 경로, 소스 코드를 넣지 마세요. 문제를 신고하기 전에, 여전히 실패하는 가장 작은 범위로 읽기를 한 번 반복하세요. 자격 증명 값을 뺀 명령어, 오류 코드, 프로젝트 ID, 필터 값을 기록하세요. 검사로 문제가 해결되지 않으면 문제 신고하세요.

빠른 시작

안전한 첫 이벤트를 보내고 읽으세요.

CLI 사용하기

정확한 필터와 JSON 출력을 사용하세요.

이슈 조사하기

상태를 바꾸기 전에 이슈 근거를 읽으세요.

API 오류

오류 코드별로 복구하세요.

시작하기

개념

설치 및 데이터 전송

조사

CLI 및 에이전트

지원

애플리케이션 로그가 보이지 않을 때 문제 해결하기

빠른 검사부터 시작하기

첫 텔레메트리가 보이지 않을 때 복구하기

안전한 테스트 이벤트 1개 보내기

보이지 않는 로그 찾기

대시보드 화면 확인하기

이슈와 트레이스 확인하기

CLI 및 API 오류 처리하기

유출된 계정 보호하기

안전하게 문제 해결하기

관련 페이지

빠른 시작

CLI 사용하기

이슈 조사하기

API 오류

​빠른 검사부터 시작하기

​첫 텔레메트리가 보이지 않을 때 복구하기

​안전한 테스트 이벤트 1개 보내기

​보이지 않는 로그 찾기

​대시보드 화면 확인하기

​이슈와 트레이스 확인하기

​CLI 및 API 오류 처리하기

​유출된 계정 보호하기

​안전하게 문제 해결하기

​관련 페이지

빠른 시작

CLI 사용하기

이슈 조사하기

API 오류

빠른 검사부터 시작하기

첫 텔레메트리가 보이지 않을 때 복구하기

안전한 테스트 이벤트 1개 보내기

보이지 않는 로그 찾기

대시보드 화면 확인하기

이슈와 트레이스 확인하기

CLI 및 API 오류 처리하기

유출된 계정 보호하기

안전하게 문제 해결하기

관련 페이지