1 트리거 기반 이벤트 상관관계

개요

트리거 기반 이벤트 상관관계를 통해 하나의 트리거에서 보고된 개별 문제들을 연관시킬 수 있습니다.

일반적으로 OK 이벤트는 하나의 트리거에서 생성된 모든 문제 이벤트를 닫을 수 있지만, 더 세부적인 접근 방식이 필요한 경우가 있습니다. 예를 들어, 로그 파일을 모니터링할 때 로그 파일에서 특정 문제들을 발견하고 모든 문제를 한꺼번에 닫기보다는 개별적으로 닫고 싶을 수 있습니다.

이는 문제 이벤트 생성 모드 매개변수가 다중으로 설정된 트리거의 경우입니다. 이러한 트리거는 일반적으로 로그 모니터링, 트랩 처리 등에 사용됩니다.

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 #Line 1의 문제 닫힘

Line2: Service 2 stopped
Line4: Service 2 was restarted #Line 2의 문제 닫힘

이를 위해 이러한 관련 이벤트들을 예를 들어 "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 

우리는 이것을 원하지 않으므로 모든 문제가 아닌 해당 근본 문제들이 닫히도록 보장하는 것이 중요합니다. 이것이 태깅이 도움이 될 수 있는 부분입니다.

트리거 구성에서 태그를 지정하여 문제와 해결을 일치시킬 수 있습니다. 다음 설정이 필요합니다:

• 문제 이벤트 생성 모드: 다중
• OK 이벤트 닫기: 태그 값이 일치하는 모든 문제
• 이벤트 일치를 위한 태그 이름 입력

• 로그 줄에서 태그 값을 추출하도록 태그를 구성

성공적으로 구성되면 모니터링 → 문제에서 애플리케이션별로 태그되고 해결과 일치된 문제 이벤트들을 볼 수 있습니다.

• 인덱스 매크로는 항상 복구 표현식이 아닌 트리거 구성의 표현식 필드를 참조합니다. 예를 들어, 복구 이벤트에서 {ITEM.VALUE1}은 복구 시점에서 문제 표현식의 첫 번째 아이템의 최신 값으로 해석됩니다. 복구 표현식이 다른 아이템을 기반으로 하고 복구 시점까지 문제 표현식 아이템의 값이 변경되면, 이벤트들은 서로 다른 태그를 받게 되어 상관관계가 없어집니다.

• 두 개의 애플리케이션이 같은 로그 파일에 오류와 복구 메시지를 기록하는 경우, 사용자는 {ITEM.VALUE} 매크로에서 서비스 A와 서비스 B의 이름을 추출하기 위해 별도의 정규 표현식을 사용하여 같은 트리거에서 두 개의 service 태그를 서로 다른 태그 값으로 사용하기로 결정할 수 있습니다(예: 메시지 형식이 다를 때). 하지만 정규 표현식과 일치하지 않으면 계획대로 작동하지 않을 수 있습니다. 일치하지 않는 정규 표현식은 빈 태그 값을 생성하고, 문제와 OK 이벤트 모두에서 단일 빈 태그 값만으로도 상관관계를 만들기에 충분합니다. 따라서 서비스 A의 복구 메시지가 실수로 서비스 B의 오류 메시지를 닫을 수 있습니다.

• 실제 태그와 태그 값은 트리거가 발동할 때만 보이게 됩니다. 사용된 정규 표현식이 유효하지 않으면 조용히 *UNKNOWN* 문자열로 대체됩니다. *UNKNOWN* 태그 값을 가진 초기 문제 이벤트를 놓치면, 닫지 말아야 할 문제 이벤트들을 닫을 수 있는 동일한 *UNKNOWN* 태그 값을 가진 후속 OK 이벤트들이 나타날 수 있습니다.

• 사용자가 {ITEM.VALUE} 매크로를 매크로 함수 없이 태그 값으로 사용하면 255자 제한이 적용됩니다. 로그 메시지가 길고 처음 255자가 비특정적일 때, 이것도 관련 없는 문제들에 대해 유사한 이벤트 태그를 생성할 수 있습니다.