<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div data-marker="__QUOTED_TEXT__"><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><blockquote></blockquote>Gena Makhomed Wrote:<br>-------------------------------------------------------<br>> On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:<br>> <br>> >> какую именно проблему Вы пытаетесь решить с помощью записи логов<br>> >> в unix socket, чтения данных из unix socket`а питоновским<br>> скриптом<br>> >> и потом записи данных этим питоновским скриптом в текстовой файл?<br>> <br>> > Если вы предлагаете писать напрямую с nginx-а в файл --<br>> > сделайте у себя ротацию файлов с интервалом 30 сек<br>> > при 200-250 тыс подключений/сек...<br>> <br>> > Если у вас уже есть такое рабочее решение -<br>> > поделитесь опытом, буду рад вас выслушать.<br>> <br>> В этом сообщении Вы говорите о том, что Вы пробовали писать логи<br>> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд,<br>> при при 200-250 тыс подключений/сек, и у Вас не получилось<br>> создать "рабочее решение".<br>> </div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО!<br>Я сказал ровно то, что и хотел сказать.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Где вы прочитали про "не получилось" ???<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Пожалуйста процитируйте... без своих домыслов и фантазий. <br><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br>> И Вы просите, чтобы я поделился с Вами опытом, как построить<br>> такое рабочее решение и говорите, что будете рады меня выслушать.<br>> <br>> Если настроить ротацию логов через сигнал USR1<br>> - никаких проблем с самой ротацией не должно быть,<br>> при любом количестве подключений.<br>> <br>> Тем более, что с помощью дополнительных параметров<br>> [buffer=size] [gzip[=level]] [flush=time] директивы<br>> access_log можно настроить и буферизацию записи логов<br>> и компрессию на лету - чтобы еще больше оптимизировать<br>> использование ресурсов процессора и занимаемого логами<br>> места на диске сервера.<br>> <br>> Расскажите, пожалуйста, какие тут у Вас могли возникнуть проблемы,<br>> что не получилось построить рабочее решение,<br>> если "писать напрямую с nginx-а в файл" ?<br>> <br>> Я пока что вижу только всего одну возможную причину,<br>> почему у Вас не получилось создать такое рабочее решение<br>> - для ротации логов Вы использовали сигнал HUP а не сигнал USR1.<br>> <br>> Потому что только в случае ротации логом с помощью сигнала HUP<br>> количество подключений в секунду и интервал ротации в 30 секунд<br>> могут влиять на процесс ротации, потому что при этом происходит<br>> <br>> "changing configuration, keeping up with a changed time zone<br>> (only for FreeBSD and Linux), starting new worker processes<br>> with a new configuration, graceful shutdown of old worker processes".<br>> <br>> Если же делать ротацию логов с помощью сигнала USR1,<br>> тогда не имеет особой разницы, какое количество подключений<br>> в секунду обрабатывают рабочие процессы и и с каким интервалом<br>> происходит ротация лог-файлов, потому что если делать ротацию<br>> с помощью сигнала USR1 - перезапуска рабочих процессов не происходит,<br>> и происходит только лишь "re-opening log files", что является очень<br>> дешевой и очень быстрой операцией, такая ротация происходит<br>> практически мгновенно и не создает дополнительной нагрузки<br>> на систему.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Хорошо, вы озвучили ожидаемое, много где (в том числе в документации nginx) описанное, а кое-где по умолчанию прям в дефолтовых конфигах примененное решение.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br>> Причина, почему у Вас не получилось настроить ротацию лог-файлов<br>> при записи логов "напрямую с nginx-а в файл" может быть в такой<br>> ситуации только одна - для ротации лог-файлов Вы использовали<br>> сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Вероятно вам не раз приходилось сталкиваться с подобным, и вы автоматически считаете, что так поступают все.<br>Распространенная модель поведения.<br>Еще раз -- единственная новость тут для меня была в том, что у меня не получилось.<br>Все как раз получилось, дальше с этим работать было неудобно.<br>К тупой записи в файл претензий не было. <br>Я по простоте душевной допустил ту же оплошность, что и вы -- решил, что раз пишу логи для дальнейшей обработки данных из них, то и все остальные поступают так же...<br><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:<br>> <br>> >> какую именно проблему Вы пытаетесь решить с помощью записи логов<br>> >> в unix socket, чтения данных из unix socket`а питоновским<br>> скриптом<br>> >> и потом записи данных этим питоновским скриптом в текстовой файл?<br>> <br>> > Если вы предлагаете писать напрямую с nginx-а в файл --<br>> > сделайте у себя ротацию файлов с интервалом 30 сек<br>> > при 200-250 тыс подключений/сек...<br>> <br>> > Если у вас уже есть такое рабочее решение -<br>> > поделитесь опытом, буду рад вас выслушать.<br>> <br>> Почему Вам не подходит решение<br>> использовать сигнал USR1 для ротации логов?<br>> <br>> Ведь Вы же прямо говорите в этом своем сообщении, что проблема<br>> у Вас именно с тем, что не удается настроить сам процесс ротации<br>> логов с интервалом 30 сек при 200-250 тыс подключений/сек.<br>> <br>> О другой проблеме - нехватки свободного места на диске сервера<br>> для записи логов, или о проблеме низкой пропускной способности<br>> дисковой подсисетмы в своем ответе - Вы ничего не говорите.<br>> <br>> Это же какие у Вас получаются там объемы логов nginx за 30 секунд,<br>> что может не хватать пропускной способности дисковой подсистемы<br>> или свободного места на диске сервера?<br>> <br>> Почему у Вас не получается сделать ротацию лог-файлов nginx<br>> с интервалом 30 сек. при 200-250 тыс подключений в секунду?<br>> <br>> Низкая пропускная способность дисковой подсистемы сервера?<br>> <br>> Или нехватка свободного места для логов на диске сервера?<br>> <br>> On 13.02.2024 11:38, Anatoliy Melnik via nginx-ru wrote:<br>> <br>> > Для меня главный вопрос, на который надо дать ответ:<br>> > ЗАЧЕМ я пишу логи? ЧТО я дальше с ними буду делать?<br>> <br>> То есть, Вы хотите сказать, что Ваша исходная задача<br>> допускает решение, которое может быть реализовано<br>> вообще без исхользования access-логов nginx?</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Об этом было в посте от <small>January 22, 2024 04:12AM</small><br>Цитирую:<br>Зачем мне это нужно:<br>Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы.<br>Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются.<br>Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут.<br><br>Регулярно требуется "нестандартная" статистика, например <br>"средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"<br>"соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час"<br>"наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..."<br>"объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)"<br>и т.д.<br>нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Конец цитаты...<br>Чисто техничски можно и без access-логов, будете сами реализовывать нечто подобное -- выберете более близкое вам решение.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br>> <br>> Например, с помощью директив модуля ngx_http_mirror_module<br>> Если Вам достаточно информации, которая присутствует в логах,<br>> значит тело запроса не нужно и можно поставить mirror_request_body<br>> off;<br>> с помощью директивы mirror в internal location и последующим <br>> проксированием запросов на какой-то сервис на Go, который будет<br>> собирать, аккумулировать и отдавать необходимую Вам статистику.<br>> <br>> На Go с использованием goroutines и каналов можно построить очень<br>> эффективный сервис, который будет максимально масштабируемым<br>> и будет выдерживать очень большую нагрузку, так что мощности<br>> хватит с запасом, если проксировать запросы на этот демон<br>> через блок upstream с включенным keepalive.<br>> <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Идеальных решений не существует.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо tcp как ни крути более затратен по сравнению с unixSocket.<br>Или с высокой вероятностью упрусь в теже ограничения unixSocket если отказаться от tcp со всеми дальше вытекающими.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">При размещении на другом сервере решить проблему исчерпания портов для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без body их будет меньше, но все-таки довольно много..<br>Заняться изучением Go, потратить на это горку времени. Не, это не проблема, но дальше Go в обозримой перспективе на горизонте не просматривается.<br>При передаче всего этого хозяйства дальше на обслуживание в моем варианте разберется любой начинающий питонист, в предложенной вами схеме квалификация нужна будет повыше мне кажется.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Как видите я просто получу иной набор проблем. </div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Мой вариант также страдает набором недостатков, но поставленные задачи решает с устраивающей меня эффективностью.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Свой вариант я могу абсолютно спокойно масштабировать до необходимых мне значений, и эти значения почти на порядок выше текущих нагрузок.<br>Реализация укладывается в сотню строк кода... <br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> >>> Возникает впечатление, что кому-то из вас принципиально важно<br>> >>> доказать незыблемую правоту своего мнения и ошибочность моих<br>> >>> действий. Вопрос - зачем?<br>> <br>> Мне интересно понять суть проблемы и найти самое оптимальное решение.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Моя проблема "Х":<br>Ограниченность в связке nginx->unixSocket->syslog <br>Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х" не возникала в принципе на необходимых мне уровнях.<br><br>Возможны ли другие решения? безусловно!<br>Отказаться от nginx, отказаться от unixSocket, отказаться от unixSocket->syslog и т.д. и.т.п.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Объективно оптимального решения практически любой проблемы не существует в природе.<br>Если у вас в крсе обучения был такой предмет как "методы оптимизации" -- вы должны это понимать.<br>Вспомните задачки из курса:</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">На одну и ту же таблицу данных:<br>Постройте оптимальный маршрут по расстоянию.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Постройте оптимальный маршрут по времени.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Постройте оптимальный маршрут по загрузке.<br>Постройте оптимальный с учетом состояния дорог.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">И ответы везде разные, а табличка-то одна :)<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">И это которые простые задачки....<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br>> >>> Это не конкурс или состязание, я сюда обратился за советом.<br>> <br>> Вы спрашивали совета о том, как решить проблему Y,<br>> хотя на самом деле - Вы хотите решить проблему X.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br>> https://ru.wikipedia.org/wiki/Проблема_XY_(Ошибка_молотка)<br>> <br>> Проблема XY — это проблема, возникающая при обращении в службу<br>> поддержки<br>> и в других похожих ситуациях, когда обратившийся за помощью человек<br>> ставит не проблему X напрямую, а спрашивает решение проблемы Y,<br>> которая<br>> по его мнению позволит решить проблему X. Тем не менее, решение<br>> проблемы<br>> Y часто не решает проблему X, или является не самым удачным для неё<br>> решением. При этом человек, пытающийся помочь, может испытывать<br>> проблемы коммуникации и/или предлагать не самые оптимальные решения.<br>> <br>> Проблема XY обычно встречается в среде технической поддержки или<br>> обслуживания клиентов, где конечный пользователь пытается решить<br>> проблему самостоятельно и неправильно понимает реальную природу<br>> проблемы, полагая, что их реальная проблема X уже решена, за<br>> исключением<br>> некоторых мелких деталей Y в их решении. Неспособность обслуживающего<br>> персонала решить реальную проблему или понять природу запроса может<br>> привести к разочарованию конечного пользователя. Ситуация может<br>> проясниться, если конечный пользователь спросит о какой-то<br>> «бессмысленной» детали, которая не связана с полезной конечной целью.<br>> Решение для обслуживающего персонала состоит в том, чтобы задавать<br>> наводящие вопросы: зачем нужна эта информация, чтобы выявить корень<br>> проблемы и перенаправить конечного пользователя с непродуктивного<br>> пути исследования.<br>> <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">И "непродуктивность пути" определяете в данной конкретной ситуации не вы.<br>И конечную реализацию делаете не вы.<br>И за результаты отвечаете не вы.<br>Как и ответственность за все выполненное в итоге так же не на вас.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> > Все данные извлекаются в скрипте "на лету" и отображаются в<br>> соответствующих счетчиках.<br>> > При необходимости сосчитать что-то другое/новое или по другом<br>> алгоритму - я всего лишь изменю несколько строк скрипта.<br>> > На данном этапе проверенная производительность одной системы<br>> 240тыс/сек, прогноз исходя из статистики нагрузки - 400-420.<br>> <br>> Вместо syslog, unix socket и скриптов на Python - Вы пробовали<br>> вариант<br>> решения этой проблемы с помощью зеркалирования исходных запросов<br>> через<br>> директиву mirror с mirror_request_body off ? Получателем этих<br>> запросов<br>> может быть или какой-то веб-сервер на Python, например, gunicorn.org,<br>> или FastWSGI или сразу backend на Go, потому что там все<br>> компилируется<br>> сразу в машинный код и с помощью goroutines и каналов можно сделать<br>> достаточно эффективный backend для сбора статистики - это проблема X.<br>> <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Это решение мной рассмативалось на каком-то этапе, решил что менее перспективно, аргументы перечислены выше, </div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">хотя на этапе рассмотрения про ограничения unixSocket еще не проявилось.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Эффективность реализации весьма эфемерное понятие.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Эффективность с точки зрения чего?<br>Мы с вами эффективность считаем по совершенно разным критериям.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Это не хорошо и не плохо. Это просто по-разному :)<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Ваше мнение может отличаться от моего.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> > И на каждом этапе обсуждения мне казалось очевидным: мне нужна<br>> рабочая связка nginx->(unixSocket)->syslog !!!<br>> <br>> Получение рабочей связки nginx->(unixSocket)->syslog - это проблема<br>> Y.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br>> На самом деле - Вам нужно решение проблемы X.<br>> </div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Это вы сами решили?<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно решать что мне надо :)<br><br>> > Уже непререкаемая уверенность в собственной непогрешимости в<br>> некоторых постах должна была меня насторожить.<br>> <br>> я вполне способен воспринимать технически грамотные ответы<br>> и признавать свои ошибки, - если таковые имели место быть.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> </div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Отличное качество. Демонстрируйте его почаще :)<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> >> «Ничего личного, только бизнес».<br>> <br>> > Никогда не понимал восторгов этим правилом.<br>> <br>> Это я к тому, что меня не интересует обсуждение Вашей личности.<br>> А интересует поиск наиболее оптимальных способов решения интересных<br>> проблем и задач, которые имеют прямое или косвенное отношение к<br>> nginx.<br>> <br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Хорошо. Личности оставим в покое.<br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Про оптимальность я выше упоминал.<br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Оптимизировать можно по разным критериям.<br>Вы исходите из одних критериев оптимальности, я из других.<br>И это абсолютно нормально.<br>Не стоит убеждать меня в "неправильности" моих критериев.<br><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">Есть большое подозрение, что уже на текущем этапе по данному вопросу осталось лишь 2 собеседника.<br><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><br data-mce-bogus="1"></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> > Из личного опыта -- стараюсь не иметь дел с адептами этого подхода,<br>> и это сугубо личное.<br>> <br>> Формула «Ничего личного, только бизнес» имеет как положительную,<br>> как и отрицательную коннотацию. Отрицательная коннотация - потому<br>> что эта формула может быть использована для оправдания каких-то<br>> непопулярных действий и решений в бизнесе. Но есть и положительная,<br>> - в том смысле, что следует отделять личное отношение от "бизнеса",<br>> то есть, что при обсуждении каких-то технических проблем необходимо<br>> руководствоваться рациональностью и логикой, а не эмоциями.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000">> <br>> -- <br>> Best regards,<br>> Gena<br>> <br>> _______________________________________________<br>> nginx-ru mailing list<br>> nginx-ru@nginx.org<br>> https://mailman.nginx.org/mailman/listinfo/nginx-ru<br><br><br><br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt; color: #000000"><hr id="zwchr"><div><br><b></b></div></div></div></div></div></div></div></div></div></div><br></div></div></body></html>