에스컬레이션
개요
에스컬레이션을 사용하면 알림 전송이나 원격 명령 실행을 위한 사용자 정의 시나리오를 만들 수 있습니다.
실질적으로 이는 다음을 의미합니다:
- 사용자에게 새로운 문제를 즉시 알릴 수 있습니다.
- 문제가 해결될 때까지 알림을 반복할 수 있습니다.
- 알림 전송을 지연시킬 수 있습니다.
- 알림을 "상위" 사용자 그룹으로 에스컬레이션할 수 있습니다.
- 원격 명령을 즉시 실행하거나 문제가 장시간 해결되지 않을 때 실행할 수 있습니다.
액션은 에스컬레이션 단계를 기준으로 에스컬레이션됩니다. 각 단계에는 시간 기간이 있습니다.
기본 기간과 개별 단계의 사용자 정의 기간을 모두 정의할 수 있습니다. 에스컬레이션 한 단계의 최소 기간은 60초입니다.
알림 전송이나 명령 실행 같은 액션은 어떤 단계에서든 시작할 수 있습니다. 1단계는 즉시 실행되는 액션용입니다. 액션을 지연시키려면 이후 단계에 할당하면 됩니다. 각 단계마다 여러 액션을 정의할 수 있습니다.
에스컬레이션 단계 수에는 제한이 없습니다.
에스컬레이션은 오퍼레이션 구성 시 정의합니다. 에스컬레이션은 복구가 아닌 문제 오퍼레이션에서만 지원됩니다.
에스컬레이션 동작의 기타 측면
액션에 여러 에스컬레이션 단계가 포함되어 있을 때 상황별로 어떤 일이 일어나는지 살펴보겠습니다.
| 상황 | 동작 |
|---|---|
| 최초 문제 알림이 전송된 후 해당 호스트가 유지보수 상태로 전환됨 | 액션 구성의 Pause operations for suppressed problems 설정에 따라, 남은 모든 에스컬레이션 단계가 유지보수 기간만큼 지연되어 실행되거나 지연 없이 실행됩니다. 유지보수 기간은 오퍼레이션을 취소하지 않습니다. |
| 최초 알림이 전송된 후 Time period 액션 조건에 정의된 시간대가 종료됨 | 남은 모든 에스컬레이션 단계가 실행됩니다. Time period 조건은 오퍼레이션을 중단할 수 없습니다. 이 조건은 오퍼레이션이 아니라 액션이 시작되는지/시작되지 않는지에 대해서만 영향을 미칩니다. |
| 유지보수 중에 문제가 시작되어 유지보수 종료 후에도 계속됨(해결되지 않음) | 액션 구성의 Pause operations for suppressed problems 설정에 따라, 모든 에스컬레이션 단계가 유지보수 종료 시점부터 실행되거나 즉시 실행됩니다. |
| no-data 유지보수 중에 문제가 시작되어 유지보수 종료 후에도 계속됨(해결되지 않음) | 모든 에스컬레이션 단계가 실행되기 전에 트리거가 발동될 때까지 기다려야 합니다. |
| 서로 다른 에스컬레이션이 연달아 발생하며 겹침 | 새 에스컬레이션의 실행이 이전 에스컬레이션을 대체하지만, 이전 에스컬레이션에서 최소 한 단계는 항상 실행됩니다. 이 동작은 트리거의 문제 평가가 발생할 때마다 생성되는 이벤트에 대한 액션에서 의미가 있습니다. |
| 에스컬레이션이 진행 중일 때(예: 메시지 전송 중), 모든 유형의 이벤트 기준: - 액션이 비활성화됨 트리거 이벤트 기준: - 트리거가 비활성화됨 - 호스트 또는 아이템이 비활성화됨 트리거에 대한 내부 이벤트 기준: - 트리거가 비활성화됨 아이템/로우레벨 디스커버리 룰에 대한 내부 이벤트 기준: - 아이템이 비활성화됨 - 호스트가 비활성화됨 |
진행 중인 메시지가 전송되고, 이어서 해당 에스컬레이션에 대한 메시지가 한 번 더 전송됩니다. 후속 메시지에는 메시지 본문 시작 부분에 취소 문구(NOTE: Escalation canceled)와 함께 사유가 명시됩니다(예: NOTE: Escalation canceled: action '<Action name>' disabled). 이를 통해 수신자는 에스컬레이션이 취소되었으며 더 이상 단계가 실행되지 않는다는 사실을 알게 됩니다. 이 메시지는 이전에 알림을 받은 모든 사람에게 전송됩니다. 취소 사유는 서버 로그 파일에도 기록됩니다(Debug Level 3=Warning부터). Escalation canceled 메시지는 오퍼레이션이 완료되었지만 복구 오퍼레이션이 구성되어 있고 아직 실행되지 않은 경우에도 전송된다는 점에 유의하세요. |
| 에스컬레이션이 진행 중일 때(예: 메시지 전송 중) 액션이 삭제됨 | 더 이상 메시지가 전송되지 않습니다. 해당 정보는 서버 로그 파일에 기록됩니다(Debug Level 3=Warning부터). 예: escalation canceled: action id:334 deleted |
에스컬레이션 예시
예시 1
"MySQL Administrators" 그룹에 30분마다 한 번씩 총 5회 반복 알림을 전송합니다. 구성 방법:
- Operations 탭에서 Default operation step duration을 "30m"(30분)으로 설정합니다.
- 에스컬레이션 Steps를 "1"부터 "5"까지로 설정합니다.
- 메시지 수신자로 "MySQL Administrators" 그룹을 선택합니다.
알림은 문제 발생 후 0:00, 0:30, 1:00, 1:30, 2:00 시점에 전송됩니다 (물론 문제가 더 빨리 해결되지 않는 한).
문제가 해결되고 복구 메시지가 구성되어 있으면, 이 에스컬레이션 시나리오 내에서 문제 메시지를 한 번 이상 받은 사람에게 전송됩니다.
활성 에스컬레이션을 생성한 트리거가 비활성화되면, Zabbix는 이미 알림을 받은 모든 사람에게 이에 대한 안내 메시지를 전송합니다.
예시 2
장기간 지속되는 문제에 대해 지연된 알림을 전송합니다. 구성 방법:
- Operations 탭에서 Default operation step duration을 "10h"(10시간)로 설정합니다.
- 에스컬레이션 Steps를 "2"부터 "2"까지로 설정합니다.
알림은 에스컬레이션 시나리오의 2단계, 즉 문제 발생 후 10시간이 지난 시점에만 전송됩니다.
메시지 텍스트를 "문제가 발생한 지 10시간이 넘었습니다"와 같이 사용자 정의할 수 있습니다.
예시 3
문제를 상급자에게 에스컬레이션합니다.
위의 첫 번째 예시에서는 MySQL 관리자에게 주기적으로 메시지를 전송하도록 구성했습니다. 이 경우 관리자는 문제가 데이터베이스 관리자에게 에스컬레이션되기 전에 네 개의 메시지를 받게 됩니다. 관리자는 문제가 아직 확인(acknowledge)되지 않은 경우, 즉 아무도 처리하지 않는 것으로 추정되는 경우에만 메시지를 받는다는 점에 유의하세요.
Operation 2의 세부 정보:
사용자 정의 메시지에서 {ESC.HISTORY} 매크로를 사용한 점에 유의하세요. 이 매크로에는 전송된 알림 및 실행된 명령 등 해당 에스컬레이션에서 이전에 실행된 모든 단계에 대한 정보가 담깁니다.
예시 4
보다 복잡한 시나리오입니다. MySQL 관리자에게 여러 메시지를 보내고 관리자에게 에스컬레이션한 후, Zabbix는 MySQL 데이터베이스를 재시작하려 시도합니다. 이는 문제가 2:30 동안 지속되고 확인(acknowledge)되지 않은 경우에 발생합니다.
문제가 여전히 존재하면, 다시 30분 후 Zabbix는 모든 guest 사용자에게 메시지를 전송합니다.
이것으로도 해결되지 않으면, 다시 한 시간 후 Zabbix는 IPMI 명령을 사용해 MySQL 데이터베이스가 있는 서버를 재부팅합니다(두 번째 원격 명령).
예시 5
단계 범위가 겹치고 사용자 정의 간격을 가진 여러 오퍼레이션이 포함된 에스컬레이션입니다. 기본 오퍼레이션 단계 기간은 30분입니다.
알림은 다음과 같이 전송됩니다:
- MySQL 관리자에게 문제 발생 후 0:00, 0:30, 1:00, 1:30 시점에 전송됩니다.
- 데이터베이스 관리자에게 2:00과 2:10 시점에 전송됩니다(단계가 겹칠 때의 Step duration에 대해 Operation details에 설명된 대로, 후속 오퍼레이션에 정의된 더 짧은 사용자 정의 단계 기간 10분이 여기에 구성된 더 긴 단계 기간 1시간을 재정의합니다).
- Zabbix 관리자에게 문제 발생 후 2:00, 2:10, 2:20 시점에 전송됩니다(사용자 정의 단계 기간 10분이 적용됩니다).
- guest 사용자에게 문제 발생 후 4:00 시점에 전송됩니다(8단계와 11단계 사이에는 기본 단계 기간 30분이 적용됩니다).