
Të gjithë i duan alarmet.
Natyrisht, është shumë më mirë të marrësh një njoftim kur ndodhi diçka (ose u riparua), sesa të ulesh, të shohësh grafikët dhe të kërkosh anomalitë.
Dhe janë krijuar shumë mjete për këtë. Alertmanager nga ekosistemi Prometheus dhe vmalert nga grupi i produkteve VictoriaMetrics. Njoftimet e Zabbix dhe alarmet në Grafana. Skriptet e krijuara vetë në bash dhe botet e Telegramit që herë pas here tërheqin ndonjë URL dhe tregojnë nëse diçka nuk shkon siç duhet. Shumë gjëra.
Ne, nĂ« kompaninĂ« tonĂ«, gjithashtu kemi pĂ«rdorur zgjidhje tĂ« ndryshme, derisa u pĂ«rballĂ«m me vĂ«shtirĂ«sinĂ«, ose mĂ« saktĂ«, pamundĂ«sinĂ« e krijimit tĂ« alarmĂ«ve tĂ« ndĂ«rlikuar dhe tĂ« pĂ«rbĂ«rĂ«. Ăka dĂ«shironim dhe çfarĂ« arritĂ«m tĂ« bĂ«nim â nĂ« pjesĂ«n e poshtme. TLDR: KĂ«shtu lindi projekti open source
Më shumë se një periudhë të gjatë kemi jetuar mirë me alarmet e konfiguruara në Grafana. Po, kjo nuk është rruga më e mirë. Gjithmonë rekomandohet të përdoren ndonjë zgjidhje të specializuar, si Alertmanager. Edhe ne nuk kemi hezituar ta shohim kalimin. Pastaj, ngadalë, filluam të dëshironim më shumë.
Të tregosh kur një grafik ka rënë/rritur me XX% dhe ndodhet atje për N minuta krahasuar me periudhën e mëparshme në M orë? Kjo duket se mund të realizohet me Grafana ose Alertmanager, por është mjaft e vështirë. (Ndoshta nuk është e mundur, nuk mund ta them tani)
Gjithçka bëhet edhe më e ndërlikuar kur vendimi për alarmin duhet të merret bazuar në të dhëna nga burime të ndryshme. Një shembull në jetë:
Kontrollojmë të dhënat nga dy baza Clickhouse, pastaj i krahasojmë me disa të dhëna nga Postgres dhe marrim vendimin për alarmin. Të sinjalizojmë ose ta anulojmë.
Kemi akumuluar mjaft dëshira të ngjashme për të menduar për zgjidhjen tonë. Dhe atëherë përpiqemi të hartojmë listën e parë të kërkesave/mundësive të këtij shërbimi, i cili nuk është krijuar ende.
të drejtohemi në burime të ndryshme të të dhënave. Për shembull, Prometheus, Clickhouse, Postgres.
tĂ« dĂ«rgojmĂ« alarme nĂ« kanale tĂ« ndryshme â telegram, slack etj.
në procesin e mendimit u bë e qartë se dëshirojmë jo një përshkrim deklarativ, por mundësinë për të shkruar skripta.
të fillojmë skripta sipas një orari.
lehtë përditësimi i skripteve pa rindezjen e shërbimit.
mundësia për të zgjeruar funksionalitetin pa e riparë shërbimin nga kodet burimore.
Ky është një listë ilustrative dhe, shumë mundësisht, jo shumë e saktë. Disa pikë janë modifikuar, disa janë zhdukur. Gjithçka si zakonisht.
Në fakt, kështu filloi historia e Balerter.

Do të përpiqem të përshkruaj shkurtimisht se çfarë kemi arritur dhe si funksionon. (Po, sigurisht, kjo nuk është përfundimi. Ka shumë plane për zhvillimin e produktit. Unë do të ndalem vetëm te sotja.)
Si funksionon?
Ju shkruani një skenar në Lua, ku qartë dërgoni kërkesa (në Prometheus, Clickhouse, etj). Merrni përgjigje dhe si ndodhi i përpunoni dhe i shkoni krahasojeni. Pas kësaj aktivizoni/ çaktivizoni ndonjë alarëm. Balerter do të dërgojë vetë një njoftim në kanalet që keni konfiguruar (Email, telegram, slack, etj.). Skripti ekzekutohet me një periodicitet të caktuar. Dhe... në thelb, kjo është e gjitha.)
Më mirë ta tregojmë me një shembull:
-- @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 ĂfarĂ« po ndodh kĂ«tu:
përcaktojmë se ky skenar duhet të ekzekutohet çdo 10 sekonda
shkruajmë emrin e skriptit (për API, për t'u shfaqur në logje, për përdorim në teste)
lidhe modul për daljen e logjeve
lidhe modul për qasje në ClickHouse me emrin
ch1(lidhi e vetme konfigurohet në konfigurim)dërgo kërkesën në ClickHouse
nĂ« rast gabimi â shfaq njĂ« mesazh nĂ« log dhe dil
krahason rezultatin e kërkesës me një konstantë (në një shembull real, mund ta marim këtë vlerë, për shembull, nga data Postgres)
aktivizojmë ose çaktivizojmë alertin me ID
rps-min-limitdo të merrni një njoftim nëse statusi i alertit ka ndryshuar
Shembulli është mjaft i thjeshtë dhe i qartë. Megjithatë, natyrisht, në jetë reale skriptet mund të jenë mjaft të gjera dhe komplekse. Ato lehtë mund të ngatërrohen dhe të bëjnë gabime.
Prandaj, ka lindur dĂ«shira logjike â tĂ« kesh mundĂ«sinĂ« tĂ« shkruash teste pĂ«r skriptet e tua. Dhe nĂ« versionin v0.4.0, kjo Ă«shtĂ« bĂ«rĂ« e mundur.
Testimi i skripteve
Një shembull testi për skriptin tonë nga shembulli më sipër:
-- @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')Hapat e procedurës:
shkruajmë emrin e skenarit për të cilin është shkruar testi
emri i testit (për logët)
lidhi modul testingut
specifikojmë cili rezultat duhet të kthehet për një kërkesë të caktuar në Clickhouse
ch1kontrollojmë se u thirr alert (gabim) rps-min-limit me mesazhin e specifikuar
kontrollojmë që alerti rps-min-limit nuk është fikur (sukses)
ĂfarĂ« tjetĂ«r di tĂ« bĂ«jĂ« Balerter?
Do të përpiqem të prek aftësitë më të rëndësishme të Balerter, sipas mendimit tim. Mund të shihni gjithçka në detaje në faqen zyrtare.
të merrni të dhëna nga
clickhouse
postgres
mysql
prometheus
loki
dërgoni njoftime në kanale
slack
telegram
syslog
notify (njoftime UI në kompjuterin tuaj)
email
discord
të krijoni grafike nga të dhënat tuaja, ngarkoni imazhe në një depo të përputhshme me S3 dhe lidheni me njoftimet ()
lejon shkĂ«mbimin e tĂ« dhĂ«nave midis skenarĂ«ve â depo globale Key/Value
të shkruani bibliotekat tuaja në Lua dhe t'i përdorni ato në skriptet (bibliotekat lua për punën me json, csv jepen si standart)
të dërgoni kërkesa HTTP nga skriptet tuaja (po ashtu, të merrni përgjigje, sigurisht)
ofron API (ende nuk është aq funksional sa dëshirojmë)
eksporton metrika në formatin Prometheus
ĂfarĂ« do tĂ« dĂ«shironit tĂ« dinit mĂ« shumĂ«?
Tani është e qartë se përdoruesit dhe ne duam mundësinë për të menaxhuar ekzekutimin e skripteve me sintaksën cron. Kjo do të realizohet para versionit v1.0.0
Dëshirojmë të mbështesim më shumë burime të dhënash dhe kanale për dërgimin e njoftimeve. Për shembull, ndokujt sigurisht do t'i mungojë MongoDB. Ndokujt Elastic Search. Dërgimi i SMS-ve dhe/ose telefonatat në celular. Dëshirojmë të jemi në gjendje të marrim skriptet jo vetëm nga skedarët, por edhe, për shembull, nga databaza. Në fund, dëshirojmë një site më të rehatshëm për projektin dhe dokumentacion më të mirë.
Gjithmonë ndokujt i mungon diçka) Këtu shpresojmë në kërkesën e komunitetit për të vendosur përprioritete siç duhet. Dhe në ndihmën e komunitetit për të realizuar gjithçka.
Në përfundim
Ne përdorim ka kemi prej kohësh. Dhjetëra skriptet qëndrojnë përpara qetësisë sonë. Shpresoj që ky punim të jetë i dobishëm për ndonje tjetër.
Dhe mirë se vini me çështjet dhe PR-të tuaj.
Burimi: habr.com
