Voir les logs des containers Gladys, Mqtt etc plus facilement!

Je ne sais pas si certains connaissent mais pour ceux qui ne connaissent pas ce container c’est à découvrir ! Il s’agit d’un container qui montre en temps réel les logs des autres containers, bien pratique pour débuger ou suivre l’exécution de certaines commandes, il est léger, 4mb en ram, il peut démarrer, arrêter, redémarrer les containers !

Un tuto pour l’installer ici

Le lien github

La doc est là

Le docker compose est là, par contre il y a une erreur dans la ligne : DOZZLE_ENABLE_ACTIONS: true
il faut mettre
DOZZLE_ENABLE_ACTIONS: « true »

version: "3"
services:
  dozzle:
    image: amir20/dozzle:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 8080:8080
    environment:
      DOZZLE_ENABLE_ACTIONS: "true"

@pierre-gilles, cela pourrait être intéressant de pouvoir intégrer ce container dans Gladys comme Node-red ou zigbee2mqtt, tu en pense quoi ?

Je connais bien l’outil (super pratique !!) que j’utilise sur mon NAS où j’ai au moins 40 services docker qui tournent :slight_smile:

Pas certain de l’utilité de l’intégrer à l’install de Gladys par contre, car celui qui consulte les logs, c’est celui qui est un utilisateur avancé -sauf exception- donc pour moi ça ne colle pas trop.

Après j’ai toujours été pour une meilleure visibilité / contrôle des containers depuis l’interface de Gladys, mais cela a déjà été l’objet de demandes de fonctionnalité !

@guim31

Bah pas forcement, par exemple pour visualiser ou débuger les logs d’exécution des scènes cela peut-être pratique et si en plus c’est accessible de la même manière que l’interface de zigbee2mqtt ce serait top non ?! :+1:

C’est dommage que @Lokkye sembles pris dernièrement car c’est un dev qui parait très similaire (je dirais même identique) à celui de l’intégration Node-red donc le dev devrait pas être chronophage ! :woozy_face:

Certes mais cela demande peut-être un développement plus important et complexe que si la gestion de ce container était développé comme celui de Node-red et cela couvrirait les demandes de fonctionnalités existantes ! :blush:

Ça a l’air carrément bien ce truc.

Je trouve que l’intégrer aurait en effet l’avantage de faciliter les retours de bug sur le forum.
Car perso je ne sais jamais comment faire pour récupérer les logs et on me les a demandés plus d’une fois…

1 Like

@Hizo

Clairement !!! C’est un container compressé de 4MB en plus donc léger sur le disque et pas gourmand en mémoire

Bah là c’est clair que ça faciliterait les choses !!! :slight_smile:

Il faut se connecter en SSH puis lancer la commande docker logs nom_du_conteneur et le nom du conteneur peut être trouvé par la commande docker ps. Il se peut que pour certain, il faut ajouter le sudo avant les commandes. Mais ce serait clairement plus user-friendly de les avoir directement depuis Gladys

Je sais pas si t’as perdu @hizo…Mais Mme Michu oui !!! :joy:

1 Like

C’est pas faux

Non, j’ai bien compris ce qu’il disait, c’est juste que ça veut pas rester dans mon cerveau, plus assez d’espace disponible… :cry:

1 Like

Vous pouvez lire la réponse de @pierre-gilles ici Un bouton d'export d'informations / logs

1 Like

j’ai le même problème…probablement les mêmes causes !!! :joy:

Merci @cce66 pour la demande de fonctionnalité, ça a l’air très cool Dozzle, je ne connaissais pas :slight_smile:

Merci @cicoub13 pour la mention, je maintiens ce que j’avais dis à l’époque pour la partie debug, il manque clairement des briques à Gladys pour permettre un debug plus facile.

Depuis mon message en 2020, il y a eu plusieurs ajouts qui vont dans ce sens, la vue « tâches en arrière plan » par exemple :

Cette vue n’est pas encore utilisée à son plein potentiel car seul certaines parties de Gladys ont implémentés ce mécanisme, et pour l’instant aucun service ne l’a implémenté.

→ Je serais pour que l’usage de cet onglet se généralise. Tout ce qui tourne en arrière plan doit être encapsulé dans des « jobs » Gladys afin d’apparaître dans cette vue, débuggable facilement en cas de problème.

L’intégration MQTT va bientôt avoir (dans la prochaine release) un onglet « Debug MQTT », ce qui permet à l’utilisateur de voir le traffic MQTT entrant sur l’instance, pratique pour débugger quand on test :

Ce n’est qu’un exemple, mais j’aimerais que Gladys et les intégrations soient plus communicantes dans l’interface pour que l’utilisateur soit moins perdu.

Par exemple, les scènes sont durs à débugger, il faudrait qu’il y a un historique d’exécution des scènes, avec toutes les informations pour que l’utilisateur comprenne ce qu’il s’est passé en cas de soucis.

Pour revenir sur le sujet

Je suis partagé sur la demande initial de @cce66, Dozzle étant un outil clairement pour expert, pourquoi on mettrait en place (ce qui représente du travail) un outil pour le lancer facilement dans Gladys, si quelqu’un veut utiliser Dozzle, il est capable de lancer une ligne de commande non ?

Est-ce qu’aussi en terme de message, on ne veut dire aux utilisateurs Gladys: on supporte le fait d’inciter les utilisateurs à aller voir les logs ?

Après, vous me direz que je suis le premier à demander les logs aux utilisateurs chez qui il y a des bugs, et vous avez raison :smiley: Mais j’aimerais que ça change !

1 Like

bonjour @pierre-gilles

Disons que dans un premier temps, Doozle pourrait faire l’affaire (comme l’intégration Node-red) il suffit « juste » de l’intégrer façon Zigbee2mqtt après c’est clair qu’une solution interne aurait l’avantage de ne montrer que le nécessaire, là l’avantage de Doozle est de permettre de stopper relancer les containers entre autres et permet le débogage des scènes.
A ce propos dans l’intégration Node-red, le fait de désactiver supprime le container… et les flows,…Facheux si on n’a pas fait de sauvegarde avant !!! Faudrait ajouter un message d’alerte. :woozy_face:
En tout le dev debug MQTT :+1: :+1: :+1: