另请参阅:编译问题.
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';
在 MySQL/MariaDB 中,必须设置 "STRICT_TRANS_TABLES" 模式的 sql_mode
设置。如果缺少此设置,Zabbix 数据库升级将失败(另请参阅 ZBX-19435)。
如果数据库表是使用 MariaDB 10.2.1 及之前的版本创建的,升级 Zabbix 可能会失败,因为在这些版本中,默认的 ROW_FORMAT(即行格式,是指数据的记录即数据行在磁盘中的物理存储方式) 是 compact。这个问题可以通过将 ROW_FORMAT 更改为 dynamic 来解决 (另请参见 ZBX-17690)。
在双栈环境(系统配置为同时支持 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 包而不是官方 Zabbix 包。
在这种情况下,需要卸载 EPEL 中的 Zabbix 包,例如:
阻止从 EPEL 安装 Zabbix 包。在 /etc/yum.conf
文件中添加以下行:
重新安装 Zabbix server:
请注意,官方 Zabbix 包的版本字符串中包含单词 release
:
在 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或其衍生系统上升级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 数据库,则 DBTLSConnect 参数 的 “verify_ca” 选项不支持数据库 TLS 连接。
当在高负载下运行,并且涉及多个 LLD worker 时,可能会遇到由 与行锁定策略相关的 InnoDB 错误(参见 上游错误)。 从 8.0.29 开始,该错误在 MySQL 中已修复,但在 MariaDB 中未修复。 有关详细信息,请参阅 ZBX-21506。
如果第一个事件和第二个事件之间的时间间隔非常小,即半秒或更短,事件可能无法正确关联。
PostgreSQL 11 及更早版本仅支持大约 -1.34E-154 到 1.34E+154 的浮点数范围。
在 NetBSD 8.X 和 9.X 上, Zabbix 各种进程可能会在启动时随机崩溃。这是由于默认堆栈大小(4MB)太小,需要执行以下命令来增加:
点击 ZBX-18275 查看相关问题报告。
由于标准的 Go regexp 库的限制,Zabbix agent 2 不支持正向预查和反向预查功能。
用 Debian 9 (stretch) 和 Ubuntu 16.04 (xenial) 之前版本的标准 OpenIPMI 库包运行 IPMI 检查会无法正常运行。要解决此问题,请重新编译 OpenIPMI 库并启用 OpenSSL,参考 ZBX-6139。
· - 如果 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。
PostgreSQL, SQLite or Oracle connector → MariaDB or MySQL unixODBC driver
MariaDB connector → MariaDB unixODBC driver
MySQL connector → MySQL unixODBC driver
请参阅 ZBX-7665 了解更多信息和可用的解决方案。
在 HTTP 检查中使用的 request_method 参数可能被错误地设置为 “1”,监控项的非默认值是由于从 Zabbix 4.0 之前的版本升级造成的。点击 ZBX-19308 查看解决方法。
由于 上游 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 。
当容器以无根模式或在受限环境中运行时,执行 ICMP 检查时可能会遇到与 fping 执行相关的错误,例如 fping: Operation not permitted
或所有资源的所有数据包丢失。
要解决这个问题,请将 --cap-add=net_raw
添加到 "docker run" 或 "podman run" 命令中。
此外,在非根环境中执行 fping 可能需要修改 sysctl,例如:
这里的 "1995" 是 zabbix GID。有关更多详细信息,请参阅 ZBX-22833。
对于 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 监控数据中的峰值可能与某些物理因素有关,如电源中的电压峰值。详情点击 ZBX-14318。
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 。
在 Centos/RHEL 7 中遇到了 Zabbix server 的 alerter 进程崩溃的情况。有关详细信息,请参阅 ZBX-10461 。
在升级 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)
更改为夏令时 (DST) 会导致显示 X 轴标签时出现异常(例如日期重复、日期缺失等)。
如果文件系统达到 100% 并且日志正在追加,则 log[]
和 logrt[]
监控项会从头重读日志文件,(参阅 ZBX-10884 )获取更多。
如果监控项的值不存在,Zabbix server 会生成慢查询。这是由MySQL 5.6/5.7 版本中的一个已知 问题 引起的。解决方法是禁用 MySQL 中的 index_condition_pushdown optimizer。详情参阅 ZBX-10652。
在具有大量项目和项目预处理步骤的 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前端页面链接时,过滤器会自动为用户保存在数据库中,替换之前保存的该页面的过滤器和/或时间选择器设置。这些设置将保持有效,直到用户手动更新或重置它们。
由于 net-snmp bug,在 SNMP trap 中使用 SNMPv3 时可能无法正确显示 IPv6 地址。有关更多详细信息和可能的解决方法,请参阅 ZBX-14541。
登录失败的消息将仅显示存储的 IP 地址的前 39 个字符,这是由于数据库字段中的字符限制。这意味着超过 39 个字符的 IPv6 IP 地址将不能完整显示。
Zabbix agent 配置文件 (zabbix_agentd.conf) 中设置非 DNS 性质的 Server
参数可能会增加 Windows 上 Zabbix agent 的响应时间。发生这种情况是因为 Windows DNS 缓存守护程序不会缓存 IPv4 地址的否定响应。但是会缓存 IPv6 地址的否定响应,因此可能的解决方法是在主机上禁用 IPv4。
YAML 导出/导入 存在一些已知问题:
在 SUSE 上使用 NGINX + php-fpm,前端设置向导将无法保存配置文件。这是由 /usr/lib/systemd/system/php-fpm.service 单元中的设置引起的,该设置阻止 Zabbix 写入 /etc。 (在 PHP 7.4 中引入).。
有两种解决方法可供选择:
在某些情况下,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 中用于数据迁移的辅助过程将无法工作。
使用 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 文档(有关其他备份和恢复选项)。
微软文档指出,具有少于64个逻辑处理器的系统始终 只有一个处理器组,即组0。然而,Zabbix用户报告了一个罕见的bug ZBX-20260, 在具有64个或更少逻辑处理器的系统上存在两个处理器组。这导致了 "(n)"性能计数器只对两个处理器组中的一个有效。这个bug的实际根本原因 未知。然而,一个类似的情况在 stackoverflow.com, 中被描述,那里的根本原因是BIOS和Windows之间的交互操作。
在过滤器中(例如,在数据收集 → 维护中),当应用于包含某些Unicode字符的实体(例如,ȼ, ɇ)时,可能无法正确工作。 此问题源于MySQL或MariaDB数据库的默认utf8mb4_bin排序规则在处理Unicode字符的排序和比较时的方式。
为了解决这一限制,用户可以将数据库列的排序规则更改为其他选项,如utf8mb4_0900_bin, utf8mb4_0900_ai_ci,或utf8mb4_unicode_520_ci。 然而,需要注意的是,更改排序规则可能会导致处理空格时出现意外行为,以及对其他字符的排序和过滤产生影响。
有关更改排序规则的更多信息,请参阅MySQL文档或MariaDB文档。 关于排序规则差异的详细信息,请参阅MySQL文档中的Unicode字符集。
地图中显示的嵌套主机组信息不正确,例如:
在版本 7.0.7 中,Zabbix 服务器在处理低级发现规则 覆盖 时崩溃。 作为变通方法,禁用包含覆盖的 LLD 规则。 此问题已在 Zabbix 7.0.8rc2 中修复。
在版本7.0.14中,当一次接收到多个值(如在日志监控期间)针对单个监控项时,Zabbix preprocessing管理器可能会导致CPU利用率过高,尤其是在配置了多个预处理工作进程的情况下。 作为临时解决方案,可以将StartPreprocessors
server/proxy配置参数设置为1
。 在Zabbix 7.0.15中,问题问题已得到修复。
宏函数在脚本监控项参数和浏览器监控项的脚本参数中不起作用。此问题已在Zabbix 7.0.7中修复。
使用除超级管理员以外的角色访问 Zabbix Web 前端可能会导致出现以下信息:“发生系统错误。请联络 Zabbix 管理员。”。此问题影响使用 MariaDB 版本 10.5.1 至 10.5.9 的安装。
为避免此问题,将 MariaDB 更新至 10.5.9 以上版本。更多详情,请参阅 ZBX-25746。
如果您怀疑您的 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.conf
3. 通过向目标进程发送信号 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 负责几乎所有的内存分配。
另请参阅:
-std=gnu99
, -g
, -O0
等)。在使用 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] 插件指示服务器回滚当前事务。 [提交;]
此错误似乎是由涉及外键约束的回滚操作问题触发的。
另请参阅: