Home Assistantのログでシステムディスクがいっぱいになるのを防ぐ方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Prevent Home Assistant Logs From Filling the System Disk

まず増加しているファイルを正確に特定し、繰り返し発生するイベントを修正して、そのログを管理する層で保持期間を設定することで、Home Assistantのログによるディスク容量の圧迫を防げます。

小規模なホームサーバーでは、Home Assistant Coreのログ、Dockerのログ、Supervisorやアドオンのログ、ホストのジャーナルが同じシステムディスクを消費することがあり、それぞれ必要な対処が異なります。短時間の管理された測定期間で増加量を確認し、書き込み元を特定できるだけの証拠を残し、元に戻せる上限を設定してください。残り容量が安全な再起動やバックアップに不足するほど少ない場合は、不要な書き込みを停止します。

容量を消費しているログを特定する

まず空き容量の合計を記録し、何も削除せずに、対象ファイルシステム内の最大サイズのファイルとディレクトリを一覧表示します。Home Assistantを通常どおり稼働させたまま、5～10分後にもう一度サイズを比較してください。静的な大容量ファイルの一覧よりも、サイズが変化したファイルのほうが有用です。

Home Assistantの事例では、ディスク容量の枯渇がRecorderデータベースではなく、別の層に起因することがあります。ある解決済みのディスカッションでは、増加元がsystemdジャーナルであることが判明しました。そのため、最初に確認すべきなのはHome Assistantが忙しそうに見えるかどうかではなく、どのディレクトリが増え続けているかです。

Coreのログが増えている場合は、繰り返し出力されるコンポーネントとメッセージを確認します。DockerのJSONログが増えている場合は、コンテナのログドライバーを確認します。ジャーナルが増えている場合は、出力元のサービスを調べます。空き容量がすでに危険なほど少ない場合は、追加の書き込みによって復旧が難しくなる前に、最もノイズの多い不要なコンテナ、またはHome Assistant自体を停止してください。

可視性を下げる前に繰り返しエラーを修正する

最も多いメッセージを数え、タイムスタンプをデバイス、インテグレーション、オートメーション、アドオン、またはネットワークイベントと照合します。何千回も繰り返される警告は、無関係な単発エントリが何十件もある場合より、予防策を講じるうえで有用なことが多いです。設定を変更する前に、バージョンとトリガーを含む短いサンプルを保存してください。

Home Assistant Coreのある問題では、Tradfriのエラーによってログが10 GBを超え、システムディスクが枯渇したことが記録されています。これは1つのインテグレーションがログを大量出力する事例を示す、特定バージョンに依存した例です。Tradfriやローテーションが常に原因だと決めつけるのではなく、出力元を切り分ける根拠として扱ってください。

記録が完了したらデバッグログを無効にし、ノイズの多いことが確認されたインテグレーションだけを再読み込みまたは無効化して、元のトリガーを再実行します。メッセージの発生率が急減した場合は、そのインテグレーションまたは依存関係を修正してください。変化がない場合は設定を元に戻し、すべての警告を抑制するのではなく、次に確認済みの出力元を調べます。

ログを管理する層で保持期間を設定する

ホストのジャーナル、Dockerのログドライバー、リバースプロキシ、その他のアドオンについて、それぞれ個別に上限を設定します。Coreのロガーレベルではsystemdジャーナルの保存容量を制限できません。また、Dockerのサイズ設定では、マウントされた設定ディレクトリ内に直接書き込まれるファイルはローテーションされません。

チェック間隔をカバーするのに十分な履歴を残しながら、バックアップ、アップデート、データベース処理、復旧のための容量も確保できる上限を選びます。関連するZimaSpaceの記事Home Assistantの空き容量では、最後の余裕まで使い切ると、一時的に追加のディスク容量を必要とする処理が失敗する理由を説明しています。

各ポリシーは、再作成後も維持される設定に記録します。影響を受けるサービスだけを再起動または再作成し、設定が有効になっていることを確認してください。ロールバックできるよう、変更前の値も保持します。異常な書き込み元を特定する代わりに、定期的な一括削除を使わないでください。

-15% OFF

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

Single board computer zimaboard2

元のトリガーで増加が制限内に収まることを確認する

デバイスのオフライン、インテグレーションの再試行、バックアップ、ネットワーク障害など、ログが急増した原因のイベントを再現します。以前の増加時間より長い期間にわたり、同じファイルサイズ、メッセージ発生率、空き容量、サービスの健全性、オートメーションの応答を追跡します。

合格と判断できる結果は、ログの使用量が安定またはローテーションされ、必要な診断情報が失われず、通常どおり履歴が書き込まれ、次回のバックアップとアップデートに十分な空き容量がある状態です。サービスの再作成後にも上限が機能することを確認するため、ホストを一度再起動してからトリガーを再実行します。

継続中の障害を診断するために必要な証拠が失われる場合は、保持設定を元に戻します。確認済みの原因を切り分けた後もログが増え続ける場合は、繰り返し出力されるメッセージ、出力元のコンポーネント、バージョン、増加率、保存先パスを添えてエスカレーションしてください。ディスクが枯渇に近づいた場合は、再度書き込みを停止します。