
Të gjithë e duan alertin.
Sigurisht, është shumë më mirë të marrësh një njoftim kur diçka ka ndodhur (apo është rregulluar), sesa të qëndrosh dhe të shohësh grafiku 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 zabbix dhe alertet në Grafana. Skripte të shkruara nga ne në bash dhe bot Telegram që tërheqin periodikisht ndonjë URL dhe thonë nëse diçka nuk është në rregull. Shumë gjëra.
Ne, nĂ« kompaninĂ« tonĂ«, gjithashtu kemi pĂ«rdorur zgjidhje tĂ« ndryshme derisa u pĂ«rballĂ«m me kompleksitetin, ose ndoshta mĂ« saktĂ«, me pamundĂ«sinĂ« e krijimit tĂ« alertave tĂ« komplikuar, tĂ« pĂ«rbĂ«rĂ«. ĂfarĂ« dĂ«shironim dhe çfarĂ« bĂ«mĂ« nĂ« fund â nĂ« titullin poshtĂ«. TLDR: KĂ«shtu filloi projekti open source
Mjaft gjatë kaluam mirë me alertat e konfiguruara në Grafana. Po, kjo nuk është rruga më e mirë. Gjithmonë rekomandohet përdorimi i ndonjë zgjidhjeje të specializuar, si Alertmanager. Edhe ne nuk kemi hequr dorë ndonjëherë nga ideja për të migruar. Pastaj, ngadalë, na erdhi dëshira për më shumë.
Të thuash kur një grafik ka rënë/rritur me XX% dhe ndodhet atje për N minuta krahasuar me periudhën e kaluar në M orë? Kjo, duket, mund të provohet të realizohet me Grafana ose Alertmanager, por është mjaft e vështirë. (Ose ndoshta nuk është e mundur, tani nuk po e them dot)
Gjithçka bëhet edhe më e komplikuar kur vendimi për alertin duhet të merret në bazë të të dhënave nga burime të ndryshme. Një rast i gjallë:
Kontrollojmë të dhënat nga dy bazat e të dhënave Clickhouse, pastaj i krahasojmë ato me disa të dhëna nga Postgres, dhe marrim një vendim për alertin. Sinjalizo ose anulo
Këto dëshira të ngjashme u grumbulluan mjaft për ne që të mendojmë për një zgjidhje tonën. Dhe atëherë përpiqemi të hartojmë listën e parë të kërkesave/mundësive për këtë shërbim, që ende nuk është krijuar
të lidhemi me burime të ndryshme të të dhënave. Për shembull, Prometheus, Clickhouse, Postgres
tĂ« dĂ«rgojmĂ« alertet nĂ« kanale tĂ« ndryshme â telegram, slack, etj.
në procesin e mendimit bëhet e qartë se dëshirohet jo një përshkrim deklarativ, por mundësia për të shkruar skripte
të nisim skripte sipas një programi
përditësimi i lehtë i skripteve pa rrestartuar shërbimin
mundësia për të zgjeruar funksionalitetin pa e rindërtuar shërbimin nga kodet burimore
Ky është një listë shembujsh dhe, për shumë të mundshme, jo shumë e saktë. Disa pika janë modifikuar, disa kanë vdekur. Siç ndodh zakonisht.
Në të vërtetë, pikërisht kështu filloi historia e Balerter.

Do të përpiqem të përshkruaj shkurtimisht se çfarë rezultati arritëm dhe si funksionon. (Po, sigurisht, kjo nuk është përfundimtare. Ka shumë plane për zhvillimin e produktit. Do të ndalem posaçërisht në ditën e sotme)
Si funksionon kjo?
Ju shkruani njĂ« script nĂ« Lua, ku dĂ«rgoni drejtpĂ«rdrejt kĂ«rkesa (nĂ« Prometheus, Clickhouse etj.). Merrni pĂ«rgjigje dhe siç i ĐŸĐ±ŃĐ°Đ±ĐŸŃuoni dhe i krahasoni ato. Pas kĂ«saj, aktivizoni/çaktivizoni ndonjĂ« alert. Balerter do tĂ« dĂ«rgojĂ« vetĂ« njoftimin nĂ« kanalet qĂ« keni cilĂ«suar (Email, telegram, slack etj.). Scripti ekzekutohet me njĂ« periudhĂ« tĂ« caktuar kohore. Dhe... kjo Ă«shtĂ« gjithçka)
Më mirë është 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 janë shumë të vogla: " .. tostring(resultRPS))
else
alert.success("rps-min-limit", "Requests RPS janë në rregull")
end ĂfarĂ« ndodh kĂ«tu:
specifikojmë se ky script duhet të ekzekutohet çdo 10 sekonda
specifikojmë emrin e scriptit (për API, për shfaqje në regjistrime, për përdorim në teste)
lidhim modul për regjistrimin e log-eve
lidhim modul për qasje në Clickhouse me emrin
ch1(vetë lidhja konfigurohet në konfigurim)dërgojmë kërkesën në Clickhouse
nĂ«se ndodhi njĂ« gabim â tregojmĂ« njĂ« mesazh nĂ« log dhe dalim
krahasoni rezultatin e kërkesës me konstantën (në një shembull jetësor, mund ta merrnim këtë vlerë, për shembull, nga baza e të dhënave 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 kuptueshëm. Megjithatë, natyrisht, në jetën reale, scriptet mund të jenë mjaft të përziera dhe komplekse. Ato lehtë mund të bëhen konfuz dhe të bëjnë gabime.
Prandaj, lindi dĂ«shira logjike â tĂ« kemi mundĂ«sinĂ« pĂ«r tĂ« shkruar teste pĂ«r scriptet tona. Dhe nĂ« versionin v0.4.0, kjo u bĂ« e mundur.
Testimi i scriptëve
Shembulli i testit për scriptin 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 janë shumë të vogla: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS janë në rregull')Hapat
specifikojmë emrin e scriptit, për të cilin është shkruar testi
emri i testit (për regjistrat)
lidhim modul testimi
diskutojmë se çfarë rezultati duhet të kthehet për një kërkesë të caktuar në Clickhouse
ch1kontrollojmë që është thirrur alarmin (error) rps-min-limit me mesazhin e specifikuar
kontrollojmë që alarmi rps-min-limit nuk është ç aktivizuar (success)
ĂfarĂ« tjetĂ«r mund tĂ« bĂ«jĂ« Balerter?
Do të përpiqem të prek aftësitë më të rëndësishme të Balerter. Mund të shihni më shumë në faqen zyrtare
të marrim të dhëna nga
clickhouse
postgres
mysql
prometheus
loki
të dërgojmë njoftime në kanale
slack
telegram
syslog
notiify (njoftime UI në kompjuterin tuaj)
email
discord
tĂ« ndĂ«rtojmĂ« grafika mbi tĂ« dhĂ«nat tuaja, tĂ« ngarkojmĂ« imazhe nĂ« njĂ« ruajtje tĂ« kompatibilshme me S3 dhe tâi bashkojmĂ« ato me njoftimet ()
lejon shkĂ«mbimin e tĂ« dhĂ«nave midis skripteve â njĂ« ruajtje globale Key/Value
të shkruajmë bibliotekat tona në Lua dhe t'i përdorim ato në skripte (me default vijnë biblioteka lua për të punuar me json, csv)
të dërgojmë kërkesa HTTP nga skriptet tuaja (dhe sigurisht të marrim përgjigje)
siguron API (ende nuk është aq funksional sa do të doja)
eksporton metrika në formatin Prometheus
ĂfarĂ« do tĂ« doja tĂ« dija mĂ« shumĂ«?
Tani është e qartë se përdoruesit dhe ne duam mundësinë për të menaxhuar fillimin e skripteve me ndihmën e sintaksës cron. Kjo do të realizohet deri në versionin v1.0.0
Dëshirojmë të mbështesim më shumë burime të dhënash dhe kanale njoftimi. Për shembull, disa sigurisht që do të kishin nevojë për MongoDB. Disa për Elastic Search. Të dërgojmë SMS dhe/ose të bëjmë telefonata në celular. Duam të jemi në gjendje të marrim skriptet jo vetëm nga skedarët, por edhe, për shembull, nga databaza. Në fund, duam një faqe më të përshtatshme për projektin dhe dokumentacion më të mirë.
Dikush gjithmonë i mungon diçka) Këtu shpresojmë për kërkesat e komunitetit, për të vendosur përparësitë e duhura. Dhe për ndihmën e komunitetit, për ta realizuar të gjitha
Në përfundim
Ne përdorim mjaft kohë. Dhjetëra skripte qëndrojnë në mbrojtje të qetësisë sonë. Shpresoj që ky punë të jetë e dobishme për dikë tjetër.
Dhe mirëseardhje me çështjet tuaja dhe PR.
Burimi: habr.com
