Table of Contents

8 已知问题

另请参阅:编译问题.

使用 MySQL 8.0.0-8.0.17 启动 Proxy

zabbix_proxy 在 8.0.0-8.0.17 版本的 MySQL 上启动失败并报错 "access denied" :

[Z3001]  connection to database 'zabbix' failed: [1227] Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

这是由于 MySQL 8.0.0 版本开始强制设置会话变量的特殊权限。然而,在 8.0.18 中删除了此行为: 从 MySQL 8.0.18 开始,不再限制设置系统会话变量的操作

解决方法是向zabbix 用户授予额外权限:

对于 MySQL 8.0.14 - 8.0.17: grant SESSION_VARIABLES_ADMIN on . to 'zabbix'@'localhost';

对于 MySQL 8.0.0 - 8.0.13: grant SYSTEM_VARIABLES_ADMIN on . to 'zabbix'@'localhost';

升级

升级成功的 SQL 模式设置

在 MySQL/MariaDB 中,必须设置 "STRICT_TRANS_TABLES" 模式的 sql_mode 设置。如果缺少此设置,Zabbix 数据库升级将失败(另请参阅 ZBX-19435)。

从 MariaDB 10.2.1 以及之前的版本升级

如果数据库表是使用 MariaDB 10.2.1 及之前的版本创建的,升级 Zabbix 可能会失败,因为在这些版本中,默认的 ROW_FORMAT(即行格式,是指数据的记录即数据行在磁盘中的物理存储方式) 是 compact。这个问题可以通过将 ROW_FORMAT 更改为 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 的兼容性。

例如,当使用 Zabbix agent2监控PostgreSQL 模板监控 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

如有必要,您也可以在配置 Zabbix agent2监控PostgreSQL 模板的连接字符串宏时直接使用 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 包的版本字符串中包含单词 release

7.0.0-release1.el8

适用于 Red Hat UBI 环境的 RHEL Zabbix 包

Red Hat Universal Base Image 环境中从 Red Hat Enterprise Linux (RHEL) 包安装 Zabbix 时,请确保可以访问所需的仓库和依赖项。 Zabbix 包依赖于 libOpenIPMI.solibOpenIPMIposix.so 库,这些库在 UBI 系统上启用的默认包管理器仓库中没有提供,这将导致安装失败。

libOpenIPMI.solibOpenIPMIposix.so 库包含在 OpenIPMI-libs 包中,该包由 redhat-#-for-<arch>-appstream-rpms 仓库提供。 对该仓库的访问由订阅进行管理,在 UBI 环境中,订阅通过将 RHEL 主机的仓库配置和密钥目录挂载到容器文件系统命名空间中来传播。

更多信息,请参阅 ZBX-24291

红帽企业版Linux软件包的签名密钥过期

红帽企业版Linux或其衍生系统上升级Zabbix时,可能会遇到Zabbix软件库中软件包的签名密钥过期问题。 当签名密钥过期时,验证软件包签名的尝试将导致错误,指出证书或密钥不再有效。例如:

错误:使用证书D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD(Zabbix LLC(2022年7月)<[email protected]>)验证签名:
         1. 证书19F2475308EFA7DD无效:证书未生效
             因为:主密钥未生效
             因为:2024年7月4日11:41:23Z过期
         2. 密钥19F2475308EFA7DD无效:密钥未生效
             因为:主密钥未生效
             因为:2024年7月4日11:41:23Z过期

为了解决此类问题,手动重新安装适用于您的红帽企业版Linux变体的最新zabbix-release软件包 (将下面的链接替换为Zabbix软件库中的正确链接)。

例如,在红帽企业版Linux 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 worker 时,可能会遇到由 与行锁定策略相关的 InnoDB 错误(参见 上游错误)。 从 8.0.29 开始,该错误在 MySQL 中已修复,但在 MariaDB 中未修复。 有关详细信息,请参阅 ZBX-21506

全局事件关联

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

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 regexp 库的限制,Zabbix agent 2 不支持正向预查和反向预查功能。

IPMI 检查

用 Debian 9 (stretch) 和 Ubuntu 16.04 (xenial) 之前版本的标准 OpenIPMI 库包运行 IPMI 检查会无法正常运行。要解决此问题,请重新编译 OpenIPMI 库并启用 OpenSSL,参考 ZBX-6139

SSH 检查

· - 如果 libssh2 库是从软件包安装的,一些 Linux 发行版如 Debian、Ubuntu 不支持加密私钥(带密码)。 有关详细信息,请参阅 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 connector library 编译的 Zabbix server 或 Zabbix proxy 上使用 MySQL unixODBC 驱动程序,反之亦然。如果可以,由于 上游 bug,最好避免使用与驱动程序相同的连接器。建议设置:
PostgreSQL, SQLite or Oracle connector → MariaDB or MySQL unixODBC driver
       MariaDB connector → MariaDB unixODBC driver
       MySQL connector → MySQL unixODBC driver

请参阅 ZBX-7665 了解更多信息和可用的解决方案。

  • 从 Microsoft SQL Server 查询的 XML 数据在 Linux 和 UNIX 系统上可能会以各种方式被截断。
  • 在 CentOS 8 上用 Oracle Instant Client for Linux 11.2.0.4.0 通过 ODBC 检查监控 Oracle 数据库会导致 Zabbix server 崩溃。该问题可以通过将 Oracle Instant Client 升级到 12.1.0.2.0、12.2.0.1.0、18.5.0.0.0 或 19 来解决。另请参见 ZBX-18402

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

在 HTTP 检查中使用的 request_method 参数可能被错误地设置为 “1”,监控项的非默认值是由于从 Zabbix 4.0 之前的版本升级造成的。点击 ZBX-19308 查看解决方法。

Web 监控和 HTTP agent

由于 上游 bug,在 Web 场景或 HTTP agent 中启用 “SSL verify peer” 时,Zabbix server 在 CentOS 6、CentOS 7 或其他 Linux 发行版上可能存在内存泄漏(leaks memory)的问题。参考 ZBX-10486 获取更多信息和解决方案 。

简单检查

在 v3.10 之前的 fping 版本中存在错误处理重复的回显重放数据包的 bug。可能会导致 icmpping, icmppingloss, icmppingsec 监控项故障。建议使用最新版本的 fping。参考 ZBX-11726

在无根容器中执行 fping 时出现的错误

当容器以无根模式或在受限环境中运行时,执行 ICMP 检查时可能会遇到与 fping 执行相关的错误,例如 fping: Operation not permitted 或所有资源的所有数据包丢失。

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

此外,在非根环境中执行 fping 可能需要修改 sysctl,例如:

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

这里的 "1995" 是 zabbix GID。有关更多详细信息,请参阅 ZBX-22833

SNMP 检查

对于 OpenBSD 操作系统,如果在 Zabbix server 配置文件中设置了 SourceIP 参数,则 5.7.3(及之前)版本中 Net-SNMP 库的 use-after-free bug 会导致 Zabbix server 崩溃。其中一种解决办法是不设置 SourceIP 参数。同样的问题也存在于 Linux,但它不会导致 Zabbix server 停止工作。OpenBSD 上的 net-snmp 软件包的本地补丁已启用,并将与 OpenBSD 6.3 一起发布。

SNMP 数据峰值

SNMP 监控数据中的峰值可能与某些物理因素有关,如电源中的电压峰值。详情点击 ZBX-14318

SNMP trap

SNMP trap 所需的 “net-snmp-perl” 软件包已在 RHEL/CentOS 8.0-8.2 中删除,在 RHEL 8.3 中重新添加。

所以如果你使用的是 RHEL 8.0-8.2,最好的解决方案是升级到 RHEL 8.3;如果你使用的是 CentOS 8.0-8.2,您可以等待 CentOS 8.3 或使用 EPEL 源提供的软件包。

详情参阅 ZBX-17192

Alerter 进程在 Centos/RHEL 7 中崩溃

在 Centos/RHEL 7 中遇到了 Zabbix server 的 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 中] (https://www.php.net/manualen/function.setlocale) 设置语言环境有关:语言环境信息是按进程维护的,而不是按线程维护的。因此,在多线程环境中,当有多个监控项由同一个 Apache 进程运行时,可能会在另一个线程中更改语言环境,从而改变 Zabbix 线程中处理数据的方式。

更多信息,详见相关问题报告: - ZBX-10911 (Problem with flipping frontend locales) - ZBX-16297 (Problem with number processing in graphs using the bcdiv function of BC Math functions)

Graphs 图形

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

日志文件监控

如果文件系统达到 100% 并且日志正在追加,则 log[]logrt[] 监控项会从头重读日志文件,(参阅 ZBX-10884 )获取更多。

MySQL 慢查询

如果监控项的值不存在,Zabbix server 会生成慢查询。这是由MySQL 5.6/5.7 版本中的一个已知 问题 引起的。解决方法是禁用 MySQL 中的 index_condition_pushdown optimizer。详情参阅 ZBX-10652

Oracle 数据库慢配置同步

在具有大量项目和项目预处理步骤的 Oracle DB 中,Zabbix 安装的配置同步可能会很慢。 这是由于 Oracle 数据库引擎处理 nclob 类型字段的速度较慢所致。

为了提高性能,您可以通过手动应用数据库补丁 items_nvarchar_prepare.sql 将字段类型从 nclob 转换为 nvarchar2。 请注意,此转换将将项目预处理参数和项目参数(例如 Description、脚本项的字段 Script、HTTP 代理项的字段 Request bodyHeaders、数据库监视器项的字段 SQL query)的最大字段大小限制从 65535 字节降低到 4000 字节。 在应用补丁之前,补丁中提供了用于确定需要删除的模板名称的查询作为注释。 另外,如果设置了 MAX_STRING_SIZE,您可以在补丁查询中将 nvarchar2(4000) 更改为 nvarchar2(32767),以设置 32767 字节的字段大小限制。

有关详细讨论,请参阅 ZBX-22363

从链接获取的持久化过滤器设置

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

SNMPv3 trap 中的 IPv6 地址问题

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

裁剪了登录失败信息中的长 IPv6 IP 地址

登录失败的消息将仅显示存储的 IP 地址的前 39 个字符,这是由于数据库字段中的字符限制。这意味着超过 39 个字符的 IPv6 IP 地址将不能完整显示。

Windows 的 Zabbix agent

Zabbix agent 配置文件 (zabbix_agentd.conf) 中设置非 DNS 性质的 Server 参数可能会增加 Windows 上 Zabbix agent 的响应时间。发生这种情况是因为 Windows DNS 缓存守护程序不会缓存 IPv4 地址的否定响应。但是会缓存 IPv6 地址的否定响应,因此可能的解决方法是在主机上禁用 IPv4。

YAML 导出/导入

YAML 导出/导入 存在一些已知问题:

  • 错误消息不会被翻译;
  • 有时会无法导入带有 .yaml 文件扩展名的有效 JSON 文件;
  • 日期如果不加引号会自动转换为 Unix 时间戳。

使用 NGINX 和 php-fpm 在 SUSE 上设置向导

在 SUSE 上使用 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 请求中的授权头到达 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),请改为添加以下指令:
       
       ```ini
       CGIPassAuth On
       ```相比之下,**nginx** 自动处理授权头。
       然而,如果 nginx 作为反向 proxy 运行,您可能需要显式转发授权头,通过在 `/etc/nginx/nginx.conf`(针对您的 Zabbix 前端位置)中添加以下指令来实现:
       
       ```ini
       ...
       location / {
       ...
           proxy_set_header Authorization $http_authorization;
           proxy_pass http://backend_server;
       ...
       }
       ```更新配置后,请重启您的 Web 服务器。
       
       欲了解更多信息,请参阅:
       
       -   [ZBX-22952](https://support.zabbix.com/browse/ZBX-22952)
       -   [Apache 2.4 + PHP-FPM and Authorization headers](https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers)
       -   [SetEnvIfNoCase](https://httpd.apache.org/docs/2.4/mod/mod_setenvif.html#setenvifnocase) 和 [CGIPassAuth](https://httpd.apache.org/docs/2.4/mod/core.html#CGIPassAuth) 指令
       -   [NGINX Reverse Proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/)
       
       
       #### 在 Ubuntu 20 上使用 Chromium 运行 Zabbix web
       
       尽管在大多数情况下,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上使用MySQL安装与Zabbix配合时,Zabbix日志中可能会出现通用错误消息 *[9002] Some errors occurred*。此消息由数据库发送给Zabbix服务器或proxy。要确定错误的原因,请查阅Azure日志。
       
       
       #### 切换到 PCRE2 后正则表达式无效
       
       在 Zabbix 6.0 中添加了对 PCRE2 的支持。尽管 PCRE 仍受支持 ,但 RHEL/CentOS 7 及更高版本、SLES(所有版本)、Debian 9 及更高版本、Ubuntu 16.04 及更高版本的 Zabbix 安装包已更新为使用 PCRE2。尽管有很多好处,但是切换到 PCRE2 可能导致某些现有的 PCRE 正则表达式无效或无法正确解析。特别是 *\^[\\w-\\.]* 表达式会受影响。为了使该正则表达式再次生效且不影响语义,请将表达式更改为 *\^[-\\w\\.]* 。 这是因为 PCRE2 将破折号视为分隔符,在字符类中创建了一个范围。
       
       以下 Zabbix 安装包已更新为使用 PCRE2:RHEL/CentOS 7 及更新版本、SLES(所有版本)、Debian 9 及更新版本、Ubuntu 16.04 及更新版本。
       
       
       #### 地图小部件错误
       
       如果您从旧版Zabbix升级,使用NGINX但升级过程中未切换到新的NGINX配置文件,Geomap小部件中的地图可能无法正确加载。
       
       要解决此问题,您可以丢弃旧的配置文件,使用当前版本包中的配置文件,并按照[下载说明](https://www.zabbix.com/download?zabbix=6.0&os_distribution=red_hat_enterprise_linux&os_version=8&db=mysql&ws=nginx)中 *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;
           }
       
       
               
       #### 使用全局变量在不同Webhook调用间共享的用例
       
       由于全局变量(例如,通过`global = 1`而没有`var`,`let`或`const`声明)在不同的Webhook调用间共享,以下代码将导致标签值计数器逐渐增加:

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

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


       建议使用局部变量而不是全局变量,以确保每个脚本在其自己的数据上操作,且在同时调用间没有冲突。


       #### 升级至 TimescaleDB 后 Zabbix 服务器崩溃

       从 Zabbix 7.0.0 升级至 Zabbix 7.0.1(或更高版本)并使用 TimescaleDB 会导致服务器崩溃。此问题由 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}),则应重建该表。

       :::noteimportant
       确保 Zabbix 服务器版本至少为 7.0.1rc2(或更高版本);否则,它将再次设置错误的压缩策略。
       此外,在运行脚本前停止 Zabbix 服务器,并确认 `auditlog` 由 *zabbix* 用户拥有。
       :::

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

       ```sql
       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 数据库恢复错误

使用 pg_restore 恢复在 Zabbix 7.0.0-7.0.4 中创建的 PostgreSQL 或 TimescaleDB 备份将导致缺少 base36_decode 函数的错误,从而导致恢复失败:

ERROR:  函数 base36_decode(text) 不存在
       LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
                    ^
       HINT:  没有函数与给定的名称和参数类型匹配。您可能需要添加显式类型转换。

当使用 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上的处理器组

微软文档指出,具有少于64个逻辑处理器的系统始终 只有一个处理器组,即组0。然而,Zabbix用户报告了一个罕见的bug ZBX-20260, 在具有64个或更少逻辑处理器的系统上存在两个处理器组。这导致了 "(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字符集

地图中嵌套主机组的错误信息

地图中显示的嵌套主机组信息不正确,例如:

  • 主机组标签显示的问题概览未包含嵌套主机组中的所有主机;
  • “主机组元素”视图未为嵌套主机组中的每个主机单独显示地图元素;
  • 地图标签显示的问题总览未包括嵌套主机组中的问题。

在 7.0.7 中 LLD 规则覆盖出错

在版本 7.0.7 中,Zabbix 服务器在处理低级发现规则 覆盖 时崩溃。 作为变通方法,禁用包含覆盖的 LLD 规则。 此问题已在 Zabbix 7.0.8rc2 中修复。

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

在版本7.0.14中,当一次接收到多个值(如在日志监控期间)针对单个监控项时,Zabbix preprocessing管理器可能会导致CPU利用率过高,尤其是在配置了多个预处理工作进程的情况下。 作为临时解决方案,可以将StartPreprocessors server/proxy配置参数设置为1。 在Zabbix 7.0.15中,问题问题已得到修复。

宏函数

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

使用 MariaDB 10.5.1–10.5.9 访问 UI 元素

使用除超级管理员以外的角色访问 Zabbix Web 前端可能会导致出现以下信息:“发生系统错误。请联络 Zabbix 管理员。”。此问题影响使用 MariaDB 版本 10.5.1 至 10.5.9 的安装。

为避免此问题,将 MariaDB 更新至 10.5.9 以上版本。更多详情,请参阅 ZBX-25746

使用 tcmalloc 进行内存使用情况的剖析

如果您怀疑您的 Zabbix 安装使用了过多的内存,可以使用 tcmalloc's 内存剖析功能来调查 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
       
       使用本地文件 ./sbin/zabbix_server
       使用本地文件 ./heap_profile.0001.heap
       总计: 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 查询 [txnlev:1] [更新 alerts 设置 status=1,retries=0,error='' 其中 alertid=154618];
       1531697:20250128:064734.713 查询 [txnlev:1] [提交;]
       1531697:20250128:064734.753 [Z3005] 查询失败: [3101] 插件指示服务器回滚当前事务。 [提交;]

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

另请参阅: