Documentation
Table of Contents
- 8 已知问题
- 7.0.20 版本中的已知问题
- 升级
- 模板
- 意外安装 EPEL Zabbix 软件包
- Red Hat UBI环境中的RHEL Zabbix包
- RHEL包签名密钥过期
- 数据库 TLS 连接与 mariadb
- MySQL/MariaDB可能的死锁
- 全局事件关联
- PostgreSQL 11及更早版本的数值(浮点)数据类型范围
- NetBSD 8.0 及更新版本
- Zabbix agent 2 中的正则表达式限制
- IPMI检查
- IPMI — 不受信任的主机可能导致 OpenIPMI 崩溃
- SSH检查
- ODBC检查
- 监控项中错误的请求方法参数
- Web监控和HTTP agent
- 简单检查
- 无 root 权限容器中 fping 执行的错误
- SNMP检查
- SNMP数据峰值
- SNMP陷阱
- RHEL 7中的Alerter进程崩溃
- 升级 Zabbix agent 2（6.0.5 或更早版本）
- 前端语言切换
- 图形
- 日志文件监控
- 慢MySQL查询
- Oracle 配置同步缓慢
- 从链接持久化过滤器设置
- SNMPv3陷阱中的IPv6地址问题
- 失败登录信息中截断的长IPv6地址
- Windows上的Zabbix agent检查
- YAML 导出/导入
- SUSE 上的设置向导，使用 nginx 和 php-fpm
- 授权头转发
- Ubuntu 20 上用于 Zabbix web 服务的 Chromium
- MySQL自定义错误代码
- Invalid regular expressions after switching to PCRE2
- Geomap widget error
- 预处理 — 全局变量存在安全隐患
- 升级到 7.0 后，TimescaleDB 出现服务器崩溃
- 升级后出现数据库还原错误（使用 PostgreSQL/TimescaleDB）：7.0.0-7.0.4
- Windows上的处理器组 {#win-proc-groups}
- 使用utf8mb4排序规则过滤的限制
- 地图中嵌套主机组信息不正确
- 在7.0.7中损坏的LLD规则覆盖
- Zabbix中预处理管理器性能 问题 在 Zabbix 7.0.14
- 宏函数
- MariaDB 10.5.1-10.5.9对UI元素的访问
- 使用tcmalloc分析内存过度使用
- MySQL 8.0多主模式下的组复制
8 已知问题
7.0.20 版本中的已知问题
不建议升级到此version，原因如下：
- 若使用Zabbix agent 2 MySQL插件会出现CPU使用率突然飙升问题（参见ZBX-27156）
- Zabbix主动式agent监控项的图表会因未定义索引错误显示"未定义array键"警告（参见ZBX-27153）
升级
成功升级所需的 SQL 模式设置
MySQL/mariadb中的sql_mode设置必须启用"STRICT_TRANS_TABLES"模式。 若未设置此模式，Zabbix数据库升级将失败（另请参阅ZBX-19435）。
使用MariaDB 10.2.1及更早版本升级
如果数据库表是使用mariadb 10.2.1及更早版本创建的，则升级Zabbix可能会失败，因为这些版本中的默认行格式是compact。 可以通过将行格式更改为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的兼容性。
例如，使用PostgreSQL by Zabbix agent 2模板监控PostgreSQL时，可能需要编辑pg_hba.conffile以允许zbx_monitor用户的连接。 如果双栈环境优先使用IPv6（系统将localhost解析为::1），而您配置了localhost但仅添加IPv4条目（127.0.0.1/32），由于缺少匹配的IPv6条目，连接将会失败。
以下pg_hba.conffile示例确保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必要时，在配置PostgreSQL by Zabbix agent 2模板宏的连接string时，也可直接使用IPv4地址（127.0.0.1）。
意外安装 EPEL Zabbix 软件包
如果已安装并启用了EPEL仓库，安装Zabbix软件包时可能会拉取EPEL版本而非官方Zabbix软件包。 解决方法如下：
1. 移除所有通过EPEL安装的Zabbix软件包：
2. 通过将以下行添加至/etc/yum.conf file来排除EPEL中的Zabbix软件包：
3. 重新安装官方Zabbix server软件包：
官方Zabbix软件包在安装时，其version string中包含release字样（例如7.0.0-release1.el8），以此与EPEL软件包区分。
Red Hat UBI环境中的RHEL Zabbix包
在 Red Hat Universal Base Image 环境中从 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。
RHEL包签名密钥过期
在Red Hat Enterprise Linux或其衍生系统上升级Zabbix时，您可能会遇到Zabbix repository上的软件包签名密钥问题过期的问题。 当签名密钥过期时，尝试验证软件包签名会导致错误，提示证书或密钥不再有效。 例如：
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
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中的正确链接）。
例如，在RHEL 9上，run：
然后，update仓库信息：
更多信息，请参阅ZBX-24761。
数据库 TLS 连接与 mariadb
数据库TLS连接不支持在使用mariadb时对DBTLSConnect parameter使用'verify_ca'选项
MySQL/MariaDB可能的死锁
在高负载运行且涉及多个LLD工作进程时，可能会run陷入由InnoDB行锁策略相关的死锁错误（参见upstream bug）。 该错误已在MySQL 8.0.29版本中修复，但mariadb中尚未解决。 更多细节请参阅ZBX-21506。
全局事件关联
如果第一个事件与第二个事件之间的时间间隔非常小（即半秒或更短），则事件可能无法get正确关联。
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 正则表达式库的限制，Zabbix agent 2 不支持正则表达式中的前向和后向预查（lookaheads and lookbehinds）。
IPMI检查
在Debian 9（stretch）之前和Ubuntu 16.04（xenial）之前的版本中，IPMI检查无法与标准的OpenIPMI库包一起工作。 要解决此问题，请按照ZBX-6139中讨论的方法重新编译启用OpenSSL的OpenIPMI库。
IPMI — 不受信任的主机可能导致 OpenIPMI 崩溃
Zabbix用于轮询IPMI数据的OpenIPMI库存在一个漏洞，该漏洞可能由来自不可信设备的特制响应触发。
不可信的IPMI设备可能发送精心构造的数据，导致OpenIPMI库崩溃，进而使得执行IPMI轮询的Zabbix server进程终止。
SSH检查
- 部分Linux发行版（如Debian、Ubuntu）若通过软件包安装libssh2库，则不支持加密私钥（含密码短语）。 详情请参阅ZBX-4850。
- 在某些搭载OpenSSH 8的Linux发行版上使用libssh 0.9.x时，SSH检查可能偶发报告"Cannot read data from SSH server"错误。 该问题由libssh的issue引发（more detailed report）。 预计稳定版libssh 0.9.5将修复此错误。 详情参见ZBX-17756。
- SSH脚本中使用管道符"|"可能导致"Cannot read data from SSH server"错误。 此类情况建议升级libssh库version。 详情参见ZBX-21337。
ODBC检查
- 不应将MySQL unixODBC驱动与基于mariadb连接器库编译的Zabbix server或Zabbix proxy混用，反之亦然。由于upstream bug问题，也应尽量避免使用与驱动相同的连接器。 推荐配置方案：
PostgreSQL、SQLite或Oracle连接器 → mariadb或MySQL unixODBC驱动 mariadb连接器 → mariadb unixODBC驱动 MySQL连接器 → MySQL unixODBC驱动
更多信息及可用解决方案请参阅ZBX-7665。
从Microsoft SQL Server查询的XML数据在Linux和UNIX系统上可能get以多种方式被截断。
已发现使用ODBC检查监控Oracle数据库时，若采用不同版本的Oracle Instant Client for Linux会导致Zabbix server崩溃。 另请参阅：ZBX-18402、ZBX-20803。
若使用FreeTDS UnixODBC驱动，需在SQLquery前添加'SET NOCOUNT ON'语句（例如
SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....）。否则Zabbix中的数据库监控监控项将因错误"SQLquery返回空结果"而无法获取信息。
更多详情参见ZBX-19917。
监控项中错误的请求方法参数
请求方法参数（仅用于HTTP检查）可能被错误地设置为'1'，这是所有监控项的非默认值，这是由于从4.0版本之前的Zabbix version升级导致的。 有关如何修复此情况的详细信息，请参阅ZBX-19308。
Web监控和HTTP agent
在某些Linux发行版上，当Web场景或HTTP agent中启用"SSL verify peer"时，由于upstream bug问题，Zabbix server会出现memory泄漏。 更多信息及可用解决方案请参阅ZBX-10486。
简单检查
在fping v3.10之前的版本中存在一个缺陷，该缺陷会错误处理重复的echo回复数据包。 这可能导致icmpping、icmppingloss、icmppingsec 监控项出现意外结果。 建议使用最新version的fping。 更多详情请参阅ZBX-11726。
无 root 权限容器中 fping 执行的错误
当容器以非root模式运行或在特定限制环境中时，执行ICMP检查时可能会遇到与fping执行相关的错误，例如fping: Operation not permitted或所有数据包到所有资源丢失的情况。
要解决此问题，请在"docker run"或"podman run"命令中添加--cap-add=net_raw。
此外，在非root环境中执行fping可能需要修改sysctl，例如：
其中"1995"是zabbix的GID。 更多详情，请参阅ZBX-22833。
SNMP检查
若使用OpenBSD操作系统，Net-SNMP库5.7.3及以下版本中的version存在一个释放后使用漏洞，当在Zabbix server配置file中设置SourceIP参数时，可能导致Zabbix server崩溃。 作为临时解决方案，请勿设置SourceIP参数。 此问题同样存在于Linux系统，但不会导致Zabbix server停止工作。 OpenBSD已对net-snmp包应用本地补丁，该修复将随OpenBSD 6.3版本发布。
SNMP数据峰值
已观测到SNMP数据中的尖峰现象，可能与某些物理因素（如市电电压波动）相关。 详见ZBX-14318获取更多细节。
SNMP陷阱
用于SNMP trap的"net-snmp-perl"软件包在RHEL 8.0-8.2中已被移除，在RHEL 8.3中重新加入。
因此如果您正在使用RHEL 8.0-8.2，最佳解决方案是升级到RHEL 8.3。
更多信息请参阅ZBX-17192。
RHEL 7中的Alerter进程崩溃
在RHEL 7系统中发现多起Zabbix server告警进程崩溃实例 详情请参阅ZBX-10461
升级 Zabbix agent 2（6.0.5 或更早版本）
当从软件包升级Zabbix agent 2（version 6.0.5或更早版本）时，可能会出现与插件相关的file冲突错误。 要修复此错误，请备份您的agent 2配置（如有必要），卸载agent 2并重新安装。
在基于RHEL的系统上，run：
在基于Debian的系统上，run：
更多信息，请参阅ZBX-23250。
前端语言切换
已观察到前端语言环境可能无规律切换，即某些页面（或部分页面）显示为一种语言，而其他页面（或部分页面）显示为另一种语言。 当存在多个使用不同语言环境的用户时，通常会出现此问题。
已知的临时解决方案是在PHP和Apache中禁用多线程。
该问题与语言环境设置机制in PHP有关：语言环境信息是按进程而非线程维护的。 因此在多线程环境中，当同一Apache进程处理多个项目run时，可能出现其他线程更改语言环境的情况，从而影响Zabbix线程中数据的处理方式。
更多信息请参阅相关问题报告：
图形
夏令时
夏令时(DST)变更会导致X轴标签显示异常(日期重复、日期缺失等).
求和聚合
当在不足一小时的周期图表中使用配置时,若数据来自趋势数据,图表会显示错误(翻倍)的数值.
文本重叠
某些前端语言(如日语)使用本地字体可能导致图表图例中的文本重叠. 为避免此问题,请使用PHP GD扩展的version 2.3.0或更高版本.
日志文件监控
log[] 和 logrt[] 监控项 会反复从头重读日志 file，当 file 系统空间已满100%且日志 file 正在被追加时（更多信息请参阅 ZBX-10884）。
慢MySQL查询
Zabbix server 在 监控项 值不存在时会生成缓慢的 SELECT queries. 该 issue 已知会在 MySQL 5.6/5.7 版本中出现(详细讨论参见 ZBX-10652), 在特定情况下也可能出现在更高版本的 MySQL 中. 解决方法是禁用 MySQL 中的 index_condition_pushdown 或 prefer_ordering_index 优化器. 但需注意, 此解决方法可能无法修复所有与缓慢 queries 相关的 问题.
Oracle 配置同步缓慢
在具有大量监控项和监控项预处理步骤的Oracle数据库Zabbix部署中，配置同步可能会变慢。 这是由于Oracle数据库引擎处理nclob类型字段的速度较慢所致。
为提高性能，您可以通过手动应用数据库补丁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。
从链接持久化过滤器设置
当打开包含筛选器设置（包括时间选择器）的Zabbix前端页面链接时，系统会自动将该筛选器保存至数据库并替换该用户此前为该页面保存的筛选器和/或时间选择器设置。 这些设置将保持有效状态，直至用户手动更新或重置它们。
SNMPv3陷阱中的IPv6地址问题
由于net-snmp的一个bug，当在SNMP陷阱中使用SNMPv3时，IPv6地址可能无法正确显示。 更多详情及可能的解决方案，请参阅ZBX-14541。
失败登录信息中截断的长IPv6地址
当login尝试失败时，系统只会显示存储IP地址的前39个字符，因为这是数据库字段的字符限制。 这意味着超过39个字符的IPv6地址将无法完整显示。
Windows上的Zabbix agent检查
在Zabbix agent配置文件file(zabbix_agentd.conf)的Server参数中配置不存在的DNS条目可能会增加Windows平台上Zabbix agent的响应时间。 这是因为Windows DNS缓存服务不会缓存IPv4地址的否定响应。 但对于IPv6地址，否定响应会被缓存，因此可能的解决方案是在主机上禁用IPv4。
YAML 导出/导入
YAML export/import存在以下已知问题:
- 错误信息不可翻译
- 带有.yaml file扩展名的有效JSON有时无法导入
- 未加引号的人类可读日期会自动转换为Unix时间戳
SUSE 上的设置向导，使用 nginx 和 php-fpm
前端安装向导无法在SUSE系统上使用nginx + php-fpm保存配置file。 这是由于/usr/lib/systemd/system/php-fpm.service单元中的设置导致，该设置阻止了Zabbix向/etc目录写入（该问题在PHP 7.4中引入）。
目前有两种临时解决方案：
- 在php-fpm的systemd单元中，将ProtectSystem选项从'full'改为'true'。
- 手动保存/etc/zabbix/web/zabbix.conf.php文件file。
授权头转发
在某些情况下，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）中：
如果 Apache 直接执行脚本来处理请求（例如使用 mod_cgi），请改用添加以下指令：
相比之下，nginx 会自动处理 Authorization 标头。 但是，如果 nginx 作为反向 proxy 使用，则可以通过将以下指令添加到 /etc/nginx/nginx.conf（用于您的 Zabbix 前端位置）来显式转发 Authorization 标头：
...
location / {
...
proxy_set_header Authorization $http_authorization;
proxy_pass http://backend_server;
...
}更新配置后，请重启您的 Web 服务器。
有关更多详细信息，请参阅：
- ZBX-22952
- Apache 2.4 + PHP-FPM and Authorization headers
- SetEnvIfNoCase 和 CGIPassAuth 指令
- NGINX Reverse Proxy
Ubuntu 20 上用于 Zabbix web 服务的 Chromium
尽管在大多数情况下，Zabbix网页服务可以run与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 server或proxy。 要确定错误原因，请查阅Azure日志。
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将短横线视为分隔符，从而在字符类内部创建了一个范围。
Geomap widget error
如果您从旧版Zabbix version升级而来且仍使用nginx，但在升级过程中未切换至新的nginx配置file，则地理地图小部件中的地图可能无法正确加载。
要修复问题，您可以丢弃旧的配置file，使用当前version包中的配置file，并按照download instructions中e. 为Zabbix前端配置PHP章节所述重新配置。
或者，您可以手动编辑现有的nginx配置file（通常位于/etc/zabbix/nginx.conf文件）。 为此，请打开file并找到以下代码块：
然后，将此块替换为：
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}预处理 — 全局变量存在安全隐患
JavaScript预处理代码会在每次请求时执行，但对未声明标识符的赋值（例如secret = value）create会创建可能持续存在于当前执行环境之外的隐式全局变量。 将敏感数据（令牌、密码等）存储在隐式全局变量中，会增加后续预处理运行或同一环境中执行的其他集成意外暴露或重复使用的风险。
不要依赖隐式全局变量。 始终使用var或const声明变量，并避免将密钥附加到全局objects（例如globalThis或window）。 预处理代码内部没有支持的方法可以覆盖内置的全局objects。
安全示例：
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });升级到 7.0 后，TimescaleDB 出现服务器崩溃
从Zabbix 7.0.0升级至7.0.1（或更高版本）时，若使用TimescaleDB会导致服务器崩溃。 该问题源于Zabbix 7.0中针对审计日志表压缩作业问题的临时解决方案，该方案不可逆地改变了审计日志表的压缩策略。
要修复此问题，需手动重建审计日志表。 可通过以下query检测存在问题的审计日志表：
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}），则需重建该表。
请确保Zabbix server版本不低于7.0.1rc2version（或更高），否则会再次设置错误的压缩策略。 此外，运行脚本前需停止Zabbix server服务，并确认auditlog属主为zabbix用户。
重建审计日志表的最简方法如下：
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。
由于分区所需时间戳是通过自定义函数从auditid字段提取的，timescaledb-extras工具包中的数据迁移辅助存储过程将无法生效。
升级后出现数据库还原错误（使用 PostgreSQL/TimescaleDB）：7.0.0-7.0.4
使用pg_restore恢复在Zabbix 7.0.0-7.0.4中创建的PostgreSQL或TimescaleDB备份时，将出现缺失base36_decode函数错误，导致恢复失败：
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创建的备份进行恢复时发生。
要修复此问题，请在创建备份前替换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 documentation（获取更多备份与恢复选项）。
Windows上的处理器组 {#win-proc-groups}
微软官方文档指出，逻辑处理器少于64个的系统通常只有一个处理器组（Group 0）。 但Zabbix用户曾报告过一个罕见错误ZBX-20260，即在逻辑处理器数量为64或更少的系统上出现两个处理器组的情况。 这导致"(n)"性能计数器仅显示两个处理器组中的一个。 该错误的确切根源尚未明确。 不过，stackoverflow.com中描述了类似案例，其根本原因与BIOS和Windows系统的交互操作有关。
使用utf8mb4排序规则过滤的限制
当应用于包含某些Unicode字符（如ȼ、ɇ）的实体时，过滤器（例如在数据收集 > 使用过滤器中）可能无法正常工作。 该问题是由于MySQL或mariadb数据库的默认utf8mb4_bin排序规则处理Unicode字符排序和比较的方式所导致的。
为解决此限制，用户可以将数据库列的排序规则更改为其他选项，如utf8mb4_0900_bin、utf8mb4_0900_ai_ci或utf8mb4_unicode_520_ci。 但需注意，更改排序规则可能会导致处理空格时的意外行为，以及其他字符的排序和过滤问题。
有关更改排序规则的更多信息，请参阅MySQL documentation或MariaDB documentation。 有关排序规则差异的详细信息，请参阅MySQL文档中的Unicode Character Sets。
地图中嵌套主机组信息不正确
嵌套主机组中的信息在地图中显示不正确，例如：
- 主机组标签显示的问题摘要未包含嵌套主机组中的所有主机；
- "主机组元素"视图未为嵌套主机组中的每个主机显示单独的地图元素；
- 地图标签显示所有问题的摘要，但不包括嵌套主机组中的问题。
在7.0.7中损坏的LLD规则覆盖
在version 7.0.7版本中，Zabbix server在处理低级发现规则覆盖时发生崩溃。 临时解决方案是禁用包含覆盖项的LLD规则。 该问题已在Zabbix 7.0.8rc2版本中修复。
Zabbix中预处理管理器性能 问题 在 Zabbix 7.0.14
在 version 7.0.14 中，当单个 监控项 一次性接收到多个值时（例如在日志监控期间），并且配置了多个预处理工作进程时，Zabbix preprocessing 管理进程可能导致高 CPU 使用率。
作为临时解决方法，请将 StartPreprocessors startpreprocessors/startpreprocessors 配置参数设置为 1。
该 问题 已在 Zabbix 7.0.15 中修复。
宏函数
宏函数无法在脚本监控项参数和浏览器监控项脚本参数中使用. 该问题已在Zabbix 7.0.7中修复.
MariaDB 10.5.1-10.5.9对UI元素的访问
使用非超级管理员角色访问Zabbix前端时可能出现提示："系统错误发生. 请联系Zabbix管理员". 该问题影响使用第三方外部配套软件 10.5.1至10.5.9版本的安装环境.
为避免此问题, 请update mariadb至version 10.5.9以上版本. 更多详情请参阅ZBX-25746.
使用tcmalloc分析内存过度使用
如果您怀疑Zabbix安装使用了过多的memory，可以使用tcmalloc's的memory分析功能来调查Zabbix server/proxy的memory消耗情况。
1. 在安装Zabbix from sources时，配置以下附加标志：
-std=gnu99 flag是构建Zabbix server、Zabbix proxy或Zabbix agent所必需的。 -g flag会添加额外的调试信息，而-O0会禁用优化，这可能会干扰tcmalloc的分析功能。
2. 在启动Zabbix server之前设置以下环境变量。 这些变量告诉tcmalloc如何跟踪和报告memory使用情况：
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
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和ZBX-25584。
- 关于编译选项(
-std=gnu99、-g、-O0等)的GCC Option Summary。 - tcmalloc分析环境变量的Gperftools Heap Profiler文档。
MySQL 8.0多主模式下的组复制
当在多主模式下使用MySQL 8.0组复制时，您可能会在事务提交期间遇到类似以下错误：
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 查看相关问题报告。
- MySQL Bug #96758 "Rollbacks with Foreign Keys on single node" 查看上游问题。