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

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

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

이 페이지에서
  1. 제한된 신호로 시작
  2. 범위에 영향을 받는 경로 및 릴리스
  3. 타임라인 구축 및 보존
  4. 복구 확인

SQL을 통한 사고 대응

응답자가 동일한 질문에 동일한 순서로 답변하면 사고 대응이 더 빨라집니다. 즉, 변경이 언제 시작되었는지, 어떤 사용자와 워크플로가 영향을 받는지, 무엇이 변경되었는지, 시스템이 복구되었는지 등입니다. 구조화된 이벤트는 이러한 차원을 보존하므로 구조화되지 않은 메시지를 검색하지 않고도 광범위한 신호에서 방어 가능한 타임라인으로 이동할 수 있습니다.

HTTP 5xx 스파이크를 릴리스 및 영향을 받는 체크아웃 경로와 연관시키는 사고 대시보드

광범위하게 시작한 다음 변경 사항을 설명할 수 있는 경로와 릴리스 차원을 유지합니다.

제한된 신호로 시작

api_request_completed와 같은 안정적인 완료 이벤트를 선택한 다음 전체 5분 버킷을 비교합니다. 경로 템플릿, 릴리스 식별자, 상태, 오류 범주 및 안전한 계정 식별자를 별도의 필드로 유지합니다.

SELECT
  date_bin(INTERVAL '5 minutes', timestamp_utc, TIMESTAMP '1970-01-01') AS bucket,
  COUNT(*) AS requests,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '2 hours'
GROUP BY bucket
ORDER BY bucket;

하나의 저용량 버킷에서 사고를 선언하지 마세요. 요율을 요청량 및 해당 서비스의 운영 목표와 비교하세요.

범위에 영향을 받는 경로 및 릴리스

시작 시간이 명확해지면 변경 사항을 설명할 수 있는 차원을 유지합니다. 경로 및 릴리스별로 그룹화하고 최소 볼륨 임계값을 유지하며 실패한 요청 및 비율을 기준으로 순위를 매깁니다.

SELECT
  route_template,
  release,
  COUNT(*) AS requests,
  SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failed_requests,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '30 minutes'
GROUP BY route_template, release
HAVING COUNT(*) >= 20
ORDER BY failed_requests DESC, error_rate_pct DESC;

해당 차원이 응답을 변경할 수 있는 경우에만 error_type, 종속성, 지역 또는 개인정보 보호 계정 식별자를 사용하여 쿼리를 반복합니다. 원시 요청 본문, 승인 헤더, 이메일 및 자유 형식 예외 텍스트를 피하세요.

타임라인 구축 및 보존

사건 로그에 각 가설, 쿼리, 기간, 결과 및 조치를 기록합니다. 두 번째 응답자가 범위를 재현할 수 있도록 가장 유용한 쿼리를 대시보드 옆에 저장하세요. 정확한 UTC 타임스탬프를 사용하여 배포, 기능 플래그 변경, 종속성 오류 및 복구 작업을 표시합니다.

API 오류율 레시피를 사용하여 영향을 받은 경로의 순위를 지정하고, 릴리스 회귀 레시피를 사용하여 빌드를 비교하고, 오류 예산 소모 레시피를 사용하여 사고를 가용성 목표와 연결합니다. 응답자에게 명시적인 고객 영향 계약이 필요한 경우 incident_impact_observed 이벤트 스키마로 시작하세요.

복구 확인

롤백이나 구성 변경은 그 자체로는 복구가 아닙니다. 버킷이 완료될 때까지 기다렸다가 오류율과 지연 시간이 예상 범위로 돌아왔는지 확인하고 트래픽 볼륨이 사라지지 않았는지 확인합니다. 지연된 재시도 및 백그라운드 작업을 처리할 수 있을 만큼 오랫동안 창을 계속 관찰하세요.

사고가 발생한 후 검증된 탐지 쿼리를 대시보드 또는 알림로 전환하고, 최소 볼륨과 소유권을 문서화하고, 대응자에게 영향을 격리하는 데 필요한 안전 필드가 부족한 경우 이벤트 계약을 업데이트하세요. 알림 문제 해결 가이드에서는 소음을 발생시키지 않고 결과 알림 경로를 테스트하는 방법을 설명합니다.

관련 제품 기능

검토된 SQL을 자체 임계값 및 응답 워크플로로 승격합니다.

소유권 및 기술 참조

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

편집 기준 검토