Thinking about optional addition of /metrics endpoint logic to docker build

Describe the solution you'd like

Currently pgadmin4 running in docker container do not provide metrics for opservability.
In our project we run pgadmin4 inside kubernetes clusters behind custom proxies to avoid exposing postgres instance to the company network.

Only pgadmin4 .. and the micoservices running inside kubernetes should be able to connect to the postgres ports.

This brings us the challenge that multiple users are connected to this pgadmin4 instance and we faced already multiple times the issue that pgadmin4 was temporary not / only very slow responding for unknown reasons.

In cloud / kubernetes it is common best practice that services running inside kubernetes provide a /metrics endpoint which can be scraped by prometheus to bring observability informations to the outside world.

I started now to investigate what pgadmin4 out of the box supports

.. and have not really found anything usefull in such situations and want to ask about a possibility to optional extend pgadmin4 docker build with a "wrapper" library which simply would add the metrics information and endpoint to the application if a special container startup environment variable is present.

First reasearches brought me awareness about the existence of a promissing library which would bring such a possibility with very low efford.

https://github.com/rycus86/prometheus_flask_exporter

I created there a help request about my idea:
https://github.com/rycus86/prometheus_flask_exporter/issues/167

And it looks like ... yes it would not be complicated

Main point about chance of such a feature request

My main point why i create this Feature request draft is:

... would it be a interesting optional feature which whould get a chance to be part of the default docker build creation ?
... if it would be done in the correct way ... for sure ..
... or is it completely not wanted / wished to have such a thing in the default pgadmin4 docker container available ?

In case of a negative feedback i will continue to do this for our needs inside the company .. but i thought ... it would really a fruitfull feature for all the others which face same situations like we.

Describe alternatives you've considered

... here i would spend time later .. if such a optional feature would have a chance to be added to default docker build

Additional context

.... same for here ... I would want to spend here only time if the feature request would have a chance.