장애 시간의 로그가 중앙 검색에 없더라도, 장애가 없었다고 결론 내릴 수는 없습니다. 먼저 검색한 시간대와 대상 VM이 맞는지 확인하세요. 같은 시간의 로컬 로그와 수집기 오류도 함께 살펴보세요.
시간과 대상부터 맞춰 보세요
사용자가 증상을 겪은 시간 구간을 받아 검색 화면의 시간대와 시각 필드를 확인하세요. OpenTelemetry는 이벤트 발생 시각과 수집 시스템의 관측 시각을 구분합니다. 관측 시각이 중앙 저장 완료 시각은 아니며, 두 값의 차이를 전송 지연으로 단정할 수 없습니다. 필드가 없다면 수집되는 시각 정보와 그 한계를 기록하세요.
사이트·클러스터 범위를 맞춘 뒤 VM 관리 ID와 게스트 식별자를 연결하고, 장애 당시 어느 노드에 있었는지 확인하세요. VM 이름만으로 대상을 정하거나 게스트 식별자가 VM 관리 ID와 같다고 가정하지 마세요. 현재 배치와 장애 당시 배치는 다를 수 있습니다.
검색 공백과 수집 공백을 구분하세요
예를 들어 특정 VM의 중앙 로그만 보이지 않는다면 같은 구간의 로컬 로그, 수집기의 수신·처리·전송 상태, 목적지 상태를 대조하세요. OpenTelemetry Collector 공식 문서는 수신·전송 실패와 데이터 드롭 가능성을 설명합니다. 다른 수집기를 쓴다면 해당 제품의 상태 지표와 설정을 확인해야 합니다.
로컬과 중앙의 보관 조건도 따로 확인하세요. systemd journal은 저장 방식과 기록량 제한, 용량·보존 시간 설정의 영향을 받습니다. 최신 문서의 설정을 대상 Ubuntu VM의 기본값으로 간주하거나, 보존 기간 안의 모든 로그가 남아 있다고 약속할 수는 없습니다.
))
확인한 시간 구간과 대상, 남은 로그 공백을 기록해 다음 담당자에게 넘기세요. 자료가 없는 구간은 무장애나 특정 원인으로 채우지 말고 ‘확인하지 못한 구간’으로 남기세요.
대상 인프라와 필요한 연동 범위는 상담에서 확인하세요. PIVOT 공개 소개의 실제 제공 범위는 도입 버전과 대상 환경을 기준으로 확인합니다.
공식 근거: OpenTelemetry 로그 데이터 모델 · 호스트 식별자 규약 · Collector 문제 해결 · systemd 로그 보관 설정