Punë e lehtë me alarme komplekse. Ose historia e krijimit të Balerter

Punë e lehtë me alarme komplekse. Ose historia e krijimit të Balerter

Të gjithë i pëlqejnë alarmet.

Sigurisht, është shumë më mirë të njoftohesh kur diçka ka ndodhur (ose është rregulluar) sesa të ulesh dhe të shikosh grafikët dhe të kërkosh anomali.

Dhe shumë mjete janë krijuar për këtë. Alertmanager nga ekosistemi Prometheus dhe vmalert nga grupi i produkteve VictoriaMetrics. Njoftimet dhe sinjalizimet Zabbix në Grafana. Skriptet e shkruara vetë në bot bash dhe Telegram që nxjerrin periodikisht disa URL dhe ju tregojnë nëse diçka nuk shkon. Shumë nga gjithçka.

Ne, në kompaninë tonë, përdorëm gjithashtu zgjidhje të ndryshme derisa u përballëm me kompleksitetin, ose, më saktë, pamundësinë e krijimit të sinjalizimeve komplekse, të përbëra. Ajo që ne donim dhe çfarë përfunduam duke bërë është poshtë prerjes. TLDR: Kështu u shfaq projekti me kod të hapur Balerist

Për një kohë të gjatë jetuam mirë me sinjalizimet e konfiguruara në Grafana. Po, kjo nuk është mënyra më e mirë. Rekomandohet gjithmonë përdorimi i disa zgjidhjeve të specializuara, si Alertmanager. Dhe ne gjithashtu shikuam drejt lëvizjes më shumë se një herë. Dhe pastaj, pak nga pak, ne donim më shumë.

Thuaj kur një grafik i caktuar ka rënë/rritur me XX% dhe ka qenë aty për N minuta në krahasim me periudhën e mëparshme të M orësh? Duket se mund të përpiqeni ta zbatoni këtë me Grafana ose Alertmanager, por nuk është aq e lehtë. (Ose ndoshta nuk është e mundur, nuk do ta them tani)

Gjërat ndërlikohen edhe më shumë kur vendimi i alarmit duhet të merret bazuar në të dhëna nga burime të ndryshme. Shembull i drejtpërdrejtë:

Ne kontrollojmë të dhënat nga dy bazat e të dhënave Clickhouse, më pas i krahasojmë me disa të dhëna nga Postgres dhe vendosim për një alarm. Sinjalizoni ose anuloni

Ne kemi grumbulluar mjaft dëshira të ngjashme që ne të mendojmë për vendimin tonë. Dhe më pas u përpoqëm të përpilonim listën e parë të kërkesave/aftësive të këtij shërbimi, e cila ende nuk është krijuar.

  • qasje në burime të ndryshme të të dhënave. Për shembull, Prometheus, Clickhouse, Postgres

  • dërgoni sinjalizime në kanale të ndryshme - telegram, slack, etj.

  • në procesin e të menduarit, u bë e qartë se nuk doja një përshkrim deklarativ, por aftësinë për të shkruar skenarë

  • ekzekutimi i skripteve sipas një orari

  • përditësim i lehtë i skripteve pa rifilluar shërbimin

  • aftësia për të zgjeruar disi funksionalitetin pa rindërtuar shërbimin nga kodet burimore

Kjo listë është e përafërt dhe ka shumë të ngjarë jo shumë e saktë. Disa pika ndryshuan, disa vdiqën. Gjithçka është si zakonisht.

Në fakt, kështu filloi historia e Balerter.

Punë e lehtë me alarme komplekse. Ose historia e krijimit të Balerter

Do të përpiqem të përshkruaj shkurtimisht se çfarë ndodhi në fund dhe si funksionon. (Po, sigurisht, ky nuk është fundi. Ka shumë plane për zhvillimin e produktit. Do të ndalem vetëm sot)

Si funksionon kjo gjë?

Ju shkruani një skript në Lua ku dërgoni në mënyrë eksplicite kërkesa (tek Prometheus, Clickhouse, etj.). Ju merrni përgjigje dhe disi i përpunoni dhe krahasoni ato. Pastaj aktivizoni/fikni një lloj alarmi. Vetë Balerter do të dërgojë një njoftim në kanalet që keni konfiguruar (Email, telegram, slack, etj.). Skripti ekzekutohet në intervale të caktuara. Dhe ... në përgjithësi, kjo është e gjitha)

Është më mirë të tregohet 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 < minResultRPS then
    alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end 

Cfare po ndodh ketu:

  • ne tregojmë se ky skrip duhet të ekzekutohet çdo 10 sekonda

  • tregoni emrin e skriptit (për API, për shfaqje në regjistra, për përdorim në teste)

  • lidhni modulin për nxjerrjen e regjistrave

  • lidhni një modul për të hyrë në shtëpinë e klikimit me emrin ch1 (vetë lidhja është konfiguruar në konfigurim)

  • dërgoni një kërkesë në clickhouse

  • në rast gabimi, shfaqim një mesazh në regjistër dhe dalim

  • Krahasoni rezultatin e pyetjes me një konstante (në një shembull të drejtpërdrejtë, ne mund ta marrim këtë vlerë, për shembull, nga baza e të dhënave Postgres)

  • aktivizoni ose çaktivizoni sinjalizimin me ID rps-min-limit

  • do të merrni një njoftim nëse statusi i alarmit ka ndryshuar

Shembulli është mjaft i thjeshtë dhe i kuptueshëm. Sidoqoftë, sigurisht, në jetën reale skenarët mund të jenë mjaft të gjata dhe komplekse. Është e lehtë të ngatërrohesh dhe të bësh gabime.

Prandaj, është pjekur një dëshirë logjike - të jeni në gjendje të shkruani teste për skenarët tuaj. Dhe në versionin v0.4.0 kjo u shfaq.

Testimi i skripteve

Shembull i testit për skriptin tonë nga shembulli i mësipërm:

-- @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:

  • tregoni emrin e skenarit për të cilin është shkruar testi

  • emri i testit (për regjistrat)

  • lidhni modulin e testimit

  • ne themi se çfarë rezultati duhet të kthehet për një kërkesë specifike në clickhouse ch1

  • ne kontrollojmë që alarmi (gabimi) rps-min-limit me mesazhin e specifikuar është thirrur

  • kontrollo që sinjalizimi rps-min-limit nuk është çaktivizuar (sukses)

Çfarë tjetër mund të bëjë Balerter?

Do të përpiqem të prek aftësitë më të rëndësishme, për mendimin tim, Balerter. Ju mund të shihni gjithçka në detaje në faqen zyrtare të internetit https://balerter.com

  • marrin të dhëna nga

    • klikim shtëpie

    • postgres

    • MySQL

    • prometeu

    • kaçurrela

  • dërgoni njoftime në kanale

    • xhoko

    • telegram

    • syslog

    • njofto (njoftime UI në kompjuterin tënd)

    • Email

    • mosmarrëveshje

  • ndërtoni grafikët bazuar në të dhënat tuaja, ngarkoni imazhin në hapësirën ruajtëse të përputhshme me S3 dhe bashkëngjitni atë me njoftimet (Shembull me foto)

  • ju lejon të shkëmbeni të dhëna midis skripteve - ruajtja globale e çelësit/vlerës

  • shkruani bibliotekat tuaja në Lua dhe përdorni ato në skriptet (si parazgjedhje, bibliotekat lua ofrohen për të punuar me json, csv)

  • dërgoni kërkesa HTTP nga skriptet tuaja (dhe merrni përgjigje, natyrisht)

  • ofron një API (ende jo aq funksionale sa do të dëshironim)

  • eksporton metrikë në formatin Prometheus

Çfarë tjetër do të dëshironit të jeni në gjendje të bëni?

Është tashmë e qartë se përdoruesit dhe ne duam aftësinë për të kontrolluar nisjen e skripteve duke përdorur sintaksën cron. Kjo do të bëhet përpara versionit v1.0.0

Dëshiroj të mbështes më shumë burime të dhënash dhe kanale të shpërndarjes së njoftimeve. Për shembull, dikujt patjetër do t'i mungojë MongoDB. Kërkim elastik për disa. Dërgoni SMS dhe/ose bëni thirrje në telefonin tuaj celular. Ne duam të jemi në gjendje të marrim skriptet jo vetëm nga skedarët, por gjithashtu, për shembull, nga një bazë të dhënash. Në fund, ne duam një faqe interneti më miqësore për përdoruesit dhe dokumentacion më të mirë për projektin.

Dikujt i mungon gjithmonë diçka) Këtu ne mbështetemi në kërkesën e komunitetit për të vendosur prioritetet në mënyrë korrekte. Dhe në ndihmë të komunitetit për të realizuar gjithçka

Në përfundim

Ne përdorim Balerist Unë e kam atë për një kohë të gjatë tani. Dhjetra skenare ruajnë qetësinë tonë mendore. Shpresoj që kjo punë të jetë e dobishme për dikë tjetër.

Dhe mirëpritur me Çështjen dhe PR-në tuaj.

Burimi: www.habr.com

Shto një koment