[Enhancement]: Metrics endpoint for monitoring

[LeonFroelje]

Type of Enhancement

Server Backend

Describe the Feature/Enhancement

It would be awesome if there was some way to be able to expose some server metrics to some external application. Other projects do this by exposing a /metrics endpoint where some client can authenticate and collect these metrics.

Why would this be helpful?

I have set up Prometheus for collecting metrics from my self-hosted services and visualize them with Grafana. As far as I know, this is a pretty common setup. This is useful when something goes wrong, and I need to troubleshoot.

Future Implementation (Screenshot)

We could create a MetricsController and then route any requests to the /metrics endpoint to this controller. Within the metrics controller, we would then need to check whether the request is authenticated, i.e. if the user may access the metrics endpoint.
For authentication, we could add a permission such as canAccessMetrics to the users model and then check if it's set.
If the request is authenticated, the response contains some metrics data in e.g. JSON format.

Audiobookshelf Server Version

v1.17.7

Current Implementation (Screenshot)

No response

[nichwall]

What kind of metrics do you expect to be exposed?

[LeonFroelje]

Just some ideas off the top of my head would be

• Number of active (logged in) users
• Total number of users
• Number of active sessions
• Disk space used in total
• Number of audiobooks/items in libraries in total
• Uptime
• Number of backups
• Average listening time
• Session start/end timestamps
• Number of active upload tasks
• Active library scans
• Failed login attempts

Maybe even library specific stuff such as number of audiobooks in libraries or size of libraries.
I don't think that system metrics like memory/CPU usage would be strictly necessary, since one could just use the node exporter (in Prometheus) for that stuff.

EDIT: typo

[jaycedk]

Would love to see this also 😉

[nichwall]

Thanks for writing to a list. Some of this would be addressed by #3335, but not sure if that same endpoint should return everything or add a new endpoint with all of the information.

[LeonFroelje]

Prometheus expects a single metrics endpoint for scrape jobs. I'm not sure how other monitoring solutions work in this regard. Therefore, at least for Prometheus users, it would be convenient to have a single endpoint for all the metrics we want to expose.
If we add all the metrics not addressed in #3335 to the /libraries/stats endpoint, the URL should at least be changed to not be part of the /libraries path.
If we add another endpoint (for example /metrics) in addition to /libraries/stats, the endpoint in #3335 might be redundant since the /metrics endpoint would (probably?) also return the collective library stats.
I'm not sure if this is the best possible solution, but my preference would be to have a single /metrics (or /stats) endpoint that returns everything instead of separate endpoints for library stats and metrics. The stats pages in the UI could then be refactored to query the information returned by the /metrics endpoint. For library specific stats, query parameters might be used instead of returning all the data and only rendering a subset of it.
If there is enough interest in this feature and the way of implementation is agreed upon, I would be willing to implement it unless someone else really wants to.