Gena Makhomed Wrote:
-------------------------------------------------------
> 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/L3UKQXO2PKI
> HBFWHHTQRKDQY53XGE5BN.html
>
> Я же практически прямым текстом Вам написал, что Ваша попытка
> выжать максимум производительности из связки nginx-syslog -
> это есть проблема Y и задал Вам вопрос, какую именно проблему X
> Вы таким способом пытаетесь решить. И что я слышу в ответ -
> что Вы не смогли получить работающую систему при 200-250 тысяч
> подключений в секунду и при ротации логов раз в 30 секунд - именно
> это и значают Ваши слова "Если у вас уже есть такое рабочее решение
> - поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете,
> как именно построить рабочую систему ротации логов при такой
> нагрузке,
> то логично предположить, что Вы попытались это сделать, у Вас это
> не получилось и Вы тогда пошли другим путем - писать логи
> через syslog unix socket`ы, потому что там ротации не надо делать.
>

Сойдемся на формулировке:
"Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон."
Если таковая вас устроит.

Дальнейшее перемалывание темы ротации лично для меня интереса не представляет.
Т.к. концептуально является переливанием из пустого в порожнее.
>
> Читать из 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
> > Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х"
> не возникала в принципе на необходимых мне уровнях.
>
Все. Точка.
При износе какой-то запчасти в механизме чаще меняют запчасть, а не механизм.
Я свой случай отношу именно к категории про запчасть.
Вы предлагаете замену всего при весьма не очевидных плюсах в результате.
Зачем мне менять рабочее, устраивающее меня решение на другое, которое в любом случае придется допиливать и отлаживать, подгонять под свои цели?
Чтоб было лучше? Лучше кому? И лучше в чем?
Что такого я получу в результате, чего у меня нет сейчас?

Полученное решение эффективно расходует мое рабочее время, занимая ровно "0" секунд в день на его обслуживание.
оптимально устраивает начальство на предмет отображения полученных данных.
Создает равномерную нагрузку на cpu. Без ярко выраженных всплесков, которые будут при обработке файла с накопленными данными.

И даже сокращает "углеродный след" не насилуя попусту жесткие диски операциями чтения-записи :)


Вам не подходит?
Не пользуйтесь подобными конструкциями.

>
> > Объективно оптимального решения практически любой проблемы не
> существует в природе.
>
> Практически всегда можно найти оптимальное ли близкое к оптимальному
> решение, надо просто осознавать какие критерии важны в первую
> очередь,
> а какие являются второстепенными - и исходя из условий задачи
> - всегда можно найти оптимальное или близкое к оптимальному решение
> для этих условий. Поэтому, например, иногда будет более оптимальным
> VPN WireGuard, а иногда - более оптимальным будет VPN OpenVPN.
> Все зависит от критериев оптимальности и всех условий задачи.
>
> > Если у вас в крсе обучения был такой предмет как "методы
> оптимизации" -- вы должны это понимать.
> > Вспомните задачки из курса:
> > На одну и ту же таблицу данных:
> > Постройте оптимальный маршрут по расстоянию.
> > Постройте оптимальный маршрут по времени.
> > Постройте оптимальный маршрут по загрузке.
> > Постройте оптимальный с учетом состояния дорог.
> > И ответы везде разные, а табличка-то одна :)
> > И это которые простые задачки....
>
> И что, Вы разве тогда находили _субъективно_ оптимальные решения?
> И у каждого из 30 студентов в группе было свое собственное решение,
> каждой из этих задач, которое он и считал самым оптимальным?
> Или же для каждой этой задачи оптимальные решения получались
> одинаковыми или очень сильно похожими друг на друга?
>
Решение было свое собственное, (ну не совсем у каждого, а по вариантам) потому что критерий оптимальности был у каждого свой, "данный свыше".
В обычной жизни критерии могут быть очень похожи, но это таки субъективные критерии.

> > Эффективность с точки зрения чего?
> > Мы с вами эффективность считаем по совершенно разным критериям.
> > Это не хорошо и не плохо. Это просто по-разному :)
> > Ваше мнение может отличаться от моего.
>
> при одинаковых критериях эффективности - тоже будут разные решения?
>
> > Объективно оптимального решения практически любой проблемы не
> существует в природе.
>
> То есть, у каждого будет свое собственное _субъективное_ понимание
> того, какое решение является наиболее эффективным при четко заданных
> критериях эффективности?
ДА!
ДА!
На оба ваших вопроса выше...
Оглянитесь вокруг, и вы сами в этом убедитесь.
Кровли одинаковой конструкции очень похожих домов покрыты разным материалом.
Внешне одинаковые постройки с одинаковой теплоэффективностью в качестве теплоизолятора содержат разные материалы.
По дорогам ездят разные автомобили с одинаковыми требованиями к эффективности.
Люди носят разную одежду при одинаковых требованиях к эффективности.

Список можно продолжать до бесконечности.
Можно придраться к каждому пункту по принципу "... а тут они не все критерии!"
Так в жизни практически не бывает "чтоб прям все":) По крайней мере в моей.


>
> > Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно
> решать что мне надо :)
>
> Решайте сами, я просто хотел понять Вашу исходную задачу X,
> поэтому и задавал уточняющие вопросы.
>
Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте теме я уже все решил.

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

Может.
У Пикуля есть произведение "Честь Имею".
Там есть эпизод с описанием различия принципов обучения в российской и немецкой академиях генштаба.
Так вот - в немецкой идеалом считалось, когда любой выпускник, поставленный в сложную ситуацию, принимал оптимальное эффективное ЕДИНСТВЕННО ВЕРНОЕ решение, одинаковое для всех успешных выпускников в такой ситуации.
Коренное отличие русской состояло в том, что каждый выпускник принимал оптимальное эффективное решение для достижения цели, и идеалом считалось когда у подавляющего большинства решения разные, но очень близки по эффективности.
Если мне память не изменяет -- давно читал.
Может что и напутал или помню не правильно...

Кроме того при одинаковых критериях исходные условия могут быть разными.
И решения будут КАРДИНАЛЬНО отличаться.
Вот при одинаковых условиях, критериях, ресурсах, предпочтениях и конечных требованиях уже можно ожидать низкой вариативности в реализации. И то не факт.

>
> > Не стоит убеждать меня в "неправильности" моих критериев..
>
> Проблема XY - это не про неправильность критериев.
>
> Проблема XY - это про то, что Вы ищете решение проблемы Y,
> хотя на самом деле Вам нужно решение проблемы X.
Любая проблема является следствием одних проблем, и причиной других.
Это нормально..
При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не едет" 2 концептуальных решения:
1.Заменить машину.
2.Устранить причины "не едет" в имеющейся.
Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя запчасть.
Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти.
Вы предлагаете замену машины.
Да, тут тоже есть куда развить тему, к чему придраться и т.д.
Аналогия может не самая удачная. Можете привести свою.

>
> > Есть большое подозрение, что уже на текущем этапе по данному вопросу
> осталось лишь 2 собеседника.
>
> я не настаиваю на продолжении диалога, если Вам этот разговор
> не интересен, не полезен или доставляет какой-то дискомфорт.
>
> On 14.02.2024 23:58, Anatoliy Melnik via nginx-ru wrote:
>
> > 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются
> > потери по сети, каждый прокси в этом плане становится
> > автономно-независимой единицей.
> > При высоких нагрузках -- расхождения в статистике.
>
> Каким образом можно получить расхождения в статистике,
> если на диске есть свободное место - в лог пишутся все
> сообщения, потерь не может быть в этом случае.
>
Файлы в следующем пункте.
> Получить потери можно в случае использования syslog
> и unix socket`ов - если читающая сторона не будет
> успевать читать данные из сокета - у nginx не останется
> иных варантов, кроме как дропать часть записей.
>
> При записи логов в файлы - этот вариант исключен,
> если на разделе есть достаточное количество свободного места.
>
О появились доп. условия -- место на разделе...


> Хотя бы даже одним только этим свойством запись логов в файлы
> намного лучше записи логов в unix socket`ы.
>
А как же место на разделе? Замена одной проблемы другой. Только и всего.
Т.е. Проблему X -- расхождение при использовании сокета, вы меняете на проблему У -- достаточное количество места и производительность системы ввода-вывода, просто с вашей точки зрения это как-бы и не проблема вовсе, с моей точки зрения менять одну проблему на другую смысла нет, если можно решить первую. Тем более решение оказалось сущим пустяком.



> Потому что, грубо говоря, при использовании 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.
Лично для меня уже не актуальны ни Х ни Y, ни их комбинации.


Вот вам идея оптимального по большинству критериев решения --
Когда будете решать сходную задачу напишите свой модуль для nginx
Чтоб сразу считать все нужное "внутри" без посредников.
Я такое решение тоже рассматривал, отказался.
Лично мои трудозатраты по реализации такого подхода превосходят все разумные пределы.
Что и стало ключевым фактором "против".

> --
> Best regards,
> Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru



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