Use prometheus as a monitoring server and storage
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 37.4k
- Forks
- 3k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 73
Description
What problem will this feature address?
What I'm seeing primarily with #1735 is that dokploy uses a bespoke homegrown monitoring system, which has some downsides to it (such as needing maintenance on this repo for both storage, typing, and collection).
Describe the solution you'd like
Instead, I'd recommend to use Prometheus (and friends) for metrics collection, storage, and querying.
With it, the dashboards can be unified, and dokploy can deploy prometheus-node-exporter uniformly across all nodes, and collect data with one format, that it can then provide hardcoded queries and graphs for on monitoring screens, that will be up-to-date.
With it, monitoring is not limited to when the screen is opened, but it will be historical, all the time, and even far into the past.
With it, there's the possibility of using prometheus-like alternatives (such as Grafana's Mimir) that can save to S3, hooking into existing S3 config of dokploy, and saving metrics on S3 as well.
With it, there's also the possibility of pointing to metrics endpoints in applications, and then (under monitoring) creating application-specific graphs via generic queries, and monitoring your application that way. (These can then also be shared around, etc.)
This allows full extendability with future monitoring types (System PSI, networking, process states, etc.), while keeping the storage and querying simple, without needing to add extra compiled code to this repo pertaining the storage of all that data; just deploying new collectors, pointing at them, and then querying that data back.
Describe alternatives you've considered
Keeping the current system as-is.
Additional context
No response
Will you send a PR to implement it?
I'll help with the implementation, and give guidance/information.
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
No files, tests, or entry points are named. Start by reviewing the existing monitoring system referenced in #1735 and the current monitoring screens, then define the Prometheus deployment, collection, storage, querying, and application-metrics scope; done means historical metrics and dashboards replace the bespoke system.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grafana, prometheus
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100