View Gladys, Mqtt etc container logs more easily!

I don’t know if some people already know about this, but for those who don’t, this container is worth discovering! It’s a container that shows in real time the logs of other containers, very handy for debugging or following the execution of certain commands. It’s lightweight, 4 MB in RAM, and it can start, stop, and restart containers!

A tutorial to install it here

The GitHub link

The docs are here

The docker-compose is here, however there is an error in the line: DOZZLE_ENABLE_ACTIONS: true
you must put
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, this could be interesting to integrate this container into Gladys like Node-RED or zigbee2mqtt, what do you think?

I’m familiar with that tool (super handy!!), which I use on my NAS where I have at least 40 Docker services running :slight_smile:

Not sure about the usefulness of integrating it into the Gladys install though, because the person who checks the logs is an advanced user—except in rare cases—so to me it doesn’t really fit.

That said, I’ve always been in favor of better visibility/control of containers from the Gladys interface, but that’s already been the subject of feature requests!

@guim31

Well, not necessarily — for example, to view or debug the execution logs of scenes that can be handy, and if on top of that it’s accessible the same way as the zigbee2mqtt interface that would be great, right?! :+1:

It’s a shame that @Lokkye seems busy lately because he’s a dev who appears very similar (I would even say identical) to the one for the Node-RED integration, so the development shouldn’t be time-consuming! :woozy_face:

Sure, but that might require a larger and more complex development than if the management of this container were developed like the Node-RED one, and that would cover the existing feature requests! :blush:

This thing looks really great.

I think integrating it would indeed have the advantage of making bug reports on the forum easier.
Because personally I never know how to get the logs and I’ve been asked for them more than once…

1 Like

@Hizo

Clearly!!! It’s an extra compressed container of 4MB, so

You need to connect via SSH then run the command docker logs nom_du_conteneur and the container name can be found with the docker ps command. It may be that for some, you need to add sudo before the commands. But it would clearly be more user-friendly to have them directly from Gladys

I don’t know if you’ve lost @hizo… But Mrs. Michu did!!! :joy:

1 Like

That’s not wrong

No, I did understand what he was saying, it’s just that it won’t stay in my brain, there’s not enough space left… :cry:

1 Like

You can read @pierre-gilles’s response here Un bouton d'export d'informations / logs

1 Like

I have the same problem… probably the same causes!!! :joy:

Thanks @cce66 for the feature request, Dozzle looks really cool, I didn’t know it :slight_smile:

Thanks @cicoub13 for the mention, I stand by what I said back then about the debugging part, Gladys clearly lacks building blocks to allow easier debugging.

Since my message in 2020, there have been several additions that go in this direction, the « background tasks » view for example:

This view is not yet used to its full potential because only certain parts of Gladys have implemented this mechanism, and for the moment no service has implemented it.

→ I would be in favor of generalizing the use of this tab. Everything that runs in the background should be encapsulated in Gladys « jobs » so it appears in this view, easily debuggable in case of a problem.

The MQTT integration will soon have (in the next release) a « Debug MQTT » tab, which allows the user to see incoming MQTT traffic on the instance, handy for debugging when testing:

This is just an example, but I’d like Gladys and the integrations to be more communicative in the interface so the user is less lost.

For example, scenes are hard to debug, there should be an execution history for scenes, with all the information so the user understands what happened in case of issues.

Back to the subject

I’m torn about @cce66’s initial request — Dozzle is clearly a tool for experts; why would we set up (which represents work) a tool to launch it easily in Gladys? If someone wants to use Dozzle, they can run a command line themselves, right?

Also, in terms of messaging, do we want to tell Gladys users that we support encouraging them to go check the logs?

That said, you’ll tell me that I’m the first to ask users who have bugs for logs, and you’re right :smiley: But I’d like that to change!

1 Like

hello @pierre-gilles

Let’s say that at first, Doozle could do