ProHoster > блог > адміністраванне > Лёгкая праца са складанымі алертамі. Або гісторыя стварэння Balerter

Лёгкая праца са складанымі алертамі. Або гісторыя стварэння Balerter

Лёгкая праца са складанымі алертамі. Або гісторыя стварэння Balerter

Усе любяць алерты.

Вядома, значна лепш атрымаць апавяшчэнне калі нешта адбылося (ці паправілася), чым сядзець, глядзець на графікі і шукаць анамаліі.

І інструментаў для гэтага створана нямала. Alertmanager з экасістэмы Prometheus і vmalert з групы прадуктаў VictoriaMetrics. Апавяшчэнні zabbix і алерты ў Grafana. Самапісныя скрыпты на bash і Telegram боты, якія перыядычна тузаюць нейкі URL і кажуць, калі нешта не так. Шмат усяго.

Мы, у нашай кампаніі, таксама выкарыстоўвалі розныя рашэнні, пакуль не ўперліся ў складанасць, ці, хутчэй, немагчымасць стварэння складаных, складовых алертаў. Чаго нам хацелася і што ў выніку зрабілі - пад катом. TLDR: Так з'явіўся open source праект Balerter

Даволі доўга мы нядрэнна жылі з алертамі, настроенымі ў Grafana. Так, гэта не лепшы шлях. Заўсёды рэкамендуецца выкарыстоўваць нейкія спецыялізаваныя рашэнні, накшталт Alertmanager. І мы таксама неаднаразова глядзелі ў бок пераезду. А потым, паціху, нам захацелася большага.

Сказаць, калі нейкі графік упаў/вырас на XX% і знаходзіцца там ужо N хвілін у параўнанні з папярэднім перыядам у M гадзін? Гэта, здаецца, можна паспрабаваць рэалізаваць з Grafana ці Alertmanager, але даволі не проста. (А можа і нельга, я зараз і не скажу)

Усё становіцца яшчэ складаней, калі рашэнне аб алерце трэба прыняць на аснове дадзеных з розных крыніц. Жывы прыклад:

Правяраем дадзеныя з двух баз Clickhouse, далей параўноўваем з некаторымі дадзенымі з Postgres, і прыманы рашэнне аб алерце. Сігналізаваць ці адмяніць

Падобных жаданак у нас назапасілася дастаткова шмат, каб мы задумаліся аб сваім рашэнні. І тады паспрабавалі скласці першы спіс патрабаванняў/магчымасцяў гэтага, не створанага пакуль, сэрвісу

  • звяртацца да розных крыніц даных. Напрыклад, Prometheus, Clickhouse, Postgres

  • адпраўляць алерты ў розныя каналы - telegram, slack і г.д.

  • у працэсе абдумвання стала зразумела, што хочацца не дэкларатыўнага апісання, а магчымасці пісаць скрыпты.

  • запуск скрыптоў па раскладзе

  • лёгкае абнаўленне скрыптоў без перазапуску сэрвісу

  • магчымасць неяк пашыраць функцыянал без перазборкі сэрвісу з зыходных кодаў

Гэта спіс узорны і, хутчэй за ўсё, не вельмі дакладны. Нейкія пункты відазмяняліся, нейкія паміралі. Усё як звычайна.

Уласна, менавіта так пачалася гісторыя Balerter.

Лёгкая праца са складанымі алертамі. Або гісторыя стварэння Balerter

Паспрабую апісаць сцісла, што ў выніку атрымалася і як гэта працуе. (Так, вядома, гэта не фінал. Шмат планаў для развіцця прадукта. Я проста спынюся на сённяшнім дні)

Як гэта працуе?

Вы пішыце скрыпт на Lua, дзе відавочна адпраўляеце запыты (у Prometheus, Clickhouse і т.д). Атрымліваеце адказы і неяк іх апрацоўваеце і параўноўваеце. Пасля чаго ўключаеце/выключаеце нейкі алерт. Balerter сам адправіць апавяшчэнне ў каналы, якія вы наладзілі (Email, telegram, 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, для адлюстравання ў логах, для выкарыстання ў тэстах)

  • падлучальны модуль для вываду логаў

  • падлучальны модуль для доступу да клікхаўса з імем ch1 (само падключэнне наладжваецца ў канфігу)

  • адпраўляем запыт у клікхаус

  • у выпадку памылкі - выводзім паведамленне ў лог і выходзім

  • параўноўваем вынік запыту з канстантай (у жывым прыкладзе мы маглі б гэтае значэнне атрымліваць, напрыклад, з базы 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')

Па кроках:

  • паказваем імя скрыпту, для якога напісаны тэст

  • імя цеста (для логаў)

  • падключаем модуль тэсціравання

  • кажам, які вынік трэба вярнуць пры вызначаным запыце да клікхаўса ch1

  • правяраем, што быў выкліканы алерт (error) rps-min-limit з указаным паведамленнем

  • правяраем, што алерт rps-min-limit не быў адключаны (success)

Што яшчэ ўмее Balerter?

Я паспрабую закрануць самых важных, па ім меркаванню, уменнях Balerter. Падрабязна ўсё паглядзець можна на афіцыйным сайце https://balerter.com

  • атрымліваць дадзеныя з

    • Clickhouse

    • Postgres

    • MySQL

    • праметэя

    • Локі

  • адпраўляць апавяшчэння да каналы

    • слабіну

    • тэлеграма

    • сістэмны часопіс

    • notiify (UI апавяшчэння на вашым кампутары)

    • электронная пошта

    • разлад

  • будаваць графікі па вашых дадзеных, загружаць малюнак у S3 сумяшчальнае сховішча і прымацоўваць да апавяшчэнняў (Прыклад з карцінкамі)

  • дазваляе абменьвацца дадзенымі паміж скрыптамі - глабальнае Key/Value сховішча

  • пісаць свае біблітэкі на Lua і выкарыстоўваць іх у скрыптах (па-змаўчанні пастаўляюцца lua-бібліятэкі для працы з json, csv)

  • адпраўляць HTTP запыты з вашых скрыптоў (ну і атрымліваць адказы, зразумела)

  • падае API (пакуль яшчэ не такое функцыянальнае, як хацелася б)

  • экспартуе метрыкі ў фармаце Prometheus

А што хацелася б умець яшчэ?

Ужо зразумела, што карыстачы і мы жадаем магчымасць кіраваць запускам скрыптоў з дапамогай сінтаксісу крон. Гэта будзе зроблена да версіі v1.0.0

Жадаецца падтрымаць больш крыніц дадзеных і каналаў дастаўкі апавяшчэнняў. Напрыклад, камусьці сапраўды не будзе хапаць MongoDB. Камусьці Elastic Search. Адпраўляць SMS і/ці рабіць дазвон на мабільны. Жадаем умець атрымліваць скрыпты не толькі з файлаў, але і, напрыклад, з базы дадзеных. У рэшце рэшт жадаем для праекту зручнейшы сайт і добрую дакументацыю.

Заўсёды камусьці чагосьці не хапае) Тут мы спадзяемся на запыт суполкі, каб правільна выбудаваць прыярытэты. І на дапамогу супольнасці, каб усё рэалізаваць

У заключэнне

мы выкарыстоўваем Balerter у сябе ўжо даўнавата. Дзесяткі скрыптоў стаяць на варце нашага спакою. Спадзяюся, гэтая праца стане карысная камусьці яшчэ.

І сардэчна запрашаем з вашымі Issue і PR.

Крыніца: habr.com

Дадаць каментар