amarao (amarao_san) wrote,
amarao
amarao_san

Category:

kapacitor: хадуп в стакане воды

Возня с influx/telegraf/kapacitor распределяется таким образом:

influx: ряд сложных идей требующих осмысленя, путаница между полями и тегами, недо-sql с которым надо учиться сживаться. На самом деле он просто DSL, а под SQL мимикрирует.

telegraf - совершенно скучная правильно работающая программа. Что сказали, то и делает. При хоть каком-то понимании influx'а вообще не требует специального внимания.

kapacitor - и тут открываются бездны. Дело даже не в том, что внутри kapacitor'овых скриптов путаница из трёх скриптовых языков (это дефекты дизайна и они не смертельные). Проблема в том, что kapacitor - это парадигма программирования, правильная и интересная, но совершенно чужеродная императивно-функциональному мозгу.

Всё программирование происходит на pipeline'ах, которые формируются посредством группировки входящих данных и обработки этих данных "нодами" (активными сущностями в DSL) капаситора. До тех пор, пока программирование идёт в форме дерева (точнее, леса деревьев) - это довольно разумно ложится на классический map/reduce плюс чуток функций второго порядка. В современной экосистеме программирования довольно интуитивно, и не вызвает никаких вопросов.

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

Эта модель строго соответствует предметной области (метрики мониторинга распределённых систем), и в какой-то части похожи на проблемы обычного мониторинга (ака nagios).

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

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

Изучение капаситора состоит из 10% изучения его языков программирования, 10% изучения его как сервиса, и 10% изучения списка его нод и их свойств, и 70% осознания проблемности этой области обработки данных.
Tags: kapacitor, мониторинг, системное администрирование
Subscribe

  • btrfs'ное

    Начинаю подумывать, не перетащить ли мне мой incoming (который сейчас на JBOD'ном LVM'е) на аналогичный, но в виде BTRFS. Плюсы очевидные - простой…

  • btrfs @ degrade

    Не очень эргономично. При замене диска нужно сначала смонтировать в деградировавшем режиме, потом добавить замену, и потом только удалить missing.…

  • btrfs WTFs

    # btrfs device add /dev/sdp1 /media/JBOD ERROR: error adding the device '/dev/sdp1' - Invalid argument Reason: [73866.037363] btrfs: dev…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 8 comments