9 已知问题

另请参阅：编译问题。

使用 MySQL 8.0.0-8.0.17 启动 Proxy

zabbix_proxy 在 8.0.0-8.0.17 版本的 MySQL 上启动失败并报错 “access denied” ：

  1. [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 地址：

  1. # TYPE     DATABASE     USER            ADDRESS          METHOD
  2.          host     all          zbx_monitor     localhost        trust
  3.          host     all          zbx_monitor     127.0.0.1/32     md5
  4.          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 包，例如：

  1. dnf remove zabbix-server-mysql

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

  1. exclude=zabbix7.0*

重新安装 Zabbix server：

  1. dnf install zabbix-server-mysql

请注意，官方 Zabbix 包的版本字符串中包含单词 release：

  1. 7.0.0-release1.el8

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

在 Red Hat Universal Base Image 环境中从 Red Hat Enterprise Linux (RHEL) 包安装 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 存储库上遇到软件包签名密钥过期的问题。

当签名密钥过期时，尝试验证软件包签名将导致错误，指示证书或密钥不再有效。例如：

  1. error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
  2.          1. Certificiate 19F2475308EFA7DD invalid: certificate is not alive
  3.              because: The primary key is not live
  4.              because: Expired on 2024-07-04T11:41:23Z
  5.          2. Key 19F2475308EFA7DD invalid: key is not alive
  6.              because: The primary key is not live
  7.              because: Expired on 2024-07-04T11:41:23Z

要解决此类问题，请针对你的特定 RHEL 变体手动重新安装最新的“zabbix-release”软件包（将下面的链接替换为来自Zabbix 存储库的正确链接）。

例如，在RHEL 9上，运行：

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

然后，更新存储库信息：

  1. 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）太小，需要执行以下命令来增加：

  1. 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，最好避免使用与驱动程序相同的连接器。建议设置：
  1. PostgreSQL, SQLite or Oracle connector → MariaDB or MySQL unixODBC driver
  2.        MariaDB connector → MariaDB unixODBC driver
  3.        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，例如：

  1. 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 的系统上运行以下命令：

  1. dnf remove zabbix-agent2
  2.        dnf install zabbix-agent2

在基于 Debian 的系统上运行以下命令：

  1. apt remove zabbix-agent2
  2.        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 body 和 Headers、数据库监视器项的字段 SQL query）的最大字段大小限制从 65535 字节降低到 4000 字节。 在应用补丁之前，补丁中提供了用于确定需要删除的模板名称的查询作为注释。 另外，如果设置了 MAX_STRING_SIZE，您可以在补丁查询中将 nvarchar2(4000) 更改为 nvarchar2(32767)，以设置 32767 字节的字段大小限制。

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

API 登录

使用自定义脚本方式 进行 user.login 登录而不执行 user.logout，会创建大量打开的用户会话。

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 文件。

在 Ubuntu 20 上使用 Chromium 运行 Zabbix web

尽管在大多数情况下，Zabbix Web 服务可以使用 Chromium 运行，但在 Ubuntu 20.04 上使用 Chromium 会导致以下错误：

  1. Cannot fetch data: chrome failed to start:cmd_run.go:994:
  2.        WARNING: cannot create user data directory: cannot create "/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
  3.        Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.

发生此错误是因为 /var/lib/zabbix 已经被用作用户 ‘zabbix’ 的主目录。

MySQL 自定义错误代码

如果在 Azure 上安装 Zabbix 和 MySQL，Zabbix 日志中可能会出现不明确的报错信息 [9002] Some errors occurred 。这种通用错误文本由数据库发送到 Zabbix server 或 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 及更新版本。

Geomap 小部件错误

如果您从旧版本的 Zabbix 升级，并且使用 NGINX，但在升级过程中没有切换到新的 NGINX 配置文件，则 Geomap 小部件中的地图可能无法正确加载。

要解决此问题，您可以放弃旧的配置文件，使用当前版本包中的配置文件，并按照下载说明中的e. 配置 Zabbix 前端的 PHP部分重新配置它。

或者，您可以手动编辑现有的 NGINX 配置文件（通常为 /etc/zabbix/nginx.conf）。要这样做，请打开文件并找到以下块：

  1. location ~ /(api\/|conf[^\.]|include|locale|vendor) {
  2.                deny            all;
  3.                return          404;
  4.        }

然后，将此块替换为：

  1. location ~ /(api\/|conf[^\.]|include|locale) {
  2.                deny            all;
  3.                return          404;
  4.        }
  6.        location /vendor {
  7.                deny            all;
  8.                return          404;
  9.        }

带有在 Webhook 调用间共享的全局变量的用例

由于全局变量在不同的 Webhook 调用之间共享，以下代码将导致标签值“counter”逐渐增加：

  1. try 
  2.        {
  3.           aa = aa + 1;
  4.        }
  5.        catch(e)
  6.        {
  7.           aa = 0;
  8.        }
  10.        result = {
  11.                'tags': {
  12.                    'endpoint': aa
  13.                }
  14.            };
  15.        return JSON.stringify(result);

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

从 7.0 版本升级后使用 PostgreSQL/TimescaleDB 的服务器崩溃

从 Zabbix 7.0.0 升级到 Zabbix 7.0.1（或更高版本）且使用 PostgreSQL/TimescaleDB 时，会导致服务器崩溃。此问题是由 Zabbix 7.0 中对 auditlog 表的压缩任务问题的一种变通方法引起的，该方法不可逆转地更改了 auditlog 表的压缩策略。

要解决此问题，请手动重建 auditlog 表。可以使用以下查询检测有问题的 auditlog 表：

  1. 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 版本（或更高版本）；否则它将再次设置错误的压缩策略。

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

  1. CREATE TABLE auditlog_tmp (
  2.            LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
  3.        );
  5.        SELECT create_hypertable('auditlog_tmp', 'auditid', chunk_time_interval => 604800,
  6.                time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);
  8.        WITH moved_rows AS (
  9.            DELETE FROM auditlog
  10.            RETURNING *
  11.        )
  12.        INSERT INTO auditlog_tmp
  13.        SELECT * FROM moved_rows;
  15.        DROP TABLE auditlog;
  16.        ALTER TABLE auditlog_tmp RENAME TO auditlog;

在运行脚本时，Zabbix 服务器必须停止。确保“auditlog”由“zabbix”用户拥有。

有关更优化的数据迁移方法，请参阅 TimescaleDB 文档。

:::noteclassic 由于分区所需的时间戳是使用自定义函数从“auditid”字段中提取的，因此 timescaledb-extras 中用于数据迁移的辅助过程将不起作用。