9 已知问题

另请参阅：编译问题。

使用 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.so 和 libOpenIPMIposix.so 库，这些库在 UBI 系统上启用的默认包管理器仓库中没有提供，这将导致安装失败。

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

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

Expired signing key for RHEL packages

When upgrading Zabbix on Red Hat Enterprise Linux or its derivatives, you may encounter an expired signing key issue for packages on Zabbix repository. When a signing key expires, attempts to verify package signatures will result in an error indicating that the certificate or key is no longer valid. For example:

error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
         1. Certificiate 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

To resolve such issues, manually reinstall the latest zabbix-release package for your specific variant of RHEL (replace the link below with the correct one from Zabbix repository).

For example, on RHEL 9, run:

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

Then, update the repository information:

dnf update

For more information, see 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 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 会导致以下错误：

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 自定义错误代码

如果在 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）。要这样做，请打开文件并找到以下块：

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

Use case with global variables shared across webhook calls

As global variables are shared across different webhook calls, the following code will result in the tag value counter gradually increasing:

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

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

Using local variables instead of global ones is recommended to make sure that each script operates on its own data and that there are no collisions between simultaneous calls.

Server crash with PostgreSQL/TimescaleDB after upgrade from 7.0

Upgrading to Zabbix 7.0.1 (or later) from Zabbix 7.0.0 with PostgreSQL/TimescaleDB results in a server crash. This issue is caused by a workaround to a compression job issue in the auditlog table in Zabbix 7.0 that irreversibly changed the compression policy of the auditlog table.

To fix the issue, please perform a manual rebuild of the auditlog table. The buggy auditlog table can be detected using this query:

SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.

If it returns a JSON object containing property compress_after (like {"hypertable_id": 14, "compress_after": 612000}) then you should rebuild the table.

The simplest way for rebuilding the auditlog table is:

    CREATE TABLE auditlog_tmp (
               LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
           );

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

See also TimescaleDB documentation for more optimized ways to migrate data.