- 8 既知の問題
- 7.0.20 の既知の問題
- アップグレード
- テンプレート
- EPEL Zabbixパッケージの誤インストール
- Red Hat UBI環境のRHEL用Zabbixパッケージ
- RHELパッケージの署名キーの有効期限切れ
- MariaDBでのデータベースTLS接続
- MySQL/MariaDBで発生する可能性のあるデッドロック
- グローバルイベント相関
- PostgreSQL 11以前における数値（float）データ型の範囲
- NetBSD 8.0 以降
- Zabbixエージェント2の正規表現の制限
- IPMIチェック
- IPMI — 信頼されていないホストによりOpenIPMIがクラッシュする可能性があります
- SSHチェック
- ODBCチェック
- アイテムにおけるリクエストメソッドパラメータの誤り
- Web監視とHTTPエージェント
- シンプルチェック
- ルートレスコンテナでの fping 実行時のエラー
- SNMPチェック
- SNMPデータのスパイク
- SNMPトラップ
- RHEL 7でのアラート送信プロセスのクラッシュ
- Zabbixエージェント 2 のアップグレード（6.0.5 以前）
- Webインターフェースのロケールが切り替わる
- グラフ
- ログファイル監視
- 遅いMySQLクエリ
- Oracleでの設定同期の遅延
- リンクからの永続的なフィルター設定
- SNMPv3トラップにおけるIPv6アドレスの問題
- 失敗したログイン情報における長いIPv6 IPアドレスの切り詰め
- WindowsでのZabbixエージェントチェック
- YAMLエクスポート/インポート
- SUSE で NGINX と php-fpm を使用する場合のセットアップウィザード
- 認証ヘッダーの転送
- Ubuntu 20上のZabbix web service向けChromium
- MySQLカスタムエラーコード
- PCRE2への切り替え後に無効になる正規表現
- Geomapウィジェットのエラー
- 前処理 — グローバル変数は安全ではありません
- 7.0 からアップグレード後、TimescaleDB でサーバーがクラッシュする
- 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 既知の問題
参照: コンパイルの問題
7.0.20 の既知の問題
以下の理由により、このバージョンへのアップグレードは推奨されません。
- Zabbix エージェント 2 の MySQL プラグインを使用している場合、CPU 使用率が突然急上昇する問題があるため（ZBX-27156 を参照）
- 未定義のインデックスエラーにより、Zabbix アクティブエージェントのアイテムのグラフに "Undefined array key" 警告が表示されるため（ZBX-27153 を参照）
アップグレード
アップグレードを正常に実行するためのSQLモード設定
MySQL/MariaDB の sql_mode 設定では、"STRICT_TRANS_TABLES" モードを設定する必要があります。
これが設定されていない場合、Zabbix データベースのアップグレードは失敗します（ZBX-19435 も参照してください）。
MariaDB 10.2.1以前でのアップグレード
データベーステーブルがMariaDB 10.2.1以前で作成されている場合、これらのバージョンではデフォルトの行形式がcompactであるため、Zabbixのアップグレードに失敗する可能性があります。
これは、行形式をdynamicに変更することで修正できます（ZBX-17690も参照してください）。
テンプレート
デュアルスタック（IPv4/IPv6）環境におけるテンプレートの互換性
デュアルスタック環境（IPv4 と IPv6 の両方をサポートするよう設定されたシステム）では、ホスト名 localhost は通常、IPv4 と IPv6 の両方のアドレスに解決されます。
多くのオペレーティングシステムや DNS リゾルバーでは IPv4 よりも IPv6 が優先されることが一般的であるため、監視対象のサービスが IPv4 のみで待ち受けるよう設定されている場合、Zabbix テンプレートが正しく動作しないことがあります。
IPv6 アドレスで待ち受けるよう設定されていないサービスはアクセス不能になる可能性があり、その結果、監視に失敗します。
ユーザーが IPv4 用のアクセスを正しく設定していても、IPv6 がデフォルトで優先される動作により、接続性の問題が発生する場合があります。
この問題の回避策としては、サービス（Nginx、Apache、PostgreSQL など）が IPv4 と IPv6 の両方のアドレスで待ち受けるよう設定されており、かつ Zabbix サーバー/エージェント から IPv6 経由でのアクセスが許可されていることを確認してください。
さらに、Zabbix テンプレートおよび設定では、IPv4 と IPv6 の両方との互換性を確保するため、127.0.0.1 ではなく明示的に localhost を使用してください。
たとえば、PostgreSQL by Zabbix agent 2 テンプレートを使用して PostgreSQL を監視する場合、zbx_monitor ユーザーの接続を許可するために pg_hba.conf ファイルを編集する必要があることがあります。
デュアルスタック環境で 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必要に応じて、接続文字列用の PostgreSQL by Zabbix agent 2 テンプレートマクロを設定する際に、IPv4 アドレス（127.0.0.1）を直接使用することもできます。
EPEL Zabbixパッケージの誤インストール
EPELリポジトリがインストールされ、有効になっている場合、Zabbixパッケージのインストール時に、公式のZabbixパッケージではなくEPEL版が取得されることがあります。 これを解決するには、次の手順を実行します。
1. EPELからインストールされたZabbixパッケージを削除します。
dnf remove zabbix-server-mysql2. /etc/yum.repos.d/epel.repo ファイルに次の行を追加して、EPELからZabbixパッケージを除外します。
[epel]
...
excludepkgs=zabbix*3. 公式のZabbixサーバーパッケージを再インストールします。
dnf install zabbix-server-mysqlインストール時、公式のZabbixパッケージにはバージョン文字列に 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ライブラリは、redhat-#-for-<arch>-appstream-rpmsリポジトリによって提供されるOpenIPMI-libsパッケージで使用できます。このリポジトリへのアクセスはサブスクリプションによって管理されUBI環境の場合、RHELホストのリポジトリ構成およびシークレットディレクトリをコンテナーファイルシステムの名前空間にマウントすることによって伝播されます。
詳細については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 では次を実行します。
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpmその後、リポジトリ情報を更新します。
dnf update詳細については、ZBX-24761 を参照してください。
MariaDBでのデータベースTLS接続
MariaDBを使用している場合、DBTLSConnect parameter の 'verify_ca' オプションでは、データベースTLS接続はサポートされていません。
MySQL/MariaDBで発生する可能性のあるデッドロック
高負荷時に、かつ複数のLLDワーカーが関与している場合、行ロック戦略に関連するInnoDBエラーが原因でデッドロックが発生する可能性があります（upstream bugを参照）。 このエラーはMySQLでは8.0.29以降で修正されていますが、MariaDBでは修正されていません。 詳細については、ZBX-21506を参照してください。
グローバルイベント相関
最初のイベントと2番目のイベントの間の時間間隔が非常に短い場合、つまり0.5秒以下の場合、イベントが正しく相関付けされないことがあります。
PostgreSQL 11以前における数値（float）データ型の範囲
PostgreSQL 11およびそれ以前のバージョンでは、サポートされる浮動小数点値の範囲はおよそ -1.34E-154 から 1.34E+154 までです。
NetBSD 8.0 以降
NetBSD バージョン 8.X および 9.X では、各種 Zabbix プロセスが起動時にランダムにクラッシュする場合があります。
これはデフォルトのスタックサイズ（4MB）が小さすぎることが原因で、次を実行して増やす必要があります。
ulimit -s 10240詳細については、関連する問題レポートを参照してください: ZBX-18275。
Zabbixエージェント2の正規表現の制限
Zabbixエージェント2は、標準のGo正規表現ライブラリの制限により、正規表現の先読みと後読みをサポートしていません。
IPMIチェック
IPMIチェックは、Debian 9（stretch）より前および Ubuntu 16.04（xenial）より前では、標準の OpenIPMI ライブラリパッケージでは動作しません。
これを修正するには、ZBX-6139 で説明されているように、OpenSSL を有効にして OpenIPMI ライブラリを再コンパイルしてください。
IPMI — 信頼されていないホストによりOpenIPMIがクラッシュする可能性があります
ZabbixがIPMIデータのポーリングに使用するOpenIPMIライブラリには、信頼されていないデバイスからの細工された応答によって引き起こされる不具合があります。
信頼されていないIPMIデバイスは、OpenIPMIライブラリをクラッシュさせる細工されたデータを送信する可能性があり、その結果、IPMIポーリングを実行するZabbixサーバーのプロセスが終了する場合があります。
SSHチェック
- Debian、Ubuntu などの一部の Linux ディストリビューションでは、libssh2 ライブラリがパッケージからインストールされている場合、暗号化された秘密鍵（パスフレーズ付き）はサポートされません。 詳細については ZBX-4850 を参照してください。
- 一部の Linux ディストリビューションで OpenSSH 8 とともに libssh 0.9.x を使用している場合、SSHチェックで断続的に "Cannot read data from SSH server" が報告されることがあります。 これは libssh の 問題 によって発生します（より詳細なレポート）。 このエラーは、安定版 libssh 0.9.5 のリリースで修正されていることが期待されます。 詳細については ZBX-17756 も参照してください。
- SSH スクリプトでパイプ "|" を使用すると、"Cannot read data from SSH server" エラーが発生する場合があります。 この場合は、libssh ライブラリのバージョンをアップグレードすることを推奨します。 詳細については ZBX-21337 も参照してください。
ODBCチェック
- 可能であれば、MariaDBコネクターライブラリに対してコンパイルされたZabbixサーバーまたはZabbixプロキシではMySQL unixODBCドライバーを使用せず、その逆の場合も同様にしてください。また、upstream bug により、ドライバーと同じコネクターの使用も避けることを推奨します。
推奨構成:
PostgreSQL、SQLite、またはOracleコネクター → MariaDBまたはMySQL unixODBCドライバー
MariaDBコネクター → MariaDB unixODBCドライバー
MySQLコネクター → MySQL unixODBCドライバー
詳細および利用可能な回避策については、ZBX-7665 を参照してください。
-
Microsoft SQL Serverから取得したXMLデータは、LinuxおよびUNIXシステム上でさまざまな形で切り詰められる場合があります。
-
Linux向けの各種バージョンのOracle Instant Clientを使用してOracleデータベースを監視するためにODBCチェックを使用すると、Zabbixサーバーがクラッシュすることが確認されています。
関連情報: ZBX-18402、ZBX-20803。 -
FreeTDS UnixODBCドライバーを使用する場合は、SQLクエリの先頭に 'SET NOCOUNT ON' 文を追加する必要があります（例:
SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....）。
そうしないと、Zabbixのデータベースモニターアイテムは次のエラーにより情報を取得できません。
"SQL query returned empty result".
詳細については、ZBX-19917 を参照してください。
アイテムにおけるリクエストメソッドパラメータの誤り
HTTPチェックでのみ使用されるリクエストメソッドパラメータが、4.0より前のZabbixバージョンからのアップグレードの結果として、すべてのアイテムでデフォルト以外の値である「1」に誤って設定されている場合があります。
この状況の修正方法の詳細については、ZBX-19308を参照してください。
Web監視とHTTPエージェント
一部のLinuxディストリビューションでは、WebシナリオまたはHTTPエージェントで「SSL verify peer」を有効にすると、upstream bug によりZabbixサーバーでメモリリークが発生します。
詳細および利用可能な回避策については、ZBX-10486 を参照してください。
シンプルチェック
v3.10 より前の fping バージョンには、重複したエコー応答パケットを誤って処理する不具合があります。
これにより、icmpping、icmppingloss、icmppingsec アイテムで予期しない結果が発生する可能性があります。
fping は最新バージョンを使用することを推奨します。
詳細については、ZBX-11726 を参照してください。
ルートレスコンテナでの fping 実行時のエラー
コンテナがルートレスモードで実行されている場合、または特定の制限がある環境では、ICMPチェックの実行時に fping: Operation not permitted や、すべてのリソースへのすべてのパケットが失われるといった、fping の実行に関連するエラーが発生することがあります。
この問題を修正するには、docker run または podman run コマンドに --cap-add=net_raw を追加してください。
さらに、非 root 環境で fping を実行するには、sysctl の変更が必要になる場合があります。例:
sudo sysctl -w "net.ipv4.ping_group_range=0 1995"ここで、1995 は zabbix の GID です。
詳細については、ZBX-22833 を参照してください。
SNMPチェック
OpenBSDオペレーティングシステムを使用している場合、Net-SNMPライブラリのバージョン5.7.3までに存在するuse-after-freeバグにより、Zabbixサーバー設定ファイルでSourceIPパラメータが設定されていると、Zabbixサーバーがクラッシュする可能性があります。
回避策として、SourceIPパラメータを設定しないでください。
同じ問題はLinuxにも当てはまりますが、Zabbixサーバーが停止することはありません。
OpenBSD上のnet-snmpパッケージにはローカルパッチが適用されており、OpenBSD 6.3でリリースされる予定です。
SNMPデータのスパイク
SNMPデータのスパイクは、商用電源の電圧スパイクのような特定の物理的要因に関連して発生することがあります。 詳細については、ZBX-14318を参照してください。
SNMPトラップ
SNMPトラップに必要な "net-snmp-perl" パッケージは、RHEL 8.0-8.2 では削除されていましたが、RHEL 8.3 で再追加されました。
そのため、RHEL 8.0-8.2 を使用している場合の最善の解決策は、RHEL 8.3 にアップグレードすることです。
詳細については、ZBX-17192 も参照してください。
RHEL 7でのアラート送信プロセスのクラッシュ
RHEL 7で、Zabbixサーバーのアラート送信プロセスがクラッシュする事例が確認されています。
詳細については、ZBX-10461を参照してください。
Zabbixエージェント 2 のアップグレード（6.0.5 以前）
パッケージから Zabbixエージェント 2（バージョン 6.0.5 以前）をアップグレードする際に、プラグイン関連ファイルの競合エラーが発生する場合があります。
このエラーを修正するには、エージェント 2 の設定をバックアップし（必要な場合）、エージェント 2 をアンインストールして新たにインストールしてください。
RHEL ベースのシステムでは、次を実行します。
dnf remove zabbix-agent2
dnf install zabbix-agent2Debian ベースのシステムでは、次を実行します。
apt remove zabbix-agent2
apt install zabbix-agent2詳細については、ZBX-23250 を参照してください。
Webインターフェースのロケールが切り替わる
明確な理由がないにもかかわらず、Webインターフェースのロケールが切り替わることが確認されています。つまり、あるページ（またはページの一部）は1つの言語で表示される一方で、別のページ（またはページの一部）は別の言語で表示されることがあります。 通常、この問題は複数のユーザーが存在し、その一部が1つのロケールを使用し、他のユーザーが別のロケールを使用している場合に発生することがあります。
この問題に対する既知の回避策は、PHPおよびApacheでマルチスレッドを無効にすることです。
この問題は、PHPにおけるロケール設定の仕組みに関連しています。ロケール情報はスレッドごとではなく、プロセスごとに保持されます。 そのため、マルチスレッド環境では、同じApacheプロセス上で複数のプロジェクトが実行されている場合、別のスレッドでロケールが変更され、その結果、Zabbixのスレッドでのデータ処理方法に影響する可能性があります。
詳細については、関連する問題報告を参照してください。
グラフ
グラフ（クラシック）の問題
クラシックグラフで問題が発生した場合は、GDライブラリ（libgd）をバージョン 2.3.3-13 以降に、PHP をバージョン 8.0.19、8.1.33、8.2.29、8.3.25、8.4.12 以降に更新することを推奨します。
サマータイム
サマータイム（DST）の変更により、X 軸ラベルの表示に不規則性（日付の重複、日付の欠落など）が生じます。
合計集計
グラフで 1 時間未満の期間に対して sum aggregation を使用すると、データがトレンドから取得される場合に、グラフに誤った（乗算された）値が表示されます。
テキストの重なり
一部のWebインターフェース言語（例: 日本語）では、ローカルフォントが原因でグラフの凡例内のテキストが重なることがあります。 これを回避するには、PHP GD 拡張モジュールのバージョン 2.3.0 以降を使用してください。
ログファイル監視
log[] および logrt[] アイテムは、ファイルシステムが 100% いっぱいで、ログファイルに追記が行われている場合、ログファイルの先頭から繰り返し再読み込みします（詳細は ZBX-10884 を参照してください）。
遅いMySQLクエリ
Zabbixサーバーは、アイテムに値が存在しない場合に、遅い SELECT クエリを生成します。
この問題は、MySQL 5.6/5.7 バージョンで発生することが知られています（詳細な議論については、ZBX-10652を参照してください）。また、特定のケースでは、後のMySQLバージョンでも発生する可能性があります。
この問題の回避策として、MySQLで index_condition_pushdown または prefer_ordering_index オプティマイザを無効にする方法があります。
ただし、この回避策ですべての遅いクエリに関連する問題が解決されるとは限らない点に注意してください。
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 Webインターフェースページへのリンクを開くと、そのフィルターはユーザー用としてデータベースに自動的に保存され、そのページで以前に保存されていたフィルターおよび/または期間セレクターの設定を置き換えます。
これらの設定は、ユーザーが手動で更新またはリセットするまで有効なままです。
SNMPv3トラップにおけるIPv6アドレスの問題
net-snmpのバグにより、SNMPトラップでSNMPv3を使用している場合、IPv6アドレスが正しく表示されないことがあります。
詳細および回避策の可能性については、ZBX-14541を参照してください。
失敗したログイン情報における長いIPv6 IPアドレスの切り詰め
失敗したログイン試行メッセージには、データベースフィールドの文字数制限により、保存されたIPアドレスの先頭39文字のみが表示されます。
つまり、39文字を超えるIPv6 IPアドレスは完全には表示されません。
WindowsでのZabbixエージェントチェック
Zabbixエージェント設定ファイル（zabbix_agentd.conf）のServerパラメータに存在しないDNSエントリがあると、Windows上でZabbixエージェントの応答時間が増加する可能性があります。
これは、WindowsのDNSキャッシュデーモンがIPv4アドレスに対する否定応答をキャッシュしないために発生します。
ただし、IPv6アドレスに対する否定応答はキャッシュされるため、考えられる回避策としてホスト上でIPv4を無効にする方法があります。
YAMLエクスポート/インポート
YAMLのエクスポート/インポートには、いくつかの既知の問題があります。
- エラーメッセージは翻訳できません。
- .yamlファイル拡張子を持つ有効なJSONは、インポートできない場合があります。
- 引用符で囲まれていない人間が読みやすい日付は、自動的にUnixタイムスタンプに変換されます。
SUSE で NGINX と php-fpm を使用する場合のセットアップウィザード
SUSE で NGINX + php-fpm を使用している場合、Webインターフェースのセットアップウィザードは設定ファイルを保存できません。
これは /usr/lib/systemd/system/php-fpm.service ユニット内の設定が原因で、Zabbix が /etc に書き込めないようになっています（PHP 7.4 で導入）。
利用可能な回避策は 2 つあります。
- php-fpm の systemd ユニットで、ProtectSystem オプションを 'full' ではなく 'true' に設定します。
- /etc/zabbix/web/zabbix.conf.php ファイルを手動で保存します。
認証ヘッダーの転送
ApacheまたはNGINXが、APIリクエスト内の認証ヘッダーをZabbixに転送できない場合があります。 これにより、Zabbix APIやOktaを使用したSAMLといったシングルサインオン(SSO)サービスの使用時に認証の問題が発生する可能性があります。
この問題を解決するには、Webサーバーの設定を更新してください。
Apacheをリバースプロキシ(CGI以外の設定)として使用する場合は、(RHELベースシステムの場合) /etc/httpd/conf/httpd.confまたは(Debian/Ubuntuの場合) /etc/apache2/apache2.confに次のディレクティブを追加してください。
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1Apacheがリクエストを処理するためにスクリプトを直接実行する場合(例: mod_cgiを使用)、代わりに次のディレクティブを追加してください。
CGIPassAuth On一方、NGINXはAuthorizationヘッダーを自動的に処理します。
ただし、NGINXがリバースプロキシとして動作している場合は、/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およびAuthorizationヘッダー
- SetEnvIfNoCaseおよびCGIPassAuthディレクティブ
- NGINXリバースプロキシ
Ubuntu 20上のZabbix web service向けChromium
ほとんどの場合、Zabbix web serviceは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を使用している場合、汎用エラーメッセージ [9002] Some errors occurred がZabbixログに表示されることがあります。
このメッセージは、データベースからZabbixサーバーまたはプロキシに送信されます。
エラーの原因を特定するには、Azureログを確認してください。
PCRE2への切り替え後に無効になる正規表現
Zabbix 6.0 では、PCRE2 のサポートが追加されました。
PCRE も引き続きサポートされていますが、RHEL 7 以降、SLES（全バージョン）、Debian 9 以降、Ubuntu 16.04 以降向けの Zabbix インストールパッケージは、PCRE2 を使用するよう更新されています。
多くの利点がある一方で、PCRE2 への切り替えにより、既存の一部の PCRE 正規表現パターンが無効になったり、動作が変わったりする場合があります。
特に、これはパターン \^[\w-\.] に影響します。
この正規表現を意味を変えずに再び有効にするには、式を \^[-\w\.] に変更してください。
これは、PCRE2 がダッシュ記号を区切り文字として扱い、文字クラス内で範囲を作成するために発生します。
Geomapウィジェットのエラー
NGINX を使用していて、古い Zabbix バージョンからアップグレードした際に、新しい NGINX 設定ファイルへ切り替えていない場合、Geomapウィジェットの地図が正しく読み込まれないことがあります。
この問題を修正するには、古い設定ファイルを破棄し、現在のバージョンのパッケージに含まれる設定ファイルを使用して、ダウンロード手順 の e. Configure PHP for Zabbix frontend セクションで説明されているとおりに再設定してください。
または、既存の 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;
}前処理 — グローバル変数は安全ではありません
前処理のJavaScriptはリクエストごとに実行されますが、宣言されていない識別子への代入（たとえば secret = value）は、現在の実行を超えて保持される可能性がある暗黙的なグローバル変数を作成します。
機密データ（トークン、パスワードなど）を暗黙的なグローバル変数に保存すると、後続の前処理実行や、同じ環境で実行される他の連携機能によって誤って公開または再利用されるリスクが高まります。
暗黙的なグローバル変数に依存しないでください。
変数は必ず var または const で宣言し、機密情報をグローバルオブジェクト（たとえば globalThis や window）に追加しないでください。
前処理内から組み込みのグローバルオブジェクトを上書きするためのサポートされた方法はありません。
安全な例:
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });7.0 からアップグレード後、TimescaleDB でサーバーがクラッシュする
TimescaleDB を使用している環境で、Zabbix 7.0.0 から Zabbix 7.0.1（またはそれ以降）へアップグレードすると、サーバーがクラッシュします。
この問題は、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（またはそれ以降）であることを確認してください。そうでない場合、誤った圧縮ポリシーが再び設定されます。
また、スクリプトを実行する前に Zabbix サーバーを停止し、auditlog の所有者が zabbix ユーザーであることを確認してください。
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;データ移行をより最適化された方法で行うには、TimescaleDB documentation も参照してください。
パーティション分割に必要なタイムスタンプは、独自に作成された関数によって 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: 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のプロセッサグループ
Microsoftのドキュメントによると、論理プロセッサ数が64未満のシステムでは、プロセッサグループは常に1つで、Group 0になります。
ただし、Zabbixユーザーからは、論理プロセッサ数が64以下のシステムで2つのプロセッサグループが存在するというまれなバグ ZBX-20260 が報告されています。
この結果、2つあるプロセッサグループのうち1つについてしか "\Processor(n)" パフォーマンスカウンターが存在しない状態になっていました。
このバグの実際の根本原因は不明です。
ただし、同様の事例が stackoverflow.com で説明されており、そちらでは根本原因はBIOSとWindowsの相互運用にありました。
utf8mb4照合順序におけるフィルタリングの制限
フィルター（例：Data collection > Maintenance）は、特定のUnicode文字（例：ȼ、ɇ）を含むエンティティに適用した場合、正しく機能しないことがあります。
この問題は、MySQLまたはMariaDBデータベースのデフォルトのutf8mb4_bin照合順序における、Unicode文字のソートおよび比較の処理方法に起因します。
この制限に対処するため、ユーザーはデータベース列の照合順序を、utf8mb4_0900_bin、utf8mb4_0900_ai_ci、utf8mb4_unicode_520_ci などの代替値に変更できます。
ただし、照合順序を変更すると、空白の扱いや、他の文字に対するソートおよびフィルタリングで予期しない動作が発生する可能性がある点に注意してください。
照合順序の変更方法の詳細については、MySQL documentation または MariaDB documentation を参照してください。
照合順序の違いの詳細については、MySQL documentation の Unicode Character Sets を参照してください。
マップ内のネストされたホストグループからの情報が不正確
マップでは、ネストされたホストグループからの情報が正しく表示されません。例えば、次のような問題があります。
- ホストグループのラベルに、ネストされたホストグループ内のすべてのホストを含まない問題のサマリーが表示される。
- 「ホストグループ要素」ビューでは、ネストされたホストグループ内の各ホストに対して個別のマップ要素が表示されない。
- マップのラベルに、ネストされたホストグループ内の問題を含まない、すべての問題のサマリーが表示される。
7.0.7 における破損した LLD ルールのオーバーライド
バージョン 7.0.7 では、低レベルディスカバリルールのオーバーライドを処理する際に、Zabbixサーバーがクラッシュします。
回避策として、オーバーライドを含む LLD ルールを無効にしてください。
この問題は Zabbix 7.0.8rc2 で修正されています。
Zabbix 7.0.14における保存前処理マネージャーのパフォーマンス問題
バージョン7.0.14では、ログ監視中など、1つのアイテムに対して複数の値が同時に受信され、複数の保存前処理ワーカーが設定されている場合、Zabbix保存前処理マネージャーによってCPU使用率が上昇する可能性があります。
一時的な回避策として、サーバー/プロキシの設定パラメーターStartPreprocessorsを1に設定してください。
この問題はZabbix 7.0.15で修正されています。
マクロ関数
マクロ関数は、スクリプトアイテムのパラメータおよびブラウザアイテムのスクリプトパラメータでは動作しません。
Zabbix 7.0.7で修正されました。
MariaDB 10.5.1–10.5.9 におけるUI要素へのアクセス
Super Admin 以外のロールで Zabbix の Webインターフェース にアクセスすると、次のメッセージが表示される場合があります: 「System error occurred. Please contact Zabbix administrator.」。 この問題は、MariaDB versions 10.5.1 から 10.5.9 を使用しているインストール環境に影響します。
この問題を回避するには、MariaDB を 10.5.9 より新しいバージョンに更新してください。 詳細については、ZBX-25746 を参照してください。
tcmalloc を使用した過剰なメモリ使用量のプロファイリング
Zabbix のインストール環境でメモリを使いすぎている疑いがある場合は、tcmalloc のメモリプロファイリング機能を使用して、Zabbix サーバー/プロキシのメモリ消費を調査できます。
1. Zabbix をソースからインストールする場合は、追加のフラグを設定します。
export CFLAGS="-std=gnu99 -g -O0"-std=gnu99 フラグは、Zabbix サーバー、Zabbix プロキシ、または Zabbix エージェントのビルドに必要です。
-g フラグは追加のデバッグ情報を付加し、-O0 は最適化を無効にします。最適化は tcmalloc のプロファイリングに干渉する可能性があります。
2. Zabbix サーバーを起動する前に、以下の環境変数を設定します。
これらの変数は、メモリ使用量をどのように追跡し、レポートするかを 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) に置き換えてください。
kill -5 12344. 生成されたプロファイルを表示します。
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 がほぼすべてのメモリ割り当ての原因となっています。
関連情報:
- 関連する問題レポートについては、ZBX-25050 および ZBX-25584 を参照してください。
- コンパイルオプション（
-std=gnu99、-g、-O0など）については、GCC Option Summary を参照してください。 - tcmalloc プロファイリング用の環境変数については、Gperftools Heap Profiler のドキュメントを参照してください。
マルチプライマリモードにおける MySQL 8.0 Group Replication
MySQL 8.0 Group Replication をマルチプライマリモードで使用している場合、トランザクションのコミット中に次のようなエラーが発生することがあります。
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" を参照してください。