Support for other Consul properties

[bmerry]

Consul's service registration API supports a bunch of other parameters apart from the ones implemented in the ConsulAgent class. I'm not familiar with all of them so I'm not sure which would make sense for prometheus_async, but the one I would like to use is Meta to associate some extra key-value pairs with the service.

Perhaps the simplest would be to have ConsulAgent take an optional argument called something like json_extra that is added to the JSON sent to consul - which would give future-proofing for arbitrary attributes?

[hynek]

TBH I'm kinda regretting shipping Consul support at all, because it's a PITA to test and I don't use it myself anymore (we run Nomad that does registering for me).

I'm not sure what to do about it – if someone 😇 shipped a package that uses the provided SD hooks (those aren't going anywhere) and wrote a nice Consul SD plugin, it would probably be a win for everyone involve.

[bmerry]

I had considered writing a PR, but I ended up having something else handle the registration because the process using prometheus_async doesn't know all the information to register and I didn't want it to need to know. So the bad news is no PR from me, the good news is that I won't be bothered if nothing gets done.

[hynek]

Hah, that's one of the problems. I think custom implementations of the SD agent protocol are the way to go in the end.

[bmerry]

Hah, that's one of the problems. I think custom implementations of the SD agent protocol are the way to go in the end.

Out of interest, if one is writing one's own implementation, what is the advantage of using the SD agent protocol over just doing the registration and deregistration directly?

[hynek]

I can’t think of one except having it wrapped nicely together.