Система алертов для графита

[Александр Акулов]

Приветствую всех!

Графит отличный проект, но я не могу найти для него нормальную систему алертов.
Я ориентируюсь на zabbix, там всё более-менее хорошо с триггерами. Я могу настроить триггер используя несколько элементов данных, могу настроить триггер если значения более чем на 20% отличаются от того, что было неделю назад и тд. Я могу выставить важность триггера и настроить отправку всех уведомлений на почту, а критических и на смс.
По сравнению со всем этим то, что есть у Seyren наводит на меня уныние.

Может я чего-то не знаю, и есть какая-то классная система алертов для графита? Чем вы пользуетесь?

[Timur Batyrshin]

Riemann здесь не поможет?

Для роутинга уведомлений -- какой-нибудь PagerDuty.

вторник, 9 декабря 2014 г., 15:27:44 UTC+3 пользователь Александр Акулов написал:

[Denis Kot]

Для личного развития. Чем графит лучше zabbix? Или точнее что такого есть в графите, чего не в zabbix?

Denis Kot
Skype: kot.denis

10 декабря 2014 г., 10:26 пользователь Timur Batyrshin <ert...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "devopsru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Alexander Driantsov]

> Для личного развития. Чем графит лучше zabbix? Или точнее что такого есть в графите, чего не в zabbix?

Это разные вещи принципиально. 

Графит(а вернее Carbon) - back-end для хранения метрик, 

zabbix - система мониторинга. 

Graphite хорош тем, что способен собирать десятки тысячи метрик при низких затратах на железо(на что в конфигурации с zabbix'ом потребовалось бы несколько машин и периодические работы по оптимизации его базы), горизонтально масштабируем, позволяет объединять различные метрики и строить графики зависимостей по ним, да и вообще очень крут.

Графит не был создан для того чтобы оповещать вас о проблемах, он создан для того чтобы собирать метрики, для дальнейшего просмотра статистики/тенденции. 

Конечно, вы можете собирать и системные метрики(collectd?), но нужно понимать, что реагировать на изменения в метриках, не есть задача графита. Для этого вам лучше взять тот же zabbix/nagios

[Denis Kot]

Спасибо. Т.е. если мне нужно рисовать графики с периодичностью в, например, 1 секунду, то графит как раз для этого подходит?

Denis Kot
Skype: kot.denis

10 декабря 2014 г., 11:50 пользователь Alexander Driantsov <ben...@ecwid.com> написал:

[Alexander Driantsov]

>Спасибо. Т.е. если мне нужно рисовать графики с периодичностью в, например, 1 секунду, то графит как раз для этого подходит?

Да, именно.  Вернее даже несколько тысяч графиков в секунду. Почитайте про него, он очень хорошо работает с диском и даже при низком io работает очень быстро.

[Timur Batyrshin]

Сразу посоветую посмотреть параллельно с графитом еще в сторону InfluxDB.

У графита, говорят, трудно решаемые проблемы с производительностью возникают на очень больших масштабах данных (в любом случае на несколько порядков больших, чем в случае заббикса) + на таком количестве метрик их становится проблематично группировать (всю информацию в имя метрики не запихнешь). InfluxDB вроде как должен их решить.

Есть еще несколько вариантов баз для метрик, но они менее прозрачны в установке/поддержке, либо относительно мало популярны (или и то и другое вместе).

среда, 10 декабря 2014 г., 11:53:50 UTC+3 пользователь Denis Kot написал:

[Anton Lebedevich]

Нет, раз в секунду - это слишком быстро для graphite, там по всему стеку
разнообразные проблемы возникают, а раз в 10 секунд работает нормально.
В зависимости от числа метрик и машин может придется задуматься о
масштабировании.
Если будете раз в 10 секунд данные собирать, то лучше сразу поставить
несколько carbon-cache за одним carbon-relay и SSD диск.

On 12/10/2014 11:53 AM, Denis Kot wrote:
> Спасибо. Т.е. если мне нужно рисовать графики с периодичностью в,
> например, 1 секунду, то графит как раз для этого подходит?
>
> Denis Kot
> Skype: kot.denis
>
>
> 10 декабря 2014 г., 11:50 пользователь Alexander Driantsov

> <ben...@ecwid.com <mailto:ben...@ecwid.com>> написал:

>
> > Для личного развития. Чем графит лучше zabbix? Или точнее что такого есть в графите, чего не в zabbix?
>
> Это разные вещи принципиально.
>
> Графит(а вернее Carbon) - back-end для хранения метрик,
> zabbix - система мониторинга.
>
> Graphite хорош тем, что способен собирать десятки тысячи метрик при
> низких затратах на железо(на что в конфигурации с zabbix'ом
> потребовалось бы несколько машин и периодические работы по
> оптимизации его базы), горизонтально масштабируем, позволяет
> объединять различные метрики и строить графики зависимостей по ним,
> да и вообще очень крут.
>
> Графит не был создан для того чтобы оповещать вас о проблемах, он
> создан для того чтобы собирать метрики, для дальнейшего просмотра
> статистики/тенденции.
>
> Конечно, вы можете собирать и системные метрики(collectd?), но нужно
> понимать, что реагировать на изменения в метриках, не есть задача
> графита. Для этого вам лучше взять тот же zabbix/nagios
>
> 2014-12-10 11:31 GMT+03:00 Denis Kot <deni...@gmail.com

> <mailto:deni...@gmail.com>>:

>
> Для личного развития. Чем графит лучше zabbix? Или точнее что
> такого есть в графите, чего не в zabbix?
>
> Denis Kot
> Skype: kot.denis
>
>
> 10 декабря 2014 г., 10:26 пользователь Timur Batyrshin

> <ert...@gmail.com <mailto:ert...@gmail.com>> написал:

[Slawa Olhovchenkov]

On Wed, Dec 10, 2014 at 02:08:08AM -0800, Timur Batyrshin wrote:

> Сразу посоветую посмотреть параллельно с графитом еще в сторону InfluxDB.
> У графита, говорят, трудно решаемые проблемы с производительностью
> возникают на очень больших масштабах данных (в любом случае на несколько
> порядков больших, чем в случае заббикса) + на таком количестве метрик их
> становится проблематично группировать (всю информацию в имя метрики не
> запихнешь). InfluxDB вроде как должен их решить.

GO.
что-то меня сомнения гложут

[Eugene Klimov]

https://github.com/klen/graphite-beacon

Такая подойдет? 

[Александр Акулов]

Я полгода назад смотрел все проекты которые перечислены тут http://graphite.readthedocs.org/en/latest/tools.html#monitoring
На тот момент, идея с триггерами в конфиге казалось мне хорошей. Есть ещё подобный проект https://github.com/ybrs/graphite-alerts. Я уже не помню точно, что мне в них не хватило, но мне пришлось писать свои скрипты которые выглядят очень похоже.

Теперь у меня изменились требования, т.к. триггеры должны уметь настраивать много людей, идея с конфигами отпадает.
- Мне нужен хороший веб интерфейс через который видно в каком состоянии находятся триггеры, можно их создавать и редактировать.
- Подписаться на уведомления о срабатывании триггера.

Syeren более-менее подходит, но там проблема, что можно настраивать только пороги. Я не могу взять 2 значения из графита и сравнить их. Или настроить в seyren уведомления если значения из графита, например, не приходят. Мне хочется как у graphite-alerts или beacon прописывать условия, ещё лучше как в zabbix.
Приветствуется возможность задать важность триггера.

Мне предлагали заливать данные из графита в заббикс и в заббиксе навастривают триггеры. Но это идея кажется мне ужасной.

Riemann и shinken не осилил. Я вообще плохо понимаю как они с графитом взаимодействуют. У них своя база данных в которую нужно данные из графита заливать или как?



четверг, 11 декабря 2014 г., 8:56:33 UTC+5 пользователь Eugene Klimov написал:

https://github.com/klen/graphite-beacon

Такая подойдет? 

[Anton Lebedevich]

Не совсем в тему, а на новинку Bosun смотрел кто-нибудь?
http://blog.stackoverflow.com/2014/11/announcing-bosun-our-new-open-source-monitoring-alerting-system/
Меня там порадовало в документации, что можно сделать алерт, который
срабатывает, если тренд пересекает порог слишком скоро (железо пора
закупать)

> <https://github.com/klen/graphite-beacon>
> Такая подойдет?

[Timur Batyrshin]

Буквально сегодня Selectel статью про InfluxDB опубликовал на хабре: http://habrahabr.ru/company/selectel/blog/245515/

Ну и в английском интернете уже некоторое время назад хайп начался насчет него.

среда, 10 декабря 2014 г., 17:39:35 UTC+3 пользователь Slawa Olhovchenkov написал:

[Slawa Olhovchenkov]

On Thu, Dec 11, 2014 at 03:50:21AM -0800, Timur Batyrshin wrote:

> Буквально сегодня Selectel статью про InfluxDB опубликовал на
> хабре: http://habrahabr.ru/company/selectel/blog/245515/
> Ну и в английском интернете уже некоторое время назад хайп начался насчет
> него.

вопрос-то не в хайпе. а как оно потом начнет глючить из-за разных
генетических проблем go.

> среда, 10 декабря 2014 г., 17:39:35 UTC+3 пользователь Slawa Olhovchenkov
> написал:
> >
> > On Wed, Dec 10, 2014 at 02:08:08AM -0800, Timur Batyrshin wrote:
> >
> > > Сразу посоветую посмотреть параллельно с графитом еще в сторону
> > InfluxDB.
> > > У графита, говорят, трудно решаемые проблемы с производительностью
> > > возникают на очень больших масштабах данных (в любом случае на несколько
> > > порядков больших, чем в случае заббикса) + на таком количестве метрик их
> > > становится проблематично группировать (всю информацию в имя метрики не
> > > запихнешь). InfluxDB вроде как должен их решить.
> >
> > GO.
> > что-то меня сомнения гложут
> >
>

> --
> Вы получили это сообщение, поскольку подписаны на группу devopsru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.

> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Anton Lebedevich]

Дело не столько в генетических проблемах, сколько в том, как оно данные
пишет на диск. Сейчас InfluxDB для хранения данных использует leveldb
(или его форки).
http://influxdb.com/blog/2014/06/20/leveldb_vs_rocksdb_vs_hyperleveldb_vs_lmdb_performance.html
Каждый байт, туда записанный, сначала попадает в WAL, потом несколько
раз перезаписывается при compaction на каждом уровне leveldb. Не на SSD
они даже не тестируются.

[Orlovsky Alexander]

четверг, 11 декабря 2014 г., 14:54:34 UTC+3 пользователь Slawa Olhovchenkov написал:

On Thu, Dec 11, 2014 at 03:50:21AM -0800, Timur Batyrshin wrote:

> Буквально сегодня Selectel статью про InfluxDB опубликовал на
> хабре: http://habrahabr.ru/company/selectel/blog/245515/
> Ну и в английском интернете уже некоторое время назад хайп начался насчет
> него.

вопрос-то не в хайпе. а как оно потом начнет глючить из-за разных
генетических проблем go.

расскажите поподробнее

какие "генетические проблемы", вы имеете в виду? 

[Slawa Olhovchenkov]

говорят процесс не прибить.
о том, что tcp конеект порвался -- не узнать.
если всё это правда -- значит очень плохая продуманность языка, будет
постоянная борьба с внутренними проблемами.
или врут?

[Max Lapshin]

У нас в эрливидео необходимость прибить корутину (эрланговский процесс) — один из важнейших механизмов контроля нагрузки. Клиент может подключиться, попросить данные, которые требуют минуту для подготовки и уйти.

Если тут не детектить закрытие сокета и не прибивать процесс, то беда.

[Alex Chistyakov]

2014-12-17 12:47 GMT+03:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:
> On Wed, Dec 17, 2014 at 01:12:40AM -0800, Orlovsky Alexander wrote:
>
>>
>> четверг, 11 декабря 2014 г., 14:54:34 UTC+3 пользователь Slawa Olhovchenkov
>> написал:
>> >
>> > On Thu, Dec 11, 2014 at 03:50:21AM -0800, Timur Batyrshin wrote:
>> >
>> > > Буквально сегодня Selectel статью про InfluxDB опубликовал на
>> > > хабре: http://habrahabr.ru/company/selectel/blog/245515/
>> > > Ну и в английском интернете уже некоторое время назад хайп начался
>> > насчет
>> > > него.
>> >
>> > вопрос-то не в хайпе. а как оно потом начнет глючить из-за разных
>> > генетических проблем go.
>> >
>>
>> расскажите поподробнее
>> какие "генетические проблемы", вы имеете в виду?
>
> говорят процесс не прибить.

А в C, говорят, из обработчика сигнала нельзя сделать надежный форк. Я
сам видел, как человек жаловался!
Осталось понять одно - зачем ему это. И зачем тебе это.

--
SY,
Alex

> о том, что tcp конеект порвался -- не узнать.
> если всё это правда -- значит очень плохая продуманность языка, будет
> постоянная борьба с внутренними проблемами.
> или врут?
>

[Slawa Olhovchenkov]

On Wed, Dec 17, 2014 at 02:08:44PM +0400, Alex Chistyakov wrote:

> 2014-12-17 12:47 GMT+03:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:
> > On Wed, Dec 17, 2014 at 01:12:40AM -0800, Orlovsky Alexander wrote:
> >
> >>
> >> четверг, 11 декабря 2014 г., 14:54:34 UTC+3 пользователь Slawa Olhovchenkov
> >> написал:
> >> >
> >> > On Thu, Dec 11, 2014 at 03:50:21AM -0800, Timur Batyrshin wrote:
> >> >
> >> > > Буквально сегодня Selectel статью про InfluxDB опубликовал на
> >> > > хабре: http://habrahabr.ru/company/selectel/blog/245515/
> >> > > Ну и в английском интернете уже некоторое время назад хайп начался
> >> > насчет
> >> > > него.
> >> >
> >> > вопрос-то не в хайпе. а как оно потом начнет глючить из-за разных
> >> > генетических проблем go.
> >> >
> >>
> >> расскажите поподробнее
> >> какие "генетические проблемы", вы имеете в виду?
> >
> > говорят процесс не прибить.
>
> А в C, говорят, из обработчика сигнала нельзя сделать надежный форк. Я
> сам видел, как человек жаловался!
> Осталось понять одно - зачем ему это. И зачем тебе это.

надежный форк.
окей, саша, я записал.

[Ilya Zharskiy]

У нас на районе все чёткие пацанчеги давно даннопёсом пользуются: http://datadoghq.com/

[Александр Акулов]

Сервисы мониторинга это для хипсеров.

четверг, 19 февраля 2015 г., 20:54:26 UTC+5 пользователь Ilya Zharskiy написал:

[Кирилл Ширинкин]

Есть очень классный доклад как раз про графит, сбор миллиона метрик и все сопутствующие проблемы и, если память не изменяет, ещё и про алертинг там что-то было: https://www.youtube.com/watch?v=hsneYQ8Yn7A Смотрел с большим удовольствием.

вторник, 9 декабря 2014 г., 13:27:44 UTC+1 пользователь Александр Акулов написал:

[Dmitriy Kapusta]

Посмотрите в сторону Cabot:

http://cabotapp.com/use/graphite-checks.html

Умеет алертить как на сами метрики  графита, так и на результат применения графитовских функций к метрикам (avg, группировка, и тд и тп). Возможности большие, мордашка симпатичная. Вместе с каким-нибудь красивым дашбордом (мы используем Графану) заткнёт за пояс и заббикс, и наджиос.

Единсвенный минус - относительно сложен в установке на bare-metal: https://gist.github.com/Gromph/5f4db73b0f38775bc2f0

При желании могу проконсультировать по установке.

четверг, 11 декабря 2014 г., 10:14:00 UTC+3 пользователь Александр Акулов написал:

[Slawa Olhovchenkov]

On Mon, May 18, 2015 at 07:13:33AM -0700, Dmitriy Kapusta wrote:

> Посмотрите в сторону Cabot:
> http://cabotapp.com/use/graphite-checks.html
> Умеет алертить как на сами метрики графита, так и на результат применения
> графитовских функций к метрикам (avg, группировка, и тд и тп). Возможности
> большие, мордашка симпатичная. Вместе с каким-нибудь красивым дашбордом (мы
> используем Графану) заткнёт за пояс и заббикс, и наджиос.

ну как минимум два из этих трех какашки, если уж говорить прямо.
так что читать "заткнет за пояс" несколько смешно.
вот тут, к примеру, про графит http://grisha.org/blog/2015/05/04/recording-time-series/

[Александр Акулов]

Мы остановились на Riemann, он анализирует метрики налету и кажется, что это очень круто.
Только он мне очень тяжело даётся. Никаких внятных статей нету по интеграции, нашёл только эти конфиги, пытаюсь их как нибудь приспособить. https://github.com/guardian/riemann-config

понедельник, 18 мая 2015 г., 19:21:46 UTC+5 пользователь Dmitriy Kapusta написал:

[Dmitriy Kapusta]

Спасибо, не знал про такую проблему. Прочитал с интересом. 

Нас, правда, она не сильно касается - метрики редкие (самые частые - раз в минуту), хранятся без агрегации. Грубо говоря, на графике я вижу каждую точку, которую отсылаю. Агрегируются только совсем старые данные.

Александр, гляньте, всё-таки, на досуге Cabot :) Попадание в ваши запросы почти 100%:

- никаких конфигов (только на этапе установки);

- красивый веб;

- разграничение прав, авторизация, подписки и тд;

- "сложные" условия срабатывания триггеров (сравнение метрик, арифметика значений - возможно почти всё);

понедельник, 18 мая 2015 г., 17:29:53 UTC+3 пользователь Slawa Olhovchenkov написал:

[Slawa Olhovchenkov]

On Mon, May 18, 2015 at 10:42:04AM -0700, Dmitriy Kapusta wrote:

> Спасибо, не знал про такую проблему. Прочитал с интересом.
> Нас, правда, она не сильно касается - метрики редкие (самые частые - раз в
> минуту), хранятся без агрегации. Грубо говоря, на графике я вижу каждую
> точку, которую отсылаю. Агрегируются только совсем старые данные.

ну вот с минутными данными по байтам на интерфейсе и влетают.

[Anton Lebedevich]

Надо не rate (число байтов за минуту), а total (число байт с момента
создания интерфейса) передавать, тогда не влетишь. Rate из total через
positive only diff получается, зато пропуски и слегка промахнувшиеся
по времени данные не так страшны.


Всего,
Антон.

[Slawa Olhovchenkov]

ну передаются-то именно байты

[p.stro...@gmail.com]

Рекомендую посмотреть в сторону sensu, отличный гибкий инструмент, интегрируется с графитом, много плагинов, отлично маштабируется ...

вторник, 9 декабря 2014 г., 18:27:44 UTC+6 пользователь Александр Акулов написал:

[Igor Kochergin]

Получать зпббикс хттп запросом итем из графит апи. А дальше любые тригеры можешь вешать.