모든 시그널을 하나의 분명한 이야기로.
LogBrew는 로그, 트레이스, 이슈, 릴리스를 연결해 모든 실패를 이해할 수 있게 합니다.
로그
메시지를 검색하고, 로그가 실패를 설명하면 트레이스를 여세요.
POST /webhooks/payments
{ "title": "POST /webhooks/payments", "project": "Checkout API", "duration": "12 ms", "spans": 3, "trace_id": "webhook-8e91", "issue_id": "PAY-1043", "request_id": "req-webhook-8e91", "release": "checkout-api@1.24.0", "environment": "production", "http": { "method": "POST", "route": "/webhooks/payments", "status_code": 400 }, "operations": [ { "span_id": "webhook", "parent_span_id": null, "name": "POST /webhooks/payments", "start_offset_ms": 0, "duration_ms": 12, "status": "error" }, { "span_id": "secret", "parent_span_id": "webhook", "name": "signing_key.load", "start_offset_ms": 0, "duration_ms": 3, "status": "ok" }, { "span_id": "verify", "parent_span_id": "webhook", "name": "signature.verify", "start_offset_ms": 3, "duration_ms": 9, "status": "error", "attributes": { "key_version": "v7", "signature_match": false, "payload_logged": false } } ], "logs": [ { "offset_ms": 0, "severity": "info", "message": "Payment webhook received; provider event evt-9032" }, { "offset_ms": 3, "severity": "info", "message": "Loaded signing key version v7 from runtime configuration" }, { "offset_ms": 12, "severity": "error", "message": "Signature verification failed; returned 400 without updating order state" } ] }
근거를 실제 작업에 활용하세요.
이슈
실패를 검색하고 트레이스 맥락을 여세요.
| 오류 | Checkout API | 3 | ||
| 치명적 | Checkout API | 18 | ||
| 경고 | Checkout API | 6 | ||
| 정보 | Checkout API | 12 |
트레이스
요청을 열어 경로와 관련 시그널을 확인하세요.
| Checkout API | 오류 | 12 ms | 3 | |
| Checkout API | 정상 | 46 ms | 3 | |
| Checkout API | 정상 | 8 ms | 2 | |
| Checkout API | 오류 | 2,548 ms | 4 |
POST /webhooks/payments
{ "title": "POST /webhooks/payments", "project": "Checkout API", "duration": "12 ms", "spans": 3, "trace_id": "webhook-8e91", "issue_id": "PAY-1043", "request_id": "req-webhook-8e91", "release": "checkout-api@1.24.0", "environment": "production", "http": { "method": "POST", "route": "/webhooks/payments", "status_code": 400 }, "operations": [ { "span_id": "webhook", "parent_span_id": null, "name": "POST /webhooks/payments", "start_offset_ms": 0, "duration_ms": 12, "status": "error" }, { "span_id": "secret", "parent_span_id": "webhook", "name": "signing_key.load", "start_offset_ms": 0, "duration_ms": 3, "status": "ok" }, { "span_id": "verify", "parent_span_id": "webhook", "name": "signature.verify", "start_offset_ms": 3, "duration_ms": 9, "status": "error", "attributes": { "key_version": "v7", "signature_match": false, "payload_logged": false } } ], "logs": [ { "offset_ms": 0, "severity": "info", "message": "Payment webhook received; provider event evt-9032" }, { "offset_ms": 3, "severity": "info", "message": "Loaded signing key version v7 from runtime configuration" }, { "offset_ms": 12, "severity": "error", "message": "Signature verification failed; returned 400 without updating order state" } ] }
모든 시그널에 답으로 가는 길을 만드세요.
LogBrew를 열고 다음 프로덕션 질문을 집중된 조사로 바꾸세요.
자주 묻는 질문에서 LogBrew에 대한 답을 찾아보세요
애플리케이션을 연결하고, 오류를 조사하고, 코딩 에이전트와 함께 일하는 방법을 알아보세요.
LogBrew는 묶인 이슈, 로그, 트레이스로 애플리케이션 실패를 조사하도록 돕습니다. 이슈를 열어 수집된 맥락을 살펴보거나, 로그에서 특정 이벤트를 검색하세요. 볼 수 있는 세부 정보는 연동 방식과 애플리케이션이 보내는 데이터에 따라 다릅니다.
로그는 정상 활동을 포함해 개별 이벤트를 기록합니다. 에러 트래킹은 관련된 실패를 이슈로 묶어, 반복된 발생 건과 마지막 발생 시점을 검토할 수 있게 합니다. 이슈로 다룰 문제를 고른 다음, 관련 로그에서 맥락을 살펴보세요.
수집된 발생 건에서 시작해 환경, 릴리스, 메시지, 스택 트레이스를 확인하세요. 관련 로그와 트레이스 근거가 있으면 함께 검토하세요. 이러한 기록은 로컬에서 오류를 재현할 수 없을 때도 조사 범위를 좁혀 주지만, 근본 원인을 보장하지는 않습니다.
연동에서 브레드크럼이나 관련 로그를 수집하면, 이슈 세부 정보에서 실패 전후의 이벤트를 볼 수 있습니다. 연결된 트레이스가 있으면 작업 소요 시간도 볼 수 있습니다. 애플리케이션이 수집하지 않은 활동은 LogBrew가 재구성할 수 없습니다.
로그는 이벤트 하나를 기록합니다. 스택 트레이스는 오류와 관련된 함수 호출을 보여 줍니다. 분산 트레이스는 요청이나 작업 안에서 이어지는 관련 작업을 따라가며, 여러 서비스에 걸칠 수도 있습니다. 디버깅할 때 각각 다른 질문에 답합니다.
이슈 화면에서 묶인 실패, 발생 횟수, 최근 발생 건을 검토하세요. 프로젝트와 기간으로 결과를 좁힌 다음, 개별 발생 건을 살펴보세요. 반복 여부는 패턴을 찾는 데 도움이 되지만, 그것만으로 사용자 영향을 측정하지는 않습니다.
연동에서 일치하는 트레이스 맥락을 수집하고 전파하면 관련 이벤트를 연결할 수 있습니다. 타임스탬프가 같거나 메시지가 비슷하다는 것만으로는 두 이벤트가 같은 요청에 속한다고 증명할 수 없습니다. 연동마다 트레이싱 안내를 따르세요.
오류는 활성 트레이스 맥락 없이 수집될 수 있습니다. 살펴보는 시점에 트레이스를 사용할 수 없을 수도 있습니다. 이슈 세부 정보의 근거 상태와 연동의 트레이싱 설정을 확인하세요. 최신 SDK로 바꿔도 이전 발생 건에 트레이스 맥락이 추가되지는 않습니다.
네. 제공되는 조사 맥락, CLI, MCP 도구로 에이전트에 범위가 정해진 근거를 전달하세요. 에이전트 가이드에서 작업 흐름을 설명합니다. 공유하는 데이터를 확인하고, 자격 증명은 프롬프트에 넣지 말고, 제안된 변경은 적용하기 전에 검토하세요.
대시보드에서 바로 조사할 수 있습니다. 에이전트 도구는 선택 사항입니다. 두 방식 모두 수집된 근거를 사용하고, 누락되거나 제한된 맥락을 숨기지 않아야 합니다. LogBrew는 자동 수정을 보장하지 않습니다.
프로젝트를 만들고, 사용하는 언어나 프레임워크에 맞는 연동을 선택한 다음, 해당 설정 가이드를 따르세요. 안전한 테스트 이벤트를 보내고 원하는 프로젝트에 표시되는지 확인하세요. 지원되는 시그널과 설정은 연동마다 다릅니다.
먼저 선택한 프로젝트, 기간, 그 밖의 필터를 확인하세요. 그런 다음 프로젝트 설정과 연동이 보내는 시그널을 확인하세요. 로그, 이슈, 트레이스는 서로 다른 스트림이므로 로그 화면이 비어 있어도 이슈를 받지 않았다는 뜻은 아닙니다.
텔레메트리를 프로젝트로 나누고, 지원되는 화면에서 접근 가능한 프로젝트를 하나, 여러 개, 또는 전체 선택할 수 있습니다. 서비스는 프로젝트 안에서 데이터를 보고하는 구성 요소를 나타냅니다. 프런트엔드, 백엔드, 워커 활동을 비교할 때는 이 범위를 분명히 구분하세요.
텔레메트리 수집과 전송에는 리소스가 사용됩니다. 영향은 SDK, 설정, 이벤트 양에 따라 다릅니다. 실제와 비슷한 부하에서 연동을 테스트하고, 해당 SDK 문서에 나온 제어 옵션을 사용하세요. 오버헤드가 전혀 없다고 가정하지 마세요.
메시지, 속성, 오류 맥락에 비밀 정보나 불필요한 개인정보를 넣지 마세요. SDK의 수집 및 가림 처리 옵션을 검토한 다음, 프로덕션에서 연동을 활성화하기 전에 안전한 테스트 이벤트를 살펴보세요. 모든 필드가 자동으로 제거된다고 가정하지 마세요.
현재 요금제와 기본 제공량은 요금 페이지에서 확인하세요. 로그인한 후에는 계정 및 사용량 페이지에서 내 계정에 표시되는 정보를 확인하세요. 무제한 수집을 가정하지 말고 현재 요금제 세부 정보를 확인하세요.