첫 번째 Telemetry SQL 쿼리 작성
알려진 합성 행에서 답변을 확인할 수 있는 질문으로 시작하세요. 이 연습에서는 이전 시작 단계에서 생성된 api_request_completed 테이블을 쿼리합니다.
최근 행 검사
집계 대신 이벤트 그레인으로 시작합니다.
SELECT
timestamp_utc,
request_id,
route_template,
status_code,
latency_ms,
release,
environment
FROM api_request_completed
WHERE environment = 'development'
ORDER BY timestamp_utc DESC
LIMIT 100;
합성 req_demo_001 행을 찾습니다. 누락되었거나 잘못 입력된 경우 이벤트 수집 및 스키마 확인로 돌아가세요.
요청량 및 오류 계산
원시 행이 올바르게 보이면 경로 그레인에서 집계합니다.
SELECT
route_template,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS server_errors,
ROUND(
100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0),
2
) AS server_error_pct
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'development'
GROUP BY route_template
ORDER BY requests DESC;
분모는 동일한 기간 동안의 각 경로에 대한 요청량입니다. NULLIF는 쿼리가 나중에 조인에 적용되거나 빈 버킷으로 생성된 시간 척추에 적용되는 경우 분할을 보호합니다.
단위를 확인한 후에만 대기 시간을 추가하십시오.
SELECT
route_template,
COUNT(*) AS requests,
approx_percentile_cont(0.5) WITHIN GROUP (ORDER BY latency_ms)
AS p50_latency_ms,
approx_percentile_cont(0.95) WITHIN GROUP (ORDER BY latency_ms)
AS p95_latency_ms
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'development'
GROUP BY route_template
ORDER BY p95_latency_ms DESC;
백분위수를 해석하기 전에 latency_ms가 숫자이고 항상 밀리초 단위로 측정되는지 확인하세요. 희소 그룹, 근사 함수 및 표본 크기 주의 사항은 SQL 백분위수를 참조하세요.
저장하기 전에 확인하세요
성공한 요청과 실패한 요청이 알려진 작은 고정 장치를 사용하세요. 예상 요청 횟수와 오류율을 수동으로 계산한 다음 이를 SQL 결과와 비교합니다.
다음 네 가지 사항을 확인하세요.
- 세분리: 한 행은 완료된 요청 1개를 나타냅니다.
- 분모: 재시도 및 내부 트래픽은 의도적으로 포함되거나 제외됩니다.
- 창: 최신 불완전 버킷은 전체 버킷과 비교되지 않습니다.
- 차원: 경로 템플릿, 릴리스 및 환경은 안정적인 값을 사용합니다.
유효한 SQL는 여전히 잘못된 비즈니스 질문에 답할 수 있습니다. 쿼리와 함께 정의 및 제외를 저장합니다.
계속
전체 스키마, 고정 장치, 시각화 및 알림 권장 사항을 보려면 API 오류율 레시피를 사용하세요. 연결된 합성 데이터베이스에서 실습하려면 SaaS SQL Lab을 엽니다. 그런 다음 첫 번째 대시보드 및 알림 만들기를 계속 진행하세요.