Абсолютно с вами согласен.
Когда есть устоявшаяся методология и понимание процесса разработки и дейплоймента — chef прекрасно ложиться на Technical Operations.
Вот кстати тоже интересная ссылка по теме, про интеграцию docker с chef docs.deis.io/en/latest/gettingstarted/concepts/#concepts
Я пытался использовать logstash вместе с rsyslog, чтобы syslog сразу пересылать по сети в logstash, так как он на серверах уже есть и мы его используем достаточно тесно с zabbix.
Не хотелось деплоить агентов logstash вместе с java на сервера, где джава совсем не нужна.
Все достаточно прямолинейно.
У меня логи переливаются с серверов на центральный rsync сервер и там парсер на питоне их распарсивает и заливает их в elasticsearch. Парсер стартует по крону каждую минуту и заливает файлы начиная с самых свежих. То есть если логов много, когда активность юзеров выше — теоретически парсер может не успевать. Но это не проблема, так как в более спокойное время он подтягивает старые логи. Получается никакой потери логов даже под высокой нагрузкой.
у меня 3 xlarge инстанса на ec2, все упирается в disk-IO к сожалению. я использую striped LVM над 4 дисками ephemeral storage.
Насколько я понял, проблема не в языке jruby или python. Проблема в реализации, так как logstash тратил ресурсы и время на обработку входящих данных по TCP. Когда я тестировал, производительности не хватало. Я использовал rsync для транспорта данных и python+pyes c мультипроцессингом docs.python.org/2/library/multiprocessing.html для закачки логов в elasticsearch.
Я недавно видел в действии реализацию flume+elasticsearch. Мне очень понравилось. Если у меня будет достаточно времени — буду переходить на него.
можно делать
knife ssh «role:webserver AND chef_environment:production» «sudo chef-client» -С 4
и деплоить изменения сразу и с указанной конкуренцией ( что может быть удобно, когда сервера стоят за балансировщиком и нужно чтото рестартить).
По моему скромному мнению, chef идеалогически правильно заточен под devops workflow.
Посмотрите в сторону Proxmox, вполне удобно и даст Вам KVM виртуализацию с GUI обвязкой.
Proxmox cluster будет вполне удобно для фермы.
Я гоняю на ней в продакше FreeBSD через KVM безо всяких проблем, даже очень старые типа 4.1.
C другой стороны они потребовали гораздо меньше танцев при переноски с VmWare платформы виртуализации, чем Win2k например.
mongodb тоже может быть использовано для кеширования. С постоянным хранилищем и кучей приятных фич, таких как репликация и шардинг.
Даже статья была тут habrahabr.ru/post/124212/
3 amazon x.large инстанса с 2Тb локального хранилища каждый.
Занято примерно процентов 60-70 дисков, то есть около 5Тб данных.
Никакого дублирования данных, чтобы получить максимальную скорость. Если инстанс умирает, теряем треть индекса, но логи архивируются на s3, так что всегда можно поднять архив, если что.
Когда есть устоявшаяся методология и понимание процесса разработки и дейплоймента — chef прекрасно ложиться на Technical Operations.
Вот кстати тоже интересная ссылка по теме, про интеграцию docker с chef docs.deis.io/en/latest/gettingstarted/concepts/#concepts
Чем вы деплоите на видновс сервера? Какую автоматизацию используете?
Не хотелось деплоить агентов logstash вместе с java на сервера, где джава совсем не нужна.
У меня логи переливаются с серверов на центральный rsync сервер и там парсер на питоне их распарсивает и заливает их в elasticsearch. Парсер стартует по крону каждую минуту и заливает файлы начиная с самых свежих. То есть если логов много, когда активность юзеров выше — теоретически парсер может не успевать. Но это не проблема, так как в более спокойное время он подтягивает старые логи. Получается никакой потери логов даже под высокой нагрузкой.
Насколько я понял, проблема не в языке jruby или python. Проблема в реализации, так как logstash тратил ресурсы и время на обработку входящих данных по TCP. Когда я тестировал, производительности не хватало. Я использовал rsync для транспорта данных и python+pyes c мультипроцессингом docs.python.org/2/library/multiprocessing.html для закачки логов в elasticsearch.
Я недавно видел в действии реализацию flume+elasticsearch. Мне очень понравилось. Если у меня будет достаточно времени — буду переходить на него.
можно делать
knife ssh «role:webserver AND chef_environment:production» «sudo chef-client» -С 4
и деплоить изменения сразу и с указанной конкуренцией ( что может быть удобно, когда сервера стоят за балансировщиком и нужно чтото рестартить).
По моему скромному мнению, chef идеалогически правильно заточен под devops workflow.
С какими параметрами они были отформатированны?
Proxmox cluster будет вполне удобно для фермы.
Я гоняю на ней в продакше FreeBSD через KVM безо всяких проблем, даже очень старые типа 4.1.
C другой стороны они потребовали гораздо меньше танцев при переноски с VmWare платформы виртуализации, чем Win2k например.
Даже статья была тут habrahabr.ru/post/124212/
Занято примерно процентов 60-70 дисков, то есть около 5Тб данных.
Никакого дублирования данных, чтобы получить максимальную скорость. Если инстанс умирает, теряем треть индекса, но логи архивируются на s3, так что всегда можно поднять архив, если что.
elasticcluster
Status green Nodes 3 Docs 3 053 513 952
Но я не использую logstash, он слишком медленный, не успевает за потоком логов. Пришлось кастомный python код писать самому используя pyes.
Спасибо