Про собирание метрик в линуксах
Историческая справка по собиранию метрик в линуксах, маленький кусочек вырванный из грандиозного контекста.
Было куча всего, но потом какие-то чуваки написали 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.
И вот фиг знаешь что с чем использовать. Я пока остановился на двух вариантах:
- страшненький, но надёжный: Diamond->Brubeck->Graphite->Grafana
- красивенький, но стрёмный: Diamond->Brubeck?->InfluxDB->Grafana
В красивеньком Brubeck под вопросом потому, что я не въезжаю зачем для БД, заточенной под хранение временных серий, нужен дополнительный агрегатор, поскольку в моей картине мира такая БД должна это сама уметь, а если не умеет, то нафиг она нужна. Но сами разработчики InfluxDB удосужились написать доку по взаимодействию со StatsD, поэтому не разберёшь, нужна какая-то предварительная агрегация или не нужна.
В реализацию возьму, видимо. всё-таки страшненький. А когда устаканится, может быть, заменю внутренности на что-то новое.
Читать далее
- Модная типизация в Python
- Опыт использования Julia
- Генерация подземелий — от простого к сложному
- Автоматический генератор квестов
- World Builders 2023: Предпочтения игроков в стратегии
- Миграции backend на практике
- Типы в Python не радуют
- Open source сервисы аутентификации
- Обновил конфиги Emacs
- Открываем лор Сказки под лицензией CC BY 4.0