Request: Docker Metrics Port for Prometheus

[FrenchBen]

Docker 1.13 has built-in support for the Prometheus metrics output, available by updating the daemon config with --metrics-addr ...
See PR: moby/moby#25820

This metrics address needs to be tied to a port number, which I would like to see added to the list of Default Port Allocations:
https://github.com/prometheus/prometheus/wiki/Default-port-allocations

The port of choice for Docker would be: 9323

Aside from an official request, I can edit the wiki, but was unsure if any other steps were needed?

cc @beorn7 @fabxc @brancz @brian-brazil

[brancz]

Thanks a lot for opening this issue regarding this. I've been meaning to start a discussion around that wiki page, because it seems people add entries randomly, without having a discussion first, even if the exporter or application is not existent yet. So they are "reserving" the port. How about moving that page into the website so there is at least a PR for these. Then the wiki in total could be turned off.

I'm sorry for misusing your issue to start this discussion, regarding this issue, it sounds good to me :) if this has not already happened you may want to add docker to the list of natively instrumented applications. You can find that list in the docs repo.

[brian-brazil]

I've been meaning to start a discussion around that wiki page, because it seems people add entries randomly, without having a discussion first, even if the exporter or application is not existent yet.

That's the idea, it's a very low overhead way to get unique ports and it's also giving us a fairly complete list of exporters.

9201 is the next free port number if Docker wishes to follow our port number scheme.

[beorn7]

Note that there is already an entry:

9323 - Docker Prometheus Metrics under /metrics endpoint

[brancz]

Fair enough.

[brian-brazil]

Note that there is already an entry:

People keep on skipping numbers, I'm trying to fill the gaps.

[FrenchBen]

Thanks for all of the feedback - The idea behind the port was to go from the bottom of the list and find the next 'suitable' port.
For example 9201 returned the following details: WAP session service
http://www.speedguide.net/port.php?port=9201

I didn't want to use a port that could've been used for something else, although WAP probably died back in 2011.

I'll create a PR to add Docker to the natively instrumented applications.
edit: Where are the docs with that list, didn't see it in the repo?

Additionally you can apparently restrict Wiki edits to collaborators only:
Restrict editing to users in teams with push access only
https://help.github.com/articles/changing-access-permissions-for-wikis/

[brian-brazil]

Pretty much all ports are already taken by something.

If Docker as a project want to do their own thing port wise that's perfectly fine, the port list is just a suggestion and shouldn't supersede a project's existing port policies.

[stevvooe]

Thanks for looking into this everyone!

@brian-brazil I think we just want a port that does metrics, target discovery and white-label metric forwarding. I haven't really spec'ed anything out but we might serve up the following routes:

/discovery # target discovery for other hosts and containers
/metrics # engine-level metrics
/metrics/container/<id> # externally observable, docker stats/cadvisor-like

From what I understand about prometheus, it seems reasonable to do this all through a single port. However, I am not sure if the current target discovery mechanism allows differentiation based on path.

Either way, a single port is okay for now. Ideally, we'd like to avoid having a port per container, if possible.

[brian-brazil]

However, I am not sure if the current target discovery mechanism allows differentiation based on path.

It does, though using a url parameter is the usual way of doing this.

[juliusv]

However, I am not sure if the current target discovery mechanism allows differentiation based on path.

It does, though using a url parameter is the usual way of doing this.

In the Docker case with simple container IDs, a path element would look better/cleaner and more REST-ish IMO.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.