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 AUTOKUMA__DOCKER__HOSTS 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 AUTOKUMA__DOCKER__HOSTS 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.