Трикове за обработка на метрики в Kapacitor

Вероятно, сегодня уже ни у кого не возникает вопрос, зачем собирать метрики сервисов. Следующий логичный шаг – настроить алертинг на собранные метрики, который будет уведомлять о любых отклонениях в данных через удобные вам каналы (почту, Slack, Telegram). В сервисе онлайн-бронирования отелей Ostrovok.ru все метрики наших сервисов собираются в InfluxDB и отображаются в Grafana, там же настроен базовый алертинг. Для задач «нужно посчитать что-то и сравнить с этим» мы используем Kapacitor.

Kapacitor – это часть TICK-стека, который умеет обрабатывать метрики из InfluxDB. Он может объединить несколько измерений (join), из полученных данных вычислить что-то полезное, записать результат обратно в InfluxDB и отправить алерт в Slack/Telegram/почту.

Весь стек имеет отличную и подробную документацията, но всегда найдутся полезные вещи, которые не указаны в мануалах. В этой статье я решил собрать ряд таких полезных неочевидных советов (основной синтаксис TICKscipt описан тук) и показать, как их можно применять, на примере решения одной из наших задач.

Да тръгваме!

float & int, ошибки вычислений

Это абсолютно стандартная проблема, решается через каст:

var alert_float = 5.0
var alert_int = 10
data|eval(lambda: float("value") > alert_float OR float("value") < float("alert_int"))

Использование default()

Если тег/поле не заполнено, возникнут ошибки в вычислениях:

|default()
        .tag('status', 'empty')
        .field('value', 0)

fill в join (inner vs outer)

По умолчанию join отбросит точки, где данных нет (inner).
При fill(‘null’) будет выполнен outer join, после которого нужно сделать default() и заполнить пустые значения:

var data = res1
    |join(res2)
        .as('res1', 'res2)
        .fill('null')
    |default()
        .field('res1.value', 0.0)
        .field('res2.value', 100.0)

Однако есть нюанс. Если в примере выше одна из серий (res1 или res2) будет пустой, итоговая серия (data) также будет пустой. На эту тему есть несколько тикетов на гитхабе (1633, 1871, 6967) – ждем фиксов и немного страдаем.

Использование условий в вычислениях (if в lambda)

|eval(lambda: if("value" > 0, true, false)

Последние пять минут из пайплайна за период

Например, вам нужно сравнить значения последних пяти минут с предыдущей неделей. Можно взять две пачки данных двумя отдельными batch’ами или вытащить часть данных из большего периода:

 |where(lambda: duration((unixNano(now()) - unixNano("time"))/1000, 1u) < 5m)

Алтернативата за последните пет минути може да бъде използването на нодата BarrierNode, която отсява данните по-рано от зададеното време:

|barrier()
        .period(5m)

Примери за използване на Go-шаблони в съобщение

Шаблоните отговарят на формата от пакета text.template, по-долу са няколко често срещани задачки.

if-else

Подреждаме нещата, без да нараняваме хората с текст без нужда:

|alert()
    ...
    .message(
        '{{ if eq .Level "OK" }}Сега е окей{{ else }}Шефе, всичко е разбито{{end}}'
    )

Две цифри след десетичната запетая в съобщение

Подобряваме четимостта на съобщението:

|alert()
    ...
    .message(
        'сега стойността е {{ index .Fields "value" | printf "%0.2f" }}'
    )

Развиваме променливите в съобщение

Извеждаме повече информация в съобщението, за да отговорим на въпроса «Защо крещи?»

var warnAlert = 10
  |alert()
    ...
    .message(
       'Днешната стойност е под '+string(warnAlert)+'%'
    )

Уникален идентификатор на алармата

Необходима вещ, когато в данните има повече от една група, иначе ще се генерира само една аларма:

|alert()
      ...
      .id('{{ index .Tags "myname" }}\/{{ index .Tags "myfield" }}')

Кастомизирани обработващи функции

В голям списък от обработващи функции има exec, което позволява да изпълните свой скрипт с подадените параметри (stdin) – истинско творчество!

Един от нашите кастомизации е малък Python скрипт за изпращане на уведомления в Slack.
Първоначално искахме да изпратим изображение от Grafana, защитено с авторизация, в съобщението. След това – да пишем OK в треда на предишната аларма от същата група, а не в отделно съобщение. По-късно – да добавим в съобщението най-честата грешка за последните X минути.

Отделна тема – свързването с други услуги и каквито и да било действия, инициирани от алармата (само ако вашето наблюдение работи достатъчно добре).
Пример за описание на обработваща функция, където slack_handler.py е нашият собствен скрипт:

topic: slack_graph
id: slack_graph.alert
match: level() != INFO AND changed() == TRUE
kind: exec
options:
  prog: \/sbin\/slack_handler.py
  args: ["-c", "CHANNELID", "--graph", "--search"]

Как да дебъгваме?

Вариант с извеждане в лог

|log()
      .level("error")
      .prefix("нещо")

Да наблюдаваме (cli): kapacitor -url host-or-ip:9092 logs lvl=error

Вариант с httpOut

Показва данни в текущия пайплайн:

|httpOut('нещо')

Да наблюдаваме (get): host-or-ip:9092\/kapacitor\/v1\/tasks\/task_name\/something

Схема на изпълнение

• Всяка задача връща дърво на изпълнението с полезни цифри във формат graphviz.
• Взимаме блок dot.
• Вмъкваме в viewer, наслаждаваме се.

Къде още можем да получим timestamp в influxdb при обратно записване?

timestamp в influxdb при обратно записване

Например, настройваме аларма за сумата на заявките на час (groupBy(1h)) и искаме да запишем възникналата аларма в influxdb (за да покажем наличието на проблем на графиката в grafana).

influxDBOut() ще запише в timestamp стойността time от алармата, в съответствие с това, точката на графиката ще бъде записана по-рано/по-късно, отколкото е дошла алармата.

Когато е необходима точност: заобикаляме този проблем чрез извикване на персонализиран хендлер, който ще запише данните в influxdb с текущия timestamp.

docker, изграждане и деплой

При стартиране kapacitor може да зарежда задачи, шаблони и хендлери от директорията, указана в конфигурацията, в блока [load].

За коректно създаване на задача са необходими следните неща:

1. Име на файла – разгръща се в id/име на скрипта.
2. Тип – stream/batch
3. dbrp – ключова дума за указване в коя база + политика работи скриптът (dbrp «supplier».«autogen»).

Ако в някаква batch-задача не има ред с dbrp, целият сервис ще откаже да стартира и честно ще напише за това в логовете.

В chronograf, напротив, този ред не трябва да съществува, защото не се приема през интерфейса и дава грешка.

Хак при изграждането на контейнера: Dockerfile излиза с -1, ако има редове с //.+dbrp, което веднага ще позволи да се разбере причината за сбоя при изграждането на билд.

join един към много

Задача-пример: трябва да вземем 95-ти перцентил на времето за работа на услугата за седмица, да сравним всяка минута от последните 10 с това значение.

Не може да се направи join един към много, last/mean/median по група точки превръщат нодата в stream, ще се върне грешка «cannot add child mismatched edges: batch -> stream».

Резултатът от batch-а, като променлива в lambda-израза, също не се подставя.

Има вариант да се запазят нужните цифри от първия batch в файл чрез udf и да се зареди този файл чрез sideload.

Какво решаваме с това?

Имаме около 100 доставчици на хотели, към всеки от тях може да има няколко свързвания, да ги наречем канали. Тези канали са около 300, всеки от каналите може да се провали. От всички записвани метрики ще следим процента на грешките (requests и errors).

Защо не графана?

Алармите за грешки, конфигурирани в графана, имат няколко минуса. Някои от тях са критични, на други може да затворим очи, в зависимост от ситуацията.

Графана не може да изчислява между измерванията + алармиране, а на нас ни е нужен процентът (requests-errors)/requests.

Грешките изглеждат злонамерено:

И по-малко злонамерено, ако гледаме с успешните заявки:

Добре, можем предварително да изчислим ставката в услугата преди графана, и в някои случаи това ще е достатъчно. Но не в нашия случай, тъй като за всеки канал се изчислява «нормално» съотношение, а алармите работят на статични стойности (търсим на око, сменяме, ако алармира често).

Ето примери за «нормално» за различни канали:

Пренебрегваме предишната точка и предполагаме, че при всички доставчици «нормалната» ситуация е подобна. Сега всичко е добре, можем ли да се справим с алармите в графана?
Можем, но не искаме, защото трябва да изберем един от вариантите:
а) да направим множество графики за всеки канал поотделно (и мъчително да ги поддържаме)
б) да оставим една графика с всички канали (и да се загубим в цветните линии и настроените аларми)

Какво направихме?

Отново, в документацията има добър начален пример (Изчисляване на ставки за обединени серии), можем да хвърлим поглед или да го вземем за основа при аналогични задачи.

Какво направихме в крайна сметка:

• обединение на две серии за няколко часа, групиране по канали;
• попълваме сериите по групи, ако няма данни;
• сравняваме медианата от последните 10 минути с предишните данни;
• крещим, ако нещо е открито;
• пишем изчислените ставки и станалите аларми в influxdb;
• изпращаме полезно съобщение в slack.

На мое мнение, успяхме да постигнем максимално красиво всичко, което искахме да получим на изхода (и дори малко повече с персонализирани обработвачи).

На github.com можете да видите примерен код и минимална схема (graphviz) на получения скрипт.

Пример на получения код:

dbrp "supplier"."autogen" var name = 'requests.rate' var grafana_dash = 'pczpmYZWU/mydashboard' var grafana_panel = '26' var period = 8h var todayPeriod = 10m var every = 1m var warnAlert = 15 var warnReset = 5 var reqQuery = 'SELECT sum("count") AS value FROM "supplier"."autogen"."requests"' var errQuery = 'SELECT sum("count") AS value FROM "supplier"."autogen"."errors"' var prevErr = batch |query(errQuery) .period(period) .every(every) .groupBy(1m, 'channel', 'supplier') var prevReq = batch |query(reqQuery) .period(period) .every(every) .groupBy(1m, 'channel', 'supplier') var rates = prevReq |join(prevErr) .as('req', 'err') .tolerance(1m) .fill('null') |default() .field('err.value', 0.0) .field('req.value', 0.0) |eval(lambda: if("err.value" > 0, 100.0 * (float("req.value") - float("err.value")) / float("req.value"), 100.0)) .as('rate') rates |influxDBOut() .quiet() .create() .database('kapacitor') .retentionPolicy('autogen') .measurement('rates') var todayRate = rates |where(lambda: duration((unixNano(now()) - unixNano("time")) / 1000, 1u)  warnAlert) .warnReset(lambda: ("prev.median" - "today.median") < warnReset) .flapping(0.25, 0.5) .stateChangesOnly() .message('{{ .Level }}: {{ index .Tags "channel" }} err/req ratio ({{ index .Tags "supplier" }}) {{ if eq .Level "OK" }}It is ok now{{ else }} median за ' + string(todayPeriod) + ' е {{ index .Fields "today.median" | printf "%0.2f" }}%, спрямо предишния ' + string(period) + ' е {{ index .Fields "prev.median" | printf "%0.2f" }}%{{ end }} http://grafana.ostrovok.in/d/' + string(grafana_dash) + '?var-supplier={{ index .Tags "supplier" }}&var-channel={{ index .Tags "channel" }}&panelId=' + string(grafana_panel) + '&fullscreen&tz=UTC0300') .id('{{ index .Tags "name" }} /{{ index .Tags "channel" }}') .levelTag('level') .messageField('message') .durationField('duration') .topic('slack_graph') trigger |eval(lambda: "today.median") .as('value') .keep() |influxDBOut() .quiet() .create() .database('kapacitor') .retentionPolicy('autogen') .measurement('alerts') .tag('alertName', name)

Какъв е изходът?

Kapacitor отлично може да извършва мониторинг и алармиране с множество групировки, да извършва допълнителни изчисления върху вече записаните метрики, да извършва персонализирани действия и да стартира скриптове (udf).

Прагът за влизане не е много висок – опитайте го, ако Grafana или други инструменти не удовлетворяват напълно вашите нужди.

Източник: habr.com