[comment]: # ({d4c2e042-97796c37})
# 8 已知问题

参见：[Compilation issues](/manual/installation/known_issues/compilation_issues)。

[comment]: # ({/d4c2e042-97796c37})

[comment]: # ({59bf15f1-ac66370d})


#### 7.0.20 版本中的已知问题

不建议升级到此version，原因如下：

-    若使用Zabbix agent 2 MySQL插件会出现CPU使用率突然飙升问题（参见[ZBX-27156](https://support.zabbix.com/browse/ZBX-27156)）
-    Zabbix主动式agent监控项的图表会因未定义索引错误显示"未定义array键"警告（参见[ZBX-27153](https://support.zabbix.com/browse/ZBX-27153)）

[comment]: # ({/59bf15f1-ac66370d})

[comment]: # ({acc59e29-60337342})
#### 升级

[comment]: # ({/acc59e29-60337342})

[comment]: # ({4128d758-9dcbc232})
##### 成功升级所需的 SQL 模式设置

MySQL/mariadb中的`sql_mode`设置必须启用"STRICT_TRANS_TABLES"模式。
若未设置此模式，Zabbix数据库升级将失败（另请参阅[ZBX-19435](https://support.zabbix.com/browse/ZBX-19435)）。

[comment]: # ({/4128d758-9dcbc232})

[comment]: # ({62592ed3-5c2a7ea7})
##### 使用MariaDB 10.2.1及更早版本升级

如果数据库表是使用mariadb 10.2.1及更早版本创建的，则升级Zabbix可能会失败，因为这些版本中的默认行格式是compact。
可以通过将行格式更改为dynamic来修复此问题（另请参阅[ZBX-17690](https://support.zabbix.com/browse/ZBX-17690)）。

[comment]: # ({/62592ed3-5c2a7ea7})

[comment]: # ({468fcd25-284cbce4})
#### 模板

[comment]: # ({/468fcd25-284cbce4})

[comment]: # ({fe6574bb-e0ea85e4})
##### 双栈(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的兼容性。

**例如**，使用[PostgreSQL by Zabbix agent 2](https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/db/postgresql_agent2?at=refs%2Fheads%2Frelease%2F7.0)模板监控PostgreSQL时，可能需要编辑`pg_hba.conf`file以允许`zbx_monitor`用户的连接。
如果双栈环境优先使用IPv6（系统将localhost解析为`::1`），而您配置了`localhost`但仅添加IPv4条目（`127.0.0.1/32`），由于缺少匹配的IPv6条目，连接将会失败。

以下`pg_hba.conf`file示例确保`zbx_monitor`用户可通过不同认证方法，使用IPv4和IPv6地址从本地机器连接任意数据库：

```ini
# 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](https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/db/postgresql_agent2?at=refs%2Fheads%2Frelease%2F7.0)模板宏的连接string时，也可直接使用IPv4地址（`127.0.0.1`）。

[comment]: # ({/fe6574bb-e0ea85e4})

[comment]: # ({56ece64f-5da64b1a})
#### EPEL Zabbix 软件包的意外安装

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

1\. 删除从 EPEL 安装的任何 Zabbix 软件包：

```bash
dnf remove zabbix-server-mysql
```

2\. 通过在 `/etc/yum.repos.d/epel.repo` 文件中添加以下行，将 Zabbix 软件包从 EPEL 中排除：

```ini
[epel]
...
excludepkgs=zabbix*
```

3\. 重新安装官方 Zabbix 服务器软件包：

```bash
dnf install zabbix-server-mysql
```

在安装过程中，官方 Zabbix 软件包的版本字符串中包含 `release` 一词（例如，`7.0.0-release1.el8`），以区别于 EPEL 软件包。

[comment]: # ({/56ece64f-5da64b1a})

[comment]: # ({16623e24-ca1706ae})
#### Red Hat UBI环境中的RHEL Zabbix包

在 [Red Hat Universal Base Image](https://catalog.redhat.com/software/base-images) 环境中从 Red Hat Enterprise Linux 软件包安装 Zabbix 时，请确保能够访问所需的仓库和依赖项。  
Zabbix 软件包依赖于 `libOpenIPMI.so` 和 `libOpenIPMIposix.so` 库，这些库在 UBI 系统上默认启用的软件包管理器仓库中无法找到，这将导致安装失败。

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

有关更多信息，请参阅 [ZBX-24291](https://support.zabbix.com/browse/ZBX-24291)。

[comment]: # ({/16623e24-ca1706ae})

[comment]: # ({ddb884e8-af503946})
#### RHEL包签名密钥过期

在[Red Hat Enterprise Linux](/manual/installation/upgrade/packages/rhel#update-repository-configuration-package)或其衍生系统上升级Zabbix时，您可能会遇到[Zabbix repository](https://repo.zabbix.com/zabbix/7.0/)上的软件包签名密钥问题过期的问题。
当签名密钥过期时，尝试验证软件包签名会导致错误，提示证书或密钥不再有效。
例如：

```bash
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <packager@zabbix.com>):
  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](https://repo.zabbix.com/zabbix/7.0/)中的正确链接）。

例如，在**RHEL 9**上，run：

```bash
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm
```
然后，update仓库信息：

```bash
dnf update
```
更多信息，请参阅[ZBX-24761](https://support.zabbix.com/browse/ZBX-24761)。

[comment]: # ({/ddb884e8-af503946})

[comment]: # ({1247e44f-40e33d04})
#### 数据库 TLS 连接与 mariadb

数据库TLS连接不支持在使用mariadb时对DBTLSConnect [parameter](/manual/appendix/config/zabbix_server)使用'verify_ca'选项

[comment]: # ({/1247e44f-40e33d04})

[comment]: # ({fa488c09-40ea4656})


#### MySQL/MariaDB可能的死锁

在高负载运行且涉及多个LLD工作进程时，可能会run陷入由InnoDB行锁策略相关的死锁错误（参见[upstream bug](https://github.com/mysql/mysql-server/commit/7037a0bdc83196755a3bf3e935cfb3c0127715d5)）。
该错误已在MySQL 8.0.29版本中修复，但mariadb中尚未解决。
更多细节请参阅[ZBX-21506](https://support.zabbix.com/browse/ZBX-21506)。

[comment]: # ({/fa488c09-40ea4656})

[comment]: # ({1ca1b80c-70c19e71})
#### 全局事件关联

如果第一个事件与第二个事件之间的时间间隔非常小（即半秒或更短），则事件可能无法get正确关联。

[comment]: # ({/1ca1b80c-70c19e71})

[comment]: # ({6c096f65-215c95a7})
#### PostgreSQL 11及更早版本的数值(浮点)数据类型范围

PostgreSQL 11及更早版本仅支持约-1.34E-154至1.34E+154的浮点数值范围

[comment]: # ({/6c096f65-215c95a7})

[comment]: # ({782693b6-dfc40df7})
#### NetBSD 8.0 及更新版本

在NetBSD 8.X和9.X版本上，各种Zabbix进程可能在启动时随机崩溃。
这是由于默认堆栈大小（4MB）过小所致，必须通过运行以下命令增加堆栈大小：

```bash
ulimit -s 10240
```
更多信息，请参阅相关问题报告：[ZBX-18275](https://support.zabbix.com/browse/ZBX-18275)。

[comment]: # ({/782693b6-dfc40df7})

[comment]: # ({9e6b7b54-ca368d3f})
#### Zabbix agent 2 中的正则表达式限制

由于标准 Go 正则表达式库的限制，Zabbix agent 2 不支持正则表达式中的前向和后向预查（lookaheads and lookbehinds）。

[comment]: # ({/9e6b7b54-ca368d3f})

[comment]: # ({153d6a2b-3cf04fe3})
#### IPMI检查

在Debian 9（stretch）之前和Ubuntu 16.04（xenial）之前的版本中，IPMI检查无法与标准的OpenIPMI库包一起工作。
要解决此问题，请按照[ZBX-6139](https://support.zabbix.com/browse/ZBX-6139)中讨论的方法重新编译启用OpenSSL的OpenIPMI库。

[comment]: # ({/153d6a2b-3cf04fe3})

[comment]: # ({4584bdf5-bcfb94d3})
#### IPMI — 不受信任的主机可能导致 OpenIPMI 崩溃

Zabbix用于轮询IPMI数据的OpenIPMI库存在一个漏洞，该漏洞可能由来自不可信设备的特制响应触发。  
不可信的IPMI设备可能发送精心构造的数据，导致OpenIPMI库崩溃，进而使得执行IPMI轮询的Zabbix server进程终止。

[comment]: # ({/4584bdf5-bcfb94d3})

[comment]: # ({aa786b9a-8c5cdd23})
#### SSH检查

-   部分Linux发行版（如Debian、Ubuntu）若通过软件包安装libssh2库，则不支持加密私钥（含密码短语）。
详情请参阅[ZBX-4850](https://support.zabbix.com/browse/ZBX-4850)。
-   在某些搭载OpenSSH 8的Linux发行版上使用libssh 0.9.x时，SSH检查可能偶发报告"Cannot read data from SSH server"错误。
该问题由libssh的[issue](https://gitlab.com/libssh/libssh-mirror/-/merge_requests/101)引发（[more detailed report](https://bugs.libssh.org/T231)）。
预计稳定版libssh 0.9.5将修复此错误。
详情参见[ZBX-17756](https://support.zabbix.com/browse/ZBX-17756)。
-   SSH脚本中使用管道符"|"可能导致"Cannot read data from SSH server"错误。
此类情况建议升级libssh库version。
详情参见[ZBX-21337](https://support.zabbix.com/browse/ZBX-21337)。

[comment]: # ({/aa786b9a-8c5cdd23})

[comment]: # ({ce3da609-0c2fc2b9})
#### ODBC 检查

-   不应将 MySQL unixODBC 驱动与使用 MariaDB connector library 编译的 Zabbix 服务器或 Zabbix proxy 一起使用，反之亦然；如果可能，也最好避免使用与驱动相同的 connector，因为存在一个 [上游 bug](https://bugs.mysql.com/bug.php?id=73709)。
建议的配置：

    PostgreSQL、SQLite 或 Oracle connector → MariaDB 或 MySQL unixODBC 驱动<br>MariaDB connector → MariaDB unixODBC 驱动<br>MySQL connector → MySQL unixODBC 驱动

    有关更多信息和可用的解决方法，请参见 [ZBX-7665](https://support.zabbix.com/browse/ZBX-7665)。

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

-   已观察到，使用针对 Linux 的各种版本 Oracle Instant Client 进行 Oracle 数据库监控的 ODBC 检查会导致 Zabbix 服务器崩溃。<br> 
另请参见：[ZBX-18402](https://support.zabbix.com/browse/ZBX-18402)、[ZBX-20803](https://support.zabbix.com/browse/ZBX-20803)。

-   如果使用 FreeTDS UnixODBC 驱动，需要在 SQL 查询前添加 'SET NOCOUNT ON' 语句（例如，````SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....````）。
否则，Zabbix 中的数据库监控项将无法检索信息，并报错
“SQL query returned empty result”。<br>
有关更多信息，请参见 [ZBX-19917](https://support.zabbix.com/browse/ZBX-19917)。

[comment]: # ({/ce3da609-0c2fc2b9})

[comment]: # ({fa40a989-1db730d3})
#### 监控项中错误的请求方法参数

请求方法参数（仅用于HTTP检查）可能被错误地设置为'1'，这是所有监控项的非默认值，这是由于从4.0版本之前的Zabbix version升级导致的。
有关如何修复此情况的详细信息，请参阅[ZBX-19308](https://support.zabbix.com/browse/ZBX-19308)。

[comment]: # ({/fa40a989-1db730d3})

[comment]: # ({6b07e4f0-4713dff4})
#### Web监控和HTTP agent

在某些Linux发行版上，当Web场景或HTTP agent中启用"SSL verify peer"时，由于[upstream bug](https://bugzilla.redhat.com/show_bug.cgi?id=1057388)问题，Zabbix server会出现memory泄漏。
更多信息及可用解决方案请参阅[ZBX-10486](https://support.zabbix.com/browse/ZBX-10486)。

[comment]: # ({/6b07e4f0-4713dff4})

[comment]: # ({5aaa698c-9cd7efe1})
#### 简单检查

在**fping** v3.10之前的版本中存在一个缺陷，该缺陷会错误处理重复的echo回复数据包。
这可能导致`icmpping`、`icmppingloss`、`icmppingsec` 监控项出现意外结果。
建议使用最新version的**fping**。
更多详情请参阅[ZBX-11726](https://support.zabbix.com/browse/ZBX-11726)。

[comment]: # ({/5aaa698c-9cd7efe1})

[comment]: # ({7d921240-49c461f1})


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

当容器以非root模式运行或在特定限制环境中时，执行ICMP检查时可能会遇到与fping执行相关的错误，例如`fping: Operation not permitted`或所有数据包到所有资源丢失的情况。

要解决此问题，请在"docker run"或"podman run"命令中添加`--cap-add=net_raw`。

此外，在非root环境中执行fping可能需要修改sysctl，例如：

```bash
sudo sysctl -w "net.ipv4.ping_group_range=0 1995"
```
其中"1995"是zabbix的GID。
更多详情，请参阅[ZBX-22833](https://support.zabbix.com/browse/ZBX-22833)。

[comment]: # ({/7d921240-49c461f1})

[comment]: # ({4356fdf8-a4574c73})
#### SNMP检查

若使用OpenBSD操作系统，Net-SNMP库5.7.3及以下版本中的version存在一个释放后使用漏洞，当在Zabbix server配置file中设置SourceIP参数时，可能导致Zabbix server崩溃。
作为临时解决方案，请勿设置SourceIP参数。
此问题同样存在于Linux系统，但不会导致Zabbix server停止工作。
OpenBSD已对net-snmp包应用本地补丁，该修复将随OpenBSD 6.3版本发布。

[comment]: # ({/4356fdf8-a4574c73})

[comment]: # ({4cdd7794-d699f9d6})
#### SNMP数据峰值

已观测到SNMP数据中的尖峰现象，可能与某些物理因素（如市电电压波动）相关。
详见[ZBX-14318](https://support.zabbix.com/browse/ZBX-14318)获取更多细节。

[comment]: # ({/4cdd7794-d699f9d6})

[comment]: # ({219609d4-7aeb682d})
#### SNMP陷阱

用于SNMP trap的"net-snmp-perl"软件包在RHEL 8.0-8.2中已被移除，在RHEL 8.3中重新加入。

因此如果您正在使用RHEL 8.0-8.2，最佳解决方案是升级到RHEL 8.3。

更多信息请参阅[ZBX-17192](https://support.zabbix.com/browse/ZBX-17192)。

[comment]: # ({/219609d4-7aeb682d})

[comment]: # ({9a52cca5-f46cb486})
#### RHEL 7中的Alerter进程崩溃

在RHEL 7系统中发现多起Zabbix server告警进程崩溃实例
详情请参阅[ZBX-10461](https://support.zabbix.com/browse/ZBX-10461)

[comment]: # ({/9a52cca5-f46cb486})

[comment]: # ({e54095e6-e9907d15})
#### 升级 Zabbix agent 2（6.0.5 或更早版本）

当从软件包升级Zabbix agent 2（version 6.0.5或更早版本）时，可能会出现与插件相关的file冲突错误。
要修复此错误，请备份您的agent 2配置（如有必要），卸载agent 2并重新安装。

在基于RHEL的系统上，run：

```bash
dnf remove zabbix-agent2
dnf install zabbix-agent2
```
在基于Debian的系统上，run：

```bash
apt remove zabbix-agent2
apt install zabbix-agent2
```
更多信息，请参阅[ZBX-23250](https://support.zabbix.com/browse/ZBX-23250)。

[comment]: # ({/e54095e6-e9907d15})

[comment]: # ({70349327-6e1fb8fe})
#### 前端语言切换

已观察到前端语言环境可能无规律切换，即某些页面（或部分页面）显示为一种语言，而其他页面（或部分页面）显示为另一种语言。
当存在多个使用不同语言环境的用户时，通常会出现此问题。

已知的临时解决方案是在PHP和Apache中禁用多线程。

该问题与语言环境设置机制[in PHP](https://www.php.net/manual/en/function.setlocale)有关：语言环境信息是按进程而非线程维护的。
因此在多线程环境中，当同一Apache进程处理多个项目run时，可能出现其他线程更改语言环境的情况，从而影响Zabbix线程中数据的处理方式。

更多信息请参阅相关问题报告：

-   [ZBX-10911](https://support.zabbix.com/browse/ZBX-10911)（前端语言环境切换问题）
-   [ZBX-16297](https://support.zabbix.com/browse/ZBX-16297)（使用BC Math函数`bcdiv`处理图形数据时出现的数值处理问题）

[comment]: # ({/70349327-6e1fb8fe})

[comment]: # ({7925147c-4f3b73ce})
#### 图形

##### 经典图形问题

如果您遇到经典图形的问题，建议将 GD 库（libgd）更新到 2.3.3-13 或更高版本，并将 PHP 更新到 8.0.19、8.1.33、8.2.29、8.3.25、8.4.12 或更高版本。

##### 夏令时

夏令时（DST）的更改会导致在显示 X 轴标签时出现异常（日期重复、日期缺失等）。

##### 求和聚合

在图形中对少于一小时的时间段使用[求和聚合](/manual/config/visualization/graphs/aggregate#configuration)时，如果数据来自趋势，图形会显示不正确的（被放大后的）值。

##### 文本重叠

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

[comment]: # ({/7925147c-4f3b73ce})

[comment]: # ({d77e6a97-357fdb5b})
#### 日志文件监控

`log[]` 和 `logrt[]` 监控项 会反复从头重读日志 file，当 file 系统空间已满100%且日志 file 正在被追加时（更多信息请参阅 [ZBX-10884](https://support.zabbix.com/browse/ZBX-10884)）。

[comment]: # ({/d77e6a97-357fdb5b})

[comment]: # ({726d79e5-82ff58c2})
#### 慢MySQL查询

Zabbix server 在 监控项 值不存在时会生成缓慢的 `SELECT` queries.
该 [issue](https://bugs.mysql.com/bug.php?id=74602) 已知会在 MySQL 5.6/5.7 版本中出现(详细讨论参见 [ZBX-10652](https://support.zabbix.com/browse/ZBX-10652)), 在特定情况下也可能出现在更高版本的 MySQL 中.
解决方法是禁用 MySQL 中的 [`index_condition_pushdown`](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html#optflag_index-condition-pushdown) 或 [`prefer_ordering_index`](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html#optflag_prefer-ordering-index) 优化器.
但需注意, 此解决方法可能无法修复所有与缓慢 queries 相关的 问题.

[comment]: # ({/726d79e5-82ff58c2})

[comment]: # ({4271402d-7ed39efb})
#### Oracle 配置同步缓慢

在具有大量监控项和监控项预处理步骤的Oracle数据库Zabbix部署中，配置同步可能会变慢。
这是由于Oracle数据库引擎处理*nclob*类型字段的速度较慢所致。

为提高性能，您可以通过手动应用数据库补丁[items_nvarchar_prepare.sql](/../assets/en/manual/installation/items_nvarchar_prepare.sql)将字段类型从*nclob*转换为*nvarchar2*。
请注意，此转换会将监控项预处理参数和监控项参数（如*Description*、脚本监控项的字段*Script*、HTTP agent 监控项的字段*Request body*和*Headers*、数据库监控监控项的字段*SQL query*）的最大字段大小限制从65535字节减少到4000字节。
补丁中提供了queries作为注释，用于确定在应用补丁前需要删除的模板名称。
或者，如果设置了MAX_STRING_SIZE，您可以在补丁queries中将*nvarchar2(4000)*更改为*nvarchar2(32767)*，以设置32767字节的字段大小限制。

如需更详细的讨论，请参阅[ZBX-22363](https://support.zabbix.com/browse/ZBX-22363)。

[comment]: # ({/4271402d-7ed39efb})

[comment]: # ({7b21750b-e6d094e6})
#### 从链接持久化过滤器设置

当打开包含筛选器设置（包括时间选择器）的Zabbix前端页面链接时，系统会自动将该筛选器保存至数据库并替换该用户此前为该页面保存的筛选器和/或时间选择器设置。
这些设置将保持有效状态，直至用户手动更新或重置它们。

[comment]: # ({/7b21750b-e6d094e6})

[comment]: # ({7e8483c4-17c4463f})
#### SNMPv3陷阱中的IPv6地址问题

由于net-snmp的一个bug，当在SNMP陷阱中使用SNMPv3时，IPv6地址可能无法正确显示。
更多详情及可能的解决方案，请参阅[ZBX-14541](https://support.zabbix.com/browse/ZBX-14541)。

[comment]: # ({/7e8483c4-17c4463f})

[comment]: # ({ca8e0df9-d77627ce})
#### 失败登录信息中截断的长IPv6地址

当login尝试失败时，系统只会显示存储IP地址的前39个字符，因为这是数据库字段的字符限制。
这意味着超过39个字符的IPv6地址将无法完整显示。

[comment]: # ({/ca8e0df9-d77627ce})

[comment]: # ({e11e57ad-57420738})
#### Windows上的Zabbix agent检查

在Zabbix agent配置文件file(zabbix\_agentd.conf)的`Server`参数中配置不存在的DNS条目可能会增加Windows平台上Zabbix agent的响应时间。
这是因为Windows DNS缓存服务不会缓存IPv4地址的否定响应。
但对于IPv6地址，否定响应会被缓存，因此可能的解决方案是在主机上禁用IPv4。

[comment]: # ({/e11e57ad-57420738})

[comment]: # ({a4766858-40001075})
#### YAML 导出/导入

YAML [export/import](/manual/xml_export_import)存在以下已知问题:

-   错误信息不可翻译
-   带有.yaml file扩展名的有效JSON有时无法导入
-   未加引号的人类可读日期会自动转换为Unix时间戳

[comment]: # ({/a4766858-40001075})

[comment]: # ({d08dcd7b-fcbf4bce})
#### SUSE 上的设置向导，使用 nginx 和 php-fpm

前端安装向导无法在SUSE系统上使用nginx + php-fpm保存配置file。
这是由于/usr/lib/systemd/system/php-fpm.service单元中的设置导致，该设置阻止了Zabbix向/etc目录写入（该问题在[PHP 7.4](https://bugs.php.net/bug.php?id=72510)中引入）。

目前有两种临时解决方案：

- 在php-fpm的systemd单元中，将[ProtectSystem](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=)选项从'full'改为'true'。
- 手动保存/etc/zabbix/web/zabbix.conf.php文件file。

[comment]: # ({/d08dcd7b-fcbf4bce})

[comment]: # ({48a90962-b776ce1f})
#### 授权头转发

在某些情况下，Apache 或 nginx 可能会阻止 API 请求中的 Authorization 标头传递到 Zabbix。
这会导致在使用 Zabbix API 或单点登录（SSO）服务（例如使用 Okta 的 SAML）时出现身份验证 问题。

为了解决这个问题，请 update 您的 Web 服务器配置。

对于 **Apache**，如果将其用作反向 proxy（非 CGI 配置），请将以下指令添加到 `/etc/httpd/conf/httpd.conf`（基于 RHEL 的系统）或 `/etc/apache2/apache2.conf`（Debian/Ubuntu）中：

```ini
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
```

如果 Apache 直接执行脚本来处理请求（例如使用 mod\_cgi），请改用添加以下指令：

```ini
CGIPassAuth On
```

相比之下，**nginx** 会自动处理 Authorization 标头。
但是，如果 nginx 作为反向 proxy 使用，则可以通过将以下指令添加到 `/etc/nginx/nginx.conf`（用于您的 Zabbix 前端位置）来显式转发 Authorization 标头：

```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/)

[comment]: # ({/48a90962-b776ce1f})

[comment]: # ({862e7b88-8009b04b})
#### Ubuntu 20 上用于 Zabbix web 服务的 Chromium

尽管在大多数情况下，Zabbix网页服务可以run与Chromium配合使用，但在Ubuntu 20.04系统上使用Chromium会导致以下错误：

```default
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'的主目录。

[comment]: # ({/862e7b88-8009b04b})

[comment]: # ({d669982d-1f99c5d8})
#### 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 server或proxy。
要确定错误原因，请查阅Azure日志。

[comment]: # ({/d669982d-1f99c5d8})

[comment]: # ({1ecb446e-eb422070})
#### Invalid regular expressions after switching to PCRE2 

Zabbix 6.0已添加对PCRE2的支持。
尽管仍支持PCRE，但针对RHEL 7及以上版本、SLES（所有版本）、Debian 9及以上版本、Ubuntu 16.04及以上版本的Zabbix安装包已更新为使用PCRE2。
虽然带来诸多优势，但切换到PCRE2可能导致某些现有PCRE正则表达式模式失效或行为异常。
特别值得注意的是，这会影响到*\^[\\w-\\.]*模式。
为使该正则表达式重新生效且不影响语义，需将表达式修改为*\^[-\\w\\.]*。
此问题的根源在于PCRE2将短横线视为分隔符，从而在字符类内部创建了一个范围。

[comment]: # ({/1ecb446e-eb422070})

[comment]: # ({17e0a154-093b78e2})
#### Geomap widget error 

如果您从旧版Zabbix version升级而来且仍使用nginx，但在升级过程中未切换至新的nginx配置file，则地理地图小部件中的地图可能无法正确加载。

要修复问题，您可以丢弃旧的配置file，使用当前version包中的配置file，并按照[download instructions](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配置file（通常位于*/etc/zabbix/nginx.conf*文件）。
为此，请打开file并找到以下代码块：

```ini
location ~ /(api\/|conf[^\.]|include|locale|vendor) {
        deny            all;
        return          404;
}
```
然后，将此块替换为：

```ini
location ~ /(api\/|conf[^\.]|include|locale) {
        deny            all;
        return          404;
}

location /vendor {
        deny            all;
        return          404;
}
```

[comment]: # ({/17e0a154-093b78e2})

[comment]: # ({f73f4f1f-4654fb6f})


#### 预处理 — 全局变量存在安全隐患

JavaScript预处理代码会在每次请求时执行，但对未声明标识符的赋值（例如`secret = value`）create会创建可能持续存在于当前执行环境之外的隐式全局变量。
将敏感数据（令牌、密码等）存储在隐式全局变量中，会增加后续预处理运行或同一环境中执行的其他集成意外暴露或重复使用的风险。

不要依赖隐式全局变量。
始终使用`var`或`const`声明变量，并避免将密钥附加到全局objects（例如`globalThis`或`window`）。
预处理代码内部没有支持的方法可以覆盖内置的全局objects。

安全示例：

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

[comment]: # ({/f73f4f1f-4654fb6f})

[comment]: # ({3a50967e-d2d024db})
#### 升级到 7.0 后，TimescaleDB 出现服务器崩溃

从Zabbix 7.0.0升级至7.0.1（或更高版本）时，若使用TimescaleDB会导致服务器崩溃。
该问题源于Zabbix 7.0中针对审计日志表压缩作业问题的临时解决方案，该方案不可逆地改变了审计日志表的压缩策略。

要修复此问题，需手动重建审计日志表。
可通过以下query检测存在问题的审计日志表：

```default
SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.
```
若返回的JSONobject包含`compress_after`属性（如{"hypertable_id": 14, "compress_after": 612000}），则需重建该表。

:::noteimportant
请确保Zabbix server版本不低于7.0.1rc2version（或更高），否则会再次设置错误的压缩策略。
此外，运行脚本前需停止Zabbix server服务，并确认`auditlog`属主为*zabbix*用户。

:::

重建审计日志表的最简方法如下：

```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 documentation](https://docs.timescale.com/self-hosted/latest/migration/same-db/)。

:::noteclassic
由于分区所需时间戳是通过自定义函数从`auditid`字段提取的，timescaledb-extras工具包中的数据迁移辅助存储过程将无法生效。

:::

[comment]: # ({/3a50967e-d2d024db})

[comment]: # ({3f0c39a4-0049c3e1})
#### 升级后出现数据库还原错误（使用 PostgreSQL/TimescaleDB）：7.0.0-7.0.4

使用[`pg_restore`](https://www.postgresql.org/docs/current/app-pgrestore.html)恢复在Zabbix 7.0.0-7.0.4中创建的PostgreSQL或TimescaleDB备份时，将出现缺失`base36_decode`函数错误，导致恢复失败：

```sql
ERROR:  function base36_decode(text) does not exist
LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
             ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
```
此错误在使用[`pg_dump`](https://www.postgresql.org/docs/current/app-pgdump.html)创建的备份进行恢复时发生。

要修复此问题，请在创建备份前替换Zabbix数据库中的`cuid_timestamp`函数（建议在运行脚本前停止PostgreSQL/TimescaleDB）：

```sql
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](https://support.zabbix.com/browse/ZBX-24955)（获取关于该错误的更多详情）和[TimescaleDB documentation](https://docs.timescale.com/self-hosted/latest/backup-and-restore/)（获取更多备份与恢复选项）。

[comment]: # ({/3f0c39a4-0049c3e1})

[comment]: # ({3cc25c44-9701964f})


#### Windows上的处理器组 {#win-proc-groups} {#win-proc-groups}

微软官方文档指出，逻辑处理器少于64个的系统通常只有一个处理器组（Group 0）。
但Zabbix用户曾报告过一个罕见错误[ZBX-20260](https://support.zabbix.com/browse/ZBX-20260)，即在逻辑处理器数量为64或更少的系统上出现两个处理器组的情况。
这导致"\Processor(n)"性能计数器仅显示两个处理器组中的一个。
该错误的确切根源尚未明确。
不过，[stackoverflow.com](https://stackoverflow.com/questions/28098082/unable-to-use-more-than-one-processor-group-for-my-threads-in-a-c-sharp-app)中描述了类似案例，其根本原因与BIOS和Windows系统的交互操作有关。

[comment]: # ({/3cc25c44-9701964f})

[comment]: # ({b8259264-e9a9a589})
#### 使用utf8mb4排序规则过滤的限制

当应用于包含某些Unicode字符（如ȼ、ɇ）的实体时，过滤器（例如在*数据收集* > [使用过滤器](/manual/web_interface/frontend_sections/data_collection/maintenance#使用过滤器)中）可能无法正常工作。
该问题是由于MySQL或mariadb数据库的默认utf8mb4\_bin排序规则处理Unicode字符排序和比较的方式所导致的。

为解决此限制，用户可以将数据库列的排序规则更改为其他选项，如utf8mb4\_0900\_bin、utf8mb4\_0900\_ai\_ci或utf8mb4\_unicode\_520\_ci。
但需注意，更改排序规则可能会导致处理空格时的意外行为，以及其他字符的排序和过滤问题。

有关更改排序规则的更多信息，请参阅[MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/alter-table.html#alter-table-character-set)或[MariaDB documentation](https://mariadb.com/kb/en/alter-database/)。
有关排序规则差异的详细信息，请参阅MySQL文档中的[Unicode Character Sets](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-sets.html)。

[comment]: # ({/b8259264-e9a9a589})

[comment]: # ({ef04ad04-6555f84a})


#### 地图中嵌套主机组信息不正确

嵌套主机组中的信息在地图中显示不正确，例如：

- 主机组标签显示的问题摘要未包含嵌套主机组中的所有主机；
- "主机组元素"视图未为嵌套主机组中的每个主机显示单独的地图元素；
- 地图标签显示所有问题的摘要，但不包括嵌套主机组中的问题。

[comment]: # ({/ef04ad04-6555f84a})

[comment]: # ({6be27fed-bc1758f9})


#### 在7.0.7中损坏的LLD规则覆盖

在version 7.0.7版本中，Zabbix server在处理低级发现规则[覆盖](/manual/discovery/low_level_discovery#覆盖)时发生崩溃。
临时解决方案是禁用包含覆盖项的LLD规则。
该问题已在Zabbix 7.0.8rc2版本中修复。

[comment]: # ({/6be27fed-bc1758f9})

[comment]: # ({40c5a82b-fd33c026})
#### Zabbix中预处理管理器性能 问题 在 Zabbix 7.0.14

在 version 7.0.14 中，当单个 监控项 一次性接收到多个值时（例如在日志监控期间），并且配置了多个预处理工作进程时，Zabbix [preprocessing](/manual/config/items/preprocessing) 管理进程可能导致高 CPU 使用率。  
作为临时解决方法，请将 `StartPreprocessors` [startpreprocessors](/manual/appendix/config/zabbix_server#startpreprocessors)/[startpreprocessors](/manual/appendix/config/zabbix_proxy#startpreprocessors) 配置参数设置为 `1`。  
该 问题 已在 Zabbix 7.0.15 中修复。

[comment]: # ({/40c5a82b-fd33c026})

[comment]: # ({7fd01df7-0b2a4404})


#### 宏函数

宏函数无法在脚本监控项参数和浏览器监控项脚本参数中使用.
该问题已在Zabbix 7.0.7中修复.

[comment]: # ({/7fd01df7-0b2a4404})

[comment]: # ({32be743a-08e30174})
#### 使用 MariaDB 10.5.1-10.5.9 访问 UI 元素

使用 Super Admin 以外的角色访问 Zabbix web frontend 时，可能会出现以下消息：“发生系统错误。
请联系 Zabbix 管理员。”。
此问题影响使用 [MariaDB 版本](/manual/installation/requirements#third-party-external-surrounding-software) 10.5.1 到 10.5.9 的安装。

为避免此问题，请将 MariaDB 更新到高于 10.5.9 的版本。
有关更多详细信息，请参见 [ZBX-25746](https://support.zabbix.com/browse/ZBX-25746)。

[comment]: # ({/32be743a-08e30174})

[comment]: # ({1b095acd-a2d54ba5})
#### 使用tcmalloc分析内存过度使用

如果您怀疑Zabbix安装使用了过多的memory，可以使用[tcmalloc's](https://github.com/google/tcmalloc)的memory分析功能来调查Zabbix server/proxy的memory消耗情况。

1\. 在安装Zabbix [from sources](/manual/installation/install#3-从源代码安装)时，配置以下附加标志：

```bash
export CFLAGS="-std=gnu99 -g -O0"
```
`-std=gnu99` flag是构建Zabbix server、Zabbix proxy或Zabbix agent所必需的。
`-g` flag会添加额外的调试信息，而`-O0`会禁用优化，这可能会干扰tcmalloc的分析功能。

2\. 在启动Zabbix server之前设置以下环境变量。
这些变量告诉tcmalloc如何跟踪和报告memory使用情况：

```bash
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)：

```bash
kill -5 1234
```
4\. 打印生成的分析报告：

```bash
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负责几乎所有memory分配。

另请参阅：

-   相关问题的报告[ZBX-25050](https://support.zabbix.com/browse/ZBX-25050)和[ZBX-25584](https://support.zabbix.com/browse/ZBX-25584)。
-   关于编译选项(`-std=gnu99`、`-g`、`-O0`等)的[GCC Option Summary](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Option-Summary.html)。
-   tcmalloc分析环境变量的[Gperftools Heap Profiler](https://gperftools.github.io/gperftools/heapprofile.html)文档。

[comment]: # ({/1b095acd-a2d54ba5})

[comment]: # ({c40b2ad1-265a3af4})
#### 多主模式下的 MySQL 8.0 Group Replication

在多主模式下使用 MySQL 8.0 Group Replication 时，您可能会在事务提交期间遇到类似以下的错误：

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

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

另请参见：

-   [ZBX-26060](https://support.zabbix.com/browse/ZBX-26060) 中的相关问题报告。
-   [MySQL Bug #96758 "Rollbacks with Foreign Keys on single node"](https://bugs.mysql.com/bug.php?id=96758) 中的上游问题。

[comment]: # ({/c40b2ad1-265a3af4})