ProHoster > блог > Администрација > Лесна работа со сложени предупредувања. Или историјата на создавањето на Балертер

Лесна работа со сложени предупредувања. Или историјата на создавањето на Балертер

Лесна работа со сложени предупредувања. Или историјата на создавањето на Балертер

Секој сака предупредувања.

Се разбира, многу е подобро да бидете известени кога нешто се случило (или е поправено), отколку да седите и да гледате графикони и да барате аномалии.

И многу алатки се создадени за ова. Alertmanager од екосистемот Prometheus и vmalert од групата производи VictoriaMetrics. Известувања и предупредувања на Zabbix во Графана. Само-напишани скрипти во баш и Телеграм-ботови кои периодично повлекуваат одредена URL-адреса и ви кажуваат дали нешто не е во ред. Многу од се.

Ние, во нашата компанија, користевме и различни решенија додека не наидовме на сложеноста или, подобро кажано, на неможноста за создавање сложени, композитни предупредувања. Она што го сакавме и што на крајот го направивме е под сечењето. TLDR: Вака се појави проектот со отворен код Балератор

Доста долго време живеевме добро со сигналите конфигурирани во Графана. Да, ова не е најдобриот начин. Секогаш се препорачува да користите некои специјализирани решенија, како што е Alertmanager. И, исто така, гледавме кон движење повеќе од еднаш. И тогаш, малку по малку, сакавме повеќе.

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

Работите стануваат уште покомплицирани кога одлуката за предупредување мора да се донесе врз основа на податоци од различни извори. Во живо пример:

Ги проверуваме податоците од две бази на податоци на Clickhouse, потоа ги споредуваме со некои податоци од Postgres и одлучуваме за предупредување. Сигнирајте или откажете

Имаме акумулирано доста слични желби за да размислиме за нашата одлука. И тогаш се обидовме да ја составиме првата листа на барања/способности на оваа услуга, која сè уште не е создадена.

  • пристап до различни извори на податоци. На пример, Прометеј, Кликхаус, Постгрес

  • праќајте предупредувања до различни канали - телеграма, лабаво, итн.

  • во процесот на размислување, стана јасно дека не сакам декларативен опис, туку способност да пишувам скрипти

  • водење на скрипти на распоред

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

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

Оваа листа е приближна и најверојатно не е многу точна. Некои точки се сменија, некои умреа. Сè е како и обично.

Всушност, вака започна историјата на Балертер.

Лесна работа со сложени предупредувања. Или историјата на создавањето на Балертер

Ќе се обидам накратко да опишам што се случи на крајот и како функционира. (Да, се разбира, ова не е крајот. Има многу планови за развој на производи. Само ќе застанам на денес)

Како тоа функционира?

Пишуваш скрипта во Луа каде експлицитно испраќаш барања (до Прометеј, Кликхаус итн.). Добивате одговори и некако ги обработувате и споредувате. Потоа вклучете/исклучете некој вид на предупредување. Самиот Balerter ќе испрати известување до каналите што сте ги конфигурирале (email, телеграма, 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 (самата врска е конфигурирана во конфигурацијата)

  • испрати барање до 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 со наведената порака

  • проверете дали предупредувањето за ограничување на вртежи во минута не е оневозможено (успешно)

Што друго може да направи Балертер?

Ќе се обидам да ги допрам најважните, според мене, вештините на Балертер. Сè детално можете да видите на официјалната веб-страница https://balerter.com

  • добиваат податоци од

    • кликхаус

    • postgres

    • mysql

    • прометеј

    • локи

  • испраќајте известувања до каналите

    • гасена

    • телеграма

    • системски лог

    • известувај (Известувања за интерфејс на вашиот компјутер)

    • е-маил

    • раздор

  • градете графикони врз основа на вашите податоци, поставете ја сликата во складиште компатибилно со S3 и прикачете ја на известувањата (Пример со слики)

  • ви овозможува да разменувате податоци помеѓу скрипти - глобално складирање клуч/вредност

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

  • праќајте HTTP барања од вашите скрипти (и добивајте одговори, се разбира)

  • обезбедува API (сè уште не е толку функционален како што би сакале)

  • извозни метрики во формат Прометеј

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

Веќе е јасно дека корисниците и ние сакаме можност да го контролираме стартувањето на скриптите користејќи ја синтаксата cron. Ова ќе се направи пред верзијата v1.0.0

Би сакал да поддржам повеќе извори на податоци и канали за доставување известувања. На пример, на некој дефинитивно ќе му недостасува MongoDB. Еластично пребарување за некои. Испраќајте СМС и/или остварувајте повици на вашиот мобилен телефон. Сакаме да можеме да примаме скрипти не само од датотеки, туку и, на пример, од база на податоци. На крајот, сакаме веб-локација попријатна за корисниците и подобра документација за проектот.

На некој секогаш нешто му недостасува) Овде се потпираме на барањето на заедницата за правилно да ги поставиме приоритетите. И на помош на заедницата да се реализира се

Во заклучок

Ние користиме Балератор Го имам веќе подолго време. Десетици сценарија го чуваат нашиот мир на умот. Се надевам дека ова дело ќе биде корисно за некој друг.

И добредојде со вашето прашање и ПР.

Извор: www.habr.com

Додадете коментар