DevOps et supervision

Montray apporte les vérifications de santé systemd dans la barre d'état du bureau

Un nouvel outil open source utilise une icône dans la barre d'état système pour alerter les utilisateurs Linux lorsque des services systemd ou des vérifications de santé personnalisées échouent, évitant ainsi les pannes silencieuses.

Capture d'écran de l'interface de Montray montrant des icônes de statut colorées dans la barre d'état système
Illustration créée pour cet article

Traduit automatiquement depuis l’original en anglais.

Le développeur dimonomid a publié Montray, un utilitaire de surveillance léger conçu pour offrir une visibilité immédiate sur les défaillances des services systemd et les vérifications de santé personnalisées. Publié sur GitHub en octobre 2026, cet outil répond au problème courant des plantages silencieux de services en arrière-plan en affichant des indicateurs de statut directement dans la barre d'état système du bureau. Il permet aux utilisateurs Linux de surveiller à la fois les machines locales et les serveurs distants sans déployer des piles de surveillance d'entreprise complexes.

Ce qui s'est passé

Le projet est né d'une frustration personnelle face aux défaillances silencieuses dans les environnements auto-hébergés. En 2021, le développeur a découvert que son service Syncthing était cassé depuis plusieurs semaines, entraînant des problèmes importants de synchronisation de données difficiles à résoudre. Des incidents similaires se sont produits avec Certbot, où les échecs de renouvellement des certificats sont passés inaperçus jusqu'à l'expiration des services. Le problème fondamental résidait dans le fait que si systemd suivait ces défaillances en interne, il ne fournissait aucune alerte proactive et visible à l'utilisateur.

Montray résout ce problème en divisant la fonctionnalité en deux composants : un serveur backend et une interface utilisateur frontend. Le montray-server, écrit en Go, s'exécute comme un service en arrière-plan sur la machine cible. Il effectue des vérifications de santé et expose le statut actuel via une API WebSocket en lecture seule. Le montray-ui, construit avec Rust et Slint, s'exécute sur le bureau de l'utilisateur. Il se connecte à une ou plusieurs instances de serveur, agrège leurs statuts et affiche une icône codée par couleur dans la barre d'état système. Cette architecture permet à un seul ordinateur portable de surveiller simultanément plusieurs serveurs distants.

L'interface est conçue pour minimiser la charge cognitive. Une icône verte indique que tous les systèmes sont opérationnels. Une icône jaune clignotante signale un avertissement, tel qu'une défaillance non critique d'un service, tandis qu'une icône rouge clignotante indique un état d'erreur. Si l'interface elle-même perd la connexion à un serveur, l'icône clignote en magenta. Les utilisateurs peuvent mettre en veille spécifique certains incidents s'ils souhaitent les reconnaître temporairement sans résoudre immédiatement le problème sous-jacent.

Détails clés

  • Architecture à double composant : Le système sépare la logique de surveillance (montray-server en Go) de la logique d'affichage (montray-ui en Rust/Slint).
  • Surveillance distante via SSH : L'interface prend en charge les tunnels SSH sécurisés pour se connecter aux serveurs distants, évitant ainsi la nécessité d'exposer publiquement les ports de surveillance.
  • Vérifications personnalisables : Au-delà des services systemd, les utilisateurs peuvent configurer des vérifications arbitraires en ligne de commande, telles que la vérification de l'espace disque ou de la santé RAID.
  • Indicateurs d'état : L'icône de la barre d'état reflète le pire état non mis en veille parmi tous les serveurs surveillés, utilisant des motifs clignotants verts, jaunes, rouges ou magenta.
  • Orienté Linux : Bien que l'interface puisse fonctionner sur Windows ou macOS, l'intégration systemd du serveur est spécifique à Linux, limitant les capacités de surveillance locale sur d'autres systèmes d'exploitation.
  • Open source : Le projet est hébergé sur GitHub, avec des binaires précompilés disponibles pour une installation facile sur les distributions Linux.

Contexte

Systemd est le système d'initialisation utilisé par la plupart des distributions Linux modernes pour gérer les processus et les services système. Lorsqu'un service échoue, systemd enregistre l'événement dans son journal, mais il ne fournit pas intrinsèquement de notification de bureau ni d'indice visuel à l'utilisateur. Pour les auto-hébergeurs exécutant des applications critiques comme des outils de synchronisation de fichiers ou des serveurs web, ce manque de retour immédiat peut entraîner des temps d'arrêt prolongés. Les solutions de surveillance traditionnelles comme Prometheus ou Nagios sont puissantes mais nécessitent souvent une configuration et une maintenance importantes, ce qui est disproportionné pour les déploiements mono-utilisateurs ou à petite échelle.

Montray comble cette lacune en offrant une approche de surveillance « local-first ». Il exploite l'infrastructure systemd existante pour détecter les défaillances, mais les présente d'une manière impossible à ignorer pour un utilisateur de bureau. En utilisant des technologies standard comme WebSockets pour la transmission de données et SSH pour l'accès distant sécurisé, il s'intègre parfaitement aux flux de travail Linux existants sans nécessiter de nouveaux protocoles réseau ni de dépendances lourdes.

Pourquoi c'est important

Pour les équipes et les individus qui gèrent leur propre infrastructure logicielle, les défaillances silencieuses constituent un risque majeur. Un job de sauvegarde qui cesse de s'exécuter ou un certificat TLS qui échoue au renouvellement peut avoir des conséquences graves s'il n'est pas traité rapidement. Les outils de surveillance d'entreprise sont souvent excessifs pour ces scénarios, nécessitant des serveurs dédiés et une configuration complexe. Montray offre un juste milieu : il est suffisamment léger pour s'exécuter sur la même machine qu'il surveille, tout en étant assez robuste pour gérer plusieurs hôtes distants.

La conception de l'outil respecte les contraintes de confidentialité et de sécurité de l'auto-hébergement. En utilisant des tunnels SSH pour les connexions distantes, il évite d'ouvrir des ports supplémentaires sur les pare-feu ou de gérer des jetons d'authentification complexes pour des services externes. Cela le rend particulièrement adapté aux développeurs qui gèrent des serveurs personnels ou des infrastructures de petites entreprises où la simplicité de sécurité est une priorité. La possibilité de définir des vérifications personnalisées signifie également qu'il peut surveiller des métriques de santé spécifiques aux applications, et pas seulement les états des services au niveau système.

Ce que vous pouvez faire

  • Installer localement : Téléchargez les binaires précompilés pour montray-server et montray-ui depuis GitHub et suivez les instructions d'installation pour surveiller votre machine Linux locale.
  • Configurer les vérifications systemd : Modifiez le fichier /etc/montray-server.yml pour spécifier quels services systemd doivent déclencher des avertissements ou des erreurs, par exemple en définissant les défaillances de Syncthing comme des erreurs prioritaires.
  • Ajouter des serveurs distants : Configurez montray-server sur des hôtes distants et configurez votre montray-ui local pour se connecter via des tunnels SSH en modifiant le fichier ~/.config/montray-ui/montray-ui.yml.
  • Définir des vérifications de santé personnalisées : Ajoutez des commandes exécutables à la configuration du serveur pour surveiller l'espace disque, la connectivité de la base de données ou d'autres métriques spécifiques aux applications.
  • Tester les notifications : Déclenchez une défaillance de test dans un service non critique pour vérifier que l'icône de la barre d'état change de couleur et que les notifications de bureau apparaissent comme prévu.
  • Consulter la documentation : Consultez le dépôt GitHub du projet pour des guides détaillés sur la configuration de la sécurité, y compris les options d'authentification TLS et par jeton bearer pour les configurations non-SSH.

Autres actualités

Toutes les actualités