Комментарии 42
А чем вызвано переписывание агента с python на ruby?
Это вызвано тем, что у нас все программисты используют Ruby, а python агент был написан достаточно давно и мы посчитали, что удобнее будет иметь все части системы на одном языке. P.s. мы были на Zabbix meetup в эту субботу, и Алексей Владышев из Zabbix подтвердил такую же проблему с их системой, которая написана на C, но имеет php frontend.
legacy, я понимаю. Но не могу не посочувствовать.
Из моего опыта, было дешевле освоить python, чем бороться с утечками и размером памяти у ruby. Еще хороший вариант на Go, и быстро и все можно в один бинарник влить, и не мучатся с зависимостями.
У Zabbix, как я понимаю, c наследием вообще жутко.
В моем случае, мы отказываемся от заббикса, как не справившегося.
Из моего опыта, было дешевле освоить python, чем бороться с утечками и размером памяти у ruby. Еще хороший вариант на Go, и быстро и все можно в один бинарник влить, и не мучатся с зависимостями.
У Zabbix, как я понимаю, c наследием вообще жутко.
В моем случае, мы отказываемся от заббикса, как не справившегося.
Сейчас у ruby с памятью ситуация потихоньку исправляется. Хотя go тут подошел бы идеально, на мой взгляд.
Расскажите, чем не справился?
1. Порядка терабайта метрик в месяц
2. Слабые возможности по составлению графиков, например две оси Y (на разные метрики), молчу про возможности визуализации
3. Нельзя отдать возможность написания шаблонов в «народ», слишком сложно и неявно
2. Слабые возможности по составлению графиков, например две оси Y (на разные метрики), молчу про возможности визуализации
3. Нельзя отдать возможность написания шаблонов в «народ», слишком сложно и неявно
Да это серьезно.
А NVPS в такой системе сколько?
Терабайт это объем данных истории или кол-во метрик?
До плагина графаны досидели?
На что планируете менять?
А NVPS в такой системе сколько?
Терабайт это объем данных истории или кол-во метрик?
До плагина графаны досидели?
На что планируете менять?
Мы не считали детали, прикидка общая. Терабайт — это размер базы за месяц, метрики мы пока не жмем, храним все, что есть.
NVPS — тут то же сложно. У нас есть метрики раз в секунду, раз в 10 сек и так далее, до раз в 10 минут. Количество метрик варьируется (иногда сильно) в зависимости от сервера/сервиса.
Grafana — это сейчас наше все. :) Zabbix планируем выпилить, и судя по всему, как страшный сон.
На текущий момент пришли к следующему:
— хранение данных opentsdb
— визуализация grafana
— сбор данных collectd (так же рассматриваем diamond)
— алертинг, выбираем между shinken и bosun. Очень вероятно, что будем совместно использовать.
— прогностика — kale
NVPS — тут то же сложно. У нас есть метрики раз в секунду, раз в 10 сек и так далее, до раз в 10 минут. Количество метрик варьируется (иногда сильно) в зависимости от сервера/сервиса.
Grafana — это сейчас наше все. :) Zabbix планируем выпилить, и судя по всему, как страшный сон.
На текущий момент пришли к следующему:
— хранение данных opentsdb
— визуализация grafana
— сбор данных collectd (так же рассматриваем diamond)
— алертинг, выбираем между shinken и bosun. Очень вероятно, что будем совместно использовать.
— прогностика — kale
NVPS — что у вас показывает, график на элементе zabbix[wcache,values]?
плагин Zabbix для Grafana — вы про это github.com/alexanderzobnin/grafana-zabbix?
а дайте плиз ссылку на kale?
плагин Zabbix для Grafana — вы про это github.com/alexanderzobnin/grafana-zabbix?
а дайте плиз ссылку на kale?
У меня нет метрик в заббиксе, на основании своего старого опыта, я просто не стал туда это все вносить. Зачем мне так нагружать РСУБД, которая просто не предназначена для такой работы, при условии приближенном к realtime?! Чтобы предупредить дальнейшие вопросы: у меня сейчас заббикс это наследие, причин его оставлять, я не вижу. Заббикс работает сейчас как алертинг, и не более.
habrahabr.ru/post/219377
habrahabr.ru/post/219377
Ну как бы без цифирей трудно говорить, где у вас там риалтайм, выставляете в в заббиксе большие кеши мегов на 512 или больше и у вас in-memory db :)
За kale thanks!
За kale thanks!
Ага, и начинаем все дальше и все толще делать серваки, все больше наворачивать на них решений по оптимизации. Тут архитектурная проблема. Если угодно, то не в самом заббиксе, а в том, что он использует рсубд.
Вот сейчас у меня тестеры просят иметь возможность просмотра набора метрик (достаточно сложный набор, и не только простые mean на шкале фремени) за 1-2 месяца, причем в реалтайме. На обычной рсубд это будет огромный набор джоинов и не последовательного чтения. На time series базе, чтение будет почти линейным. А в случае opentsdb, еще и распределенным, и мне не надо думать не о шардинге, не о бекапах.
Дальше математика: 2 месяца, это 2 Терабайта данных. Сейчас у меня на 1ТБ базе запрос около 40 метрик за 30 дней грузит сервак с (2 новых ксеончика, средних, 64 ГБ ram, ssd sas raid10) на секунд 15-20 с LA ~7-8, то есть горлышко в диске. Если сюда вставить рсубд, то по нагрузке все будет куда печальнее.
Вот сейчас у меня тестеры просят иметь возможность просмотра набора метрик (достаточно сложный набор, и не только простые mean на шкале фремени) за 1-2 месяца, причем в реалтайме. На обычной рсубд это будет огромный набор джоинов и не последовательного чтения. На time series базе, чтение будет почти линейным. А в случае opentsdb, еще и распределенным, и мне не надо думать не о шардинге, не о бекапах.
Дальше математика: 2 месяца, это 2 Терабайта данных. Сейчас у меня на 1ТБ базе запрос около 40 метрик за 30 дней грузит сервак с (2 новых ксеончика, средних, 64 ГБ ram, ssd sas raid10) на секунд 15-20 с LA ~7-8, то есть горлышко в диске. Если сюда вставить рсубд, то по нагрузке все будет куда печальнее.
За 1-2 месяца у вас просто кол-во точек не уместится на графике (если у вас еще интервалы по 10 сек), поэтому там используется тренды.
Не подумайте, что я вас отговариваю, Яндекс давно отказался от Zabbix.
Нам он удобен именно с точки зрения легкости его скрещивать со всем ,)
Не подумайте, что я вас отговариваю, Яндекс давно отказался от Zabbix.
Нам он удобен именно с точки зрения легкости его скрещивать со всем ,)
За 1-2 мес я получу графики (некоторые с двумя осями Y), где аномалии будет заметны, соответсвенно в той же grafana я могу выделить фрагмент и изучить его более внимательно. И при этом мне не надо будет дергать данные из разных точек. Например, у меня сейчас аномалия, и я хочу посмотреть за N-дней назад, были ли аномалии. С исторической БД такое не возможно (так, чтобы было удобно).
По поводу легкости скрешивания, ну у меня тут есть вопросы то же. На мой взгляд, описание шаблонов nagios-like куда удобнее.
По поводу легкости скрешивания, ну у меня тут есть вопросы то же. На мой взгляд, описание шаблонов nagios-like куда удобнее.
По поводу RDMS — Алексей обещает, что сделают плагинабл архитектуру для Zabbix, чтобы можно было разные БД использовать. Но боюсь это будет не скоро.
На митапе я лишь указал на различие в культуре разработки C и PHP, не более того. У каждого проекта с солидной историей есть определенный технический долг, в нашем случае этот долг сконцентрирован на стороне интерфейса, PHP. С этим мы активно работаем.
Eсли говорить о цифрах. Наши пользователи и клиенты подтвердят, что 70-80 миллиардов (!) проверок в месяц не являются пределом для Zabbix. И это не только простые пинги, но и тяжелые проверки уровня приложений, мониторинг лог файлов, VMWare и прочее.
Eсли говорить о цифрах. Наши пользователи и клиенты подтвердят, что 70-80 миллиардов (!) проверок в месяц не являются пределом для Zabbix. И это не только простые пинги, но и тяжелые проверки уровня приложений, мониторинг лог файлов, VMWare и прочее.
Моя проблема с zabbix не в проверках, а в невозможности хранить нормально time series и гибко их отрисовывать.
Сделайте партиционирование, разделите установки на операционный заббикс который алертинг, историю за неделю.
Остальные данные перекладывайте в историческую-аналитическую базу, в тот же opentsdи можно раз в час переливать.
С отрисовкой мне кажется вопрос полностью решен плагином на который дал выше.
Просто менять заббикс это когда она реально считать триггеры не может. То есть у вас дикий NVPS и вы уже все разнесли по проксям.
Остальные данные перекладывайте в историческую-аналитическую базу, в тот же opentsdи можно раз в час переливать.
С отрисовкой мне кажется вопрос полностью решен плагином на который дал выше.
Просто менять заббикс это когда она реально считать триггеры не может. То есть у вас дикий NVPS и вы уже все разнесли по проксям.
У меня вопрос — а зачем мне этим всем заниматься, когда проблема решается куда более простыми средствами?
Вот простой юзкейз: у меня есть логи, скажем gunicorn (php-fpm & etc), за сутки, есть метрики в zabbix, есть алгоритм (формула), которая дает возможность проанализировать запросы и его взаимоотношение с метриками. Как это реализовать в заббикс?
Будет большой набор костылей, скриптов и тд. В моем случае, я по курлу дергаю апишечки и все.
Вот простой юзкейз: у меня есть логи, скажем gunicorn (php-fpm & etc), за сутки, есть метрики в zabbix, есть алгоритм (формула), которая дает возможность проанализировать запросы и его взаимоотношение с метриками. Как это реализовать в заббикс?
Будет большой набор костылей, скриптов и тд. В моем случае, я по курлу дергаю апишечки и все.
С логами соглашусь на 100% в заббиксе это слабое место — мы идем по пути, что логи льем в elasticsearch, graylog2 и оттуда дергаем агрегированную метрику. Например вернуть кол-во вхождений слова error за последнею минуту и вешаем на нее триггер.
Ага, мы уже кажется обсуждали. На каком количестве логов начинает ложиться ES? Все таки его основная функция индексация и поиск, а не хранение.
И это не решает, без костылей, проблему поиска совпадений между метриками и логами. И совместных отчетов.
И это не решает, без костылей, проблему поиска совпадений между метриками и логами. И совместных отчетов.
Вы логи куда льете?
Для меня сейчас это очень актуальная задача. Ну в graylog2 он в монгу льет, а еластик как раз для индексации.
Для меня сейчас это очень актуальная задача. Ну в graylog2 он в монгу льет, а еластик как раз для индексации.
В моем наследии — в ES, сейчас переходим на hadoop. Там файлами будем класть, на начальном этапе, с RF=3. В перспективе возможно hbase/cassandra, тут будем смотреть на объемы и запросы от бизнеса.
Индексировать через, через еластик?
Как метрики из логов делать собираетесь?
Как метрики из логов делать собираетесь?
Да, ES.
Метрики из логов, мы еще тут прорабатываем архитектуру.
Для начала, будет дублирование, из приложения будем по udp класть в statsd, он уже будет класть в opentsdb.
И видимо на кластере хадупа, запустим несколько паучков, которые будут в ленивом режиме класть инфу в timeseries. Возможно по мере реализации придем к другим решениям.
Метрики из логов, мы еще тут прорабатываем архитектуру.
Для начала, будет дублирование, из приложения будем по udp класть в statsd, он уже будет класть в opentsdb.
И видимо на кластере хадупа, запустим несколько паучков, которые будут в ленивом режиме класть инфу в timeseries. Возможно по мере реализации придем к другим решениям.
При небольшом пересчете, эти «средние» 500 Гигабит трафика в секунду выливаются примерно в 5 273 Терабайт переданных данных в день. И это объем данных, передаваемый только лишь ~1300 серверами в нашей системе!
Вы гигабайтный файл с серверов передаете каждые четыре минуты? Откуда такие цифры?
Считается использование каналов всех серверов в системе. Каждую секунду, среднее значение по всем сервервам — 500 Gbit/s.
А MaxScale перед Galera попробовать не хотите mariadb.com/products/mariadb-maxscale?
New Relic много что мониторит, кроме как пинг серверов. У вас насколько близок к ним продукт?
Они интересны тем, что мониторят все от и до. И скрипты, и замедления от общения с sql, и какие запросы в sql вызвали замедления. За это и деньги просят.
P.S. И таки да, мониторить uptime — это одно, а вот делать тест портов, а потом еще и бекап в облако — ой, совсем другое!
Они интересны тем, что мониторят все от и до. И скрипты, и замедления от общения с sql, и какие запросы в sql вызвали замедления. За это и деньги просят.
P.S. И таки да, мониторить uptime — это одно, а вот делать тест портов, а потом еще и бекап в облако — ой, совсем другое!
Основной фокус New Relic'a это мониторинг приложений, как инструмент для разработчиков. Мы же — это больше платформа для системных администраторов и хостинг провайдеров, которые используют нас как «white label» решение, предоставляя доступ своим клиентам и сотрудникам технической поддержки, которым в первую очередь нужен мониторинг ресурсов и доступности серверов. Таким компаниям не приходится создавать свою платформу, они выдают нашу систему за свою.
> You can then add more servers for just $5 per server
Вот мне было всегда интересно, почему так дорого? Всего лишь «CPU, RAM, Disk Space, Network, etc». Например, у меня 20 виртуалок на DO по $5 каждая и мне теперь умножать цену за виртуалки вдвое ради ваших 20 проверок?
Вот мне было всегда интересно, почему так дорого? Всего лишь «CPU, RAM, Disk Space, Network, etc». Например, у меня 20 виртуалок на DO по $5 каждая и мне теперь умножать цену за виртуалки вдвое ради ваших 20 проверок?
Привет, на самом деле вы правы и это лишь общая цена, т.к. большинство мелких клиентов добавляют 1-2 сервера и всё. Нам с них просто нет смысла по доллару собирать. В данный момент всем кто имеет больше 5 серверов, мы опускаем цену, возможно добавим это на сайт.
А вы не задумывались об альтернативной модели биллинга? Например мне бы было удобно подписываться на что-то вроде «100.000» проверок в месяц за $x. Можно пойти еще дальше и сделать дневную или даже почасовую тарификацию. Да, это потребует дополнительных человеко-часов на разработку, но люди будут охотнее пользоваться вашим сервисом.
Вы серьезно? Нет FreeBSD?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
200 млн. проверок в месяц или архитектура и статистика сервиса CloudStats.me