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

개요

트리거 기반 이벤트 상관관계를 사용하면 하나의 트리거에서 보고된 별도의 문제들을 연결할 수 있습니다.

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

이는 문제 이벤트 생성 모드 매개변수가 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 #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]

아이템이 설정되면 설정 변경사항이 적용될 때까지 잠시 기다린 다음 최신 데이터로 이동하여 아이템이 데이터 수집을 시작했는지 확인하세요.

트리거

아이템이 작동하면 트리거를 구성해야 합니다. 로그 파일의 어떤 항목이 주목할 만한지 결정하는 것이 중요합니다. 예를 들어, 다음 트리거 표현식은 잠재적인 문제를 알리기 위해 'Stopping'과 같은 문자열을 검색합니다:

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

"Stopping" 문자열이 포함된 각 줄이 문제로 간주되도록 하려면 트리거 구성에서 문제 이벤트 생성 모드를 'Multiple'로 설정하세요.

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

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

이것을 원하지 않으므로 모든 문제가 아닌 해당하는 근본 문제가 닫히도록 보장하는 것이 중요합니다. 여기서 태그가 도움이 될 수 있습니다.

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

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

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

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

잘못된 구성이 가능하고, 관련 없는 문제에 대해 유사한 이벤트 태그가 생성될 수 있으므로 아래에 설명된 경우를 검토하세요!

인덱스 매크로는 항상 트리거 구성의 복구 표현식이 아닌 표현식 필드를 참조합니다. 예를 들어, 복구 이벤트에서 {ITEM.VALUE1}은 복구 시점에서 문제 표현식의 첫 번째 아이템의 최신 값으로 해석됩니다. 복구 표현식이 다른 아이템을 기반으로 하고 복구 시점에 문제 표현식 아이템의 값이 변경되면 이벤트들은 다른 태그를 갖게 되어 상관관계가 형성되지 않습니다.
동일한 로그 파일에 오류 및 복구 메시지를 작성하는 두 개의 애플리케이션이 있는 경우 사용자는 {ITEM.VALUE} 매크로에서 서비스 A와 서비스 B의 이름을 추출하기 위해 태그 값에 별도의 정규 표현식을 사용하여 동일한 트리거에 두 개의 service 태그를 다른 태그 값으로 사용하기로 결정할 수 있습니다(예: 메시지 형식이 다를 때). 그러나 정규 표현식에 일치하는 것이 없으면 계획대로 작동하지 않을 수 있습니다. 일치하지 않는 정규 표현식은 빈 태그 값을 산출하고 문제 및 OK 이벤트 모두에서 하나의 빈 태그 값이면 이들을 연결하기에 충분합니다. 따라서 서비스 A의 복구 메시지가 실수로 서비스 B의 오류 메시지를 닫을 수 있습니다.
실제 태그와 태그 값은 트리거가 실행될 때만 표시됩니다. 사용된 정규 표현식이 유효하지 않으면 조용히 *UNKNOWN* 문자열로 대체됩니다. *UNKNOWN* 태그 값을 가진 초기 문제 이벤트를 놓치면 동일한 *UNKNOWN* 태그 값을 가진 후속 OK 이벤트가 나타나서 닫지 말았어야 할 문제 이벤트를 닫을 수 있습니다.
사용자가 매크로 함수 없이 {ITEM.VALUE} 매크로를 태그 값으로 사용하면 255자 제한이 적용됩니다. 로그 메시지가 길고 처음 255자가 비특정적일 때 관련 없는 문제에 대해서도 유사한 이벤트 태그가 생성될 수 있습니다.

다음은?

2 글로벌 이벤트 상관관계