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

Вт Фев 13 11:07:24 UTC 2024

вт, 13 февр. 2024 г. в 10:38, Anatoliy Melnik via nginx-ru <
nginx-ru на nginx.org>:

> Gena Makhomed Wrote:
> -------------------------------------------------------
> > On 12.02.2024 12:30, Anatoliy Melnik via nginx-ru wrote:
> >
> > > Из его собщения от 5 февраля однозначно следует, что он
> > > уже пытался настроить запись логов напрямую в файл но не смог
> > > получить рабочего решения при 200-250 тысячах подключений в секунду
> > > и необходимости делать ротацию лога каждые 30 секунд. И даже
> > предлагает
> > > мне самому попробовать и убедиться, что это не работает и что таким
> > > образом запись и ротацию логов в файл самим nginx при такой большой
> > > нагрузке и при таком интервале ротации - настроить невозможно,
> >
> > > Я предлагал попробовать и поделиться, лично я попробовал, получил
> > результат -- пишет, работает, возможно. И сделал это ДО того, как сюда
> > обратился...
> > > НО меня сей результат не удовлетворил.
> >
> > Так и расскажите, почему не удовлетворил, поделитесь опытом
> > с участниками и читателями этого списка рассылки. Тем более,
> > что здесь присутствуют и разрабочики nginx, так что если проблема
> > в коде nginx действителько существует - эту проблему в коде исправят.
> >
> > Насколько мне известно, переоткрытие лог-файлов по сигналу USR1
> > происходит практически мгновенно и не требует перезапуска
> > рабочих процессов nginx, поэтому - не может приводить ни к каким
> > проблемам на любом количестве соединений при ротации лог-файлов
> > nginx раз в 30 секунд.
> >
> > Тем более, что директива access_log позволяет настроить
> > процесс записи логов наиболее оптимальным способом, ключив
> > буферизацию, и при необходимости - компрессию логов на лету.
> >
> > access_log path [buffer=size] [gzip[=level] [flush=time]
> >
> > Поэтому - я просто не понимаю, какие у Вас могли там возникнуть
> > проблемы, если делать ротацию логов nginx раз в 30 секунд на любом
> > количестве подключений - от количества подключений это вообще никак
> > не зависит, потому что новые рабочие процессы nginx при этом
> > не создаются и страрые рабочие процессы nginx не завершаются.
> >
> > кстати, и logrotate делает ротацию логов nginx таким же способом:
> >
> > # cat /etc/logrotate.d/nginx
> >
> > if [ -f /var/run/nginx.pid ]; then
> >          kill -USR1 `cat /var/run/nginx.pid`
> > fi
> >
> >
>
> Для меня логи не цель, а средство.
> Источник для необходимых статистических данных.
> Чем не удовлетворил результат - смотрите чуть дальше.
>
> > > Да, да (понимаю) -- чем он меня "не удовлетворил"??
> > > --- можете фантазировать сколько угодно.
> >
> > Могу, но не хочу. Поэтому и прошу Вас чтобы Вы сами рассказали всем
> > здесь присутствующим о том, какие проблемы Вы обнаружили при ротации
> > логов с помощью сигнала USR1. Я здесь не вижу вообще никаких проблем.
> >
> > > Задача по предотвращению исчерпания места на диске так же была
> > решена задолго ДО обращения сюда.
> >
> > Поделитесь своим опытом решения этой задачи.
> > Потому что я пока что не смог найти решения.
> >
>
> Мы с вами решаем задачи при разных исходных условиях и разных конечных
> целях.
> Еще и с разными ресурсами.
> Для меня главный вопрос, на который надо дать ответ:
> ЗАЧЕМ я пишу логи? ЧТО я дальше с ними буду делать?
>
>
> > > Возникает впечатление, что кому-то из вас принципиально важно
> > доказать незыблемую правоту своего мнения и ошибочность моих
> > действий.
> > > Вопрос - зачем?
> >
> > Я уже отвечал на этот Ваш вопрос.
> >
> > Этот список рассылки - он посвящен nginx, а не процессу
> > самоутверждения.
> > И если кто-то начинает ради самоутверждения распространять ложную
> > информацию про nginx, например, что nginx не способен самостоятельно
> > писать логи в файлы при количестве подключений 200-250 тысяч в
> > секунду
> > и ротации лог-файлов раз в 30 секунду и что решением этой проблемы
> > является набор костылей в виде syslog, unix socket, и десяти
> > одновременно запущеных копий скрипта на Python - то это FUD
> > и это вредит не только конкретно тому человеку, который это
> > делает, но и всему nginx community, то есть всем участниками
> > и читателям списка рассылки, потому что часть неопытных пользователей
> > nginx может в этот FUD поверить и считать эту Вашу информацию
> > истинной.
> >
> > FUD - это
> > https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
> > https://ru.wikipedia.org/wiki/FUD
> >
> > > Это не конкурс или состязание, я сюда обратился за советом.
> >
> > Так я тоже обратился к Вам за советом - пожалуйста, поделитесь
> > опытом,
> > и расскажите, какие проблемы Вы обнаружили при ротации логов nginx
> > с помощью сигнала USR1 что были вынуждены отказаться от этого
> > варианта
> > работы и логами и были вынуждены в результате соорудить то,
> > что Вы назвали решением этой проблемы - в виде syslog, unix socket и
> > скрипта на Python запускемого в 10 экземплярах и пишущего логи в 10
> > отдельных файлов.
> >
> > Решением какой именно _проблемы_ является эта конструкция,
> > которую Вы называете в своих сообщениях решением проблемы?
> >
> > > Какая разница насколько глубокое ущелье на моем пути, если я уже
> > построил через него мост?
> > > Может он не самый красивый, вечный, грузоподъемный и уникальный...
> > > Для моих целей его достаточно :)
> > > Возможно, по мнению кого-то, я вообще иду "не туда"!
> >
> > Дело тут не только и не столько в https://xkcd.ru/386/
> > потому что идя не туда, Вы еще этот способ идти не туда
> > и рекламируете как _решение проблемы_, чем делаете FUD,
> > хотя лично Вам этот веб-сервер ничего плохого не сделал.
> >
> > > И? Вы свои аргументы привели, мое мнение они не изменили...
> > > Или для некоторых "есть только два мнения: моё и неправильное"?
> >
> > Поделитесь своим опытом, расскажите, почему эта конструкция
> > из syslog, unix socket и десяти скриптов на python, пишущих
> > сообщения в десять лог-файлов оказалась для Вас лучше,
> > чем встроенные в nginx возможности для записи и ротации логов?
> >
> Повторюсь:
> Логи - не цель, а всего лишь средство.
>
> Скрипт один, с модулем multiprocessing, так что экземпляров получается 11,
> но это не важно.
> Запись в файлы были лишь эпизодом для выяснения ограничений связки
> nginx->(unixSocket)->syslog
> Сейчас я вообще не пишу эти файлы, но при необходимости могу это начать
> делать так же на лету, не дергая ни nginx, ни сам сервис "типа персональный
> nginx-овый сислог".
>
> Все данные извлекаются в скрипте "на лету" и отображаются в
> соответствующих счетчиках.
>
> При необходимости сосчитать что-то другое/новое или по другом алгоритму -
> я всего лишь изменю несколько строк скрипта.
> На данном этапе проверенная производительность одной системы 240тыс/сек,
> прогноз исходя из статистики нагрузки - 400-420.
>
> Запись горы сообщений напрямую в файл из nginx-а работает, файлы
> ротируются, но мне это никак не помогает в решении поставленной задачи.
> Поэтому и "не удовлетворил".
>
> Собственно как следствие -- отсутствие проблемы доступного дискового
> пространства. Нагрузка на дисковую подсистему близка к нулю.
>
> И я с самого начала не говорил, что мне нужны файлы! Меня интересовала
> связка nginx->(unixSocket)->syslog.
> Именно эту проблему я и озвучил.
>
> Можно сослаться на мои посты:
> "Сами файлы логов живут максимум 15-20 минут, этого достаточно для
> извлечения необходимых данных."
> "Производительности хранилища точно достаточно для 150тыс/сек (один из
> способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном
> физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений
> на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении
> нескольких часов заливка-ротация-удаление)"
> "Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на
> tmpfs в RAM. "
>
> Это были лишь промежуточные этапы, мне нужно было убедиться, что проблема
> именно на этапе nginx->(unixSocket)->syslog.
> И запись в файл на очень быстрый носитель был, наверное, самый прямой
> путь, дающий адекватные результаты.
> Свою функцию этот этап выполнил, но повторюсь - это не было целью!
> И на каждом этапе обсуждения мне казалось очевидным: мне нужна рабочая
> связка nginx->(unixSocket)->syslog !!!
>

я боюсь, сработал стереотип, который выглядит примерно так

"связка может быть рабочая или не рабочая в зависимости от, наверное,
десятка параметров настройки операционной системы" ..... "поэтому логично
для проверки сравнить количество патронов, вылетающих из точки А с
прилетающими в точку Б" .... любым доступным автору способом, например,
tcpdump (если топикстартеру удобно другое - без проблем)

и первая часть была опущена в силу предполагаемой очевидности. потому что
никто не знает конкретную комбинацию параметров, и даже, если и знает,
навряд ли сможет предложить способ вычисления, как из комбинации параметров
получить булево "да, будет работать на рейте 200к" или "нет, не будет".

все таки любопытно. вот вас интересовал вопрос "рабочей связки".
в каком виде вы ожидаете помощь от комьюнити (с учетом, что никто не
понимает, в чем именно у вас узкое место)

предположу, что эту ситуацию можно из "не работает" превратить в "работает,
если".
если найти узкое место и устранить

>
>
> Вот даже не знаю зачем тут все это излагаю...
> Уже непререкаемая уверенность в собственной непогрешимости в некоторых
> постах должна была меня насторожить.
> А уж выводы типа:
> > И если кто-то начинает ради самоутверждения распространять ложную
> > информацию про nginx, например, что nginx не способен самостоятельно
> > писать логи в файлы при количестве подключений 200-250 тысяч в
> > секунду...
>
> Буквально апогей!!!! Выршина дедукции!!! Шерлок Холмс не у вас, случайно,
> учился??
>
> Чего уж там - давайте и углеродный след приплетем (нынче это модно).
>
>
>
> > > Или я чего-то не понимаю?
> >
> > «Ничего личного, только бизнес».
> Никогда не понимал восторгов этим правилом.
> Из личного опыта -- стараюсь не иметь дел с адептами этого подхода, и это
> сугубо личное.
>
> >
> > Источник:
> > https://uchet-jkh.ru/i/nicego-licnogo-tolko-biznes-otkuda-fraza
> >
> > --
> > Best regards,
> >   Gena
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Best regards.....
> to be continued ???
> ------------------------------
>
>
> _______________________________________________
> 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/20240213/fe3ca56f/attachment-0001.htm>