Dokploy / Dokploy/dokploy

Use prometheus as a monitoring server and storage

Open
#2,376 0 comments 19 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.