Да, можно обойтись, только стоимость внешнего адреса сравнима со стоимостью VPS, которая у настоящих сварщиков (айтишников) уже обычно есть под рукой.
Родной облачный доступ требует подписки и наличия карточки, способной ее оплатить. Если есть "халявный" способ - расскажите, я думаю всем будет интересно.
Да это их стандартное поведение, главное увести диалог в личную переписку, затем кормить там завтраками.
Их «дочка» — eBay тем же самым занимается.
Вот например ситуация с купонами — явная ошибка eBay — уже почти больше двух недель кормят завтраками вся информация в социальных сетях гасится их SMM-щиками с уводом переписки в личку и дальнейшим полном игнорированием проблемы техподдержкой
Ну здесь может быть несколько подходов:
— если обработчик логов справляется на одной машине, то tail отправляет лог на лог-коллектор, где происходит обработка через тот же tail например — я думаю сотни миллиардов «хитов» такая связка в состоянии обработать
— если обработчик на одной машине не справляется, то tail делает пре-процессинг выявляя из записи в логе PID и делая балансировку лога на соответствующий лог-коллектор — при таком количестве «хитов» можно уже посадить отдельного человека и написать модуль для nginx, чтобы лог-запись сразу попадала в «правильный» лог-файл (один из н-цати, по количеству лог-коллекторов)
Приведенная выше ссылка — это сравнение сферического коня в вакууме, в стиле «Hello World», реальная нагрузка на веб-сервер при обработки статики не ограничивается отдачей одного файла.
В данной конфигурации «железа» у nginx для целей отдачи статики вокеров должно быть не более двух, конкретно в этом примере лучше 1, размер файла в 33 Кб выбран не случайно, чтобы «пролететь» мимо стандартных 32Кб буферов, кэширование файловых дескрипторов наверняка отключено, включено ли aio и sendfile и т.д. и т.п. — т.е. без конфигов и кода сервера на NodeJS это бессмысленно, может файл вообще в памяти в кэше NodeJS процесса осел. Особенно умиляет CPU-usage который в случае с NodeJS как минимум в 50 раз выше, что частично подтверждает догадку с кэшем в памяти :)
1) nginx тоже «рекурсивен» (асинхронен) и почему один «рекурсивный» сервер должен работать не медленнее другого «рекурсивного» сервера у меня в голове не укладывается — вспоминается легендарная фраза из мультика «А в попугаях то, я гораздо длиннее !!!»
2) Еще раз повторю, что если запись ДО 500 Кбайт/с в ОДИН поток, для Вас является высокой нагрузкой — то мне Вас жаль — современные SATA диски способны справиться с нагрузкой выше на 2 порядка, а SSD на 3 порядка
3) Да, для 2014 года файл на десятки гигабайт это мега-объем, но если это проблема, то его можно ротировать раз в час / 15 минут например, если данные не важны — удалять, если нужны — архивировать :)
4) В стандартном формате, перечисленным выше — напишу, в нужном Вам — может быть займет чуть больше — все описывается элементарно — можете ознакомиться сами nginx.org/ru/docs/http/ngx_http_log_module.html#log_format :)
Но Вас опыт наработанный админами за десятилетия не устраивает, захотелось создать дополнительную точку отказа, понизить надежность системы — да пожалуйста, может быть мой комментарий прочтут думающие люди и поймут насколько использование nginx в этой задаче проще и элегантнее.
Вы можете сопротивляться сколько угодно долго, но по Вашим ответам видно, что зерно сомнений в правильности выбранного пути уже начинает точить Вас :)
Одна строчка в логе — это хит, а не сессия, сколько их там забота обработчика.
Методика обработки лога ничем не отличается от алгоритма, описанного в статье, вешается watcher на событие «запись в файл», полученная пачка данных обрабатывается, процесс спит или занимается своими делами до следующего события «запись в файл». Следить нужно именно за записью в файл, а не файловый дескриптор.
Грубо и в лоб это решается открытием пайпа «tail -F access_log_name |», я не знаток NodeJS скорей всего есть стандартные событийные библиотеки такого рода, опять же в лоб можно обойтись стандартными средствами — stat на файл, с памятью предыдущего состояния.
Проблем с ротацией нет никаких, можете использовать стандартные средства, например syslog.
Мой комментарий относился к первому пункту ораторас предложением использовать memcached или in-memory таблицы, он никак не относится к Ваше методике обработки информации.
И даже при вашем подходе при сбое питания (ну или например перезагрузке процесса NodeJS, его корке и т.п.) будут 100% потеряны данные за последние 90 секунд и тех кто не проявлял активности (совершил запрос только на stat.gif) за последние 2 часа.
Только в памяти собирать было бы совершенно неправильно — потеря питания — и вся статистика за сутки пропала, но использовать что-то вида memcachedb или redis было бы более логично, для задачи такого рода — MongoDB тут явный оверкилл.
1) Как связана рекурсия со скоростью отдачи картинки, не совсем понятно. Вы всю статику на сайте тоже NodeJS отдаете, потому что он рекурсивен или все таки nginx?
2) Даже SATA HDD не загибаются от записи на скорости порядка 50-500Кбайт/с в один поток
3) Формат логов nginx описывается в его конфиге — хотите пишите в csv, хотите в формате query_string, хотите в json и именно то что нужно — соответственно никакие специальные парсеры писать не нужно
4) Значит вы свой код сократили бы примерно на 2/3 (код сервера) к затратам же по времени добавили бы 10-15 секунд на добавление описания access_log-а в нужном формате в конфиге nginx
P.S.: можете и дальше продолжать забивать гвозди микроскопом, разубеждать Вас в этом у меня нет ни сил, ни желания
А зачем здесь вообще мультипоточность, работа по http, когда задача решается тейлом в одном процессе лог-файла nginx, отдающего однопиксельный gif, зачем было изобретать весь этот велосипед?
Из плюсов подхода: нет никакой задержки на работу Вашего сервера при отдаче пикселя, возможность пережить падения сервера, запустив обработку с начала, возможность сразу отфильтровать запросы отличные от p.gif и stat.gif и т.д и т.п.
В DNS на яндексе для домена example-site.ru можно прописать CNAME запись на домен example.dlinkddns.com и необходимость в этом скрипте отпадет сама-собой,
Да, все верно
Половина статьи посвящена созданию внешнего туннеля - эту часть статьи можно просто пропустить
Yaha Cloud это же частная инициатива, если автор плагина захочет, то сможет поддержать и умный дом Маруси.
Без VPS/VDS туннель можно поднять через https://vk.com/dev/vk_tunnel - это требует больших телодвижений и не совсем то, что вы хотите.
Централизованная же поддержка зависит в первую очередь от востребованности данного функционала - будет спрос - будет и предложение.
Да, можно обойтись, только стоимость внешнего адреса сравнима со стоимостью VPS, которая у настоящих сварщиков (айтишников) уже обычно есть под рукой.
Родной облачный доступ требует подписки и наличия карточки, способной ее оплатить. Если есть "халявный" способ - расскажите, я думаю всем будет интересно.
Их «дочка» — eBay тем же самым занимается.
Вот например ситуация с купонами — явная ошибка eBay — уже почти больше двух недель кормят завтраками вся информация в социальных сетях гасится их SMM-щиками с уводом переписки в личку и дальнейшим полном игнорированием проблемы техподдержкой
— если обработчик логов справляется на одной машине, то tail отправляет лог на лог-коллектор, где происходит обработка через тот же tail например — я думаю сотни миллиардов «хитов» такая связка в состоянии обработать
— если обработчик на одной машине не справляется, то tail делает пре-процессинг выявляя из записи в логе PID и делая балансировку лога на соответствующий лог-коллектор — при таком количестве «хитов» можно уже посадить отдельного человека и написать модуль для nginx, чтобы лог-запись сразу попадала в «правильный» лог-файл (один из н-цати, по количеству лог-коллекторов)
Вы еще раз прочитайте, то что я написал — счетчики как раз и обрабатываются realtime
В данной конфигурации «железа» у nginx для целей отдачи статики вокеров должно быть не более двух, конкретно в этом примере лучше 1, размер файла в 33 Кб выбран не случайно, чтобы «пролететь» мимо стандартных 32Кб буферов, кэширование файловых дескрипторов наверняка отключено, включено ли aio и sendfile и т.д. и т.п. — т.е. без конфигов и кода сервера на NodeJS это бессмысленно, может файл вообще в памяти в кэше NodeJS процесса осел. Особенно умиляет CPU-usage который в случае с NodeJS как минимум в 50 раз выше, что частично подтверждает догадку с кэшем в памяти :)
2) Еще раз повторю, что если запись ДО 500 Кбайт/с в ОДИН поток, для Вас является высокой нагрузкой — то мне Вас жаль — современные SATA диски способны справиться с нагрузкой выше на 2 порядка, а SSD на 3 порядка
3) Да, для 2014 года файл на десятки гигабайт это мега-объем, но если это проблема, то его можно ротировать раз в час / 15 минут например, если данные не важны — удалять, если нужны — архивировать :)
4) В стандартном формате, перечисленным выше — напишу, в нужном Вам — может быть займет чуть больше — все описывается элементарно — можете ознакомиться сами nginx.org/ru/docs/http/ngx_http_log_module.html#log_format :)
Но Вас опыт наработанный админами за десятилетия не устраивает, захотелось создать дополнительную точку отказа, понизить надежность системы — да пожалуйста, может быть мой комментарий прочтут думающие люди и поймут насколько использование nginx в этой задаче проще и элегантнее.
Вы можете сопротивляться сколько угодно долго, но по Вашим ответам видно, что зерно сомнений в правильности выбранного пути уже начинает точить Вас :)
Методика обработки лога ничем не отличается от алгоритма, описанного в статье, вешается watcher на событие «запись в файл», полученная пачка данных обрабатывается, процесс спит или занимается своими делами до следующего события «запись в файл». Следить нужно именно за записью в файл, а не файловый дескриптор.
Грубо и в лоб это решается открытием пайпа «tail -F access_log_name |», я не знаток NodeJS скорей всего есть стандартные событийные библиотеки такого рода, опять же в лоб можно обойтись стандартными средствами — stat на файл, с памятью предыдущего состояния.
Проблем с ротацией нет никаких, можете использовать стандартные средства, например syslog.
И даже при вашем подходе при сбое питания (ну или например перезагрузке процесса NodeJS, его корке и т.п.) будут 100% потеряны данные за последние 90 секунд и тех кто не проявлял активности (совершил запрос только на stat.gif) за последние 2 часа.
2) Даже SATA HDD не загибаются от записи на скорости порядка 50-500Кбайт/с в один поток
3) Формат логов nginx описывается в его конфиге — хотите пишите в csv, хотите в формате query_string, хотите в json и именно то что нужно — соответственно никакие специальные парсеры писать не нужно
4) Значит вы свой код сократили бы примерно на 2/3 (код сервера) к затратам же по времени добавили бы 10-15 секунд на добавление описания access_log-а в нужном формате в конфиге nginx
P.S.: можете и дальше продолжать забивать гвозди микроскопом, разубеждать Вас в этом у меня нет ни сил, ни желания
Из плюсов подхода: нет никакой задержки на работу Вашего сервера при отдаче пикселя, возможность пережить падения сервера, запустив обработку с начала, возможность сразу отфильтровать запросы отличные от p.gif и stat.gif и т.д и т.п.
CNAME example.dlinkddns.com
На Яндексе нужно поставить @ вместо пустой строки
en.wikipedia.org/wiki/CNAME_record