5단계 에스컬레이션
원본 보기5 에스컬레이션
개요
에스컬레이션을 통해 알림을 전송하거나 원격 명령을 실행하는 사용자 정의 시나리오를 생성할 수 있습니다.
실용적으로는 다음을 의미합니다:
- 사용자가 새로운 문제에 대해 즉시 알림을 받을 수 있습니다.
- 문제가 해결될 때까지 알림이 반복될 수 있습니다.
- 알림 전송을 지연시킬 수 있습니다.
- 알림을 다른 "상위" 사용자 그룹으로 에스컬레이션할 수 있습니다.
- 원격 명령을 즉시 실행하거나 문제가 장기간 해결되지 않을 때 실행할 수 있습니다.
작업은 에스컬레이션 단계를 기반으로 에스컬레이션됩니다. 각 단계는 시간 지속 시간을 가집니다.
기본 지속 시간과 개별 단계의 사용자 정의 지속 시간을 모두 정의할 수 있습니다. 하나의 에스컬레이션 단계의 최소 지속 시간은 60 초입니다.
모든 단계에서 알림 전송 또는 명령 실행과 같은 작업을 시작할 수 있습니다. 1단계는 즉시 작업을 위한 것입니다. 작업을 지연시키고 싶다면 나중 단계에 할당할 수 있습니다. 각 단계마다 여러 작업을 정의할 수 있습니다.
에스컬레이션 단계의 수는 제한되지 않습니다.
에스컬레이션은 작업 구성 시 정의됩니다. 에스컬레이션은 문제 작업에 대해서만 지원되며 복구에는 지원되지 않습니다.
에스컬레이션 동작의 기타 측면
작업에 여러 에스컬레이션 단계가 포함된 경우 다양한 상황에서 어떤 일이 일어나는지 살펴보겠습니다.
| 상황 | 동작 |
|---|---|
| 초기 문제 알림이 전송된 후 해당 호스트가 유지 보수 모드로 전환됨 | 작업 구성의 억제된 문제에 대한 작업 일시 중지 설정에 따라, 나머지 모든 에스컬레이션 단계는 유지 보수 기간으로 인한 지연과 함께 또는 지연 없이 실행됩니다. 유지 보수 기간은 작업을 취소하지 않습니다. |
| 초기 알림이 전송된 후 시간 기간 작업 조건에 정의된 시간 기간이 종료됨 | 나머지 모든 에스컬레이션 단계가 실행됩니다. 시간 기간 조건은 작업을 중지할 수 없으며, 작업이 언제 시작되거나 시작되지 않는지에 관해서만 효과가 있고 작업에는 효과가 없습니다. |
| 유지 보수 중에 문제가 시작되고 유지 보수 종료 후에도 계속됨(해결되지 않음) | 작업 구성의 억제된 문제에 대한 작업 일시 중지 설정에 따라, 모든 에스컬레이션 단계는 유지 보수 종료 순간부터 또는 즉시 실행됩니다. |
| 무데이터 유지 보수 중에 문제가 시작되고 유지 보수 종료 후에도 계속됨(해결되지 않음) | 모든 에스컬레이션 단계가 실행되기 전에 트리거가 발동될 때까지 기다려야 합니다. |
| 서로 다른 에스컬레이션이 연속으로 발생하여 겹침 | 각각의 새로운 에스컬레이션 실행이 이전 에스컬레이션을 대체하지만, 이전 에스컬레이션에서 항상 실행되는 최소 하나의 에스컬레이션 단계가 있습니다. 이 동작은 트리거의 모든 문제 평가마다 생성되는 이벤트에 대한 작업과 관련이 있습니다. |
| 진행 중인 에스컬레이션(메시지 전송 중)에서 모든 유형의 이벤트를 기반으로: - 작업이 비활성화됨 트리거 이벤트를 기반으로: - 트리거가 비활성화됨 - 호스트 또는 아이템이 비활성화됨 트리거에 대한 내부 이벤트를 기반으로: - 트리거가 비활성화됨 아이템/로우레벨 디스커버리 규칙에 대한 내부 이벤트를 기반으로: - 아이템이 비활성화됨 - 호스트가 비활성화됨 |
진행 중인 메시지가 전송되고 에스컬레이션에서 하나 더 메시지가 전송됩니다. 후속 메시지는 메시지 본문 시작 부분에 취소 텍스트(참고: 에스컬레이션 취소됨)가 있고 이유를 명시합니다(예: 참고: 에스컬레이션 취소됨: 작업 '<작업 이름>' 비활성화됨). 이렇게 수신자는 에스컬레이션이 취소되었고 더 이상 단계가 실행되지 않을 것임을 알게 됩니다. 이 메시지는 이전에 알림을 받은 모든 사람에게 전송됩니다. 취소 이유는 서버 로그 파일에도 기록됩니다(디버그 레벨 3=경고부터). 작업은 완료되었지만 복구 작업이 구성되어 있고 아직 실행되지 않은 경우에도 에스컬레이션 취소됨 메시지가 전송됩니다. |
| 진행 중인 에스컬레이션(메시지 전송 중)에서 작업이 삭제됨 | 더 이상 메시지가 전송되지 않습니다. 정보는 서버 로그 파일에 기록됩니다(디버그 레벨 3=경고부터), 예: escalation canceled: action id:334 deleted |
에스컬레이션 예시
예시 1
"MySQL Administrators" 그룹에 30분마다 한 번씩(총 5회) 반복 알림을 전송합니다. 구성 방법:
- 작업 탭에서 기본 작업 단계 지속 시간을 "30m"(30분)로 설정합니다.
- 에스컬레이션 단계를 "1"에서 "5"로 설정합니다.
- "MySQL Administrators" 그룹을 메시지 수신자로 선택합니다.
알림은 문제 시작 후 0:00, 0:30, 1:00, 1:30, 2:00 시간에 전송됩니다 (물론 문제가 더 빨리 해결되지 않는 한).
문제가 해결되고 복구 메시지가 구성된 경우, 이 에스컬레이션 시나리오 내에서 최소 한 번의 문제 메시지를 받은 사람들에게 전송됩니다.
활성 에스컬레이션을 생성한 트리거가 비활성화되면 Zabbix는 이미 알림을 받은 모든 사람에게 이에 대한 정보 메시지를 전송합니다.
예시 2
오래 지속된 문제에 대한 지연된 알림 전송. 구성 방법:
- 작업 탭에서 기본 작업 단계 지속 시간을 "10h"(10시간)로 설정합니다.
- 에스컬레이션 단계를 "2"에서 "2"로 설정합니다.
알림은 에스컬레이션 시나리오의 2단계, 즉 문제 시작 후 10시간에만 전송됩니다.
"문제가 10시간 이상 지속되었습니다"와 같은 메시지 텍스트를 사용자 정의할 수 있습니다.
예시 3
상사에게 문제를 에스컬레이션.
위의 첫 번째 예시에서 MySQL 관리자들에게 주기적으로 메시지를 전송하도록 구성했습니다. 이 경우 관리자들은 문제가 데이터베이스 매니저에게 에스컬레이션되기 전에 네 개의 메시지를 받게 됩니다. 매니저는 문제가 아직 승인되지 않은 경우에만 메시지를 받을 것이며, 이는 아무도 그것을 작업하고 있지 않다는 것을 의미합니다.
작업 2의 세부 정보:
사용자 정의 메시지에서 {ESC.HISTORY} 매크로의 사용에 주목하십시오. 이 매크로는 전송된 알림 및 실행된 명령과 같은 이 에스컬레이션에서 이전에 실행된 모든 단계에 대한 정보를 포함할 것입니다.
예시 4
더 복잡한 시나리오. MySQL 관리자들에게 여러 메시지를 보내고 매니저에게 에스컬레이션한 후, Zabbix는 MySQL 데이터베이스를 재시작하려고 시도할 것입니다. 이는 문제가 2시간 30분 동안 존재하고 승인되지 않은 경우에 발생합니다.
문제가 여전히 존재한다면 30분 후 Zabbix는 모든 게스트 사용자에게 메시지를 전송할 것입니다.
이것으로도 해결되지 않는다면 1시간 후 Zabbix는 IPMI 명령을 사용하여 MySQL 데이터베이스가 있는 서버를 재부팅할 것입니다(두 번째 원격 명령).
예시 5
겹치는 단계 범위와 사용자 정의 간격을 가진 여러 작업으로 구성된 에스컬레이션. 기본 작업 단계 지속 시간은 30분입니다.
알림은 다음과 같이 전송됩니다:
- MySQL 관리자들에게 문제 시작 후 0:00, 0:30, 1:00, 1:30에.
- 데이터베이스 매니저에게 2:00과 2:10에 (후속 작업에 정의된 더 짧은 사용자 정의 단계 지속 시간 10분이 여기서 구성된 더 긴 단계 지속 시간 1시간을 재정의합니다. 단계 지속 시간에 대한 작업 세부 정보에서 단계가 겹칠 때 설명된 바와 같습니다).
- Zabbix 관리자들에게 문제 시작 후 2:00, 2:10, 2:20에 (사용자 정의 단계 지속 시간 10분이 적용됩니다).
- 게스트 사용자들에게 문제 시작 후 4:00에 (8단계와 11단계 사이에서 기본 단계 지속 시간 30분이 적용됩니다).