Table of Contents

8 已知问题

8 已知问题

参见：Compilation issues。

升级

成功升级所需的 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 解析器通常优先使用 IPv6 而非 IPv4，如果被监控的服务仅配置为监听 IPv4，则 Zabbix 模板可能会无法正常工作。

未配置为监听 IPv6 地址的服务可能会变得无法访问，从而导致监控失败。用户可能已为 IPv4 正确配置了访问权限，但由于默认优先使用 IPv6，仍可能会遇到连接问题。

解决此问题的方法是确保服务（如 nginx、Apache、PostgreSQL 等）配置为同时监听 IPv4 和 IPv6 地址，并且 Zabbix server/agent 被允许通过 IPv6 访问。此外，在 Zabbix 模板和配置中，应显式使用 localhost 而不是 127.0.0.1，以确保与 IPv4 和 IPv6 的兼容性。

例如，使用 PostgreSQL by Zabbix agent 2 模板监控 PostgreSQL 时，可能需要编辑 pg_hba.conf file，以允许 zbx_monitor 用户进行连接。如果双栈环境优先使用 IPv6（系统将 localhost 解析为 ::1），并且你配置了 localhost，但仅添加了 IPv4 条目（127.0.0.1/32），则由于没有匹配的 IPv6 条目，连接将失败。

以下 pg_hba.conf file 示例确保 zbx_monitor 用户可以从本地机器使用 IPv4 和 IPv6 地址以不同的认证方式连接到任意数据库：

# TYPE     DATABASE     USER            ADDRESS          METHOD
         主机     all          zbx_monitor     localhost        trust
         主机     all          zbx_monitor     127.0.0.1/32     md5
         主机     all          zbx_monitor     ::1/128          scram-sha-256

如有必要，在为 PostgreSQL by Zabbix agent 2 模板宏配置连接 string 时，也可以直接使用 IPv4 地址（127.0.0.1）。

意外安装 EPEL Zabbix 软件包

安装并启用EPEL仓库后，从软件包安装Zabbix将导致安装EPEL中的Zabbix软件包，而不是官方的Zabbix软件包。

在这种情况下，请卸载来自EPEL的Zabbix软件包，例如：

dnf remove zabbix-server-mysql

阻止从EPEL安装Zabbix软件包。在文件 /etc/yum.conf 中添加以下行：

exclude=zabbix7.0*

再次安装 Zabbix server：

dnf install zabbix-server-mysql

请注意，官方Zabbix软件包在其 version string 中包含 release 字样：

7.0.0-release1.el8

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 主机的仓库配置和密钥目录挂载到容器文件系统命名空间中，get 会传播这些访问权限。

有关更多信息，请参阅 ZBX-24291。

RHEL包签名密钥过期

在 4-更新仓库配置包或其衍生版本上升级 Zabbix 时，可能会遇到软件包的签名密钥问题已过期的问题，相关链接为 Zabbix repository。
当签名密钥过期后，尝试验证软件包签名时会报错，提示证书或密钥已不再有效。例如：

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 repository 的正确链接）。

例如，在 RHEL 9 上运行：

rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm

然后，update 更新仓库信息：

dnf update

有关更多信息，请参见 ZBX-24761。

数据库 TLS 连接与 mariadb

如果使用 mariadb，则在 DBTLSConnect parameter 中不支持使用 'verify_ca' 选项的数据库 TLS 连接。

MySQL/MariaDB可能的死锁

在高负载情况下运行，并且涉及多个LLD工作进程时，可能会由于与行锁策略相关的InnoDB错误而run到死锁中（参见upstream bug）。此错误已在MySQL 8.0.29版本中修复，但在mariadb中尚未修复。更多详细信息，请参见ZBX-21506。

全局事件关联

如果首尾事件之间的时间间隔非常小（例如半秒或更短），事件可能无法通过get正确关联。

PostgreSQL 11及更早版本的数值(浮点)数据类型范围

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 中的正则表达式限制

由于标准 Go 正则表达式库的限制，Zabbix agent 2 不支持正则表达式中的前向和后向预查（lookaheads and lookbehinds）。

IPMI检查

在Debian系统中，使用标准的OpenIPMI库包时，IPMI检查功能在9（stretch）之前版本以及Ubuntu在16.04（xenial）之前版本中将无法正常工作。为了解决这个问题，需要按照ZBX-6139中讨论的方法，启用OpenSSL重新编译OpenIPMI库。

SSH检查

某些 Linux 发行版（如 Debian、Ubuntu）如果通过软件包安装了 libssh2 库，则不支持加密的私钥（带口令）。更多详细信息，请参阅 ZBX-4850。
在某些带有 OpenSSH 8 的 Linux 发行版上，当使用 libssh 0.9.x 时，SSH 检查偶尔会报告“Cannot read data from SSH server”（无法从 SSH 服务器读取数据）。这是由 libssh 的一个缺陷引起的 (issue (more detailed report)。预计该问题已在稳定的 libssh 0.9.5 版本中修复。更多详细信息，请参阅 ZBX-17756。
在 SSH 脚本中使用管道“|”可能导致“Cannot read data from SSH server”（无法从 SSH 服务器读取数据）错误。在这种情况下，建议升级 libssh 库版本。更多详细信息，请参阅 ZBX-21337。

ODBC检查

不应将MySQL unixODBC驱动程序与针对Zabbix server或Zabbix proxy编译的mariadb连接器库一起使用，反之亦然。如果可能，由于存在upstream bug，最好也避免使用相同的连接器作为驱动程序。建议的设置如下：

PostgreSQL、SQLite或Oracle连接器 → mariadb或MySQL unixODBC驱动程序 mariadb连接器 → mariadb unixODBC驱动程序 MySQL连接器 → MySQL unixODBC驱动程序

更多信息和可用的解决方法，请参见ZBX-7665。

从Microsoft SQL Server查询的XML数据在Linux和UNIX系统上可能会以各种方式被get截断。
已观察到，在Linux上使用不同版本的Oracle Instant Client通过ODBC检查监控Oracle数据库时，会导致Zabbix server崩溃。
另请参阅：ZBX-18402、 ZBX-20803。
如果使用FreeTDS UnixODBC驱动程序，需要在SQL query前添加'SET NOCOUNT ON'语句（例如，SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....）。
否则，Zabbix中的数据库监控监控项将无法检索信息，并返回错误“SQL query返回空结果”。
更多信息，请参见ZBX-19917。

监控项中错误的请求方法参数

请求方法参数仅在HTTP检查中使用，可能错误地被设置为“1”，这是由于从低于4.0版本的Zabbix升级后，所有监控项的非默认值导致的。有关如何解决此问题的详细信息，请参见ZBX-19308。

Web监控和HTTP agent

在某些 Linux 发行版中，由于在 Web 场景或 HTTP agent 中启用 "SSL verify peer" 时出现 upstream bug，导致 Zabbix server 出现 memory。有关详细信息和可用的解决方法，请参阅 ZBX-10486。

简单检查

在 fping v3.10 之前的版本中存在一个错误，该错误导致处理不当重复的回显应答数据包。这可能会导致意外的结果。 icmpping、icmppingloss、icmppingsec 监控项。建议使用最新的 version 版本的 fping。请参阅 ZBX-11726 了解更多信息细节。

无 root 权限容器中 fping 执行的错误

当容器以无根模式或在特定限制环境中运行时，在执行 ICMP 检查（例如 fping: Operation not permitted 或发送至所有资源的数据包全部丢失）时，您可能会遇到与 fping 执行相关的错误。

要解决此问题，请将 --cap-add=net_raw 添加到 "docker run" 或 "podman run" 命令中。

此外，在非 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 version 之前版本可能导致 Zabbix 崩溃如果在Zabbix server中设置了SourceIP参数，则为服务器配置文件。作为变通方案，请不要设置 SourceIP 参数。同样的问题也适用于Linux，但并不总是如此。导致 Zabbix server 停止工作。net-snmp 的本地补丁在 OpenBSD 上应用的软件包将随 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 server 告警器进程崩溃的实例。详情请参阅 ZBX-10461。

升级 Zabbix agent 2（6.0.5 或更早版本）

当从软件包升级 Zabbix agent 2（version 6.0.5 或更早版本）时，可能会出现与插件相关的 file 冲突错误。
要解决此错误，请备份您的 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 中的多线程。

此问题与设置区域的方式有关 in PHP：区域信息是按进程维护的，而不是按线程维护的。因此，在多线程环境中，当有多个项目 run 由同一个 Apache 进程处理时，可能会在另一个线程中更改区域设置，并且这会改变 Zabbix 线程中数据的处理方式。

有关更多信息，请参阅相关的问题报告：

ZBX-10911（前端区域设置翻转问题）
ZBX-16297（在图形中使用 BC Math 函数的 bcdiv 函数进行数字处理时的问题）

图形

夏令时

夏令时（DST）的更改会导致显示 X 轴标签时出现异常（例如日期重复、日期缺失等）。

求和聚合

当在图表中使用配置且时间段小于一小时时，如果数据来源于趋势数据，图表会显示错误的（被放大）值。

文本重叠

对于某些前端语言（例如日语），本地字体可能导致图例中的文本重叠。
为避免此问题，请使用 PHP GD 扩展的 version 2.3.0（或更高版本）。

日志文件监控

log[] 和 logrt[] 在监控项中会反复从头开始重新读取日志 file，如果 file 系统已满 100% 且日志 file 正在被追加内容（更多信息请参见 ZBX-10884）。

慢MySQL查询

当监控项不存在值时，Zabbix server会产生缓慢的SELECTqueries。
此issue问题已知出现在MySQL的5.6/5.7版本中
（详细讨论请参见ZBX-10652），
并且在某些特定情况下，也可能出现在后续的MySQL版本中。
解决此问题的方法是禁用MySQL中的index_condition_pushdown或prefer_ordering_index优化器。
但是请注意，此解决方法可能无法修复所有与缓慢queries相关的问题问题。

Oracle 配置同步缓慢

在具有 Oracle 数据库且包含大量监控项和监控项预处理步骤的 Zabbix 安装中，配置同步可能会较慢。此问题是由于 Oracle 数据库引擎处理 nclob 类型字段的速度所导致。

为了提升性能，您可以通过手动应用数据库补丁 items_nvarchar_prepare.sql 将字段类型从 nclob 转换为 nvarchar2。请注意，此操作 version 将导致监控项预处理参数以及监控项参数（例如 Description、脚本监控项的字段 Script、HTTP agent 监控项的字段 Request body 和 Headers、数据库监控监控项的字段 SQL query）的最大字段大小限制从 65535 字节减少到 4000 字节。补丁中以注释形式提供了用于确定在应用补丁前需要删除的模板名称的 queries。或者，如果设置了 MAX_STRING_SIZE，您可以在补丁的 queries 中将 nvarchar2(4000) 更改为 nvarchar2(32767)，以将字段大小限制设置为 32767 字节。

有关扩展讨论，请参见 ZBX-22363。

从链接持久化过滤器设置

当打开包含过滤器设置（包括时间选择器）的 Zabbix 前端页面链接时，该过滤器会自动保存到数据库中，以替换该用户此前保存的此页面的过滤器和/或时间选择器设置。这些设置将保持有效，直到用户手动更新或重置它们。

SNMPv3陷阱中的IPv6地址问题

由于 net-snmp 的缺陷，在 SNMP 陷阱中使用 SNMPv3 时可能无法正确显示 IPv6 地址。有关详细信息和可能的解决方法，请参阅 ZBX-14541。

失败登录信息中截断的长IPv6地址

失败的 login 尝试消息将仅显示存储的 IP 地址的前 39 个字符，因为这是数据库字段中的字符限制。这意味着超过 39 个字符的 IPv6 IP 地址将显示不完整。

Windows上的Zabbix agent检查

在 Server 参数的 Zabbix agent 配置
file（zabbix_agentd.conf）中存在无效的 DNS 条目可能会增加
Zabbix agent 在 Windows 上的响应时间。这是因为 Windows DNS 缓存守护进程不会缓存针对 IPv4 地址的否定响应。
但是，对于 IPv6 地址，否定响应会被缓存，因此此问题的一个可能解决方法是禁用主机上的 IPv4。

YAML 导出/导入

以下是一些已知的与YAML相关的问题：

export/import:

错误信息无法翻译；
有时带有 .yaml file 扩展名的有效 JSON 无法被导入；
未加引号的人类可读日期会自动转换为 Unix 时间戳。

SUSE 上的设置向导，使用 nginx 和 php-fpm

前端安装向导无法在 SUSE 上保存配置 file 与 nginx + php-fpm。这是由于在 /usr/lib/systemd/system/php-fpm.service 单元中的一个设置导致的，该设置阻止了 Zabbix 向 /etc 目录写入内容（在 PHP 7.4 中引入）。

目前有两种解决方法：

在 php-fpm systemd 单元中将 ProtectSystem 选项设置为 'true' 而不是 'full'。
手动保存 /etc/zabbix/web/zabbix.conf.php 文件。

授权头转发

在某些情况下，Apache 或 nginx 可能会阻止 API 请求中的 Authorization 标头传递到 Zabbix。这会导致在使用 Zabbix API 或单点登录（SSO）服务（例如使用 Okta 的 SAML）时出现身份验证问题。

为了解决这个问题，请 update 您的 Web 服务器配置。

对于 Apache，如果将其用作反向 proxy（非 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 作为反向 proxy 使用，则可以通过将以下指令添加到 /etc/nginx/nginx.conf（用于您的 Zabbix 前端位置）来显式转发 Authorization 标头：

...
       location / {
       ...
           proxy_set_header Authorization $http_authorization;
           proxy_pass http://backend_server;
       ...
       }

更新配置后，请重启您的 Web 服务器。

有关更多详细信息，请参阅：

ZBX-22952
Apache 2.4 + PHP-FPM and Authorization headers
SetEnvIfNoCase 和 CGIPassAuth 指令
NGINX Reverse Proxy

Ubuntu 20 上用于 Zabbix web 服务的 Chromium

尽管在大多数情况下，Zabbix 网页服务可以 run 与 Chromium 一起使用，但使用 Chromium 浏览器时，Ubuntu 20.04 会出现以下错误：

无法获取数据：chrome 启动失败：cmd_run.go:994:
       警告：无法create用户数据目录：无法create
       “/var/lib/zabbix/snap/chromium/1564”：创建目录 /var/lib/zabbix 时出错：权限被拒绝
       抱歉，当前不支持位于 /home 以外的主目录。详情请参见 https://forum.snapcraft.io/t/11209。

此错误发生是因为将 /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 server 或 proxy。要确定错误原因，请查阅 Azure 日志。

Invalid regular expressions after switching to PCRE2

在 Zabbix 6.0 中已添加对 PCRE2 的支持。尽管 PCRE 仍然受支持，但针对 RHEL 7 及更新版本、SLES（所有版本）、Debian 9 及更新版本、Ubuntu 16.04 及更新版本的 Zabbix 安装包已更新为使用 PCRE2。尽管切换到 PCRE2 提供了许多优势，但可能会导致某些现有的 PCRE 正则表达式模式无效或行为发生变化。特别是，模式 ^[\w-\.] 会受到影响。为了在不影响语义的情况下使该正则表达式再次有效，请将表达式更改为 ^[-\w\.]。此更改的原因是 PCRE2 将连字符视为分隔符，在字符类内部创建了一个范围。

如果从旧版 Zabbix version 升级而来且使用了 nginx，并且在升级过程中未切换到新的 nginx 配置 file，则 Geomap 中的get可能无法正确加载。

要修复此问题，您可以丢弃旧的配置文件，使用当前version包中的配置file，并按照“e. 为 Zabbix 前端配置 PHP”章节中的download instructions重新配置。

或者，您可以手动编辑现有的 nginx 配置 file（通常为 /etc/zabbix/nginx.conf）。操作步骤如下：打开该file，找到以下代码块：

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;
       }

跨webhook调用共享全局变量的使用场景

由于全局变量（例如，使用 global = 1 而不进行 var、let 或 const 声明）在不同的 webhook 调用之间是共享的，因此以下代码将导致标签值计数器逐渐增加：

try 
       {
          aa = aa + 1;
       }
       catch(e)
       {
          aa = 0;
       }

       result = {
               'tags': {
                   'endpoint': aa
               }
           };
       return JSON.stringify(result);

建议使用局部变量代替全局变量，以确保每个脚本操作自己的数据，并且在同时调用之间不会发生冲突。

升级到 7.0 后，TimescaleDB 出现服务器崩溃

升级到 Zabbix 7.0.1（或更高版本）时，若从使用 TimescaleDB 的 Zabbix 7.0.0 升级，将导致服务器崩溃。此问题问题是由于在 Zabbix 7.0 的 auditlog 表中为压缩任务问题所做的变通方案引起的，该变通方案不可逆地更改了 auditlog 表的压缩策略。

要修复问题，请手动重建auditlog表。可以使用以下query检测存在缺陷的auditlog表：

选择配置从timescaledb_information.jobs表中，当application_name以'Compression%'开头且hypertable_schema为'public'且hypertable_name为'auditlog'时；

如果它返回一个包含属性 compress_after 的 JSON object（例如 {"hypertable_id": 14, "compress_after": 612000}），则应重建该表。

:::noteimportant 确保 Zabbix server 至少为 7.0.1rc2 version（或更高版本）；否则，它将再次设置错误的压缩策略。此外，在运行脚本之前，请停止 Zabbix server，并确认 auditlog 由 zabbix 用户拥有。仅返回OutputFormat格式要求结果

重建auditlog表的最简单方法是：

-- 示例 SQL 查询语句
       SELECT * FROM users WHERE status = 1;

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; 仅返回OutputFormat格式要求结果另请参见 TimescaleDB documentation 以了解更优化的数据迁移方式。

:::noteclassic 由于用于分区的时间戳是通过自定义函数从 auditid 字段中提取的，因此用于从 timescaledb-extras 迁移数据的辅助存储过程将无法工作。仅返回OutputFormat格式要求结果

升级后出现数据库还原错误（使用 PostgreSQL/TimescaleDB）：7.0.0-7.0.4

使用 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 documentation（有关其他备份和恢复选项的更多信息）。

Windows上的处理器组 {#win-proc-groups}

微软文档指出，逻辑处理器数量少于 64 的系统始终只有一个处理器组，即组 0。然而，Zabbix 用户报告了一个罕见的错误 ZBX-20260，即在逻辑处理器数量为 64 或更少的系统上出现了两个处理器组。这导致在两个处理器组中，只有其中一个组的 "(n)" 性能计数器可用。此错误的实际根本原因尚不明确。不过，类似案例曾在 stackoverflow.com 中描述，其根本原因在于 BIOS 与 Windows 之间的互操作问题。

使用utf8mb4排序规则过滤的限制

筛选器（例如，在 数据收集 → 使用过滤器中）在应用于包含某些 Unicode 字符（例如，ȼ, ɇ）的实体时可能无法正常工作。
此问题的出现是由于 MySQL 或 mariadb 数据库的默认 utf8mb4_bin 排序规则在处理 Unicode 字符排序和比较时的方式所致。

为解决此限制，用户可以将数据库列的排序规则更改为其他选项，例如 utf8mb4_0900_bin、utf8mb4_0900_ai_ci 或 utf8mb4_unicode_520_ci。
但请注意，更改排序规则可能会导致在空格处理以及其它字符的排序和筛选中出现意外行为。

有关更改排序规则的更多信息，请参阅 MySQL documentation 或 MariaDB documentation。
有关排序规则差异的详细信息，请参阅 MySQL 文档中的 Unicode Character Sets。

地图中嵌套主机组信息不正确

在地图中嵌套的主机组的信息显示不正确，例如：

主机组标签显示的问题摘要未包含嵌套主机组中的所有主机；
“主机组元素”视图未为嵌套主机组中的每个主机显示单独的地图元素；
地图标签显示了所有问题的摘要，但未包含嵌套主机组中的问题。

在7.0.7中损坏的LLD规则覆盖

在 version 7.0.7 中，处理低级别自动发现规则覆盖时，Zabbix server 会发生崩溃。作为临时解决方案，请禁用包含覆盖项的LLD规则。该问题已在 Zabbix 7.0.8rc2 中修复。

Zabbix中预处理管理器性能问题在 Zabbix 7.0.14

在 version 7.0.14 中，当单个监控项一次性接收到多个值时（例如在日志监控期间），并且配置了多个预处理工作进程时，Zabbix preprocessing 管理进程可能导致高 CPU 使用率。
作为临时解决方法，请将 StartPreprocessors startpreprocessors/startpreprocessors 配置参数设置为 1。
该问题已在 Zabbix 7.0.15 中修复。

宏函数

宏函数在脚本监控项参数和浏览器监控项脚本参数中不起作用。该问题已在 Zabbix 7.0.7 中修复。

MariaDB 10.5.1-10.5.9对UI元素的访问

使用非超级管理员角色访问 Zabbix Web 前端可能会导致显示以下消息：“系统错误发生。请联系 Zabbix 管理员。” 此问题问题影响通过10.5.1使用的第三方外部配套软件安装10.5.9。

为了避免此问题，请将update mariadb到比10.5.9更新的version。有关更多详细信息，请参见ZBX-25746。

使用tcmalloc分析内存过度使用

如果您怀疑 Zabbix 安装使用了过多内存，可以使用 tcmalloc's 中的 memory 分析功能来调查 Zabbix server/proxy 的 memory 消耗情况。

1. 在安装 Zabbix from sources 时，配置额外的标志：

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

-std=gnu99 flag 是构建 Zabbix server、Zabbix proxy 或 Zabbix agent 所必需的。
-g flag 添加额外的调试信息，而 -O0 则禁用优化，这些优化可能会干扰 tcmalloc 的分析功能。

2. 在启动 Zabbix server 之前设置以下环境变量。
这些变量告诉 tcmalloc 如何跟踪和报告 memory 使用情况：

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. 通过向目标 get 进程发送信号 5 来触发一个 profile 转储。将 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 负责几乎所有的 memory 分配。

另请参阅：

ZBX-25050 和 ZBX-25584 中的相关问题报告。
GCC Option Summary 中关于编译选项（如 -std=gnu99、-g、-O0 等）的内容。
Gperftools Heap Profiler 中关于用于 tcmalloc 分析的环境变量的文档。

MySQL 8.0多主模式下的组复制

在使用 MySQL 8.0 组复制的多主模式时，您可能会在事务提交期间遇到类似于以下的错误：

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 失败: [3101] 插件指示服务器回滚当前事务。[commit;]

此错误似乎是由涉及外键约束的回滚操作触发的问题。