Plexとその依存サービスのヘルスチェックを設定する方法

Plexのヘルスチェックでは、サーバープロセスが実行中であることだけでなく、ユーザーが実際に利用する小さな経路を検証する必要があります。

ライブネスとレディネスは分けて考えます。Plexプロセスが稼働していても、メディアストレージが利用できなかったり、アプリデータが読み取り専用になっていたり、プロキシ経路が壊れていたりする場合があります。サーバーエンドポイント、状態パスへの書き込み権限、メディアパスへの読み取り権限、必要に応じたリモート到達性など、処理が軽く責任範囲が明確なチェックを使用してください。本番メディアを変更したり、大量のバックグラウンド処理を発生させたりするプローブは避けます。

ライブネスとレディネスを分けて定義する

ライブネスはサービスを再起動すべきかを確認し、レディネスは現在想定するワークロードを提供できるかを確認します。両者を統合すると、一時的な依存先の遅延によって再起動が発生する可能性があります。

レディネスとライブネスのシグナルは異なる目的で使われるため、一時的なストレージ遅延をPlexプロセスの再起動理由として自動的に扱うべきではありません。

ライブネスには軽量なローカルエンドポイントまたはプロセスチェックを使用し、ストレージやネットワークの依存関係については別のレディネス結果を返します。プロセスの置き換えを自動的に示すのは、ライブネス条件が失敗した場合だけにしてください。

無害な操作でアプリデータとメディアを検証する

Plexには永続的な状態へのアクセスとソースメディアへのアクセスが必要ですが、ヘルスチェックによって稼働中のデータベースを変更したり、本番ファイルの名前を変更したりしてはいけません。使い捨てのテストパスと、既知の読み取り専用メディアプローブを使用してください。

依存先が利用可能になる前でも、サービスが正常に見えることがあります。依存先のヘルス状態のタイミングが問題になるため、ストレージとネットワークのチェックはプロセスの状態とは別に報告する必要があります。

専用のアプリデータ用ヘルスディレクトリに小さなファイルを作成して削除し、その後、メディアマウント上にある既知の小さなファイルを読み取ります。どちらかが失敗した場合は、ライブラリの内容に触れず、失敗したパスを報告してください。

実際に依存する経路にだけネットワークチェックを追加する

LAN再生、リバースプロキシ経由のアクセス、VPNアクセス、リモートポート転送は、それぞれ異なる経路です。1つのプローブですべてを表そうとすると、障害が発生した境界が分かりにくくなります。

まずローカルサーバーの経路をテストし、次にネットワーク外部から選択したリモート経路をテストします。リモートPlexストリーミングのチェックは、リモートアクセスがサービスの約束に含まれる場合にのみ有用です。

各ネットワークプローブには、LAN、プロキシ、VPNなど、検証する経路にちなんだ名前を付けます。一方が失敗して別の経路が成功した場合は、正常なサーバーを再起動するのではなく、その層の担当先にアラートを送ります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

短時間のノイズを無視する失敗しきい値を設定する

プローブが1回失敗しただけなら、起動処理、ストレージのウェイクアップ、DNSの遅延、一時的なネットワークイベントが原因かもしれません。ヘルスチェックでは、無害な一時停止によるフラッピングを避けながら、継続的な利用不能状態を検出する必要があります。

短時間のリソース停止が、継続的な利用不能状態と同じ対応を引き起こさないように、測定したエラー、飽和度、使用率に基づいてリトライ回数と間隔のしきい値を選択します。

テスト期間中に、短時間の依存先遅延と継続的な障害を1回ずつ発生させます。短時間の遅延では再起動が発生せず、継続的な障害は許容できる対応時間内に検出されるよう、しきい値を調整してください。