Про собирание метрик в линуксах

Историческая справка по собиранию метрик в линуксах, маленький кусочек вырванный из грандиозного контекста.

Было куча всего, но потом какие-то чуваки написали Graphite, чтобы сделать собирание метрик удобным для себя. Написали на питоне, что характерно, и сделали его таким удобным, что на него подсела куча народа. Однако он был тормозной, благо его разбили на 3 части: Whisper — хранилище, Carbon — агрегатор, Graphite-web — веб-морда. И короче все 3 тормозили, по разным причинам, но были удобные, чем задали местный стандарт сбора метрик.

И люди ломанулись переписывать Graphite. Не весь, а его части. И не только переписывать, но и писать плагины к другому софту, которые позволяли бы ему как-то взаимодействовать с графитом или заменять одну из его частей. А ещё начали дописывать обёртки.

Сначала некие чуваки решили, что медленно работает Carbon, потому что он получает метрики не пачками, а как придётся. Поэтому написали StatsD (на NodeJS), который это дело оптимизировал и слал меньше запросов Carbon-у. Но (внезапно!), товарищи с Github-а обнаружили что StatsD тоже тормозит, хотя и меньше, поэтому переписали его на C (слава богам), назвали Brubeck, поэтому сбор метрик перестал тормозить. И ни одна из этих команд не удосужилась собрать пакеты хоть для чего-то, потому что они крутые программисты, гитхабовские пацаны вообще чёткие, у них в репозитории даже тегов нет.

Следующей жертвой стала веб-морда, которую позаменяли кто чем мог. Сходу, кроме родного интерфейса гуглятся Grafana, Tessera и Graphene. Каждая со своими уникальными нюансами.

Единственное, что не трогали, это Whisper, наверно потому, что без Carbon-a он никому не нужен. А вот Carbon народ пытается заменять и тут уже начинается хардкор. Почему-то все начали переписывать его на Go, в итоге получилось куча недопиленных поделок, сориентироваться среди которых невозможно. Внезапно, сюда же влезла InfluxDB, которая оказалась ничего такой заменой для Carbon-a и Whisper-а, после чего сам графит уже и не нужен становится.

Однако у InfluxDB свой протокол, а протокол Graphite она поддерживает сбоку, конвертируя его метрики в свои, правила для конвертации нужно прописывать вручную в конфиге. С InfluxDB уже постепенно умеет работать часть софта, писавшегося для Graphite, но опять таки, не полностью и другая часть не работает. Плюс сама InfluxDB ещё очень-очень активно разрабатывается и весь софт за ней не успевает. Выливается всё это в очередь небольших патчей, которые нужно написать, чтобы оно всё заработало.

А ещё есть 100500 сборщиков метрик, каждый из которых живёт собственной жизнью. Встречаются и приколы, вроде подсовывания Graphite rdd файлов (хранилища метрик на диске) от Collectd.

И вот фиг знаешь что с чем использовать. Я пока остановился на двух вариантах:

  1. страшненький, но надёжный: Diamond->Brubeck->Graphite->Grafana
  2. красивенький, но стрёмный: Diamond->Brubeck?->InfluxDB->Grafana

В красивеньком Brubeck под вопросом потому, что я не въезжаю зачем для БД, заточенной под хранение временных серий, нужен дополнительный агрегатор, поскольку в моей картине мира такая БД должна это сама уметь, а если не умеет, то нафиг она нужна. Но сами разработчики InfluxDB удосужились написать доку по взаимодействию со StatsD, поэтому не разберёшь, нужна какая-то предварительная агрегация или не нужна.

В реализацию возьму, видимо. всё-таки страшненький. А когда устаканится, может быть, заменю внутренности на что-то новое.

  • Антон Алексаненков

    Устаканилось чего-нибудь? :)
    А зачем из Diamond в Brubeck сначала класть, а только потом в БД ? Так быстрее или чего?
    Я собираюсь collectd и brubeck параллельно юзать, чтоб все в influx слать, поэтому спрашиваю, вдруг глупость :)

    • Brubeck просто умеет очень быстро собирать очень много метрик. Если это не надо, то можно использовать дефолтный графитовый сборщик. То есть это уже оптимизация.

      Как использовать и brubeck и collectd параллельно не знаю, это немного разные вещи. Может быть такой вариант: collectd/diamond/что-то ещё на хосте шлёт метрики на сервер, где их ловит brubeck/statsd/carbon и они пишут в influx/ещё куда-то

      • Антон Алексаненков

        То есть, я правильно понял, что brubeckstatsd просто проксируют большой поток метрик, чтоб не свалить бд, примерно как Nginx перед gunicorn? :)

        У меня нагрузка совсем небольшая, поэтому в итоге просто включил statsd плагин в уже используемом collectd. Этот collectd стоит локально на хосте с приложением, собирает хардварные метрики хоста и метрики приложения, а потом засылает их в influx на отдельном серваке. Хотя, получается, что в таком случае, можно напрямую в инфлюкс слать метрики приложения…

        • >brubeckstatsd просто проксируют большой поток метрик, чтоб не свалить бд, примерно как Nginx перед gunicorn
          Да, примерно так.

          Если influx умеет понимать формат метрик collectd, то можно сразу на неё слать. По-моему, это ты и делаешь (statsd плагин как раз обеспечивает нужный формат данных для influx, хотя могу и ошибаться).

          В качестве альтернативы могу предложить использовать https://newrelic.com/ или аналогичный сервис, получаешь сразу много плюшек, включая нотификацию. И не надо хостить лишние сервисы у себя.