Monitによるkusanagi restartの連鎖で全サイト停止する

AlmaLinux 9 / KUSANAGI 9.11.2 / httpd-behind-nginx 構成です。

稼働中の全profileへ突然アクセスできなくなり、確認したところ nginx129@with_httpd.service が停止していました。
手動で

systemctl start nginx129@with_httpd

を実行すると正常に起動し、全サイトが復旧しました。

調査したところ、Monitによる kusanagi restart が短時間に繰り返され、最終的にsystemdのstart-limit-hitに到達していたことが分かりました。

最初の契機として、あるprofileのnginx SSLアクセスログでHTTP 499が検出され、

trying to restart
restart: '/opt/kusanagi/bin/kusanagi restart'

となっていました。

該当profileのMonit設定は以下です。

restart program = "/opt/kusanagi/bin/kusanagi restart"
if match '"(GET|POST) /.* HTTP/.*" (499|5[0-9][0-9]) [0-9]+ ' for 5 cycles then restart
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor

その後、kusanagi restartによるnginx/httpdの再起動中に、別profileで502/503が記録され、それを各profileのMonitが検出してさらに kusanagi restart を実行する、という連鎖が発生していました。

実際に短時間でnginx/httpdのstop/startが繰り返され、まずhttpdが

10:25:24
httpd@with_nginx.service: Start request repeated too quickly.
httpd@with_nginx.service: Failed with result 'start-limit-hit'.

となりました。

その後もrestartが続き、nginxも

10:26:02
nginx129@with_httpd.service: Start request repeated too quickly.
nginx129@with_httpd.service: Failed with result 'start-limit-hit'.

となっています。

systemdの設定を確認すると、nginx/httpdともに

StartLimitIntervalUSec=10s
StartLimitBurst=5

でした。

KUSANAGIのbackend.logでも、

10:25:24
'systemctl restart httpd@with_nginx.service' returned 1

10:26:02
'systemctl restart nginx129@with_httpd.service' returned 1

10:26:03
'systemctl restart nginx129@with_httpd.service' returned 1

10:26:04
'systemctl restart nginx129@with_httpd.service' returned 1

などが記録されています。

nginxの設定テスト自体は正常で、後からsystemctl startを実行すると正常起動するため、nginx設定エラーではなく、短時間のrestart回数がsystemdのStartLimitBurstを超えたことが直接の停止原因と考えています。

気になっているのは、Monitのrestart回数制限は各profileのcheck単位ですが、実際に実行されるのがprofile単位の復旧ではなく

/opt/kusanagi/bin/kusanagi restart

である点です。

例えば複数profileがそれぞれ1回ずつrestartを要求した場合、各profileでは「5 restarts within 5 cycles」に到達していなくても、共有しているnginx/httpdには短時間に5回を超えるrestartが発生し得ます。

また、一度の kusanagi restart による瞬断で他profileに502/503が発生し、その502/503が次の kusanagi restart の契機になるため、restart処理自身が次のrestart条件を作る状態になっているように見えます。

なお、保存していたKUSANAGI 9.9.0のRPMと現在の9.11.2を比較したところ、Monitのnginx監視条件は9.9.0時点ですでに

(499|5[0-9][0-9])

となっており、9.11.2で新たに499監視が追加されたものではありませんでした。
changelog上では9.8.9で

Add 499 to monit restart condition.

とされています。

9.9.0と9.11.2のMonitテンプレートの主な差は、

if match

から

if content =

への変更でした。

そのため今回の現象は9.11.2固有とは限らず、以前のバージョンでも発生し得る構造ではないかと考えています。
過去にも原因不明で一部サイトへアクセスできなくなり、kusanagi restartで復旧したことがあった可能性がありますが、今回ほど詳細には調査していませんでした。

なお9.10.4以降では、同一のstate-changing commandをbackend側で順番待ちさせる処理も追加されているようですが、今回その待機処理が実際に発動したかどうかまではログから確認できていません。

現在は再発防止のため、暫定的に

kusanagi monit off

として運用しています。

Monitの各profileによる5xx/499検出から共有サービス全体の kusanagi restart を実行する現在の構成では、このようなprofile間のrestart連鎖が発生する可能性があるように思います。

仕様上想定された動作なのか、またMonitのrestart処理について修正等が必要な状態なのか、ご確認いただけますでしょうか。