WSO2 CEP와 Siddhi의 이벤트 처리 구조

모니터링 수집값을 볼 때 현재 값 하나로 판단하기 어려운 경우가 있습니다. 순간적으로 높았던 값인지, 일정 시간 계속 높았던 값인지 구분하려면 여러 이벤트를 시간 범위로 묶어 봐야 합니다.

CEP는 이렇게 들어오는 이벤트에 필터와 집계, 패턴 규칙을 적용하는 방식입니다. 당시 사용했던 WSO2 CEP의 구조와 관련 규칙을 정리했습니다. 아래 구조 설명은 WSO2 CEP 4.2 문서를 기준으로 봅니다.

이벤트 수신부터 결과 전송까지

WSO2 CEP 4.2 사용자 가이드 는 이벤트를 받는 receiver, 입력·출력 stream, Siddhi 쿼리로 처리하는 execution plan, 결과를 내보내는 publisher로 흐름을 설명합니다.

수신 단계에서는 외부 데이터를 처리 가능한 이벤트 형식으로 바꿉니다. 실행 계획은 어떤 값을 필터링하고 계산할지 정하며, publisher는 처리한 결과를 외부로 보냅니다. 이벤트를 계산하는 일과 결과를 저장하거나 알림으로 보내는 일을 나눠 볼 수 있습니다.

시간 구간과 집계 규칙

당시 수집기 규칙 API 기록에는 1분 구간의 값을 평균 내거나 최댓값과 최솟값으로 계산하는 Siddhi 규칙이 남아 있습니다. 호스트와 메트릭 종류별로 묶어 계산하고 조건에 맞는 결과를 출력 스트림으로 보내는 형태였습니다.

아래는 같은 구조를 이해하기 위한 CPU 평균 예시입니다. 운영에서 사용한 임계치나 수집 규칙을 그대로 옮긴 것은 아닙니다.

define stream ServerMetricStream (host string, cpu double);
 
from ServerMetricStream#window.time(1 min)
select host, avg(cpu) as avgCpu
group by host
having avgCpu > 90
insert into AlertStream;

window.time(1 min)은 최근 1분의 이벤트를 유지하는 시간 창입니다. 이 예시에서는 새 이벤트가 들어올 때 호스트별 평균을 계산합니다. 1분에 한 번만 결과를 내는 규칙이라는 뜻은 아닙니다. 출력 주기를 제한하려면 그 조건도 별도로 구성해야 합니다. 문법은 Siddhi 쿼리 가이드 에서 확인할 수 있습니다.

규칙 결과와 운영 알림의 차이

조건을 만족하는 이벤트를 만드는 것과 운영자에게 알림을 보내는 것은 구분해야 합니다. 같은 조건이 계속 참이면 결과 이벤트가 반복될 수 있기 때문입니다. 알림을 한 번만 보낼지, 일정 시간 뒤 다시 보낼지, 정상 복구를 알릴지는 이후 처리에서 정할 문제입니다.

규칙을 볼 때도 필터 조건뿐 아니라 입력 이벤트의 단위, 집계 구간, 그룹 기준, 출력 주기를 함께 확인해야 합니다. 이 중 하나가 달라지면 같은 메트릭으로도 결과가 달라질 수 있습니다.

실제 규칙을 조회하고 등록하는 API는 수집기 CEP 규칙 REST API 글에서 이어서 다룹니다.