문서
원본 보기11 유지보수
개요
유지보수는 사전 정의된 시간 동안 문제를 억제하는 데 사용됩니다.
Zabbix에서 호스트와 호스트 그룹에 대한 유지보수 기간을 정의할 수 있습니다.
또한 트리거 태그를 지정하여 단일 트리거(또는 트리거의 부분 집합)에 대해서만 유지보수를 정의하는 것이 가능합니다. 이 경우 유지보수는 해당 트리거에 대해서만 활성화되며, 호스트 또는 호스트 그룹의 다른 모든 트리거는 유지보수 상태가 되지 않습니다.
유지보수 유형에는 두 가지가 있습니다: 데이터 수집 포함과 데이터 수집 없음입니다.
데이터 수집 포함 유지보수 중에는 트리거가 평소와 같이 처리되고 필요에 따라 이벤트가 생성됩니다. 하지만 액션 구성에서 억제된 문제에 대한 작업 일시정지 옵션이 선택되어 있으면, 유지보수 중인 호스트/트리거에 대한 문제 에스컬레이션이 일시정지됩니다. 이 경우 알림 발송이나 원격 명령을 포함할 수 있는 에스컬레이션 단계는 유지보수 기간이 지속되는 동안 무시됩니다. 유지보수 중에는 문제 복구 및 업데이트 작업은 억제되지 않고, 에스컬레이션만 억제됩니다. 유지보수 중에 문제가 시작된 경우 복구 알림은 발송되지 않습니다.
예를 들어, 문제 시작 후 0분, 30분, 60분에 에스컬레이션 단계가 예정되어 있고, 실제 문제 발생 후 10분부터 40분까지 30분 동안 유지보수가 진행되는 경우, 2단계와 3단계는 30분 늦게 실행되어 60분과 90분에 실행됩니다(문제가 여전히 존재하는 경우). 마찬가지로 유지보수 중에 문제가 발생하면 에스컬레이션은 유지보수 후에 시작됩니다.
유지보수 중에도 문제 알림을 정상적으로(지연 없이) 받으려면 액션 구성에서 억제된 문제에 대한 작업 일시정지 옵션을 선택 해제해야 합니다.
트리거 표현식에서 사용되는 호스트 중 적어도 하나가 유지보수 모드가 아닌 경우, Zabbix는 문제 알림을 발송합니다.
Zabbix 서버는 유지보수 중에도 실행되어야 합니다. 유지보수는 매분마다 또는 유지보수 기간에 변경사항이 있을 경우 구성 캐시가 다시 로드되는 즉시 재계산됩니다.
타이머 프로세스는 매분 0초에 호스트 상태를 유지보수로/에서 변경해야 하는지 확인합니다. 또한 타이머 프로세스는 매초마다 구성 업데이트 후 [유지보수 기간]에 변경사항이 있는지에 따라 시작/중지되어야 하는 유지보수가 있는지 확인합니다. 따라서 유지보수 기간 시작/중지 속도는 구성 업데이트 간격(기본값 10초)에 따라 달라집니다. 유지보수 기간 변경에는 활성화 시작/활성화 종료 설정은 포함되지 않습니다. 또한 호스트/호스트 그룹이 기존 활성 유지보수 기간에 추가되면, 변경사항은 다음 분의 시작 시에만 타이머 프로세스에 의해 활성화됩니다.
호스트가 유지보수에 들어가면 Zabbix 서버 타이머 프로세스는 모든 열린 문제를 읽어 억제가 필요한지 확인합니다. 열린 문제가 많을 경우 성능에 영향을 미칠 수 있습니다. Zabbix 서버는 시작 시에도 유지보수가 구성되어 있지 않더라도 모든 열린 문제를 읽습니다.
Zabbix 서버(또는 프록시)는 유지보수 유형(데이터 수집 없음 유지보수 포함)에 관계없이 항상 데이터를 수집합니다. 데이터 수집 없음이 설정되면 데이터는 나중에 서버에서 무시됩니다.
데이터 수집 없음 유지보수가 종료되면, nodata() 함수를 사용하는 트리거는 확인 중인 기간 동안 다음 확인 전에는 발동되지 않습니다.
호스트가 유지보수 중일 때 로그 아이템이 추가되고 유지보수가 종료되면, 유지보수 종료 이후의 새로운 로그파일 항목만 수집됩니다.
데이터 수집 없음 유지보수 중인 호스트에 대해 타임스탬프가 있는 값이 전송되면(예: Zabbix sender 사용), 이 값은 삭제됩니다. 하지만 만료된 유지보수 기간에 대해 타임스탬프가 있는 값을 전송하는 것은 가능하며, 이는 허용됩니다.
유지보수 기간, 호스트, 그룹 또는 태그가 사용자에 의해 변경되면, 변경사항은 구성 캐시 동기화 후에만 적용됩니다.
구성
유지보수 기간을 구성하려면:
- Data collection > Maintenance로 이동합니다.
- Create maintenance period를 클릭합니다 (또는 기존 유지보수 기간의 이름을 클릭).
- 양식에 유지보수 매개변수를 입력합니다.
모든 필수 입력 필드는 빨간색 별표로 표시됩니다.
| 매개변수 | 설명 |
|---|---|
| Name | 유지보수 기간의 이름. |
| Maintenance type | 두 가지 유형의 유지보수를 설정할 수 있습니다: With data collection - 유지보수 중에 서버가 데이터를 수집하고 트리거가 처리됩니다; No data collection - 데이터는 여전히 수집될 수 있지만 유지보수 중에는 데이터베이스에 저장되지 않으며, 트리거( nodata() 함수 포함)가 작동하지 않습니다.각 유형이 가용성 보고서에 미치는 영향은 유지보수 기간의 영향을 참조하세요. |
| Active since | 유지보수 기간 실행이 활성화되는 날짜와 시간. 참고: 이 시간만 설정하는 것으로는 유지보수 기간이 활성화되지 않습니다; 유지보수 기간은 Periods에서 구성되어야 합니다 (아래 참조). |
| Active till | 유지보수 기간 실행이 비활성화되는 날짜와 시간. |
| Periods | 이 블록을 통해 유지보수가 실행되는 정확한 날짜와 시간을 정의할 수 있습니다.  을 클릭하면 유지보수 일정을 정의할 수 있는 유연한 Maintenance period 양식이 포함된 팝업 창이 열립니다. 자세한 설명은 유지보수 기간을 참조하세요. |
| Host groups | 유지보수가 활성화될 호스트 그룹을 선택합니다. 지정된 호스트 그룹의 모든 호스트에 대해 유지보수가 활성화됩니다. 이 필드는 자동 완성 기능이 있어 입력을 시작하면 사용 가능한 모든 호스트 그룹의 드롭다운이 표시됩니다. 상위 호스트 그룹을 지정하면 중첩된 모든 호스트 그룹이 암시적으로 선택됩니다. 따라서 중첩된 그룹의 호스트에서도 유지보수가 활성화됩니다. |
| Hosts | 유지보수가 활성화될 호스트를 선택합니다. 이 필드는 자동 완성 기능이 있어 입력을 시작하면 사용 가능한 모든 호스트의 드롭다운이 표시됩니다. |
| Tags | 유지보수 중인 호스트에서 일치하는 태그가 있는 문제를 억제할 태그를 지정합니다. 여러 조건을 설정할 수 있습니다. 태그 이름 일치는 항상 대소문자를 구분합니다. 각 조건에 사용할 수 있는 두 가지 연산자가 있습니다: Contains - 태그 값이 입력된 문자열을 포함하는 지정된 태그 이름을 포함합니다(부분 문자열 일치, 대소문자 구분); Equals - 지정된 태그 이름과 값을 포함합니다(대소문자 구분). 조건에 대한 두 가지 계산 유형이 있습니다: And/Or - 모든 조건이 충족되어야 하며, 동일한 태그 이름을 가진 조건은 Or 조건으로 그룹화됩니다; Or - 하나의 조건이 충족되면 충분합니다. 태그는 With data collection 유지보수 유형이 선택된 경우에만 지정할 수 있습니다. |
| Description | 유지보수 기간의 설명. |
점검 기간
점검 기간 창은 반복적이거나 일회성 점검을 위한 시간을 예약하는 데 사용됩니다. 이 폼은 선택된 기간 유형에 따라 사용 가능한 필드가 변경되는 동적 형태입니다.
| 기간 유형 | 설명 |
|---|---|
| 일회성 | 일회성 점검 기간을 구성합니다: 날짜 - 점검 기간의 날짜와 시간; 점검 기간 길이 - 점검이 활성화될 기간. |
| 매일 | 매일 점검 기간을 구성합니다: 매일/며칠마다 - 점검 빈도 (1 - (기본값) 매일, 2 - 이틀마다 등); 시간(시:분) - 점검이 시작되는 시간; 점검 기간 길이 - 점검이 활성화될 기간. 매일/며칠마다 매개변수가 "1"보다 클 때, 시작일은 활성화 시작일이 속하는 날입니다. 예시: - 활성화 시작일이 "2021-01-01 12:00"으로 설정되고, 매일/며칠마다가 "2"로 설정되며, 시간(시:분)이 "23:00"으로 설정된 경우, 첫 번째 점검 기간은 1월 1일 23:00에 시작되고 두 번째 점검 기간은 1월 3일 23:00에 시작됩니다; - 활성화 시작일이 "2021-01-01 12:00"으로 설정되고, 매일/며칠마다가 "2"로 설정되며, 시간(시:분)이 "01:00"으로 설정된 경우, 첫 번째 점검 기간은 1월 3일 01:00에 시작되고 두 번째 점검 기간은 1월 5일 01:00에 시작됩니다. |
| 매주 | 매주 점검 기간을 구성합니다: 매주/몇 주마다 - 점검 빈도 (1 - (기본값) 매주, 2 - 격주 등); 요일 - 점검이 수행될 요일; 시간(시:분) - 점검이 시작되는 시간; 점검 기간 길이 - 점검이 활성화될 기간. 매주/몇 주마다 매개변수가 "1"보다 클 때, 시작 주는 활성화 시작일이 속하는 주입니다. 예시는 위의 매일 매개변수 설명을 참조하세요. |
| 매월 | 매월 점검 기간을 구성합니다: 월 - 정기 점검이 수행될 모든 월을 선택; 날짜: 월의 일 - 매월 같은 날짜에 점검이 수행되어야 하는 경우 (예: 매월 1일) 이 옵션을 선택하고, 나타나는 월의 일 필드에서 필요한 날을 선택; 날짜: 요일 - 특정 요일에만 점검이 수행되어야 하는 경우 (예: 매월 첫 번째 월요일) 이 옵션을 선택하고, 드롭다운에서 필요한 주(첫 번째, 두 번째, 세 번째, 네 번째 또는 마지막)를 선택한 다음 점검 요일의 체크박스를 선택; 시간(시:분) - 점검이 시작되는 시간; 점검 기간 길이 - 점검이 활성화될 기간. |
점검 기간을 생성할 때는 생성하는 사용자의 시간대가 사용됩니다. 하지만 반복 점검 기간(매일, 매주, 매월)이 예약될 때는 Zabbix 서버의 시간대가 사용됩니다. 반복 점검 기간의 예측 가능한 동작을 보장하려면 Zabbix의 모든 구성 요소에서 공통 시간대를 사용해야 합니다.
완료되면 추가를 눌러 점검 기간을 기간 블록에 추가합니다.
일광 절약 시간제(DST) 변경은 점검 지속 시간에 영향을 주지 않는다는 점에 유의하세요. 예를 들어, 보통 01:00에 시작하여 03:00에 종료되는 2시간 점검이 구성되어 있다고 가정해보겠습니다:
- 점검 1시간 후(02:00에) DST 변경이 발생하여 현재 시간이 02:00에서 03:00으로 변경되면, 점검은 1시간 더 지속됩니다(04:00까지);
- 점검 2시간 후(03:00에) DST 변경이 발생하여 현재 시간이 03:00에서 02:00으로 변경되면, 2시간이 경과했으므로 점검이 중지됩니다;
- DST 변경으로 건너뛰어지는 시간 동안 점검 기간이 시작되도록 설정된 경우, 점검은 시작되지 않습니다.
점검 기간이 "1일"로 설정되고(실제 점검 기간은 24시간, Zabbix는 일을 시간으로 계산하므로) 00:00에 시작하여 다음 날 00:00에 종료되는 경우:
- 현재 시간이 1시간 앞당겨지면 다음 날 01:00에 점검이 중지됩니다;
- 현재 시간이 1시간 뒤로 이동하면 그날 23:00에 점검이 중지됩니다.
디스플레이
유지보수 중인 호스트 표시
호스트명 옆의 주황색 렌치 아이콘 
은 다음 위치에서 해당 호스트가 유지보수 중임을 나타냅니다:
- 대시보드
- 모니터링 > 문제
- 인벤토리 > 호스트 > 호스트 인벤토리 세부정보
- 데이터 수집 > 호스트 ('상태' 컬럼 참조)
마우스 포인터를 아이콘 위에 위치시키면 유지보수 세부정보가 표시됩니다.
또한 유지보수 중인 호스트는 모니터링 > 맵에서 주황색 배경으로 표시됩니다.
억제된 문제 표시
일반적으로 유지보수 중인 호스트의 문제는 억제되어, 즉 프론트엔드에 표시되지 않습니다. 하지만 다음 위치에서 억제된 문제 표시 옵션을 선택하여 억제된 문제가 표시되도록 구성할 수도 있습니다:
- 대시보드 (문제 호스트, 문제, 심각도별 문제, 트리거 개요 위젯 구성에서)
- 모니터링 > 문제 (필터에서)
- 모니터링 > 맵 (맵 구성에서)
- 전역 알림 (사용자 프로필 구성에서)
억제된 문제가 표시될 때 다음 아이콘이 표시됩니다: 
.
아이콘 위에 마우스를 올리면 더 자세한 정보가 표시됩니다.
유지보수 중 큐 계산
Zabbix 프론트엔드에 표시되는 큐(관리 > 큐)는 Zabbix 서버에 의해 계산됩니다. 이 큐는 데이터 수집 없음 유지보수 상태의 항목들을 포함하지 않으며, 이러한 항목들의 값이 지연되더라도 큐 길이는 항상 0입니다. 데이터 수집 포함 유지보수 상태에서 지연된 항목들은 여전히 큐에서 계산됩니다.
Zabbix 프록시는 유지보수 기간을 인식하지 못합니다. 왜냐하면 Zabbix 서버와 프록시 간에 유지보수 설정의 동기화가 없기 때문입니다.
Zabbix 프록시에서 계산되는 내부 체크(예: zabbix[queue,,] 및 zabbix[stats,,,queue,,])는 Zabbix 서버의 유지보수 상태와 관계없이 지연된 항목들을 보고합니다.
결과적으로, 데이터 수집 없음 유지보수 상태에 있는 동일한 항목들에 대해 Zabbix 프론트엔드와 Zabbix 프록시의 내부 체크에서 서로 다른 큐 길이가 보고될 수 있습니다.