Comment configurer les contrôles d’intégrité de Jellyfin et de ses dépendances
Un contrôle de santé utile de Jellyfin doit prouver que le service a terminé son démarrage et peut accéder à sa base de données, et pas seulement que le processus du conteneur existe toujours. Utilisez le point de terminaison /health de Jellyfin comme contrôle de l’application, puis accordez suffisamment de temps aux migrations de démarrage avant qu’un orchestrateur puisse déclarer le service défaillant.
Sur un serveur domestique, les contrôles de santé sont particulièrement utiles lorsque Jellyfin dépend de médias montés, d’un proxy inverse, du DNS, du stockage ou d’un autre service susceptible d’être prêt à un moment différent. Construisez les contrôles par couches : santé de l’application Jellyfin en premier, disponibilité des dépendances ensuite, alertes en troisième, puis redémarrage automatique en dernier. Cet ordre empêche un superviseur d’arrêter à répétition un serveur qui effectue encore une migration ou une tâche de démarrage légitime.
Commencez par le point de terminaison de santé de l’application Jellyfin
Testez http://SERVER:8096/health depuis le même espace de noms réseau que celui utilisé par votre contrôleur de santé. Une requête réussie dans le navigateur de votre ordinateur portable est moins utile si le contrôle réel s’exécute dans un conteneur utilisant un nom DNS ou une route différents.
Jellyfin documente un point de terminaison de santé intégré qui vérifie la connectivité HTTP et celle de la base de données. La même documentation précise que ce point de terminaison ne se comporte pas comme un signal de disponibilité définitif tant que le serveur est encore en cours de démarrage, raison pour laquelle le délai de démarrage doit faire partie de la conception.
Enregistrez trois états : immédiatement après le démarrage, une fois Jellyfin utilisable et pendant un arrêt volontaire. Votre contrôle doit distinguer ces états de manière fiable avant que vous ne le reliiez à une logique de redémarrage ou à un système de notification.
Accordez une période de grâce aux migrations de démarrage
Une politique de santé qui commence à compter les échecs dès le démarrage d’un conteneur peut créer une boucle de redémarrage pendant les mises à niveau. Définissez une période de grâce suffisamment longue pour vos migrations de base de données et le chargement des extensions habituels, puis ne commencez l’intervalle et le nombre de tentatives ordinaires qu’après cette période.
Docker Compose prend en charge start_period, start_interval, interval, timeout et retries dans le contrôle de santé d’un service. Utilisez ces paramètres de temporisation du contrôle de santé pour exprimer la tolérance au démarrage au lieu d’intégrer de longues attentes dans la commande de test.
Après avoir configuré la période de grâce, redémarrez Jellyfin deux fois : une fois dans des conditions normales et une fois après une mise à jour ou une restauration de sauvegarde plus longue. Une bonne politique maintient l’état de démarrage pendant l’initialisation de Jellyfin, puis passe à l’état sain sans redémarrage inutile du conteneur.
Vérifiez les dépendances séparément de Jellyfin
Ne transformez pas une seule sonde Jellyfin en script géant qui teste le montage des médias, le DNS, le proxy inverse, les fournisseurs de métadonnées en ligne et chaque client. Chaque dépendance doit disposer d’un signal distinct afin qu’un échec indique la couche défaillante.
Pour une bibliothèque montée, un contrôle de dépendance à faible risque peut vérifier que le point de montage attendu existe et contient un chemin sentinelle connu en lecture seule. Pour un proxy inverse, vérifiez séparément l’accessibilité du serveur en amont et celle du point de terminaison TLS public, afin qu’un problème de certificat ne soit pas identifié à tort comme une défaillance de la base de données Jellyfin.
Cette vérification par couches est similaire à la vérification du transcodage matériel : l’information utile est de savoir si le sous-système attendu est réellement actif, et non si un écran de configuration indique simplement qu’il devrait l’être.
Déclenchez une alerte avant de redémarrer automatiquement
Considérez un résultat signalant un état défaillant comme un élément à examiner en premier. Une seule sonde en échec pendant une forte sollicitation du disque ou une brève interruption réseau ne justifie pas nécessairement le redémarrage de Jellyfin, surtout si la défaillance se situe en dehors du processus Jellyfin.
Une politique pratique pour un serveur domestique consiste à exiger plusieurs échecs consécutifs, à prévenir l’administrateur et à ne redémarrer que lorsque le contrôle de santé de l’application reste en échec alors que l’hôte et le stockage requis sont toujours disponibles. Si la dépendance de stockage est absente, redémarrer Jellyfin peut aggraver la situation en déclenchant des tâches de démarrage sur un chemin de bibliothèque incomplet.
Rendez le message d’alerte précis : résultat du point de terminaison, résultat des dépendances, dernière heure de réussite et indication précisant si un redémarrage a été tenté. Le contrôle de santé devient ainsi un outil d’exploitation plutôt qu’un simple voyant binaire rouge ou vert.
Validez le contrôle dans des conditions réelles de défaillance
Testez la politique terminée en arrêtant proprement Jellyfin, en bloquant temporairement le port de l’application et, sur un chemin de test hors production, en rendant une dépendance indisponible. Confirmez que chaque événement produit l’état attendu et ne déclenche pas une action destructive sans rapport.
Rétablissez ensuite toutes les dépendances et vérifiez que Jellyfin revient à l’état sain sans modification manuelle. La récupération fait partie de la conception du contrôle de santé : une sonde qui détecte une défaillance mais ne repasse jamais à l’état normal après la récupération du service n’est pas fiable.
Cessez les ajustements lorsque le contrôle sait distinguer les états de démarrage, sain, défaillant et dépendance en échec lors de tests répétés. Si ces états restent ambigus, maintenez l’automatisation en mode alerte uniquement jusqu’à ce que la sonde soit suffisamment précise pour piloter les redémarrages en toute sécurité.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin doit-il utiliser un compte partagé unique ou des comptes distincts pour chaque membre du foyer ?
Choisissez les comptes familiaux Jellyfin selon les limites d’identité, d’accès, de contrôle parental et de récupération dont vous avez besoin.
Pourquoi l’utilisation de la mémoire de Jellyfin reste-t-elle élevée une fois la tâche terminée ?
Distinguez la croissance du processus Jellyfin du cache Linux, et n’intervenez que lorsque la mémoire continue d’augmenter ou crée une réelle pression.
Signes indiquant qu’une configuration de stockage Jellyfin devient un risque pour la récupération des données
Auditez les rôles de stockage de Jellyfin, séparez l’état actif des sauvegardes et des données reconstructibles, puis validez la disposition par une restauration.
