Живу в Ирландии уже больше 2х лет, в целом написано правдиво, можно конечно напридираться по мелочам, но не буду.
Не понял только совета про детей — куча коллег переехала с детьми, и всем (и родителям, и детям) местные школы нравятся гораздо больше чем в России/Украине.
Ну и про медицину — стоматология тут мне нравится несравнимо больше чем в Москве. Или к примеру оптика и проверка зрения/покупка очков. Зато про остальную медицину очень смешанные впечатления. Но к примеру то как продажа лекарств отрегулирована мне нравится.
Категорически не согласен, придраться можно разве что к дыням. Tomatoes on the vine прекрасные всегда, манго не намного хуже чем в Тайланде, виноград отличный круглый год, яблоки на любой вкус.
Очень понравилась эта часть заключения, прекрасно сформулировано. Сам ощутил в первую очередь это после переезда в Ирландию:
В нашей компании работает около 65 национальностей и это безумно крутой опыт в обмене культурными знаниями. Если сравнить себя год назад с текущей версией, то ощущается какая то свобода от границ государства, национальностей, религии и так далее. Вы просто общаетесь с хорошими людьми каждый день.
Идея этакого тестового полигона для новых проверок интересная, но особой разницы между добавлением проверки в go-critic и любой другой проект с точки зрения пользователя может и не быть, к тому же не очень понятно как эту идею пользователям «продать».
Ну и отсутствие интеграции с редакторами/gometalinter делает ваш проект заметно менее привлекательным, ведь если уже кто-то заморочился с новой проверкой она должна быть полностью интегрирована в процесс разработки.
Про сам linter — опробовал на своем pet project, весьма полезной показалась rangeExprCopy, а paramTypeCombine скорее вредной. И если вы хотите иметь opinionated проверки, то надо чтоб их было легко отключить, а пока есть только опция -enable, тобишь явный whitelist.
А вообще желаю удачи с проектом, мало статического анализа не бывает.
Вот вы пишете, что «решили познакомиться с этим инструментом поближе» — и что из этого вышло? Используете уже где-то?
Я с Prometheus игрался несколько месяцев, он мне показался весьма перспективным (тегированные метрики + нормальный язык запросов + алерты), но pull-модель до сих пор смущает, поскольку приходится на серверах крутить по несколько сервисов, которые отдают метрики по HTTP. Ну и нет никаких возможностей по хранению старых данных с меньшей точностью, как в Graphite — только удалять можно. Так что дальше экспериментов дело не пошло.
Самое смешное то, что он не просто форкается и что-то шлет, он еще дергает Zabbix-API на каждый пакет.
При нормальной нагрузке это отличный способ убить сервер Заббикса.
Хотя, при нормальной нагрузке хранить сообщения в Postgres/MySQL базе Zabbix это уже плохая идея.
Если бы эта статья была не в блоге компании Zabbix, я бы посоветовал автору не мучаться, и использовать Graylog2/Logstash + Elasticsearch.
Чтобы еще больше испугаться, можно вспомнить о том, что внутри того же Заббикса реализованы свои аналоги очередей, и вообще внутренней логики наворочено ну очень много. А тут сам сервер весьма прост — тысяча строк кода, а очередями занимается специализированный сервер.
Спасибо за статью, весьма интересная тема. Добавят к этому Skydock поддержку нескольких серверов — будет отличная штука. Именно таких вот утилит и не хватает докеру для нормального использования в продакшне. Сам я пока использую docker только для QA, но перспективы у него очень большие.
Спасибо за статью, давно хотел попробовать Vagrant с Ansible и lxc/kvm. После знакомства с Docker будет интересно посмотреть на плагин Sahara. Хочу заметить, что статья действительно выглядит слегка незаконченной. Могли бы побольше описать свои сложные юз-кейсы, раз уж заявлены «другие истории из жизни бродяг».
Да нет, именно система мониторинга, как внешних, так и внутренних сервисов. Просто сильно кастомизированная под конкретный веб-проект. И именно в таких условиях sensu с возможностью роутить алерты очень удобен.
Задача примерно такая: мониторинг доступности самих серверов, а также неких внешних веб-сервисов с конкретных серверов, с записью всех неуспешных попыток в историю (Graylog2), и выводом всех проблем (вместе с адекватным описанием) на Dashboard для саппорта, который кроме этого показывает внутренние метрики проекта и внутренние же очереди для обрабоки саппортом. Т.е. веб-мониторинг самого Zabbix никак не подходил — запросы требовалось слать именно с конечных серверов. Как и дашборд Zabbix-а не подходил для этой задачи вывода информации никак.
Я прекрасно понимаю, что все это можно сделать и через Zabbix через запуск скрипта для проверки веб-сервисов через UserParameters, и выдергивание через API данных для Dashboard, и даже можно было пережить неудобную историю в самом Zabbix-е. Но лично мне проще было вынести эту специфичную задачу в Sensu, и производить развертывание и настройку всего этого через Ansible, и, соответственно, хранить все в git вместе с другими playbook-ами для развертывания проекта с нуля. Теперь все логично — dashboard и внутренние проверки/метрики развертываются вместе со всем проектом, а общий мониторинг площадки все также выполняется Zabbix-ом.
Вот смотрите — вы не видите такой задачи. А люди увидели, и решили таким образом. Дашборд у Zabbix-а ужасный, хоть и весьма функциональный. Все зависит от задач. Для вас Zabbix покрывает 100% встреченных задач. Я до недавнего времени тоже думал, что это все блажь хипстерская, а потом выяснилось, что вместо насилия над Zabbix и построения костылей, для одной из задач мониторинга проще использовать Sensu. Я вас переубедить не пытаюсь, просто показываю, что спектр задач у всех сильно разный, а для каждой задачи лучше использовать подходящий инструмент.
Вы сравниваете теплое с мягким, пытаясь сравнить Sensu с энтерпрайз-мониторингом. Задача Sensu — дать возможность максимально гибко направлять результаты проверок в различные обработчики. Это именно то, чего не хватает тому же Zabbix-у. Если нужен в качестве бекенда именно Graphite с его продвинутыми возможностями анализа данных — как вы завернете данные из Zabbix-а туда? Если нужно построить простой и наглядный Dashboard и слать данные туда, как вы это сделаете из Zabbix? Только через API, а это не самый простой способ. А если нужна история проверок не в убогом виде Zabbix, а в искабельном виде, в том же Logstash или Graylog2? Zabbix вроде бы все умеет, но не так хорошо, как специализированные инструменты.
Да и вообще — Zabbix развивается с 1998 года, Nagios с 1999, а Sensu с 2011, и сейчас в версии 0.12. У него хватает надостатков, но при этом он решает многие задачи, которые энтерпрайз-системы могут решить только с помощью каких-то костылей. Ну и на ваш вопрос типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Zabbix будет примерно на том же уровне — «поставьте сбоку 100 zabbix-прокси, каждый с максимально прокачанной СУБД для хранения потока данных». Про Nagios говорить не буду, я в нем не эксперт, а тем же Zabbix-ом пользуюсь уже не первый год, и ясно вижу его недостатки. Для каждой задачи нужен свой инструмент, и Sensu появился именно потому, что многие задачи с помощью Nagios/Zabbix решаются слишком неудобно для решающего.
Я специально в начале статьи сделал экскурс в истрию, чтобы показать, что появление Sensu — ответ сообщества на проблемы и недостатки имеющихся утилит. Даже ссылку на презентацию привёл.
С 1000 серверов никаких проблем. Каждый из них запустит свои (локальные) проверки, и опубликует их результаты в очереди RabbitMQ, а потом из этой очереди N серверов Sensu будут их забирать.
Надо смотреть исходники. По логике, клиент должен проверки раз в N секунд запускать, где N для каждой проверки свое. А уж как он распределяет их по этому интервалу — вопрос. Вообще Sensu создан для мониторинга серверов с агентами и проверками на них, а не для проверки сетевых устройств по SNMP.
Snmp тоже через внешние плагины. Проверки по расписанию — можно выставить большой интервал проверок, можно запускать в ручном режиме через API, можно выставить периоды, в которые не будет алерт создаваться через subdue. В документации описаны все возможности.
Но это вкусовщина, да и раз на раз не приходится нигде.
Не понял только совета про детей — куча коллег переехала с детьми, и всем (и родителям, и детям) местные школы нравятся гораздо больше чем в России/Украине.
Ну и про медицину — стоматология тут мне нравится несравнимо больше чем в Москве. Или к примеру оптика и проверка зрения/покупка очков. Зато про остальную медицину очень смешанные впечатления. Но к примеру то как продажа лекарств отрегулирована мне нравится.
Категорически не согласен, придраться можно разве что к дыням. Tomatoes on the vine прекрасные всегда, манго не намного хуже чем в Тайланде, виноград отличный круглый год, яблоки на любой вкус.
Ну и отсутствие интеграции с редакторами/gometalinter делает ваш проект заметно менее привлекательным, ведь если уже кто-то заморочился с новой проверкой она должна быть полностью интегрирована в процесс разработки.
Про сам linter — опробовал на своем pet project, весьма полезной показалась rangeExprCopy, а paramTypeCombine скорее вредной. И если вы хотите иметь opinionated проверки, то надо чтоб их было легко отключить, а пока есть только опция -enable, тобишь явный whitelist.
А вообще желаю удачи с проектом, мало статического анализа не бывает.
Я с Prometheus игрался несколько месяцев, он мне показался весьма перспективным (тегированные метрики + нормальный язык запросов + алерты), но pull-модель до сих пор смущает, поскольку приходится на серверах крутить по несколько сервисов, которые отдают метрики по HTTP. Ну и нет никаких возможностей по хранению старых данных с меньшей точностью, как в Graphite — только удалять можно. Так что дальше экспериментов дело не пошло.
При нормальной нагрузке это отличный способ убить сервер Заббикса.
Хотя, при нормальной нагрузке хранить сообщения в Postgres/MySQL базе Zabbix это уже плохая идея.
Если бы эта статья была не в блоге компании Zabbix, я бы посоветовал автору не мучаться, и использовать Graylog2/Logstash + Elasticsearch.
Я прекрасно понимаю, что все это можно сделать и через Zabbix через запуск скрипта для проверки веб-сервисов через UserParameters, и выдергивание через API данных для Dashboard, и даже можно было пережить неудобную историю в самом Zabbix-е. Но лично мне проще было вынести эту специфичную задачу в Sensu, и производить развертывание и настройку всего этого через Ansible, и, соответственно, хранить все в git вместе с другими playbook-ами для развертывания проекта с нуля. Теперь все логично — dashboard и внутренние проверки/метрики развертываются вместе со всем проектом, а общий мониторинг площадки все также выполняется Zabbix-ом.
Да и вообще — Zabbix развивается с 1998 года, Nagios с 1999, а Sensu с 2011, и сейчас в версии 0.12. У него хватает надостатков, но при этом он решает многие задачи, которые энтерпрайз-системы могут решить только с помощью каких-то костылей. Ну и на ваш вопрос типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Zabbix будет примерно на том же уровне — «поставьте сбоку 100 zabbix-прокси, каждый с максимально прокачанной СУБД для хранения потока данных». Про Nagios говорить не буду, я в нем не эксперт, а тем же Zabbix-ом пользуюсь уже не первый год, и ясно вижу его недостатки. Для каждой задачи нужен свой инструмент, и Sensu появился именно потому, что многие задачи с помощью Nagios/Zabbix решаются слишком неудобно для решающего.