Did I get that right?

You did.

Do you think it might help to add some docs explaining what all the Uvicorn loggers do? Maybe on the server behavior page, cross-referencing it with the logging settings section? I'm happy to update the docs in a separate PR if that makes more sense.

I'd be happy to receive help. You can use this branch if you want, so we can merge the functionality with the docs together (I'm not possessive with my branches 👀 ).

But do we agree with those changes? I'm not sure about it myself... @br3ndonland @euri10 opinions?

Ok cool! I will get some docs pushed up here soon.

And definitely open to suggestions on the descriptions and such. I will defer to @euri10 for the direction we want to go overall.

well I'd be in favor of NOT changing the name uvicorn.error

Not because I think the name is not confusing, it is.

But because it mimics what gunicorn does with gunicorn.error` and dozens of users, not to say hundreds or even thousands, are on a daily basis using, seeing this same exact name, so really I don't get the fuss on this (last commit on https://github.com/benoitc/gunicorn/blob/master/examples/logging.conf is 20 feb 2014) : people literally use this name for almost ten years now....

I don't think we gain anything in changing something that people are most likely used to now for a long time.

This said, I won't oppose it should people feel strongly about it, but to me there's almost no gain in changing, so I'll let you choose :)

I'm totally fine with not changing it. :)

Let's not do this then. I've closed #562. If someone has a good argument, and/or strategy to achieve it, feel free to comment on the issue.

That sounds good. I'm also fine with keeping the current logger name.

This said, I won't oppose it should people feel strongly about it, but to me there's almost no gain in changing, so I'll let you choose :)

I don't feel very strongly about it, as I don't work with uvicorn anymore - but I do find the reasoning to keep the current scheme questionable at best. Gunicorn using a very confusing and in fact problem-inducing (i.e. log monitoring) naming scheme is not a good reason to propagate that anti-pattern further. I also wonder if the extend of the confusion can be compared. Uvicorn greets the user with "[gunicorn.error] Application startup complete" for example.

For me as a newcomer it was really confusing to see a server starting and greeting me with a bunch of errors saying things like
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit).
For me, stderr has been always to log errors and not informational messages. For instance, starting uvicorn like this:
uvicorn main:app 2>error.log 1>out.log
will result in a file error.log with the start information.
I'm using Google Cloud Run and Cloud Functions and this might trigger alerts that aren't real errors.

I've changed my mind. I'm strong about this change now. I'm reopening this PR.

I'll update the documentation.

I'm closing this as stale.

If someone wants to help me, and take this, I'd appreciate.

I'd consider taking a poke at this; what critical parts remain?

I think the "missing" section on the description. 👀

Would push for this change, as I dug into a rabbit hole of confusion seeing the logger named as uvicorn.error

Like a user said earlier, what if if we rename uvicorn.access touvicorn.client and uvicorn.error to uvicorn.client?