Как сделать выдачу статики с параллельным вызовом fastcgi без ожидания его завершения?

Question

[MirKey]

Сервер выдаёт статический контент, при запросе нужно выдать файлы, но при этом отправить в fastcgi/python скрипт информацию о запросе для статистики. То есть ждать ответа от fastcgi не нужно. Fastcgi не должен участвовать в обработке запроса, на нём только статистика.
Если fastcgi не доступен, то ни как не реагировать - т.е. не должен выбрасывать ошибку.

Answer 1

[ky0]

nginx.org/ru/docs/http/ngx_http_mirror_module.html

Comments

[MirKey]

Спасибо, это то что нужно.
А почему именованные пути не работают в зеркале?

location @mirror {  
	expires off; 
        fastcgi_pass   127.0.0.1:9200;
        fastcgi_param REQUEST_METHOD $request_method;
        fastcgi_param CONTENT_TYPE $content_type;
        fastcgi_param CONTENT_LENGTH $content_length;
		fastcgi_param PATH_INFO $fastcgi_script_name;
		fastcgi_param QUERY_STRING $query_string;
	}
	 
	location / { 
		mirror @mirror;
	}

Answer 2

[Сергей П]

А для чего вам такое странное поведение?
Вообще тут много вопросов из вашей постановки вытекает. Очень тревожных и странных вопросов.
Начать можно с чего. Вы ставите вопрос так, будто хотите передавать данные "в скрипт". Надо перестраивать ход мысли. Вы передаёте данные в некий сторадж. Это может быть некая структура в памяти процесса (например вашего FastCGI-сервера), или в БД (postgres, sqlite, clickhouse, redis), или в очереди какой-нибудь (rabbit, кафка)... Данные не могут передаваться в код. Разве что в виде параметров и аргументов.
Опять же, ваш FastCGI может быть запущен в нескольких инстансах, как вы будете заботиться о синхронзации? Прочитайте про CAP-теорему. Если вы городите какое-то самодельное решение, то вам придётся как следует понимать суть этой теоремы, проблемы, которые она обрисовывает и то, на каких двух стульях из трёх вы хотите сидеть.

Если вы подробнее расскажете о своей задаче, то вам подскажут какими способами правильнее такие вещи делать. Пока что складывается ощущение, что в момент отдачи статики вы хотите делать http-запросы вашему бэкенду. Для чего? Считать статистику? Биллинг?

Вообще лучше всеми этими вопросами не грузить ваш nginx, хотя там можно даже lua-скрипты встраивать с нетривиальной логикой. Для некоторых нужд можно парсить, например, логи nginx-а. Настроить так, чтобы в нужный пайп сыпалось только то, что требуется и отдельным микросервисом его вычитывать и делать что там вам требуется. Агрегировать? Статистику считать? Журналировать?
Так же можно поднять какую-то очередь и заставить nginx туда писать по факту обращений.
Вообще там много вопросов будет. А что если к файлу обратились, но контент не качали, только заголовок? А что если разрыв соединения? А что если один большой файл много раз фрагментами докачивали? А что если кто-то себе поставил перед вашим сервером кэширующий прокси?

Теги вашего вопроса следует привести в соответствие с правилами. Тег Python не нужен, ведь вы не привели никакого кода и к питону ваш вопрос совершенно никакого отношения не имеет.

Comments

[MirKey]

Идея в том чтобы собирать статистику по посещаемым страницам на сайте. Статистика пока будет собираться в pgsql/edgedb: url, query, url referrer, user-agent, IP addr, cookie token, [UTM:5].
Разрывы соединений, фрагменты, кеширующие прокси это всё не критично.

[Сергей П]

MirKey, для вашего случая оптимально отдельным процессом парсить логи через пайп. Создайте пайп в файловой системе и пишите логи nginx туда, а читайте его отдельным простеньким процессом, который будет писать в БД. Просто и сердито.

[MirKey]

Сергей П, возможно через пайп идеальное решение по скорости работы(хм, не факт, запросы через диск...), однако нужно решить вопрос переполнения логов на случай если скрипт/процесс отвалится и в целом у меня слабые познания в таких решениях, к тому же подсказали mirror/ngx_http_mirror_module что идеально подходит под решение задачи.

[Сергей П]

MirKey, может быть mirror и подходит идеально, не пробовал.
Можно, кстати, не в пайп писать, а в обычные файлы со, скажем, суточной или часовой ротацией.
Я бы добавил скрипту отдельный ключик, как
tail -F <access.log>
Чтобы с ним скрипт постоянно держал открытым на чтение этот файл и сразу вычитывал дописываемое содержимое.
Без ключа такой скрипт мог бы всасывать разом весь каталог с логами по маске и повторно не забирал записи, которые у него уже есть по таймштампу.
Если такой каталог смонтировать на небольшой рамдрайв, то медленно точно не будет. А можно замонтировать и на SSD, если приоритет не в скорости. Сейчас SSD достаточно крепки для такого использования.
Наверно это тот ещё колхоз по сравнению со специальными модулями для nginx-а, зато это универсальное решение не только для nginx, но и для всего, что пишет полезное в логи.