Skip to main content
라우팅과 정제된 분류에는 상태 응답을 사용하세요. 진단에는 보호된 로그, 메트릭, 제공자 감사 기록, 데이터베이스 상태를 사용하세요.

​
웹 상태 엔드포인트

준비 상태 범주는 configuration, authentication, tls, storage, capability, canary_stale뿐입니다. 응답은 의도적으로 제공자, 엔드포인트, 버킷 이름, 객체 키, 자격 증명, 원시 오류를 생략합니다.
쓰기가 안전하다고 판단하기 위해 liveness를 사용하지 마세요. 프로브 URL에 자격 증명을 넣지 마세요.

​
Deep 카나리

예약된 deep 카나리는 임의 바이트를 ephemeral에 쓰고, SHA-256 메타데이터를 기록하고, 정확한 바이트를 읽어 해시하고, 복사하여 검증한 다음 두 객체를 삭제합니다. 최신성 창 안에 성공한 카나리가 없으면 준비 상태는 canary_stale을 보고합니다. 오래된 카나리의 경우:
  1. 웹 instrumentation이 카나리 스케줄러를 시작했는지 확인하고;
  2. storage.readiness, storage.operation.*, 제공자 지연을 검사하며;
  3. ephemeral이 조건부 생성, 읽기, 복사, 삭제를 허용하는지 확인하고;
  4. 워커/웹 시계와 이벤트 루프 포화를 점검하며;
  5. 수명 주기 정책이 트랜잭션 중에 카나리 객체를 삭제하지 않는지 확인하고;
  6. 동일한 네트워크와 아이덴티티 컨텍스트에서 제공자 계약을 실행하세요.
실패를 숨기기 위해 경과 시간 임계값을 영구적으로 늘리지 마세요.

​
범주별 분류

​
configuration

STORAGE_CONFIG_FILE의 가독성/모드와 엄격한 JSON을 검증하세요. 세 프로필이 모두 존재해야 합니다. 정규 제공자 ID s3, gcs, azure, 또는 local을 사용하세요. 프로덕션은 local을 사용할 수 없습니다.

​
authentication

워크로드 아이덴티티 바인딩, 역할 범위, 토큰 audience, 자격 증명 로테이션 중첩, 제공자 감사 거부를 확인하세요. 웹과 워커는 일치하는 액세스가 필요합니다. 토큰을 출력하거나, env를 실행하거나, Secret 데이터를 티켓에 복사하지 마세요.

​
tls

엔드포인트 DNS/SAN, 프라이빗 CA 마운트, 완전한 발급 체인, 만료, 프록시 신뢰, CA 로테이션 후 파드 재시작을 확인하세요. 검증을 활성화한 상태로 유지하고 HTTP, --insecure, rejectUnauthorized: false를 사용하지 마세요.

​
storage

기존 버킷/컨테이너, 경로, DNS, egress, 할당량, 스로틀링, 용량, 필수 객체 작업을 확인하세요. 상태 검사는 누락된 스토리지를 생성하지 않습니다.

​
capability

WORM이 필요할 때 프로필 requireWorm, 버전 관리, 객체 보존/불변성, 법적 홀드를 검증하세요. 정책 변경 후 실환경 자격 검증을 다시 실행하세요.

​
스캐너 장애

증상에는 증가하는 storage.quarantine.depth, storage.quarantine.oldest_age_seconds, storage.scanner.failure, outbox 재시도, 최종 데드 레터가 포함됩니다. clamd 소켓/호스트, TLS CA, 서버 이름, 크기 제한, 시간 초과, 네트워크 정책, 엔진 상태, 시그니처 업데이트 상태를 확인하세요. 스캐너를 복원한 다음 정상적인 멱등 재시도를 허용하거나 승인된 재생 절차를 사용하세요. 객체는 최종 깨끗한 판정이 나올 때까지 quarantine 상태로 남아야 합니다. 수동으로 깨끗하다고 표시하거나 스캔을 우회하지 마세요.

​
변경 데드 레터

storage.outbox.deadletter, storage.outbox.pending, storage.outbox.deadlettered를 모니터링하세요. 페이로드나 객체 키를 불필요하게 내보내지 않고 ID/상태/작업으로 보호된 StorageMutationOutbox 레코드를 검사하세요.
  1. 스캐너, 권한, 보존, TLS, 누락 객체, 또는 제공자 장애로 분류하고;
  2. 원인을 복구하며;
  3. 객체가 저장된 SHA-256 및 정확한 버전과 여전히 일치하는지 확인하고;
  4. 승인된 멱등 큐 작업을 통해 재생한 다음;
  5. 완료와 감사 증거를 확인하세요.
대시보드를 녹색으로 만들기 위해 데드 레터 행을 삭제하지 마세요. 보존으로 차단된 삭제는 강제 삭제할 객체가 아니라 해결해야 할 정책 실패입니다.

​
마이그레이션 및 조정

storage.migration.result, storage.reconciliation.missing, storage.reconciliation.orphan_observed, storage.reconciliation.orphan_confirmed, 조정 outbox 복구 메트릭을 모니터링하세요.
  • 누락된 예상 객체는 quarantine/실패한 무결성 상태로 되돌아갑니다.
  • orphan은 먼저 관찰되고 유예 기간 후에만 확인됩니다.
  • 마이그레이션 재시도는 DEAD_LETTER에 도달할 수 있습니다. 소스를 유지하고 재생 전에 조사하세요.
확인된 orphan을 자동으로 삭제하지 마세요. 업로드 세션, 마이그레이션 원장, 제공자 버전, 보존, 법적 홀드와 상관관계를 확인하세요.

​
안전한 검증

전용 접두사와 워크로드와 동등한 아이덴티티를 사용하세요.
ODF/Ceph의 경우 정확한 버전과 프라이빗 CA로 ./scripts/storage/validate-ceph-rgw.sh를 사용하세요. 인시던트에 첨부하기 전에 출력을 정제하세요.