MIRACLE ZBX 6.0.10および5.0.29にて、MIRACLE ZBXエージェントサービスのユーザーおよびグループがzabbixとなるようにサービス設定ファイルを変更しました。この変更により、当該バージョン以降のMIRACLE ZBXエージェントでは、AllowRoot設定を有効にするだけではrootユーザーでサービスを起動できなくなりました。
本記事では、該当するバージョンのMIRACLE ZBXエージェントをrootユーザーで起動するための手順を説明します。
なお、本記事はMIRACLE ZBXエージェントをrootユーザーで起動することを推奨するものではありません。
systemdを使用しているLinuxにインストールした環境のみ影響を受けます。対象となるOSは以下のとおりです。
OSの表記については動作環境を確認してください。
MIRACLE ZBXエージェントをrootユーザーで起動するための手順を説明します。この手順による変更はパッケージの更新などによって巻き戻ってしまうため、パッケージ更新のさいは実施し直す必要があります。
AllowRoot=1
#User=zabbix
#Group=zabbix
# chown root:zabbix /var/run/zabbix
# chown root:zabbix /var/log/zabbix/zabbix_agentd.log
# systemctl daemon-reload
# systemctl restart zabbix-agent
# ps -ef | grep zabbix_agentd
root 1576 1 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd ...
root 1577 1576 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd: ...
root 1578 1576 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd: ...
root 1579 1576 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd: ...
root 1580 1576 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd: ...
root 1581 1576 0 15:49 ? 00:00:00 /usr/sbin/zabbix_agentd: ...
MIRACLE ZBX 5.0および6.0のaarch64 エージェント/エージェント2ではsystem.hw.cpu
がZBX_NOTSUPPORTED
となり値を取得できない場合があります。
system.hw.cpu
の実装MIRACLE ZBXエージェントならびにエージェント2は/proc/cpuinfo
を読み込みsystem.hw.cpu
の値を取得しています。以下はx86_64 Linux OSにおける/proc/cpuinfo
の例です。
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Silver 4112 CPU @ 2.60GHz
stepping : 4
microcode : 0x2006b06
cpu MHz : 2593.906
cache size : 8448 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid rdseed adx smap xsaveopt arat md_clear flush_l1d arch_capabilities
vmx flags : vnmi invvpid ept_x_only tsc_offset vtpr mtf ept vpid unrestricted_guest
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data retbleed
bogomips : 5187.81
clflush size : 64
cache_alignment : 64
address sizes : 42 bits physical, 48 bits virtual
power management:
エージェントはこの中で次の値を取得しています。
processor
vendor_id
model name
cpu MHz
エージェントがprocessor
番号によるCPUコアごとのクロック周波数を/sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_max_freq
(N
はprocessor
の番号)から取得できず、またvendor_id
・model name
・cpu MHz
いずれかの値も取得できなかった場合、エージェントはZBX_NOTSUPPORTED
エラーを返す実装になっています。
ここでaarch64 Linux OSの/proc/cpuinfo
に、エージェントが読み込む値が含まれていないケースを考えます。これはCentOS Stream 8 aarch64から取得しました。
processor : 0
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 1
また/sys/devices/system/cpu/cpu0
ディレクトリにクロック周波数の情報が配置されていないとします。これもCentOS Stream 8 aarch64の情報です。
# ls /sys/devices/system/cpu/cpu0/
cache crash_notes driver hotplug online regs topology
cpu_capacity crash_notes_size firmware_node node0 power subsystem uevent
このときaarch64のMIRACLE ZBXエージェント/エージェント2は前述した実装にもとづきsystem.hw.cpu
をZBX_NOTSUPPORTED
とします。
したがってaarch64 Linux OS上で稼働させているエージェントのsystem.hw.cpu
がZBX_NOTSUPPORTED
となったさいは上記のシステム情報を確認いただき、クロック周波数のファイル/sys/devices/system/cpu/cpuN
が存在せず/proc/cpuinfo
にvendor_id
・model name
・cpu MHz
いずれかも含まれていない場合はこのキーの値は取得できないことをご承知おきください。
MIRACLE ZBX Webフロントエンドが動作するPHP環境としてphp-fpmを使用している環境では、使用しているPHPのバージョンやphp-fpmの設定内容によってphp-fpmプロセスのメモリ使用量が増加し、システムに支障をきたす場合があります。php-fpmのメモリ使用量が増加する問題について原因と対策を解説します。
MIRACLE ZBXアプライアンス製品では、以下のバージョンが影響を受けます。
MIRACLE ZBXパッケージを使用して構築している場合、以下のバージョンが影響を受ける可能性があります。
php-fpmのメモリ使用量が増える原因として以下の2つがあります。
使用しているPHPのバージョンによってはメモリリークの不具合の影響を受ける可能性があります。例えば、MySQLiやMySQLndモジュールについて以下のようなメモリリークの不具合が報告されています。
PHPのメモリ管理の仕組み上、処理が完了してもオブジェクトに割り当てられたメモリが解放されず、ガベージコレクション機構によって後からメモリが解放されることがあります。そのため、ガベージコレクションが動作するまでの間、php-fpmプロセスのメモリ使用量が増加します。
PHPのガベージコレクションについては、公式ドキュメントのガベージコレクションを参照してください。
php-fpmプロセスのメモリ使用量が増加する問題への対策として、次の2点を実施してください。
メモリリークなどの不具合が修正されているバージョンを使用するため、PHPパッケージをアップデートする必要があります。OSがサポートしている最新バージョンを使用することを推奨します。MIRACLE LINUX8系OSではPHP 7.4、MIRACLE LINUX 7系OSではSoftware CollectionsのPHP 7.3が最新バージョンとなっています。詳細についてはパッケージ提供元に確認してください。
パッケージのアップデート手順について、MIRACLE ZBX Virtual Appliance V5.0を使用している場合はMIRACLE ZBX Virtual Appliance V5.0でのPHPのアップデートについてを参照してください。その他の環境を使用している場合はパッケージ提供元に確認してください。
PHPの仕様を考慮すると、問題の2つ目の原因として挙げている解放されずに残るオブジェクトによってメモリ使用量が増加する事象については根本的に解決することができません。php-fpmプロセスの設定を変更してシステム全体への影響を低減することが問題への対策となります。
設定変更の内容として次の2点が挙げられます。
php-fpmは多数のリクエストを処理するために複数プロセスで動作するようになっています。このプロセス数を少なくすることにより、プロセス1つあたりのメモリ使用量が増加してもphp-fpm全体としてのメモリ使用量を抑えることができます。
設定ファイル/etc/php-fpm.d/zabbix.conf
を編集しpm.max_children
の値を変更してください。使用環境によって適正な値は変わるため、環境に合わせて設定値を調整してください。例として、プロセス数の上限を5に設定する場合は以下のようになります。
pm.max_children = 5
解放されずに残ったオブジェクトに割り当てられたメモリはガベージコレクションによって解放されますが、ガベージコレクションが動作するのを待たずにphp-fpmのプロセスを再起動することを推奨します。
ガベージコレクションは頻繁に動作するものではないため定常的にメモリ使用量を小さくできるわけではなく、動作する際に負荷が高くなる可能性があるためです。また、MIRACLE ZBX Webフロントエンドに割り当てられるメモリはそれほど多くないという事情を考慮すると、ガベージコレクションが動作するよりも先にメモリ不足による実行時エラーが発生する可能性もあります。
php-fpmプロセスを定期的に再起動するには、設定ファイル/etc/php-fpm.d/zabbix.conf
を編集してpm.max_requests
を設定してください。このパラメーターを設定すると、指定された回数だけリクエストを処理した後にプロセスを再起動するようになります。使用環境によって適正な値は変わるため、環境に合わせて設定値を調整してください。例として、リクエストを500回処理した後にプロセスを再起動する場合は以下のようになります。
pm.max_requests = 500
log_slow_queries
の 追加proc_info
キーにcpu_time
オプションの実装{ITEM.TYPE}
の追加local0
~local7
を選択できる機能を追加web.page.*
キーのサポ ートを追加value_cache_reset
の追加discard_alerts
の追加MIRACLE ZBX WebフロントエンドでAdmin/guestユーザの標準の言語を日本語(ja_JP)に設定 しています。
MIRACLE ZBX Webフロントエンドのグラフで使用するフォントをDejaVuSansからNotoSansCJKへ変更しています。 MIRACLE ZBX Webフロントエンドを動かすOSがRHEL7系OSまたはAmazon Linux 2の場合はVL-PGothicが使われます。
log_slow_queries
の追加
MIRACLE ZBXサーバ/プロキシのランタイムコントロールにlog_slow_queries
を追加しています。
サーバ/プロキシサービスの再起動なしに設定項目LogSlowQueries
の値を変更でき ます。
設定可能な値は1から3600000です。
# zabbix_server -R log_slow_queries=5000
MIRACLE ZBX Webフロントエンドの「監視データ」->「障害」ページで、 「障害発生時のヒストリを表示」オプションを追加しました。 このオプションが有効になった場合、各障害の列に「ヒストリ ログ」が追加され 障害が発生したアイテムIDとそのヒストリログが表示されます。
telnet.run
に長いコマンド文字列を渡して値を取得するとき、
出力に不要な文字列が含まれてしまう問題を修正しています
(ZBXNEXT-6653)。
ノーマルグラフと積算グラフをCSVとしてダウンロードできる機能を追加しています。 グラフ右上の「CSV」リンクをクリックすることでダウンロードできます。
MIRACLE ZBXサーバ/プロキシパッケージのメジャーバージョンアップデート後に
明示的にコマンドラインで-U
オプションを渡して実行しない限り
データベースのアップグレードがおこなわれないよう修正しています。
データベースのアップデートを進めるには次のように実行します。
# zabbix_server -f -U
ログを確認し、データベースのアップデートが完了したのちにあらためて
systemctl
コマンドからサービスを起動してください。
# systemctl start zabbix-server
Windowsイベントログを監視するキーeventlog
を拡張した
eventlog_ext
キーを実装しています。
このキーはイベントログをグローバル正規表現をもとにフィルタできます。
また正規表現の条件式に「対象のイベントログを指定する」 「除外するイベントログを指定する」を追加しています。 この条件式によって、文字列や重要度、イベントソース、イベントIDをもとに イベントログをフィルタする正規表現を作成できます。
eventlog_ext用の正規表現の条件式は正規表現の編集画面でテストできません。
MIRACLE ZBXではメンテナンス中のホストで発生した障害や メンテナンス中のホストで復旧した障害の通知メールは メンテナンス期間が終了したのちに送信されるように実装を変更しています。
proc_info
キーにcpu_time
オプションの実装
WindowsのMIRACLE ZBXエージェント/エージェント2にてproc_info
キーの第二引数 に
cpu_time
を指定できます。このオプションによってCPU時間を計測できます。
MIRACLE ZBXではキーの長さが2048文字以上のアイテムをZBX_NOTSUPPORTED
エラーとし
監視できないよう実装しています。
{ITEM.TYPE}
の追加マクロ{ITEM.TYPE}
でアイテムの型を文字列で取得できます。
Web監視の設定でヒストリとトレンドの保存期間をそれぞれ設定できるようになりました。
local0
~local7
を選択できる機能を追加
MIRACLE ZBX サーバ/プロキシ/エージェント/エージェント2でログをSyslogへ転送するとき
Syslogのファシリティをlocal0
~local7
まで選ぶことができるようになりました。
web.page.*
キーのサポートを追 加Windowsエージェント/エージェント2で次のキーを使ったアイテムの監視ができるようになり ました。
web.page.get
web.page.perf
web.page.regexp
データベースにMariaDBを使用しているMIRACLE ZBXサーバにて、 以下のテーブルに対し自動でパーティショニングをする機能を追加しています。
history
history_log
history_str
history_text
history_uint
trends
trends_uint
MIRACLE ZBX Webフロントエンドからメンテナンス期間の設定をおこなうさい、
期間のタイプに「毎月」を指定した場合、
日にちに-1
を設定すると当月の最終日(月末)として設定されます。
同様に-2
~-7
を設定すると
当月の月末から1~6日前までとして設定されます。
value_cache_reset
の追加
MIRACLE ZBXサーバのランタイムコントロールにvalue_cache_reset
を追加していま す。
バリューキャッシュをリセットできます。
discard_alerts
の追加
MIRACLE ZBXサーバのランタイムコントロールにdiscard_alerts
を追加しています。
このランタイムコントロールにトリガーIDを渡して実行することで、
そのIDをもつトリガーが無効になります。
無効になったトリガーに紐づく障害はそのトリガーが有効になるまで「障害」ページに表示されません。
例としてトリガーID17656
のトリガーを無効にするには次のように実行します。
# zabbix_server -R discard_alerts=17656
このコマンドを引き続き実行することで複数のトリガーを無効にできます。 3つのトリガーID 17654~17656を無効にするには次のように連続して実行します。
# zabbix_server -R discard_alerts=17654
# zabbix_server -R discard_alerts=17655
# zabbix_server -R discard_alerts=17656
なお次のようにdiscard_alerts
オプションに複数の値を渡すことはできませ ん。
# zabbix_server -R discard_alerts=17654,17655,17656
また値を渡さずに実行すると、現在このランタイムコントロールを通じて無効となった トリガーIDの一覧がログに出力されます。
# zabbix_server -R discard_alerts
トリガーIDにマイナス符号を付けて実行することで無効にしたトリガーIDのアクション実行の抑制を解除できます。 ランタイムコントロールによって無効にされたトリガーID 17654のアクション実行の抑制を解除するには、 次のように実行します。
# zabbix_server -R discard_alerts=-17654
トリガーを再び有効にするにはWebフロントエンドから操作してください。
MIRACLE ZBXサーバにて監査ログをSyslogへ転送できるようになっています。
この機能を有効にするには以下の設定ファイルを編集します。
ここではSyslogのファシリティはlocal2
、プライオリティはnotice
とします。
またWebサーバはApacheとします。
/etc/zabbix/zabbix_server.conf
AuditlogSyslog=1
AuditlogSyslogFacility=local2
AuditlogSyslogPriority=notice
/etc/zabbix/web/zabbix.conf.php
$AUDITLOG_SYSLOG = [
'FACILITY' => LOG_LOCAL2,
'PRIORITY' => LOG_NOTICE,
];
/etc/rsyslog.d/zabbix_auditlog.conf
local2.notice /var/log/zabbix/zabbix_audit.log
上記設定を追加したのちに各種サービスを再起動すると監査ログがSyslogへ転送されます。
# systemctl restart zabbix-server httpd php-fpm rsyslog
MIRACLE ZBX Webフロントエンドのログインユーザのパスワードを内部でハッシュ化するさい、
コストパラメータの値を任意に設定可能な機能を追加しています。
設定は/etc/zabbix/web/zabbix.conf.php
で次のようにおこないます。
$BCRYPT_COST = 14;
MIRACLE ZBX Webフロントエンドの管理者はログインユーザのパスワードポリシーを設定できます。
MIRACLE ZBX 5.0では追加のSQLスクリプトをデータベースに対し実行し、
/etc/zabbix/web/zabbix.conf.php
に以下に示す設定を追加することで
パスワードポリシーを設定できます。
設定項目 | 説明 |
---|---|
MIN_LENGTH |
パスワードの最小長を設定できます。 |
MIN_LOWERCASE_CHARS |
パスワードに最低何文字の小文字を含めるかを設定できます。 |
MIN_UPPERCASE_CHARS |
パスワードに最低何文字の大文字を含めるかを設定できます。 |
MIN_NUMERIC_CHARS |
パスワードに最低何文字の数字を含めるかを設定できます。 |
MIN_OTHER_CHARS |
パスワードに最低何文字の記号を含めるかを設定できます。 |
HISTORY |
設定された数をNとし、過去N回のうちに設定されたパスワードの再利用を制限できます。 |
MAX_DAYS |
パスワードの有効期間を一日単位で設定できます。 |
この機能を有効にするにはSQLスクリプトpwpolicy.sql
を実行します。
ここで、MIRACLE ZBX Webフロントエンドが使用するデータベースをzabbix
とします。
# mysql zabbix -u zabbix -p < /usr/share/doc/miracle-zbx-web-mysql*/pwpolicy.sql
次に設定ファイル/etc/zabbix/web/zabbix.conf.php
を編集します。
$PASSWORD_POLICY = [
'MIN_LENGTH' => 7,
'MIN_LOWERCASE_CHARS' => 1,
'MIN_UPPERCASE_CHARS' => 1,
'MIN_NUMERIC_CHARS' => 1,
'MIN_OTHER_CHARS' => 1,
'HISTORY' => 4,
'MAX_DAYS' => 90,
];
最後にphp-fpm
サービスを再起動します。
# systemctl restart php-fpm
Solaris 11でMIRACLE ZBXエージェントパッケージをインストールしたとき、
インストールスクリプトでzabbix
ユーザとzabbix
グループが
自動的に作成されず次のようなエラーが画面に出力されます。
## Executing preinstall script.
## Installing part 1 of 1.
pkgadd: ERROR: unable to create package object </etc/zabbix>.
pathname does not exist
group name <zabbix> not found in group table(s)
owner name <zabbix> not found in passwd table(s)
/etc/zabbix
/etc/zabbix/zabbix_agentd.conf.new
ERROR: attribute verification of </etc/zabbix/zabbix_agentd.conf.new> failed
group name <zabbix> not found in group table(s)
owner name <zabbix> not found in passwd table(s)
...省略...
[ verifying class <none> ]
ERROR: attribute verification of </etc/zabbix> failed
group name <zabbix> not found in group table(s)
owner name <zabbix> not found in passwd table(s)
ERROR: attribute verification of </etc/zabbix/zabbix_agentd.conf.new> failed
group name <zabbix> not found in group table(s)
owner name <zabbix> not found in passwd table(s)
...省略...
Installation of <miracle-zbx-agent> partially failed.
次のオペレーティングシステムが影響を受けます。
次のMIRACLE ZBXのバージョンでこの問題が発生します。
すでにパッケージをインストールしてエラーを確認している場合はpkgrm
コマンドで
パッケージを削除してください。
# pkgrm miracle-zbx-agent
問題を回避するには次の手順でインストールします。
zabbix
グループを作成します。
# groupadd zabbix
zabbix
グループに所属するzabbix
ユーザを作成します。
# useradd -G zabbix -m zabbix
# pkgadd -d /path/to/miracle-zbx-agent-XXX-solaris11-sparc.pkg all
以降はインストールマニュアルにしたがい設定ファイルの準備やサービスの起動をおこなってください。
上述したバージョンのMIRACLE ZBXエージェントパッケージでは、
ファイルやディレクトリをインストールする前に実行されるpreinstall
スクリプトにて
シェルスクリプトの誤った条件分岐によりuseradd
およびgroupadd
コマンドが
意図どおりに実行されず、zabbix
ユーザ/グループが正常に作成されません。
その後Solarisのパッケージマネージャはインストール時点で存在しないユーザ/グループを参照して ファイルやディレクトリのパーミッションを変更しようとするため、 「概要」に載せたエラーが発生します。
弊社提供のRed Hat Enterprise Linux(RHEL)6系向けのMIRACLE ZBX 5.0 RPMパッケージにはOpenSSL 1.0.1以上が必要です。したがってお使いのRHEL6系環境にインストールされているOpenSSLが1.0.1未満の場合、パッケージをインストールできません。
MIRACLE ZBX 5.0がベースとしているZabbix 5.0では、ソースコードをビルドする際にバージョン1.0.1以上のOpenSSLが求められます。そのため弊社提供のRHEL6系向けRPMパッケージではOpenSSL 1.0.1以上が必要です。
バージョン1.0.1未満のOpenSSLがインストールされている環境でMIRACLE ZBXパッケージのインストールを試みたとき、以下のようなエラーが発生します。
Error: Package: miracle-zbx-agent-5.0.5-2.ML6.x86_64 (miracle-zbx) Requires: libcrypto.so.10(libcrypto.so.10)(64bit) Error: Package: miracle-zbx-agent-5.0.5-2.ML6.x86_64 (miracle-zbx) Requires: libcrypto.so.10(OPENSSL_1.0.1)(64bit) Error: Package: miracle-zbx-agent-5.0.5-2.ML6.x86_64 (miracle-zbx) Requires: libssl.so.10(libssl.so.10)(64bit) Error: Package: miracle-zbx-agent-5.0.5-2.ML6.x86_64 (miracle-zbx) Requires: libcrypto.so.10(OPENSSL_1.0.1_EC)(64bit)
このようなエラーが発生した場合、OSにインストールされているOpenSSLのバージョンを確認し、バージョンアップデート後に再度MIRACLE ZBXパッケージのインストールを試みるようお願いします。OpenSSLのバージョンを確認するには次のコマンドを実行します。
$ rpm -q openssl
OpenSSLのバージョンアップデート方法は各OS提供元へお問い合わせください。
OpenSSLのバージョンが1.0.1以上でもパッケージのインストールに失敗する場合はお手数ですが弊社サポートまでお問い合わせください。
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が 生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
2020年10月27日 新規作成
Red Hat Enterprise Linux 7(RHEL7)系OSにMIRACLE ZBX 5.0.4-3~5.0.6-3をインストールすると、Webフロントエンドを動かすためのrh-php72-php-fpmサービスが正常に起動しません。
WebサーバとしてApacheを動かしているRHEL7系OSにて、MIRACLE ZBX Webフロントエンドをインストールしphp-fpmサービスを起動すると、サービスが次のような状態になりrh-php72-php-fpmサービスが正常に立ち上がりません。
● rh-php72-php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/rh-php72-php-fpm.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since 水 2020-12-23 15:12:13 JST; 58min ago
Process: 15025 ExecStart=/opt/rh/rh-php72/root/usr/sbin/php-fpm --nodaemonize (code=exited, status=78)
Main PID: 15025 (code=exited, status=78)
12月 23 15:12:13 localhost.localdomain systemd[1]: Starting The PHP FastCGI Process Manager...
12月 23 15:12:13 localhost.localdomain php-fpm[15025]: [23-Dec-2020 15:12:13] ERROR: [pool zabbix] cannot get uid for user 'nginx': Success (0)
12月 23 15:12:13 localhost.localdomain php-fpm[15025]: [23-Dec-2020 15:12:13] ERROR: FPM initialization failed
12月 23 15:12:13 localhost.localdomain systemd[1]: rh-php72-php-fpm.service: main process exited, code=exited, status=78/n/a
12月 23 15:12:13 localhost.localdomain systemd[1]: Failed to start The PHP FastCGI Process Manager.
12月 23 15:12:13 localhost.localdomain systemd[1]: Unit rh-php72-php-fpm.service entered failed state.
12月 23 15:12:13 localhost.localdomain systemd[1]: rh-php72-php-fpm.service failed.
このエラーはphp-fpmの設定ファイル内にて listen.acl_users で指定されているユーザのUIDが取得できないときに表示されます。MIRACLE ZBXが提供している設定ファイルではlisten.acl_usersにapacheとnginxユーザを指定していますが、標準ではシステムにnginxユーザが存在しないためエラーになります。
/etc/opt/rh/rh-php72/php-fpm.d/zabbix.confを編集し、 listen.acl_usersから”nginx”を削除します。編集後は以下のような設定になります。
listen.acl_users = apache
上記のように変更したあとにrh-php72-php-fpmサービスを再起動してください。
systemctl restart rh-php72-php-fpm
Software Collections(SCL)版PHP 7.2パッケージのサポートが2020年11月で終了しました。
MIRACLE ZBX 5.0.8-3 より、SCL版PHP 7.3パッケージに依存するMIRACLE ZBX Webフロントエンドパッケージの提供を開始します。SCL版PHP 7.2に依存するWebフロントエンドパッケージは引き続き提供します。
本ドキュメントでは当該Webフロントエンドパッケージの新規インストール方法およびPHP 7.2からのアップデート方法について説明します。
MIRACLE ZBX 5.0 インストールマニュアルを参照してください。
ここではDBにMySQLまたはMariaDBを使用しているものとします。
動作中のhttpd
とrh-php72-php-fpm
サービスを停止します。rh-php72-php-fpm
サービスの自動起動を有効にしている場合はそれを無効にします。
# systemctl stop httpd rh-php72-php-fpm
# systemctl disable rh-php72-php-fpm
PHP 7.2に依存するWebフロントエンドパッケージを削除します。
# yum remove miracle-zbx-web-deps-scl miracle-zbx-web-mysql-scl miracle-zbx-apache-conf-scl
PHP 7.3に依存するWebフロントエンドパッケージをインストールします。
# yum install miracle-zbx-web-deps-scl-php73 miracle-zbx-web-mysql-scl-php73 miracle-zbx-apache-conf-scl-php73
httpd
とrh-php73-php-fpm
サービスを起動します。
# systemctl start httpd rh-php73-php-fpm
rh-php73-php-fpm
サービスの自動起動を有効にする場合は以下のコマンドを実行します。
# systemctl enable rh-php73-php-fpm
動作中のrh-nginx112-nginx
とrh-php72-php-fpm
サービスを停止します。rh-php72-php-fpm
サービスの自動起動を有効にしている場合はそれを無効にします。
# systemctl stop rh-nginx112-nginx rh-php72-php-fpm
# systemctl disable rh-php72-php-fpm
PHP 7.2に依存するWebフロントエンドパッケージを削除します。
# yum remove miracle-zbx-web-deps-scl miracle-zbx-web-mysql-scl miracle-zbx-nginx-conf-scl
PHP 7.3に依存するWebフロントエンドパッケージをインストールします。
# yum install miracle-zbx-web-deps-scl-php73 miracle-zbx-web-mysql-scl-php73 miracle-zbx-nginx-conf-scl-php73
/etc/opt/rh/rh-nginx112/nginx/nginx.conf
を編集します。/etc/opt/rh/rh-nginx112/nginx/conf.d/zabbix-rh-php73.conf
がincludeされるよう変更します。
http {
include mime.types;
include /etc/opt/rh/rh-nginx112/nginx/conf.d/zabbix-rh-php73.conf;
default_type application/octet-stream;
}
/etc/opt/rh/rh-php73/php-fpm.d/zabbix.conf
を編集します。listen.acl_user
にnginx
を指定します。
listen.acl_users = nginx
rh-nginx112-nginx
とrh-php73-php-fpm
サービスを起動します。
# systemctl start rh-nginx112-nginx rh-php73-php-fpm
rh-php73-php-fpm
サービスの自動起動を有効にする場合は以下のコマンドを実行します。# systemctl enable rh-php73-php-fpm
未復旧の障害が多くなると、Webフロントエンドの一部のページで表示に時間がかかる、あるいは表示できなくなる場合があります。
未復旧の障害が多くなる(およそ10万件以上)と、Webフロントエンドの一部のページで表示に時間がかかる、あるいは表示できなくなる場合があります。例として以下のページがあります。
未解決の障害は随時解決することを推奨します。トリガーに復旧条件を設定する、ログ監視やSNMPトラップ監視は復旧したらクローズするなどです。
クローズせず障害が蓄積していくと、Webフロントエンドへのアクセス時にhttpdに以下のようなログが出力されることがあります。この場合はPHPプロセスのメモリ割り当てを増やすことで問題を緩和できる可能性があります。
HP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /usr/share/zabbix/xxx on line nnn\n', referer: http://〜/zabbix/〜
PHPの処理はOSやZBXのバージョンによってphp-fpmもしくはmod_phpによって行われます。使用している環境に合わせて設定を行ってください。
php-fpmの場合
/etc/php-fpm.d/zabbix.conf 設定ファイルにおいて、php-fpmプロセスに課されたメモリサイズ上限を調整してください。
なおML7系においては /etc/opt/rh/rh-php72/php-fpm.d/zabbix.conf (SCLのrh-php72の場合。バージョンによって適切なパスに読み替えてください)を編集してください。
mod_phpの場合
/etc/httpd/conf.d/zabbix.conf 設定ファイルにおいて、apacheプロセスに課されたメモリサイズ上限を調整してください。
なおこのメモリ制限は各php-fpm・apacheプロセス毎制限のため、そのままではシステム全体のメモリが不足することがあります。システムメモリサイズが制限されている場合は一度に起動可能なプロセスの数を制限してください。
さらに多くの件数の障害が存在する場合は設定だけではシステムに搭載されたメモリが不足するため、
システムに割り当てるメモリの追加等が必要になります。
MIRACLE LINUX 8またはそれと互換性のあるOSにMIRACLE ZBXサーバやプロキシをインストールした環境において、以下のように「Cannot read data from SSH server」というメッセージが表示され、SSH監視に失敗する場合があります。
以下のMIRACLE ZBXのバージョンとインストール先OSのバージョンをどちらも満たす場合に問題が発生します。
MIRACLE ZBXのバージョン
インストール先OS
※以下のOSについては、この問題の影響はありません。
MIRACLE ZBXではSSH監視のためにlibsshを使用しています。libssh 0.9に含まれるバグによりSSH経由で出力を取得する際にエラーになることがあるため、SSH監視が失敗します。
libsshのバグの詳細については、以下のページを参照してください。
https://bugs.libssh.org/T231
以下のバージョンのlibsshパッケージで不具合が修正されました。
このバージョン以降のパッケージに更新してください。更新方法についてはパッケージの提供元に確認してください。
パッケージの更新後は、zabbix-serverサービスの再起動が必要となります。
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が 生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
2020年9月2日 新規作成
2021年5月24日 libsshパッケージの更新に伴い解決方法の内容を更新
Apache Log4jの脆弱性(CVE-2021-44228)のMIRACLE ZBXへの影響について
Apache Software Foundationが提供しているJavaライブラリApache Log4jにて、第三者による任意コード実行の脆弱性が報告されています。この問題の詳細な概要は下記URLより確認してください。
MIRACLE ZBXではMIRACLE ZBX Java GatewayパッケージにてJavaを使用しています。Java Gatewayのソースコードには、Apache Log4jライブラリを直接呼び出す処理は含まれていません。
Java Gatewayが用いるロギングライブラリLogback 1.2.3においても本脆弱性の影響はありません。Logback 1.2.3ではApache Log4j 1.2.17を使用しており、本脆弱性をもつApache Log4j 2.x系のバージョンではないためです。
したがってMIRACLE ZBX Java Gatewayおよびその依存ライブラリにおいて本脆弱性による影響はありません。
2021年12月14日 初稿
当社コミュニティ版パッケージをお使いの場合など、
サーバやエージェントなど全ての種類のパッケージのインストール方法が記載されています。
当社アプライアンス製品をお使いの場合など、
エージェントのインストール方法のみが記載されています。
2020年 7月 9日 新規作成
2020年 10月 13日 マニュアル更新
2020年 11月 18日 マニュアル更新
2021年 1月 7日 マニュアル更新
2021年 1月 29日 マニュアル更新
2021年 3月 8日 マニュアル更新
2021年 4月 2日 マニュアル更新
2021年 6月 3日 「MIRACLE ZBX 5.0 インストールマニュアル」更新
2021年 7月 8日 マニュアル更新
2021年 8月 2日 マニュアル更新
2021年 9月 13日 マニュアル更新
2021年 12月 6日 マニュアル更新
2022年 4月 11日 マニュアル更新
2022年 7月 19日 マニュアル更新、RHEL9用の記述を追加しました。
2022年 11月 17日 マニュアル更新、AIX 7.3用の記述を追加しました。
2023年 3月 6日 マニュアル更新、aarch64パッケージの記述を追加しました。