参照: コンパイルの問題
Zabbix 6.4.0rc1 (rc1 = Release Candidate 1) does not support template nesting (restored in 6.4.0rc2). If you have upgraded to Zabbix 6.4.0rc1, a DB patch will convert all nested templates into a flat template structure. This means that all entities (items, triggers, etc.) from nested templates will be transferred to the template that contained these nested templates. The support for template nesting has been fully restored in Zabbix 6.4.0rc2. However, if you have already upgraded to Zabbix 6.4.0rc1, the previously existing template structure will not be recovered. :::
MySQLのバージョン8.0.0-8.0.17上でzabbix_proxyを実行する際、以下のような"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では、この動作は削除されました: As of MySQL 8.0.18, setting the session value of this system variable is no longer a restricted operation.
回避策としては、zabbix
ユーザーに権限を与えます:
MySQLバージョン8.0.14 - 8.0.17の場合:
MySQLバージョン8.0.0 - 8.0.13の場合:
PostgreSQL バージョン 9.6 ~ 12 は、多数のパーティションを含むテーブルを更新するときに大量のメモリを使用します (問題レポートを参照)。 この問題は、トレンドが比較的小さな (1 日など) チャンクに分割されている場合に、Zabbix が TimescaleDB を備えたシステムでトレンドを更新するときに発生します。 これにより、デフォルトのハウスキーピング設定でトレンド テーブルに何百ものチャンクが存在することになり、PostgreSQL がメモリ不足になる可能性があります。
この問題はZabbix 5.0.1以降のTimescaleDBを使用した新規インストールでは解決されていますが、それ以前に TimescaleDB を Zabbix でセットアップした場合は、移行に関する注意事項ZBX-16347 を参照してください。 #### Timescale DB 2.5.0: 整数を含むテーブルで圧縮ポリシーが失敗する可能性がある
この問題は、TimescaleDB 2.5.0 が使用されている場合に発生します。 TimescaleDB 2.5.1 以降では解決されています。
詳細については、TimescaleDB Issue #3773 を参照してください。
The sql_mode
setting in MySQL/MariaDB must have the "STRICT_TRANS_TABLES" mode set. If it is absent, the Zabbix database upgrade will fail (see also ZBX-19435).
MariaDB 10.2.1以前のバージョンでは、デフォルトの行フォーマットがコンパクトであるため、
これらのバージョンでデータベーステーブルを作成した場合、Zabbixのアップグレードに失敗することがあります。
この問題は、行の形式をダイナミックに変更することで解決できます。
ZBX-17690を参照してください。
In dual-stack environments (systems configured to support both IPv4 and IPv6), the hostname localhost
typically resolves to both IPv4 and IPv6 addresses. Due to the common prioritization of IPv6 over IPv4 by many operating systems and DNS resolvers, Zabbix templates may fail to work correctly if the service being monitored is configured to listen only on IPv4.
Services that are not configured to listen on IPv6 addresses may become inaccessible, leading to monitoring failures. Users might configure access correctly for IPv4 but still face connectivity issues due to the default behavior of prioritizing IPv6.
A workaround for this is to ensure that the services (Nginx, Apache, PostgreSQL, etc.) are configured to listen on both IPv4 and IPv6 addresses, and Zabbix server/agent is allowed access via IPv6. Additionally, in Zabbix templates and configurations, use localhost
explicitly instead of 127.0.0.1
to ensure compatibility with both IPv4 and IPv6.
For example, when monitoring PostgreSQL with the PostgreSQL by Zabbix agent 2 template, you may need to edit the pg_hba.conf
file to allow connections for the zbx_monitor
user. If the dual-stack environment prioritizes IPv6 (system resolves localhost to ::1
) and you configure localhost
but only add an IPv4 entry (127.0.0.1/32
), the connection will fail because there is no matching IPv6 entry.
The following pg_hba.conf
file example ensures that the zbx_monitor
user can connect to any database from the local machine using both IPv4 and IPv6 addresses with different authentication methods:
# 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
If necessary, you can also use the IPv4 address (127.0.0.1
) directly when configuring the PostgreSQL by Zabbix agent 2 template macro for the connection string.
With EPEL repository installed and enabled, installing Zabbix from packages will lead to EPEL Zabbix packages being installed rather than official Zabbix packages.
In this case uninstall Zabbix packages from EPEL, i.e.:
Block Zabbix packages from EPEL. Add the following line in the /etc/yum.conf
file:
Install Zabbix server again:
Notice that official Zabbix packages have the word release
in their version string:
When installing Zabbix from Red Hat Enterprise Linux packages on Red Hat Universal Base Image environments, ensure access to required repositories and dependencies. Zabbix packages depend on libOpenIPMI.so
and libOpenIPMIposix.so
libraries, which are not provided by any package in the default package manager repositories enabled on UBI systems and will result in installation failures.
The libOpenIPMI.so
and libOpenIPMIposix.so
libraries are available in the OpenIPMI-libs
package, which is provided by the redhat-#-for-<arch>-appstream-rpms
repository. Access to this repository is curated by subscriptions, which, in the case of UBI environments, get propagated by mounting repository configuration and secrets directories of the RHEL host into the container file-system namespace.
For more information, see ZBX-24291.
DBTLSConnect parameterの 'verify_ca' オプションでは、
MariaDB を使用したデータベースTLS 接続はサポートされません。
負荷が高く、複数のLLD処理が実行されている場合、行ロック処理に関するInnoDBエラーが原因でデッドロックが発生する可能性があります。(upstream bug参照) このエラーは、MySQL 8.0.29で修正されましたが、MariaDBでは修正されていません。詳細は、ZBX-21506を参照してください。
最初のイベントと2番目のイベントの時間間隔が非常に小さい場合(0.5秒以下)、イベントは正しく相関しないことがあります。
PostgreSQL 11およびそれ以前のバージョンでは、浮動小数点数データ型をサポートしています。
1.34E-154 から 1.34E+154 までの範囲になります。
NetBSD 8.0以降では、起動時にZabbixの様々なプロセスがランダムにクラッシュすることがあります。
バージョン8.Xおよび9.Xでは、デフォルトのスタックサイズ(4MB)が小さすぎることが原因です。この値を増やす必要があります。
詳しくは、関連する問題報告ZBX-18275を参照してください。
Zabbix agent 2 does not support lookaheads and lookbehinds in regular expressions due to the standard Go regexp library limitations.
9 (stretch) 以前の Debian および 16.04 (xenial) 以前の Ubuntu では、標準の OpenIPMI ライブラリパッケージではIPMI チェックが動作しません。
修正するにはZBX-6139 で説明されているように OpenSSL を有効にして
OpenIPMI ライブラリを再コンパイルしてください。
libssh2 ライブラリがパッケージからインストールされている場合、Debian、Ubuntu などの一部の Linux ディストリビューションは、暗号化された秘密鍵 (パスフレーズ付き) をサポートしません。 詳細についてはZBX-4850 を参照してください。
OpenSSH 8 を使用して CentOS 8 で libssh 0.9.x を使用すると、SSH チェックで「SSH サーバーからデータを読み取れません」と報告されることがあります。 これは、libssh の 問題 (詳細レポート) が原因です。このエラーは安定版のlibssh 0.9.5 リリースで修正される予定です。 詳細についてはZBX-17756 も参照してください。
パイプ"|"を使用したSSH スクリプトで「SSH サーバーからデータを読み取れません」というエラーが発生する可能性があります。 この場合libssh ライブラリのバージョンをアップグレードすることをお勧めします。 詳細については、ZBX-21337 を参照してください。
MySQL unixODBC ドライバーは、MariaDB コネクタ ライブラリに対してコンパイルされた Zabbix サーバーまたは Zabbix プロキシと共に使用しないでください。アップストリームのバグ のため、可能であればドライバーと同じコネクタを使用しないこともお勧めします。推奨セットアップ:
PostgreSQL, SQLite または Oracle connector → MariaDB または MySQL unixODBC driver MariaDB connector → MariaDB unixODBC driver MySQL connector → MySQL unixODBC driver
詳細および利用可能な回避策についてはZBX-7665 を参照してください。
Microsoft SQL Server からクエリされた XML データは、Linux および UNIX システムでさまざまな方法で切り捨てられる場合があります。
さまざまなバージョンの Linux 用 Oracle Instant Client を使用して Oracle データベースを監視するために ODBC チェックを使用すると、Zabbix サーバーがクラッシュすることが確認されています。[ZBX-18402](https://support.zabbix.com/browse/ZBX-18402)ZBX-20803も参照してください。
FreeTDS UnixODBC ドライバーを使用している場合は、'SET NOCOUNT ON' ステートメントを SQL クエリの先頭に追加する必要があります (例:`SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....
`)。そうしないと、Zabbix のデータベース モニタ アイテムは"SQL クエリが空の結果を返しました"というエラーで情報の取得に失敗します。(https://support.zabbix.com/browse/ZBX-19917) を参照してください。
HTTPチェックでのみ使用されるrequest method parameterが、4.0以前のZabbixからアップグレードした結果、
すべてのアイテムにデフォルト値ではない'1'が設定されることがあります。
この問題の解決方法の詳細については、ZBX-19308を参照してください。
いくつかのLinuxディストリビューション上で、WebシナリオやHTTPエージェント内で「SSLピア検証」を有効にしていた時にupstream bugによってメモリリークが発生します。 ZBX-10486を参照してより詳細な情報と回避策を確認してください。
v3.10より前のバージョンのfpingには、重複したエコーリプライパケットを誤って処理するバグがあります。
これは icmpping
, icmppingloss
, icmppingsec
アイテムに予期せぬ結果をもたらすかもしれません。
このため、最新バージョンのfpingを使用することをお勧めします。
詳細はZBX-11726を参照してください。
When containers are running in rootless mode or in a specific-restrictions environment, you may face errors related to fping execution when performing ICMP checks, such as fping: Operation not permitted
or all packets to all resources lost.
To fix this problem add --cap-add=net_raw
to "docker run" or "podman run" commands.
Additionally fping execution in non-root environments may require sysctl modification, i.e.:
where "1995" is the zabbix GID. For more details, see ZBX-22833.
OpenBSDオペレーティングシステムを使用している場合、バージョン5.7.3までのNet-SNMPライブラリの
use-after-freeバグにより、Zabbix server にSourceIPパラメータが設定されている場合
Zabbix server がクラッシュする可能性があります。回避策として、SourceIPパラメータを設定しないようお願いします。
Linuxでも同様の問題が発生しますが、Zabbix server の動作が停止することはありません。
OpenBSDのnet-snmpパッケージに対するローカルパッチが適用され、OpenBSD 6.3でリリースされる予定です。
SNMPデータのスパイクが確認されています。
詳細はZBX-14318を参照してください。
SNMPトラップの処理で必要な"net-snmp-perl"パッケージは、RHEL 8.0-8.2で削除され、RHEL 8.3で追加されました。
RHEL 8.0-8.2を使用している場合、RHEL 8.3にアップグレードするのが最適な解決策です。
ZBX-17192を参照してください。
RHEL 7上でZabbixサーバーのalerterプロセスがクラッシュすることが確認されています。 詳細はZBX-10461を参照してください。
When upgrading Zabbix agent 2 (version 6.0.5 or older) from packages, a plugin-related file conflict error may occur. To fix the error, back up your agent 2 configuration (if necessary), uninstall agent 2 and install it anew.
On RHEL-based systems, run:
On Debian-based systems, run:
For more information, see ZBX-23250.
Webインターフェースの言語設定が、明らかにロジックなしでフリッピングすることが確認されています。
あるページ (またはページの一部) はある言語で表示され、別のページ (またはページの一部) は別の言語で表示される。
一般的に、この問題は複数のユーザーがいて、そのうちの何人かがあるロケールを使い、それ以外に別のロケールを使う
ユーザーがいる場合に発生することがあります。
この問題を回避する方法として知られているのは、PHPとApacheのマルチスレッドを無効にすることです。
この問題は、ロケールの設定がどのように行われるかに関連しています。
in PHP
ロケールの情報はスレッド単位ではなくプロセス単位で管理されます。
そのため、マルチスレッド環境において、同じ Apache プロセスで実行される複数のプロジェクトがある場合、
別のスレッドでロケールが変更される可能性があります。
その結果、Zabbixスレッドで処理できるデータが変更される可能性があります。
詳細については、関連する問題報告を参照してください。
PHP 7.3の設定で "opcache" が有効な場合、ZabbixのWebインターフェースを初めて読み込んだときに、
空白の画面が表示されることがあります。これは登録されたPHP bugです。
この問題を回避するには、php.ini の opcache.optimization_levelパラメータを0x7FFFBFDF
に設定してください。
夏時間 (DST) への変更により、X 軸ラベルの表示が不規則になります。 (日付の重複、日付の欠落など)
1 時間未満の期間のグラフで 合計集計 を使用すると、データがトレンドから取得されたときに、グラフに誤った (乗算された) 値が表示されます。
log[]とlogrt[]
は、ファイルシステムが100%一杯の状態でログファイルが追加される場合、ログファイルを最初から読み直します。
(詳しくは ZBX-10884 を参照してください)
Zabbixサーバは、アイテムが存在しない場合、スロークエリ(SELECT)を生成します。
これは、以下の既知の問題によるものです。
MySQL 5.6/5.7バージョンにおける既知の問題
この問題の回避策は、index_condition_pushdown optimizer を無効にします。
詳細についてはZBX-10652を参照してください。
Configuration sync might be slow in Zabbix 6.0 installations with Oracle DB that have high number of items and item preprocessing steps. This is caused by the Oracle database engine speed processing nclob type fields.
To improve performance, you can convert the field types from nclob to nvarchar2 by manually applying the database patch items_nvarchar_prepare.sql. Note that this conversion will reduce the maximum field size limit from 65535 bytes to 4000 bytes for item preprocessing parameters and item parameters such as Description, Script item's field Script, HTTP agent item's fields Request body and Headers, Database monitor item's field SQL query. Queries to determine template names that need to be deleted before applying the patch are provided in the patch as a comment. Alternatively, if MAX_STRING_SIZE is set you can change nvarchar2(4000) to nvarchar2(32767) in the patch queries to set the 32767 bytes field size limit.
For an extended discussion, see ZBX-22363.
user.login
methodを使用し、user.logout
がない
カスタムスクリプトを実行した場合、多数のオープンユーザーセッションが作成される可能性があります。
net-snmp のバグにより、SNMP トラップで SNMPv3 を使用する場合、IPv6 アドレスが正しく表示されないことがあります。
詳細および回避策については、ZBX-14541を参照してください。
ログインに失敗したメッセージには、保存されているIPアドレスの最初の39文字だけが表示されます。
これは、データベースフィールドの文字数制限のためです。
つまり、39文字より長いIPv6 IPアドレスは、不完全に表示されます。
Zabbix agent設定ファイル(zabbix_agentd.conf)のServerパラメータに既存のDNSエントリがない場合、
Zabbixエージェントの応答時間が長くなる可能性があります。
これは、WindowsのDNSキャッシュデーモンがIPv4アドレスのネガティブレスポンスをキャッシュしないためです。
しかし、IPv6アドレスではネガティブレスポンスはキャッシュされます。
この問題を回避するには、ホスト上でIPv4を無効にする必要があります。
YAML には、いくつかの既知の問題があります。 export/import
SUSE で NGINX + php-fpm を使用している場合、フロントエンドのセットアップウィザードで設定ファイルを保存できません。
これは、/usr/lib/systemd/system/php-fpm.service unitの設定により、Zabbixが/etcに書き込むことができないためです。
(PHP7.4で導入されました)。
2つの回避策があります。
ほとんどの場合、Zabbix WebサービスはChromiumで動作しますが、Ubuntu 20.04でChromiumを使用すると、以下のエラーが発生します。
Cannot fetch data: chrome failed to start:cmd_run.go:994: <br>
WARNING: cannot create user data directory: cannot create <br>
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied <br>
Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details. <br>
このエラーは、ユーザ zabbix のホームディレクトリとして /var/lib/zabbix
が使用されているため発生します。
Azure上のMySQLインストールでZabbixを使用する場合、不明確なエラーメッセージ
[9002] Some errors occurred がZabbixログに表示されることがあります。
この一般的なエラーテキストは、データベースから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以降
The maps in the Geomap widget may not load correctly, if you have upgraded from an older Zabbix version with NGINX and didn't switch to the new NGINX configuration file during the upgrade.
To fix the issue, you can discard the old configuration file, use the configuration file from the current version package and reconfigure it as described in the download instructions in section e. Configure PHP for Zabbix frontend.
Alternatively, you can manually edit an existing NGINX configuration file (typically, /etc/zabbix/nginx.conf). To do so, open the file and locate the following block:
Then, replace this block with:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
In Zabbix versions 6.4.3 and older, logrotate is only included into packages for zabbix-agent, zabbix-agent2 and zabbix-web-service, but needs to be installed separately for Zabbix server and proxy. The logrotate dependency has been added to the server and proxy packages for RHEL and SUSE starting from Zabbix 6.4.4rc1.
The Windows Zabbix agent download ZIP file is missing zabbix_sender.h and zabbix_sender.lib files in versions 6.4.0-6.4.12, required for zabbix_sender.dll.
Zabbix server 6.4.12 and Zabbix proxy 6.4.12 are not compatible with other versions of proxy/server. If either server or proxy is 6.4.12, then both server and proxy must be 6.4.12.
This issue is fixed in 6.4.13 and later. However, while the following releases are compatible with 6.4.11 server/proxy (or sooner); they are still not compatible with 6.4.12 server/proxy.