Kubernetes SQL을 통한 신뢰성 모니터링
Kubernetes는 수명이 짧은 개체를 많이 생성하므로 포드별로 원시 관찰을 그룹화하면 잡음이 많은 보고서가 생성되는 경우가 많습니다. 워크로드 경계(클러스터, 네임스페이스, 배포 또는 작업 소유자, 애플리케이션 릴리스, 제어된 전환, 준비 결과, 워크로드가 수행하는 고객 대면 작업)에서 시작하세요.
게이지에서 별도의 전환
관찰된 재시작 카운터가 증가하면 container_restarted 이벤트를 내보냅니다. 누적 카운터를 컨텍스트로 유지하되 샘플 전체에서 합산하지 마세요. 별도의 부울 관찰로 준비 상태를 기록합니다. 계획된 롤아웃은 정상 상태의 포드를 대체할 수 있는 반면, 충돌 루프는 반복적인 재시작 전환을 생성하고 종종 지속적인 준비 상태 손실을 발생시킵니다.
제한된 클러스터, 네임스페이스 및 워크로드 이름을 사용합니다. Kubernetes 비밀, 환경 변수 값, 전체 매니페스트, 컨테이너 인수, 원시 로그 메시지 또는 고객 페이로드를 이벤트에 복사하지 마세요.
불안정한 워크로드 순위
Kubernetes 재시작 SQL 레시피는 관찰을 워크로드별로 그룹화하고, 재시작 전환을 계산하고, 관찰된 최대 카운터를 보존하고, 준비되지 않은 비율을 계산합니다. 해당 고정 장치는 전환 횟수와 누적 재시작 상태 간의 차이를 보여줍니다.
다음 순서로 결과를 조사합니다.
- 롤아웃 교체뿐 아니라 재시작이 반복되는지 확인합니다.
- 동일한 기간 동안 준비 손실이 발생했는지 확인합니다.
- 릴리스, 노드 풀, 클러스터, 통제된 사유 카테고리를 비교하세요.
- API 오류, 작업 지연 또는 기타 제품 결과와 함께 타이밍에 동참하세요.
인프라 레시피 컬렉션은 리소스 포화도, 하트비트 및 사고 타이밍을 추가합니다. 이러한 신호는 애플리케이션 오류와 용량 압박 또는 광범위한 클러스터 문제를 구별하는 데 도움이 됩니다.
수집기-이벤트 경계 및 워크로드-소유자 정규화를 구축할 때 Kubernetes 통합 가이드부터 시작하세요.
이탈이 아닌 영향에 대한 알림
워크로드 대시보드는 재시작 전환, 준비 상태, 롤아웃 마커 및 애플리케이션 오류율을 함께 유지해야 합니다. 지속적인 상태를 검토한 후에만 페이지로 이동합니다. 하나의 포드 일정이 변경되거나 예상되는 배포 교체는 일반적으로 실행 가능하지 않습니다.
Kubernetes 신뢰성 사용 사례는 이벤트 계약에 대한 코딩 에이전트 프롬프트를 제공합니다. 프로덕션 응답에 대한 쿼리를 사용하기 전에 합성 재시작, 롤아웃, 복구 및 지연된 이벤트 사례를 검증합니다.