Hi @csmarchbanks Thank you for your response.

As mentioned, I am using your prometheus_client library. Looks like when CollectroRegistry is instantiated, it may be using that process PID as identification, thus destroying the previous metrics (to me, overriding would mean only replacing the same metrics as being used in the current instantiation, so I would really want to see overriding, not destroying).

Do you think that CollectorRegistry constructor could be extended to eventually provide a name / ID used for the push binding (class CollectorRegistry(Collector, binding_name: str = None))?

Having that addition would simplify a lot the client-side development, as right now all of us in the similar situation need to add some way of making the push_gateway part static. I do hear you about those other options, but this one takes just one extra string to get it working and not worrying about the extra service being there all the time.

If possible, I would also like to see a possibility to specify expiration time for metrics. Although, most likely my understanding of how it works is just not on the level to see how it could be done otherwise (I am just starting with it).

Another option that you could try is the pushadd_to_gateway method. This will only replace metrics with the same name, but it means that stale metrics would not be cleaned up and you would have to handle that manually.

I don't think we should have a binding_name on a collector, mostly as I would not want to tie a registry to something about pushing, a registry should just have metrics defined. Would it be helpful if a registry had a common label that could be shared among all metrics defined on it?

Expiration time would probably need to be a request for pushgateway, or at least I don't know of that feature today.

I don't think we should have a binding_name on a collector, mostly as I would not want to tie a registry to something about pushing, a registry should just have metrics defined.

Not sure if I understand this concern correctly. My understanding is that with the current implementation a collector is implicitly binding to the process (ID). What is a difference between using a process ID for binding vs. an arbitrary string or a random number? Using process ID for case like mine is clearly providing unexpected results (subsequent instantiation of push containing process is destroying previous information). On the other hand, using user supplied one (if elected to do that) would overcome this issue. For sure, as I am new to Prometheus, I am missing something.

Also, the second problem (for me) is that as collector binds to process id, there is basically no way to start two collectors in one script. This further convolutes a solution where for instance a couple or so collectors would be beneficial, but in order to do so some extra voodoo needs to be done to run multiple push processes and addressing them.

In my case, I have a handful of clients that talk to a single PHP client via REST. That module starts a Python script with each received data, and that script talks to another Python script that runs as a daemon thus having one collector open. Once the data is passed, that script exits. It would really simplify that design, if I could have multiple collectors open in that daemon script, instead of trying to have a dispatcher for a dispatcher to hit multiple daemon scripts. (Actually, it would be even simpler in my case, if just one collector could be used, where the push_to_gateway call would clearly separate pushes using different job names. Although, again most likely this is just my misunderstanding of push_to_gateway working.)