Prometheus metrics exporting #811
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/MSC
Matrix/Media
Meta
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: continuwuation/continuwuity#811
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
note we can't leave /metrics on by default as many people expose all routes on their continuwuity deployment
I guess there's potentially an option to open a second listener for metrics, so it can run in a separate thread on a different port? That would add complexity, but would replicate one of the (unintentionally?) useful features of the multiple listeners in Synapse.
Yeah, this and HTML web interface ones are the ones I'd like people to be able to put on separate interfaces, although at that point, it makes sense to separate federation endpoints, too. The challenge is giving that flexibility without introducing a bunch of complexity in configuration.
I think separating client and federation mainly risks complicating reverse proxy setup, which at the moment is one of our strengths - people coming from Synapse are often amazed at the simplicity of just forwarding everything to one port.
That said, it wouldn't be terribly difficult to provide example config for all the major reverse proxies to show how to handle the metrics endpoint securely, so maybe it would be easier overall to just keep everything on one port? 🤔
Yeah the simplest default situation is to have everything on one port under matrix.sub and have sub/.well_know/matrix forwarded to matrix.sub, and then have the reverse proxy block /metrics. The challenge is when people want to start putting the HTML auth pages under a different domain. I guess that probably counts as an extra feature that's not needed for the initial implementation though.
what about making the metrics endpoint restrict requests to local connections only?
I guess that would be possible, but it opens the doors to issues with misconfiguration or spoofing if we allow reading the IP from a header for reverse proxies.
We could also allow configuring basic authentication, as most Prometheus implementations support that