프록시
개요
Zabbix 프록시는 Zabbix 서버를 대신하여 성능 및 가용성 데이터를 수집할 수 있습니다. 이를 통해 프록시가 데이터 수집 부하 일부를 떠맡아 Zabbix 서버의 부담을 덜어줄 수 있습니다.
또한 프록시를 사용하는 것은 중앙 집중식·분산 모니터링을 구현하는 가장 쉬운 방법입니다. 모든 에이전트와 프록시가 하나의 Zabbix 서버로 보고하고 모든 데이터가 중앙에서 수집됩니다.
Zabbix 프록시는 다음 용도로 사용할 수 있습니다:
- 원격 위치 모니터링
- 통신이 불안정한 위치 모니터링
- 수천 개의 장치를 모니터링할 때 Zabbix 서버 부담 경감
- 분산 모니터링 유지보수 단순화
프록시는 Zabbix 서버로 향하는 TCP 연결 하나만 필요로 합니다. 이 방식은 방화벽 규칙을 하나만 설정하면 되므로 방화벽을 우회하기가 더 쉽습니다.
Zabbix 프록시는 반드시 별도의 데이터베이스를 사용해야 합니다. Zabbix 서버 데이터베이스를 가리키도록 설정하면 구성이 깨집니다.
프록시가 수집한 모든 데이터는 서버로 전송되기 전에 로컬에 저장됩니다. 이 방식 덕분에 서버와의 일시적인 통신 문제로 데이터가 유실되지 않습니다. 프록시 구성 파일의 ProxyLocalBuffer와 ProxyOfflineBuffer 매개변수가 데이터를 로컬에 얼마나 오래 보관할지 제어합니다.
Zabbix 서버 데이터베이스에서 직접 최신 구성 변경 사항을 받는 프록시가, CacheUpdateFrequency 값 때문에 그만큼 빠르게 갱신되지 않는 Zabbix 서버보다 더 최신 구성을 가지게 되는 경우가 있을 수 있습니다. 그 결과 프록시가 데이터를 수집해 Zabbix 서버로 전송해도 서버가 그 데이터를 무시할 수 있습니다.
Zabbix 프록시는 데이터 수집기입니다. 트리거를 계산하거나 이벤트를 처리하거나 알림을 보내지 않습니다. 프록시 기능 개요는 다음 표를 참고하세요:
| 기능 | < | 프록시 지원 여부 |
|---|---|---|
| 아이템 | < | < |
| < | Zabbix 에이전트 점검 | 예 |
| ^ | Zabbix 에이전트 점검(능동형) | 예 ^1^ |
| ^ | 단순 점검 | 예 |
| ^ | 트래퍼 아이템 | 예 |
| ^ | SNMP 점검 | 예 |
| ^ | SNMP 트랩 | 예 |
| ^ | IPMI 점검 | 예 |
| ^ | JMX 점검 | 예 |
| ^ | 로그 파일 모니터링 | 예 |
| ^ | 내부 점검 | 예 |
| ^ | SSH 점검 | 예 |
| ^ | Telnet 점검 | 예 |
| ^ | 외부 점검 | 예 |
| ^ | 종속 아이템 | 예 |
| ^ | 스크립트 아이템 | 예 |
| ^ | 브라우저 아이템 | 예 |
| 내장 웹 모니터링 | < | 예 |
| 아이템 값 전처리 | < | 예 |
| 네트워크 디스커버리 | < | 예 |
| 능동형 에이전트 자동 등록 | < | 예 |
| 로우 레벨 디스커버리 | < | 예 ^2^ |
| 원격 명령 | < | 예 |
| 트리거 계산 | < | 아니오 |
| 이벤트 처리 | < | 아니오 |
| 이벤트 상관관계 | < | 아니오 |
| 알림 전송 | < | 아니오 |
[1] 에이전트가 서버가 아닌 프록시에게 능동형 점검을 요청하도록
하려면, 에이전트 구성 파일의 ServerActive 매개변수에
해당 프록시가 나열돼 있어야 합니다.
[2] LLD의 경우, Zabbix 프록시는 데이터를 수집하고 전처리만 한 뒤
추가 처리를 위해 Zabbix 서버로 전송합니다.
과부하 방지
Zabbix 서버가 한동안 다운돼 있었고 프록시들이 많은 데이터를 수집한 상태에서 서버가 시작되면, 서버가 과부하 상태(히스토리 캐시 사용률이 한동안 95~100%로 유지됨)에 빠질 수 있습니다. 이 과부하는 점검 처리가 원래보다 느려지는 성능 저하로 이어질 수 있습니다. 히스토리 캐시 과부하로 인해 발생하는 문제를 피하기 위해 이런 시나리오에 대한 보호 장치가 구현돼 있습니다.
Zabbix 서버의 히스토리 캐시가 가득 차면 히스토리 캐시 쓰기 접근이 제한되어 서버의 데이터 수집 프로세스가 지연됩니다. 히스토리 캐시 과부하가 가장 흔하게 발생하는 경우는 서버 다운타임 이후 프록시들이 수집한 데이터를 업로드할 때입니다. 이를 피하기 위해 프록시 스로틀링이 추가됐습니다(현재는 비활성화할 수 없습니다).
히스토리 캐시 사용률이 80%에 도달하면 Zabbix 서버는 프록시로부터 데이터 수신을 중단합니다. 대신 해당 프록시들은 스로틀링 목록에 올라갑니다. 이 상태는 캐시 사용률이 60%로 떨어질 때까지 계속됩니다. 이후 서버는 스로틀링 목록에 정의된 순서대로 프록시로부터 데이터 수신을 하나씩 재개합니다. 즉 스로틀링 기간 중 가장 먼저 데이터 업로드를 시도한 프록시가 가장 먼저 처리되며, 그 프록시가 완료될 때까지 서버는 다른 프록시로부터 데이터를 받지 않습니다.
이 스로틀링 모드는 캐시 사용률이 다시 80%에 도달하거나 20%로 떨어지거나 스로틀링 목록이 비워질 때까지 계속됩니다. 첫 번째 경우엔 서버가 다시 프록시 데이터 수신을 중단합니다. 나머지 두 경우엔 서버가 모든 프록시로부터 정상적으로 데이터를 받기 시작합니다.
위 내용은 다음 표로 정리할 수 있습니다:
| 히스토리 쓰기 캐시 사용률 |
Zabbix 서버 모드 | Zabbix 서버 동작 |
|---|---|---|
| 80% 도달 | 대기 | 프록시 데이터 수신을 중단하지만, 스로틀링 목록(나중에 연락할 프록시의 우선순위 목록)은 유지합니다. |
| 60%로 하락 | 스로틀됨 | 스로틀링 목록 처리를 시작하지만 여전히 프록시 데이터는 받지 않습니다. |
| 20%로 하락 | 정상 | 스로틀링 목록을 비우고 프록시 데이터를 정상적으로 받기 시작합니다. |
zabbix[wcache,history,pused] 내부 아이템을 사용해 Zabbix 서버의 이런 동작을 지표와 연관지어 볼 수 있습니다.
구성
프록시를 설치하고 구성했다면, 이제 Zabbix 프론트엔드에서 프록시를 구성할 차례입니다.
프록시 추가
Zabbix 프론트엔드에서 프록시를 구성하려면:
- 이동: 관리 → 프록시
- 프록시 생성 클릭
| 매개변수 | < | 설명 |
|---|---|---|
| 프록시 이름 | < | 프록시 이름을 입력합니다. 프록시 구성 파일의 Hostname 매개변수와 같은 이름이어야 합니다. |
| 프록시 그룹 | < | 프록시 로드 밸런싱/고가용성을 위한 프록시 그룹을 하나 선택합니다. |
| 능동형 에이전트용 주소 | < | 모니터링 대상 능동형 에이전트나 센더가 연결해야 할 주소를 입력합니다. Zabbix 7.0 이상 에이전트에서만 지원됩니다. 이 주소는 능동형·수동형 프록시 연결 모두에 사용됩니다. 이 필드는 프록시 그룹 필드에서 프록시 그룹이 선택된 경우에만 표시됩니다. |
| 주소 | 연결할 IP 주소/DNS 이름. | |
| ^ | 포트 | 연결할 TCP 포트 번호(기본값 10051). 사용자 매크로를 지원합니다. |
| 프록시 모드 | < | 프록시 모드를 선택합니다. 능동형 - 프록시가 Zabbix 서버에 연결해 구성 데이터를 요청합니다 수동형 - Zabbix 서버가 프록시에 연결합니다 암호화된 통신을 사용하지 않으면(민감함) 능동형 프록시 사용 시 Zabbix 서버 트래퍼 포트에 접근할 수 있는 대상에게 프록시 구성 데이터가 노출될 수 있다는 점에 유의하세요. 인증이 이뤄지지 않거나 프록시 주소 필드에서 프록시 주소가 제한되지 않으면 누구든 능동형 프록시인 척하며 구성 데이터를 요청할 수 있기 때문입니다. |
| 프록시 주소 | < | 지정하면, 이 콤마로 구분된 IP 주소 목록(CIDR 표기 가능) 또는 능동형 Zabbix 프록시의 DNS 이름에서만 능동형 프록시 요청을 허용합니다. 이 필드는 프록시 모드 필드에서 능동형 프록시가 선택된 경우에만 표시됩니다. 매크로는 지원되지 않습니다. |
| 인터페이스 | < | 수동형 프록시의 인터페이스 정보를 입력합니다. 이 필드는 프록시 모드 필드에서 수동형 프록시가 선택된 경우에만 표시됩니다. |
| 주소 | 수동형 프록시의 IP 주소/DNS 이름. | |
| ^ | 포트 | 수동형 프록시의 TCP 포트 번호(기본값 10051). 사용자 매크로를 지원합니다. |
| 설명 | < | 프록시 설명을 입력합니다. |
암호화 탭에서는 프록시와의 암호화된 연결을 요구할 수 있습니다.
| 매개변수 | 설명 |
|---|---|
| 프록시로의 연결 | 서버가 수동형 프록시에 연결하는 방식: 암호화 없음(기본값), PSK(사전 공유 키) 또는 인증서 사용. |
| 프록시로부터의 연결 | 능동형 프록시로부터 허용할 연결 유형을 선택합니다. 여러 연결 유형을 동시에 선택할 수 있습니다(테스트나 다른 연결 유형으로 전환할 때 유용). 기본값은 "암호화 없음"입니다. |
| 발급자 | 허용된 인증서 발급자. 인증서는 먼저 CA(인증 기관)로 검증됩니다. 유효하고 CA가 서명한 경우, 발급자 필드로 허용되는 CA를 추가로 제한할 수 있습니다. 이 필드는 선택 사항이며, Zabbix 설치가 여러 CA의 인증서를 사용하는 경우에 씁니다. |
| 주체 | 허용된 인증서 주체. 인증서는 먼저 CA로 검증됩니다. 유효하고 CA가 서명한 경우, 주체 필드로 Subject 문자열 값 하나만 허용하도록 제한할 수 있습니다. 이 필드가 비어 있으면 구성된 CA가 서명한 유효한 인증서라면 모두 허용됩니다. |
| PSK 식별자 | 사전 공유 키 식별 문자열. PSK 식별자에 민감한 정보를 넣지 마세요. 이 값은 수신자에게 어떤 PSK를 사용할지 알리기 위해 네트워크로 암호화되지 않은 채 전송됩니다. |
| PSK | 사전 공유 키(16진수 문자열). 최대 길이: Zabbix가 GnuTLS나 OpenSSL 라이브러리를 사용하면 512자리 16진수(256바이트 PSK), mbed TLS(PolarSSL) 라이브러리를 사용하면 64자리 16진수(32바이트 PSK). 예: 1f87b595725ac58dd977beef14b97461a7c1045b9a1c963065002c5473194952 |
타임아웃 탭에서는 지원되는 아이템 유형에 대해 전역 타임아웃을 재정의할 수 있습니다.
| 매개변수 | 설명 |
|---|---|
| 아이템 유형별 타임아웃 | 타임아웃 옵션을 선택합니다: 전역 - 전역 타임아웃을 사용합니다(각 아이템 유형별로 회색으로 표시된 Timeout 필드에 표시됨); 재정의 - 사용자 지정 타임아웃을 사용합니다(각 아이템 유형별 Timeout 필드에서 설정). 허용 범위: 1~600초(기본값: 전역 타임아웃에서 상속). 시간 접미사(예: 30s, 1m)와 사용자 매크로를 지원합니다. Global timeouts 링크를 클릭하면 전역 타임아웃을 구성할 수 있습니다. Global timeouts 링크는 Administration → General 프론트엔드 섹션에 대한 권한을 가진 Super admin 유형 사용자에게만 표시된다는 점에 유의하세요. 지원되는 아이템 유형: - Zabbix 에이전트(수동형·능동형 점검 모두) - 단순 점검( icmpping*, vmware.* 아이템 제외)- SNMP 에이전트(SNMP walk[OID], get[OID] 아이템에만 해당)- 외부 점검 - 데이터베이스 모니터 - HTTP 에이전트 - SSH 에이전트 - TELNET 에이전트 - 스크립트 - 브라우저 재정의로 설정한 타임아웃은 전역 타임아웃보다 우선하지만, 아이템 구성에서 개별 아이템 타임아웃이 설정된 경우 그 값이 우선한다는 점에 유의하세요. |
프록시의 메이저 버전이 서버의 메이저 버전과 일치하지 않으면,
아이콘이
아이템 유형별 타임아웃 옆에 표시되며, 마우스를 올리면
"프록시와 서버 버전이 일치하지 않아 타임아웃이 비활성화되었습니다"라는
메시지가 나타납니다.
이런 경우 프록시는 프록시 구성 파일의 Timeout 매개변수를 사용합니다.
기존 프록시의 편집 폼에는 다음과 같은 추가 버튼이 있습니다:
- 구성 새로고침 - 프록시 구성을 새로고침합니다
- 복제 - 기존 프록시의 속성을 기반으로 새 프록시를 생성합니다
- 삭제 - 프록시를 삭제합니다
호스트 구성
호스트 구성 폼의 모니터링 주체 필드를 사용해 개별 호스트를 프록시나 프록시 그룹이 모니터링하도록 지정할 수 있습니다.
호스트를 프록시나 프록시 그룹이 모니터링하도록 지정하는 또 다른 방법은 호스트 일괄 업데이트입니다.