mDNS discovery (WIP) #1903
mDNS discovery (WIP) #1903
Conversation
|
Thank you for your contribution! I think the main question we need to answer is whether this discovery mechanism has enough adoption to be included in the main Prometheus server by default. Will you be able to commit to act as maintainer for this discovery, in case any bug reports / further feature requests come in? |
| var wg sync.WaitGroup | ||
|
|
||
| names := []string{ | ||
| "_prometheus-http._tcp", |
There was a problem hiding this comment.
Should we make this configurable, using prometheus as default?
There was a problem hiding this comment.
All the other services are of the form _<service>[-proto]._<tcp|udp> to avoid clashing with any human-interfacing DNS names on .local-domains.
I'm OK with _prometheus._tcp - but then we need to indicate HTTP/HTTPS-preference in the TXT-records, requirering parsing those &c.
There was a problem hiding this comment.
I meant to only make the prometheus part configurable, but still append http/https if that's part of mDNS.
There was a problem hiding this comment.
I'd have this as a mandatory parameter.
The idea is that you hook into your existing service discovery mechanism, not setup one specially for Prometheus.
There was a problem hiding this comment.
Selection of http/https is something to be left fore relabelling.
but then we need to indicate HTTP/HTTPS-preference in the TXT-records, requirering parsing those &c.
This sounds custom. Are you doing things beyond that mDNS standard?
There was a problem hiding this comment.
The most common way of doing things in mDNS is to have ex. _prometheus-http._tcp, which is what the library is doing right now.
|
I dunno about maintaining it; I'm mostly toying about with some IoT-things + Prometheus, so it seemed convenient to have around... On the down-side, the https://github.com/hashicorp/mdns library sucks in https://github.com/hashicorp/go.net, which is by no means a small dependency. And it's verbose as hell. IMHO both parts needs to be fixed some way or other. |
|
Have you seen the file_sd? You could write a standalone mDNS discovery tool which dumps out a JSON file upon change. Prometheus will watch the configured path and automatically reload the target. Have a look at these blog posts for more info: https://prometheus.io/blog/2015/06/01/advanced-service-discovery/#custom-service-discovery and https://prometheus.io/blog/2015/08/17/service-discovery-with-etcd/ |
| labelSet := model.LabelSet{ | ||
| //dnsNameLabel: model.LabelValue(name), | ||
| dnsNameLabel: model.LabelValue(response.Host), | ||
| model.InstanceLabel: model.LabelValue(strings.TrimRight(response.Host, ".")), |
There was a problem hiding this comment.
SD mechanisms should just set __address__ and leave the rest to relabelling.
There was a problem hiding this comment.
So I should set something like model.MetaLabelPrefix + "mdns_hostname" and friends for these things?
Hadn't thought about that - sounds like a feasible way to take things as well. |
|
From reading issues on github.com/hashicorp/mdns, it looks to be somewhat unmaintained. I'm working on a switch to github.com/micro/mdns which looks to be the best-maintained fork out there... |
|
Can you point me at the mDNS spec? I can't seem to find one online. |
|
Technically, multicast DNS is RFC6762. The service-discovery layer, where all the fun stuff happens, is RFC6763. Skimming section four, mentally replacing In general, when people refer to mDNS, Zeroconf, Avahi, Bonjor, ... they mean RFC6763. |
|
On reflection (and quite a bit late) it's probably better to have it as an external service-discovery mechanism. (And I guess it can always be merged in, if it turns out popular...) |
|
For future reference: I've made a standalone prometheus-mdns-sd. |
Note: This is very much Work-in-progress; I'm mostly looking for early feedback so I don't end up on too many detours.
This provider finds services published under
_prometheus-http._tcpand_prometheus-https._tcpvia mDNS (RFC6762) and adds the appropriate targets in prometheus.On OS X a fake service can be created by
dns-sd -R "My Test" _prometheus-http._tcp. . 9090 path=/metrics- the discoverer uses ~half that information, but it's useful if one want to muck about with mapping things to labels...Currently it sets
instance= provided hostname, exyour-machine-name.local__scheme__tohttporhttpsdepending on which service type it gets__address__to (in order of what's found first)ipv4:port,[ipv6]:portand finallyhostname:port.TODO