On this page

已知问题

另请参见:编译问题

升级

成功升级所需的 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 服务器/agent 通过 IPv6 访问。 此外,在 Zabbix 模板和配置中,应显式使用 localhost 而不是 127.0.0.1,以确保同时兼容 IPv4 和 IPv6。

例如,在使用 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

如有必要,在为连接字符串配置 PostgreSQL by Zabbix agent 2 模板宏时,您也可以直接使用 IPv4 地址(127.0.0.1)。

意外安装 EPEL Zabbix 软件包

如果已安装并启用 EPEL 仓库,安装 Zabbix 软件包时可能会拉取 EPEL 版本,而不是官方 Zabbix 软件包。 要解决此问题:

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.solibOpenIPMIposix.so 库,而 UBI 系统上默认启用的软件包管理器仓库中没有任何软件包提供这些库,这将导致安装失败。

libOpenIPMI.solibOpenIPMIposix.so 库可在 OpenIPMI-libs 软件包中获得,该软件包由 redhat-#-for-<arch>-appstream-rpms 仓库提供。
对此仓库的访问由订阅控制;在 UBI 环境中,这种访问是通过将 RHEL 主机的仓库配置和 secrets 目录挂载到容器文件系统命名空间中来传递的。

更多信息,请参见 ZBX-24291

RHEL 软件包的签名密钥已过期

Red Hat Enterprise Linux 或其衍生发行版上升级 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 10 上,运行:

rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/10/noarch/zabbix-release-latest.el10.noarch.rpm

然后,更新仓库信息:

dnf update

更多信息,请参见 ZBX-24761

Timescale DB:大量分区导致内存占用过高

PostgreSQL 9.6-12 版本在更新包含大量分区的表时会占用过多内存。
当 Zabbix 在使用 TimescaleDB 的系统上更新趋势数据,且趋势数据被拆分为相对较小的块(例如 1 天)时,就会出现此问题。
在默认的 housekeeping 设置下,这会导致趋势表中存在数百个块——在这种情况下,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 parameter 的 'verify_ca' 选项不支持数据库 TLS 连接。

MySQL/MariaDB 中可能出现的死锁

在高负载运行且涉及多个 LLD worker 的情况下,可能会遇到由与行锁定策略相关的 InnoDB 错误导致的死锁(参见上游缺陷)。 该错误已在 MySQL 8.0.29 起修复,但在 MariaDB 中尚未修复。 更多详细信息,请参见 ZBX-21506

全局事件关联

如果第一个和第二个事件之间的时间间隔非常短,即半秒及以下,事件可能无法被正确关联。

NetBSD 8.0 及更新版本

在 NetBSD 8.X 和 9.X 版本上,各种 Zabbix 进程在启动时可能会随机崩溃。 这是由于默认栈大小(4MB)过小导致的,必须通过运行以下命令来增大:

ulimit -s 10240

更多信息请参见相关的问题报告:ZBX-18275

Zabbix agent 2 中的正则表达式限制

由于标准的 Go regexp 库的限制,Zabbix agent 2 不支持正向预查和反向预查功能。

IPMI 检查

在 Debian 9(stretch)之前以及 Ubuntu 16.04(xenial)之前的版本中,IPMI 检查无法与标准 OpenIPMI 库软件包一起正常工作。
要解决此问题,请按照 ZBX-6139 中的说明,在启用 OpenSSL 的情况下重新编译 OpenIPMI 库。

IPMI — 不受信任的主机可能导致 OpenIPMI 崩溃

Zabbix 用于轮询 IPMI 数据的 OpenIPMI 库中存在一个缺陷,该缺陷可被来自不受信任设备的特制响应触发。
不受信任的 IPMI 设备可能会发送特制数据,导致 OpenIPMI 库崩溃,进而可能导致执行 IPMI 轮询的 Zabbix 服务器进程终止。

SSH 检查

  • 某些 Linux 发行版(如 Debian、Ubuntu)如果从软件包安装 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 检查

  • 如果可能,不应将 MySQL unixODBC 驱动程序与针对 MariaDB connector 库编译的 Zabbix 服务器或 Zabbix proxy 一起使用,反之亦然;同时,由于一个上游缺陷,最好也避免使用与驱动程序相同的 connector。
    推荐的设置:

PostgreSQL、SQLite 或 Oracle connector → MariaDB 或 MySQL unixODBC 驱动程序
MariaDB connector → MariaDB unixODBC 驱动程序
MySQL connector → MySQL unixODBC 驱动程序

更多信息及可用的变通方法,请参见 ZBX-7665

  • 从 Microsoft SQL Server 查询的 XML 数据在 Linux 和 UNIX 系统上可能会以多种方式被截断。

  • 已观察到,使用 ODBC 检查并结合多个版本的 Oracle Instant Client for Linux 来监控 Oracle 数据库时,可能会导致 Zabbix 服务器崩溃。\ 另请参见:ZBX-18402ZBX-20803

  • 如果使用 FreeTDS UnixODBC 驱动程序,则需要在 SQL 查询前加上 SET NOCOUNT ON 语句(例如,SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....)。 否则,Zabbix 中的数据库监控项将无法获取信息,并报错
    “SQL query returned empty result”。
    更多信息请参见 ZBX-19917

监控项中的请求方法参数不正确

仅用于 HTTP 检查的请求方法参数,可能会因从 4.0 之前的 Zabbix 版本升级,而被错误地设置为“1”,这对所有监控项来说都是一个非默认值。 有关如何修复此问题的详细信息,请参见 ZBX-19308

Web 监控和 HTTP agent

由于某些 Linux 发行版中的一个上游缺陷,当在 Web 场景或 HTTP agent 中启用“SSL verify peer”时,Zabbix 服务器会发生内存泄漏。 更多信息及可用的变通方法,请参见 ZBX-10486

简单检查

早于 v3.10 的 fping 版本中存在一个 bug,会错误处理重复的 echo replay 数据包。
这可能会导致 icmppingicmppinglossicmppingsec 监控项出现非预期结果。
建议使用最新版本的 fping
更多详情请参见 ZBX-11726

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

当容器以无 root 权限模式运行,或处于具有特定限制的环境中时,在执行 ICMP 检查时,您可能会遇到与 fping 执行相关的错误,例如 fping: Operation not permitted,或者所有资源的所有数据包均丢失。

要修复此问题,请在 "docker run" 或 "podman run" 命令中添加 --cap-add=net_raw

此外,在非 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 trap

SNMP trap 所需的 "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 线程中数据的处理方式。

更多信息请参见相关问题报告:

  • 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 轴标签时出现不规则情况(日期重复、日期缺失等)。

求和聚合

当在图形中对少于一小时的时间段使用 求和聚合 时,如果数据来自趋势数据,图形将显示不正确的(被放大了的)值。

文本重叠

对于某些前端语言(例如日语),本地字体可能会导致图形图例中的文本重叠。
为避免这种情况,请使用 PHP GD 扩展 2.3.0(或更高)版本。

日志文件监控

如果文件系统已 100% 满,并且日志文件仍在持续追加内容,则 log[]logrt[] 监控项会反复从头重新读取日志文件(更多信息请参见 ZBX-10884)。

MySQL 慢查询

当监控项不存在值时,Zabbix 服务器会生成较慢的 SELECT 查询。 此问题已知会在 MySQL 5.6/5.7 版本中发生(有关扩展讨论,请参见 ZBX-10652),并且在某些特定情况下,也可能出现在较新的 MySQL 版本中。 一种变通方法是在 MySQL 中禁用 index_condition_pushdownprefer_ordering_index 优化器。 但请注意,此变通方法可能无法解决与慢查询相关的所有问题。

来自链接的持久过滤器设置

当打开指向 Zabbix 前端页面且包含过滤器设置(包括时间选择器)的链接时,该过滤器会自动为用户保存到数据库中,并替换此前为该页面保存的过滤器和/或时间选择器设置。
这些设置会保持生效,直到用户手动更新或重置它们。

SNMPv3 trap 中的 IPv6 地址问题

由于 net-snmp 的一个缺陷,在 SNMP trap 中使用 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 时间戳。

在 SUSE 上使用 NGINX 和 php-fpm 的安装向导

在 SUSE 上使用 NGINX + php-fpm 时,前端安装向导无法保存配置文件。
这是由 /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 或单点登录(SSO)服务时导致身份验证问题,例如配合 Okta 使用的 SAML。

为解决此问题,请更新 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 前端 location)中来显式转发 Authorization 标头:

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

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

更多详细信息,请参见:

Ubuntu 20 上用于 Zabbix Web 服务的 Chromium

尽管在大多数情况下,Zabbix Web 服务可以使用 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 上将 Zabbix 与 MySQL 安装一起使用时,Zabbix 日志中可能会出现通用错误消息 [9002] Some errors occurred。 该消息由数据库发送到 Zabbix 服务器或 proxy。 要确定错误原因,请查阅 Azure 日志。

切换到 PCRE2 后无效的正则表达式

在 Zabbix 6.0 中,已添加对 PCRE2 的支持。
尽管仍然支持 PCRE,但适用于 RHEL 7 及更高版本、SLES(所有版本)、Debian 9 及更高版本、Ubuntu 16.04 及更高版本的 Zabbix 安装包已更新为使用 PCRE2。
虽然这带来了许多好处,但切换到 PCRE2 可能会导致某些现有的 PCRE 正则表达式模式变为无效,或表现出不同的行为。
其中,模式 \^[\w-\.] 会受到影响。
为了在不影响语义的情况下使该正则表达式重新有效,请将该表达式更改为 \^[-\w\.]
这是因为 PCRE2 会将连字符视为分隔符,从而在字符类中创建一个范围。

Geomap 小部件错误

如果您是从较旧的 Zabbix 版本升级而来,且使用的是 NGINX,并且在升级过程中未切换到新的 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)会创建隐式全局变量,这些变量可能在当前执行结束后仍然存在。 将敏感数据(令牌、密码等)存储在隐式全局变量中,会增加被后续预处理运行或在同一环境中执行的其他集成意外暴露或复用的风险。

不要依赖隐式全局变量。 始终使用 varconst 声明变量,并避免将敏感信息附加到全局对象(例如 globalThiswindow)上。 在预处理中,没有受支持的方法可以从内部覆盖内置全局对象。

安全示例:

var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });

Windows 上的处理器组

Microsoft 文档指出,逻辑处理器少于 64 个的系统始终只有一个处理器组,即 Group 0。 但是,Zabbix 用户报告了一个罕见的 bug:ZBX-20260,即在逻辑处理器数量不超过 64 个的系统上存在两个处理器组。 这导致两个处理器组中只有一个处理器组具有 "\Processor(n)" 性能计数器。 该 bug 的实际根本原因尚不清楚。 不过,在 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 Character Sets

使用 MariaDB 10.5.1–10.5.9 时访问 UI 元素

使用 Super Admin 以外的角色访问 Zabbix Web 前端时,可能会出现以下消息:“发生系统错误。 请联系 Zabbix 管理员。”。 此问题会影响使用 MariaDB versions 10.5.1 到 10.5.9 的安装环境。

为避免此问题,请将 MariaDB 更新到高于 10.5.9 的版本。更多详细信息,请参见 ZBX-25746

使用 tcmalloc 分析过高的内存使用

如果您怀疑 Zabbix 安装占用了过多内存,可以使用 tcmalloc 的内存分析功能来调查 Zabbix 服务器/proxy 的内存消耗。

1. 在从源码安装 Zabbix 时,配置附加标志:

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

-std=gnu99 标志是构建 Zabbix 服务器、Zabbix proxy 或 Zabbix agent 所必需的。
-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 来触发 profile 转储。
将 1234 替换为实际的进程 ID (PID):

kill -5 1234

4. 打印生成的 profile:

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 几乎负责了所有内存分配。

另请参见:

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

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

另请参见: