另请参阅:编译问题。
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。
在Red Hat Enterprise Linux或其衍生版本上升级 Zabbix 时,你可能会在Zabbix 存储库上遇到软件包签名密钥过期的问题。
当签名密钥过期时,尝试验证软件包签名将导致错误,指示证书或密钥不再有效。例如:
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
要解决此类问题,请针对你的特定 RHEL 变体手动重新安装最新的“zabbix-release”软件包(将下面的链接替换为来自Zabbix 存储库的正确链接)。
例如,在RHEL 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。
使用自定义脚本方式 进行 user.login
登录而不执行 user.logout
,会创建大量打开的用户会话。
由于 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 中引入).。
有两种解决方法可供选择:
尽管在大多数情况下,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' 的主目录。
如果在 Azure 上安装 Zabbix 和 MySQL,Zabbix 日志中可能会出现不明确的报错信息 [9002] Some errors occurred 。这种通用错误文本由数据库发送到 Zabbix server 或 proxy。若要获取有关错误原因的详细信息,请查看 Azure 日志。
在 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 小部件中的地图可能无法正确加载。
要解决此问题,您可以放弃旧的配置文件,使用当前版本包中的配置文件,并按照下载说明中的e. 配置 Zabbix 前端的 PHP部分重新配置它。
或者,您可以手动编辑现有的 NGINX 配置文件(通常为 /etc/zabbix/nginx.conf)。要这样做,请打开文件并找到以下块:
然后,将此块替换为:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
由于全局变量在不同的 Webhook 调用之间共享,以下代码将导致标签值“counter”逐渐增加:
try
{
aa = aa + 1;
}
catch(e)
{
aa = 0;
}
result = {
'tags': {
'endpoint': aa
}
};
return JSON.stringify(result);
建议使用局部变量而不是全局变量,以确保每个脚本在其自己的数据上操作,并且在同时调用之间不会发生冲突。
从 Zabbix 7.0.0 升级到 Zabbix 7.0.1(或更高版本)且使用 PostgreSQL/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}),那么你应该重建该表。
确保 Zabbix 服务器至少是 7.0.1rc2 版本(或更高版本);否则它将再次设置错误的压缩策略。
重建 auditlog 表的最简单方法是:
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;
在运行脚本时,Zabbix 服务器必须停止。确保“auditlog”由“zabbix”用户拥有。
有关更优化的数据迁移方法,请参阅 TimescaleDB 文档。
:::noteclassic 由于分区所需的时间戳是使用自定义函数从“auditid”字段中提取的,因此 timescaledb-extras 中用于数据迁移的辅助过程将不起作用。