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
