AutoKuma is not adding monitors to Uptime-Kuma

[masterchief324]

Preceding are my docker-composes for Uptime-Kuma, AutoKuma, and an example docker I'm trying to get added to Uptime Kuma. As you can see below, I can see where the tags are being generated, but AutoKuma is still not adding any monitors to Uptime-Kuma.

[BigBoot]

Hi, are the any messages in the AutoKuma log?

The first thing that comes to mind is that you are using container_name as id, which might include characters that are not valid, you should probably first slugify them like in the example:

{# Generate an autokuma id by slugifying the "container_name" #}
{% set id = container_name | slugify %}

Besides that it's hard to say anything without logs.

[masterchief324]

I don't get logs.

[BigBoot]

Hmm this is weird, are you sure the jellyseer container actually exists and is on the same docker host as autokuma?

[masterchief324]

I can absolutely confirm that the jellyseerr container exists and responds.

[papirov]

I have the same issue. No errors, no logs besides the pretty logo.. I'm running a docker swarm cluster, here is an example of a service i want to monitor:

duplicati: image: lscr.io/linuxserver/duplicati:latest environment: - PUID=0 - PGID=0 - TZ=America/Chicago volumes: - /mnt/appdata/duplicati:/config ports: - :8200 deploy: labels: kuma.duplicati.http.name: "Duplicati" kuma.duplicati.http.url: "http://duplicati:8200" placement: constraints: - node.labels.nas-affinity == true networks: docker_network:

Here is kuma and autokuma composes: ` uptime-kuma: image: louislam/uptime-kuma volumes: - /mnt/appdata/uptimekuma:/app/data ports: - ":3001" deploy: placement: constraints: - node.labels.nas-affinity != true networks: docker_network:

autokuma: image: ghcr.io/bigboot/autokuma:master ports: - :3001 environment: AUTOKUMA__KUMA__URL: http://uptime-kuma:3001 AUTOKUMA__DOCKER__HOSTS: tcp://docker-socket-proxy:2375 AUTOKUMA__DOCKER__LABEL_PREFIX: kuma networks: docker_network: deploy: placement: constraints: - node.labels.nas-affinity != true

networks: docker_network: external: true name: "containerNetwork" `

Have tried with and without docker-socket-proxy (when I did without, I had it running on the manager)

Any suggestions?

[masterchief324]

papirov, out of curiosity, what platform are you running docker on?

[papirov]

4 nodes in the cluster are running on raspbian, and 1 node is on the latest Ubuntu. Autokuma is definitely talking to Uptime-Kuma, because at the two times that UptimeKuma had to be restarted/upgraded, AutoKuma logged its unhappiness

[masterchief324]

Any chance Docker is installed as a Snap package for you, as opposed to a apt?

[papirov]

0 chance. All have been installed through apt.

[masterchief324]

Perfect. I had a prior issue with a friend who couldn't do GPU passthrough because of snap, and I was concerned this issue was related.

[BigBoot]

Here are some things I can think of:

• Make sure you're using the stable/latest version, not master, at least for testing
• if you're using swarm, make sure the labels end up on the containers, not the services. Alternatively enable support for services in AutoKuma. Though swarm support definitely is less tested than plain Docker.

[papirov]

Here are some things I can think of:

• Make sure you're using the stable/latest version, not master, at least for testing
• if you're using swarm, make sure the labels end up on the containers, not the services. Alternatively enable support for services in AutoKuma. Though swarm support definitely is less tested than plain Docker.

My labels are definitely on services. But I am dumb! I needed this variable: AUTOKUMA__DOCKER__SOURCE: "both" Restarted and it's working on swarm. Woohoo!!

[toonvank]

I don't get logs.

Same issue here!

[UninspiredENVY]

I came across this issue and have the same problem. I have AutoKuma installed on Unraid, and I am getting the same issue with no logs, just a logo. Mine does say that it is migrating databases at the top.

I would really appreciate some help with this, as it would be a huge benefit to get this working.

[BigBoot]

@UninspiredENVY you can try running autokuma with increased logging by setting the following env variable: RUST_LOG=kuma_client=trace,autokuma=trace. Be aware that the generated log might contain sensitive information so I'd advise against attaching this here publicly, but this might give you some further insight into why AutoKuma doesn't generate any Monitors. You can also send me the log as a Security advisory and I can have a look.