Comment configurer les contrôles d’intégrité de Home Assistant et de ses dépendances

Configurez les contrôles d’état par couches : vérifiez d’abord la réponse de l’application Home Assistant, puis testez la base de données, MQTT, le DNS, le stockage et le chemin distant uniquement lorsque chaque dépendance est réellement nécessaire.

Un conteneur indiqué comme étant en cours d’exécution peut encore être en phase de démarrage, bloqué par le stockage, déconnecté de son broker ou incapable d’écrire l’historique. Commencez par un contrôle local de disponibilité peu coûteux, ajoutez des contrôles de dépendances distincts avec des noms clairs, prévoyez une période de grâce suffisante au démarrage et envoyez des alertes avant d’activer l’automatisation de la récupération. Chaque sonde doit indiquer ce qui a échoué et ce que prouve un résultat positif.

Définissez le comportement sain avant d’écrire une sonde

Énumérez les fonctions qui doivent fonctionner pour votre foyer : l’interface locale répond, les automatisations s’exécutent, Recorder peut écrire, les appareils MQTT échangent leur état, le DNS résout les noms requis et le stockage monté est accessible en écriture. Un simple statut positif ne peut pas prouver toutes ces fonctions.

Un guide pratique des contrôles d’état Docker distingue l’état de l’application de la simple existence du processus et explique qu’une sonde s’exécute à l’intérieur du conteneur et signale une réussite ou un échec. Utilisez cette distinction au niveau de l’application pour définir ce que votre contrôle Home Assistant doit observer.

Attribuez un responsable et une signification d’échec à chaque sonde. Le contrôle de Core ne doit pas prétendre valider la base de données, et un contrôle de socket MQTT ne doit pas affirmer que les messages des appareils sont à jour. Si un résultat ne peut pas conduire à une action précise, simplifiez ou supprimez cette sonde.

Ajoutez un contrôle léger de disponibilité de Home Assistant

Utilisez un point de terminaison ou une commande locale qui s’exécute rapidement et prouve que l’application répond, et pas seulement que le processus Python existe. Définissez un délai d’expiration inférieur à l’intervalle, un nombre raisonnable de tentatives et une période de grâce au démarrage suffisamment longue pour couvrir votre démarrage à froid mesuré.

Les contrôles d’état Compose exposent généralement des paramètres d’intervalle, de délai d’expiration, de tentatives et de période de démarrage, tandis que les conditions de dépendance peuvent retarder un consommateur jusqu’à ce qu’un prérequis soit sain. Le comportement opérationnel essentiel est la disponibilité plutôt que l’état en cours d’exécution, et non une fréquence d’interrogation agressive.

Démarrez Home Assistant depuis un stockage froid et notez le moment où la sonde réussit pour la première fois. Si elle échoue à chaque démarrage normal, augmentez la période de grâce plutôt que d’affaiblir le test. Si elle réussit avant que l’interface ou le service requis soit utilisable, le contrôle est trop superficiel et nécessite une réponse plus représentative.

Vérifiez séparément les dépendances et préservez la signification des échecs

Créez des contrôles indépendants pour la connexion à la base de données, le broker MQTT, la résolution DNS et le point de montage de stockage requis. Préférez une requête en lecture seule ou une petite écriture réversible vers un chemin de test dédié ; ne modifiez jamais les tables de Home Assistant et ne publiez pas de commandes vers de vrais appareils dans le seul but de prouver la disponibilité.

Gardez les dépendances liées à la découverte et au contrôle local distinctes de celles liées à l’accès distant. La présentation ZimaSpace des dépendances des composants Home Assistant fournit une carte utile pour décider quel échec doit vous alerter immédiatement et lequel peut rester un avertissement de service dégradé.

Étiquetez le résultat avec la couche défaillante. Si Home Assistant est sain mais que le contrôle de la base de données échoue, recherchez un problème de stockage ou d’identifiants au lieu de redémarrer Core. Si seul l’accès distant échoue, maintenez le contrôle local en fonctionnement. Cette séparation empêche une dépendance en échec d’effacer les preuves que les services sains fonctionnent.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testez les échecs, la récupération et le délai des alertes

Lors d’une fenêtre de maintenance, arrêtez une seule dépendance non critique à la fois ou bloquez temporairement son chemin de test. Vérifiez que la sonde correspondante échoue, que les contrôles indépendants restent positifs et que l’alerte nomme la bonne couche. Restaurez la dépendance et vérifiez que le même contrôle revient à l’état normal sans modifier manuellement l’état.

N’ajoutez des redémarrages automatiques qu’après avoir observé plusieurs échecs réels. Utilisez des temporisations de refroidissement et un nombre maximal de tentatives, et ne redémarrez jamais simultanément la base de données et Home Assistant sans préserver les journaux. Un redémarrage est une étape de vérification, pas la preuve que la dépendance sous-jacente a récupéré.

Une conception efficace détecte l’échec contrôlé dans le délai prévu, préserve les fonctions locales qui n’en dépendent pas et efface l’alerte après la restauration. Annulez les sondes qui génèrent une charge importante ou de fausses alertes ; faites remonter le problème si le service reste indisponible alors que tous les contrôles de dépendances sont positifs, car le test au niveau de l’application nécessite alors des éléments plus approfondis.