Add port option to exporter middleware #199
Conversation
|
I've been thinking about this again, and while my posture has always been that we shouldn't permit much configurability of these middlewares, encouraging implementers to use these as a template and make their own version instead... I have realized that in that "policy" I've been conflating both middlewares unfairly. However, I no longer think this should apply to the Exporter. Or at least it doesn't need to as much. I'm going to go through other closed PRs to see if this new thinking applied to any of them, and I closed them when I maybe shouldn't have. I'm sorry @tragiclifestories that we took forever to respond to this. This sort of landed in the middle of a wider conversation we've been having for a while, and it got bundled with a whole category of changes that I now realize it doesn't really belong with. My bad! If you rebase this to add the "signoff", I'd be happy to merge this. |
|
Fuck, I'd completely forgotten about this. Will do in the new year. Merry Xmas! |
If the port option is set, all requests for /metrics on other ports will be forwarded to the app. If it is unset or nil, or the ports match, export things as usual. Allows separate mounting of metrics and main app to enforce different security setups etc. Signed-off-by: James Turley <jamesturley@gocardless.com>
tragiclifestories
force-pushed the
gocardless:exporter-port
branch
from
643bae3
to
42860ce
|
Had 5 spare minutes and a hangover, so done this now. |
If the port option is set, all requests for /metrics on other ports will be forwarded to the app. If it is unset or nil, or the ports match, export things as usual.
Allows separate mounting of metrics and main app to enforce different security setups etc.