Re: Пустая переменная $upstream status при 499

[yanda.a]

Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> Где-то тут общение с бекендом завершено, однако ответ ещё не 
> полностью отправлен клиенту.  В процессе отправки клиенте 
> закрывает HTTP/2 stream:
Кстати да, я немного не досмотрел. В этом server {} не используется listen
http2. Но, в логах наблюдается именно http/2.0 и в хроме видно h2 в консоли
разработчика. Не могли бы вы подсказать, насколько это адекватно? 

> При этом в функции ngx_http_terminate_request(), которая обновляет 
> статус запроса тогда и только тогда, когда статус либо ещё не 
> стоит, либо клиенту вообще ничего не было отправлено.  В данном 
> случае, видимо, за счёт использования HTTP/2 случается ситуация, 
> когда клиенту вообще ничего не отправлено (вероятно, за счёт 
> других данных в соединении), и статус таки обновляется на 499.
> 
> Ситуация с $upstream_status "-", видимо, получается похожим 
> образом: если в процессе работы с бекендом клиент отменяет HTTP/2 
> stream, то у соответствующей этому stream'у структуре соединения 
> будет проставлен флаг c->error.  И если после этого случается 
> timeout бекенда, то в ngx_http_upstream_next() nginx, увидев 
> стоящий флаг c->error, не пойдёт на следующий бекенд, а вместо 
> этого завершит обработку запроса с кодом 499.
> 
> То есть я был неправ, получить в логах 499 при использовании 
> proxy_ignore_client_abort таки можно, хотя и непросто.  В простых 
> случаях это в основном затрагивает HTTP/2, но и в HTTP/1.x можно 
> получить похожее поведение, например, при использовании 
> подзапросов.
> 
> На практике при использовании proxy_ignore_client_abort это 
> означает, что работа с бекендом завершена или не начиналась.
> 
> Возвращаясь к исходному вопросу: да, текущее поведение выглядит 
> нормально.

Постараюсь описать ситуацию. Мы пытаемся выгружать эти логи в clickhouse для
анализа latency и работы бекендов в целом, и сбора разнообразной статистики.
Для этого на выходе у нас ожидается, что переменные (после парсинга это
массивы в нашем случае) $upstream_addr, $upstream_response_time и
$upstream_status имеют одну длину. Но, как показала практика, это не всегда
так. В связи с этим ещё один, вероятно последний, вопрос. Есть ли
возможность сделать это поведение более предсказуемым? Или проще добавлять
недостающие элементы массива в процессе обработки (по сути угадывая, что там
должно быть)?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286718#msg-286718