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

エヴァ・ウォン

IceWhale author

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

How to Configure Health Checks for Home Assistant and Its Dependencies

ヘルスチェックは階層化して設定します。まずHome Assistantアプリケーションの応答を確認し、その後、各依存関係が実際に必要な場合に限って、データベース、MQTT、DNS、ストレージ、リモートパスをテストします。

コンテナがrunningと表示されていても、起動中だったり、ストレージでブロックされていたり、ブローカーから切断されていたり、履歴を書き込めなかったりする場合があります。低コストなローカル準備完了チェックから始め、依存関係ごとに明確な名前の個別チェックを追加し、十分な起動猶予を設けてから、復旧の自動化を有効にする前にアラートを送信します。各プローブは、何が失敗したのか、成功結果が何を証明するのかを示す必要があります。

プローブを書く前に正常な動作を定義する

家庭内で機能すべき項目を列挙します。ローカルUIが応答すること、オートメーションが実行されること、Recorderが書き込めること、MQTTデバイスが状態を送受信できること、DNSが必要な名前を解決できること、マウントされたストレージに書き込めることです。1つのグリーンステータスだけでは、これらすべての機能を証明できません。

実用的なDockerヘルスチェックガイドでは、アプリケーションの正常性と単純なプロセスの存在を区別し、プローブがコンテナ内で実行されて成功または失敗を報告する仕組みを説明しています。Home Assistantのチェックで何を観測すべきかを定義する際は、そのアプリケーションレベルの区別を使用してください。

すべてのプローブに、担当する対象を1つ、失敗の意味を1つ割り当てます。Coreのチェックでデータベースまで検証したことにしたり、MQTTソケットのチェックでデバイスメッセージが最新だと主張したりしてはいけません。結果から具体的な次のアクションにつなげられない場合は、そのプローブを簡素化するか削除します。

軽量なHome Assistant準備完了チェックを追加する

短時間で完了し、Pythonプロセスが存在するだけでなく、アプリケーションが応答していることを証明できるローカルエンドポイントまたはコマンドを使用します。タイムアウトはインターバルより短く設定し、適切な再試行回数と、測定したコールドスタートに十分な起動猶予期間を設定します。

通常、Composeのヘルスチェックでは、インターバル、タイムアウト、再試行回数、開始期間を制御できます。また、依存関係の条件によって、前提条件が正常になるまでコンシューマーの起動を遅らせることもできます。重要な運用上の動作は、積極的なポーリング間隔ではなく、実行中の状態ではなく準備完了状態です。

Home Assistantをコールドストレージから起動し、プローブが初めて成功した時刻を記録します。通常の起動時に毎回失敗する場合は、テストを弱めるのではなく猶予期間を延ばします。UIや必要なサービスが使用可能になる前に成功する場合は、チェックが浅すぎるため、より実態を反映した応答が必要です。

依存関係を個別に確認し、失敗の意味を維持する

データベース接続、MQTTブローカー、DNS解決、必要なストレージマウントについて、独立したチェックを作成します。読み取り専用クエリ、または専用のテストパスへの小さく可逆的な書き込みを優先し、可用性を証明するためだけにHome Assistantのテーブルを変更したり、実際のデバイスへコマンドを公開したりしてはいけません。

検出とローカル制御の依存関係を、リモートアクセスの依存関係とは分けて管理します。Home Assistantコンポーネントの依存関係に関するZimaSpaceの概要は、どの障害を直ちに通知し、どの障害を低下状態の警告にとどめるかを判断する際に役立ちます。

結果には、失敗したレイヤーを付けます。Home Assistantが正常なのにデータベースチェックが失敗した場合は、Coreを再起動するのではなく、ストレージまたは認証情報を調査します。リモートアクセスだけが失敗した場合は、ローカル制御を動作させ続けます。この分離により、1つの依存関係が赤になっただけで、正常なサービスの証拠まで失われるのを防げます。

Featured

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

ZimaCube2

障害、復旧、アラートのタイミングをテストする

メンテナンス時間帯に、重要でない依存関係を一度に1つ停止するか、そのテスト経路を一時的に遮断します。対応するプローブが失敗し、無関係なチェックはグリーンのままで、アラートが正しいレイヤーを示すことを確認します。依存関係を復元し、手動で状態を編集せずに同じチェックがクリアされることを確認します。

実際の障害を複数回観測してから、自動再起動を追加します。クールダウンと最大試行回数を設定し、ログを保持せずにデータベースとHome Assistantを同時に再起動してはいけません。再起動は検証のゲートであって、基盤となる依存関係が復旧した証拠ではありません。

適切な設計では、制御した障害を想定した時間内に検出し、その障害に依存しないローカル機能を維持し、復旧後に状態をクリアします。大きな負荷や誤アラートを生むプローブはロールバックします。すべての依存関係チェックが成功しているのにサービスが準備未完了のままなら、アプリケーションレベルのテストにはより深い証拠が必要なため、エスカレーションします。