콘텐츠로 건너뛰기
Telemetry
통합 가이드

Kubernetes 워크로드 Telemetry

워크로드 수준 SQL 분석을 위해 제한된 Kubernetes 재시작, 준비 및 롤아웃 관찰을 Telemetry로 보냅니다.

검토자 Telemetry 제품 팀 . 계측 계약, 개인 정보 보호 경계 및 구현 지침. 표준 및 소유권 검토

다음에 유용합니다.
  • 컨테이너 재시작 분석
  • 준비 상태 및 출시 모니터링
  • 워크로드-애플리케이션 사고 상관관계
구현 증거

Kubernetes Workload Telemetry: 경계에서 검증된 행까지

제어된 애플리케이션 경계에서 Kubernetes Workload Telemetry를 사용하고, 이벤트 계약을 작게 유지하고, 집계 뷰를 구축하기 전에 알려진 결과를 확인하세요.

  1. 1

    결과를 선택하세요

    컨테이너 재시작 분석

  2. 2

    계약 정의

    클러스터, 네임스페이스, 워크로드, 포드, event_name 및 환경

  3. 3

    경계 계측

    보고하기 전에 각 포드를 해당 배포, StatefulSet, DaemonSet 또는 작업 소유자로 확인하여 대시보드가 단기 포드 이름에 걸쳐 조각화되지 않도록 하세요.

  4. 4

    증거를 확인하세요

    Exercise a known fixture, then inspect kubernetes_workload_event for one correctly typed terminal row.

시작하기 전에

전제 조건 및 경계

  • 범위 내 워크로드 상태 필드에 대한 읽기 전용 액세스 권한이 있는 수집기 또는 컨트롤러
  • 안정적인 클러스터, 네임스페이스, 워크로드 소유자 및 애플리케이션 릴리스 레이블
  • 비밀, 매니페스트, 환경 값, 원시 로그 및 고객 페이로드를 제외하는 수정 정책

배송 설정

서버 측 설치 및 초기화

서버 전용 코드에서 telemetry-sh를 가져오고 process.env.TELEMETRY_API_KEY로 한 번 초기화합니다. 브라우저 번들, 클라이언트에 표시되는 환경 변수, 소스 제어, 로그 및 예외 메시지에서 수집 자격 증명을 유지하세요.

kubernetes-설치

npm 설치

bash
npm install telemetry-sh
  1. 1제한된 네트워크 동작을 갖춘 재사용 가능한 서버 측 전달 클라이언트 하나를 준비합니다.
  2. 2성공, 실패, 재시도 또는 시간 초과 경계에 결과 이벤트를 추가합니다.
  3. 3알림을 활성화하기 전에 제어된 고정 장치를 보내고 저장된 행을 검사하십시오.

스니펫

하나의 체계적인 이벤트로 시작하세요

워크플로가 완료, 실패 또는 재시도되는 위치에 이 셰이프를 추가합니다. 그런 다음 실제 필드에서 대시보드를 구축합니다.

kubernetes

Kubernetes Workload Telemetry 이벤트

javascript
import telemetry from "telemetry-sh";

export async function logKubernetesWorkloadSample({
  cluster,
  namespace,
  workload,
  pod,
  restartCount,
  ready,
  applicationRelease,
  previousRestartCount,
}) {
  const eventName =
    restartCount > previousRestartCount
      ? "container_restarted"
      : "workload_sampled";

  await telemetry.log("kubernetes_workload_event", {
    cluster,
    namespace,
    workload,
    pod,
    event_name: eventName,
    restart_count: restartCount,
    ready,
    application_release: applicationRelease,
    environment: "production",
  });
}

이벤트 계약

클러스터, 네임스페이스, 워크로드, 포드, event_name 및 환경

restart_count, 준비됨, rollout_id, application_release 및 observed_generation

소스 값이 수집 승인된 경우에만 제한된 사유 범주

구현 체크포인트

체크포인트 1

보고하기 전에 각 포드를 해당 배포, StatefulSet, DaemonSet 또는 작업 소유자로 확인하여 대시보드가 단기 포드 이름에 걸쳐 조각화되지 않도록 하세요.

체크포인트 2

누적 카운터가 증가하면 container_restarted 전환을 내보냅니다. 카운터를 컨텍스트로 유지하고 게이지 샘플을 합산하지 마십시오.

체크포인트 3

페이징하기 전에 반복적인 재시작과 지속적인 준비 상태 손실 및 애플리케이션 결과를 연관시키십시오.

검증

이벤트가 도착했음을 증명하세요.

알려진 성공 및 실패 사례를 연습한 후 이를 실행하십시오. 최종 이벤트 계약이 스니펫과 다른 경우 대체 테이블 이름을 바꾸세요.

kubernetes-검증

Kubernetes Workload Telemetry 확인 쿼리

sql
SELECT *
FROM kubernetes_workload_event
ORDER BY timestamp_utc DESC
LIMIT 20;
예상 상태, 식별자, 단위 및 UTC 시간을 사용하여 논리적 결과당 하나의 터미널 행을 확인합니다.
유추된 스키마를 검사하고 재시도가 필드 유형을 변경하거나 새 논리적 이벤트 ID를 생성하지 않는지 확인합니다.
자격 증명, 원시 페이로드, 프롬프트, 비공개 콘텐츠 및 무제한 오류 메시지에 대해 저장된 필드를 검색합니다.
대시보드를 완전한 것으로 처리하기 전에 공급자 시간 초과, 수집 거부 및 프로세스 종료를 실행합니다.

구현 참조

새로운 프로덕션 경로를 활성화하기 전에 이벤트 계약, 데이터 안전 지침, 업스트림 기본 문서를 검토하세요.

프로덕션 경계

결과 이벤트를 작고 복구 가능하게 유지

이 패턴은 다음을 제공합니다.

  • 업스트림 워크플로우 옆에 제한된 SQL 지원 결과가 있습니다.
  • 대시보드, 알림 및 교차 이벤트 상관 관계를 위한 안정적인 필드입니다.
  • 성공, 실패, 재시도 및 시간 초과 동작을 검증하기 위한 고정 장치 기반 경로입니다.

이 패턴은 제공하지 않습니다

  • OTLP 내보내기, 자동 수집 파이프라인 또는 자세한 추적 및 진단 로그를 대체합니다.
  • 페이로드에 이벤트 ID가 포함되어 있기 때문에 정확히 한 번만 전달됩니다.
  • 원시 공급자 페이로드, 사용자 콘텐츠, 자격 증명 또는 규제 데이터를 수집할 수 있는 권한입니다.

이벤트 스키마 시작점

쿼리 또는 스니펫을 프로덕션에 적용하기 전에 행 그레인, 방출 경계, 필수 유형, 개인 정보 보호 클래스, 예제 페이로드 및 유효성 검사 체크리스트를 검토하세요.

관련 제품 기능

이 워크플로를 다음에서 계속하세요. 알림

검토된 신뢰성 쿼리를 소유한 임계값 및 응답 워크플로로 승격합니다.

관련 SQL 레시피

SQL로 다음 질문에 답하세요

이 워크플로의 구조화된 필드에 대해 쿼리를 실행하고, 예제 결과를 검사하고, 유용한 답변을 대시보드 또는 알림으로 전환하세요.

모든 레시피 찾아보기

구현 제품군별로 찾아보기

관련 통합 패턴 비교

이 통합과 페어링할 템플릿

더 많은 통합