Обновить
11
0
Dmitry Kireev@AutomationD

DevOps

Отправить сообщение
Да, на видео мелькнуло, но не означает 100% что это будет в конечном продукте. Да и ничего страшного если люди будут играть, от этого возрастет поток покупателей. К тому же всегда можно вежливо «попросить» посетителя. Всегда сложнее заманить клиента, чем вежливо выгнать его :)

Если зашли — это не значит что они зашли в пиццерию убить время :) Пример — я пришел с другом / сотрудником неформально пообщаться о конкретной теме, но это уже не важно, мне интереснее и удобнее заказать именно в этом заведении (при условии что решение будет успешным) — они меня подкупили новой фишкой, и я пришел к ним.

На вынос — я имел в виду заказ онлайн с доставкой, и онлайн pick-up.
Спасибо за статью, прочел месяц назад и только сейчас осознал что мне давно хотелось использовать данные в MySQL, но без map-reduce это было нереально.
Автору, спасибо за статью и интересный опыт!

С другой стороны я давно хотел попробовать Ansible из-за его «безагентности». Недавно разговаривал с ними на SCALE, очень открытые и общительные ребята.
Моя инфраструктура — это зоопарк из Windows и Linux, поэтому puppet как нельзя лучше подходит в качестве единого средства управления конфигурациями. Эх, как бы я хотел роскошь *nix only!
А с чего Вы взяли что там есть еще-что есть, кроме приложения заказа? Даже если так — у большинства посетителей Pizza Hut просто нет времени на то чтобы убивать так время, на то она и пиццерия. К тому же, по статистике, пиццу берут чаще «на вынос», и такой стол призван увеличить число посетителей, ради чего и flappy bird не жалко поставить :)
Вам подойдет, как вариант, стол с «вшитым» ipad. Дешево и эффективно!
Прекрасная идея. На данный момент активно пользуемся функцией «собери свою пиццу» на сайте. Почему бы не сделать это в самом кафе? Я — за. Я не думаю что это сильно скажется на стоимости пиццы — это не в их интересах. Внедрять скорее всего будут (если будут) сначала в узкой группе пиццерий, после чего уже во всех остальных, если увеличатся продажи.
Да, убрали. Оно и понятно, в реальном мире делается то, что лучше для бизнеса. Документ был загружен одним из пользователей, и реально обличал / клеветал одну немецкую компанию.
С точки зрения инженера — веселое время было. Злоумышленники не сразу заявили о себе и выставили требования, и я все выходные питался red bull и 5 hour energy — держали сайт. Эх, все хорошо что хорошо кончается — снятием документа или оплатой $300.
Но после этого случая мы серьезно пересмотрели нашу инфраструктуру, чего и всем советую :)
Я работаю в docstoc.com, года два назад нас DDoSили в течение 48 часов с требованиями убрать документ… Просто убрать документ с сайта…
Если речь идет о 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? Расскажите побольше о схеме доставки и обработке логов которую Вы пробовали.
Названия серверов на стикерах как-то скучно выглядят *ironic*

Rex Gaylord Jump Box:
image
Кто-нибудь нашел решение для структурированных фактов? Нужно передавать json объект. Применение — нужно передать список работающих служб, пути к исполняемым файлам.
В моей инфраструктуре сложность заключалась в том, что несколько кластеров имеют разные версии mongo, и поскольку 2.2 и 2.4 несовместимы между собой приходится иметь разные версии mongos на клиентах. Недавно решил задачу с установкой — создал пару пакетов для chocolatey для версий 2.2.X и 2.4.X. Таким образом устанавливать mongos на клиенты под винду стало еще удобнее:

class packages::mongodb::install {  
    include packages::chocolatey

    if $::kernel == "windows"
    {   

        package { "mongodb.core.2.4":            
            name => "mongodb.core.2.4",            
            ensure          => "2.4.9.2014021905",
            provider        => 'chocolatey',
            install_options => "-pre",
            require         => Class["packages::chocolatey"],
        }

        file {'c:\mongodb\2.4.9\log':
            ensure => directory,
            require => Package["mongodb.core.2.4"],
        }

        package { "mongodb.core.2.2":            
            name => "mongodb.core.2.2",            
            ensure          => "2.2.7.2014021905",
            provider        => 'chocolatey',
            install_options => "-pre",
            require         => Class["packages::chocolatey"],
        }

        file {'c:\mongodb\2.2.7\log':
            ensure => directory,                                   
            require => Package["mongodb.core.2.2"],
        }
    }
}

Позволяет распаковать mongodb в c:\mongodb\<версия>. После чего, можно установить службу, mongos, например:

class packages::mongodb::mongos::blah {  
    include packages::mongodb::install
    
    $mongo_version = '2.2.7'
        
    $cluster_name = 'Blah'    
    $bind_port = '27019'
    $configdb_list = 'cfg1.foo.corp:26001,cfg2.foo.corp:26002,cfg3.foo.corp:26003'

    $service_name = "Mongo $cluster_name Router"
    $mongo_install_path = "c:\\mongodb\\$mongo_version"
    $mongos_exe = "$mongo_install_path\\bin\\mongos.exe"
    $service_install_cmd = "\"$mongos_exe --port $bind_port --logpath $mongo_install_path\\log\\mongos-$cluster_name.log --configdb '$configdb_list' --quiet --install --serviceName '$service_name' --serviceDisplayName '$service_name' --serviceDescription '$service_name - Managed by Puppet'\""

    exec {"Register $service_name Service" :
                command => "$service_install_cmd",
                path => $::path,            
                onlyif => "if (\$(Get-WmiObject Win32_Service | Select-String -Pattern '$service_name') -eq \$null ){ exit 0 } else { exit 1 }",            
                provider => powershell,
                require => [Package["mongodb.core.2.2"],File["$mongo_install_path\\log"]], 
                notify => Service["$service_name"],
    }
     
    service {"$service_name":
                ensure => running,
                enable => true,                
                require => [ Exec["Register $service_name Service"]],                
    }
}
Хотел уточнить, что именно медленно? Доставка, парсинг или поиск?
Но что-то у Вас не так, размер нашего индекса 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 формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Эх, ностальгия… Вообще редко такие вещи в OpenSource уходят. Великолепно!
Сделал Donate.
Недавно разговаривал с представителем opscode на конференции SCALE. Как Вы и указали ранее, из коробки все используют поиск, который решает проблему оркестрации (знать о текущем состоянии конфигурации кластера и действовать на основании этого).
Также узнал много нового из «первых уст», и как оказалось, в действительности в chef та же абстракция от уровня ос, и декларативная модель. А еще я узнал почему используется install («что сделать? — Установить.»), вместо puppetовского «installed» («как должно быть? — Установлено). Ходят слухи, что они такое сделали чтобы не казаться „слизанными“ с набирающего тогда обороты puppet.
В общем будет возможность — буду пробовать chef, а пока уже половина всей инфраструктуры описаны в puppet.
Кстати, chef теперь поддерживается в theforeman — рекомендую попробовать, хорошая штука.

Всем добра и ясных инфраструктур!

Информация

В рейтинге
Не участвует
Откуда
New York, New York, США
Дата рождения
Зарегистрирован
Активность