<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div data-marker="__QUOTED_TEXT__"><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><blockquote></blockquote>Gena Makhomed Wrote:<br>-------------------------------------------------------<br>> On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote:<br>> <br>> >>> Если вы предлагаете писать напрямую с nginx-а в файл --<br>> >>> сделайте у себя ротацию файлов с интервалом 30 сек<br>> >>> при 200-250 тыс подключений/сек...<br>> >>><br>> >>> Если у вас уже есть такое рабочее решение -<br>> >>> поделитесь опытом, буду рад вас выслушать.<br>> <br>> >> В этом сообщении Вы говорите о том, что Вы пробовали писать логи<br>> >> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд,<br>> >> при при 200-250 тыс подключений/сек, и у Вас не получилось<br>> >> создать "рабочее решение".<br>> <br>> > Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО!<br>> > Я сказал ровно то, что и хотел сказать.<br>> > Где вы прочитали про "не получилось" ???<br>> > Пожалуйста процитируйте... без своих домыслов и фантазий.<br>> <br>> А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню:<br>> https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKI<br>> HBFWHHTQRKDQY53XGE5BN.html<br>> <br>> Я же практически прямым текстом Вам написал, что Ваша попытка<br>> выжать максимум производительности из связки nginx-syslog -<br>> это есть проблема Y и задал Вам вопрос, какую именно проблему X<br>> Вы таким способом пытаетесь решить. И что я слышу в ответ -<br>> что Вы не смогли получить работающую систему при 200-250 тысяч<br>> подключений в секунду и при ротации логов раз в 30 секунд - именно<br>> это и значают Ваши слова "Если у вас уже есть такое рабочее решение<br>> - поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете,<br>> как именно построить рабочую систему ротации логов при такой<br>> нагрузке,<br>> то логично предположить, что Вы попытались это сделать, у Вас это<br>> не получилось и Вы тогда пошли другим путем - писать логи<br>> через syslog unix socket`ы, потому что там ротации не надо делать.<br>> <br><br>Сойдемся на формулировке:<br>"Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон."<br>Если таковая вас устроит.<br><br>Дальнейшее перемалывание темы ротации лично для меня интереса не представляет.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Т.к. концептуально является переливанием из пустого в порожнее.<br>> <br>> Читать из unix socket`а удобно, паралельно в 10 потоков,<br>> а читать из одного текстового лог-файла - неудобно?<br>> А в чем именно неудобство чтения логов из файла?<br>> <br>> > Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются<br>> запросы.<br>> > Обращения жестко делятся на несколько типов, тип определяется<br>> значением переменной в запросе, запросы БЕЗ этой переменной<br>> игнорируются.<br>> > Беки ведут статистику сколько и какого типа запросов они получили,<br>> эти данные сливаются в БД и хранятся с дискретностью 20минут.<br>> > <br>> > Регулярно требуется "нестандартная" статистика, например<br>> > "средний размер ($body_bytes_sent) по запросам типа "sc012" за<br>> сутки"<br>> > "соотношение обращений по http и https ($schema) по запросам типа<br>> "q1wr" за час"<br>> > "наименьшее/среднее/наибольшее время ($request_time) по запросам<br>> типа "sc012" за..."<br>> > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов)<br>> в общем объеме трафика (сумма $body_bytes_sent всех запросов)"<br>> > и т.д.<br>> > нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в<br>> логах реверс-прокси.<br>> <br>> Если Вам не достаточно тех метрик, которые Angie<br>> умеет отдавать напрямую в Prometheus, рассматривали<br>> ли Вы как вариант решения своей задачи улититы<br>> <br>> https://github.com/google/mtail<br>> <br>> https://github.com/timberio/vector<br>> <br>> ?<br>Нет, не рассматривал.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">На данном этапе не интересно и не вижу необходимости ломать имеющееся.<br><br>> <br>> Referer: https://github.com/freeseacher/metrics_ru_faq<br>> <br>> <br>> > как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо<br>> tcp как ни крути более затратен по сравнению с unixSocket.<br>> > Или с высокой вероятностью упрусь в теже ограничения unixSocket если<br>> отказаться от tcp со всеми дальше вытекающими.<br>> > При размещении на другом сервере решить проблему исчерпания портов<br>> для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без<br>> body их будет меньше, но все-таки довольно много.<br>> <br>> если использовать keepalive в блоке upstream, то не упретесь,<br>> потому что одно и то же соединение к backend`у будет повторно<br>> использоваться для отправки на backend большого количества запросов,<br>> и не будет такой ситуации, что на каждый запрос открывается новое<br>> подлюкчение к backend`у, так что исчерпания портов не произойдет.<br>> дефолтовое значение proxy_http_version 1.0 - это плоая идея, потому<br>> что в http 1.0 коцен файла - это закрытие соедения, а оно может быть<br>> и по причине ошибки, и nginx будет тогда отдавать битые ответы.<br>> Если включить proxy_http_version 1.1 - такой проблемы не будет.<br>> И заодно - можно будет использовать http keepalive<br>> при подключении к backend`у, чтобы по одному tcp<br>> соединению передавать большое количество запросов.<br>> <br>> > Моя проблема "Х":<br>> > Ограниченность в связке nginx->unixSocket->syslog<br>> > Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х"<br>> не возникала в принципе на необходимых мне уровнях.<br>> <br>Все. Точка. <br>При износе какой-то запчасти в механизме чаще меняют запчасть, а не механизм.<br>Я свой случай отношу именно к категории про запчасть.<br>Вы предлагаете замену всего при весьма не очевидных плюсах в результате.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Зачем мне менять рабочее, устраивающее меня решение на другое, которое в любом случае придется допиливать и отлаживать, подгонять под свои цели?</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Чтоб было лучше? Лучше кому? И лучше в чем? <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Что такого я получу в результате, чего у меня нет сейчас?<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Полученное решение эффективно расходует мое рабочее время, занимая ровно "0" секунд в день на его обслуживание.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"> оптимально устраивает начальство на предмет отображения полученных данных.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Создает равномерную нагрузку на cpu. Без ярко выраженных всплесков, которые будут при обработке файла с накопленными данными.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">И даже сокращает "углеродный след" не насилуя попусту жесткие диски операциями чтения-записи :)<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Вам не подходит?<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Не пользуйтесь подобными конструкциями. <br><br>> <br>> > Объективно оптимального решения практически любой проблемы не<br>> существует в природе.<br>> <br>> Практически всегда можно найти оптимальное ли близкое к оптимальному<br>> решение, надо просто осознавать какие критерии важны в первую<br>> очередь,<br>> а какие являются второстепенными - и исходя из условий задачи<br>> - всегда можно найти оптимальное или близкое к оптимальному решение<br>> для этих условий. Поэтому, например, иногда будет более оптимальным<br>> VPN WireGuard, а иногда - более оптимальным будет VPN OpenVPN.<br>> Все зависит от критериев оптимальности и всех условий задачи.<br>> <br>> > Если у вас в крсе обучения был такой предмет как "методы<br>> оптимизации" -- вы должны это понимать.<br>> > Вспомните задачки из курса:<br>> > На одну и ту же таблицу данных:<br>> > Постройте оптимальный маршрут по расстоянию.<br>> > Постройте оптимальный маршрут по времени.<br>> > Постройте оптимальный маршрут по загрузке.<br>> > Постройте оптимальный с учетом состояния дорог.<br>> > И ответы везде разные, а табличка-то одна :)<br>> > И это которые простые задачки....<br>> <br>> И что, Вы разве тогда находили _субъективно_ оптимальные решения?<br>> И у каждого из 30 студентов в группе было свое собственное решение,<br>> каждой из этих задач, которое он и считал самым оптимальным?<br>> Или же для каждой этой задачи оптимальные решения получались<br>> одинаковыми или очень сильно похожими друг на друга?<br>> <br>Решение было свое собственное, (ну не совсем у каждого, а по вариантам) потому что критерий оптимальности был у каждого свой, "данный свыше".<br>В обычной жизни критерии могут быть очень похожи, но это таки субъективные критерии.<br><br>> > Эффективность с точки зрения чего?<br>> > Мы с вами эффективность считаем по совершенно разным критериям.<br>> > Это не хорошо и не плохо. Это просто по-разному :)<br>> > Ваше мнение может отличаться от моего.<br>> <br>> при одинаковых критериях эффективности - тоже будут разные решения?<br>> <br>> > Объективно оптимального решения практически любой проблемы не <br>> существует в природе.<br>> <br>> То есть, у каждого будет свое собственное _субъективное_ понимание<br>> того, какое решение является наиболее эффективным при четко заданных<br>> критериях эффективности?<br>ДА!<br>ДА!<br>На оба ваших вопроса выше...<br>Оглянитесь вокруг, и вы сами в этом убедитесь.<br>Кровли одинаковой конструкции очень похожих домов покрыты разным материалом.<br>Внешне одинаковые постройки с одинаковой теплоэффективностью в качестве теплоизолятора содержат разные материалы.<br>По дорогам ездят разные автомобили с одинаковыми требованиями к эффективности.<br>Люди носят разную одежду при одинаковых требованиях к эффективности.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br>Список можно продолжать до бесконечности.<br>Можно придраться к каждому пункту по принципу "... а тут они не все критерии!"<br>Так в жизни практически не бывает "чтоб прям все":) По крайней мере в моей.<br><br><br>> <br>> > Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно<br>> решать что мне надо :)<br>> <br>> Решайте сами, я просто хотел понять Вашу исходную задачу X,<br>> поэтому и задавал уточняющие вопросы.<br>><br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте теме я уже все решил.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"> <br>> > Про оптимальность я выше упоминал.<br>> > Оптимизировать можно по разным критериям.<br>> > Вы исходите из одних критериев оптимальности, я из других.<br>> > И это абсолютно нормально.<br>> <br>> Ненормально, если при одних и тех же критериях оптимальности<br>> и эффективности получаются совершенно различные решения<br>> - так не может быть.<br><br>Может.<br>У Пикуля есть произведение "Честь Имею".<br>Там есть эпизод с описанием различия принципов обучения в российской и немецкой академиях генштаба.<br>Так вот - в немецкой идеалом считалось, когда любой выпускник, поставленный в сложную ситуацию, принимал оптимальное эффективное ЕДИНСТВЕННО ВЕРНОЕ решение, одинаковое для всех успешных выпускников в такой ситуации.<br>Коренное отличие русской состояло в том, что каждый выпускник принимал оптимальное эффективное решение для достижения цели, и идеалом считалось когда у подавляющего большинства решения разные, но очень близки по эффективности.<br>Если мне память не изменяет -- давно читал.<br>Может что и напутал или помню не правильно...<br><br>Кроме того при одинаковых критериях исходные условия могут быть разными.<br>И решения будут КАРДИНАЛЬНО отличаться.<br>Вот при одинаковых условиях, критериях, ресурсах, предпочтениях и конечных требованиях уже можно ожидать низкой вариативности в реализации. И то не факт.<br><br>> <br>> > Не стоит убеждать меня в "неправильности" моих критериев.<br>> <br>> Проблема XY - это не про неправильность критериев.<br>> <br>> Проблема XY - это про то, что Вы ищете решение проблемы Y,<br>> хотя на самом деле Вам нужно решение проблемы X.<br>Любая проблема является следствием одних проблем, и причиной других.<br>Это нормально.<br>При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не едет" 2 концептуальных решения:<br>1.Заменить машину.<br>2.Устранить причины "не едет" в имеющейся.<br>Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя запчасть.<br>Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти.<br>Вы предлагаете замену машины.<br>Да, тут тоже есть куда развить тему, к чему придраться и т.д.<br>Аналогия может не самая удачная. Можете привести свою.<br><br>> <br>> > Есть большое подозрение, что уже на текущем этапе по данному вопросу<br>> осталось лишь 2 собеседника.<br>> <br>> я не настаиваю на продолжении диалога, если Вам этот разговор<br>> не интересен, не полезен или доставляет какой-то дискомфорт.<br>> <br>> On 14.02.2024 23:58, Anatoliy Melnik via nginx-ru wrote:<br>> <br>> > 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются<br>> > потери по сети, каждый прокси в этом плане становится<br>> > автономно-независимой единицей.<br>> > При высоких нагрузках -- расхождения в статистике.<br>> <br>> Каким образом можно получить расхождения в статистике,<br>> если на диске есть свободное место - в лог пишутся все<br>> сообщения, потерь не может быть в этом случае.<br>> <br>Файлы в следующем пункте.<br>> Получить потери можно в случае использования syslog<br>> и unix socket`ов - если читающая сторона не будет<br>> успевать читать данные из сокета - у nginx не останется<br>> иных варантов, кроме как дропать часть записей.<br>> <br>> При записи логов в файлы - этот вариант исключен,<br>> если на разделе есть достаточное количество свободного места.<br>> <br>О появились доп. условия -- место на разделе...<br><br><br>> Хотя бы даже одним только этим свойством запись логов в файлы<br>> намного лучше записи логов в unix socket`ы.<br>> <br>А как же место на разделе? Замена одной проблемы другой. Только и всего.<br>Т.е. Проблему X -- расхождение при использовании сокета, вы меняете на проблему У -- достаточное количество места и производительность системы ввода-вывода, просто с вашей точки зрения это как-бы и не проблема вовсе, с моей точки зрения менять одну проблему на другую смысла нет, если можно решить первую. Тем более решение оказалось сущим пустяком.<br><br><br><br>> Потому что, грубо говоря, при использовании unix socket`ов,<br>> у Вас есть очень небольшой буфер в памяти и он очень быстро<br>> может переполниться, что и приведет к потере части записей.<br>Что и было решено путем распараллеливания.<br><br>> <br>> А при использовании лог-файлов на диске и ротации логов по<br>> SIGUSR1 - в качестве такого "буфера" у Вас выступает все свободное<br>> место на диске - поэтому не требуется та высокая степень<br>> синхронности,<br>> которая необходима при использовании unix socket`ов.<br>> <br>> Какой смысл в статистике, если она будет не точкной и ошибочной,<br>> если система сбора статистики будет очень хрупкой и будет терять<br>> часть сообщений при всплесках пиковой нагрузки на сервис?<br>На данном этапе эксплуатации не выявлено ни одного из перечисленных вами эффектов.<br><br><br>> <br>> Если же одним из критериев эффективности и оптимальности системы<br>> сбора статистики считать полноту статистики и отсутствие потерь<br>> - в таком случае однозначно необходимо предпочесть именно логи,<br>> куда будет писать сам nginx напрямую и ротацию логов через SIGUSR1.<br>> <br>> Если же потери части входных данных Вам не создают проблем,<br>> то это у Вас какая-то не совсем понятная статистика получается.<br>> Зачем она нужна, если эти система очень легко может терять часть<br>> записей?<br>Ну не так уж и легко.<br>Собственно время покажет.<br><br><br>> <br>> > 3. Хорошо, запишем в файл прям с nginx-а. файл<br>> распарсим-посчитаем.<br>> > 3а.простыми методами (типа grep и awk) обработка статистики за 30 <br>> секунд занимает больше 30 секунд.<br>> <br>> а если через<br>> <br>> https://github.com/google/mtail<br>> <br>> https://github.com/timberio/vector.<br>> <br>> ?<br>> <br>> Ведь не Вы же первый сталкиваетесь с задачей обработки логов.<br>> И кроме grep и awk придумано и создано большое количество<br>> инструментов для этого.<br>> <br>> > 3б.пишем в файл->читаем из файла->удаляем файл в объемах <br>> 30-60Мбайт/сек... лично мое мнение - файл тут явно лишний.<br>> (Ваше мнение может отличатся от моего, я абсолютно не настаиваю).<br>> <br>> Вас не смущает тот факт, что буфер в памяти может очень легко и<br>> быстро<br>> переполниться и это приведет к потере части данных? Это не важно?<br>> Но судя по тому, что именно с этой проблемой Вы сюда и пришли -<br>> для Вас это важно и критично, чтобы потерь данных у Вас не было.<br>> <br>> Если это критично, чтобы не было потерь - тогда логично построить<br>> систему которая в принципе не способна терять данные, если только<br>> есть достаточное количество свободного места на диске. Разве не так?<br>> <br>> >>> Чисто техничски можно и без access-логов, будете сами<br>> >> реализовывать нечто<br>> >>> подобное -- выберете более близкое вам решение.<br>> >><br>> >> Вы не назвали альтернативные решения.<br>> > Это сделали за меня:<br>> > Написать свой бекэнд (как вариант на Go) и отзеркалировать туда <br>> запросы с фронотов....<br>> <br>> не только, еще можно использовать Angie и экспортировать<br>> статистику напрямую в Prometheus, если этого будет достаточно.<br>> <br>> > Из лабиринтов собственных заблуждений<br>> > скорее выберется тот, кто готов признать, что он заблуждается.<br>> <br>> А он признает?<br>А вы у кого спрашиваете?<br>> <br>> > Лично я этот путь приодолел не единожды. Чего и вам желаю.<br>> <br>> Спасибо. В чем мои заблуждения?<br>Ну как вариант:<br>"Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон."<br>Чуть попозже может всплыть и еще что-то.<br>> <br>> > Разве я кого-то пытался убедить, что его подход в корне не верен,<br>> как <br>> в этом пытаются убедить меня?<br>> <br>> Если цель кого-то пытаться убедить в истинности своей<br>> точки зрения - это полемика. Если цель найти наиболее оптимальное<br>> решение проблемы/задачи - это дискуссия. Отличие только в целях<br>> и мотивации, внешнему наблюдателю они могут быть не видны и не<br>> понятны,<br>> если он воспринимает других через призму своего собственного сознания<br>> и своих собственных установок/предубеждений.<br>Не так много встречал людей, способных к адекватному восприятию не только через призму своего собственного сознания, но также и чужого.<br><br>> <br>> > Я же свои задачи решаю, а не ваши.<br>> <br>> Задачи очень схожие часто. И можно поделиться своим опытом с другими.<br>> Но чтобы был возможен процесс поиска наиболее оптимального решения<br>> задачи - необходимо знать условия задачи и критерии<br>> оптимизации / эффективности.<br>> <br>> Причем, поиска решения настоящей задачи X о сборе статистики,<br>> а не придуманной задачи Y про оптимизацию syslog/unix socket.<br>Лично для меня уже не актуальны ни Х ни Y, ни их комбинации.<br><br><br>Вот вам идея оптимального по большинству критериев решения --<br>Когда будете решать сходную задачу напишите свой модуль для nginx<br>Чтоб сразу считать все нужное "внутри" без посредников.<br>Я такое решение тоже рассматривал, отказался.<br>Лично мои трудозатраты по реализации такого подхода превосходят все разумные пределы.<br>Что и стало ключевым фактором "против".<br><br>> -- <br>> Best regards,<br>> Gena<br>> <br>> _______________________________________________<br>> nginx-ru mailing list<br>> nginx-ru@nginx.org<br>> https://mailman.nginx.org/mailman/listinfo/nginx-ru<br><br><br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></body></html>