-
-
Notifications
You must be signed in to change notification settings - Fork 753
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.
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
Honor gunicorn access log format #527
Comments
This is a pretty big loss for observability for us, and means we have to implement something out of band (and therefore less efficient). Any word on if it will be worked on? |
Any update on this? |
Any update on this one? |
Hey folks - "Any update on this" is almost always not helpful. If there was an update on it, it'd be here on the ticket. |
@tomchristie I would be willing to take a stab. i've taken a look at the code and it seems like the We would basically need to thread through the Does this approach sound somewhat correct to you? |
@tomchristie just following up to see if my above comment made sense. |
We have the same problem at the moment and are about to write a custom logging engine for this, because we must be able to alter the uvicorn log format when running it from gunicorn. Any update on this if there will be a fix? In addition, ideally it should also be configurable in a logging.conf:
|
I have implemented the gunicorn logging in a very naive and straightforward way in my branch. Would you be interested in a PR? |
yes @immerrr ! |
Now that there is a PR, what would be required to add this functionality? We'd like to match our existing aiohttp-created logs with some new logs created from a FastAPI -> uvicorn -> gunicorn stack. |
tl;dr : not a priority on my side at all The longer version is I'm lacking time mostly, plus I dont use gunicorn nor am familiar enough with its internals to have a good idea if the implementation is correct or sensible. On top of that there are 0 tests for the feature which makes me very hesitant since this part of the code (UvicornWorker) is already weakly tested in our codebase. |
@euri10 the low priority thing is understandable. i asked it in the PR, but let me reiterate, is there anything that would help to get the ball rolling here? i mean, if it's the gunicorn part, maybe we can ask nicely in the gunicorn community to have someone come over and have a look. if it's the tests, then i can write them risking that the test code will be thrown away if the approach is not solid enough, but it's fine, i guess. WDYT? |
I answered in the PR @immerrr |
Can we merge this PR? This is extremely useful for me. |
I just had my issue merged into this thread. Any updates on this? |
While this is not implemented, asgi-logger might be useful to customize access log format. |
I got the answer. |
gunicorn support async base worker offically now. may be is time to rewrite UvicornWorker(AsyncWorker). AsyncWorker source:
it is so long to wait. #606 |
I am using FastAPI, and this worked for me: |
When running under gunicorn,
--access-logformat
isn't honored.There was some discussion of this in #389, but I didn't see an open issue for it.
Important
The text was updated successfully, but these errors were encountered: