Puna e lehtë me alarmet e ndërlikuara. Ose historia e krijimit të Balerter

Puna e lehtë me alarmet e ndërlikuara. Ose historia e krijimit të Balerter

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 Balerter

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.

Puna e lehtë me alarmet e ndërlikuara. Ose historia e krijimit të 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-limit

  • do 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 ch1

  • kontrollojmĂ« 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. https://balerter.com

  • 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 (Shembuj me imazhe)

  • 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 Balerter 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

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster