Go HTTP server structured logging로 이벤트 전송 및 확인
제어된 애플리케이션 경계에서 Go HTTP server structured logging를 사용하고, 이벤트 계약을 작게 유지하고, 집계 뷰를 구축하기 전에 알려진 결과를 확인하세요.
- 1
결과를 선택하세요
Go API 신뢰성
- 2
계약 정의
route_template, 방법 및 status_code
- 3
결과에서 방출
리소스 식별자당 하나의 그룹을 피하려면 r.URL.Path 대신 라우터 패턴을 사용하세요.
- 4
증거를 확인하세요
Exercise a known fixture, then inspect api_request_completed for one correctly typed terminal row.
시작하기 전에
시작하기 전에
- 서버측 키로 초기화된 텔레메트리 SDK
- 최종 상태 코드를 기록하는 응답 작성기 래퍼
- 애플리케이션 라우터의 정규화된 경로 이름
배송 설정
서버 측 설치 및 초기화
프로세스당 한 번씩 telemetry.NewTelemetry를 초기화하거나 컨텍스트 취소 및 명시적인 시간 초과가 필요한 경우 애플리케이션 소유 http.Client를 사용하세요. 브라우저 번들, 클라이언트에 표시되는 환경 변수, 소스 제어, 로그 및 예외 메시지에서 수집 자격 증명을 유지하세요.
Go module 설치
go get github.com/telemetry-sh/telemetry-go- 1제한된 네트워크 동작을 갖춘 재사용 가능한 서버 측 전달 클라이언트 하나를 준비합니다.
- 2성공, 실패, 재시도 또는 시간 초과 경계에 결과 이벤트를 추가합니다.
- 3알림을 활성화하기 전에 제어된 고정 장치를 보내고 저장된 행을 검사하십시오.
스니펫
하나의 체계적인 이벤트로 시작하세요
워크플로가 완료, 실패 또는 재시도되는 위치에 이 셰이프를 추가합니다. 그런 다음 실제 필드에서 대시보드를 구축합니다.
Go HTTP server structured logging 이벤트
startedAt := time.Now()
next.ServeHTTP(recorder, r)
status := "success"
if recorder.StatusCode >= 500 {
status = "failed"
}
_, err := telemetryClient.Log("api_request_completed", map[string]interface{}{
"route_template": routePattern,
"method": r.Method,
"status_code": recorder.StatusCode,
"status": status,
"latency_ms": float64(time.Since(startedAt).Microseconds()) / 1000,
"request_id": requestID,
})이벤트 스키마
route_template, 방법 및 status_code
상태, latency_ms 및 request_id
서비스, 환경, 릴리스
설정 확인하기
체크포인트 1
리소스 식별자당 하나의 그룹을 피하려면 r.URL.Path 대신 라우터 패턴을 사용하세요.
체크포인트 2
문서화된 동일한 결과 모델에서 패닉과 조기 종료를 포착합니다.
체크포인트 3
수집 오류가 애플리케이션 응답을 덮어쓰지 않도록 하세요. 서비스의 진단 경로를 통해 이를 보고합니다.
검증
이벤트가 도착했음을 증명하세요.
알려진 성공 및 실패 사례를 연습한 후 이를 실행하십시오. 최종 이벤트 계약이 스니펫과 다른 경우 대체 테이블 이름을 바꾸세요.
Go HTTP server structured logging 확인 쿼리
SELECT *
FROM api_request_completed
ORDER BY timestamp_utc DESC
LIMIT 20;구현 참조
새로운 프로덕션 경로를 활성화하기 전에 이벤트 계약, 데이터 안전 지침, 업스트림 기본 문서를 검토하세요.
이벤트를 기록할 위치
결과 이벤트를 작고 복구 가능하게 유지
이 패턴은 다음을 제공합니다.
- 업스트림 워크플로우 옆에 제한된 SQL 지원 결과가 있습니다.
- 대시보드, 알림 및 교차 이벤트 상관 관계를 위한 안정적인 필드입니다.
- 성공, 실패, 재시도 및 시간 초과 동작을 검증하기 위한 고정 장치 기반 경로입니다.
이 패턴은 제공하지 않습니다
- OTLP 내보내기, 자동 수집 파이프라인 또는 자세한 추적 및 진단 로그를 대체합니다.
- 페이로드에 이벤트 ID가 포함되어 있기 때문에 정확히 한 번만 전달됩니다.
- 원시 공급자 페이로드, 사용자 콘텐츠, 자격 증명 또는 규제 데이터를 수집할 수 있는 권한입니다.
이벤트 스키마 예제
이 워크플로의 이벤트 스키마
쿼리 또는 스니펫을 프로덕션에 적용하기 전에 행 그레인, 방출 경계, 필수 유형, 개인 정보 보호 클래스, 예제 페이로드 및 유효성 검사 체크리스트를 검토하세요.
관련 제품 기능
이 워크플로를 다음에서 계속하세요. 알림
검토된 신뢰성 쿼리를 소유한 임계값 및 응답 워크플로로 승격합니다.
관련 SQL 레시피
더 많은 SQL 예제
이 워크플로의 구조화된 필드에 대해 쿼리를 실행하고, 예제 결과를 검사하고, 유용한 답변을 대시보드 또는 알림으로 전환하세요.
경로별 API 오류율 계산
요청이 20건 이상인 API 경로 중 5xx 오류율이 가장 높은 경로는 무엇인가요?
레시피 열기p50, p95 및 p99 API 대기 시간 계산
꼬리 지연 시간이 가장 긴 엔드포인트는 무엇입니까?
레시피 열기릴리스별 API 신뢰성 비교
어떤 릴리스가 더 나쁜 API 오류 또는 꼬리 지연 시간과 일치합니까?
레시피 열기구현 제품군별로 찾아보기
관련 통합 패턴 비교
이 통합과 페어링할 템플릿
더 많은 통합
Pino 구조화된 이벤트 분석
Node.js 요청, 작업 및 제품 신뢰성 분석을 위해 Pino 진단 로그를 제한된 Telemetry 결과 이벤트와 결합합니다.
가이드 열기NestJS 요청 및 워크플로 Telemetry
정규화된 경로 결과, 대기 시간, 오류, 릴리스 및 승인된 계정 컨텍스트를 사용하여 NestJS 컨트롤러 및 공급자를 계측합니다.
가이드 열기구글 클라우드 실행 Telemetry
애플리케이션 소유의 구조화된 이벤트를 통해 Cloud Run 요청 및 작업 결과, 콜드 스타트 컨텍스트, 인스턴스 동시 실행, 재시도, 지연 시간, 출시를 추적하세요.
가이드 열기