influx: ряд сложных идей требующих осмысленя, путаница между полями и тегами, недо-sql с которым надо учиться сживаться. На самом деле он просто DSL, а под SQL мимикрирует.
telegraf - совершенно скучная правильно работающая программа. Что сказали, то и делает. При хоть каком-то понимании influx'а вообще не требует специального внимания.
kapacitor - и тут открываются бездны. Дело даже не в том, что внутри kapacitor'овых скриптов путаница из трёх скриптовых языков (это дефекты дизайна и они не смертельные). Проблема в том, что kapacitor - это парадигма программирования, правильная и интересная, но совершенно чужеродная императивно-функциональному мозгу.
Всё программирование происходит на pipeline'ах, которые формируются посредством группировки входящих данных и обработки этих данных "нодами" (активными сущностями в DSL) капаситора. До тех пор, пока программирование идёт в форме дерева (точнее, леса деревьев) - это довольно разумно ложится на классический map/reduce плюс чуток функций второго порядка. В современной экосистеме программирования довольно интуитивно, и не вызвает никаких вопросов.
Как только у нас из леса деревьев начинает образовываться граф (например, мы хотим агрегированные данные по "веткам" дерева), или мы сливаем вместе разные деревья, в этот момент мы попадаем на модель "графов с понятием времени для нод". Я даже не могу придумать ёмкое название. Суть состоит в том, что состояние данных при прохождении в графе может быть синхронным (и тогда нам гарантируются нормальные свойства графа), а может быть асинхронным, в этой ситуации у нас на месте части "соседних" данных может быть кукиш разной формы.
Эта модель строго соответствует предметной области (метрики мониторинга распределённых систем), и в какой-то части похожи на проблемы обычного мониторинга (ака nagios).
Однако, в обычном мониторинге эти проблемы купируются скудностью взаимодействия между данными.
В kapacitor'е мы имеем полноценный язык, поноценную среду манипуляции этими данными, и мы огребаем всю сложность предметной области как только пытаемся придумать что-то нетривиальное.
Изучение капаситора состоит из 10% изучения его языков программирования, 10% изучения его как сервиса, и 10% изучения списка его нод и их свойств, и 70% осознания проблемности этой области обработки данных.
