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 照合順序に変換することを強く推奨します。

libcurl 8.21.0 におけるメモリおよびファイルディスクリプタのリーク

libcurl 8.21.0 の既知の問題により、TLS で保護された接続を処理する際に、libcurl を使用する Zabbix の機能でメモリおよびファイルディスクリプタのリークが発生する可能性があります。
この問題の回避策としては、修正を含むリリースが利用可能になるまで libcurl を 8.20.0 にダウングレードしてください。

テンプレート

デュアルスタック（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リポジトリのパッケージに対して署名鍵の有効期限切れの問題が発生する場合があります。署名鍵が有効期限切れになると、パッケージ署名の検証を試みても、証明書または鍵が有効でないことを示すエラーが発生します。例:

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リポジトリから正しいものに置き換えてください）。

例えば、RHEL 10の場合は次のコマンドを実行します:

rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/10/noarch/zabbix-release-latest.el10.noarch.rpm

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

dnf update

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

MariaDB を使用したデータベース TLS 接続

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

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

高負荷で動作し、複数のLLDワーカーが関与している場合、行ロック戦略に関連するInnoDBエラーが原因でデッドロックが発生する可能性があります(上流バグを参照)。このエラーはMySQL 8.0.29以降で修正されていますが、MariaDBでは修正されていません。詳細はZBX-21506を参照してください。

グローバルイベントの相関

最初のイベントと2番目のイベントの間隔が非常に短い場合、つまり0.5秒以下の場合、イベントが正しく相関されないことがあります。

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 を使用するセットアップウィザード

Webインターフェースのセットアップウィザードは、SUSE で NGINX + php-fpm を使用している場合に設定ファイルを保存できません。これは、/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がダッシュ記号を区切り文字として扱い、文字クラス内で範囲を作成するために発生します。

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 });

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文字セットを参照してください。

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?

要件

Docs

既知の問題

アップグレード

正常なアップグレードのためのSQLモード設定

MariaDB 10.2.1以前でのアップグレード