Closed bmerry closed 9 months ago
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.
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.
Hah, that's one of the problems. I think custom implementations of the SD agent protocol are the way to go in the end.
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?
I can’t think of one except having it wrapped nicely together.
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 isMeta
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?