콘텐츠로 건너뛰기
Telemetry
문서 찾아보기
가이드업데이트된 2026년 7월 29일Telemetry 편집 및 제품 팀의 검토3 최소 읽기

코딩 에이전트와 함께 이 문서를 사용하세요.

Claude Code, Codex, Cursor 또는 다른 코딩 에이전트에 대한 집중 프롬프트 팩을 연 다음 여기에서 다루는 워크플로에 맞게 조정하세요.

이 페이지에서
  1. 이벤트 계약 테스트
  2. 모든 터미널 경로를 연습합니다.
  3. 개인 정보 보호 경계 시행
  4. 테스트 전달 실패
  5. 결정적 고정 장치로 SQL 검증
  6. 배포 확인 추가

CI에서 Telemetry 계측 테스트

Telemetry 계측은 애플리케이션 동작이며 다른 통합 경계와 마찬가지로 테스트되어야 합니다. 유용한 CI 제품군은 올바른 최종 결과가 올바른 이벤트를 생성하고, 금지된 콘텐츠가 제외되고, 전달 실패가 애플리케이션 결과를 손상시키지 않으며, 운영 SQL이 여전히 예상 결과를 반환한다는 것을 증명합니다.

CI가 프로덕션 Telemetry API에 종속되도록 만들지 마십시오. 이벤트 싱크 또는 HTTP 전송을 삽입하고 메모리에 페이로드를 캡처합니다.

이벤트 계약 테스트

스키마 규칙을 검토할 수 있도록 하나의 함수에서 이벤트를 빌드합니다.

type CheckoutInput = {
  checkoutId: string;
  status: "success" | "failed";
  durationMs: number;
  errorType?: "payment_declined" | "provider_timeout";
};

export function checkoutEvent(input: CheckoutInput) {
  return {
    event_name: "checkout_completed",
    schema_version: 1,
    checkout_id: input.checkoutId,
    status: input.status,
    duration_ms: input.durationMs,
    ...(input.errorType ? { error_type: input.errorType } : {}),
  };
}

단위 테스트는 정확한 필드 이름과 유형, 제어된 범주 값, 명시적 단위 및 조건부 요구 사항을 확인해야 합니다. 검토자가 의미 변화를 인지하지 못한 채 업데이트할 수 있는 스냅샷보다 정확한 객체 어설션을 선호합니다.

모든 터미널 경로를 연습합니다.

소유 워크플로우의 경우 다음을 다룹니다.

  • 성공
  • 예상되는 사업 실패
  • 종속성 시간 초과
  • 재시도 후 성공
  • 재시도가 소진됨
  • 해당되는 경우 취소 또는 직접 전달
  • 중복배송
  • 선택적 컨텍스트 누락

곡물을 주장하십시오. 구현이 내부적으로 재시도하더라도 논리적 요청 이벤트는 한 번만 발생해야 합니다. 시도 이벤트에는 시도 횟수와 안정적인 논리 작업 ID가 포함되어야 합니다.

개인 정보 보호 경계 시행

인증 헤더, 쿠키, 이메일, 원시 URL 쿼리, 요청 본문, 프롬프트, 도구 인수 및 예외 메시지를 포함하는 적대적인 픽스처를 만듭니다. 캡처된 이벤트에 아무도 도달할 수 없다고 어설션합니다.

허용 목록은 늘어나는 거부 목록보다 테스트하기가 더 쉽습니다. 수정이 대체 레이어인 경우 별도로 테스트하여 알 수 없는 중첩 필드가 이를 우회할 수 없는지 확인하세요.

테스트 전달 실패

가짜 싱크를 거부하고, 시간 초과하고, 속도 제한 응답을 반환하도록 합니다. 애플리케이션이 문서화된 정책을 따르는지 확인합니다.

  • 최선의 분석은 성공적인 고객 운영을 오류로 바꾸지 않습니다.
  • 중요한 감사 또는 청구 이벤트는 승인된 내구성 경로를 사용합니다.
  • 재시도는 제한되어 있으며 필요한 경우 멱등성을 사용합니다.
  • 종료 플러시는 마감일을 준수합니다.
  • 실패한 페이로드를 재귀적으로 기록하지 않고도 텔레메트리 실패를 관찰할 수 있습니다.

이벤트 전달 및 멱등성배칭, 배압 및 종료를 참조하세요.

결정적 고정 장치로 SQL 검증

중요한 SQL에 대한 작은 합성 데이터 세트와 예상 행을 저장합니다. 성공, 실패, 중복, null, 지연 및 경계 타임스탬프 사례를 포함합니다. 쿼리 테스트에서는 계산 규칙을 ​​표시해야 합니다.

SQL 레시피 라이브러리에는 결정적 입력 행과 예상 출력이 포함되어 있는 반면, SQL 플레이그라운드는 지원되는 픽스쳐를 로컬에서 실행할 수 있습니다. 애플리케이션 소유 대시보드 및 알림에 이러한 패턴을 사용하십시오.

배포 확인 추가

CI는 런타임 구성이 아닌 코드 동작을 증명합니다. 비프로덕션 환경에 배포한 후:

  1. 고유하게 식별된 합성 이벤트를 보냅니다.
  2. HTTP 응답과 저장된 테이블을 확인합니다.
  3. 필드 유형과 스키마 버전을 확인하세요.
  4. 이벤트를 찾는 가장 작은 쿼리를 실행합니다.
  5. 정책에 따라 Fixture를 삭제하거나 만료시킵니다.

새로 도입된 분석 변수가 없다는 이유만으로 애플리케이션 시작에 실패하지 마십시오. 먼저 구성을 롤아웃하고 기존 동작을 폴백으로 유지하며 배포된 모든 환경이 검증된 후에만 적용합니다.

이벤트 추적 계획에 계약을 문서화하고, 프로덕션 계측 체크리스트를 따르고, 배포 확인이 실패하면 이벤트 수집 문제 해결을 사용하세요.

관련 제품 기능

안정적인 이벤트 이름, 타입이 지정된 필드, 개인 정보 보호 검토 컨텍스트를 캡처합니다.

소유권 및 기술 참조

이 설명은 Telemetry 편집팀의 소유입니다. 제품 팀은 동작, 예시, 경계를 검토합니다.

편집 기준 검토