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.