Fork process models for metric batch reader do not work

[lzchen]

and when a new process is not created (simply a new fork is created).

When does this happen?

One thing I am still thinking about is how do I do the same for PeriodicExportingMetricReader? Unlike tracing/logging where the events are received by processor, the PMR collects them with collect function. There is nothing like emit or on_start/on_end where I can check if the pids to see the fork hook is invoked and invoke if not.

Originally posted by @srikanthccv in #2277 (comment)

[PeterJCLaw]

Is this specific to uWSGI? If so could uWSGI's own post-fork mechanisms be used to provide support?

[srikanthccv]

What do you mean by could uWSGI's own post-fork mechanisms be used to provide support?

[PeterJCLaw]

Oh, sorry, I'd misread the conversation which this was extracted from. Somehow I had thought that this issue (#2767) was essentially reporting the issue that that PR (#2277) was actually fixing. I was then suggesting that using uWSGI's decorators could help solve that issue by providing on-fork hooks compatible with uWSGI.

I suspect that uWSGI's fork hooks might still be useful here (at least when uWSGI is being used), though obviously this is broader than that.

[srikanthccv]

Yes, we have documented it here http://github.com/open-telemetry/opentelemetry-python/tree/main/docs/examples/fork-process-model#uwsgi-postfork-decorator. Since which application server is used outside the control of the OpenTelemetry, we documented how to work around the current limitations with the postfork hooks. That example no longer represents the current state of our SDK with gunicorn/uWSGI. Now, only metrics SDK doesn't work, so docs should be updated to reflect that.