Skip to content

added gunicorn production server documentation #1272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

added gunicorn production server documentation #1272

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2de4bb6
added gunicorn production server documentation
evananyonga Oct 22, 2020
dcd9dde
added a pipeline in the post_fork function
evananyonga Oct 27, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions ...ion/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,17 @@ def hello():
application = get_wsgi_application()
application = OpenTelemetryMiddleware(application)


Usage in Production Server (gunicorn)
------------------------------------

Modify the ``gunicorn.config.py`` file as shown below.

.. code-block:: python

def post_fork(server, worker):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have seen some problems regarding the forking process of Gunicorn when working with Opencensus like here and here. The main issue was that the worker thread that was responsible for sending spans to the exporter (BatchSpanProcessor in this case) was not copied to the child processes due to Gunicorn using os.fork() to spawn them. Does this post_fork() configuration fix this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, this is not enough. The entire trace pipeline (particularly batch processor) needs to be setup in post_fork for it to work.

worker(DjangoInstrumentor().instrument())
Copy link
Contributor

@owais owais Oct 22, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Why is result of instrument() being passed on to worker? Is it even expected or required for a worker to be called like this in post_fork? AFAIK, you can totally ignore doing anything with the server and worker object, and just perform general initialization but may be I'm wrong.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right actually. I was thinking about that too but I thought instrumentation should pass through a worker. I see now and agree that passing it into post_fork is quite sufficient

Copy link
Contributor

@owais owais Oct 22, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. As far as I remember, tracing as a whole needs to be setup in post_fork including creating the tracer provider, span processors, instrumentation etc. Especially if batch span processor is used. Any reason to only mention instrumentation here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you suggesting that I create a pipeline in post_fork? I was thinking more of using opentelemetry as an agent. I could be wrong.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you recommended a pipeline. Let me put that in effect.


API
---
"""
Expand Down