모니터 내부 원리¶

네트워크, 시스템 부하 등의 요인으로 인해 모니터의 감지 실행에는 몇 가지 특별한 내부 처리 메커니즘이 있습니다.

감지 트리거 시간¶

사용자가 설정한 감지 주기는 시스템 내부에서 Crontab 표현식으로 변환됩니다. 모니터는 이 표현식에 따라 정해진 시간에 시작되며, 생성 또는 저장 후 단순히 N분 간격으로 실행되지 않습니다.

예를 들어, 사용자가 "모니터 A"에 대해 실행 주기를 "5분"으로 설정한 경우, 해당 Crontab 표현식은 */5 * * * *입니다. 구체적인 트리거 시간 관계는 다음과 같습니다.

데이터 대기 창¶

데이터 대기 창은 계획된 실행 시간이 도달한 후 모니터 판단을 의도적으로 지연시켜 지연 보고된 데이터가 저장소에 기록될 더 많은 시간을 확보하기 위한 것입니다.

모니터가 10:00에 실행되도록 계획되고, 감지 구간이 최근 1시간이며, 데이터 대기 창이 5분인 경우를 가정해 보겠습니다.

데이터 대기 창은 실제 실행 시간만 지연시킬 뿐, 쿼리 범위는 계획된 실행 시간을 기준으로 하며 전체적으로 이동하지 않습니다. 대기 중에는 실행 기록 상태가 "데이터 대기 중"으로 표시됩니다. 작업 큐로 인해 실제 실행 시간이 "계획 실행 시간 + 대기 시간"보다 늦어지더라도 작업은 계속 실행되며, 실행 기록에 계획 실행 시간, 대기 구성 및 실제 시작 시간이 기록됩니다.

다음 사항에 유의하십시오.

• 기본적으로 대기하지 않으며, 기존 모니터도 대기 없이 실행됩니다.
• 대기 시간은 인접한 두 번의 계획 실행 시간 간격보다 짧아야 합니다.
• 모니터가 대기 중에 비활성화되거나 삭제되면 아직 실행되지 않은 대기 작업이 취소됩니다.

감지 범위 보정¶

플랫폼은 모든 사용자가 구성한 수천 개의 모니터를 처리해야 하므로, 동시에 트리거된 감지 작업을 동시에 실행할 수 없으며 대부분의 작업은 큐에서 대기합니다.

따라서 대부분의 감지 작업은 계획된 T 시점에 트리거되지만 실제로는 T + Δt 시점에 실행되는 상황이 발생합니다.

실제 실행 시간을 쿼리의 종료 시간으로 직접 사용하면 감지 시간 범위에 중복 또는 간격이 발생합니다. 예를 들어:

감지 시간 범위가 5분이라고 가정합니다.

이 경우:

• "작업 1"과 "작업 2"의 감지 범위는 00:05:05 ~ 00:05:10에서 중복됩니다.
• "작업 2"와 "작업 3"의 감지 범위는 00:10:05 ~ 00:10:30에서 간격이 발생하여 이 시간대의 데이터가 포함되지 않습니다.

현재 해결 방법¶

작업 큐로 인한 감지 범위 변동을 방지하기 위해 모니터의 데이터 쿼리 범위는 실제 실행 시간이 아닌 계획 트리거 시간을 기준으로 보정됩니다.

감지 시간 범위가 5분이라고 가정합니다.

따라서 감지 작업이 큐에서 얼마나 오래 대기하든 데이터 쿼리 범위는 항상 계획 트리거 시간을 기준으로 하여 시간 창의 연속성과 안정성을 보장합니다.

감지 범위 드리프트¶

네트워크 지연, 데이터 처리 등의 요인으로 인해 데이터가 보고된 후 저장소에 완전히 기록(즉, DQL로 쿼리 가능)되기까지 일반적으로 수 초에서 수십 초가 소요됩니다. 이 기간 동안 모니터 감지는 이러한 "전송 중" 데이터를 쿼리할 수 없습니다.

이로 인해 고정된 시간 범위로 감지할 때 데이터 누락이 쉽게 발생할 수 있습니다. 예를 들어:

감지 시간 범위가 5분이라고 가정합니다.

데이터 A는 두 번째 감지 실행 전에 보고되었지만, 첫 번째 감지 시 저장되지 않아 누락되었습니다. 저장된 후에는 타임스탬프가 이전이므로 이후 감지 시간 범위에 포함되지 않아 지속적으로 감지되지 않습니다.

현재 해결 방법¶

이 문제를 해결하기 위해 모든 모니터는 감지 실행 시 데이터 쿼리 범위를 과거 방향으로 1분 드리프트시켜 데이터 저장 중 발생하는 빈 시간을 방지합니다.

이 방식을 적용하면 위 예시는 다음과 같이 변경됩니다.

감지 시간 범위가 5분이라고 가정합니다.

데이터 A는 00:10:00 감지에서 누락되었지만, 타임스탬프 00:09:59가 00:15:00 감지 범위(00:09:00 ~ 00:14:00)에 포함되어 두 번째 감지에서 성공적으로 캡처됩니다.

데이터 중단 판단 로직¶

Guance는 시계열 데이터 플랫폼으로, 기존 자산 관리 소프트웨어의 "자산 총괄표" 개념이 없습니다. 시스템은 쿼리된 데이터를 기반으로 "무엇이 존재하는지"만 판단할 수 있을 뿐, "존재해야 하지만 현재 존재하지 않는" 대상을 알 수 없습니다.

예를 들어:

상자 안에 연필과 지우개가 있다고 알려져 있습니다. "상자 안에 연필과 지우개가 있다"라고 명확히 말할 수 있지만, "상자 안에 펜이 없다"라고 단정할 수는 없습니다. 상자에 "원래" 무엇이 있어야 하는지 알 수 없기 때문입니다.

따라서 모니터의 "데이터 중단 감지"는 실제로 "에지 트리거" 메커니즘을 사용하여 판단합니다. 즉, 연속된 두 번의 쿼리 결과를 비교하여 변화를 발견합니다.

핵심 로직은 다음과 같습니다. "이전 감지에서 객체 X가 존재하는 것으로 확인되었지만, 현재 감지에서 객체 X가 사라지면 X에서 데이터 중단이 발생한 것으로 판단합니다."

감지 시간 범위가 5분이라고 가정합니다.

데이터 중단 / 데이터 복구 이벤트¶

모니터가 "데이터 중단" 또는 "데이터 재보고"가 발생했다고 판단하면 사용자 구성에 따라 "데이터 중단 이벤트" 또는 "데이터 중단 복구 이벤트"를 생성할지 결정합니다.

중복되거나 의미 없는 경고를 방지하기 위해 시스템은 이벤트 생성 전에 기존 이벤트 상태를 참조하여 결정합니다.

따라서 "데이터 중단 이벤트"와 "데이터 중단 복구 이벤트"는 항상 번갈아 나타나며, 연속적인 데이터 중단 이벤트 또는 연속적인 복구 이벤트는 발생하지 않습니다.

자주 묻는 질문¶

이벤트에 표시된 시간이 이벤트 생성 시간과 일치하지 않습니다.

이벤트 상세 또는 알림에서 확인되는 시간(예: 00:15:00)은 모니터의 계획 트리퍼 시간(Crontab 표현식 기반의 정규 시간)이며, 시스템에서 이벤트가 실제로 생성된 시간이 아닙니다.

예외: 모니터 목록에서 수동으로 "실행"을 클릭하면 생성된 이벤트 시간은 실제로 클릭하여 실행한 시간이 됩니다.

이벤트에 표시된 시간이 실제 장애 발생 시간과 일치하지 않습니다.

이벤트에 표시된 시간은 모니터의 계획 트리거 시간이며, "감지 범위 드리프트" 메커니즘으로 인해 실제 감지된 데이터 범위는 계획 트리거 시간 - 감지 범위 - 드리프트 시간부터 계획 트리거 시간 - 드리프트 시간까지입니다.

따라서 실제 장애가 발생한 데이터 포인트의 시간은 계획 트리거 시간 - 감지 범위부터 계획 트리거 시간까지의 직관적인 구간 내에 있지 않을 가능성이 높습니다. 이는 정상적인 현상입니다.

플랫폼에서 직접 쿼리 시 장애로 의심되는 데이터가 발견되었지만 모니터가 경고를 생성하지 않았습니다.

이 문제는 일반적으로 다음 원인으로 인해 발생합니다.

1. 데이터 저장 지연 시간이 너무 긴 경우: 감지 실행 시 장애 데이터가 지연되어 아직 쿼리할 수 없습니다.
2. DQL 쿼리 실행 실패: 감지 프로세스가 쿼리 실패로 인해 중단되었습니다.

이러한 상황은 일반적으로 데이터 링크 또는 쿼리 엔진의 문제로 인해 발생하며, 모니터 자체의 제어 범위를 벗어납니다.