有用な診断情報を失わずに Plex のログを調整する方法

まずノイズの多いエラーを修正し、その後、実際に診断する必要があるインシデント期間に合わせて保持期間を設定し、Plexのログを調整します。

繰り返し発生している内容を把握する前にログ量を減らすと、依存関係の障害を示す唯一の証拠を消してしまう可能性があります。どのファイルが増大しているか、どのプロセスが書き込んでいるか、メッセージがどの程度の速さで繰り返されているかを測定します。根本原因を修正したら、通常のインシデント発見に十分な履歴を残せる、上限付きのポリシーを設定します。

ログレベルを変更する前に書き込み元を特定する

Plexのアプリケーションログ、コンテナの標準出力、リバースプロキシ、ホストのジャーナルは、それぞれ別々に増大する可能性があります。すべてのログソースを一度に減らすのではなく、正確な書き込み元を特定してください。

Dockerのコンテナログ処理では、アプリケーションが管理するファイルとは別に、標準出力と標準エラーを収集できます。

10分間にわたってディレクトリの増加量を測定し、最も速く増大しているファイルから短いサンプルを取得します。保持設定を変更する前に、そのサンプルを保存してください。

より速くローテーションする前に、繰り返し発生するエラーを修正する

マウントの失敗、クラッシュループ、到達不能なサービスは、正常な動作時と比べて桁違いに大量の出力を生成することがあります。保持期間を短くしても、書き込み負荷は減らず、パターンが隠れるだけです。

ログレベルを変更する前に、繰り返し表示されるメッセージで示された依存関係にエラーと飽和状態のチェックを適用します。

エラーを修正して、一度だけ再現します。ログの増加量が大幅に減った場合は、メッセージを恒久的に抑制するのではなく、適度な診断期間を維持してください。

検出にかかる時間を基準に保持期間を設定する

適切な期間とは、通常インシデントに気付く前までさかのぼれる長さでありながら、システムディスクの空き容量を守れる程度に短い期間です。使われることのない詳細なログを何か月も保持しても、メリットはありません。

ストレージのバックアップ容量と変動は有用な類推になります。保持期間は「すべてを保持する」ことではなく、運用上の価値に結び付けるべきです。

修正後の1日あたりのログ量を見積もり、希望するトラブルシューティング期間を掛けます。データベース、アップデート、その他のシステムタスクに必要な空き容量を確保してください。コンテナを置き換えても維持される永続的なアプリデータの構成とともに、ログと保持設定を保存します。ただし、一時的な診断データが恒久的な状態にならないようにしてください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ローテーションの仕組みを確認する

最も古い境界が移動し、通常運用に加えて再現したエラーが1件発生した後もログの総容量が安定して初めて、設定変更は完了したといえます。

運用における復元テストは、動作を検証することを基本としています。ログにも、設定ファイルを信頼するだけでなく、同じ原則を適用してください。

少なくとも1回、完全なローテーションサイクルを観察します。元の診断サンプルは稼働中のログディレクトリの外に保管し、証拠を残しながら本番ログが無制限に増大するのを防いでください。