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 a Message/Job Status summary endpoint #153

Open
imyousuf opened this issue Mar 11, 2023 · 2 comments · May be fixed by #198
Open

[FEATURE] Add a Message/Job Status summary endpoint #153

imyousuf opened this issue Mar 11, 2023 · 2 comments · May be fixed by #198
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@imyousuf
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
There is no way to understand the status of messages and jobs by channel; so it difficult to say what is the current status summary.

Describe the solution you'd like
We want an endpoint that would summarize by channel number of messages dispatched vs non-dispatched and then by consumers jobs queued, inflight, delivered and dead.

Describe alternatives you've considered
Currently the alternate is to run query in the DB with group by

Additional context

@imyousuf imyousuf added the enhancement New feature or request label Mar 11, 2023
@imyousuf imyousuf added this to the v0.2 milestone Mar 11, 2023
@imran2140
Copy link
Collaborator

imran2140 commented Dec 4, 2024

We can add a stats endpoint for consumers (/channel/<channelId>/consumer/<consumerId>/stats) that expose job related metrics for a consumer. The initial implementation can add job count by status, which would be useful for monitoring number / ratio of dead jobs. The endpoint should require date filter parameters to avoid doing aggregation on all time jobs.

Parameter Type
createdSince required, iso date time (inclusive)
createdUntil optional, iso date time, default to current datetime (inclusive)

Output

{
    "JobStatus": {
        "<Status>": "<Count (int)>"
    }
}

@imyousuf imyousuf self-assigned this Dec 19, 2024
@imyousuf
Copy link
Collaborator Author

Since we implemented pruning, I am not sure if date filtering makes sense. Since only messages/jobs that will remain in DB would be dead messages; so they should be reenqued and processed manually in any case. So leaving out date based filtering capability in first iteration.

@imyousuf imyousuf linked a pull request Dec 31, 2024 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants