Table of Contents
- 8 已知问题
- 升级
- 从 MariaDB 10.2.1 以及之前的版本升级
- 模板
- 意外安装 EPEL Zabbix 包的处理方法
- 适用于 Red Hat UBI 环境的 RHEL Zabbix 包
- 红帽企业版Linux软件包的签名密钥过期
- 与 MariaDB 的数据库 TLS 连接
- MySQL/MariaDB 可能出现的死锁
- 全局事件关联
- PostgreSQL 11 及更早版本的数据库支持的浮点数类型范围
- NetBSD 8.0 及更新版本
- Zabbix agent 2 中的正则表达式限制
- IPMI 检查
- SSH 检查
- ODBC 检查
- 监控项中的请求方法参数不正确
- Web 监控和 HTTP agent
- 简单检查
- 在无根容器中执行 fping 时出现的错误
- SNMP 检查
- SNMP 数据峰值
- SNMP trap
- Alerter 进程在 Centos/RHEL 7 中崩溃
- 升级 Zabbix Agent 2（6.0.5 或更旧版本）
- 前端区域信息错乱
- Graphs 图形
- 日志文件监控
- MySQL 慢查询
- Oracle 数据库慢配置同步
- 从链接获取的持久化过滤器设置
- SNMPv3 trap 中的 IPv6 地址问题
- 裁剪了登录失败信息中的长 IPv6 IP 地址
- Windows 的 Zabbix agent
- YAML 导出/导入
- 使用 NGINX 和 php-fpm 在 SUSE 上设置向导
- 授权头转发
- 升级至 7.0.0-7.0.4 后 PostgreSQL/TimescaleDB 数据库恢复错误
- 在Windows上的处理器组
- 使用utf8mb4排序规则过滤的限制
- 地图中嵌套主机组的错误信息
- 在 7.0.7 中 LLD 规则覆盖出错
- Zabbix 7.0.14中的预处理管理器性能 问题
- 宏函数
- 使用 MariaDB 10.5.1–10.5.9 访问 UI 元素
- 使用 tcmalloc 进行内存使用情况的剖析
- MySQL 8.0 多主模式下的 Group Replication
8 已知问题
另请参阅：编译问题.
升级
升级成功的 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 包，例如：
阻止从 EPEL 安装 Zabbix 包。在 /etc/yum.conf 文件中添加以下行：
重新安装 Zabbix server：
请注意，官方 Zabbix 包的版本字符串中包含单词 release：
适用于 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。
红帽企业版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上，运行：
然后，更新软件库信息：
更多信息，请参阅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）太小，需要执行以下命令来增加：
点击 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，例如：
这里的 "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 的系统上运行以下命令：
在基于 Debian 的系统上运行以下命令：
有关更多信息，请参阅 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。
从链接获取的持久化过滤器设置
当打开包含过滤器设置（包括时间选择器）的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 时，配置附加标志：
-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.conf3. 通过向目标进程发送信号 5 来触发剖析转储。将 1234 替换为实际进程 ID (PID)：
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 负责几乎所有的内存分配。
另请参阅：
- ZBX-25050 和 ZBX-25584 为相关问题报告。
- GCC Option Summary 关于编译选项 (
-std=gnu99,-g,-O0等)。 - Gperftools Heap Profiler 文档中关于 tcmalloc 剖析的环境变量。
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] 插件指示服务器回滚当前事务。 [提交;]此错误似乎是由涉及外键约束的回滚操作问题触发的。
另请参阅：
- ZBX-26060 有关相关问题报告。
- MySQL Bug #96758 "单节点上的外键回滚" 有关上游问题。