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

Вт Фев 13 09:38:13 UTC 2024

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 !!! 

Вот даже не знаю зачем тут все это излагаю... 
Уже непререкаемая уверенность в собственной непогрешимости в некоторых постах должна была меня насторожить. 
А уж выводы типа: 
> И если кто-то начинает ради самоутверждения распространять ложную 
> информацию про 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 | https://mailman.nginx.org/mailman/listinfo/nginx-ru ] 

Best regards..... 
to be continued ??? 

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