Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: add river inspector that returns various info about the system #781

Open
krhubert opened this issue Feb 20, 2025 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@krhubert
Copy link
Contributor

Motivation

I want to periodically upload metrics about jobs count, state, and kind.

The API that allows that would be great, but at the same time I have a workaround and I think this is a low prio issue.

API

I think about something similar as asynq inspector, but only with few methods like:

  • JobsCountByState
  • JobsCountByKind
  • etc...

This API might be utilized by riverui, because right now riverui uses its own sql queries

API dosen't need to guarantee backward compatibility as it will probably change in upcoming versions.

Possible solutions

  1. River middleware that sends telemetry data about each job.

This would work, but many projects enable sampling to reduce the cost of storing large amount of data.

  1. subscriptions

This approach requires a leader election to make sure only one instance sends data.
Btw - I think exposing a leader election as an API would be a great value added by river.

  1. Collector

This is the most common setup and collector could aggregate metrics. But if you want to keep things simple then instances send the telemetry data straight to the external service.

  1. Perioding job + sql

Right now I use periodic job and custom sql queries to fetch the data and send it once a while.

@bgentry bgentry added the enhancement New feature or request label Feb 20, 2025
@brandur
Copy link
Contributor

brandur commented Feb 20, 2025

Yeah, something like this seems like a good idea.

One problem that was raised recently is that some of those job count queries can get quite slow when job tables become too large. It makes me wonder if we should have some kind of system that tries to count things incrementally and keep track of stats, which would work fine, except then you either have only per-client stats, or need to aggregate them somehow.

We could also leverage the river_client table that already exists (I added it some time ago for future use, but haven't put it to work yet) so have clients write stats periodically which could be aggregated by any client easily/cheaply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants