Лесна работа със сложни сигнали. Или историята на създаването на Balerter

Всеки обича сигналите.

Разбира се, много по-добре е да бъдете уведомявани, когато нещо се е случило (или е коригирано), отколкото да седите и да гледате графиките и да търсите аномалии.

И за това са създадени много инструменти. Alertmanager от екосистемата Prometheus и vmalert от продуктовата група VictoriaMetrics. Известия и сигнали на Zabbix в Grafana. Самонаписани скриптове в bash и ботове на Telegram, които периодично извличат някои URL и ви казват, ако нещо не е наред. От всичко по много.

Ние, в нашата компания, също използвахме различни решения, докато не се натъкнахме на сложността, или по-скоро на невъзможността за създаване на сложни, комбинирани сигнали. Това, което искахме и което в крайна сметка направихме, е под разфасовката. TLDR: Ето как се появи проектът с отворен код Balerter

Доста дълго време живеехме добре с аларми, конфигурирани в Grafana. Да, това не е най-добрият начин. Винаги се препоръчва използването на някои специализирани решения, като например Alertmanager. И ние също погледнахме към преместване повече от веднъж. И тогава малко по малко искахме повече.

Да кажем, когато дадена диаграма е паднала/увеличила с XX% и е била там за N минути в сравнение с предишния период от M часа? Изглежда, че можете да опитате да приложите това с Grafana или Alertmanager, но не е съвсем лесно. (Или може би не е възможно, няма да кажа сега)

Нещата стават още по-сложни, когато решението за предупреждение трябва да се вземе въз основа на данни от различни източници. Пример на живо:

Проверяваме данните от две бази данни на Clickhouse, след което ги сравняваме с някои данни от Postgres и вземаме решение за предупреждение. Сигнал или отказ

Натрупахме доста подобни желания, за да обмислим решението си. И тогава се опитахме да съставим първия списък с изисквания/възможности на тази услуга, който все още не е създаден.

• достъп до различни източници на данни. Например Prometheus, Clickhouse, Postgres

• изпращане на сигнали до различни канали - telegram, slack и др.

• в процеса на мислене стана ясно, че не искам декларативно описание, а възможност за писане на скриптове

• изпълнение на скриптове по график

• лесно актуализиране на скриптове без рестартиране на услугата

• способността по някакъв начин да се разшири функционалността, без да се възстановява услугата от изходните кодове

Този списък е приблизителен и най-вероятно не е много точен. Някои точки се промениха, други умряха. Всичко е както обикновено.

Всъщност така започва историята на Balerter.

Ще се опитам да опиша накратко какво се случи в крайна сметка и как работи. (Да, разбира се, това не е краят. Има много планове за развитие на продуктите. Ще спра до днес)

Как действа тя?

Вие пишете скрипт в Lua, където изрично изпращате заявки (до Prometheus, Clickhouse и т.н.). Получавате отговори и по някакъв начин ги обработвате и сравнявате. След това включете/изключете някакъв вид предупреждение. Самият Balerter ще изпрати известие до каналите, които сте конфигурирали (имейл, телеграма, slack и т.н.). Скриптът се изпълнява на определени интервали. И... като цяло, това е всичко)

Най-добре е да покажете с пример:

-- @interval 10s
-- @name script1

local minRequestsRPS = 100

local log = require("log")
local ch1 = require("datasource.clickhouse.ch1")

local res, err = ch1.query("SELECT sum(requests) AS rps FROM some_table WHERE date = now()")
if err ~= nil then
    log.error("clickhouse 'ch1' query error: " .. err)
    return
end

local resultRPS = res[1].rps

if resultRPS < minResultRPS then
    alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end 

Какво става тук:

• посочваме, че този скрипт трябва да се изпълнява на всеки 10 секунди

• посочете името на скрипта (за API, за показване в регистрационни файлове, за използване в тестове)

• свържете модула за извеждане на логове

• свържете модул за достъп до clickhouse с името ch1 (самата връзка е конфигурирана в конфигурацията)

• изпратете заявка до clickhouse

• в случай на грешка показваме съобщение в дневника и излизаме

• сравнете резултата от заявката с константа (в пример на живо можем да получим тази стойност, например, от базата данни на Postgres)

• активиране или деактивиране на предупреждение с ID rps-min-limit

• ще получите известие, ако състоянието на предупреждението се е променило

Примерът е доста прост и разбираем. Въпреки това, разбира се, в реалния живот сценариите могат да бъдат доста дълги и сложни. Лесно е да се объркате и да направите грешки.

Затова е узряло едно логично желание - да можете да пишете тестове за вашите скриптове. И във версия v0.4.0 това се появи.

Тестване на скриптове

Примерен тест за нашия скрипт от горния пример:

-- @test script1
-- @name script1-test

test = require('test')

local resp = {
    {
        rps = 10
    }
} 

test.datasource('clickhouse.ch1').on('query', 'SELECT sum(requests) AS rps FROM some_table WHERE date = now()').response(resp)

test.alert().assertCalled('error', 'rps-min-limit', 'Requests RPS are very small: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')

Стъпка по стъпка:

• посочете името на скрипта, за който е написан тестът

• име на тест (за регистрационни файлове)

• свържете тестовия модул

• казваме какъв резултат трябва да бъде върнат за конкретна заявка към clickhouse ch1

• проверяваме дали предупреждението (грешка) rps-min-limit с указаното съобщение е извикано

• проверете дали предупреждението за rps-min-limit не е деактивирано (успех)

Какво друго може да направи Balerter?

Ще се опитам да засегна най-важните, според мен, умения на Balerter. Можете да видите всичко подробно на официалния сайт https://balerter.com

• получават данни от

  • clickhouse

  • Postgres

  • MySQL

  • прометей

  • Локи

• изпращане на известия до канали

  • застой

  • телеграма

  • Syslog

  • уведомяване (известия от потребителския интерфейс на вашия компютър)

  • електронна поща

  • раздор

• изградете графики въз основа на вашите данни, качете изображението в съвместимо с S3 хранилище и го прикачете към известията (Пример със снимки)

• ви позволява да обменяте данни между скриптове - глобално съхранение на ключ/стойност

• напишете свои собствени библиотеки в Lua и ги използвайте в скриптове (по подразбиране lua библиотеките се предоставят за работа с json, csv)

• изпращайте HTTP заявки от вашите скриптове (и получавате отговори, разбира се)

• предоставя API (все още не е толкова функционален, колкото бихме искали)

• експортира показатели във формат Prometheus

Какво друго бихте искали да можете да правите?

Вече е ясно, че потребителите и ние искаме възможността да контролираме стартирането на скриптове, използвайки синтаксиса Cron. Това ще бъде направено преди версия v1.0.0

Бих искал да поддържам повече източници на данни и канали за доставка на известия. Например, някой със сигурност ще пропусне MongoDB. Еластично търсене за някои. Изпращайте SMS и/или провеждайте обаждания до мобилния си телефон. Искаме да можем да получаваме скриптове не само от файлове, но и например от база данни. В крайна сметка искаме по-удобен за потребителя уебсайт и по-добра документация за проекта.

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

В заключение

Ние използваме Balerter Имам го от доста време. Десетки скриптове пазят спокойствието ни. Надявам се тази работа да бъде полезна и на някой друг.

И добре дошли с вашия проблем и PR.

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