이벤트 수집 및 스키마 확인
승인된 API 요청은 계측 검사의 끝이 아닙니다. 이벤트를 더 많은 경로, 작업자 또는 서비스에 복사하기 전에 결과 테이블과 행을 확인하세요.
이 페이지에서는 첫 번째 구조화된 이벤트 보내기에서 합성 api_request_completed 이벤트를 보냈다고 가정합니다.
테이블 찾기
Telemetry 팀을 열고 테이블을 선택한 다음 api_request_completed를 엽니다. 테이블이 없는 경우:
- API 요청이 성공적인 응답을 반환했는지 확인합니다.
- 키가 의도한 팀에 속하고 쓰기 가능 범위가 있는지 확인하세요.
- 정규화 후 정확한 테이블 이름을 확인하세요.
- 새로운 합성
request_id로 한 번 다시 시도하세요. - 스키마를 변경하기 전에 이벤트 수집 문제 해결을 따르세요.
새로운 식별자 없이 동일한 이벤트를 반복적으로 전송하지 마세요. 재시도하면 나중에 계산이 모호해질 수 있습니다.
추론된 스키마 검사
합성 API 예제는 다음과 유사한 필드를 노출해야 합니다.
| 필드 | 예상되는 분석 유형 | 확인 |
|---|---|---|
timestamp_utc |
타임스탬프 | 지속적으로 추가되고 UTC로 저장됩니다. |
route_template |
텍스트 | 원시 URL이 아닌 제한된 경로 템플릿을 포함합니다. |
status_code |
정수 | 숫자 비교를 지원할 수 있습니다. |
latency_ms |
번호 | 어디에서나 밀리초를 사용합니다. |
status |
텍스트 | 문서화된 작은 어휘를 사용합니다. |
request_id |
텍스트 | 비밀을 노출하지 않고 관련 이벤트를 연결합니다. |
중요한 분야의 유형이 잘못된 경우 프로덕션 트래픽을 보내기 전에 프로듀서를 중지하고 수정하십시오. 숫자에서 임의의 텍스트로 변경되는 필드는 저장된 SQL 및 차트를 추론하기 어렵게 만들 수 있습니다.
정확한 행 검사
샘플또는테이블 보기를 사용하여 request_id = req_demo_001를 찾으세요. 확인:
- 행은 예상되는 환경 및 릴리스에 속합니다.
latency_ms는184이며,0.184또는184000가 아닙니다.- 경로에는 실제 보고서나 계정 식별자가 포함되어 있지 않습니다.
- 인증 헤더, 쿠키, 요청 본문, 비밀, 프롬프트 또는 개인 고객 콘텐츠가 포함되지 않았습니다.
- 생성된 시간은 전송 창과 일치합니다.
예상되는 행은 이벤트 계약이 작동한다는 증거입니다. 이는 성능 벤치마크나 대표적인 프로덕션 분포가 아닙니다.
API를 통해 확인
프로그래밍 방식으로 테이블과 스키마를 검사할 수도 있습니다.
curl https://api.telemetry.sh/tables \
-H "Authorization: Bearer $TELEMETRY_API_KEY"
그런 다음 테이블 스키마를 요청합니다.
curl https://api.telemetry.sh/tables/api_request_completed/schema \
-H "Authorization: Bearer $TELEMETRY_API_KEY"
검증 자동화를 위해 읽기 가능한 키를 사용하세요. 테이블 API는 페이지 매김, 정규화, 보존 및 스키마 응답을 문서화합니다.
계약서를 기록하세요
계측을 확장하기 전에 다음 사항을 적어 두십시오.
- 이벤트 이름과 사업 내용입니다.
- 필수 및 선택 필드입니다.
- 필드 유형 및 단위.
- 허용되는 상태 및 오류 카테고리.
- ID 및 상관관계 필드.
- 금지된 필드입니다.
- 소유자 및 보유 예정 기간.
첫 번째 SQL 쿼리 작성을 계속 진행하세요. 스키마 변경 전략은 스키마 진화를 참조하세요.