Zigbee2mqtt: proposal: add Docker healthcheck

[thewilli]

The Docker container is great to run zigbee2mqtt as a "controlled, predefined environment". The only thing that I'm currently missing and would propose to add are health checks.

If health checks were integreated, we could use monitoring and alerting systems to informat about the system being in an unusable state - or just restart the container.

Those unhealthy states might include:

• CC2531 no longer available (#1308)
• MQTT Server not reachable / MQTT authentication failed
• (maybe) certain devices marked as important are not available

[peterforeman]

The first and second bullet should be fixed by exiting the application when these errors occur. If this happens while already running, the LWT will be sent (bridge offline). When restarting the application tries to reconnect all.

Your third bullet I'm not sure of the use and if it should be in zigbee2mqtt. Should it restart when a certain device is unavailable? Since the application is working fine, and is healthy.

[thewilli]

The first and second bullet should be fixed by exiting the application when these errors occur

@peterforeman restarting the application does not necessarily help when the MQTT Broker is down. And if it restarts too often in a short period of time, it might not come up again at all (e.g. when used as a Docker container). The healthcheck approach allows for a greater flexibility.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pedrolamas]

To be honest, what @thewilli says makes complete sense to me!

I use a mapped folder to have the latest zigbee-shepherd-converters and as some dependencies changed, the "node_modules" folder inside the docker container is not up-to-date.

Given that, the container launches fine and reports as started, yet looking at the logs I can see that the services didn't start and it just keeps restarting them.

A health check would have detected this issue and reported back to docker.

[pedrolamas]

Thanks @Koenkk, given the opportunity I'll take a look at what we can do to have some basic health check here!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[toxuin]

Kubernetes-based deployments would benefit from this as well.

I sometimes see odd error where there's an unhandled promise warning - and app did not crash, but does not send Zigbee/MQTT anymore.

Having a healthcheck would allow to eliminate whole class of problems like this.

Could this please be revisited? Thank you!

[pedrolamas]

@Koenkk hope you don't mind, but I'm revisiting this topic!

Looking at the code, I was thinking we could just have a simple nodejs script that would use the websocket endpoint to perform a health_check ("zigbee2mqtt/bridge/request/health_check") and report the status back to docker if that was ok.

I'm assuming that the websocket is active even if the frontend is not, but if there's even a better self-contained way we can use to perform a health_check, then I would take that instead!

[Koenkk]

@pedrolamas the websocket is only running when the frontend is enabled (and potentially requires authentication if password is set).

[pedrolamas]

Any alternative to it? Ideally, I would like to avoid having to use MQTT as that means that the communication is going through another party outside of z2m control!

[Koenkk]

@pedrolamas I currently see no other option, maybe health-check via frontend is the best one, but it can only be enabled when the user has enabled the frontend. Most easy thing would be a wget on the port where the frontend is running on (which is configurable and needs to be retrieved from configuration.yaml.