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