콘텐츠로 이동

자주 묻는 질문


이벤트 조회 및 시간 범위


"미복구 이벤트"는 기본적으로 최근 48시간만 표시되는데, 더 이전의 미복구 이벤트를 확인하려면 어떻게 해야 하나요?

페이지 오른쪽 상단에 있는 시간 위젯을 통해 시간 범위를 자유롭게 조정할 수 있습니다.


"모든 이벤트"와 "미복구 이벤트" 두 탭의 차이점은 무엇인가요? 두 탭 모두에서 미복구 이벤트를 필터링할 수 있는 이유는 무엇인가요?

비교 항목 미복구 이벤트 모든 이벤트
기본 시간 범위 최근 48시간 일반적으로 더 김 (구성 가능)
기본 필터 조건 df_status != ok 없음
표시 내용 비정상 상태 이벤트만 전체 상태 (정상/비정상/복구/데이터 누락)
용도 현재 문제 빠르게 확인 전체 이력 조회 및 분석

핵심 차이점: "미복구 이벤트"는 바로가기로, 자동으로 필터가 적용됩니다. "모든 이벤트"는 수동으로 필터 조건을 추가해야 하지만, 유연성이 더 높습니다.


시간 위젯을 조정하면 이전에 설정한 필터 조건이 초기화되나요?

초기화되지 않습니다. 시간 범위 조정은 독립적이며, 사용자가 설정한 필터 조건(이벤트 등급, 알림 정책, 모니터 이름 등)은 그대로 유지되며, 시스템은 새로운 시간 범위 내에서 해당 필터 조건을 적용합니다.


이벤트 내용 및 변수


이벤트 내용의 변수(예: {{df_dimension_tags}}, {{Result}})가 비어 있거나 형식이 맞지 않습니다. 어떻게 디버깅하나요?

변수 출처: 이벤트 내용의 변수는 모니터의 이벤트 알림 구성 영역에서 정의되며, 시스템이 실제 모니터링 데이터를 기반으로 대체합니다.

일반적인 빈 값 원인:

  1. DQL 쿼리가 해당 필드를 반환하지 않음
  2. 변수명 철자 오류 (대소문자 구분)
  3. 감지 차원 태그가 비어 있음

디버깅 방법:

  1. 이벤트 상세의 감지 지표 영역에서 원본 쿼리 결과 확인
  2. 모니터의 DQL 쿼리문이 올바른지 확인

자주 사용하는 변수 참고:

  • {{Result}} - 감지 값
  • {{df_dimension_tags}} - 감지 차원 태그 JSON
  • {{df_status}} - 이벤트 상태
  • {{df_monitor_name}} - 모니터 이름
  • {{date}} - 이벤트 생성 타임스탬프

이벤트 제목과 이벤트 내용의 차이점은 무엇인가요? 알림 시 어떤 것이 전송되나요?

  • 이벤트 제목: 이벤트 목록에 표시되며, 알림 제목(이메일 제목, DingTalk 메시지 제목 등)으로도 사용됩니다.
  • 이벤트 내용: 이벤트 상세 페이지에 표시되는 내용이며, 기본 알림 본문으로도 사용됩니다.

알림 내용 사용자 지정:

모니터는 "알림 내용 사용자 지정" 기능을 지원합니다. 이 기능을 활성화하면:

  • 이벤트 내용은 계속 이벤트 상세에 저장됨
  • 그러나 알림은 사용자 지정 템플릿을 사용하여 전송됨
  • 알림 채널별로 다른 내용을 맞춤 설정해야 하는 경우에 적합

이벤트 내용에서 지원하는 템플릿 함수는 무엇인가요? 숫자를 백분율로 포맷팅할 수 있나요?

현재 명시적으로 지원되는 템플릿 함수:

함수 기능 예시
to_datetime 타임스탬프를 날짜로 변환 {{ date \| to_datetime }}
to_status_human 상태를 읽기 쉬운 텍스트로 변환 {{ df_status \| to_status_human }}
to_fixed(n) 소수점 자릿수 고정 {{ Result \| to_fixed(2) }}
to_percent 백분율로 변환 {{ Result \| to_percent }}
to_pretty_tags 태그 출력을 보기 좋게 변환 {{ df_dimension_tags \| to_pretty_tags }}

이벤트 상태 및 복구

이벤트 복구는 자동인가요, 수동인가요? 일부 이벤트가 계속 미복구 상태로 표시되는 이유는 무엇인가요?

자동 복구: 모니터가 지표 정상화를 감지하면 자동으로 복구 이벤트가 생성되며, df_statusok로 변경됩니다.

수동 복구: 이벤트 목록 또는 상세 페이지에서 수동으로 이벤트를 복구할 수 있습니다.

일반적인 미복구 원인:

  1. 모니터 구성 문제: 복구 조건이 올바르게 구성되지 않음
  2. 데이터 누락 이벤트: 복구 정책이 구성되지 않았거나 데이터가 다시 보고되지 않음
  3. 감지 로직 문제: 임계값 설정으로 인해 자동 복구 판단이 불가능함

모니터가 음소거된 기간 동안 생성된 이벤트가 이벤트 목록에 표시되나요? 상태는 어떻게 되나요?

이벤트 목록에 표시되지만, 다음과 같은 차이가 있습니다:

  • 알림이 전송되지 않음
  • 인시던트가 동기 생성되지 않음 (동기 생성이 구성된 경우)
  • 이벤트 상태는 정상적으로 기록됨 (critical/warning 등)

음소거는 알림 전송만 중단할 뿐, 이벤트 자체의 생성 및 기록에는 영향을 미치지 않습니다.

데이터 누락 이벤트


데이터 누락 이벤트란 무엇인가요? 어떤 상황에서 활성화해야 하나요?

데이터 누락이란 모니터가 감지 주기 내에 예상된 데이터를 쿼리하지 못한 경우를 의미합니다.

구성 위치: 모니터의 "데이터 누락 이벤트" 구성 영역 (일부 모니터 유형에서 지원)

세 가지 처리 정책:

  1. 이벤트 트리거 안 함 - 자동으로 처리 (무시)
  2. 복구 이벤트 트리거 - 데이터 누락을 비정상 복구로 간주
  3. 데이터 누락 이벤트 트리거 - 전용 누락 알림 생성 (등급 구성 가능)

데이터가 분명히 보고되지 않았는데 데이터 누락 이벤트가 트리거되지 않는 이유는 무엇인가요?

Guance는 "에지 트리거" 메커니즘을 사용하여 데이터 누락을 판단합니다:

이전 쿼리에서 X를 발견했는데, 이번 쿼리에서 X를 찾을 수 없다면, X에 데이터 누락이 발생한 것입니다.

핵심 제한 사항:

  • 최초 감지 시 데이터가 없으면 알림이 생성되지 않음 (시스템이 "원래 있어야 할" 데이터를 알 수 없음)
  • "데이터 있음" 상태를 경험한 후 다시 감지되지 않아야 누락으로 판단됨

문제 해결 제안:

  1. 모니터가 최소 한 번의 감지 주기 동안 정상 실행되어 데이터를 쿼리했는지 확인
  2. "감지 범위 이동" 메커니즘 확인 (실제 감지 시간 범위는 1분 이동됨)
  3. 모니터 실행 로그를 확인하여 DQL 쿼리가 성공했는지 확인

데이터 누락 이벤트와 데이터 복구 이벤트의 생성 로직은 무엇인가요?

교대 생성 메커니즘:

  • 데이터 누락 이벤트와 데이터 복구 이벤트는 항상 교대로 생성됨
  • 연속적인 데이터 누락 이벤트가 생성되지 않음
  • 연속적인 데이터 복구 이벤트도 생성되지 않음

판단 프로세스:

최초 감지 데이터 없음 → 알림 없음
데이터 감지됨 → "데이터 있음" 상태 기록
다시 데이터 없음 감지 → 데이터 누락 이벤트 트리거
데이터 재보고됨 → 데이터 복구 이벤트 트리거
다시 데이터 없음 감지 → 데이터 누락 이벤트 트리거 (새로운)


이벤트 연관 및 문제 해결


이벤트 상세 페이지의 "연관 이벤트"는 어떻게 연관되나요? 때로는 비어 있는 이유는 무엇인가요?

연관 로직: - 동일한 감지 차원 태그 기반 (예: host, service 등) - 시간 창 기반 (동일 시간대의 관련 이벤트)

연관이 비어 있는 일반적인 원인:

  1. 해당 차원 태그가 다른 이벤트에 존재하지 않음
  2. 시간 창 내에 다른 관련 이벤트가 없음
  3. 현재 이벤트 유형이 연관을 지원하지 않음 (일부 모니터 유형)

"연관 SLO"가 0으로 표시되는 것은 무엇을 의미하나요? 언제 데이터가 생기나요?

  • 0으로 표시됨: 해당 이벤트가 어떤 SLO 작업에도 연관되지 않았음을 의미
  • 데이터가 있는 경우: 이벤트가 SLO 작업에 의해 트리거된 경우에만 연관된 SLO 정보가 표시됨
  • 모니터가 트리거한 이벤트는 기본적으로 SLO와 연관되지 않음

히스토리 트렌드 차트의 "감지 구간" 점선은 무엇을 의미하나요? 시간 범위를 조정할 수 있나요?

  • 감지 구간 점선: 해당 알림을 트리거한 구체적인 감지 시간 창을 표시
  • 차트 표시: 더 넓은 시간 범위에서 해당 감지 지표의 추세를 보여줌

차트 오른쪽 상단의 "차트 쿼리 가져오기" 버튼을 클릭하여 지표 또는 로그 탐색기로 이동하면, 탐색기에서 시간 범위를 유연하게 조정하여 장기적인 추세 분석을 수행할 수 있습니다.

이벤트 출처 및 필드


다른 출처의 이벤트(모니터, 감사, OpenAPI)는 필드 측면에서 어떤 차이가 있나요?

다른 df_source 값은 각각 다른 추가 필드에 해당합니다:

df_source 출처 추가 필드
monitor 모니터/지능형 모니터링/SLO 모니터 관련 필드 (감지 지표, 임계값 등)
audit 감사 이벤트 작업자, 작업 유형, 변경 상세 등
user OpenAPI 기록 사용자 정의 필드

OpenAPI를 통해 기록된 사용자 정의 이벤트와 시스템 생성 이벤트는 사용상 어떤 차이가 있나요?

기능 차이: - 사용자 정의 이벤트는 df_status, df_title, df_message 등의 필드를 설정할 수 있음 - 연관을 위해 df_dimension_tags를 지정할 수 있음 - 모니터 이벤트처럼 대시보드와 자동으로 연관되지 않음 - 이벤트 복구 로직을 직접 처리해야 함 (API를 통한 복구 인터페이스 호출)

사용 사례: 외부 시스템 연동, 사용자 정의 비즈니스 알림, 대량의 이력 이벤트 가져오기 등.

감사 이벤트


감사 이벤트는 구체적으로 어떤 작업을 기록하나요? 어디서 확인할 수 있나요?

확인 위치: 관리 > 기본 설정 > 보안 > 작업 감사

일반적인 기록 범위:

  • 데이터 권한 추가/삭제 (워크스페이스 간 권한 부여)
  • 모니터, SLO, 알림 정책 등 구성의 생성/수정/삭제
  • 워크스페이스 멤버 권한 변경

필드 특징: df_source = audit, 작업자, 작업 시간, 작업 유형 등 감사 전용 필드를 포함합니다.

자주 묻는 문제 해결


이벤트 상세에 표시되는 시간과 실제 장애 발생 시간이 일치하지 않는 이유는 무엇인가요?

이는 정상적인 현상이며, 이유는 두 가지입니다:

  1. 예약 트리거 시간 vs 실제 실행 시간:

    • 이벤트에 표시된 시간은 모니터의 예약 트리거 시간 (Crontab 기반의 정리된 시간)입니다.
    • 시스템에서 이벤트가 실제로 생성된 시간이 아닙니다.
  2. 감지 범위 이동:

    • 실제 감지된 데이터 범위는 예약 트리거 시간 - 감지 범위 - 1분부터 예약 트리거 시간 - 1분까지입니다.
    • 따라서 장애 데이터의 타임스탬프가 이벤트 표시 시간보다 더 이를 수 있습니다.

문제 해결 제안: 이벤트 상세의 "감지 지표" 영역을 확인하여 실제 감지된 데이터 시간 범위를 확인하세요.


플랫폼에서 직접 조회하면 장애 데이터가 보이는데, 모니터가 이벤트를 생성하지 않은 이유는 무엇인가요?

일반적인 원인:

  1. 데이터 저장 지연: 감지 실행 시 장애 데이터를 아직 쿼리할 수 없음 (모니터는 자동으로 1분 이동하여 회피하지만, 지연이 1분을 초과하면 무효화됨)
  2. DQL 쿼리 실패: 감지 과정이 쿼리 실패로 중단됨
  3. 모니터 음소거: 음소거 기간 중에는 알림이 전송되지 않지만, 이벤트는 여전히 생성됨 (이벤트 목록 확인 필요)
  4. 임계값 구성: 실제 감지 값이 트리거 임계값에 도달하지 않음

이벤트 데이터는 얼마나 오래 보관되나요? 내보내거나 보관하는 방법은 무엇인가요?

장기 보관 방안:

  • Dataway Sink 기능을 사용하여 이벤트 데이터를 외부 저장소로 분산 전송
  • OpenAPI를 통해 주기적으로 이벤트 데이터를 로컬 저장소로 가져오기
  • 데이터 전송 기능을 사용하여 Kafka, S3 등 외부 시스템으로 전달

문서 평가

이 페이지가 도움이 되었나요?