알려진 문제
참고: Compilation issues.
7.4.4에서 알려진 문제
다음 이유로 이 버전으로 업그레이드하는 것은 권장되지 않습니다:
- Zabbix agent 2 MySQL 플러그인을 사용하는 경우 CPU 사용량이 갑자기 급증하는 문제 (참고: ZBX-27156)
- 정의되지 않은 인덱스 오류로 인해 Zabbix 능동형 에이전트 아이템 그래프에서 "Undefined array key" 경고가 표시되는 문제 (참고: ZBX-27153)
업그레이드
업그레이드 성공을 위한 sql_mode 설정
MySQL/MariaDB의 sql_mode 설정에는 "STRICT_TRANS_TABLES" 모드가 설정되어 있어야 합니다.
이 설정이 없으면 Zabbix 데이터베이스 업그레이드가 실패합니다 (참고: ZBX-19435).
MariaDB 10.2.1 이하 버전에서의 업그레이드
데이터베이스 테이블이 MariaDB 10.2.1 이하 버전에서 생성된 경우 Zabbix 업그레이드가 실패할 수 있습니다. 해당 버전에서는 기본 행 형식(row format)이 compact이기 때문입니다. 행 형식을 dynamic으로 변경하면 이 문제를 해결할 수 있습니다 (참고: ZBX-17690).
MySQL 데이터베이스 문자셋 및 정렬 규칙(collation)
utf8mb3 문자셋과 utf8mb3_bin 정렬 규칙으로 생성된 MySQL 데이터베이스를 사용하는 Zabbix 설치본에서는 문제가 발생할 수 있습니다. 예를 들어, known MySQL issue로 인해 데이터베이스 스키마 업그레이드나 기타 DDL 작업 중 Row size too large (> 8126) 오류가 발생할 수 있습니다.
utf8mb3 문자셋과 utf8mb3_bin 정렬 규칙을 사용하는 데이터베이스는 Repairing Zabbix database character set and collation에 설명된 대로 utf8mb4 문자셋과 utf8mb4_bin 정렬 규칙으로 변환하는 것이 강력히 권장됩니다.
libcurl 8.21.0에서의 메모리 및 파일 디스크립터 누수
libcurl 8.21.0의 known issue로 인해 TLS로 보호된 연결을 처리할 때 libcurl을 사용하는 Zabbix 기능에서 메모리 및 파일 디스크립터 누수가 발생할 수 있습니다.
이 문제에 대한 해결책은 수정 사항이 포함된 릴리스가 나올 때까지 libcurl을 8.20.0 버전으로 다운그레이드하는 것입니다.
템플릿
듀얼 스택(IPv4/IPv6) 환경에서의 템플릿 호환성
듀얼 스택 환경(IPv4와 IPv6를 모두 지원하도록 구성된 시스템)에서는 호스트명 localhost가 일반적으로 IPv4와 IPv6 주소 모두로 확인됩니다(resolve).
많은 운영체제와 DNS 리졸버가 IPv4보다 IPv6를 우선시하는 경향 때문에, 모니터링 대상 서비스가 IPv4로만 리스닝하도록 구성된 경우 Zabbix 템플릿이 제대로 작동하지 않을 수 있습니다.
IPv6 주소로 리스닝하도록 구성되지 않은 서비스는 접근이 불가능해질 수 있으며, 이는 모니터링 실패로 이어집니다. 사용자가 IPv4에 대해서는 접근을 올바르게 구성했더라도, IPv6를 우선시하는 기본 동작 때문에 여전히 연결 문제를 겪을 수 있습니다.
이에 대한 해결책은 서비스(Nginx, Apache, PostgreSQL 등)가 IPv4와 IPv6 주소 모두로 리스닝하도록 구성하고, Zabbix 서버/에이전트가 IPv6를 통한 접근을 허용받도록 하는 것입니다.
또한 Zabbix 템플릿과 설정에서는 127.0.0.1 대신 localhost를 명시적으로 사용하여 IPv4와 IPv6 모두와의 호환성을 보장하십시오.
예를 들어, PostgreSQL by Zabbix agent 2 템플릿으로 PostgreSQL을 모니터링할 때, zbx_monitor 사용자의 연결을 허용하기 위해 pg_hba.conf 파일을 수정해야 할 수 있습니다.
듀얼 스택 환경에서 IPv6가 우선시되어(시스템이 localhost를 ::1로 확인) localhost를 구성했지만 IPv4 항목(127.0.0.1/32)만 추가한 경우, 일치하는 IPv6 항목이 없기 때문에 연결이 실패합니다.
다음 pg_hba.conf 파일 예제는 zbx_monitor 사용자가 로컬 머신에서 IPv4와 IPv6 주소 모두를 통해 서로 다른 인증 방식으로 모든 데이터베이스에 연결할 수 있도록 보장합니다:
# TYPE DATABASE USER ADDRESS METHOD
host all zbx_monitor localhost trust
host all zbx_monitor 127.0.0.1/32 md5
host all zbx_monitor ::1/128 scram-sha-256
필요하다면, PostgreSQL by Zabbix agent 2 템플릿의 연결 문자열 매크로를 설정할 때 IPv4 주소(127.0.0.1)를 직접 사용할 수도 있습니다.
EPEL Zabbix 패키지의 의도치 않은 설치
EPEL 저장소가 설치되어 활성화된 경우, Zabbix 패키지를 설치할 때 공식 Zabbix 패키지 대신 EPEL 버전이 설치될 수 있습니다. 이를 해결하려면:
1. EPEL에서 설치된 Zabbix 패키지를 제거합니다:
dnf remove zabbix-server-mysql
2. /etc/yum.repos.d/epel.repo 파일에 다음 줄을 추가하여 EPEL에서 Zabbix 패키지를 제외합니다:
[epel]
...
excludepkgs=zabbix*
3. 공식 Zabbix 서버 패키지를 재설치합니다:
dnf install zabbix-server-mysql
설치 시 공식 Zabbix 패키지의 버전 문자열에는 release라는 단어가 포함되어 있어(예: 7.0.0-release1.el8) EPEL 패키지와 구분할 수 있습니다.
Red Hat UBI 환경에서 RHEL용 Zabbix 패키지
Red Hat Universal Base Image 환경에서 Red Hat Enterprise Linux 패키지로 Zabbix를 설치할 때는 필요한 저장소와 의존성에 대한 접근이 가능한지 확인해야 합니다.
Zabbix 패키지는 libOpenIPMI.so 및 libOpenIPMIposix.so 라이브러리에 의존하는데, 이 라이브러리들은 UBI 시스템에서 기본으로 활성화된 패키지 관리자 저장소의 어떤 패키지에서도 제공되지 않아 설치가 실패하게 됩니다.
libOpenIPMI.so와 libOpenIPMIposix.so 라이브러리는 OpenIPMI-libs 패키지에서 제공되며, 이 패키지는 redhat-#-for-<arch>-appstream-rpms 저장소에서 제공됩니다.
이 저장소에 대한 접근은 구독(subscription)을 통해 관리되며, UBI 환경의 경우 RHEL 호스트의 저장소 설정 및 시크릿 디렉터리를 컨테이너 파일시스템 네임스페이스에 마운트하여 전파됩니다.
자세한 내용은 ZBX-24291을 참고하십시오.
RHEL 패키지의 서명 키 만료
Red Hat Enterprise Linux 또는 그 파생 배포판에서 Zabbix를 업그레이드할 때, Zabbix repository의 패키지에 대해 서명 키 만료 문제가 발생할 수 있습니다. 서명 키가 만료되면 패키지 서명 검증 시 인증서 또는 키가 더 이상 유효하지 않다는 오류가 발생합니다. 예를 들어:
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <packager@zabbix.com>):
1. Certificate 19F2475308EFA7DD invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2024-07-04T11:41:23Z
2. Key 19F2475308EFA7DD invalid: key is not alive
because: The primary key is not live
because: Expired on 2024-07-04T11:41:23Z
이러한 문제를 해결하려면 사용 중인 RHEL 버전에 맞는 최신 zabbix-release 패키지를 수동으로 재설치하십시오 (아래 링크를 Zabbix repository에서 정확한 링크로 교체하십시오).
예를 들어 RHEL 9에서는 다음을 실행합니다:
rpm -Uvh https://repo.zabbix.com/zabbix/7.4/release/rhel/9/noarch/zabbix-release-latest.el9.noarch.rpm
그런 다음 저장소 정보를 업데이트합니다:
dnf update
자세한 내용은 ZBX-24761을 참고하십시오.
Timescale DB: 파티션 수가 많을 때 높은 메모리 사용량
PostgreSQL 9.6-12 버전은 파티션 수가 많은 테이블을 업데이트할 때 메모리를 과도하게 사용합니다. 이 문제는 트렌드가 상대적으로 작은(예: 1일 단위) 청크로 분할된 경우, TimescaleDB를 사용하는 시스템에서 Zabbix가 트렌드를 업데이트할 때 나타납니다. 기본 하우스키핑 설정에서는 트렌드 테이블에 수백 개의 청크가 생기게 되어, PostgreSQL이 메모리 부족에 빠지기 쉬운 상황이 됩니다.
이 문제는 TimescaleDB를 사용하는 신규 설치의 경우 Zabbix 5.0.1부터 해결되었지만, 그 이전에 TimescaleDB로 Zabbix를 설정한 경우에는 마이그레이션 방법에 대해 ZBX-16347을 참고하십시오.
Timescale DB 2.5.0: 정수를 포함하는 테이블에서 압축 정책이 실패할 수 있음
이 문제는 TimescaleDB 2.5.0/2.5.1을 사용할 때 나타납니다. TimescaleDB 2.5.2부터 해결되었습니다.
자세한 내용은 TimescaleDB Issue #3773을 참고하십시오.
MariaDB에서의 데이터베이스 TLS 연결
MariaDB를 사용하는 경우 DBTLSConnect 파라미터의 'verify_ca' 옵션으로는 데이터베이스 TLS 연결이 지원되지 않습니다.
MySQL/MariaDB에서 발생 가능한 데드락
높은 부하 상태에서 둘 이상의 LLD 워커가 관련될 경우, 행 잠금(row-locking) 전략과 관련된 InnoDB 오류로 인해 데드락이 발생할 수 있습니다 (참고: upstream bug). 이 오류는 MySQL 8.0.29부터 수정되었지만 MariaDB에서는 수정되지 않았습니다. 자세한 내용은 ZBX-21506을 참고하십시오.
전역 이벤트 상관관계
첫 번째 이벤트와 두 번째 이벤트 사이의 시간 간격이 매우 짧은 경우(즉 0.5초 이하), 이벤트가 올바르게 상관관계 처리되지 않을 수 있습니다.
PostgreSQL 11 이하에서 숫자(float) 데이터 유형 범위
PostgreSQL 11 이하 버전은 약 -1.34E-154에서 1.34E+154 범위의 부동소수점 값만 지원합니다.
NetBSD 8.0 이상
NetBSD 8.X 및 9.X 버전에서 다양한 Zabbix 프로세스가 시작 시 무작위로 크래시할 수 있습니다. 이는 기본 스택 크기(4MB)가 너무 작기 때문이며, 다음을 실행하여 크기를 늘려야 합니다:
ulimit -s 10240
자세한 내용은 관련 문제 보고서를 참고하십시오: ZBX-18275.
Zabbix agent 2의 정규표현식 제한 사항
Zabbix agent 2는 표준 Go regexp 라이브러리의 제약으로 인해 정규표현식에서 lookahead와 lookbehind를 지원하지 않습니다.
IPMI 점검
IPMI 점검은 Debian 9(stretch) 이전 버전 및 Ubuntu 16.04(xenial) 이전 버전에서 표준 OpenIPMI 라이브러리 패키지로는 작동하지 않습니다. 이를 해결하려면 ZBX-6139에서 설명하는 대로 OpenSSL을 활성화하여 OpenIPMI 라이브러리를 다시 컴파일하십시오.
IPMI — 신뢰할 수 없는 호스트가 OpenIPMI를 크래시시킬 수 있음
Zabbix가 IPMI 데이터를 폴링하는 데 사용하는 OpenIPMI 라이브러리에는 신뢰할 수 없는 장치가 특별히 조작된 응답을 보낼 경우 촉발될 수 있는 버그가 있습니다.
신뢰할 수 없는 IPMI 장치가 조작된 데이터를 보내면 OpenIPMI 라이브러리가 크래시할 수 있으며, 이로 인해 IPMI 폴링을 수행하는 Zabbix 서버 프로세스가 종료될 수 있습니다.
SSH 점검
- Debian, Ubuntu 등 일부 Linux 배포판에서는 libssh2 라이브러리가 패키지로 설치된 경우 암호화된(암호문이 있는) 개인 키를 지원하지 않습니다. 자세한 내용은 ZBX-4850을 참고하십시오.
- 일부 Linux 배포판에서 OpenSSH 8과 함께 libssh 0.9.x를 사용하는 경우, SSH 점검에서 "Cannot read data from SSH server" 오류가 간헐적으로 발생할 수 있습니다. 이는 libssh issue로 인한 것입니다 (more detailed report). 이 오류는 안정 버전인 libssh 0.9.5 릴리스에서 수정된 것으로 예상됩니다. 자세한 내용은 ZBX-17756도 참고하십시오.
- SSH 스크립트에서 파이프 "|"를 사용하면 "Cannot read data from SSH server" 오류가 발생할 수 있습니다. 이 경우 libssh 라이브러리 버전을 업그레이드하는 것이 권장됩니다. 자세한 내용은 ZBX-21337도 참고하십시오.
ODBC 점검
-
MariaDB 커넥터 라이브러리를 대상으로 컴파일된 Zabbix 서버나 Zabbix 프록시에서는 MySQL unixODBC 드라이버를 사용하지 않아야 하며, 그 반대의 경우도 마찬가지입니다. 가능하다면 upstream bug 때문에 드라이버와 동일한 커넥터를 사용하는 것도 피하는 것이 좋습니다. 권장 설정:
PostgreSQL, SQLite 또는 Oracle 커넥터 → MariaDB 또는 MySQL unixODBC 드라이버
MariaDB 커넥터 → MariaDB unixODBC 드라이버
MySQL 커넥터 → MySQL unixODBC 드라이버자세한 정보와 사용 가능한 해결책은 ZBX-7665를 참고하십시오.
-
Microsoft SQL Server에서 조회한 XML 데이터가 Linux 및 UNIX 시스템에서 여러 방식으로 잘릴(truncated) 수 있습니다.
-
Linux용 다양한 버전의 Oracle Instant Client를 사용하여 Oracle 데이터베이스를 모니터링하는 ODBC 점검을 사용할 경우 Zabbix 서버가 크래시하는 것으로 관찰되었습니다.
참고: ZBX-18402, ZBX-20803. -
FreeTDS UnixODBC 드라이버를 사용하는 경우, SQL 쿼리 앞에 'SET NOCOUNT ON' 문을 추가해야 합니다(예:
SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). 그렇지 않으면 Zabbix의 데이터베이스 모니터 아이템이 "SQL query returned empty result" 오류와 함께 정보를 가져오지 못합니다.
자세한 내용은 ZBX-19917을 참고하십시오.
아이템의 잘못된 요청 방식(request method) 파라미터
HTTP 점검에서만 사용되는 요청 방식 파라미터가, pre-4.0 Zabbix 버전에서 업그레이드한 결과로 모든 아이템에 대해 기본값이 아닌 '1'로 잘못 설정될 수 있습니다. 이 상황을 해결하는 방법은 ZBX-19308을 참고하십시오.
웹 모니터링 및 HTTP 에이전트
웹 시나리오나 HTTP 에이전트에서 "SSL verify peer"가 활성화된 경우, 일부 Linux 배포판에서 upstream bug로 인해 Zabbix 서버가 메모리를 누수합니다. 자세한 정보와 사용 가능한 해결책은 ZBX-10486을 참고하십시오.
단순 점검(Simple checks)
v3.10 이전 버전의 fping에는 중복된 echo 응답 패킷을 잘못 처리하는 버그가 있습니다.
이로 인해 icmpping, icmppingloss, icmppingsec 아이템에서 예기치 않은 결과가 나타날 수 있습니다.
최신 버전의 fping을 사용하는 것이 권장됩니다.
자세한 내용은 ZBX-11726을 참고하십시오.
Rootless 컨테이너에서의 fping 실행 오류
컨테이너가 rootless 모드나 특정 제약이 있는 환경에서 실행되는 경우, ICMP 점검을 수행할 때 fping: Operation not permitted와 같은 fping 실행 관련 오류나 모든 리소스로의 모든 패킷 손실이 발생할 수 있습니다.
이 문제를 해결하려면 "docker run" 또는 "podman run" 명령에 --cap-add=net_raw를 추가하십시오.
또한 non-root 환경에서의 fping 실행에는 sysctl 수정이 필요할 수 있습니다. 예:
sudo sysctl -w "net.ipv4.ping_group_range=0 1995"
여기서 "1995"는 zabbix GID입니다. 자세한 내용은 ZBX-22833을 참고하십시오.
SNMP 점검
OpenBSD 운영체제를 사용하는 경우, Net-SNMP 라이브러리 5.7.3 버전까지 존재하는 use-after-free 버그로 인해 Zabbix 서버 설정 파일에 SourceIP 파라미터가 설정되어 있으면 Zabbix 서버가 크래시할 수 있습니다. 해결책으로는 SourceIP 파라미터를 설정하지 않는 것입니다. 동일한 문제가 Linux에서도 발생하지만, Zabbix 서버가 작동을 멈추지는 않습니다. OpenBSD의 net-snmp 패키지에 대한 로컬 패치가 적용되었으며 OpenBSD 6.3과 함께 릴리스될 예정입니다.
SNMP 데이터 스파이크
전원 전압 스파이크와 같은 특정 물리적 요인과 관련이 있을 수 있는 SNMP 데이터 스파이크가 관찰되었습니다. 자세한 내용은 ZBX-14318을 참고하십시오.
SNMP 트랩
SNMP 트랩에 필요한 "net-snmp-perl" 패키지가 RHEL 8.0-8.2에서 제거되었으며, RHEL 8.3에서 다시 추가되었습니다.
따라서 RHEL 8.0-8.2를 사용 중이라면 RHEL 8.3으로 업그레이드하는 것이 최선의 해결책입니다.
자세한 내용은 ZBX-17192도 참고하십시오.
RHEL 7에서의 alerter 프로세스 크래시
RHEL 7에서 Zabbix 서버 alerter 프로세스가 크래시하는 사례가 발견되었습니다. 자세한 내용은 ZBX-10461을 참고하십시오.
Zabbix agent 2 업그레이드 (6.0.5 이하)
Zabbix agent 2(6.0.5 이하 버전)를 패키지에서 업그레이드할 때, 플러그인 관련 파일 충돌 오류가 발생할 수 있습니다. 이 오류를 해결하려면 (필요한 경우) agent 2 설정을 백업한 후, agent 2를 제거하고 새로 설치하십시오.
RHEL 기반 시스템에서는 다음을 실행합니다:
dnf remove zabbix-agent2
dnf install zabbix-agent2
Debian 기반 시스템에서는 다음을 실행합니다:
apt remove zabbix-agent2
apt install zabbix-agent2
자세한 내용은 ZBX-23250을 참고하십시오.
프론트엔드 로케일이 바뀌는 현상
프론트엔드 로케일이 뚜렷한 규칙 없이 바뀌는 현상이 관찰되었습니다. 즉 일부 페이지(또는 페이지의 일부)는 한 언어로 표시되고 다른 페이지(또는 다른 부분)는 다른 언어로 표시됩니다. 일반적으로 여러 사용자가 있고 그중 일부는 한 로케일을, 다른 일부는 다른 로케일을 사용할 때 이 문제가 나타날 수 있습니다.
이에 대한 알려진 해결책은 PHP와 Apache에서 멀티스레딩을 비활성화하는 것입니다.
이 문제는 PHP에서 로케일 설정이 작동하는 방식과 관련이 있습니다: 로케일 정보는 스레드 단위가 아니라 프로세스 단위로 유지됩니다. 따라서 동일한 Apache 프로세스가 여러 프로젝트를 실행하는 멀티스레드 환경에서는, 다른 스레드에서 로케일이 변경되어 Zabbix 스레드에서 데이터가 처리되는 방식이 달라질 수 있습니다.
자세한 내용은 관련 문제 보고서를 참고하십시오:
그래프
클래식 그래프 문제
클래식 그래프에서 문제가 발생하는 경우, GD 라이브러리(libgd)를 2.3.3-13 이상 버전으로, PHP를 8.0.19, 8.1.33, 8.2.29, 8.3.25, 8.4.12 이상 버전으로 업데이트하는 것이 권장됩니다.
일광절약시간제(DST)
일광절약시간제(DST) 변경으로 인해 X축 레이블 표시에 불규칙성(날짜 중복, 날짜 누락 등)이 발생합니다.
합계 집계(Sum aggregation)
그래프에서 1시간 미만의 기간에 대해 합계 집계를 사용하면, 데이터가 트렌드에서 올 때 그래프에 잘못된(곱해진) 값이 표시됩니다.
텍스트 겹침
일부 프론트엔드 언어(예: 일본어)의 경우 로컬 글꼴로 인해 그래프 범례에서 텍스트가 겹칠 수 있습니다. 이를 피하려면 PHP GD 확장 2.3.0 버전(또는 그 이후)을 사용하십시오.
로그 파일 모니터링
파일 시스템이 100% 가득 차고 로그 파일에 계속 내용이 추가되는 경우, log[] 및 logrt[] 아이템이 로그 파일을 처음부터 반복적으로 다시 읽습니다 (자세한 내용은 ZBX-10884 참고).
느린 MySQL 쿼리
아이템에 대해 존재하지 않는 값이 있는 경우 Zabbix 서버는 느린 SELECT 쿼리를 생성합니다.
이 문제는 MySQL 5.6/5.7 버전에서 발생하는 것으로 알려져 있으며(자세한 논의는 ZBX-10652 참고), 특정 경우에는 이후 MySQL 버전에서도 발생할 수 있습니다.
이에 대한 해결책은 MySQL에서 index_condition_pushdown 또는 prefer_ordering_index 옵티마이저를 비활성화하는 것입니다.
다만 이 해결책이 느린 쿼리와 관련된 모든 문제를 해결하지는 못할 수 있습니다.
링크에서 유지되는 필터 설정
필터 설정(시간 선택기 포함)이 포함된 Zabbix 프론트엔드 페이지 링크를 열면, 해당 사용자에 대해 필터가 데이터베이스에 자동으로 저장되어 그 페이지의 이전에 저장된 필터 및/또는 시간 선택기 설정을 대체합니다. 이 설정은 사용자가 수동으로 업데이트하거나 재설정할 때까지 계속 적용됩니다.
SNMPv3 트랩에서의 IPv6 주소 문제
net-snmp 버그로 인해 SNMP 트랩에서 SNMPv3를 사용할 때 IPv6 주소가 올바르게 표시되지 않을 수 있습니다. 자세한 내용과 가능한 해결책은 ZBX-14541을 참고하십시오.
로그인 실패 정보에서 잘리는 긴 IPv6 IP 주소
로그인 실패 메시지에는 데이터베이스 필드의 문자 수 제한으로 인해 저장된 IP 주소의 첫 39자만 표시됩니다. 즉 39자를 초과하는 IPv6 IP 주소는 불완전하게 표시됩니다.
Windows에서의 Zabbix 에이전트 점검
Zabbix 에이전트 설정 파일(zabbix_agentd.conf)의 Server 파라미터에 존재하지 않는 DNS 항목이 있으면 Windows에서 Zabbix 에이전트의 응답 시간이 늘어날 수 있습니다.
이는 Windows DNS 캐싱 데몬이 IPv4 주소에 대한 negative 응답을 캐시하지 않기 때문입니다.
그러나 IPv6 주소에 대해서는 negative 응답이 캐시되므로, 이에 대한 해결책은 해당 호스트에서 IPv4를 비활성화하는 것입니다.
YAML 내보내기/가져오기
YAML 내보내기/가져오기에는 다음과 같은 알려진 문제가 있습니다:
- 오류 메시지가 번역되지 않음;
- 유효한 JSON이지만 .yaml 파일 확장자를 가진 경우 가져오기가 되지 않을 때가 있음;
- 따옴표로 감싸지 않은 사람이 읽을 수 있는 형식의 날짜가 자동으로 유닉스 타임스탬프로 변환됨.
NGINX 및 php-fpm을 사용하는 SUSE에서의 설치 마법사
NGINX + php-fpm을 사용하는 SUSE에서는 프론트엔드 설치 마법사가 설정 파일을 저장할 수 없습니다. 이는 /usr/lib/systemd/system/php-fpm.service 유닛의 설정 때문에 Zabbix가 /etc에 쓰기를 할 수 없어서 발생합니다 (PHP 7.4에서 도입됨).
다음 두 가지 해결 방법이 있습니다:
- php-fpm systemd 유닛에서 ProtectSystem 옵션을 'full' 대신 'true'로 설정합니다.
- /etc/zabbix/web/zabbix.conf.php 파일을 수동으로 저장합니다.
Authorization 헤더 전달
경우에 따라 Apache나 NGINX가 API 요청의 Authorization 헤더가 Zabbix에 전달되는 것을 막을 수 있습니다. 이로 인해 Zabbix API를 사용하거나 SAML with Okta와 같은 SSO(싱글 사인온) 서비스를 사용할 때 인증 문제가 발생할 수 있습니다.
이를 해결하려면 웹 서버의 설정을 업데이트하십시오.
Apache를 리버스 프록시(non-CGI 설정)로 사용하는 경우, RHEL 기반 시스템에서는 /etc/httpd/conf/httpd.conf에, Debian/Ubuntu에서는 /etc/apache2/apache2.conf에 다음 지시문을 추가하십시오:
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
Apache가 (mod_cgi 등을 사용하여) 요청을 처리하기 위해 스크립트를 직접 실행하는 경우, 대신 다음 지시문을 추가하십시오:
CGIPassAuth On
반면 NGINX는 Authorization 헤더를 자동으로 처리합니다.
그러나 NGINX가 리버스 프록시로 동작하는 경우, Zabbix 프론트엔드 location에 대해 /etc/nginx/nginx.conf에 다음 지시문을 추가하여 Authorization 헤더를 명시적으로 전달할 수 있습니다:
...
location / {
...
proxy_set_header Authorization $http_authorization;
proxy_pass http://backend_server;
...
}
설정을 업데이트한 후 웹 서버를 재시작하십시오.
자세한 내용은 다음을 참고하십시오:
- ZBX-22952
- Apache 2.4 + PHP-FPM and Authorization headers
- SetEnvIfNoCase 및 CGIPassAuth 지시문
- NGINX Reverse Proxy
Ubuntu 20에서 Zabbix web service용 Chromium
대부분의 경우 Zabbix web service는 Chromium과 함께 실행될 수 있지만, Ubuntu 20.04에서 Chromium을 사용하면 다음과 같은 오류가 발생합니다:
Cannot fetch data: chrome failed to start:cmd_run.go:994:
WARNING: cannot create user data directory: cannot create
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.
이 오류는 /var/lib/zabbix가 'zabbix' 사용자의 홈 디렉터리로 사용되기 때문에 발생합니다.
MySQL 사용자 정의 오류 코드
Zabbix는 백엔드 데이터베이스에 접근할 수 없음을 감지하면 알림을 보내고 계속 연결을 시도합니다. 특정 데이터베이스 엔진의 경우 특정 오류 코드가 인식됩니다. MySQL에서 인식되는 오류 코드는 다음과 같습니다:
- CR_CONN_HOST_ERROR
- CR_SERVER_GONE_ERROR
- CR_CONNECTION_ERROR
- CR_SERVER_LOST
- CR_UNKNOWN_HOST
- ER_SERVER_SHUTDOWN
- ER_ACCESS_DENIED_ERROR
- ER_ILLEGAL_GRANT_FOR_TABLE
- ER_TABLEACCESS_DENIED_ERROR
- ER_UNKNOWN_ERROR
또한 Azure에서 MySQL 설치본과 함께 Zabbix를 사용하는 경우, Zabbix 로그에 일반적인 오류 메시지 [9002] Some errors occurred가 나타날 수 있습니다. 이 메시지는 데이터베이스가 Zabbix 서버 또는 프록시로 보내는 것입니다. 오류의 원인을 파악하려면 Azure 로그를 확인하십시오.
PCRE2 전환 후 유효하지 않은 정규표현식
Zabbix 6.0에서 PCRE2 지원이 추가되었습니다. PCRE는 여전히 지원되지만, RHEL 7 이상, SLES(모든 버전), Debian 9 이상, Ubuntu 16.04 이상용 Zabbix 설치 패키지는 PCRE2를 사용하도록 업데이트되었습니다. 많은 이점을 제공하지만, PCRE2로의 전환으로 인해 기존의 일부 PCRE 정규표현식 패턴이 유효하지 않게 되거나 다르게 동작할 수 있습니다. 특히 이는 ^[\w-\.] 패턴에 영향을 미칩니다. 의미를 바꾸지 않으면서 이 정규표현식을 다시 유효하게 만들려면 표현식을 ^[-\w\.]로 변경하십시오. 이는 PCRE2가 문자 클래스 내에서 대시 기호를 구분자로 취급하여 범위를 생성하기 때문에 발생합니다.
문자 클래스 내 괄호가 있는 정규표현식
문자 클래스 안에 괄호가 포함된 정규표현식(예: [(])은 유효하지 않은 것으로 거부됩니다.
이는 전처리 단계, 템플릿 가져오기, 스크립트, 정규표현식 테스트, 아이콘 매핑, 값 매핑 등 정규표현식이 입력되거나 가져와지는 모든 곳에서 발생할 수 있습니다.
이 문제에 대한 해결책은 이스케이프된 괄호를 사용하는 것입니다. 예: [\(].
이 문제는 Zabbix 7.4.6에서 수정되었습니다. 자세한 내용은 ZBX-26303을 참고하십시오.
Geomap 위젯 오류
NGINX를 사용하는 이전 Zabbix 버전에서 업그레이드했지만 업그레이드 중 새로운 NGINX 설정 파일로 전환하지 않은 경우, Geomap 위젯의 지도가 올바르게 로드되지 않을 수 있습니다.
이 문제를 해결하려면 기존 설정 파일을 폐기하고, 현재 버전 패키지의 설정 파일을 사용하여 다운로드 안내의 e. Configure PHP for Zabbix frontend 섹션에 설명된 대로 재구성하십시오.
또는 기존 NGINX 설정 파일(일반적으로 /etc/zabbix/nginx.conf)을 수동으로 편집할 수도 있습니다. 그러려면 파일을 열고 다음 블록을 찾으십시오:
location ~ /(api\/|conf[^\.]|include|locale|vendor) {
deny all;
return 404;
}
그런 다음 이 블록을 다음으로 교체하십시오:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
전처리 — 전역 변수는 안전하지 않음
전처리 JavaScript는 요청마다 실행되지만, 선언되지 않은 식별자에 값을 대입하는 경우(예: secret = value) 암묵적 전역 변수가 생성되며 이는 현재 실행이 끝난 후에도 유지될 수 있습니다.
민감한 데이터(토큰, 비밀번호 등)를 암묵적 전역 변수에 저장하면 이후의 전처리 실행이나 동일 환경에서 실행되는 다른 통합에 의해 실수로 노출되거나 재사용될 위험이 커집니다.
암묵적 전역 변수에 의존하지 마십시오.
항상 var 또는 const로 변수를 선언하고, 시크릿을 전역 객체(예: globalThis나 window)에 붙이는 것을 피하십시오.
전처리 내에서 내장 전역 객체를 재정의하는 지원되는 방법은 없습니다.
안전한 예제:
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });
Windows의 프로세서 그룹
Microsoft 문서에 따르면 논리 프로세서가 64개 미만인 시스템은 항상 단일 프로세서 그룹(Group 0)을 가진다고 합니다. 그러나 Zabbix 사용자들은 논리 프로세서가 64개 이하인 시스템에서 두 개의 프로세서 그룹이 존재하는 드문 버그 ZBX-20260을 보고했습니다. 이로 인해 두 프로세서 그룹 중 하나에 대해서만 "\Processor(n)" 성능 카운터가 존재하게 되었습니다. 이 버그의 실제 근본 원인은 알려져 있지 않습니다. 다만 stackoverflow.com에 유사한 사례가 설명되어 있으며, 거기서는 BIOS와 Windows 간 상호운용성이 근본 원인이었습니다.
utf8mb4 정렬 규칙에서의 필터링 한계
특정 유니코드 문자(예: ȼ, ɇ)를 포함하는 엔터티에 대해 필터(예: Data collection > Maintenance)를 적용할 때 제대로 작동하지 않을 수 있습니다. 이 문제는 MySQL이나 MariaDB 데이터베이스의 기본 utf8mb4_bin 정렬 규칙이 유니코드 문자의 정렬 및 비교를 처리하는 방식 때문에 발생합니다.
이 제한을 해결하려면 데이터베이스 컬럼의 정렬 규칙을 utf8mb4_0900_bin, utf8mb4_0900_ai_ci, utf8mb4_unicode_520_ci 등의 대안으로 변경할 수 있습니다. 다만 정렬 규칙을 변경하면 공백 처리 방식이나 다른 문자에 대한 정렬 및 필터링에서 예기치 않은 동작이 발생할 수 있다는 점에 유의하십시오.
정렬 규칙 변경에 대한 자세한 내용은 MySQL documentation 또는 MariaDB documentation을 참고하십시오. 정렬 규칙 차이에 대한 자세한 내용은 MySQL 문서의 Unicode Character Sets를 참고하십시오.
MariaDB 10.5.1-10.5.9에서의 UI 요소 접근
Super Admin이 아닌 역할로 Zabbix 웹 프론트엔드에 접근하면 "System error occurred. Please contact Zabbix administrator." 메시지가 표시될 수 있습니다. 이 문제는 MariaDB 버전 10.5.1부터 10.5.9까지를 사용하는 설치본에 영향을 미칩니다.
이 문제를 피하려면 MariaDB를 10.5.9 이후 버전으로 업데이트하십시오. 자세한 내용은 ZBX-25746을 참고하십시오.
tcmalloc으로 과도한 메모리 사용량 프로파일링
Zabbix 설치본이 메모리를 너무 많이 사용한다고 의심되는 경우, tcmalloc의 메모리 프로파일링 기능을 사용하여 Zabbix 서버/프록시의 메모리 사용량을 조사할 수 있습니다.
1. Zabbix를 소스에서 설치할 때, 추가 플래그를 설정합니다:
export CFLAGS="-std=gnu99 -g -O0"
-std=gnu99 플래그는 Zabbix 서버, Zabbix 프록시, Zabbix 에이전트를 빌드하는 데 필요합니다.
-g 플래그는 추가 디버깅 정보를 추가하며, -O0은 tcmalloc의 프로파일링을 방해할 수 있는 최적화를 비활성화합니다.
2. Zabbix 서버를 시작하기 전에 다음 환경 변수를 설정합니다. 이 변수들은 tcmalloc에게 메모리 사용량을 추적하고 보고하는 방법을 알려줍니다:
LD_PRELOAD="/usr/lib/aarch64-linux-gnu/libtcmalloc.so" \
HEAPPROFILE=./heap_profile \
HEAP_PROFILE_ALLOCATION_INTERVAL=0 \
HEAP_PROFILE_INUSE_INTERVAL=4294967296 \
HEAPPROFILESIGNAL=5 \
MALLOCSTATS=1 \
./sbin/zabbix_server -f -c /etc/zabbix/zabbix_server.conf
3. 대상 프로세스에 시그널 5를 보내 프로파일 덤프를 발생시킵니다. 1234를 실제 프로세스 ID(PID)로 교체하십시오:
kill -5 1234
4. 생성된 프로파일을 출력합니다:
pprof-symbolize -text ./sbin/zabbix_server ./heap_profile.0001.heap
Using local file ./sbin/zabbix_server.
Using local file ./heap_profile.0001.heap.
Total: 1078.1 MB
1076.8 99.9% 99.9% 1076.8 99.9% zbx_malloc2
1.0 0.1% 100.0% 1.0 0.1% __GI___strdup
0.2 0.0% 100.0% 0.2 0.0% CRYPTO_zalloc@@OPENSSL_3.0.0
0.1 0.0% 100.0% 0.1 0.0% OPENSSL_LH_insert@@OPENSSL_3.0.0
0.0 0.0% 100.0% 0.0 0.0% zbx_realloc2
0.0 0.0% 100.0% 0.1 0.0% PKCS7_decrypt@@OPENSSL_3.0.0
0.0 0.0% 100.0% 0.0 0.0% find_best_tree_node
0.0 0.0% 100.0% 0.0 0.0% CRYPTO_strndup@@OPENSSL_3.0.0
...
0.0 0.0% 100.0% 0.0 0.0% preprocessing_flush_value
0.0 0.0% 100.0% 1074.0 99.6% preprocessor_add_request
이 예제에서 zbx_malloc2가 거의 모든 메모리 할당을 차지하고 있습니다.
다음도 참고하십시오:
- 관련 문제 보고서는 ZBX-25050 및 ZBX-25584를 참고하십시오.
- 컴파일 옵션(
-std=gnu99,-g,-O0등)에 대해서는 GCC Option Summary를 참고하십시오. - tcmalloc 프로파일링을 위한 환경 변수에 대해서는 Gperftools Heap Profiler 문서를 참고하십시오.
multi‐primary 모드의 MySQL 8.0 Group Replication
multi‐primary 모드에서 MySQL 8.0 Group Replication을 사용할 때, 다음과 유사한 오류가 트랜잭션 커밋 중에 발생할 수 있습니다:
1531697:20250128:064734.697 query [txnlev:1] [update alerts set status=1,retries=0,error='' where alertid=154618;
1531697:20250128:064734.713 query [txnlev:1] [commit;]
1531697:20250128:064734.753 [Z3005] query failed: [3101] Plugin instructed the server to rollback the current transaction. [commit;]
이 오류는 외래 키 제약 조건과 관련된 롤백 작업 문제로 인해 발생하는 것으로 보입니다.
다음도 참고하십시오:
- 관련 문제 보고서는 ZBX-26060을 참고하십시오.
- upstream 문제는 MySQL Bug #96758 "Rollbacks with Foreign Keys on single node"를 참고하십시오.