docker.docker.docker_host sample

[mcsdodo]

Could you please document what's expected to be put in the docker_host property of the docker monitor. I'm trying to monitor multiple hosts (one on-machine with sockets, others via tcp). When I use kuma.container.docker.docker_host: tcp://192.168.100.212:20001 I get an error:

WARN [autokuma::sync] Encountered error during sync: Error while trying to parse labels: Unable to parse tcp://192.168.100.212:20001 as i32
WARN [kuma_client::util] Error while parsing stirling-pdf: Unable to parse tcp://192.168.100.212:20001 as i32!

[mcsdodo]

It appears that the value should be the ID from the rows in the docker_host table within Kuma's database after reverse engineering it. Is this the intended behavior?

When setting up AUTOKUMADOCKERHOSTS collection, it would be nice to create these hosts in Kuma, then when scanning for labels maybe pair the values with system_info (not sure it's possible) and get the id?

[BigBoot]

Yes, as of now that's the intended behavior. The same problem also exists for notification providers. You can use the kuma CLI to set them up or get the internal ids.

I cannot create them automatically because there is no way identify them later (i.e. I use the autokuma tag value to associate a monitor with the corresponding container labels, but for notifications or docker hosts I can't add any kind of metadata), I guess I could just use the Name...

That said I don't think creating hosts from AUTOKUMADOCKERHOSTS would be a good idea, as there's no guarantee that uptime-kuma and autokuma use the same way to access hosts.

[mcsdodo]

The docker_host table has just docker_daemon, docker_type and name columns. To introduce a convention (in name?) to utilize pairing would be much more convenient approach than putting in IDs.

[BigBoot]

I'm closing this in favor of #81 to better keep track of the current status.