🥇Enostavno delo s kompleksnimi opozorili. Ali zgodba o ustvarjanju Balerter

Vsi imajo radi opozorila.

Seveda je veliko bolje prejeti obvestilo, ko se je nekaj zgodilo (ali popravilo), kot pa sedeti in gledati grafikon ter iskati anomalije.

Zato je bilo ustvarjenih precej orodij. Alertmanager iz ekosistema Prometheus in vmalert iz skupine izdelkov VictoriaMetrics. Obvestila zabbix in opozorila v Grafani. Lastni skripti na bashu in Telegram boti, ki občasno pokličejo nek URL in povedo, če je kaj narobe. Veliko vsega.

Tudi v naši družbi smo uporabljali različne rešitve, dokler nismo naleteli na zapletenost, ali bolje rečeno, nemogočnost ustvarjanja zapletenih, sestavljenih opozoril. Kaj smo želeli in kaj smo na koncu naredili — pod zavihkom. TLDR: Tako se je pojavil open source projekt Balerter

Dolgo časa smo dobro shajali z opozorili, nastavljenimi v Grafani. Da, to ni najboljša pot. Vedno je priporočljivo uporabljati kakšne specializirane rešitve, kot je Alertmanager. Tudi mi smo večkrat razmišljali o selitvi. Nato pa smo počasi želeli več.

Reči, kdaj je nek grafikon padel/rasel za XX% in je tam že N minut v primerjavi s prejšnjim obdobjem v M urah? To se zdi možno poskusiti uresničiti z Grafano ali Alertmanagerjem, vendar ni povsem enostavno. (Mogoče pa tudi ne morem povedati zdaj)

Vse postane še bolj zapleteno, ko je treba odločitev o opozorilu sprejeti na podlagi podatkov iz različnih virov. Živ primer:

Preverjamo podatke iz dveh baz Clickhouse, nato jih primerjamo z nekaterimi podatki iz Postgresa in sprejmemo odločitev o opozorilu. Signalizirati ali preklicati

Takšnih želja smo nabrali dovolj, da smo začeli razmišljati o svoji rešitvi. Tako smo poskusili sestaviti prvi seznam zahtev/od možnosti te, še ne ustvarjene, storitve

dostopati do različnih virov podatkov. Na primer, Prometheus, Clickhouse, Postgres
pošiljati opozorila v različne kanale — telegram, slack itd.
med razmišljanjem je postalo jasno, da si želimo ne deklarativnega opisa, ampak možnosti pisanja skriptov
zagon skriptov po urniku
enostavno posodabljanje skriptov brez ponovnega zagona storitve
možnost razširiti funkcionalnost brez ponovnega sestavljanja storitve iz izvorne kode

To je okvirni seznam in verjetno ni zelo natančen. Nekatere točke so se spremenile, druge so odpovedane. Vse kot ponavadi.

Tako se je pravzaprav začela zgodba Balerter.

Poskusil bom na kratko opisati, kaj smo na koncu dobili in kako to deluje. (Seveda, to ni konec. Opravil imamo še veliko načrtov za razvoj izdelka. Preprosto se bom ustavil pri današnjem dnevu.)

Kako deluje?

Napišete skript v Lua, kjer izrecno pošiljate poizvedbe (v Prometheus, Clickhouse itd.). Prejmete odgovore in jih nekako obdelate ter primerjate. Nato vklopite/izklopite določen alarm. Balerter bo sam poslal obvestilo v kanale, ki ste jih nastavili (Email, Telegram, Slack itd.). Skript se izvaja v vnaprej določenih časovnih intervalih. In... to je vse)

Najbolje bo pokazati na primeru:

-- @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 < minRequestsRPS then
    alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end

Kaj se dogaja tukaj:

natančno določamo, da se ta skript izvaja vsakih 10 sekund
določamo ime skripta (za API, za prikaz v dnevnikih, za uporabo v testih)
naložimo modul za izpis dnevnikov
naložimo modul za dostop do Clickhouse z imenom ch1 (samo povezovanje se nastavi v konfiguraciji)
pošljemo poizvedbo v Clickhouse
v primeru napake - prikažemo sporočilo v dnevniku in izstopimo
primerjamo rezultat poizvedbe s konstantno (v realnem primeru bi to vrednost lahko dobili, na primer, iz baze Postgres)
vključimo ali izključimo alarm z ID-jem rps-min-limit
prejeli boste obvestilo, če se status alarma spremeni

Primer je precej preprost in razumljiv. Vendar pa so v resničnem življenju skripti lahko precej zapleteni in kompleksni. Zlahka se je zapleteti in narediti napake.

Zato se je porodila logična želja – imeti možnost napisati teste za svoje skripte. In v različici v0.4.0 je to postalo mogoče.

Testiranje skript

Primer testa za naš skript iz zgornjega primera:

-- @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')

Koraki:

določimo ime skripta, za katerega je test napisan
ime testa (za dnevnike)
naložimo modul za testiranje
moto, kateri rezultat je treba vrniti pri določenem zahtevku za ClickHouse ch1
preverimo, da je bil sprožen opozorilni (error) rps-min-limit z navedenim sporočilom
preverimo, da opozorilo rps-min-limit ni bilo onemogočeno (success)

Kaj še zna Balerter?

Poskušal bom osvetliti najpomembnejše sposobnosti Balerter, po mojem mnenju. Vse podrobnosti si lahko ogledate na uradni spletni strani https://balerter.com

pridobivanje podatkov iz
- clickhouse
- postgres
- mysql
- prometheus
- loki
pošiljanje obvestil na kanale
- slack
- telegram
- syslog
- notiify (UI obvestila na vašem računalniku)
- email
- discord
grafi na osnovi vaših podatkov, nalaganje slik v S3 združljivo shrambo in pripenjanje obvestil (Primer s slikami)
omogoča izmenjavo podatkov med skripti — globalno Key/Value shrambo
pisanje lastnih bibliotek v Luai in njihovo uporabo v skriptih (privzeto so na voljo lua knjižnice za delo z json, csv)
pošiljanje HTTP zahtev iz vaših skript (in seveda prejemanje odgovorov)
nudi API (še ni tako funkcionalen, kot bi želeli)
izvaža metrike v formatu Prometheus

Kaj bi si še želeli znati?

Že je jasno, da uporabniki in mi želimo možnost upravljanja z zagonom skriptov z uporabo sintakse cron. To bo izvedeno do različice v1.0.0

Želimo podpirati več virov podatkov in kanalov za dostavo obvestil. Na primer, nekaterim zagotovo ne bo dovolj MongoDB. Nekaterim Elastic Search. Pošiljanje SMS-ov in/ali klicanje na mobilne telefone. Želimo imeti možnost pridobivanja skript ne le iz datotek, ampak tudi, na primer, iz baze podatkov. Nazadnje si želimo bolj prijazno spletno mesto in boljšo dokumentacijo za projekt.

Vedno nekdo nekaj pogreša) Tukaj računamo na zahteve skupnosti, da bomo pravilno postavili prioritete. In na pomoč skupnosti, da vse uresničimo.