这是原厂英文文档的翻译页面. 欢迎帮助我们 完善文档.

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)。

Timescale DB

PostgreSQL 9.6-12 在更新具有大量分区的数据表时会使用过多的内存(查看问题说明)。这个问题会在 Zabbix + TimescaleDB 结构下更新系统上的趋势表(trends)且趋势表被分成相对较小(例如 1 天)的块的情况下体现出来。这导致趋势表中存在数百个具有默认管理设置的块 —— 因此 PostgreSQL 可能会耗尽内存。

如果使用 TimescaleDB 新装 Zabbix,则这个问题从 Zabbix 5.0.1 开始已得到解决。但如果在此之前就使用 Zabbix + TimescaleDB 结构,请参阅 ZBX-16347 以获取迁移说明。

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

如果数据库表是使用 MariaDB 10.2.1 及之前的版本创建的,升级 Zabbix 可能会失败,因为在这些版本中,默认的 ROW_FORMAT(即行格式,是指数据的记录即数据行在磁盘中的物理存储方式) 是 compact。这个问题可以通过将 ROW_FORMAT 更改为 dynamic 来解决 (另请参见 ZBX-17690)。

模板

Template compatibility in dual-stack (IPv4/IPv6) environments

In dual-stack environments (systems configured to support both IPv4 and IPv6), the hostname localhost typically resolves to both IPv4 and IPv6 addresses. Due to the common prioritization of IPv6 over IPv4 by many operating systems and DNS resolvers, Zabbix templates may fail to work correctly if the service being monitored is configured to listen only on IPv4.

Services that are not configured to listen on IPv6 addresses may become inaccessible, leading to monitoring failures. Users might configure access correctly for IPv4 but still face connectivity issues due to the default behavior of prioritizing IPv6.

A workaround for this is to ensure that the services (Nginx, Apache, PostgreSQL, etc.) are configured to listen on both IPv4 and IPv6 addresses, and Zabbix server/agent is allowed access via IPv6. Additionally, in Zabbix templates and configurations, use localhost explicitly instead of 127.0.0.1 to ensure compatibility with both IPv4 and IPv6.

For example, when monitoring PostgreSQL with the PostgreSQL by Zabbix agent 2 template, you may need to edit the pg_hba.conf file to allow connections for the zbx_monitor user. If the dual-stack environment prioritizes IPv6 (system resolves localhost to ::1) and you configure localhost but only add an IPv4 entry (127.0.0.1/32), the connection will fail because there is no matching IPv6 entry.

The following pg_hba.conf file example ensures that the zbx_monitor user can connect to any database from the local machine using both IPv4 and IPv6 addresses with different authentication methods:

# 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

If necessary, you can also use the IPv4 address (127.0.0.1) directly when configuring the PostgreSQL by Zabbix agent 2 template macro for the connection string.

意外安装 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

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.2/release/rhel/9/noarch/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

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

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

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

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

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

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