Да, на видео мелькнуло, но не означает 100% что это будет в конечном продукте. Да и ничего страшного если люди будут играть, от этого возрастет поток покупателей. К тому же всегда можно вежливо «попросить» посетителя. Всегда сложнее заманить клиента, чем вежливо выгнать его :)
Если зашли — это не значит что они зашли в пиццерию убить время :) Пример — я пришел с другом / сотрудником неформально пообщаться о конкретной теме, но это уже не важно, мне интереснее и удобнее заказать именно в этом заведении (при условии что решение будет успешным) — они меня подкупили новой фишкой, и я пришел к ним.
На вынос — я имел в виду заказ онлайн с доставкой, и онлайн pick-up.
Спасибо за статью, прочел месяц назад и только сейчас осознал что мне давно хотелось использовать данные в MySQL, но без map-reduce это было нереально.
С другой стороны я давно хотел попробовать Ansible из-за его «безагентности». Недавно разговаривал с ними на SCALE, очень открытые и общительные ребята.
Моя инфраструктура — это зоопарк из Windows и Linux, поэтому puppet как нельзя лучше подходит в качестве единого средства управления конфигурациями. Эх, как бы я хотел роскошь *nix only!
А с чего Вы взяли что там есть еще-что есть, кроме приложения заказа? Даже если так — у большинства посетителей Pizza Hut просто нет времени на то чтобы убивать так время, на то она и пиццерия. К тому же, по статистике, пиццу берут чаще «на вынос», и такой стол призван увеличить число посетителей, ради чего и flappy bird не жалко поставить :)
Прекрасная идея. На данный момент активно пользуемся функцией «собери свою пиццу» на сайте. Почему бы не сделать это в самом кафе? Я — за. Я не думаю что это сильно скажется на стоимости пиццы — это не в их интересах. Внедрять скорее всего будут (если будут) сначала в узкой группе пиццерий, после чего уже во всех остальных, если увеличатся продажи.
Да, убрали. Оно и понятно, в реальном мире делается то, что лучше для бизнеса. Документ был загружен одним из пользователей, и реально обличал / клеветал одну немецкую компанию.
С точки зрения инженера — веселое время было. Злоумышленники не сразу заявили о себе и выставили требования, и я все выходные питался red bull и 5 hour energy — держали сайт. Эх, все хорошо что хорошо кончается — снятием документа или оплатой $300.
Но после этого случая мы серьезно пересмотрели нашу инфраструктуру, чего и всем советую :)
Если речь идет о logstash — то я создал пакет logstash в репозитории chocolatey, и вся автоматизация сводится к установке пакета. Я использую puppet и ресурс package.
Вот статья на тему использования пакетов chocolatey. Там, кстати, рассматривается пакет logstash в качестве примера.
А как деплоить — это уже решать Вам, можно все упростить до:
cinst logstash
Также буду рад ответить на вопросы и выслушать предложения.
Да, деплоить джаву где она не нужна — это резонная причина, полностью согласен (хотя фактически это особенно ничего не меняет, у меня агенты на windows серверах, и ничего — 150Mb памяти — все что нам нужно :)).
Возможно тогда интерес вызовут другие шипперы, например beaver.
Logstash действительно хорош, когда дело доходит до обработки и парсинга данных (которые можно шипить чем угодно).
Я хотел уточнить по поводу конфигурации когда logstash работал медленно, после чего Вы решили использовать свое решение.
Я использую logstash (agent) => redis => logstash (master) => elasticsearch, таким образом redis работает как буфер, и если сравнивать с Вашим решением — сильно минимизирует io (у Вас rsync (read io) => rsync (write io) => python (read io) => elastic search (write io). Выходит в версии с logstash->redis->logstash->elasticsearch disk io уменьшено как минимум на 2 раза.
То есть узкое место при чтении логов на клиенте? Или при обработке на стороне парсера?
Я хочу помочь, так-как возможно что-то упущено. Logstash показал себя как очень умереный к ресурсам продукт, и тем более (по логике) должен быть шустрее решений на python (ничего против не имею, просто имхо).
Какой у Вас Setup? Centrallized? Расскажите побольше о схеме доставки и обработке логов которую Вы пробовали.
Кто-нибудь нашел решение для структурированных фактов? Нужно передавать json объект. Применение — нужно передать список работающих служб, пути к исполняемым файлам.
В моей инфраструктуре сложность заключалась в том, что несколько кластеров имеют разные версии mongo, и поскольку 2.2 и 2.4 несовместимы между собой приходится иметь разные версии mongos на клиентах. Недавно решил задачу с установкой — создал пару пакетов для chocolatey для версий 2.2.X и 2.4.X. Таким образом устанавливать mongos на клиенты под винду стало еще удобнее:
Хотел уточнить, что именно медленно? Доставка, парсинг или поиск?
Но что-то у Вас не так, размер нашего индекса 3012959708 документов (и это за 2 недели), работает на 2х серверах — поиск в реальном времени прекрасно работает. Возможно дело в EC2 и производительности, конечно.
На всякий случай уточню, какие параметры worker и batch у агента? JVM Heap на агенте / сервере?
Также я не могу поверить что python быстрее чем jruby, на какой реализации писали?
Мы делаем запрос к elastic search напрямую. Т.е. «А сколько у нас событий такого типа в течение часа?» — результат мониторим nagios/opsview, который говорит «О, больше 1000, значит это Error и надо уведомить админов». Очень эффективно. Плюс график Kibana висит постоянно на мониторах в офисе, так что волей не волей увидишь красный цвет в графиках :)
Спасибо за статью, наткнулся совершенно случайно.
Узнал о logstash когда был на SCALE11, с тех пор используем его постоянно. Elastic Search позволяет делать невероятные вещи с поиском в реальном времени — парсим не только логи с ошибками, но и логи с метриками, на базе которых строим графики. Вручную или с помощью децентрализованных инструментов такое сделать просто нереально, поток данных — сотни и тысячи событий в секунду. Вообще, если задуматься, logstash сэкономил нам ОООчень много денег вместо того чтобы покупать Splunk.
Автоматизировал развертывание агента на Linux и Windows машины, описал в Puppet конфигурацию. Девелоперы знают, что если писать лог с суффиксом *logstash* то он будет подобран автоматически. Часто используем .json формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Недавно разговаривал с представителем opscode на конференции SCALE. Как Вы и указали ранее, из коробки все используют поиск, который решает проблему оркестрации (знать о текущем состоянии конфигурации кластера и действовать на основании этого).
Также узнал много нового из «первых уст», и как оказалось, в действительности в chef та же абстракция от уровня ос, и декларативная модель. А еще я узнал почему используется install («что сделать? — Установить.»), вместо puppetовского «installed» («как должно быть? — Установлено). Ходят слухи, что они такое сделали чтобы не казаться „слизанными“ с набирающего тогда обороты puppet.
В общем будет возможность — буду пробовать chef, а пока уже половина всей инфраструктуры описаны в puppet.
Кстати, chef теперь поддерживается в theforeman — рекомендую попробовать, хорошая штука.
Если зашли — это не значит что они зашли в пиццерию убить время :) Пример — я пришел с другом / сотрудником неформально пообщаться о конкретной теме, но это уже не важно, мне интереснее и удобнее заказать именно в этом заведении (при условии что решение будет успешным) — они меня подкупили новой фишкой, и я пришел к ним.
На вынос — я имел в виду заказ онлайн с доставкой, и онлайн pick-up.
С другой стороны я давно хотел попробовать Ansible из-за его «безагентности». Недавно разговаривал с ними на SCALE, очень открытые и общительные ребята.
Моя инфраструктура — это зоопарк из Windows и Linux, поэтому puppet как нельзя лучше подходит в качестве единого средства управления конфигурациями. Эх, как бы я хотел роскошь *nix only!
С точки зрения инженера — веселое время было. Злоумышленники не сразу заявили о себе и выставили требования, и я все выходные питался red bull и 5 hour energy — держали сайт. Эх, все хорошо что хорошо кончается — снятием документа или оплатой $300.
Но после этого случая мы серьезно пересмотрели нашу инфраструктуру, чего и всем советую :)
Вот статья на тему использования пакетов chocolatey. Там, кстати, рассматривается пакет logstash в качестве примера.
А как деплоить — это уже решать Вам, можно все упростить до:
Также буду рад ответить на вопросы и выслушать предложения.
Возможно тогда интерес вызовут другие шипперы, например beaver.
Logstash действительно хорош, когда дело доходит до обработки и парсинга данных (которые можно шипить чем угодно).
Я использую logstash (agent) => redis => logstash (master) => elasticsearch, таким образом redis работает как буфер, и если сравнивать с Вашим решением — сильно минимизирует io (у Вас rsync (read io) => rsync (write io) => python (read io) => elastic search (write io). Выходит в версии с logstash->redis->logstash->elasticsearch disk io уменьшено как минимум на 2 раза.
Я хочу помочь, так-как возможно что-то упущено. Logstash показал себя как очень умереный к ресурсам продукт, и тем более (по логике) должен быть шустрее решений на python (ничего против не имею, просто имхо).
Какой у Вас Setup? Centrallized? Расскажите побольше о схеме доставки и обработке логов которую Вы пробовали.
Rex Gaylord Jump Box:
Позволяет распаковать mongodb в c:\mongodb\<версия>. После чего, можно установить службу, mongos, например:
Но что-то у Вас не так, размер нашего индекса 3012959708 документов (и это за 2 недели), работает на 2х серверах — поиск в реальном времени прекрасно работает. Возможно дело в EC2 и производительности, конечно.
На всякий случай уточню, какие параметры worker и batch у агента? JVM Heap на агенте / сервере?
Также я не могу поверить что python быстрее чем jruby, на какой реализации писали?
Узнал о logstash когда был на SCALE11, с тех пор используем его постоянно. Elastic Search позволяет делать невероятные вещи с поиском в реальном времени — парсим не только логи с ошибками, но и логи с метриками, на базе которых строим графики. Вручную или с помощью децентрализованных инструментов такое сделать просто нереально, поток данных — сотни и тысячи событий в секунду. Вообще, если задуматься, logstash сэкономил нам ОООчень много денег вместо того чтобы покупать Splunk.
Автоматизировал развертывание агента на Linux и Windows машины, описал в Puppet конфигурацию. Девелоперы знают, что если писать лог с суффиксом *logstash* то он будет подобран автоматически. Часто используем .json формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Сделал Donate.
Также узнал много нового из «первых уст», и как оказалось, в действительности в chef та же абстракция от уровня ос, и декларативная модель. А еще я узнал почему используется install («что сделать? — Установить.»), вместо puppetовского «installed» («как должно быть? — Установлено). Ходят слухи, что они такое сделали чтобы не казаться „слизанными“ с набирающего тогда обороты puppet.
В общем будет возможность — буду пробовать chef, а пока уже половина всей инфраструктуры описаны в puppet.
Кстати, chef теперь поддерживается в theforeman — рекомендую попробовать, хорошая штука.
Всем добра и ясных инфраструктур!