参照: コンパイルの問題
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の場合:
MySQL/MariaDBのsql_mode
設定には、"STRICT_TRANS_TABLES"モードが設定されている必要があります。これが設定されていない場合、 Zabbixデータベースのアップグレードは失敗します (参照: ZBX-19435)。
データベーステーブルがMariaDB 10.2.1以前で作成された場合、Zabbixのアップグレードが失敗することがあります。これは、これらのバージョンではデフォルトの行形式がコンパクトであるためです。行形式をダイナミックに変更することで、この問題を修正できます (参照: ZBX-17690)。
デュアルスタック環境(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をインストールすると、公式のZabbixパッケージではなくEPEL Zabbixパッケージがインストールされます。
この場合、EPELからZabbixパッケージをアンインストールする、つまり、
EPELからZabbixパッケージをブロックします。 /etc/yum.conf
ファイルに次の行を追加します。
Zabbixサーバーをもう一度インストールします。
公式Zabbixパッケージには、バージョン文字列にrelease
という単語があることに注意してください。
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を参照してください。
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 9では次を実行します:
次に、リポジトリ情報を更新します:
詳細については、ZBX-24761を参照してください。
MariaDBが使用されている場合、DBTLSConnectパラメーターの'verify_ca'オプションではデータベースTLS接続はサポートされません。
負荷が高く、複数のLLD処理が実行されている場合、行ロック処理に関するInnoDBエラーが原因でデッドロックが発生する可能性があります (上流のバグ参照))。 このエラーは、MySQL 8.0.29で修正されましたが、MariaDBでは修正されていません。詳細は、ZBX-21506を参照してください。
最初のイベントと2番目のイベントの時間間隔が非常に小さい場合(0.5秒以下)、イベントは正しく相関しないことがあります。
PostgreSQL 11以前のバージョンでは、浮動小数点値の範囲は -1.34E-154 から 1.34E+154 程度までしかサポートされていません。
NetBSDバージョン8.Xおよび9.Xでは、起動時にZabbixのプロセスがランダムにクラッシュする場合があります。これは、デフォルトのスタックサイズ(4MB)が小さすぎることが原因です。以下のコマンドを実行してスタックサイズを増やす必要があります。
詳細については、関連する問題レポートZBX-18275を参照してください。
Zabbixエージェント2は、標準のGo正規表現ライブラリの制限により、正規表現の先読みと後読みをサポートしていません。
Debian 9 (stretch)以前、およびUbuntu 16.04 (xenial)以前のバージョンでは、標準のOpenIPMIライブラリパッケージではIPMI チェックが動作しません。 この問題を修正するには、ZBX-6139の説明に従ってOpenSSLを有効にし、OpenIPMIライブラリを再コンパイルしてください。
libssh2ライブラリがパッケージからインストールされている場合、Debian、Ubuntuなどの一部のLinuxディストリビューションは、暗号化された秘密鍵(パスフレーズ付き)をサポートしません。詳細については、ZBX-4850を参照してください。
OpenSSH 8を使用していくつかのLinuxディストリビューションでLIBSSH 0.9.xを使用する場合、SSHチェックは「SSH Serverからデータを読み取ることができない」と報告する場合があります。これは、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チェックでのみ使用されるリクエストメソッドパラメーターが、4.0以前のZabbixからアップグレードした結果、 すべてのアイテムにデフォルト値ではない'1'が設定されることがあります。 この問題の解決方法の詳細については、ZBX-19308を参照してください。
いくつかのLinuxディストリビューション上で、WebシナリオやHTTPエージェント内で「SSLピア検証」を有効にしていた時にupstream bugによってメモリリークが発生します。 ZBX-10486を参照してより詳細な情報と回避策を確認してください。
v3.10より前のバージョンのfpingには、重複するエコーリプレイパケットを適切に処理できないバグがあります。これにより、icmpping
、icmppingloss
、icmppingsec
の各アイテムで予期しない結果が発生する可能性があります。最新バージョンのfpingを使用することをお勧めします。詳細については、ZBX-11726を参照してください。
コンテナがrootlessモードまたは特定の制限のある環境で実行されている状態でICMPチェックを実行する際に、fping: Operation not permitted
やすべてのリソースへのすべてのパケットが失われるなど、fping実行に関連するエラーが発生する可能性があります。
この問題を解決するには、"docker run"または"podman run"コマンドに--cap-add=net_raw
を追加します。
さらに、非ルート環境でfpingを実行するには、sysctlの変更が必要になる場合があります。例:
この"1995"はzabbix GIDです。詳細については、ZBX-22833を参照してください。
OpenBSDオペレーティングシステムをご利用の場合、バージョン5.7.3までのNet-SNMPライブラリに存在するUAF(Use After Free)バグにより、Zabbixサーバー設定ファイルでSourceIPパラメーターが設定されているとZabbixサーバーがクラッシュする可能性があります。回避策として、SourceIPパラメーターを設定しないでください。Linuxでも同じ問題が発生しますが、Zabbixサーバーが動作を停止することはありません。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を参照してください。
Zabbixエージェント2 (バージョン6.0.5以前)をパッケージからアップグレードすると、プラグイン関連のファイル競合エラーが発生する場合があります。 エラーを修正するには、(必要に応じて)エージェント2の構成をバックアップし、エージェント2をアンインストールして、新たにインストールします。
RHELベースのシステムでは、次を実行します:
Debianベースのシステムでは、次のコマンドを実行します:
詳細については、ZBX-23250を参照してください。
Webインターフェースの言語設定が、明確なロジックなしに切り替わる場合があることが確認されています。例えば、一部のページ(またはページの一部)がある言語で表示され、他のページ(またはページの一部)が別の言語で表示されることがあります。 この問題は、複数のユーザーがいて、一部のユーザーがあるロケールを使用し、他のユーザーが別のロケールを使用している場合に発生する可能性があります。
この問題の既知の回避策として、PHPとApacheのマルチスレッドを無効にすることが挙げられます。
この問題は、PHPにおけるロケール設定の仕組みに関係しています。ロケール情報はスレッドごとではなくプロセスごとに保持されます。そのため、マルチスレッド環境で、同じApacheプロセスで複数のプロジェクトが実行されている場合、別のスレッドでロケールが変更され、Zabbixスレッドでのデータ処理方法が変更される可能性があります。
詳細については、関連する問題レポートをご覧ください:
夏時間(DST)への変更により、X軸ラベルの表示が不規則になります (日付の重複、日付の欠落など)。
1時間未満の期間のグラフで合計集計を使用すると、データがトレンドから取得されたときに、グラフに誤った(乗算された)値が表示されます。
一部のフロントエンド言語(日本語など)の場合、ローカルフォントはグラフ凡例でテキストが重なる可能性があります。これを避けるために、PHP GD拡張のバージョン2.3.0(以降)を使用します。
アイテムlog[]
およびlogrt[]
は、ファイルシステムが100%使用されていてログファイルに追加される場合、ログファイルを先頭から繰り返し再読み込みします (詳細については、ZBX-10884を参照してください) 。
Zabbixサーバーはアイテムの存在しない値がある場合、スローSELECT
クエリを生成します。 この問題は、MySQL 5.6/5.7バージョンで発生することが知られています(拡張された議論については、ZBX-10652を参照してください)。そして特定の場合、後のMySQLバージョンでも発生する場合があります。 これに対する回避策は、MySQLのindex_condition_pushdown
またはfirep_ordering_index
オプティマイザーを無効にすることです。 ただし、この回避策は、スロークエリに関連するすべての問題を修正しない場合があることに注意してください。
Oracle DBでアイテム数とアイテム前処理ステップ数が多い場合、Zabbixインストールで構成同期が遅くなる可能性があります。 これは、Oracleデータベースエンジンのnclob型フィールドの処理速度が原因です。
パフォーマンスを向上させるにはデータベースパッチitems_nvarchar_prepare.sql を手動で適用して、フィールドタイプをnclobからnvarchar2に変換します。 この変換により、アイテムの保存前処理パラメータおよびアイテムのパラメータ(説明、タイプ:スクリプトのフィールドスクリプト、アタイプ:HTTPエージェントのフィールドリクエストボディおよびヘッダー、タイプ:データベースモニタのフィールド SQLクエリなど)の最大フィールドサイズ制限が65535バイトから4000バイトになることに注意してください。 パッチを適用する前に削除する必要があるテンプレート名を決定するためのクエリは、パッチ内にコメントとして提供されています。または、MAX_STRING_SIZEが設定されている場合は、パッチクエリでnvarchar2(4000)をnvarchar2(32767)に変更して、32767バイトのフィールドサイズ制限を設定できます。
詳細な説明については、ZBX-22363を参照してください。
期間セレクターを含むフィルター設定を含む Zabbix フロントエンド ページへのリンクを開くと、フィルターは自動的にユーザーのデータベースに保存され、そのページの以前に保存されたフィルターや期間セレクターの設定が置き換えられます。これらの設定は、ユーザーが手動で更新またはリセットするまでアクティブなままです。
net-snmpのバグにより、SNMPトラップでSNMPv3を使用すると、IPv6アドレスが正しく表示されない場合があります。詳細と回避策については、ZBX-14541を参照してください。
ログイン失敗メッセージには、データベースフィールドの文字数制限である最初の39文字のみが表示されます。そのため、39文字を超えるIPv6 IPアドレスは不完全な形で表示されます。
Zabbixエージェント設定ファイル(zabbix_agentd.conf)のServer
パラメーターに存在しないDNSエントリがあると、Windows上でZabbixエージェントの応答時間が長くなる可能性があります。これは、Windows DNSキャッシュデーモンがIPv4アドレスの否定応答をキャッシュしないために発生します。ただし、IPv6アドレスの場合は否定応答がキャッシュされるため、回避策としてホストでIPv4を無効にすることが考えられます。
YAMLのエクスポート/インポートには、いくつかの既知の問題があります。
SUSEでNGINX + php-fpmを使用している場合、フロントエンドのセットアップウィザードは設定ファイルを保存できません。これは、/usr/lib/systemd/system/php-fpm.serviceユニットの設定により、Zabbixが/etcに書き込みできないことが原因です(PHP 7.4で導入されました)。
回避策は2つあります。
ApacheまたはNGINXが、APIリクエスト内の認証ヘッダーをZabbixに転送できない場合があります。 これにより、Zabbix APIやOktaを使用したSAMLといったシングルサインオン(SSO)サービスの使用時に認証の問題が発生する可能性があります。
この問題を解決するには、Webサーバーの設定を更新してください。
Apacheをリバースプロキシ(CGI以外の設定)として使用する場合は、(RHELベースシステムの場合) /etc/httpd/conf/httpd.conf
または(Debian/Ubuntuの場合) /etc/apache2/apache2.conf
に次のディレクティブを追加してください。
Apacheがリクエストを処理するためにスクリプトを直接実行する場合(例: mod_cgiを使用)、代わりに次のディレクティブを追加してください。
一方、NGINXはAuthorizationヘッダーを自動的に処理します。 ただし、NGINXがリバースプロキシとして動作している場合は、/etc/nginx/nginx.conf
(Zabbixフロントエンドの場所)に以下のディレクティブを追加することで、Authorizationヘッダーを明示的に転送できます。
...
location / {
...
proxy_set_header Authorization $http_authorization;
proxy_pass http://backend_server;
...
}
設定を更新したら、Webサーバーを再起動してください。
詳細については、以下を参照してください:
ほとんどの場合、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'のホームディレクトリとして使用されるために発生します。
Zabbixはバックエンドデータベースにアクセスできないことを検出すると、通知を送信し、接続を試行し続けます。特定のデータベースエンジンでは固有のエラーコードが認識されます。 MySQLで認識されるエラーコードは次のとおりです:
さらに、Azure上のMySQLインストールでZabbixを使用している場合、不明瞭なエラーメッセージ[9002] Some errors occurredがZabbixログに表示されることがあります。この一般的なエラーテキストは、データベースからZabbixサーバーまたはプロキシに送信されます。エラーの原因について詳しくは、Azureログを確認してください。
Zabbix 6.0では、PCRE2のサポートが追加されました。 PCREは現在もサポートされていますが、RHEL 7以降、SLES (全バージョン)、Debian 9以降、Ubuntu 16.04以降のZabbixインストールパッケージは、PCRE2を使用するように更新されました。 PCRE2への切り替えは多くの利点を提供する一方で、特定の既存のPCRE Regexpパターンが無効になったり、異なる動作をしたりする可能性があります。 特に、パターン^[\w-\.]に影響します。 このregexpをセマンティクスに影響することなく再度有効にするために、式を^[-\w\.]に変更します。 これは、PCRE2がダッシュ記号を区切り文字として扱い、文字クラス内に範囲を作成するために発生します。
NGINXを使用して古いバージョンのZabbixからアップグレードし、アップグレード中に新しいNGINX設定ファイルに切り替えなかった場合、Geomapウィジェットの地図が正しく読み込まれないことがあります。
この問題を解決するには、古い設定ファイルを破棄し、現在のバージョンのパッケージの設定ファイルを使用し、e. ZabbixフロントエンドのPHPの設定セクションのdownload instructionsに記載されている方法で再設定することができます。
または、既存のNGINX設定ファイル(通常、/etc/zabbix/nginx.conf)を手動で編集することができます。これを行うには、ファイルを開き以下のブロックを探します:
そして、このブロックを次のように置き換えます:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
グローバル変数は異なるWebhook呼び出し間で共有されるため、次のコードを実行すると、タグ値カウンターが徐々に増加します:
try
{
aa = aa + 1;
}
catch(e)
{
aa = 0;
}
result = {
'tags': {
'endpoint': aa
}
};
return JSON.stringify(result);
各スクリプトが独自のデータで動作し、同時呼び出し間での競合を抑止する為には、グローバル変数ではなくローカル変数を使用ください。
PostgreSQL/TimescaleDBを含むZabbix 7.0.0からZabbix 7.0.1以降にアップグレードすると、サーバーがクラッシュします。この問題は、Zabbix 7.0の監査ログテーブルの圧縮ジョブに関する問題に対する回避策によって、監査ログテーブルの圧縮ポリシーが不可逆的に変更されたことが原因で発生します。
この問題を解決するには、監査ログテーブルを手動で再構築してください。問題のある監査ログテーブルは、次のクエリで検出できます:
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ドキュメントも参照してください。
パーティショニングに必要なタイムスタンプは、カスタム関数を使用してauditid
フィールドから抽出されるため、timescaledb-extrasからのデータ移行に使用されるヘルパープロシージャは機能しません。
Zabbix 7.0.0-7.0.4で作成されたPostgreSQL/TimescaleDBバックアップをpg_restore
を使用して復元すると、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ドキュメント(追加のバックアップおよびリストアオプション)も参照してください。
Microsoftのドキュメントでは、64個未満の論理プロセッサを持つシステムでは常に1つのプロセッサグループ、Group 0があると説明されています。ただし、Zabbixのユーザーから、64個以下の論理プロセッサを持つシステムに2つのプロセッサグループがある場合に発生する稀なバグZBX-20260が報告されています。この結果2つのプロセッサグループのうち1つのプロセッサグループに対してのみ"(n)"パフォーマンスカウンターが使用されるようになりました。このバグの実際の根本原因は不明です。ただし、同様のケースがstackoverflow.comで説明されており、その根本原因はBIOSとWindowsの相互運用性にありました。
フィルタ (例: データ収集 → メンテナンス) は、特定のUnicode文字 (例: ȼ、ɇ) を含むエンティティに適用すると正しく機能しない場合があります。この問題は、MySQLまたはMariaDBデータベースのデフォルトのutf8mb4_bin照合順序がUnicode文字の並べ替えと比較を処理する方法が原因で発生します。
この制限に対処するには、ユーザーはデータベース列の照合順序をutf8mb4_0900_bin、utf8mb4_0900_ai_ci、または utf8mb4_unicode_520_ciなどの代替に変更できます。ただし、照合順序を変更すると、空白の処理や他の文字の並べ替えとフィルタリングで予期しない動作が発生する可能性があることに注意してください。
照合順序の変更の詳細については、以下を参照してください。 MySQLドキュメントまたはMariaDBドキュメント。照合順序の違いの詳細については、MySQLドキュメントのUnicode文字セットを参照してください。
ネストされたホストグループからの情報がマップに不正確に表示されます。例:
バージョン7.0.7では、ローレベルディスカバリルールのオーバーライドの処理時にZabbixサーバーがクラッシュします。 回避策として、オーバーライドを含むLLDルールを無効にします。 この問題はZabbix 7.0.8rc2で修正されました。
スクリプトアイテムパラメーターおよびブラウザアイテムスクリプトパラメーターではマクロ関数が動作しません。Zabbix 7.0.7で修正されました。
Super Admin以外の権限でZabbix Webフロントエンドにアクセスすると、"システムエラーが発生しました。Zabbix管理者に連絡してください。"というメッセージが表示される場合があります。この問題は、MariaDBバージョン10.5.1-10.5.9を使用しているインストールに影響します。
この問題を回避するには、MariaDBを10.5.9以降のバージョンに更新してください。詳細については、ZBX-25746を参照してください。
Zabbixインストールでメモリ使用量が多すぎると思われる場合は、tcmallocのメモリプロファイリング機能を使用して、Zabbixサーバー/プロキシのメモリ消費量を調査できます。
1. Zabbixをソースからインストールする際に、追加のフラグを設定します。
Zabbixサーバー、Zabbixプロキシ、またはZabbixエージェントをビルドするには、-std=gnu99
フラグが必要です。 -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. 対象プロセスにシグナル5を送信して、プロファイルダンプをトリガーします。1234を実際のプロセスID (PID)に置き換えます。
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がほぼすべてのメモリ割り当てを担当しています。
参照:
-std=gnu99
、-g
、-O0
など)については、GCC オプション概要を参照してください。