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
