8 알려진 문제점들
원본 보기- 8 알려진 문제
- 7.0.20의 알려진 문제
- 업그레이드
- 템플릿
- EPEL Zabbix 패키지의 우발적 설치
- Red Hat UBI 환경에서 RHEL용 Zabbix 패키지
- RHEL 패키지의 만료된 서명 키
- MariaDB와의 데이터베이스 TLS 연결
- MySQL/MariaDB와의 가능한 교착 상태
- 글로벌 이벤트 상관관계
- PostgreSQL 11 및 이전 버전에서 숫자(부동소수점) 데이터 타입 범위
- NetBSD 8.0 및 최신 버전
- Zabbix agent 2의 정규 표현식 제한사항
- IPMI 검사
- IPMI — 신뢰할 수 없는 호스트로 인한 OpenIPMI 충돌 가능성
- SSH 검사
- ODBC 검사
- 아이템의 잘못된 요청 방법 매개변수
- 웹 모니터링 및 HTTP 에이전트
- 단순 검사
- 루트리스 컨테이너에서 fping 실행 오류
- SNMP 검사
- SNMP 데이터 급증
- SNMP 트랩
- RHEL 7에서 알림 프로세스 충돌
- Zabbix agent 2 업그레이드(6.0.5 이전 버전)
- 프론트엔드 로케일 전환
- 그래프
- 로그 파일 모니터링
- 느린 MySQL 쿼리
- Oracle과의 느린 설정 동기화
- 링크에서 지속적인 필터 설정
- SNMPv3 트랩에서 IPv6 주소 문제
- 실패한 로그인 정보에서 긴 IPv6 IP 주소 잘림
- Windows에서 Zabbix 에이전트 검사
- YAML 내보내기/가져오기
- NGINX와 php-fpm을 사용하는 SUSE에서 설정 마법사
- 인증 헤더 포워딩
- Ubuntu 20에서 Zabbix 웹 서비스용 Chromium
- MySQL 사용자 정의 오류 코드
- PCRE2로 전환 후 잘못된 정규 표현식
- 지도 위젯 오류
- 전처리 — 전역 변수는 안전하지 않음
- 7.0에서 업그레이드 후 TimescaleDB로 인한 서버 충돌
- 7.0.0-7.0.4에서 업그레이드 후 PostgreSQL/TimescaleDB 데이터베이스 복원 오류
- Windows의 프로세서 그룹
- utf8mb4 콜레이션으로 필터링의 제한
- 맵에서 중첩된 호스트 그룹의 잘못된 정보
- 7.0.7에서 손상된 LLD 규칙 재정의
- Zabbix 7.0.14에서 전처리 매니저 성능 문제
- 매크로 함수
- MariaDB 10.5.1-10.5.9에서 UI 요소 접근
- tcmalloc으로 인한 과도한 메모리 사용 프로파일링
- MySQL 8.0 그룹 복제의 다중 기본 모드
8 알려진 문제
참조: 컴파일 문제.
7.0.20의 알려진 문제점
다음과 같은 이유로 이 버전으로의 업그레이드는 권장하지 않습니다:
- Zabbix agent 2 MySQL 플러그인을 사용하는 경우 갑작스러운 CPU 급증 문제 (ZBX-27156 참조)
- 정의되지 않은 인덱스 오류로 인해 Zabbix active agent 항목의 그래프에서 "Undefined array key" 경고가 표시되는 문제 (ZBX-27153 참조)
업그레이드
성공적인 업그레이드를 위한 SQL 모드 설정
MySQL/MariaDB의 sql_mode 설정에는 "STRICT_TRANS_TABLES" 모드가 설정되어 있어야 합니다.
이 모드가 없으면 Zabbix 데이터베이스 업그레이드가 실패합니다 (ZBX-19435 참조).
MariaDB 10.2.1 이하 버전에서의 업그레이드
MariaDB 10.2.1 이하 버전에서 데이터베이스 테이블이 생성된 경우 Zabbix 업그레이드가 실패할 수 있습니다. 이는 해당 버전들에서 기본 행 형식이 compact이기 때문입니다. 이 문제는 행 형식을 dynamic으로 변경하여 해결할 수 있습니다 (ZBX-17690 참조).
템플릿
듀얼 스택(IPv4/IPv6) 환경에서의 템플릿 호환성
듀얼 스택 환경(IPv4와 IPv6를 모두 지원하도록 구성된 시스템)에서는 호스트명 localhost가 일반적으로 IPv4와 IPv6 주소 모두로 해석됩니다.
많은 운영체제와 DNS 리졸버가 IPv4보다 IPv6를 우선시하는 일반적인 특성으로 인해, 모니터링되는 서비스가 IPv4에서만 수신 대기하도록 구성된 경우 Zabbix 템플릿이 올바르게 작동하지 않을 수 있습니다.
IPv6 주소에서 수신 대기하도록 구성되지 않은 서비스는 접근할 수 없게 되어 모니터링 실패로 이어질 수 있습니다. 사용자는 IPv4에 대해서는 접근을 올바르게 구성했지만 IPv6를 우선시하는 기본 동작으로 인해 여전히 연결 문제에 직면할 수 있습니다.
이에 대한 해결 방법은 서비스(Nginx, Apache, PostgreSQL 등)가 IPv4와 IPv6 주소 모두에서 수신 대기하도록 구성하고, Zabbix server/agent가 IPv6를 통해 접근할 수 있도록 허용하는 것입니다.
또한, Zabbix 템플릿과 구성에서 IPv4와 IPv6 모두와의 호환성을 보장하기 위해 127.0.0.1 대신 localhost를 명시적으로 사용하세요.
예를 들어, 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)를 직접 사용할 수도 있습니다.
Accidental installation of EPEL Zabbix packages
If the EPEL repository is installed and enabled, installing Zabbix packages may pull EPEL versions instead of the official Zabbix packages. To resolve this:
1. Remove any Zabbix packages installed from EPEL:
dnf remove zabbix-server-mysql
2. Exclude Zabbix packages from EPEL by adding the following line to /etc/yum.repos.d/epel.repo file:
[epel]
...
excludepkgs=zabbix*
3. Reinstall the official Zabbix server package:
dnf install zabbix-server-mysql
During installation, official Zabbix packages include the word release in their version string (e.g., 7.0.0-release1.el8), distinguishing them from EPEL packages.
Zabbix packages for RHEL on Red Hat UBI environments
When installing Zabbix from Red Hat Enterprise Linux packages on Red Hat Universal Base Image environments, ensure access to required repositories and dependencies.
Zabbix packages depend on libOpenIPMI.so and libOpenIPMIposix.so libraries, which are not provided by any package in the default package manager repositories enabled on UBI systems and will result in installation failures.
The libOpenIPMI.so and libOpenIPMIposix.so libraries are available in the OpenIPMI-libs package, which is provided by the redhat-#-for-<arch>-appstream-rpms repository.
Access to this repository is curated by subscriptions, which, in the case of UBI environments, get propagated by mounting repository configuration and secrets directories of the RHEL host into the container file-system namespace.
For more information, see ZBX-24291.
RHEL 패키지의 만료된 서명 키
Red Hat Enterprise Linux 또는 그 파생 버전에서 Zabbix를 업그레이드할 때, Zabbix 저장소의 패키지에 대한 만료된 서명 키 문제가 발생할 수 있습니다. 서명 키가 만료되면 패키지 서명을 확인하려는 시도가 인증서나 키가 더 이상 유효하지 않다는 오류를 발생시킵니다. 예를 들어:
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
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 저장소의 올바른 링크로 교체하세요).
예를 들어, RHEL 9에서는 다음을 실행하세요:
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm
그런 다음 저장소 정보를 업데이트하세요:
dnf update
자세한 정보는 ZBX-24761을 참조하세요.
MariaDB와의 데이터베이스 TLS 연결
MariaDB를 사용하는 경우 DBTLSConnect 매개변수의 'verify_ca' 옵션으로는 데이터베이스 TLS 연결이 지원되지 않습니다.
Possible deadlocks with MySQL/MariaDB
When running under high load, and with more than one LLD worker involved, it is possible to run into a deadlock caused by an InnoDB error related to the row-locking strategy (see upstream bug). The error has been fixed in MySQL since 8.0.29, but not in MariaDB. For more details, see ZBX-21506.
전역 이벤트 상관관계
첫 번째 이벤트와 두 번째 이벤트 사이의 시간 간격이 매우 짧은 경우(예: 0.5초 이하), 이벤트가 올바르게 상관관계가 설정되지 않을 수 있습니다.
Numeric (float) data type range with PostgreSQL 11 and earlier
PostgreSQL 11 and earlier versions only support floating point value range of approximately -1.34E-154 to 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 라이브러리의 제한사항으로 인해 정규 표현식에서 lookaheads와 lookbehinds를 지원하지 않습니다.
IPMI 검사
IPMI 검사는 Debian 9 (stretch) 이전 버전과 Ubuntu 16.04 (xenial) 이전 버전의 표준 OpenIPMI 라이브러리 패키지에서는 작동하지 않습니다. 이를 해결하려면 ZBX-6139에서 논의된 대로 OpenSSL을 활성화하여 OpenIPMI 라이브러리를 재컴파일하세요.
IPMI — 신뢰할 수 없는 호스트가 OpenIPMI를 충돌시킬 수 있음
Zabbix가 IPMI 데이터 폴링에 사용하는 OpenIPMI 라이브러리에 버그가 있으며, 이는 신뢰할 수 없는 장치로부터의 특별히 조작된 응답에 의해 발생할 수 있습니다.
신뢰할 수 없는 IPMI 장치는 OpenIPMI 라이브러리를 충돌시키는 조작된 데이터를 전송할 수 있으며, 이는 IPMI 폴링을 수행하는 Zabbix 서버 프로세스를 종료시킬 수 있습니다.
SSH checks
- Some Linux distributions like Debian, Ubuntu do not support encrypted private keys (with passphrase) if the libssh2 library is installed from packages. Please see ZBX-4850 for more details.
- When using libssh 0.9.x on some Linux distributions with OpenSSH 8, SSH checks may occasionally report "Cannot read data from SSH server". This is caused by a libssh issue (more detailed report). The error is expected to have been fixed by a stable libssh 0.9.5 release. See also ZBX-17756 for details.
- Using the pipe "|" in the SSH script may lead to a "Cannot read data from SSH server" error. In this case it is recommended to upgrade the libssh library version. See also ZBX-21337 for details.
ODBC checks
-
MySQL unixODBC driver should not be used with Zabbix server or Zabbix proxy compiled against MariaDB connector library and vice versa, if possible it is also better to avoid using the same connector as the driver due to an upstream bug. Suggested setup:
PostgreSQL, SQLite or Oracle connector → MariaDB or MySQL unixODBC driver
MariaDB connector → MariaDB unixODBC driver
MySQL connector → MySQL unixODBC driverSee ZBX-7665 for more information and available workarounds.
-
XML data queried from Microsoft SQL Server may get truncated in various ways on Linux and UNIX systems.
-
It has been observed that using ODBC checks for monitoring Oracle databases using various versions of Oracle Instant Client for Linux causes Zabbix server to crash.
See also: ZBX-18402, ZBX-20803. -
If using FreeTDS UnixODBC driver, you need to prepend a 'SET NOCOUNT ON' statement to an SQL query (for example,
SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). Otherwise, database monitor item in Zabbix will fail to retrieve the information with an error "SQL query returned empty result".
See ZBX-19917 for more information.
아이템의 잘못된 요청 메소드 매개변수
HTTP 검사에서만 사용되는 요청 메소드 매개변수가 4.0 이전 Zabbix 버전에서 업그레이드한 결과로 모든 아이템에 대해 기본값이 아닌 '1'로 잘못 설정될 수 있습니다. 이 상황을 해결하는 방법에 대한 자세한 내용은 ZBX-19308을 참조하세요.
웹 모니터링 및 HTTP 에이전트
일부 Linux 배포판에서 웹 시나리오 또는 HTTP agent에서 "SSL verify peer"가 활성화되어 있을 때 업스트림 버그로 인해 Zabbix 서버에서 메모리 누수가 발생합니다. 자세한 정보와 사용 가능한 해결 방법은 ZBX-10486을 참조하세요.
간단한 검사
v3.10 이전 버전의 fping에는 중복된 에코 응답 패킷을 잘못 처리하는 버그가 있습니다.
이로 인해 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 운영 체제를 사용하는 경우, 5.7.3 버전까지의 Net-SNMP 라이브러리에 있는 use-after-free 버그로 인해 Zabbix 서버 구성 파일에서 SourceIP 매개변수가 설정되어 있으면 Zabbix 서버가 크래시될 수 있습니다. 해결 방법으로 SourceIP 매개변수를 설정하지 마십시오. 동일한 문제가 Linux에도 적용되지만, Zabbix 서버가 작동을 중지하지는 않습니다. OpenBSD의 net-snmp 패키지에 대한 로컬 패치가 적용되었으며 OpenBSD 6.3과 함께 릴리스될 예정입니다.
SNMP 데이터 급증
주전원의 전압 급증과 같은 특정 물리적 요인과 관련될 수 있는 SNMP 데이터의 급증이 관찰되었습니다. 자세한 내용은 ZBX-14318을 참조하세요.
SNMP traps
SNMP trap에 필요한 "net-snmp-perl" 패키지는 RHEL 8.0-8.2에서 제거되었으며, RHEL 8.3에서 다시 추가되었습니다.
따라서 RHEL 8.0-8.2를 사용하고 있다면, RHEL 8.3으로 업그레이드하는 것이 가장 좋은 해결책입니다.
자세한 정보는 ZBX-17192를 참조하시기 바랍니다.
Alerter process crash in RHEL 7
Instances of a Zabbix server alerter process crash have been encountered in RHEL 7. Please see ZBX-10461 for details.
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) 변경으로 인해 X축 라벨 표시 시 불규칙성(날짜 중복, 날짜 누락 등)이 발생합니다.
Sum aggregation
1시간보다 짧은 기간에 대한 그래프에서 sum aggregation을 사용할 때, 데이터가 트렌드에서 나오면 그래프가 잘못된(곱해진) 값을 표시합니다.
텍스트 겹침
일부 프론트엔드 언어(예: 일본어)의 경우, 로컬 폰트로 인해 그래프 범례에서 텍스트가 겹칠 수 있습니다. 이를 방지하려면 PHP GD extension 버전 2.3.0 (또는 그 이후)을 사용하세요.
로그 파일 모니터링
log[]와 logrt[] 아이템은 파일 시스템이 100% 가득 차고 로그 파일이 추가되고 있을 때 처음부터 로그 파일을 반복적으로 다시 읽습니다 (자세한 정보는 ZBX-10884를 참조하세요).
느린 MySQL 쿼리
Zabbix 서버는 아이템에 대한 값이 존재하지 않는 경우 느린 SELECT 쿼리를 생성합니다.
이 문제는 MySQL 5.6/5.7 버전에서 발생하는 것으로 알려져 있으며(자세한 논의는 ZBX-10652 참조), 특정 경우에는 이후 MySQL 버전에서도 발생할 수 있습니다.
이에 대한 해결책은 MySQL에서 index_condition_pushdown 또는 prefer_ordering_index 옵티마이저를 비활성화하는 것입니다.
그러나 이 해결책이 느린 쿼리와 관련된 모든 문제를 해결하지는 못할 수 있다는 점을 유의하시기 바랍니다.
Oracle과의 느린 구성 동기화
많은 수의 아이템과 아이템 전처리 단계를 가진 Oracle DB가 포함된 Zabbix 설치에서 구성 동기화가 느릴 수 있습니다. 이는 Oracle 데이터베이스 엔진이 nclob 타입 필드를 처리하는 속도 때문입니다.
성능을 향상시키려면 데이터베이스 패치 items_nvarchar_prepare.sql를 수동으로 적용하여 필드 타입을 nclob에서 nvarchar2로 변환할 수 있습니다. 이 변환은 아이템 전처리 매개변수와 설명, Script 아이템의 Script 필드, HTTP 에이전트 아이템의 Request body 및 Headers 필드, Database 모니터 아이템의 SQL query 필드와 같은 아이템 매개변수의 최대 필드 크기 제한을 65535바이트에서 4000바이트로 줄인다는 점에 유의하세요. 패치를 적용하기 전에 삭제해야 하는 템플릿 이름을 결정하는 쿼리가 패치에 주석으로 제공됩니다. 또는 MAX_STRING_SIZE가 설정된 경우 패치 쿼리에서 nvarchar2(4000)을 nvarchar2(32767)로 변경하여 32767바이트 필드 크기 제한을 설정할 수 있습니다.
자세한 논의는 ZBX-22363을 참조하세요.
링크에서 지속적인 필터 설정
시간 선택기를 포함하여 필터 설정이 포함된 Zabbix 프론트엔드 페이지 링크를 열면, 필터가 자동으로 사용자의 데이터베이스에 저장되어 해당 페이지의 이전에 저장된 필터 및/또는 시간 선택기 설정을 대체합니다. 이 설정들은 사용자가 수동으로 업데이트하거나 재설정할 때까지 활성 상태로 유지됩니다.
SNMPv3 트랩에서의 IPv6 주소 문제
net-snmp 버그로 인해 SNMP 트랩에서 SNMPv3를 사용할 때 IPv6 주소가 올바르게 표시되지 않을 수 있습니다. 자세한 내용과 가능한 해결 방법은 ZBX-14541를 참조하세요.
로그인 실패 정보에서 긴 IPv6 IP 주소 잘림
로그인 실패 시도 메시지는 저장된 IP 주소의 처음 39자만 표시합니다. 이는 데이터베이스 필드의 문자 제한 때문입니다. 즉, 39자보다 긴 IPv6 IP 주소는 불완전하게 표시됩니다.
Windows에서의 Zabbix agent 점검
Zabbix agent 설정 파일(zabbix_agentd.conf)의 Server 매개변수에 존재하지 않는 DNS 항목이 있으면 Windows에서 Zabbix agent 응답 시간이 증가할 수 있습니다.
이는 Windows DNS 캐싱 데몬이 IPv4 주소에 대한 부정적인 응답을 캐시하지 않기 때문에 발생합니다.
그러나 IPv6 주소의 경우 부정적인 응답이 캐시되므로, 이에 대한 가능한 해결책은 호스트에서 IPv4를 비활성화하는 것입니다.
YAML 내보내기/가져오기
YAML 내보내기/가져오기에는 몇 가지 알려진 문제가 있습니다:
- 오류 메시지를 번역할 수 없습니다;
- .yaml 파일 확장자를 가진 유효한 JSON이 때때로 가져와지지 않습니다;
- 따옴표가 없는 사람이 읽을 수 있는 날짜는 자동으로 Unix 타임스탬프로 변환됩니다.
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나 Okta를 사용한 SAML과 같은 SSO(Single Sign-On) 서비스를 사용할 때 인증 문제를 일으킬 수 있습니다.
이를 해결하려면 웹 서버의 구성을 업데이트하세요.
Apache를 리버스 프록시로 사용하는 경우(비 CGI 설정), /etc/httpd/conf/httpd.conf(RHEL 기반 시스템) 또는 /etc/apache2/apache2.conf(Debian/Ubuntu)에 다음 지시어를 추가하세요:
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
Apache가 요청을 처리하기 위해 스크립트를 직접 실행하는 경우(예: mod_cgi 사용), 대신 다음 지시어를 추가하세요:
CGIPassAuth On
반면 NGINX는 Authorization 헤더를 자동으로 처리합니다.
하지만 NGINX가 리버스 프록시로 작동하는 경우, /etc/nginx/nginx.conf(Zabbix 프론트엔드 위치)에 다음 지시어를 추가하여 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 웹 서비스를 위한 Chromium
대부분의 경우 Zabbix 웹 서비스는 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를 사용할 때, 일반적인 오류 메시지인 [9002] Some errors occurred가 Zabbix 로그에 나타날 수 있습니다. 이 메시지는 데이터베이스에서 Zabbix 서버나 프록시로 전송됩니다. 오류의 원인을 확인하려면 Azure 로그를 참조하시기 바랍니다.
PCRE2로 전환 후 유효하지 않은 정규 표현식
Zabbix 6.0에서 PCRE2 지원이 추가되었습니다. PCRE가 여전히 지원되지만, RHEL 7 이상, SLES (모든 버전), Debian 9 이상, Ubuntu 16.04 이상용 Zabbix 설치 패키지가 PCRE2를 사용하도록 업데이트되었습니다. 많은 이점을 제공하지만, PCRE2로 전환하면 기존의 특정 PCRE 정규식 패턴이 유효하지 않게 되거나 다르게 동작할 수 있습니다. 특히, 이는 \^[\w-\.] 패턴에 영향을 줍니다. 의미를 변경하지 않고 이 정규식을 다시 유효하게 만들려면, 표현식을 \^[-\w\.]로 변경하세요. 이는 PCRE2가 대시 기호를 구분자로 처리하여 문자 클래스 내부에서 범위를 생성하기 때문에 발생합니다.
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 });
7.0 업그레이드 후 TimescaleDB로 인한 서버 크래시
TimescaleDB와 함께 Zabbix 7.0.0에서 Zabbix 7.0.1(또는 그 이후 버전)로 업그레이드하면 서버 크래시가 발생합니다. 이 문제는 Zabbix 7.0에서 auditlog 테이블의 압축 작업 문제에 대한 해결책이 auditlog 테이블의 압축 정책을 비가역적으로 변경했기 때문입니다.
문제를 해결하려면 auditlog 테이블을 수동으로 재구축해야 합니다. 버그가 있는 auditlog 테이블은 다음 쿼리로 감지할 수 있습니다:
SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.
compress_after 속성을 포함하는 JSON 객체(예: {"hypertable_id": 14, "compress_after": 612000})를 반환하면 테이블을 재구축해야 합니다.
Zabbix 서버가 최소 7.0.1rc2 버전(또는 그 이후 버전)인지 확인하세요. 그렇지 않으면 다시 잘못된 압축 정책을 설정할 것입니다.
또한 스크립트를 실행하기 전에 Zabbix 서버를 중지하고 auditlog가 zabbix 사용자가 소유하고 있는지 확인하세요.
auditlog 테이블을 재구축하는 가장 간단한 방법은 다음과 같습니다:
CREATE TABLE auditlog_tmp (
LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
);
SELECT create_hypertable('auditlog_tmp', 'auditid', chunk_time_interval => 604800,
time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);
WITH moved_rows AS (
DELETE FROM auditlog
RETURNING *
)
INSERT INTO auditlog_tmp
SELECT * FROM moved_rows;
DROP TABLE auditlog;
ALTER TABLE auditlog_tmp RENAME TO auditlog;
더 최적화된 데이터 마이그레이션 방법은 TimescaleDB 문서를 참조하세요.
파티셔닝에 필요한 타임스탬프가 사용자 정의 함수를 사용하여 auditid 필드에서 추출되기 때문에 timescaledb-extras의 데이터 마이그레이션용 헬퍼 프로시저는 작동하지 않습니다.
7.0.0-7.0.4에서 업그레이드 후 PostgreSQL/TimescaleDB 데이터베이스 복원 오류
Zabbix 7.0.0-7.0.4에서 생성된 PostgreSQL 또는 TimescaleDB 백업을 pg_restore를 사용하여 복원할 때 base36_decode 함수가 없다는 오류가 발생하여 복원이 실패합니다:
ERROR: function base36_decode(text) does not exist
LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
이 오류는 pg_dump로 생성된 백업을 복원할 때 발생합니다.
이 문제를 해결하려면 백업을 생성하기 **전에** Zabbix 데이터베이스의 cuid_timestamp 함수를 교체해주세요 (스크립트 실행 전에 PostgreSQL/TimescaleDB를 중지하는 것을 권장합니다):
CREATE OR REPLACE FUNCTION cuid_timestamp(cuid varchar(25)) RETURNS integer AS $$
DECLARE
base36 varchar;
a char[];
ret bigint;
i int;
val int;
chars varchar;
BEGIN
base36 := substring(cuid FROM 2 FOR 8);
chars := '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
FOR i IN REVERSE char_length(base36)..1 LOOP
a := a || substring(upper(base36) FROM i FOR 1)::char;
END LOOP;
i := 0;
ret := 0;
WHILE i < (array_length(a, 1)) LOOP
val := position(a[i + 1] IN chars) - 1;
ret := ret + (val * (36 ^ i));
i := i + 1;
END LOOP;
RETURN CAST(ret/1000 AS integer);
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE;
DROP FUNCTION IF EXISTS base36_decode(character varying);
ZBX-24955 (오류에 대한 추가 세부 정보) 및 TimescaleDB 문서 (추가 백업 및 복원 옵션)도 참조하세요.
Windows의 프로세서 그룹
Microsoft 문서에 따르면 64개 미만의 논리 프로세서를 가진 시스템은 항상 단일 프로세서 그룹인 Group 0을 가진다고 명시되어 있습니다. 그러나 Zabbix 사용자들은 64개 이하의 논리 프로세서를 가진 시스템에서 두 개의 프로세서 그룹이 존재하는 드문 버그 ZBX-20260를 보고했습니다. 이로 인해 두 개의 프로세서 그룹 중 하나의 그룹에서만 "\Processor(n)" 성능 카운터를 사용할 수 있었습니다. 이 버그의 실제 근본 원인은 알려지지 않았습니다. 그러나 유사한 사례가 stackoverflow.com에서 설명되었으며, 그 근본 원인은 BIOS와 Windows 간의 상호 작용에 있었습니다.
utf8mb4 collation 필터링의 제한사항
필터 (예: 데이터 수집 > 유지보수)는 특정 Unicode 문자(예: ȼ, ɇ)가 포함된 엔티티에 적용될 때 올바르게 작동하지 않을 수 있습니다. 이 문제는 MySQL 또는 MariaDB 데이터베이스의 기본 utf8mb4_bin collation이 Unicode 문자의 정렬 및 비교를 처리하는 방식 때문에 발생합니다.
이 제한사항을 해결하기 위해 사용자는 데이터베이스 컬럼의 collation을 utf8mb4_0900_bin, utf8mb4_0900_ai_ci 또는 utf8mb4_unicode_520_ci와 같은 대안으로 변경할 수 있습니다. 하지만 collation을 변경하면 빈 공간 처리와 다른 문자의 정렬 및 필터링에서 예상치 못한 동작이 발생할 수 있다는 점에 유의하세요.
collation 변경에 대한 자세한 정보는 MySQL 문서 또는 MariaDB 문서를 참조하세요. collation 차이점에 대한 자세한 내용은 MySQL 문서의 Unicode Character Sets를 참조하세요.
맵에서 중첩된 호스트 그룹의 잘못된 정보
중첩된 호스트 그룹의 정보가 맵에서 잘못 표시됩니다. 예를 들어:
- 호스트 그룹 레이블이 중첩된 호스트 그룹의 모든 호스트를 포함하지 않은 문제 요약을 표시합니다;
- "Host group elements" 뷰가 중첩된 호스트 그룹의 각 호스트에 대해 별도의 맵 요소를 표시하지 않습니다;
- 맵 레이블이 중첩된 호스트 그룹의 문제들을 포함하지 않은 모든 문제의 요약을 표시합니다.
7.0.7에서 손상된 LLD 규칙 재정의
버전 7.0.7에서 Zabbix 서버가 저수준 검색 규칙 재정의를 처리할 때 충돌이 발생합니다. 해결 방법으로 재정의가 포함된 LLD 규칙을 비활성화하세요. 이 문제는 Zabbix 7.0.8rc2에서 수정되었습니다.
Zabbix 7.0.14의 전처리 관리자 성능 문제
버전 7.0.14에서 Zabbix 전처리 관리자는 단일 아이템에 대해 여러 값이 한 번에 수신되고(로그 모니터링과 같은 경우) 둘 이상의 전처리 워커가 구성된 경우 높은 CPU 사용률을 유발할 수 있습니다.
임시 해결책으로 StartPreprocessors 서버/프록시 구성 매개변수를 1로 설정하십시오.
이 문제는 Zabbix 7.0.15에서 수정되었습니다.
매크로 함수
매크로 함수는 스크립트 아이템 매개변수와 브라우저 아이템 스크립트 매개변수에서 작동하지 않습니다. Zabbix 7.0.7에서 수정되었습니다.
MariaDB 10.5.1-10.5.9에서 UI 요소 접근
Super Admin이 아닌 역할로 Zabbix 웹 프론트엔드에 접근하면 "시스템 오류가 발생했습니다. Zabbix 관리자에게 문의하세요."라는 메시지가 나타날 수 있습니다. 이 문제는 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 문서를 참조하세요.
MySQL 8.0 Group Replication multi‐primary 모드
MySQL 8.0 Group Replication을 multi‐primary 모드에서 사용할 때, 트랜잭션 커밋 중에 다음과 유사한 오류가 발생할 수 있습니다:
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을 참조하세요.
- 업스트림 이슈는 MySQL Bug #96758 "Rollbacks with Foreign Keys on single node"를 참조하세요.