Re: Тест nginx -- сколько сообщений в log syslog без потерь?
Anatoliy Melnik
anatoliy.melnik на showjet.ru
Ср Фев 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>
Подробная информация о списке рассылки nginx-ru