8 알려진 문제

참고 항목: 컴파일 문제.

7.0.20의 알려진 문제

다음 문제로 인해 이 버전으로 업그레이드하는 것은 권장하지 않습니다:

• Zabbix agent 2 MySQL 플러그인을 사용하는 경우 갑작스러운 CPU 사용량 급증 문제(ZBX-27156 참조)
• 정의되지 않은 인덱스 오류로 인해 Zabbix 활성 에이전트 항목의 그래프에 "정의되지 않은 배열 키" 경고가 표시되는 문제(ZBX-27153 참조)

업그레이드

성공적인 업그레이드를 위한 SQL 모드 설정

MySQL/MariaDB의 sql_mode 설정에는 "STRICT_TRANS_TABLES" 모드가 설정되어 있어야 합니다. 이 모드가 없으면 Zabbix 데이터베이스 업그레이드가 실패합니다(ZBX-19435도 참조).

MariaDB 10.2.1 이하 버전에서 업그레이드

MariaDB 10.2.1 이하 버전에서는 기본 행 형식이 compact이므로, 해당 버전으로 데이터베이스 테이블을 생성한 경우 Zabbix 업그레이드가 실패할 수 있습니다. 행 형식을 dynamic으로 변경하면 이 문제를 해결할 수 있습니다(ZBX-17690도 참조).

MySQL 데이터베이스 문자 집합 및 데이터 정렬

utf8mb3 문자 집합과 utf8mb3_bin 데이터 정렬로 생성된 MySQL 데이터베이스를 사용하는 Zabbix 설치 환경에서 문제가 발생할 수 있습니다. 예를 들어, 알려진 MySQL 문제로 인해 데이터베이스 스키마 업그레이드 또는 기타 DDL 작업 중에 Row size too large (> 8126) 오류가 발생할 수 있습니다.
Zabbix 데이터베이스 문자 집합 및 데이터 정렬 복구에 설명된 대로, utf8mb3 문자 집합과 utf8mb3_bin 데이터 정렬을 사용하는 데이터베이스를 utf8mb4 문자 집합과 utf8mb4_bin 데이터 정렬로 변환할 것을 강력히 권장합니다.

libcurl 8.21.0의 메모리 및 파일 설명자 누수

libcurl 8.21.0의 알려진 문제로 인해 TLS 보안 연결을 처리할 때 libcurl을 사용하는 Zabbix 기능에서 메모리와 파일 설명자가 누수될 수 있습니다.
수정 사항이 포함된 릴리스가 제공될 때까지 libcurl을 8.20.0 버전으로 다운그레이드하면 이 문제를 우회할 수 있습니다.

템플릿

듀얼 스택(IPv4/IPv6) 환경의 템플릿 호환성

듀얼 스택 환경(IPv4와 IPv6를 모두 지원하도록 구성된 시스템)에서 호스트 이름 localhost는 일반적으로 IPv4와 IPv6 주소 모두로 확인됩니다. 많은 운영 체제와 DNS 확인자가 IPv4보다 IPv6를 우선하는 일반적인 동작으로 인해, 모니터링 대상 서비스가 IPv4에서만 수신하도록 구성된 경우 Zabbix 템플릿이 올바르게 작동하지 않을 수 있습니다.

IPv6 주소에서 수신하도록 구성되지 않은 서비스는 접근할 수 없게 되어 모니터링에 실패할 수 있습니다. 사용자가 IPv4 접근을 올바르게 구성했더라도 IPv6 우선 처리라는 기본 동작으로 인해 연결 문제가 계속 발생할 수 있습니다.

이 문제를 우회하려면 서비스(Nginx, Apache, PostgreSQL 등)가 IPv4 및 IPv6 주소 모두에서 수신하도록 구성하고, Zabbix server/agent가 IPv6를 통해 접근할 수 있도록 허용해야 합니다. 또한 IPv4와 IPv6 모두와의 호환성을 보장하려면 Zabbix 템플릿 및 구성에서 localhost를 명시적으로 사용하고 127.0.0.1은 사용하지 마십시오.

예를 들어, PostgreSQL by Zabbix agent 2 템플릿으로 PostgreSQL을 모니터링할 때 pg_hba.conf 파일을 편집하여 zbx_monitor 사용자의 연결을 허용해야 할 수 있습니다. 듀얼 스택 환경에서 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

필요한 경우 연결 문자열의 127.0.0.1 IPv4 주소를 사용하도록 PostgreSQL by Zabbix agent 2 템플릿 매크로를 직접 구성할 수도 있습니다.

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 server 패키지를 다시 설치합니다:

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 저장소에서 제공됩니다. 이 저장소에 대한 접근 권한은 구독으로 관리되며, UBI 환경에서는 RHEL 호스트의 저장소 구성 및 비밀 디렉터리를 컨테이너 파일 시스템 네임스페이스에 마운트하여 전달됩니다.

자세한 내용은 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 연결은 지원되지 않습니다.

MySQL/MariaDB에서 발생할 수 있는 교착 상태

고부하 상태에서 둘 이상의 LLD 워커가 관여하는 경우 행 잠금 전략과 관련된 InnoDB 오류로 교착 상태가 발생할 수 있습니다(업스트림 버그 참조). 이 오류는 MySQL 8.0.29부터 수정되었지만 MariaDB에서는 수정되지 않았습니다. 자세한 내용은 ZBX-21506을 참조하십시오.

전역 이벤트 상관관계

첫 번째 이벤트와 두 번째 이벤트 사이의 시간 간격이 매우 짧은 경우, 즉 0.5초 이하인 경우 이벤트의 상관관계가 올바르게 처리되지 않을 수 있습니다.

PostgreSQL 11 이하 버전의 Numeric(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 라이브러리의 제한으로 인해 정규식의 전방 탐색과 후방 탐색을 지원하지 않습니다.

IPMI 검사

Debian 9(stretch) 이전 및 Ubuntu 16.04(xenial) 이전 버전에서는 표준 OpenIPMI 라이브러리 패키지로 IPMI 검사가 작동하지 않습니다. 이 문제를 해결하려면 ZBX-6139에서 설명한 대로 OpenSSL을 활성화하여 OpenIPMI 라이브러리를 다시 컴파일하십시오.

IPMI — 신뢰할 수 없는 호스트로 인해 OpenIPMI가 충돌할 수 있음

Zabbix가 IPMI 데이터를 폴링하는 데 사용하는 OpenIPMI 라이브러리에는 신뢰할 수 없는 장치의 특수하게 조작된 응답으로 유발될 수 있는 버그가 있습니다.
신뢰할 수 없는 IPMI 장치가 OpenIPMI 라이브러리를 충돌시키는 조작된 데이터를 보낼 수 있으며, 이로 인해 IPMI 폴링을 수행하는 Zabbix server 프로세스가 종료될 수 있습니다.

SSH 검사

• Debian, Ubuntu와 같은 일부 Linux 배포판에서는 libssh2 라이브러리를 패키지로 설치한 경우 암호화된 개인 키(암호 문구 포함)를 지원하지 않습니다. 자세한 내용은 ZBX-4850을 참조하십시오.
• OpenSSH 8이 설치된 일부 Linux 배포판에서 libssh 0.9.x를 사용하면 SSH 검사에서 때때로 "SSH 서버에서 데이터를 읽을 수 없음"이 보고될 수 있습니다. 이는 libssh 문제(상세 보고서)로 인해 발생합니다. 이 오류는 안정 버전인 libssh 0.9.5 릴리스에서 수정된 것으로 예상됩니다. 자세한 내용은 ZBX-17756도 참조하십시오.
• SSH 스크립트에서 파이프 "|"를 사용하면 "SSH 서버에서 데이터를 읽을 수 없음" 오류가 발생할 수 있습니다. 이 경우 libssh 라이브러리 버전을 업그레이드하는 것이 좋습니다. 자세한 내용은 ZBX-21337도 참조하십시오.

ODBC 검사

• 가능하면 MariaDB 커넥터 라이브러리로 컴파일된 Zabbix server 또는 Zabbix proxy에 MySQL unixODBC 드라이버를 사용하거나 그 반대로 사용하지 않아야 하며, 업스트림 버그로 인해 동일한 커넥터를 드라이버로 사용하는 것도 피하는 것이 좋습니다. 권장 구성:

  PostgreSQL, SQLite 또는 Oracle 커넥터 → MariaDB 또는 MySQL unixODBC 드라이버
  MariaDB 커넥터 → MariaDB unixODBC 드라이버
  MySQL 커넥터 → MySQL unixODBC 드라이버

  자세한 내용과 사용 가능한 우회 방법은 ZBX-7665를 참조하십시오.

• Microsoft SQL Server에서 조회한 XML 데이터가 Linux 및 UNIX 시스템에서 다양한 방식으로 잘릴 수 있습니다.

• 여러 버전의 Oracle Instant Client for Linux를 사용하여 Oracle 데이터베이스를 모니터링하는 ODBC 검사가 Zabbix server를 충돌시키는 사례가 관찰되었습니다.
  참고 항목: ZBX-18402, ZBX-20803.

• FreeTDS UnixODBC 드라이버를 사용하는 경우 SQL 쿼리 앞에 'SET NOCOUNT ON' 문을 추가해야 합니다(예: SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). 그렇지 않으면 Zabbix의 데이터베이스 모니터 항목이 "SQL 쿼리가 빈 결과를 반환함" 오류와 함께 정보를 가져오지 못합니다.
  자세한 내용은 ZBX-19917을 참조하십시오.

항목의 잘못된 요청 메서드 매개변수

HTTP 검사에서만 사용하는 요청 메서드 매개변수가 4.0 이전 Zabbix 버전에서 업그레이드한 결과 모든 항목에서 기본값이 아닌 '1'로 잘못 설정될 수 있습니다. 이 상황을 해결하는 방법에 대한 자세한 내용은 ZBX-19308을 참조하십시오.

웹 모니터링 및 HTTP agent

웹 시나리오 또는 HTTP agent에서 "SSL 피어 확인"을 활성화하면 업스트림 버그로 인해 일부 Linux 배포판에서 Zabbix server의 메모리가 누수됩니다. 자세한 내용과 사용 가능한 우회 방법은 ZBX-10486을 참조하십시오.

단순 검사

fping v3.10 이전 버전에는 중복 에코 응답 패킷을 잘못 처리하는 버그가 있습니다. 이로 인해 icmpping, icmppingloss, icmppingsec 항목에 예기치 않은 결과가 발생할 수 있습니다. 최신 버전의 fping을 사용하는 것이 좋습니다. 자세한 내용은 ZBX-11726을 참조하십시오.

루트리스 컨테이너에서 fping 실행 오류

컨테이너가 루트리스 모드 또는 특정 제한 환경에서 실행되는 경우 ICMP 검사 수행 시 fping: Operation not permitted 또는 모든 리소스에 대한 모든 패킷 손실과 같은 fping 실행 관련 오류가 발생할 수 있습니다.

이 문제를 해결하려면 "docker run" 또는 "podman run" 명령에 --cap-add=net_raw를 추가하십시오.

또한 루트가 아닌 환경에서 fping을 실행하려면 다음과 같이 sysctl을 수정해야 할 수 있습니다:

sudo sysctl -w "net.ipv4.ping_group_range=0 1995"

여기서 "1995"는 zabbix GID입니다. 자세한 내용은 ZBX-22833을 참조하십시오.

SNMP 검사

OpenBSD 운영 체제를 사용하는 경우 Net-SNMP 5.7.3 이하 버전 라이브러리의 해제 후 사용 버그로 인해 Zabbix server 구성 파일에 SourceIP 매개변수가 설정되어 있으면 Zabbix server가 충돌할 수 있습니다. 우회 방법으로 SourceIP 매개변수를 설정하지 마십시오. 동일한 문제는 Linux에도 적용되지만 Zabbix server의 작동이 중지되지는 않습니다. 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의 알림 프로세스 충돌

RHEL 7에서 Zabbix server 알림 프로세스의 충돌 사례가 발생했습니다. 자세한 내용은 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 스레드의 데이터 처리 방식에 영향을 줄 수 있습니다.

자세한 내용은 관련 문제 보고서를 참조하십시오:

• ZBX-10911 (프런트엔드 로케일 전환 문제)
• ZBX-16297 (BC Math 함수의 bcdiv 함수를 사용하는 그래프의 숫자 처리 문제)

그래프

그래프(클래식) 문제

클래식 그래프에서 문제가 발생하면 GD 라이브러리(libgd)를 2.3.3-13 이상으로, PHP를 8.0.19, 8.1.33, 8.2.29, 8.3.25, 8.4.12 이상으로 업데이트하는 것이 좋습니다.

일광 절약 시간

일광 절약 시간(DST)이 변경되면 X축 레이블을 표시할 때 날짜 중복, 날짜 누락 등의 불규칙성이 발생합니다.

합계 집계

1시간 미만의 기간에 대해 그래프에서 합계 집계를 사용할 때 추세에서 데이터가 제공되면 그래프에 잘못된(곱해진) 값이 표시됩니다.

텍스트 겹침

일부 프런트엔드 언어(예: 일본어)에서는 로컬 글꼴로 인해 그래프 범례의 텍스트가 겹칠 수 있습니다. 이를 방지하려면 PHP GD 확장 기능 2.3.0 이상 버전을 사용하십시오.

로그 파일 모니터링

파일 시스템이 100% 가득 찬 상태에서 로그 파일에 내용이 추가되면 log[] 및 logrt[] 항목이 로그 파일을 처음부터 반복해서 다시 읽습니다(자세한 내용은 ZBX-10884 참조).

느린 MySQL 쿼리

항목에 존재하지 않는 값이 있는 경우 Zabbix server가 느린 SELECT 쿼리를 생성합니다. 이 문제는 MySQL 5.6/5.7 버전에서 발생하는 것으로 알려져 있으며(자세한 논의는 ZBX-10652 참조), 특정한 경우 이후 MySQL 버전에서도 발생할 수 있습니다. 이 문제를 우회하려면 MySQL에서 index_condition_pushdown 또는 prefer_ordering_index 최적화 프로그램을 비활성화하십시오. 단, 이 우회 방법으로 느린 쿼리와 관련된 모든 문제가 해결되지는 않을 수 있습니다.

Oracle에서 느린 구성 동기화

항목과 항목 전처리 단계가 많은 Oracle DB 기반 Zabbix 설치 환경에서는 구성 동기화가 느릴 수 있습니다. 이는 Oracle 데이터베이스 엔진이 nclob 형식 필드를 처리하는 속도 때문에 발생합니다.

성능을 개선하려면 필드 형식을 nclob에서 nvarchar2로 변환하기 위해 데이터베이스 패치 items_nvarchar_prepare.sql을 수동으로 적용할 수 있습니다. 이 변환은 항목 전처리 매개변수 및 설명, 스크립트 항목의 스크립트 필드, HTTP agent 항목의 요청 본문 및 헤더 필드, 데이터베이스 모니터 항목의 SQL 쿼리 필드와 같은 항목 매개변수의 최대 필드 크기 제한을 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에서는 프런트엔드 설정 마법사가 구성 파일을 저장할 수 없습니다. 이는 Zabbix가 /etc에 쓰지 못하도록 하는 /usr/lib/systemd/system/php-fpm.service 유닛의 설정 때문에 발생합니다(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 및 Authorization 헤더
• SetEnvIfNoCase 및 CGIPassAuth 지시문
• NGINX 리버스 프록시

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를 사용하면 일반 오류 메시지 [9002] 일부 오류가 발생했습니다가 Zabbix 로그에 나타날 수 있습니다. 이 메시지는 데이터베이스가 Zabbix server 또는 proxy에 보낸 것입니다. 오류의 원인을 확인하려면 Azure 로그를 참조하십시오.

PCRE2 전환 후 잘못된 정규식

Zabbix 6.0에 PCRE2 지원이 추가되었습니다. PCRE도 계속 지원되지만 RHEL 7 이상, SLES(모든 버전), Debian 9 이상, Ubuntu 16.04 이상용 Zabbix 설치 패키지는 PCRE2를 사용하도록 업데이트되었습니다. PCRE2로 전환하면 많은 이점이 있지만 기존의 일부 PCRE 정규식 패턴이 유효하지 않게 되거나 다르게 동작할 수 있습니다. 특히 ^[\w-\.] 패턴이 이에 해당합니다. 의미에 영향을 주지 않고 이 정규식을 다시 유효하게 만들려면 식을 ^[-\w\.]로 변경하십시오. 이는 PCRE2가 대시 기호를 구분 기호로 취급하여 문자 클래스 안에 범위를 만들기 때문에 발생합니다.

문자 클래스에 괄호가 있는 정규식

문자 클래스 안에 괄호가 포함된 정규식(예: [(])은 유효하지 않은 것으로 거부됩니다.

이 문제는 전처리 단계, 템플릿 가져오기, 스크립트, 정규식 테스트, 아이콘 매핑, 값 매핑을 비롯해 정규식을 입력하거나 가져오는 모든 위치에서 발생할 수 있습니다.

이 문제를 우회하려면 이스케이프된 괄호를 사용하십시오. 예: [\(].

이 문제는 Zabbix 7.0.22에서 수정되었습니다. 자세한 내용은 ZBX-26303을 참조하십시오.

Geomap 위젯 오류

NGINX를 사용하는 이전 Zabbix 버전에서 업그레이드하면서 새 NGINX 구성 파일로 전환하지 않은 경우 Geomap 위젯의 지도가 올바르게 로드되지 않을 수 있습니다.

문제를 해결하려면 이전 구성 파일을 버리고 현재 버전 패키지의 구성 파일을 사용한 다음 다운로드 지침의 e. Zabbix 프런트엔드용 PHP 구성 섹션에 설명된 대로 다시 구성할 수 있습니다.

또는 기존 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 사용 시 server 충돌

TimescaleDB를 사용하는 Zabbix 7.0.0에서 Zabbix 7.0.1 이상으로 업그레이드하면 server가 충돌합니다. 이 문제는 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})가 반환되면 테이블을 다시 빌드해야 합니다.

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 문서도 참조하십시오.

7.0.0-7.0.4에서 업그레이드한 후 PostgreSQL/TimescaleDB 데이터베이스 복원 오류

pg_restore를 사용하여 Zabbix 7.0.0-7.0.4에서 생성된 PostgreSQL 또는 TimescaleDB 백업을 복원하면 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 데이터 정렬의 필터링 제한

특정 Unicode 문자(예: ȼ, ɇ)가 포함된 엔터티에 필터(예: 데이터 수집 > 유지보수)를 적용하면 올바르게 작동하지 않을 수 있습니다. 이 문제는 MySQL 또는 MariaDB 데이터베이스의 기본 utf8mb4_bin 데이터 정렬이 Unicode 문자의 정렬 및 비교를 처리하는 방식 때문에 발생합니다.

이 제한을 해결하기 위해 사용자는 데이터베이스 열의 데이터 정렬을 utf8mb4_0900_bin, utf8mb4_0900_ai_ci 또는 utf8mb4_unicode_520_ci와 같은 대안으로 변경할 수 있습니다. 단, 데이터 정렬을 변경하면 공백 처리뿐 아니라 다른 문자의 정렬 및 필터링에서도 예기치 않은 동작이 발생할 수 있습니다.

데이터 정렬 변경에 대한 자세한 내용은 MySQL 문서 또는 MariaDB 문서를 참조하십시오. 데이터 정렬의 차이에 대한 자세한 내용은 MySQL 문서의 Unicode 문자 집합을 참조하십시오.

맵에 중첩 호스트 그룹의 잘못된 정보 표시

중첩 호스트 그룹의 정보가 맵에 잘못 표시됩니다. 예:

• 호스트 그룹 레이블에 중첩 호스트 그룹의 모든 호스트가 포함되지 않은 문제 요약이 표시됩니다.
• "호스트 그룹 요소" 보기에 중첩 호스트 그룹의 각 호스트에 대한 별도의 맵 요소가 표시되지 않습니다.
• 맵 레이블에 중첩 호스트 그룹의 문제를 포함하지 않은 전체 문제 요약이 표시됩니다.

7.0.7의 손상된 LLD 규칙 재정의

7.0.7 버전에서 Zabbix server는 로우레벨 디스커버리 규칙 재정의를 처리할 때 충돌합니다. 우회 방법으로 재정의가 포함된 LLD 규칙을 비활성화하십시오. 이 문제는 Zabbix 7.0.8rc2에서 수정되었습니다.

Zabbix 7.0.14의 전처리 관리자 성능 문제

7.0.14 버전에서 단일 항목에 대해 여러 값이 한 번에 수신되고(예: 로그 모니터링 중) 둘 이상의 전처리 워커가 구성되어 있으면 Zabbix 전처리 관리자가 높은 CPU 사용률을 유발할 수 있습니다. 임시 우회 방법으로 StartPreprocessors server/proxy 구성 매개변수를 1로 설정하십시오. 이 문제는 Zabbix 7.0.15에서 수정되었습니다.

매크로 함수

매크로 함수는 스크립트 항목 매개변수와 브라우저 항목 스크립트 매개변수에서 작동하지 않습니다. Zabbix 7.0.7에서 수정되었습니다.

MariaDB 10.5.1-10.5.9에서 UI 요소 접근

최고 관리자 이외의 역할로 Zabbix 웹 프런트엔드에 접근하면 "시스템 오류가 발생했습니다. Zabbix 관리자에게 문의하십시오." 메시지가 표시될 수 있습니다. 이 문제는 MariaDB 버전 10.5.1부터 10.5.9를 사용하는 설치 환경에 영향을 줍니다.

이 문제를 방지하려면 MariaDB를 10.5.9보다 높은 버전으로 업데이트하십시오. 자세한 내용은 ZBX-25746을 참조하십시오.

tcmalloc을 사용한 과도한 메모리 사용량 프로파일링

Zabbix 설치 환경에서 메모리를 너무 많이 사용하는 것으로 의심되는 경우 tcmalloc의 메모리 프로파일링 기능을 사용하여 Zabbix server/proxy의 메모리 사용량을 조사할 수 있습니다.

1. Zabbix를 소스에서 설치할 때 추가 플래그를 구성합니다:

export CFLAGS="-std=gnu99 -g -O0"

-std=gnu99 플래그는 Zabbix server, Zabbix proxy 또는 Zabbix agent 빌드에 필요합니다. -g 플래그는 추가 디버깅 정보를 포함하고, -O0는 tcmalloc 프로파일링을 방해할 수 있는 최적화를 비활성화합니다.

2. Zabbix server를 시작하기 전에 다음 환경 변수를 설정합니다. 이 변수는 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를 참조하십시오.
• GCC 옵션 요약에서 컴파일 옵션(-std=gnu99, -g, -O0 등)을 참조하십시오.
• tcmalloc 프로파일링 환경 변수는 Gperftools Heap Profiler 문서를 참조하십시오.

다중 프라이머리 모드의 MySQL 8.0 Group Replication

다중 프라이머리 모드에서 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을 참조하십시오.
• 업스트림 문제는 MySQL Bug #96758 "단일 노드에서 외래 키를 사용하는 롤백"를 참조하십시오.