트리거 기반 상관관계

개요

트리거 기반 이벤트 상관관계는 하나의 트리거가 보고하는 개별 장애를 서로 연관시킬 수 있게 해줍니다.

일반적으로 하나의 OK 이벤트가 해당 트리거로 생성된 모든 장애 이벤트를 종료할 수 있지만, 더 세밀한 접근이 필요한 경우가 있습니다. 예를 들어 로그 파일을 모니터링할 때 로그 파일에서 특정 장애를 발견하고 이를 한꺼번에가 아니라 개별적으로 종료하고 싶을 수 있습니다.

PROBLEM 이벤트 생성 모드 파라미터가 Multiple로 설정된 트리거가 이런 경우에 해당합니다. 이런 트리거는 보통 로그 모니터링, 트랩 처리 등에 사용됩니다.

Zabbix에서는 태깅을 기반으로 장애 이벤트를 연관시킬 수 있습니다. 태그는 값을 추출하고 장애 이벤트에 대한 식별자를 만드는 데 사용됩니다. 이를 활용하면 일치하는 태그를 기준으로 장애를 개별적으로 종료할 수도 있습니다.

다시 말해, 동일한 트리거가 이벤트 태그로 식별되는 별개의 이벤트를 생성할 수 있습니다. 따라서 장애 이벤트를 하나씩 식별하고 이벤트 태그에 의한 식별을 기준으로 개별적으로 종료할 수 있습니다.

동작 방식

로그 모니터링에서는 다음과 유사한 줄을 만날 수 있습니다:

Line1: Service 1 stopped
Line2: Service 2 stopped
Line3: Service 1 was restarted
Line4: Service 2 was restarted

이벤트 상관관계의 아이디어는 Line1의 장애 이벤트를 Line3의 해결과 연결하고 Line2의 장애 이벤트를 Line4의 해결과 연결해, 이 장애들을 하나씩 종료할 수 있게 하는 것입니다:

Line1: Service 1 stopped
Line3: Service 1 was restarted #problem from Line 1 closed

Line2: Service 2 stopped
Line4: Service 2 was restarted #problem from Line 2 closed

이를 위해서는 연관된 이벤트에 예를 들어 "Service 1", "Service 2"와 같이 태그를 지정해야 합니다. 이는 로그 줄에 정규 표현식을 적용해 태그 값을 추출하는 방식으로 할 수 있습니다. 그러면 이벤트가 생성될 때 각각 "Service 1", "Service 2"로 태그가 지정되어 장애를 해결과 연결할 수 있습니다.

설정

아이템

먼저 로그 파일을 모니터링하는 아이템을 설정해야 합니다. 예를 들면 다음과 같습니다:

log[/var/log/syslog]

아이템을 설정한 후, 설정 변경이 반영되도록 1분 정도 기다린 다음 최근 데이터로 이동해 아이템이 데이터 수집을 시작했는지 확인하세요.

트리거

아이템이 동작하면 트리거를 설정해야 합니다. 로그 파일의 어떤 항목에 주의를 기울일 가치가 있는지 결정하는 것이 중요합니다. 예를 들어 다음 트리거 표현식은 잠재적인 장애를 알리기 위해 'Stopping' 같은 문자열을 검색합니다:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

그다음 복구 표현식을 정의합니다. 다음 복구 표현식은 "Starting" 문자열을 포함하는 로그 줄이 발견되면 모든 장애를 해결합니다:

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

우리가 원하는 것은 그것이 아니므로, 모든 장애가 아니라 해당하는 근본 장애만 종료되도록 하는 방법이 중요합니다. 바로 여기서 태깅이 도움이 됩니다.

트리거 설정에서 태그를 지정하면 장애와 해결을 연결할 수 있습니다. 다음 설정을 해야 합니다:

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• 이벤트 매칭에 사용할 태그 이름 입력

• 로그 줄에서 태그 값을 추출하도록 태그를 설정합니다

설정이 성공적으로 완료되면 Monitoring → Problems에서 애플리케이션별로 태그가 지정되고 해결과 연결된 장애 이벤트를 볼 수 있습니다.

• 인덱스가 붙은 매크로는 항상 트리거 설정의 Recovery expression이 아니라 Expression 필드를 참조합니다. 예를 들어 복구 이벤트에서 {ITEM.VALUE1}은 복구 시점에 장애 표현식에 있는 첫 번째 아이템의 최신 값으로 확인됩니다. 복구 표현식이 다른 아이템을 기반으로 하고 복구 시점까지 장애 표현식 아이템의 값이 변경되면, 이벤트는 서로 다른 태그를 갖게 되어 상관관계가 성립하지 않습니다.

• 두 애플리케이션이 동일한 로그 파일에 오류 메시지와 복구 메시지를 기록하는 경우, 사용자는 (예를 들어 메시지 형식이 다를 때) {ITEM.VALUE} 매크로에서 서비스 A와 서비스 B 같은 이름을 추출하기 위해 태그 값에 별도의 정규 표현식을 사용해서 동일한 트리거에 서로 다른 태그 값을 가진 두 개의 service 태그를 사용하기로 할 수 있습니다. 하지만 정규 표현식에 일치하는 것이 없으면 계획대로 동작하지 않을 수 있습니다. 일치하지 않는 정규 표현식은 빈 태그 값을 만들어내고, 장애 이벤트와 OK 이벤트 양쪽에 하나의 빈 태그 값만 있어도 두 이벤트가 연관되기에 충분합니다. 그래서 서비스 A의 복구 메시지가 서비스 B의 오류 메시지를 뜻하지 않게 종료해버릴 수 있습니다.

• 실제 태그와 태그 값은 트리거가 발생할 때만 확인할 수 있습니다. 사용된 정규 표현식이 유효하지 않으면 아무런 알림 없이 *UNKNOWN* 문자열로 대체됩니다. *UNKNOWN* 태그 값을 가진 최초의 장애 이벤트를 놓치면, 동일한 *UNKNOWN* 태그 값을 가진 후속 OK 이벤트가 나타나서 종료하지 말아야 할 장애 이벤트를 종료할 수 있습니다.

• 사용자가 매크로 함수 없이 {ITEM.VALUE} 매크로를 태그 값으로 사용하면 255자 제한이 적용됩니다. 로그 메시지가 길고 앞의 255자가 특징적이지 않은 경우, 이 역시 관련 없는 장애에 유사한 이벤트 태그가 생기는 결과를 낳을 수 있습니다.