On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote:

>>> Если вы предлагаете писать напрямую с nginx-а в файл --
>>> сделайте у себя ротацию файлов с интервалом 30 сек
>>> при 200-250 тыс подключений/сек...
>>>
>>> Если у вас уже есть такое рабочее решение -
>>> поделитесь опытом, буду рад вас выслушать.

>> В этом сообщении Вы говорите о том, что Вы пробовали писать логи
>> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд,
>> при при 200-250 тыс подключений/сек, и у Вас не получилось
>> создать "рабочее решение".

> Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО!
> Я сказал ровно то, что и хотел сказать.
> Где вы прочитали про "не получилось" ???
> Пожалуйста процитируйте... без своих домыслов и фантазий.

А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню:
https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKIHBFWHHTQRKDQY53XGE5BN.html

Я же практически прямым текстом Вам написал, что Ваша попытка
выжать максимум производительности из связки nginx-syslog -
это есть проблема Y и задал Вам вопрос, какую именно проблему X
Вы таким способом пытаетесь решить. И что я слышу в ответ -
что Вы не смогли получить работающую систему при 200-250 тысяч
подключений в секунду и при ротации логов раз в 30 секунд - именно
это и значают Ваши слова "Если у вас уже есть такое рабочее решение
- поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете,
как именно построить рабочую систему ротации логов при такой нагрузке,
то логично предположить, что Вы попытались это сделать, у Вас это
не получилось и Вы тогда пошли другим путем - писать логи
через syslog unix socket`ы, потому что там ротации не надо делать.

А невозможность получить "такое рабочее решение" при таких параметрах
нагрузки может быть вызвана только тем, что ротацию логов Вы делали
через SIGHUP а не через SIGUSR1.

То есть, я так и понял Ваш ответ на мой вопрос, что проблемой X,
которую Вам не удалось решить, является проблема ротации логов
nginx раз в 30 секунд при нагрузке в 200-250 тыс подключений/сек.

И поэтому - Вы, вместо того, чтобы искать решение проблемы Х,
начали решать проблему Y - искать способы, как оптимизировать
работу связки nginx-syslog - заведомо более затратный по ресурсам
способом, по сравнению с обработкой и ротацией логов по SIGUSR1.

И если я Вам задаю вопрос о том, в чем именно состоит Ваша проблема X,
которую Вы пытаетесь решить, а в ответ слышу про количество подключений
в секунду и интервал ротации раз в 30 секунд и "Если у вас уже есть
такое рабочее решение - поделитесь опытом, буду рад вас выслушать",
то что еще мне оствалалось подумать в этой ситуации, и каким еще
образом я мог бы понять Ваши слова? Вот попробуйте поставить себя
на мое место и посмотреть на эту ситуацию с моей точки зрения,
когда Вы задаете кому-то такой вопрос и слышие такой ответ.

И все последующее - это уже следствие того, что Вы начали
говорить, что syslog-unix socket-python - это есть решение
проблемы X. А сама проблема X у вас появилась из-за использования
SIGHUP дял ротации логов, вместо SIGUSR1. Понятно, что при таких
парметрах, 200-250 подключений в секунду и интервале ротации раз
в 30 секунд ничего работать не будет. Но при использовании SIGUSR1
- нет проблем, вне зависимости от того, какое там количество подключений
в секунду, 200 тысяч 250 тысяч или какое-либо еще, потому что рабочие
процессы при ротации через SIGUSR1 не перезапускаются, а всего лишь
переоткрывается лог-файл, что происходит практически мгновенно
и это очень дешевая операция, много ресурсов она не занимает.

Или все было совсем не так и это все является моими домыслами
и фантазиями и Ваши слова "Если у вас уже есть такое рабочее
решение - поделитесь опытом, буду рад вас выслушать" означают
что-то совершенно другое?

Я и поделился с Вами опытом - используйте SIGUSR1
вместо SIGHUP и тогда Ваша проблема X будет решена
и тогда не надо будет заниматься поиском решения
для проблемы Y - как сделать, чтобы связка nginx-syslog
через unix socket не глючила и не теряла сообщения.

Причина проблемы ведь не в nginx, причина проблемы
в syslog, потому что он читает данные в один поток,
и не успевает их обрабатывать. А когда вы создаете
10 потоков на Python - то вы увеличиваете мощность
"читателя" в 10 и более раз, потому что в такой
ситуации в каждый из unix socket`ов уходит в 10 раз
меньше сообщений и тогда читающая сторона успевает
эти сообщения читать и поэтому у nginx нет причин
чтобы дропать сообщения из-за того, что syslog
не успевает их читать из unix socket`а.

>> Причина, почему у Вас не получилось настроить ротацию лог-файлов
>> при записи логов "напрямую с nginx-а в файл" может быть в такой
>> ситуации только одна - для ротации лог-файлов Вы использовали
>> сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось.

> Вероятно вам не раз приходилось сталкиваться с подобным, и вы автоматически считаете, что так поступают все.
> Распространенная модель поведения.
> Еще раз -- единственная новость тут для меня была в том, что у меня не получилось.

Я именно так и понял Ваш ответ:

>>> Если вы предлагаете писать напрямую с nginx-а в файл --
>>> сделайте у себя ротацию файлов с интервалом 30 сек
>>> при 200-250 тыс подключений/сек...
>>>
>>> Если у вас уже есть такое рабочее решение -
>>> поделитесь опытом, буду рад вас выслушать.

Потому что если бы у Вас получилось - то Вы бы не говорили,
что Вам не удалось настроить ротацию логов раз в 30 секунд
при 200-250 тысяч подключений в секунду и Вы бы тогда не говорили,
что были бы рады выслушать как сделать рабочее решение при таких
параметрах нагрузки. Если бы Вы для ротации использовали бы SIGUSR1
а не SIGHUP - тогда бы у Вас все получилось и вообще не надо было бы
говорить про количество подключений и интервал ротации, потому что
через SIGUSR1 ротацию логов можно делать хоть раз в секунду,
при любом количестве подключений, хоть 100 миллионов в секунду.

Каким еще способом можно понять Ваш ответ, если Вы мне в ответ приводите
информацию про параметры нагрузки и спрашиваете меня есть ли у меня
такое рабочее решение этой Вашей проблемы X с ротацией лог-файлов.

> Все как раз получилось, дальше с этим работать было неудобно.

Читать из unix socket`а удобно, паралельно в 10 потоков,
а читать из одного текстового лог-файла - неудобно?
А в чем именно неудобство чтения логов из файла?

> Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы.
> Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются.
> Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут.
>
> Регулярно требуется "нестандартная" статистика, например
> "средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"
> "соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час"
> "наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..."
> "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)"
> и т.д.
> нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси.

Если Вам не достаточно тех метрик, которые Angie
умеет отдавать напрямую в Prometheus, рассматривали
ли Вы как вариант решения своей задачи улититы

https://github.com/google/mtail

https://github.com/timberio/vector

?

Referer: https://github.com/freeseacher/metrics_ru_faq


> как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо tcp как ни крути более затратен по сравнению с unixSocket.
> Или с высокой вероятностью упрусь в теже ограничения unixSocket если отказаться от tcp со всеми дальше вытекающими.
> При размещении на другом сервере решить проблему исчерпания портов для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без body их будет меньше, но все-таки довольно много.

если использовать keepalive в блоке upstream, то не упретесь,
потому что одно и то же соединение к backend`у будет повторно
использоваться для отправки на backend большого количества запросов,
и не будет такой ситуации, что на каждый запрос открывается новое
подлюкчение к backend`у, так что исчерпания портов не произойдет.
дефолтовое значение proxy_http_version 1.0 - это плоая идея, потому
что в http 1.0 коцен файла - это закрытие соедения, а оно может быть
и по причине ошибки, и nginx будет тогда отдавать битые ответы.
Если включить proxy_http_version 1.1 - такой проблемы не будет.
И заодно - можно будет использовать http keepalive
при подключении к backend`у, чтобы по одному tcp
соединению передавать большое количество запросов.

> Моя проблема "Х":
> Ограниченность в связке nginx->unixSocket->syslog
> Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х" не возникала в принципе на необходимых мне уровнях.

Ваша проблема X в том, что Вам нужна нестандартная статистика
по запросам. А оптимизировать скорость работы nginx->unixSocket->syslog
- это есть проблема Y которая к исходной Вашей проблеме X
не имеет вообще никакого отношения.

> Объективно оптимального решения практически любой проблемы не существует в природе.

Практически всегда можно найти оптимальное ли близкое к оптимальному
решение, надо просто осознавать какие критерии важны в первую очередь,
а какие являются второстепенными - и исходя из условий задачи
- всегда можно найти оптимальное или близкое к оптимальному решение
для этих условий. Поэтому, например, иногда будет более оптимальным
VPN WireGuard, а иногда - более оптимальным будет VPN OpenVPN.
Все зависит от критериев оптимальности и всех условий задачи.

> Если у вас в крсе обучения был такой предмет как "методы оптимизации" -- вы должны это понимать.
> Вспомните задачки из курса:
> На одну и ту же таблицу данных:
> Постройте оптимальный маршрут по расстоянию.
> Постройте оптимальный маршрут по времени.
> Постройте оптимальный маршрут по загрузке.
> Постройте оптимальный с учетом состояния дорог.
> И ответы везде разные, а табличка-то одна :)
> И это которые простые задачки....

И что, Вы разве тогда находили _субъективно_ оптимальные решения?
И у каждого из 30 студентов в группе было свое собственное решение,
каждой из этих задач, которое он и считал самым оптимальным?
Или же для каждой этой задачи оптимальные решения получались
одинаковыми или очень сильно похожими друг на друга?

> Эффективность с точки зрения чего?
> Мы с вами эффективность считаем по совершенно разным критериям.
> Это не хорошо и не плохо. Это просто по-разному :)
> Ваше мнение может отличаться от моего.

при одинаковых критериях эффективности - тоже будут разные решения?

> Объективно оптимального решения практически любой проблемы не
существует в природе.

То есть, у каждого будет свое собственное _субъективное_ понимание
того, какое решение является наиболее эффективным при четко заданных
критериях эффективности?

> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно решать что мне надо :)

Решайте сами, я просто хотел понять Вашу исходную задачу X,
поэтому и задавал уточняющие вопросы.

> Про оптимальность я выше упоминал.
> Оптимизировать можно по разным критериям.
> Вы исходите из одних критериев оптимальности, я из других.
> И это абсолютно нормально.

Ненормально, если при одних и тех же критериях оптимальности
и эффективности получаются совершенно различные решения
- так не может быть.

> Не стоит убеждать меня в "неправильности" моих критериев.

Проблема XY - это не про неправильность критериев.

Проблема XY - это про то, что Вы ищете решение проблемы Y,
хотя на самом деле Вам нужно решение проблемы X.

> Есть большое подозрение, что уже на текущем этапе по данному вопросу осталось лишь 2 собеседника.

я не настаиваю на продолжении диалога, если Вам этот разговор
не интересен, не полезен или доставляет какой-то дискомфорт.

On 14.02.2024 23:58, Anatoliy Melnik via nginx-ru wrote:

> 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются
> потери по сети, каждый прокси в этом плане становится
> автономно-независимой единицей.
> При высоких нагрузках -- расхождения в статистике.

Каким образом можно получить расхождения в статистике,
если на диске есть свободное место - в лог пишутся все
сообщения, потерь не может быть в этом случае.

Получить потери можно в случае использования syslog
и unix socket`ов - если читающая сторона не будет
успевать читать данные из сокета - у nginx не останется
иных варантов, кроме как дропать часть записей.

При записи логов в файлы - этот вариант исключен,
если на разделе есть достаточное количество свободного места.

Хотя бы даже одним только этим свойством запись логов в файлы
намного лучше записи логов в unix socket`ы.

Потому что, грубо говоря, при использовании unix socket`ов,
у Вас есть очень небольшой буфер в памяти и он очень быстро
может переполниться, что и приведет к потере части записей.

А при использовании лог-файлов на диске и ротации логов по
SIGUSR1 - в качестве такого "буфера" у Вас выступает все свободное
место на диске - поэтому не требуется та высокая степень синхронности,
которая необходима при использовании unix socket`ов.

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

Если же одним из критериев эффективности и оптимальности системы
сбора статистики считать полноту статистики и отсутствие потерь
- в таком случае однозначно необходимо предпочесть именно логи,
куда будет писать сам nginx напрямую и ротацию логов через SIGUSR1.

Если же потери части входных данных Вам не создают проблем,
то это у Вас какая-то не совсем понятная статистика получается.
Зачем она нужна, если эти система очень легко может терять часть
записей?

> 3. Хорошо, запишем в файл прям с nginx-а. файл распарсим-посчитаем.
> 3а.простыми методами (типа grep и awk) обработка статистики за 30
секунд занимает больше 30 секунд.

а если через

https://github.com/google/mtail

https://github.com/timberio/vector.

?

Ведь не Вы же первый сталкиваетесь с задачей обработки логов.
И кроме grep и awk придумано и создано большое количество
инструментов для этого.

> 3б.пишем в файл->читаем из файла->удаляем файл в объемах
30-60Мбайт/сек... лично мое мнение - файл тут явно лишний.
(Ваше мнение может отличатся от моего, я абсолютно не настаиваю).

Вас не смущает тот факт, что буфер в памяти может очень легко и быстро
переполниться и это приведет к потере части данных? Это не важно?
Но судя по тому, что именно с этой проблемой Вы сюда и пришли -
для Вас это важно и критично, чтобы потерь данных у Вас не было.

Если это критично, чтобы не было потерь - тогда логично построить
систему которая в принципе не способна терять данные, если только
есть достаточное количество свободного места на диске. Разве не так?

>>> Чисто техничски можно и без access-логов, будете сами
>> реализовывать нечто
>>> подобное -- выберете более близкое вам решение.
>>
>> Вы не назвали альтернативные решения.
> Это сделали за меня:
> Написать свой бекэнд (как вариант на Go) и отзеркалировать туда
запросы с фронотов....

не только, еще можно использовать Angie и экспортировать
статистику напрямую в Prometheus, если этого будет достаточно.

> Из лабиринтов собственных заблуждений
> скорее выберется тот, кто готов признать, что он заблуждается.

А он признает?

> Лично я этот путь приодолел не единожды. Чего и вам желаю.

Спасибо. В чем мои заблуждения?

> Разве я кого-то пытался убедить, что его подход в корне не верен, как
в этом пытаются убедить меня?

Если цель кого-то пытаться убедить в истинности своей
точки зрения - это полемика. Если цель найти наиболее оптимальное
решение проблемы/задачи - это дискуссия. Отличие только в целях
и мотивации, внешнему наблюдателю они могут быть не видны и не понятны,
если он воспринимает других через призму своего собственного сознания
и своих собственных установок/предубеждений.

> Я же свои задачи решаю, а не ваши.

Задачи очень схожие часто. И можно поделиться своим опытом с другими.
Но чтобы был возможен процесс поиска наиболее оптимального решения
задачи - необходимо знать условия задачи и критерии
оптимизации / эффективности.

Причем, поиска решения настоящей задачи X о сборе статистики,
а не придуманной задачи Y про оптимизацию syslog/unix socket.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru