Comments 26
а как с snmp? Через внешние плагины? Непонятно, как делать проверки по расписанию, например.
Snmp тоже через внешние плагины. Проверки по расписанию — можно выставить большой интервал проверок, можно запускать в ручном режиме через API, можно выставить периоды, в которые не будет алерт создаваться через subdue. В документации описаны все возможности.
управление очередью есть? Вот есть у меня за тысячу свитчей на сети, хочу снимать с них данные. Если начну (всего лишь) пинговать все полторы тысячи раз в секунду — то всё обвалится, а если распределить более-менее равномерно (не более 50 проверок одновременно, например), то будет работать нормально.
в мануале не нашёл.
нагиос сейчас со всей этой радостью справляется отлично, лоадавг по нулям.
в мануале не нашёл.
нагиос сейчас со всей этой радостью справляется отлично, лоадавг по нулям.
Надо смотреть исходники. По логике, клиент должен проверки раз в N секунд запускать, где N для каждой проверки свое. А уж как он распределяет их по этому интервалу — вопрос. Вообще Sensu создан для мониторинга серверов с агентами и проверками на них, а не для проверки сетевых устройств по SNMP.
Дык RabbitMQ. Там и рулите. Это как раз сервер сообщений.
Вот вроде, официальный плагин:
https://github.com/sensu-plugins/sensu-plugins-snmp
https://github.com/sensu-plugins/sensu-plugins-snmp
Среди плюсов не вижу ничего, чего нет в том же zabbix-е. Сообщество ruby-программистов уткнулось в проблему фундаментального недостатка?
Серьезно?
а когда заббикс научился использовать скрипты проверок от нагиоса и хранить конфиг в git вместо базы?
а когда заббикс научился использовать скрипты проверок от нагиоса и хранить конфиг в git вместо базы?
А оно надо это забиксу? Они идут своим путем.
Посредством сторонних костылей, вроде бы, да, научился — dev.aperto.fr/projects/3/wiki/Nagios_plugin_wrapper
Я не проверял — мне проще написать параметр в конфиг, чем прыгать с чужими проверялками.
Кто мешает хранить кусок mysqldump-а в git, если так уж хочется?
Я не проверял — мне проще написать параметр в конфиг, чем прыгать с чужими проверялками.
Кто мешает хранить кусок mysqldump-а в git, если так уж хочется?
Эм, вообще говоря это проблемы не составляет.
Я специально в начале статьи сделал экскурс в истрию, чтобы показать, что появление Sensu — ответ сообщества на проблемы и недостатки имеющихся утилит. Даже ссылку на презентацию привёл.
Вот, что характерно, презентация совершенно ни о чем и скорее свидетельствует об уровне бардака в голове у докладывающего. На 95% — совершенно общие слова о том, как человек замучен Nagios'ом и о неких недостатках архитектуры Nagios'а (и всяких внешних штуковин, к нему подключающихся).
Из того, что я вижу — радикально нового ничего по сути не предложено и ни одна из действительно актуальных проблем мониторинга современности не затронута. Использование «более generic» протоколов типа того же AMQP и написанных на коленке плагинов вместо специализированных эффективных протоколов и агентов — скорее огромный шаг назад, повышающий на порядок-два требования к железу. Очереди и модульность системы вообще не является чем-то сверхновым, подавляющее большинство систем мониторинга построены по таким принципам.
На вопросы типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Sensu будет что-то типа «поставьте сбоку еще пару сотен серверов под роутинг мониторинга и попытайтесь придумать сами что-нибудь для Graphite для хранения такого потока данных». Вопросы типа application domain метрик не рассматривались вообще — видимо, за ненадобностью.
Из того, что я вижу — радикально нового ничего по сути не предложено и ни одна из действительно актуальных проблем мониторинга современности не затронута. Использование «более generic» протоколов типа того же AMQP и написанных на коленке плагинов вместо специализированных эффективных протоколов и агентов — скорее огромный шаг назад, повышающий на порядок-два требования к железу. Очереди и модульность системы вообще не является чем-то сверхновым, подавляющее большинство систем мониторинга построены по таким принципам.
На вопросы типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Sensu будет что-то типа «поставьте сбоку еще пару сотен серверов под роутинг мониторинга и попытайтесь придумать сами что-нибудь для Graphite для хранения такого потока данных». Вопросы типа application domain метрик не рассматривались вообще — видимо, за ненадобностью.
Вы сравниваете теплое с мягким, пытаясь сравнить 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 решаются слишком неудобно для решающего.
Да и вообще — Zabbix развивается с 1998 года, Nagios с 1999, а Sensu с 2011, и сейчас в версии 0.12. У него хватает надостатков, но при этом он решает многие задачи, которые энтерпрайз-системы могут решить только с помощью каких-то костылей. Ну и на ваш вопрос типа «у нас есть 10K серверов, с 200-300 метрик на каждый, из них ~30-40 нужно трекать хотя бы раз в 10 секунд — как бы нам это сделать» ответ у Zabbix будет примерно на том же уровне — «поставьте сбоку 100 zabbix-прокси, каждый с максимально прокачанной СУБД для хранения потока данных». Про Nagios говорить не буду, я в нем не эксперт, а тем же Zabbix-ом пользуюсь уже не первый год, и ясно вижу его недостатки. Для каждой задачи нужен свой инструмент, и Sensu появился именно потому, что многие задачи с помощью Nagios/Zabbix решаются слишком неудобно для решающего.
Я ровно к тому, что задача на самом деле надуманная. Ну, не вижу я в реальном мире такой сверхсамозадачи — роутить трафик метрик. Если мне нужно что-то проанализировать сложное по метрикам — то я в жизнь не подумаю брать Graphite для post-mortem аналитики, а обойдусь каким-то специализированным решением (отгружу, что нужно из базы в сторонку и как-то обработаю). Если говорить о дашбордах в Zabbix — встроенные dashboard'ы Zabbix'а покрывали пока 100% встреченных мною задач, и, опять же, я скорее пойду по пути наименьшего сопротивления и допишу соответствующую функциональность в Zabbix, нежели буду городить какой-то отдельный dashboard. Гонять весь объем логов через систему мониторинга — с моей точки зрения — вообще варварство и дикость. Если нужно трекать логи — они и будут трекаться (и индексироваться — хотя, опять же, как показывает практика — индексирование — скорее порочная практика) отдельно, а в Zabbix/Nagios/whatever будут отсылаться только коротенькие результаты проверки.
На вопрос про 10K серверов ответ у Zabbix будет на уровне «30-40 zabbix proxy», у хорошо настроенного Nagios — штук 5-7. Боюсь, что у Sensu количество серверов, только разгребающих очередь, будет на порядок-полтора-два больше, не считая того, что такая инфраструктура плагинов будет страшно жрать ресурсы на каждом проверяемом сервере и не считая всего того, что будет стоять за серверами, разгребающими очередь.
Собственно, я даже заочно могу сразу сказать, что идея «разгребать MQ-очередь метрик по одной» при достижении определенных нагрузок — дурацкая и порочная сама по себе, даже вне зависимости от эффективности реализации MQ и клиентов. Спасение — только буферизация, только отказ от real-time-с-точностью-до-события, от timing consistency, выставление четких параметров рабочего sliding window и следование им…
На вопрос про 10K серверов ответ у Zabbix будет на уровне «30-40 zabbix proxy», у хорошо настроенного Nagios — штук 5-7. Боюсь, что у Sensu количество серверов, только разгребающих очередь, будет на порядок-полтора-два больше, не считая того, что такая инфраструктура плагинов будет страшно жрать ресурсы на каждом проверяемом сервере и не считая всего того, что будет стоять за серверами, разгребающими очередь.
Собственно, я даже заочно могу сразу сказать, что идея «разгребать MQ-очередь метрик по одной» при достижении определенных нагрузок — дурацкая и порочная сама по себе, даже вне зависимости от эффективности реализации MQ и клиентов. Спасение — только буферизация, только отказ от real-time-с-точностью-до-события, от timing consistency, выставление четких параметров рабочего sliding window и следование им…
Вот смотрите — вы не видите такой задачи. А люди увидели, и решили таким образом. Дашборд у Zabbix-а ужасный, хоть и весьма функциональный. Все зависит от задач. Для вас Zabbix покрывает 100% встреченных задач. Я до недавнего времени тоже думал, что это все блажь хипстерская, а потом выяснилось, что вместо насилия над Zabbix и построения костылей, для одной из задач мониторинга проще использовать Sensu. Я вас переубедить не пытаюсь, просто показываю, что спектр задач у всех сильно разный, а для каждой задачи лучше использовать подходящий инструмент.
Ну так и поделитесь — если не секрет — что же за задачу вы лично решали с помощью Sensu? Думаю, с живым примером было бы куда интереснее читать о сравнительно новой системе.
Задача примерно такая: мониторинг доступности самих серверов, а также неких внешних веб-сервисов с конкретных серверов, с записью всех неуспешных попыток в историю (Graylog2), и выводом всех проблем (вместе с адекватным описанием) на Dashboard для саппорта, который кроме этого показывает внутренние метрики проекта и внутренние же очереди для обрабоки саппортом. Т.е. веб-мониторинг самого Zabbix никак не подходил — запросы требовалось слать именно с конечных серверов. Как и дашборд Zabbix-а не подходил для этой задачи вывода информации никак.
Я прекрасно понимаю, что все это можно сделать и через Zabbix через запуск скрипта для проверки веб-сервисов через UserParameters, и выдергивание через API данных для Dashboard, и даже можно было пережить неудобную историю в самом Zabbix-е. Но лично мне проще было вынести эту специфичную задачу в Sensu, и производить развертывание и настройку всего этого через Ansible, и, соответственно, хранить все в git вместе с другими playbook-ами для развертывания проекта с нуля. Теперь все логично — dashboard и внутренние проверки/метрики развертываются вместе со всем проектом, а общий мониторинг площадки все также выполняется Zabbix-ом.
Я прекрасно понимаю, что все это можно сделать и через Zabbix через запуск скрипта для проверки веб-сервисов через UserParameters, и выдергивание через API данных для Dashboard, и даже можно было пережить неудобную историю в самом Zabbix-е. Но лично мне проще было вынести эту специфичную задачу в Sensu, и производить развертывание и настройку всего этого через Ansible, и, соответственно, хранить все в git вместе с другими playbook-ами для развертывания проекта с нуля. Теперь все логично — dashboard и внутренние проверки/метрики развертываются вместе со всем проектом, а общий мониторинг площадки все также выполняется Zabbix-ом.
Меня в мониторинге использование очередей одновременно и радует и пугает: радует в том смысле, что становится легко масштабировать, а пугает в том смысле, что это еще одна точка отказа в сервисе, который в общем-то и должен заниматься слежением за точками отказа.
UFO just landed and posted this here
Sign up to leave a comment.
Sensu — фреймворк для мониторинга