BLOG

2022 年 09 月 13 日

Zabbix の Web フロントエンドが表示できない原因と改善方法

Web フロントエンドが表示できない・読み込みが遅い事象でよくある原因と改善方法について紹介します。

お客様からの問い合わせでよくある事象として「Web フロントエンドにアクセスできなくなった」「Web フロントエンドの表示が遅い」といったものがあります。
本記事ではこのような事象でよくある原因と改善方法を紹介します。

対象バージョン
 原因 1：Web フロントエンドの設定
 原因 2：php-fpm, apache の設定
 原因 3：未解決の障害
 原因 4：データベースの高負荷
 原因 5：Trapper プロセスの高負荷
 原因 6：マシンのリソース不足

対象バージョン

Zabbix 2.0
Zabbix 2.2
Zabbix 3.0
Zabbix 4.0
Zabbix 5.0
Zabbix 6.0

原因 1：Web フロントエンドの設定

問題の概要

Web フロントエンドの設定が、そのマシンの性能で処理できる量を超えたデータを処理するように設定されてしまっていることでデータ処理に時間がかかり、メモリ不足になることがあります。

改善策

表示するデータが多いことの改善策として、フィルタや表示期間の設定で対象となるデータを絞り込むことや以下の設定から表示件数の上限を減らすことが挙げられます。

[ 管理 ]->[ 一般設定 ]->[ 表示設定 ]

検索 / フィルタの項目の上限値
テーブルセル内のリストの最大項目数

フィルタや表示期間の設定で対象となるデータを絞り込む

ダッシュボードでは、ウィジェット毎に表示する行数を設定できます。

なお、上記を設定しても後述の未解決の障害が原因の場合は、ダッシュボードの [ 深刻度ごとの障害数 ]、[ 障害 ]、[ ホスト ]、[ 概要 ]、[ マップ ] 等のページが表示できなくなることや読み込みに時間がかかることがあります。

原因 2：php-fpm, apache の設定

問題の概要

Web フロントエンドの処理を行う php-fpm または apache のメモリ使用量が上限に達して必要なメモリを確保できないことがあります。
php-fpm や apache のメモリ使用量が増加する原因としては、Web フロントエンドの処理で扱うデータが多いことやメモリリーク等があります。

改善策

下記設定を変更してメモリ使用量の上限を上げることやプロセス数等を変更することが改善策となります。

php-fpm を利用している場合

/etc/php-fpm.d/zabbix.conf
ML7 系においては /etc/opt/rh/rh-php72/php-fpm.d/zabbix.conf（SCL の rh-php72 の場合。バージョンによって適切なパスに読み替えてください）

pm.max_children
pm.max_requests
php_value[memory_limit]

mod_php を利用している場合

/etc/httpd/conf.d/zabbix.conf
php_value memory_limit

php-fpm、apache の設定については以下の記事でも紹介しています。

原因 3：未解決の障害

問題の概要

未解決の障害イベントが多く溜まると PHP のメモリを大量に消費し、メモリ使用量の上限に達することがあります。
この問題は、Zabbix 4.0 以上のバージョンで発生します。

改善策 1

以下のように未解決の障害をクローズすることでメモリ使用量を抑えることができます。

トリガーの設定から「手動クローズを許可」にチェックを入れる

[ 監視データ ]->[ 障害 ] ページから対象の障害を選択して一括更新を押下する

「障害のクローズ」にチェックを入れ更新を押下する

改善策 2

同じトリガーの障害イベントで頻繁に手動クローズしているような場合、復旧できるような閾値となるようトリガー条件式を変更することも対策となります。

改善策 3

復旧しないトリガーを作成しないことも対策となります。

復旧しないトリガー条件式の例

バージョン 5.0 以前

{host:key.regexp(.*)}=1

バージョン 6.0 以降

find(/host/key,,regexp,.*)=1

上記のようなトリガー条件式では、取得した全ての値を障害判定するため復旧しません。
障害判定する値を限定することや一定時間後に復旧するような条件式を設定することが改善策として挙げられます。

30 秒以上値を取得しない場合に復旧するトリガー条件式の例

バージョン 5.0 以前
障害の条件式

{host:key.regexp(.*,30)}=1

復旧条件式

{host:key.nodata(30)}<>0

バージョン 6.0 以降
障害の条件式

find(/host/key,30s,regexp,.*)=1

復旧条件式

nodata(/host/key,30)<>0

原因 4：データベースの高負荷

問題の概要

データベースの高負荷によってデータベースにアクセスが必要な処理で遅延やタイムアウトが発生することがあります。

top コマンドや ps コマンド等で利用している DB（mysqld, postgres）の CPU 使用率やメモリ使用率を確認できます。

改善策

データベースは様々な原因で高負荷となります。
解消するにはそれぞれに合わせた対応が必要となります。

中でもよくある原因として、ログ監視や SNMP トラップ監視で短期間に大量の値を取得したことが挙げられます。

一時的な事象であれば、負荷が下がるまで待つだけでも良いですが、長期間継続するような場合には取得対象を絞ることやアイテム数を減らす等の対応をしてください。

原因 5：Trapper プロセスの高負荷

問題の概要

Zabbix の Web フロントエンドでは基本的に直接データベースへアクセスして情報を取得しますが、一部のページや機能（アイテムのテスト等）では Zabbix サーバの Trapper プロセスと通信します。

Zabbix サーバが起動しているにも拘わらず Web フロントエンドに「Zabbix サーバーが動作していません」と警告が表示される場合やアイテムのテストが実行できない場合は、Trapper プロセスの高負荷が原因として考えられます。

Trapper プロセスが高負荷となる原因としては、ログ監視等のアクティブ監視や Zabbix トラッパーアイテムの監視で短期間に大量の値を受け取ったことが挙げられます。

改善策 1

一時的な事象であれば、負荷が下がるまで待つだけでも良いですが、長期間継続している場合は、アクティブ監視や Zabbix トラッパーアイテムの数を減らすことが対策となります。

スクリプト等で Zabbix トラップを送信している場合は、実行間隔を開けることや送信するデータを減らすことも対策となります。

改善策 2

メモリに余裕がある場合は、Trapper プロセスの起動数を増やすことも改善策となります。

zabbix_server.conf の StartTrappers パラメータで Trapper プロセスの起動数を設定することができます。

### Option: StartTrappers
#       Number of pre-forked instances of trappers.
#       Trappers accept incoming connections from Zabbix sender, active agents and active proxies.
#       At least one trapper process must be running to display server availability and view queue
#       in the frontend.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartTrappers=5