Ответ мониторинга nginx от вышестоящего сервера

У меня есть установка обратного прокси с nginx.

Client ------> Nginx ------------------------------------> Backend Server
       <------       <-----------------------------------
                      (I want to see the requests here)

Как я могу записать HTTP-запросы, включая заголовки, отправленные с внутреннего сервера на nginx, в файл?

Возможно, одна из директив в HTTP-прокси-модуле nginx может помочь мне в этом.

Но я не могу найти никаких полезных указаний.


person Brian    schedule 15.07.2017    source источник


Ответы (2)


Примечание: я дал этот ответ до того, как OP добавил тег openresty. Я не эксперт в Openresty, но уверен, что привел правильные данные в случае ванильного Nginx.


«Внутренний сервер» в терминологии Nginx называется «восходящий». И есть отдельная страница в документации, на которой перечислены переменные, связанные с вверх по течению. Среди них вас наверняка заинтересуют

  • $upstream_addr - IP-адрес внутреннего сервера, обработавшего запрос
  • $upstream_connect_time, $upstream_header_time, $upstream_response_time - сколько времени Nginx ждал подтверждения соединения, заголовка от восходящего потока и сколько времени понадобилось бэкэнду для обработки запроса
  • $upstream_http_*NAME* будет содержать заголовок ответа *NAME*. Например, $upstream_http_etag или $upstream_http_last_modified.
  • есть и другие переменные для сообщения о состоянии кеширования, повторных попытках и т. д.

Это довольно распространенная практика - записывать их в файл журнала Nginx. Вам нужно будет объявить собственный формат журнала, например:

log_format my_upstream '$remote_addr [$time_local] "$request" $status'
  '"$upstream_addr" $upstream_response_time $upstream_http_etag';

а затем используйте его в location или server:

access_log /var/log/nginx/upstream.log my_upstream;
person Alexander Azarov    schedule 15.07.2017
comment
Странно, что мое значение upstream_* всегда отображает -. например upstream_addr, upstream_http_host и upstream_connect_time - person Brian; 16.07.2017
comment
Это точно не о местонахождении файла журнала. Некоторые переменные могут содержать -, когда они не имеют смысла. Например. upstream_response_time не имеет смысла в случае обслуживания статических файлов или когда Nginx вернул ответ из своего кеша. - person Alexander Azarov; 16.07.2017
comment
Я думаю, что моя проблема в том, что access_log запускается до того, как nginx получит ответ от восходящего потока. Вот почему мой upstream_addr не имеет значения. - person Brian; 16.07.2017
comment
Я не видел вашей конфигурации, поэтому понятия не имею, что происходит на вашей стороне. Что я знаю наверняка, так это то, что (а) Nginx - одна из самых стабильных программ, которые я встречал; (б) эти переменные работают; (в) все можно прикрутить, в том числе и самые стабильные софты. - person Alexander Azarov; 16.07.2017
comment
Есть ли способ получить доступ к заголовкам, отправленным с nginx на вышестоящий сервер? Я проверил код, и в восходящей структуре только headers_in и нет headers_out. - person sank; 05.06.2018

Если вы можете принять OpenResty:

Внутри https://github.com/openresty/lua-nginx-module#body_filter_by_lua_block вы можете реконструировать тело полностью, если хотите включить его в журнал. Если указан флаг eof, вы можете получить весь заголовок ответа (https://github.com/openresty/lua-nginx-module#ngxrespget_headers)

Десять устанавливают переменную в Lua и используют ее в log_format.

Внимание - ваш лог-файл доступа может быть огромным!

Подсказка - вы можете использовать отдельные access_log и log_format для ведения журнала ответов.

person Alexander Altshuler    schedule 17.07.2017
comment
Это относится только к заголовкам ответа, возвращаемым клиенту (не между прокси и восходящим потоком). - person trinth; 13.09.2019