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以前でデータベーステーブルが作成された場合、Zabbixのアップグレードが失敗することがあります。これらのバージョンではデフォルトの行フォーマットがcompactであるためです。この問題は、行フォーマットをdynamicに変更することで修正できます（ZBX-17690も参照）。

MySQLデータベースの文字セットと照合順序

utf8mb3 文字セットと utf8mb3_bin 照合順序で作成された MySQL データベースを使用している Zabbix のインストール環境では、問題が発生する場合があります。たとえば、既知の MySQL の問題により、データベーススキーマのアップグレードやその他の DDL 操作中に Row size too large (> 8126) エラーが発生することがあります。
Zabbix データベースの文字セットと照合順序の修復に記載されているとおり、utf8mb3 文字セットと utf8mb3_bin 照合順序を使用しているデータベースを utf8mb4 文字セットと utf8mb4_bin 照合順序に変換することを強く推奨します。

テンプレート

デュアルスタック（IPv4/IPv6）環境におけるテンプレートの互換性

デュアルスタック環境（IPv4 と IPv6 の両方をサポートするように構成されたシステム）では、ホスト名 localhost は通常、IPv4 アドレスと IPv6 アドレスの両方に解決されます。
多くのオペレーティングシステムや DNS リゾルバーでは IPv4 より IPv6 が優先されるため、監視対象のサービスが IPv4 のみで待ち受けるように構成されていると、Zabbix テンプレートが正しく動作しない場合があります。

IPv6 アドレスでの待ち受けが設定されていないサービスは到達不能になる可能性があり、その結果、監視に失敗します。
ユーザーは IPv4 では正しくアクセスを設定していても、既定の IPv6 優先動作のために接続問題に直面することがあります。

この回避策として、サービス（Nginx、Apache、PostgreSQL など）を IPv4 と IPv6 の両方のアドレスで待ち受けるように構成し、Zabbix サーバー/エージェントが IPv6 経由でアクセスできるようにします。
さらに、Zabbix テンプレートや設定では、127.0.0.1 ではなく localhost を明示的に使用して、IPv4 と IPv6 の両方との互換性を確保します。

例として、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-mysql

2. /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.4/release/rhel/9/noarch/zabbix-release-latest.el9.noarch.rpm

その後、リポジトリ情報を更新します:

dnf update

詳細については、ZBX-24761 を参照してください。

Timescale DB: パーティション数が多い場合のメモリ使用量の増加

PostgreSQLバージョン9.6-12では、多数のパーティションを持つテーブルを更新する際に過剰なメモリを使用します。この問題は、ZabbixがTimescaleDBを使用しているシステムでトレンドを比較的小さなチャンク（例：1日）に分割している場合に発生します。これにより、デフォルトのハウスキーピング設定ではトレンドテーブルに数百のチャンクが存在し、PostgreSQLがメモリ不足に陥る可能性があります。

この問題は、TimescaleDBを使用した新規インストールのZabbix 5.0.1以降で解決されていますが、それ以前にTimescaleDBをセットアップした場合は、ZBX-16347の移行手順をご参照ください。

Timescale DB 2.5.0: 整数を含むテーブルで圧縮ポリシーが失敗する可能性

この問題は、TimescaleDB 2.5.0/2.5.1を使用している場合に発生します。 TimescaleDB 2.5.2以降で解決されています。

詳細については、TimescaleDB Issue #3773をご参照ください。

MariaDBとのデータベースTLS接続

MariaDBを使用している場合、DBTLSConnect パラメータの'verify_ca'オプションによるデータベースTLS接続はサポートされていません。

MySQL/MariaDBで発生する可能性のあるデッドロック

高負荷で動作し、複数のLLDワーカーが関与している場合、行ロック戦略に関連するInnoDBエラーが原因でデッドロックが発生する可能性があります(上流バグを参照)。このエラーは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チェック

Debian 9（stretch）以前およびUbuntu 16.04（xenial）以前の標準OpenIPMIライブラリパッケージでは、IPMIチェックは動作しません。これを修正するには、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チェックでのみ使用されるリクエストメソッドパラメータが、Zabbix 4.0以前のバージョンからのアップグレードの結果として、すべてのアイテムでデフォルト以外の値「1」に誤って設定されている場合があります。この状況を修正する方法の詳細については、ZBX-19308を参照してください。

Web監視とHTTPエージェント

Zabbixサーバーは、WebシナリオまたはHTTPエージェントで「SSL verify peer」が有効になっている場合、一部のLinuxディストリビューションで上流のバグによりメモリリークが発生します。詳細および利用可能な回避策については、ZBX-10486を参照してください。

シンプルチェック

fping v3.10より前のバージョンには、重複したエコーリプレイパケットを誤って処理するバグがあります。これにより、icmpping、icmppingloss、icmppingsecアイテムで予期しない結果が発生する可能性があります。 fpingの最新バージョンを使用することを推奨します。詳細はZBX-11726をご覧ください。

rootlessコンテナでのfping実行時のエラー

コンテナがrootlessモードまたは特定の制限環境で実行されている場合、ICMPチェックを実行する際にfpingの実行に関連するエラー（例：fping: Operation not permittedや、すべてのリソースへのパケットが失われる）に直面することがあります。

この問題を修正するには、"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 agent 2 (6.0.5以前)のアップグレード

パッケージからZabbix agent 2 (バージョン6.0.5以前)をアップグレードする際、プラグイン関連のファイル競合エラーが発生する場合があります。このエラーを修正するには、必要に応じてagent 2の設定をバックアップし、agent 2をアンインストールして再インストールしてください。

RHEL系システムでは、以下を実行します:

dnf remove zabbix-agent2
dnf install zabbix-agent2

Debian系システムでは、以下を実行します:

apt remove zabbix-agent2
apt install zabbix-agent2

詳細はZBX-23250を参照してください。

フロントエンドのロケールが切り替わる

フロントエンドのロケールが明確な理由もなく切り替わる、つまり、あるページ（またはページの一部）がある言語で表示され、他のページ（またはページの一部）が別の言語で表示されることがあることが確認されています。この問題は、複数のユーザーがいて、そのうちの一部があるロケールを使用し、他のユーザーが別のロケールを使用している場合によく発生します。

この問題の既知の回避策は、PHPおよびApacheでマルチスレッドを無効にすることです。

この問題は、PHPでのロケールの設定の仕組みに関連しています。ロケール情報はスレッドごとではなく、プロセスごとに保持されます。したがって、マルチスレッド環境では、同じApacheプロセスで複数のプロジェクトが実行されている場合、別のスレッドでロケールが変更され、その結果Zabbixのスレッドでデータの処理方法が変わる可能性があります。

詳細については、関連する問題レポートを参照してください:

ZBX-10911（フロントエンドのロケールが切り替わる問題）
ZBX-16297（BC Math関数のbcdiv関数を使用したグラフでの数値処理の問題）

グラフ

グラフ（クラシック）の問題

クラシックグラフで問題が発生する場合は、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時間未満の期間のグラフで合計集計を使用すると、データがトレンドから取得される場合に、グラフに誤った（増幅された）値が表示されます。

テキストの重なり

一部のWebインターフェース言語（例: 日本語）では、ローカルフォントが原因でグラフの凡例内のテキストが重なることがあります。これを回避するには、PHP GD拡張モジュールのバージョン2.3.0以降を使用してください。

ログファイルの監視

ファイルシステムが100%フルで、ログファイルが追記されている場合、log[] および logrt[] アイテムはログファイルの先頭から繰り返し再読み込みします（詳細は ZBX-10884 を参照してください）。

遅いMySQLクエリ

Zabbixサーバーは、アイテムの値が存在しない場合に遅いSELECTクエリを生成します。この問題はMySQL 5.6/5.7バージョンで発生することが知られています（詳細な議論についてはZBX-10652を参照）。また、特定の場合にはそれ以降のMySQLバージョンでも発生する可能性があります。これに対する回避策としては、MySQLでindex_condition_pushdownまたはprefer_ordering_indexオプティマイザを無効にすることです。ただし、この回避策ですべての遅いクエリに関連する問題が解決するわけではないことに注意してください。

リンクからのフィルター設定の永続化

フィルター設定（時間セレクターを含む）を含むZabbixフロントエンドページへのリンクを開くと、そのフィルターは自動的にデータベースにユーザーごとに保存され、そのページの以前に保存されたフィルターや時間セレクターの設定が置き換えられます。これらの設定は、ユーザーが手動で更新またはリセットするまで有効です。

SNMPv3トラップにおけるIPv6アドレスの問題

net-snmpのバグにより、SNMPトラップでSNMPv3を使用する場合、IPv6アドレスが正しく表示されないことがあります。詳細および回避策については、ZBX-14541を参照してください。

失敗したログイン情報での長いIPv6 IPアドレスの切り捨て

失敗したログイン試行メッセージでは、データベースフィールドの文字数制限が39文字のため、格納された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を使用したセットアップウィザード

フロントエンドのセットアップウィザードは、NGINX + php-fpmを使用したSUSEで設定ファイルを保存できません。これは、/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=$1

Apacheがリクエストを処理するためにスクリプトを直接実行する場合(例: 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サービス用Chromium

ほとんどの場合、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.

このエラーは、ユーザー'zabbix'のホームディレクトリとして/var/lib/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サーバーまたはプロキシに送信されます。エラーの原因を特定するには、Azureのログを参照してください。

PCRE2への切り替え後の無効な正規表現

Zabbix 6.0でPCRE2のサポートが追加されました。 PCREも引き続きサポートされていますが、RHEL 7以降、SLES（全バージョン）、Debian 9以降、Ubuntu 16.04以降のZabbixインストールパッケージはPCRE2を使用するように更新されています。多くの利点がある一方で、PCRE2への切り替えにより、既存のPCRE正規表現パターンの一部が無効になったり、異なる動作をする場合があります。特に、パターン \^[\w-\.] に影響します。この正規表現を意味を変えずに再び有効にするには、式を \^[-\w\.] に変更してください。これは、PCRE2がダッシュ記号を区切り文字として扱い、文字クラス内で範囲を作成するために発生します。

Invalid regular expressions with parentheses in character class

A regular expression containing a parenthesis inside a character class (e.g., [(]) is rejected as invalid.

This can occur anywhere a regular expression is entered or imported, including preprocessing steps, template import, scripts, regular expression testing, icon mapping, and value mapping.

The issue has been fixed in Zabbix 7.4.6. For more details, see ZBX-26303.

Geomapウィジェットのエラー

NGINXを使用している古いZabbixバージョンからアップグレードし、アップグレード時に新しいNGINX設定ファイルに切り替えなかった場合、Geomapウィジェットの地図が正しく読み込まれないことがあります。

この問題を解決するには、古い設定ファイルを破棄し、現在のバージョンパッケージの設定ファイルを使用し、ダウンロード手順の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;
}

前処理 — グローバル変数は安全ではありません

前処理のJavaScriptはリクエストごとに実行されますが、宣言されていない識別子への代入（例: secret = value）は暗黙的なグローバル変数を作成し、現在の実行を超えて持続する可能性があります。暗黙的なグローバル変数に機密データ（トークン、パスワードなど）を保存すると、後続の前処理実行や同じ環境で実行される他の統合によって、偶発的な漏洩や再利用のリスクが高まります。

暗黙的なグローバル変数に依存しないでください。常にvarやconstで変数を宣言し、グローバルオブジェクト（例: globalThisやwindow）に秘密情報を付与しないでください。前処理内から組み込みのグローバルオブジェクトを上書きするサポートされた方法はありません。

安全な例:

var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });

Windowsのプロセッサグループ

Microsoftのドキュメントによると、64個未満の論理プロセッサを持つシステムには常に1つのプロセッサグループ（グループ0）しかありません。しかし、Zabbixユーザーからは、64個以下の論理プロセッサを持つシステムで2つのプロセッサグループが存在するという稀なバグZBX-20260が報告されています。この結果、2つのプロセッサグループのうち1つのプロセッサグループに対してのみ"\Processor(n)"パフォーマンスカウンタが存在することになります。このバグの実際の根本原因は不明です。しかし、stackoverflow.comで同様のケースが説明されており、そこではBIOSとWindowsの相互運用に根本原因がありました。

utf8mb4照合順序によるフィルタリングの制限

フィルタ（例：データ収集 > メンテナンス）は、特定のUnicode文字（例：ȼ、ɇ）を含むエンティティに適用した場合、正しく機能しないことがあります。この問題は、MySQLまたはMariaDBデータベースのデフォルトのutf8mb4_bin照合順序が、Unicode文字のソートや比較をどのように処理するかによって発生します。

この制限に対処するには、データベースのカラムの照合順序をutf8mb4_0900_bin、utf8mb4_0900_ai_ci、utf8mb4_unicode_520_ciなどの代替案に変更することができます。ただし、照合順序を変更すると、空白の扱いや他の文字のソートやフィルタリングで予期しない動作が発生する可能性があることに注意してください。

照合順序の変更についての詳細は、MySQLドキュメントまたはMariaDBドキュメントを参照してください。照合順序の違いについては、MySQLドキュメントのUnicode文字セットを参照してください。

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.conf

3. 対象プロセスに signal 5 を送信して、プロファイルのダンプをトリガーします。
1234 は実際のプロセス ID (PID) に置き換えてください:

kill -5 1234

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 がほぼすべてのメモリ割り当てを担当しています。

マルチプライマリモードでの 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;]

このエラーは、外部キー制約を伴うロールバック処理の問題によって発生しているようです。

What’s next?

1 コンパイルの問題

Docs

8 既知の問題

7.4.4 の既知の問題