Jobs monitor
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 49.2k
- Forks
- 4.5k
- Avg merge
- 1d 3m
- Merged PRs (30d)
- 239
Description
Is your feature request related to a problem? Please describe.
In my LocalAI use case, users send tasks through the Nextcloud Assistant and the OpenAI and LocalAI Integration.
The tasks:
- can be of different type: transcription, summaries, chatting .. and can require long time to complete.
- can come concurrently and from multiple instances so that I'd like to know how and when these tasks are executing, the resources they are using.
Currently I don't have a way to know the tasks currently running in LocalAI.
Describe the solution you'd like
It would be great to have a way to monitor the jobs that are sent to LocalAI. The way I think it would useful, is to have a Linux top-like command in which I can see information about running jobs:
- job id
- job status: executing, queued ...
- start time
- command
- backend
- model
- client (IP and / or user agent)
Other interesting features that could be considered:
- To have a way to kill a job.
- Be able to see past jobs with their start and end times.
- To have this monitoring panel in the Web UI
Describe alternatives you've considered
I had a look at the endpoint /backends/jobs but I get a "Resource not found" error (also reported here).
Additional context
I'm not sure if what I'm asking is already possible with current API, but as mentioned just above my attempts were unsuccessful.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by investigating the /backends/jobs endpoint and the existing LocalAI API behavior, including why it returns "Resource not found." Define how running and past jobs should expose job IDs, status, timing, command, backend, model, client, and optional cancellation before implementing monitoring or a Web UI.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend, observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100