[Feature] Add queued jobs count to telemetry

[dangarmol]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Currently, the exposed telemetry only exposes the number of active jobs, such as immich_queues_metadata_extraction_active, which is most certainly going to be either 0 or whatever the max parallelism is set to. This is not very useful. A much more useful trace would be something like immich_queues_metadata_extraction_queued for all jobs. This way, the rate at which jobs are consumed can be observed much more accurately.

This would be really helpful to troubleshoot #24520. I just tried to create a visualisation in my existing Prometheus/Grafana deployment but the metrics I need are not available.

There is #11069, but that FR is more of a generic ask for additional metrics. My request is targeted to a particular set of metrics (queued jobs).

Platform

• Server
• Web
• Mobile

[bo0tzz]

We can track this under #11069; a new thread for every metric someone wants could get out of hand quick ;)

[dangarmol]

Hey @bo0tzz, I’m sorry but I disagree. I think that having a blanket Feature Request for all metrics does not encourage anyone to make incremental PRs to close FRs over time. That blanket FR will likely stay there for a long time (it’s been there for almost 1.5 years)

On the other hand, the metrics I requested are quite scoped and related to an open issue. It is also very easy to open a PR that closes this FR, whereas the other one may as well be open forever, since there can always be new metrics that people want.

In fact, I was planning on doing this myself today or tomorrow, but I wanted to have a linked FR to explain the reason why the PR is needed. I already got some quick changes that I tested locally and seem to be working.

I’ll keep you posted, but in the meantime please consider reopening this FR and, in general, discouraging blanket long-lived Issues/Feature Requests in favour of more atomic ones 😉

[bo0tzz]

It's a decision made on a case to case basis, I'm not keen to blanket discourage or encourage any particular type. Note that we don't require a thread for every PR; a small change like this one is perfectly fine without prior discussion, for larger changes we do prefer discussing them with us first to make sure there's no wasted effort (but that doesn't have to be in an issue or FR discussion specifically).