Re: Тест nginx -- сколько сообщений в log syslog без потерь?

Ср Фев 14 21:58:08 UTC 2024

Evgeniy Berdnikov Wrote: 
------------------------------------------------------- 
> On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru 
> wrote: 
> > Все как раз получилось, дальше с этим работать было неудобно. 
> > К тупой записи в файл претензий не было. 
> 
> Вы не сообщили, почему "дальше с этим работать было неудобно". 
> Может, поясните? Если посмотреть на озвученный список задач -- 
> 
> > Зачем мне это нужно: 
> [...] 
> > Регулярно требуется "нестандартная" статистика, например 
> > "средний размер ($body_bytes_sent) по запросам типа "sc012" за 
> сутки" 
> > "соотношение обращений по http и https ($schema) по запросам типа 
> "q1wr" 
> > за час" 
> > "наименьшее/среднее/наибольшее время ($request_time) по запросам 
> типа 
> > "sc012" за..." 
> > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких 
> запросов) в 
> > общем объеме трафика (сумма $body_bytes_sent всех запросов)" 
> > и т.д. 
> 
> то вроде трудно придумать что-то проще и эффективней, чем прост 
> парсинг 
> логов. А лог что из файла, что из пайпа, что из сокета читается 
> абсолютно одинаково, одним и тем же read(), и парсится одинаково. 
> 
> Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут 
> вообще 
> какие-то unix-сокеты, если задача в разборе последовательно идущих 
> строк 
> и каких-то элементарных вычислениях? 

1. первоначально логи сливались по сети и централизованно считались.(без записи в файлы) 
при высоких нагрузках пошли расхождения. 
2. Хорошо -- пусть каждый прокси сам свое считает: исключаются потери по сети, каждый прокси в этом плане становится автономно-независимой единицей. 
При высоких нагрузках -- расхождения в статистике. 
3. Хорошо, запишем в файл прям с nginx-а. файл распарсим-посчитаем. 
3а.простыми методами (типа grep и awk) обработка статистики за 30 секунд занимает больше 30 секунд. 
3б.пишем в файл->читаем из файла->удаляем файл в объемах 30-60Мбайт/сек... лично мое мнение - файл тут явно лишний. (Ваше мнение может отличатся от моего, я абсолютно не настаиваю). 

> 
> > Чисто техничски можно и без access-логов, будете сами 
> реализовывать нечто 
> > подобное -- выберете более близкое вам решение. 
> 
> Вы не назвали альтернативные решения. 
Это сделали за меня: 
Написать свой бекэнд (как вариант на Go) и отзеркалировать туда запросы с фронотов.... 
Не имею ничего против -- реализовуйте! Я не настаиваю на своем варианте. 
Не продвигаю как единственно правильный (или у вас иное мнение?) 

> 
> > Мой вариант также страдает набором недостатков, но поставленные 
> задачи 
> > решает с устраивающей меня эффективностью. 
> 
> Вы не конкретизировали, какие недостатки видите у своего варианта и 
> почему его плюсы по сравнению с другими подходами перевешивают. 
Ну почему же? 
Недостатки: 
Скорее всего более высокая нагрузка на CPU по сравнению с альтернативой (замеров и испытаний никто не проводил, это чисто теоретический вывод) 
Предположительно масштабируемость моего решения хуже по сравнению с предложенной альтернативой (чисто теоретический вывод) 
Т.к. я не программист -- само качество решения в плане программного кода далеко от идеала. 
Жесткое неприятие выбранного мной подхода со стороны некоторых участников обсуждения (почему-- для меня до сих пор загадка). 
Плюсы: 
При передаче всего этого хозяйства дальше на обслуживание в моем варианте разберется любой начинающий питонист, в предложенной схеме с зеркалированием квалификация нужна будет повыше мне кажется. 
Запаса по вычислительной мощности более чем достаточно. 
На существующих мощностях практически гарантированный порог 720тыс/сек. прогнозируемый, (исходя из показателей работы системы на 240тыс/сек на одном сервере) -- порядка 1.1-1.2 млн./сек. 
Что в 3 (проверенный) и 5 (прогноз) раз превышает имеющийся на данный момент уровень. 
Чего хватает на 4-5 лет при росте нагрузки на 22-24% ежегодно. (имеющийся на данный момент прогноз оптимистичный оценивается максимум в 14-16% в год) 
Затраты времени на реализацию значительно меньше, чем вариант со своим бекэндом. 

> 
> > Свой вариант я могу абсолютно спокойно масштабировать до 
> необходимых мне 
> > значений, и эти значения почти на порядок выше текущих нагрузок. 
> 
> Вы крутейший специалист :)) в своих собственных глазах, конечно. 
Из лабиринтов собственных заблуждений скорее выберется тот, кто готов признать, что он заблуждается. 
Лично я этот путь приодолел не единожды. Чего и вам желаю. 
> 
> > Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов. 
> > И "непродуктивность пути" определяете в данной конкретной 
> ситуации не вы. 
> > И конечную реализацию делаете не вы. 
> > И за результаты отвечаете не вы. 
> > Как и ответственность за все выполненное в итоге так же не на 
> вас. 
> 
> И что, это лишает собеседника право высказать своё мнение о 
> правильности 
> постановки задачи? 
Откуда такие выводы? 
Собеседник не единожды высказал свое мнение и даже больше. 
Придумал у меня проблему, которой нет. Привел для нее решение... нет смысла пересказывать -- все есть в ветке. 

Я его принял к сведению, но разве я обязан после этого изменить свое собственное? 
Разве я кого-то пытался убедить, что его подход в корне не верен, как в этом пытаются убедить меня? 

Если я начну вас убеждать в неправильности вашего выбора... ну пусть книг, которые вы читаете -- это ОБЯЗАТЕЛЬНО должно как-то кардинально повлиять на ваши вкусы? 
Возможно вы полистаете что-то из рекомендованного, может понравится.. А если нет? 

> Вы также не сообщили, каковы критерии 
> "продуктивности 
> пути", почему выбрана конретная реализация и т.д. Поэтому нет никаких 
> оснований даже подозревать, что Вы что-то делаете правильно... :) 
> 
Ну нет оснований - и нет, не подозревайте. 
Кто судит о правильности или не правильности? 
Вы для себя сами решаете что правильно, а что нет. Я поступаю аналогичным образом... В чем я не прав? 
Лишь в том, что выбрал подход, который вы считаете неправильным? И что? Ваше мнение я выслушал, принял к сведению и остался при своем. 

Критерии продуктивности: 
У меня все выполняет ту функцию, которую я и хотел, в нужных мне объемах и с устраивающим меня запасом прочности -- для меня вполне критерий. 
Ваше мнение может отличаться от моего. Может очень сильно отличаться. Может вообще не иметь с моим мнением ничего общего... и что? для вас это повод для... чего? 
Я же свои задачи решаю, а не ваши. 
Когда и если я буду решать задачи по вашим ТЗ и постановкам -- буду реализовывать ваши подходы-мнения-рекомендации 
в полном объеме вне зависимости от своего собственного мнения о правильности или не правильности выбранного вами подхода. 

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

Предложение с написанием собственного бекэнда по пунктам "ресурс" и "имеющееся в наличии" проигрывало. в моем случае. 
Ваше мнение может отличаться от моего :) 

У вас критерии кардинально отличаются? 
Вы оную считаете по какой-то отдельной формуле? 

> 
> > Оптимизировать можно по разным критериям. 
> > Вы исходите из одних критериев оптимальности, я из других. 
> > И это абсолютно нормально. 
> > Не стоит убеждать меня в "неправильности" моих критериев. 
> 
> Ненормально то, что один собеседник пытается аргументировать свои 
> мысли, 
> а другой всё время отвечает "Не учите меня жить! У меня другая 
> ситуация!" 
> А какая именно -- не говорит. 
С моей колокольни это выглядело несколько иначе. 
Лично я там обнаружил, что у меня проблемы которых у меня на самом деле нет. 
Что я решаю не те проблемы, которые должен. 
Что я возвожу напраслину на nginx и чуть ли не на все комьюнити... ну и далее по тексту. 
Хотя я с самого начала сказал, что свои вопросы я решил. 
Или я опять не прав -- самонадеян -- заблуждаюсь -- ....?? 

> -- 
> Eugene Berdnikov 
> _______________________________________________ 
> nginx-ru mailing list 
> nginx-ru на nginx.org 
> https://mailman.nginx.org/mailman/listinfo/nginx-ru 

----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240215/6f6ac107/attachment-0001.htm>