Hi, Maxim, and thanks for the feedback. My approach is to monitor the downstream NGINX server, whereas I think that your approach points at monitoring the upstream Gunicorn, isn't it? If so, then yes, that's another way to do it. I have never checked whether Gunicorn (in my particular case) offers that information, but it would definitely be one way to do it.
Anyhow, I still would love to be able to query NGINX for much more information about active requests and upstreams but, unfortunately, I cannot be of much help with the internals of NGINX. Thanks. On Thu, Aug 21, 2025 at 4:05 PM Maxim Dounin <mdou...@mdounin.ru> wrote: > Hello! > > On Thu, Aug 21, 2025 at 09:38:16AM +0200, Jaume Sabater wrote: > > > Related to the information provided by NGINX via stub_status, I would > like > > to suggest implementing ways to get feedback on the upstream servers, so > > one could figure out when they are done with requests and updates on the > > upstream node can start again. > > > > For example, let's say I have an upstream "myapp" with two servers, " > > myapp1.domain.com" and "myapp2.domain.com". I add the "down" option to > the > > first one and reload. Then I have to wait for the server to finish off > > processing requests to that first server before deploying the new version > > of the "myapp" application. Once completed, I need to remove the "down" > > option, add it to the other server, then reload. Not sure if this is the > > expected way to do things, of course, but right now I need to play with > > console tools to check for connections, which is not as reliable as > having > > NGINX inform about, say, they number of active requests with " > > myapp1.domain.com". > > Thanks for the input. > > With reloads, I don't think implementing this would be trivial and > can be done efficiently, as this information needs to be collected > and updated in shared memory. Even when using upstream shared > memory zones, since these are recreated on configuration reloads, > so the new worker processes don't have access to data of old > upstream servers. > > Just in case, the most simple approach for the particular use case > would be to monitor old worker processes - and when they are all > done, you can be sure the upstream server in question is no longer > used. This should work even if the same server is used elsewhere, > and you cannot rely on checking connections and/or status of the > upstream server itself. > > -- > Maxim Dounin > http://mdounin.ru/ > -- Jaume Sabater "Ubi sapientas ibi libertas"
