Comments 11
Чем он лучше statsite?
Вы статью вообще не читали? Отказались от event-loop архитектуры, тк в таком проекте она бесполезна, idle не бывает.
По ссылке используется libevent github.com/armon/statsite/blob/master/src/networking.c#L30
По ссылке используется libevent github.com/armon/statsite/blob/master/src/networking.c#L30
Не пробовали github.com/lomik/go-carbon?
Это всё же уже после агрегации, проблема была именно в сборе метрик.
о сборе метрик недавно пролетало github.com/vimeo/statsdaemon
Из statsd можно собрать кластер при помощи вот этого: github.com/hulu/statsd-router
Есть еще Heka hekad.readthedocs.org/en/v0.9.2 — не знаю, на сколько производительный, но он еще и logstash заменяет.
А вообще, не совсем понятно, зачем агрегировать метрики со всех серверов на одном бедном statsd/brubeck/whatever? Мы держим statsd на каждом сервере, агрегируем на месте и складываем оттуда напрямую в графит. Проблем с произвотидельностью statsd не было, даже на балансерах, где проскакивает 2600 метрик в секунду. Не 4.3 миллиона, конечно, но у нас столько и не будет никогда с одного сервера.
Один общий statsd/аналог следует держать рядышком для подсчета гистограм/персентилей, ибо их нужно агрегировать в одном месте. «Гистограммные» метрики — это около 5% от всех наших метрик, что пишем. Так что, statsd там тоже хватит.
Один общий statsd/аналог следует держать рядышком для подсчета гистограм/персентилей, ибо их нужно агрегировать в одном месте. «Гистограммные» метрики — это около 5% от всех наших метрик, что пишем. Так что, statsd там тоже хватит.
Каким образом у вас одни метрики идут на локальный statsd, а другие на общий? Это логика вашего приложения и вы используете разные адреса для разных метрик?
Сейчас никак, мы только планируем это делать. Сейчас у нас персентили считает каждый сервер сам по себе, что не совсем удобно, когда хочется посмотреть общую картину. Тут есть несколько вариантов:
1. Проксировать «персентильные» метрики конвенционально по имени (скажем, если есть суффикс «histogram»)
2. На уровне конфига statsd/аналога перечислять список метрик (возможно, со звездочками) которые пойдут на центральную считалку. Тут Heka выглядит более удобным инструментом для таких дел. Поскольку помимо метрик если еще и логи, которые тоже нужно доставлять, а с Хекой их еще можно сразу превращать и в метрики за компанию.
3. В логике приложения я бы этого не делал. У нас несколько десятков сервисов на разных языках, работают над ними разные команды. Данную логику лучше инкапсулировать на уровне платформы и протокола, чтобы минимизировать риск что-то сделать не так. Суффикс «histogram» кажется приемлемым компромиссом.
1. Проксировать «персентильные» метрики конвенционально по имени (скажем, если есть суффикс «histogram»)
2. На уровне конфига statsd/аналога перечислять список метрик (возможно, со звездочками) которые пойдут на центральную считалку. Тут Heka выглядит более удобным инструментом для таких дел. Поскольку помимо метрик если еще и логи, которые тоже нужно доставлять, а с Хекой их еще можно сразу превращать и в метрики за компанию.
3. В логике приложения я бы этого не делал. У нас несколько десятков сервисов на разных языках, работают над ними разные команды. Данную логику лучше инкапсулировать на уровне платформы и протокола, чтобы минимизировать риск что-то сделать не так. Суффикс «histogram» кажется приемлемым компромиссом.
А есть где-то мануал, как все поставить с нуля, включая агентов и вебинтерфейс?
Sign up to leave a comment.
Brubeck — быстрый, statsd-совместимый агрегатор метрик от GitHub