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

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

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

이 페이지에서
  1. 애플리케이션 경계에서 제한된 이벤트 방출
  2. 신뢰성 질문을 분리하세요
  3. OpenTelemetry 데이터베이스 필드를 의도적으로 매핑
  4. 순서대로 조사하다
  5. 애플리케이션 측 경계 파악
  6. 검증된 쿼리를 작업으로 전환

SQL을 통한 데이터베이스 신뢰성 모니터링

데이터베이스 증상은 서버 메트릭에서 명확하게 나타나기도 전에 애플리케이션에 나타나는 경우가 많습니다. 호출자가 연결을 기다리거나, 한 작업 지문이 느려지거나, 트랜잭션 롤백, 사용자 작업 잠금이 차단되거나, 복제본이 뒤쳐지거나, 릴리스 중 마이그레이션이 실패하는 등의 현상이 발생합니다. 구조화된 애플리케이션 이벤트는 해당 결과를 응답하는 데 필요한 서비스, 릴리스, 경로, 테넌트 영향 및 제어된 오류 범주와 연결합니다.

애플리케이션 경계에서 제한된 이벤트 방출

각 데이터베이스 작업 또는 논리적 트랜잭션에 대해 하나의 완료 이벤트를 기록합니다. 원시 SQL 대신 제어된 작업 이름이나 정규화된 지문을 사용하세요. 영향 분석을 지원하는 경우에만 기간, 결과, 데이터베이스 역할, 서비스, 릴리스 및 개인 정보 보호 계정 식별자를 포함합니다.

쿼리 매개변수, 연결 문자열, 자격 증명, 인증 데이터 또는 무제한 SQL 텍스트를 기록하지 마세요. deadlock, serialization_failureconnection_timeout와 같은 오류 범주는 원시 예외 메시지보다 그룹화하기가 더 안전하고 쉽습니다.

{
  "event_name": "database_query_completed",
  "query_fingerprint": "checkout.select_with_line_items",
  "service": "checkout-api",
  "database_name": "app_production",
  "status": "success",
  "duration_ms": 842,
  "rows_returned": 4,
  "release": "2026.07.2",
  "environment": "production"
}

node-postgres 통합 또는 Prisma 통합을 시작점으로 사용한 다음 래퍼를 중앙 집중화하여 모든 작업이 동일한 필드 이름, 시계, 상태 값 및 수정 정책을 사용하도록 합니다.

신뢰성 질문을 분리하세요

하나의 일반적인 "데이터베이스 상태" 점수는 다양한 실패 모드를 숨깁니다. 다음과 같은 경우에는 집중된 이벤트 테이블이나 안정적인 이벤트 이름을 사용하세요.

  1. 쿼리 완료: 기간, 정규화된 지문, 행, 결과 및 릴리스.
  2. 풀 상태: 활성, 유휴, 구성된 최대값, 획득 대기 및 시간 초과.
  3. 트랜잭션: 논리적 트랜잭션 식별자, 커밋 또는 롤백, 제어된 오류 유형.
  4. 잠금 대기: 차단 및 차단 지문, 대기 기간, 해결 및 교착 상태 감지.
  5. 복제 또는 CDC: 소비자, 지역, 뒤처진 초 및 바이트, 현재 상태.
  6. 마이그레이션: 마이그레이션 식별자, 릴리스, 기간, 터미널 상태 및 롤백 범주.

데이터베이스 신뢰성 레시피 모음에는 스키마, 테스트된 쿼리, 결정론적 결과, 시각화, 엣지 케이스, 대시보드 계획 및 각 질문에 대한 알림 지침이 포함되어 있습니다. 포함된 조명기를 적용하기 전에 읽기 전용 브라우저 SQL 플레이그라운드에서 실행할 수 있습니다.

OpenTelemetry 데이터베이스 필드를 의도적으로 매핑

애플리케이션이 이미 OpenTelemetry 데이터베이스 범위를 내보내는 경우 경쟁 어휘를 생성하는 대신 필드의 안정적인 의미를 재사용하세요. 현재 OpenTelemetry 데이터베이스 클라이언트 범위 규칙db.system.name, 낮은 카디널리티 db.operation.name, db.namespace, db.collection.name, db.query.summary 및 데이터베이스 응답 상태를 정의합니다. 맥락. 또한 쿼리 텍스트는 카디널리티가 높을 수 있으며 정리가 필요하다고 알림합니다.

실용적인 구조적 이벤트 매핑은 다음과 같습니다.

OpenTelemetry 컨텍스트 구조화된 이벤트 필드 리뷰 노트
db.system.name database_system 제한된 데이터베이스 제품 식별자를 유지합니다.
db.operation.name operation_name SELECT와 같은 제어 동사 또는 안정적인 클라이언트 작업을 사용하세요.
db.query.summary query_fingerprint 수집 전에 생성된 낮은 카디널리티 요약을 선호합니다.
db.response.status_code database_status_code 의미 체계가 문서화된 경우에만 드라이버 또는 데이터베이스 코드를 보존하십시오.
기간 duration_ms 풀 획득 및 네트워크 시간이 포함되는지 여부를 명시합니다.
추적 및 범위 컨텍스트 trace_id, span_id 범위 페이로드를 복사하지 않고 상관 관계에 식별자를 사용합니다.

매핑은 필드가 안전하다는 자동 증명이 아닙니다. 쿼리 요약, 컬렉션 이름, 네임스페이스 및 응답 메시지는 일부 시스템에서 여전히 테넌트 또는 스키마 세부 정보를 노출할 수 있습니다. 실제 방출된 값을 검토하고, 카디널리티를 제한하고, 원시 쿼리 텍스트와 바인딩된 값을 기본적으로 유지합니다.

순서대로 조사하다

고객이 볼 수 있는 기간과 실패율로 시작한 다음 풀 획득이 대기 시간을 설명하는지 확인하세요. p95 기간과 총 쿼리 시간을 기준으로 작업 순위를 매깁니다. 수천 번 실행된 적당히 느린 쿼리는 드물게 발생하는 이상값보다 더 많은 애플리케이션 시간을 소비할 수 있습니다. 원시 메시지를 그룹화하는 대신 SQLSTATE 또는 다른 제어된 드라이버 코드를 작업 및 릴리스별로 비교하십시오.

실패가 트랜잭션인 경우 터미널 오류에서 예상되는 재시도 가능한 롤백을 분할하고 장기 실행 트랜잭션 클래스를 별도로 검토합니다. 동시 작성자가 관련된 경우 잠금 대기 및 교착 상태 이벤트를 검사합니다. 풀 포화를 크기 조정 문제로 해석하기 전에 연결 열기, 닫기, 획득 시간 초과 및 영향을 받는 요청을 비교하십시오. 다운스트림 읽기 모델을 신뢰하기 전에 애플리케이션에서 관찰된 오래된 읽기 및 장애 조치 결과 옆에 복제본 또는 CDC 지연을 확인하세요. 마이그레이션 실패를 배포 타임스탬프와 일치시킵니다.

활용도만으로 연결 풀 제한을 늘리지 마십시오. 풀이 크면 경합이 데이터베이스로 이동할 수 있습니다. 대기 중인 호출자 또는 시간 초과를 요구하고, 데이터베이스 용량을 확인하고, 변경 사항을 모니터링합니다.

애플리케이션 측 경계 파악

이러한 이벤트는 어떤 애플리케이션 워크플로, 릴리스, 지역 또는 고객 대상 요청에서 데이터베이스 증상이 발생했는지 응답합니다. 이는 데이터베이스 자체 진단 시스템을 대체하지 않습니다. 다음 용도로 데이터베이스 기반 도구를 사용하세요.

  • 쿼리 계획, 최적화 프로그램 추정, 버퍼 및 캐시 동작, 테이블 통계, 진공 또는 압축 상태.
  • 서버 대기 이벤트, 잠금 그래프, 활성 세션 검사, 스토리지 대기 시간 및 리소스 포화도.
  • 복제 토폴로지, 미리 쓰기 로그 보존, 장애 조치 조정, 백업 확인 및 특정 시점 복구.
  • 데이터베이스 또는 보안 프로그램에 필요한 권위 있는 감사, 액세스 제어, 암호화 및 규정 준수 증거.

조사 중에 두 가지 보기를 결합하십시오. 즉, 구조화된 애플리케이션 이벤트를 사용하여 영향과 소유권을 찾은 다음 제한된 데이터베이스 진단을 사용하여 서버 측 원인을 설명합니다. 조인을 편리하게 하기 위해 중요한 서버 진단을 광범위한 분석 테이블에 복사하지 마십시오.

검증된 쿼리를 작업으로 전환

대시보드는 모든 요율 외에 볼륨을 유지하고, 완전한 UTC 버킷을 사용하고, 집계에서 최근 안전 이벤트까지의 경로를 보존해야 합니다. 알림에는 지속적인 조건, 최소 볼륨, 소유자 및 문서화된 응답이 필요합니다. 단일 느린 쿼리, 짧은 지연 급증 또는 예상되는 롤백이 페이지를 정당화하는 경우는 거의 없습니다.

쿼리에 의존하기 전에 합성 성공, 시간 초과, 교착 상태, 중복 및 지연된 이벤트 사례를 테스트하세요. 대시보드 옆에 이벤트 버전과 임계값을 기록합니다. SQL 방법론은 자동화된 레시피 확인을 설명합니다. 데이터베이스 안정성 사용 사례는 결과 신호를 구현 워크플로에 연결합니다.

관련 제품 기능

구조화된 이벤트 테이블에 대해 읽기 전용 DataFusion SQL을 실행하고 결과를 재사용합니다.

소유권 및 기술 참조

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

편집 기준 검토