Docker service monitor

[nbvcxz]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

New Monitor, Other

🔖 Feature description

Docker container monitor is great, especially it works both with socket and tcp. But it can monitor only running containers. When you use Docker Swarm (or services), the container name is: service_name.somerandompattern.
The issue is, that after updating a service, the random suffix changes. It's not a big deal when you have few Docker container sensors, but for more, it's difficult to manage.

✔️ Solution

I see 3 solutions to improve this sensor:

• Create a new sensor type to monitor Docker services
• Extend current sensor to be able to track not only containers, but also services
• (Kind of override) Allow current Docker sensor to use wildcards (for container names) e.g. some_name*

❓ Alternatives

No response

📝 Additional Context

No response

[SigInTheHead]

This would be an excellent addition, I have some important services that are replicated, and can't currently find a way of checking that they are all running

[nixmomo]

is there a solution for swarm or wildcard names now?
It would be so great to monitor swarm stacks / services too.... Nobody uses a single docker host in 2022

[matze19999]

Wildcards unfortunately also do not work for docker containers.

It would be amazing if Uptime Kuma would be able to check the uptime of a Docker Service like Portainer does!!

[Enissay]

This is well needed. Adding more info:

• you can see a sample of the name given to the container while running in a swarm

❯ docker container ps
CONTAINER ID   IMAGE                                     COMMAND                  CREATED         STATUS                   PORTS                          NAMES
3f197fcd9dc1   louislam/uptime-kuma:1                    "/usr/bin/dumb-init …"   9 minutes ago   Up 8 minutes (healthy)   3001/tcp                       uptime_kuma_app.1.i8q81aas6fqnirz2pwchg9a07

• I believe it would be a good start as suggested to begin with the support of partial name monitoring. Either a wild card OR a checkbox that will make sure to match the left part of the name. In my example, a valid name would be uptime_kuma_app.
• I am not sure how things are implemented, but it is easy to get the container ID from the partial name, then continue teh check as usual for non swarm containers... I usually use something like (if more than 1 match found, test should fail):

❯ docker container ls | grep uptime_kuma_app | awk '{print $1}'
3f197fcd9dc1

• Monitoring might be more complex since it lists all containers belonging to the same service running on other servers which might be partially up...

❯ docker service ps dozzle_dozzle 
ID             NAME                                          IMAGE                  NODE       DESIRED STATE   CURRENT STATE           ERROR                              PORTS
ip9t5amhase7   dozzle_dozzle.5ezxb3fkd63fw3jwyax0pfii1       amir20/dozzle:latest   vm02    Running         Running 2 weeks ago                                        
v262e92z7q3w   dozzle_dozzle.q8r9sxvpdiwawvvkvidbhkonc       amir20/dozzle:latest   desktop   Running         Running 11 hours ago                                                 
tih8p62gfora    \_ dozzle_dozzle.q8r9sxvpdiwawvvkvidbhkonc   amir20/dozzle:latest   desktop   Shutdown        Shutdown 11 hours ago                                      
c5ms6h6jtjgt    \_ dozzle_dozzle.q8r9sxvpdiwawvvkvidbhkonc   amir20/dozzle:latest   desktop   Shutdown        Rejected 4 days ago     "No such image: amir20/dozzle:…"   
e28xqhad2tpl   dozzle_dozzle.w1tpwujm8481fn8pdt73rlbmc       amir20/dozzle:latest   vm01     Running         Running 2 weeks ago                                        

[apwiggins]

There are containers that can run but be in an 'unhealthy' state. In bash, one can check for container health and then make further decisions based on health state.

 if [ "$(docker inspect -f "{{.State.Health.Status}}" mycontainer)" == "healthy" ] ; then                                                                                                                                                           
          printf ' OK'                                                                                                                                                                                                                               
          exit 0 
 else
     some_action
fi

[CommanderStorm]

I think this is better tracked in #4233, as docker-compose and docker swarm are likely not as different or #957 for the docker-.
=> merging these issues via closing this one as a duplicate.

Tip

If you have a look at the dependency linked in #957, @BigBoot has shared https://github.com/BigBoot/AutoKuma, which claims to solve this usecase.
We have not tested if it works as advertised, nor audited said software.