starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Metrics endpoint for monitoring #2486

New Issue
Open
opened 2026-04-25 00:07:39 +02:00 by adam · 6 comments
adam commented 2026-04-25 00:07:39 +02:00
Owner
Copy Link
Copy Source

Originally created by @LeonFroelje on GitHub (Jan 13, 2025).

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

Originally created by @LeonFroelje on GitHub (Jan 13, 2025). ### 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_
adam added the enhancement label 2026-04-25 00:07:39 +02:00
adam commented 2026-04-25 00:07:40 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 13, 2025):

What kind of metrics do you expect to be exposed?

@nichwall commented on GitHub (Jan 13, 2025): What kind of metrics do you expect to be exposed?
adam commented 2026-04-25 00:07:40 +02:00
Author
Owner
Copy Link
Copy Source

@LeonFroelje commented on GitHub (Jan 13, 2025):

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

@LeonFroelje commented on GitHub (Jan 13, 2025): 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
adam commented 2026-04-25 00:07:40 +02:00
Author
Owner
Copy Link
Copy Source

@jaycedk commented on GitHub (Jan 15, 2025):

Would love to see this also 😉

@jaycedk commented on GitHub (Jan 15, 2025): Would love to see this also 😉
adam commented 2026-04-25 00:07:40 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 15, 2025):

Thanks for writing to a list. Some of this would be addressed by https://github.com/advplyr/audiobookshelf/pull/3335, but not sure if that same endpoint should return everything or add a new endpoint with all of the information.

@nichwall commented on GitHub (Jan 15, 2025): Thanks for writing to a list. Some of this would be addressed by https://github.com/advplyr/audiobookshelf/pull/3335, but not sure if that same endpoint should return everything or add a new endpoint with all of the information.
adam commented 2026-04-25 00:07:40 +02:00
Author
Owner
Copy Link
Copy Source

@LeonFroelje commented on GitHub (Jan 15, 2025):

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.

@LeonFroelje commented on GitHub (Jan 15, 2025): 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.
adam commented 2026-04-25 00:07:41 +02:00
Author
Owner
Copy Link
Copy Source

@gilgwath commented on GitHub (Jul 17, 2025):

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

Good suggestions; I'd add to that Last successful backup. Handy to know when your backups stopped working.

@gilgwath commented on GitHub (Jul 17, 2025): > 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 Good suggestions; I'd add to that `Last successful backup`. Handy to know when your backups stopped working.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2486
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?