ProHoster > Dienoraštis > Administravimas > Lengvas darbas su sudėtingais įspėjimais. Arba Balerterio sukūrimo istorija

Lengvas darbas su sudėtingais įspėjimais. Arba Balerterio sukūrimo istorija

Lengvas darbas su sudėtingais įspėjimais. Arba Balerterio sukūrimo istorija

Visi mėgsta įspėjimus.

Žinoma, daug geriau gauti pranešimą, kai kas nors atsitiko (ar pataisyta), nei sėdėti ir žiūrėti į grafikus ir ieškoti anomalijų.

Ir tam buvo sukurta daug įrankių. Alertmanager iš Prometheus ekosistemos ir vmalert iš VictoriaMetrics produktų grupės. „Zabbix“ pranešimai ir įspėjimai „Grafana“. Savarankiškai parašyti scenarijai „bash“ ir „Telegram“ robotuose, kurie periodiškai atrenka tam tikrą URL ir praneša, jei kažkas negerai. Daug visko.

Mes, savo įmonėje, taip pat naudojome skirtingus sprendimus, kol nesusidūrėme su sudėtingumu arba, tiksliau, iki negalėjimo sukurti sudėtingų, sudėtinių įspėjimų. Tai, ko norėjome ir ką padarėme, yra žemiau. TLDR: Taip atsirado atvirojo kodo projektas Balerteris

Gana ilgą laiką gerai gyvenome su Grafana sukonfigūruotais įspėjimais. Taip, tai nėra geriausias būdas. Visada rekomenduojama naudoti tam tikrus specializuotus sprendimus, pvz., Alertmanager. Ir mes taip pat ne kartą žiūrėjome į judėjimą. Ir tada pamažu norėjome daugiau.

Pasakykite, kada tam tikra diagrama nukrito/padidėjo XX% ir buvo ten N minučių, palyginti su ankstesniu M valandų periodu? Atrodo, kad galite pabandyti tai įgyvendinti naudodami „Grafana“ ar „Alertmanager“, tačiau tai nėra lengva. (O gal tai neįmanoma, dabar nesakysiu)

Viskas tampa dar sudėtingesnė, kai sprendimas dėl įspėjimo turi būti priimtas remiantis duomenimis iš skirtingų šaltinių. Gyvas pavyzdys:

Patikriname duomenis iš dviejų „Clickhouse“ duomenų bazių, tada palyginame juos su kai kuriais „Postgres“ duomenimis ir nusprendžiame dėl įspėjimo. Signalizuoti arba atšaukti

Panašių norų, kad galėtume pagalvoti apie savo sprendimą, susikaupė gana daug. Ir tada pabandėme sudaryti pirmąjį šios paslaugos reikalavimų/galimybių sąrašą, kuris dar nesukurtas.

  • pasiekti skirtingus duomenų šaltinius. Pavyzdžiui, „Prometheus“, „Clickhouse“, „Postgres“.

  • siųsti perspėjimus įvairiais kanalais – telegrama, slack ir kt.

  • mąstymo procese tapo aišku, kad noriu ne deklaratyvaus aprašymo, o gebėjimo rašyti scenarijus

  • paleisti scenarijus pagal tvarkaraštį

  • lengvas scenarijų atnaujinimas nepaleidžiant paslaugos iš naujo

  • galimybė kažkaip išplėsti funkcionalumą neperkuriant paslaugos iš šaltinio kodų

Šis sąrašas yra apytikslis ir greičiausiai nėra labai tikslus. Kai kurie taškai pasikeitė, kai kurie mirė. Viskas kaip įprasta.

Tiesą sakant, taip prasidėjo Balerterio istorija.

Lengvas darbas su sudėtingais įspėjimais. Arba Balerterio sukūrimo istorija

Pabandysiu trumpai apibūdinti, kas galiausiai atsitiko ir kaip tai veikia. (Taip, žinoma, tai dar ne pabaiga. Yra daug produktų kūrimo planų. Sustosiu ties šiandien)

Kaip tai veikia?

Rašote scenarijų „Lua“, kur aiškiai siunčiate užklausas (į „Prometheus“, „Clickhouse“ ir kt.). Gauni atsakymus ir kažkaip juos apdoroji bei palygini. Tada įjunkite/išjunkite kažkokį įspėjimą. Balerter pats išsiųs pranešimą jūsų sukonfigūruotiems kanalams (el. paštu, telegrama, slack ir kt.). Scenarijus vykdomas nustatytais intervalais. Ir... apskritai, tai viskas)

Geriausia parodyti pavyzdžiu:

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

Kas čia vyksta:

  • nurodome, kad šis scenarijus turi būti vykdomas kas 10 sekundžių

  • nurodykite scenarijaus pavadinimą (skirtą API, rodyti žurnaluose, naudoti testuose)

  • prijunkite modulį žurnalams išvesti

  • prijunkite modulį, kad pasiektumėte Clickhouse su pavadinimu ch1 (pats ryšys sukonfigūruotas konfigūracijose)

  • atsiųskite užklausą „clickhouse“.

  • įvykus klaidai, žurnale parodome pranešimą ir išeiname

  • palyginkite užklausos rezultatą su konstanta (tiesiame pavyzdyje šią reikšmę galėtume gauti, pavyzdžiui, iš Postgres duomenų bazės)

  • įjungti arba išjungti įspėjimą su ID rps-min-limit

  • gausite pranešimą, jei perspėjimo būsena pasikeis

Pavyzdys gana paprastas ir suprantamas. Tačiau, žinoma, realiame gyvenime scenarijai gali būti gana ilgi ir sudėtingi. Lengva susipainioti ir suklysti.

Todėl subrendo logiškas noras – mokėti rašyti savo scenarijus testus. Ir 0.4.0 versijoje tai pasirodė.

Scenarijų testavimas

Mūsų scenarijaus testo pavyzdys iš aukščiau pateikto pavyzdžio:

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

Žingsniai:

  • nurodykite scenarijaus, kuriam parašytas testas, pavadinimą

  • bandymo pavadinimas (rąstams)

  • prijunkite testavimo modulį

  • mes pasakome, koks rezultatas turi būti grąžintas už konkrečią užklausą clickhouse ch1

  • patikriname, ar buvo iškviestas įspėjimas (klaida) rps-min-limit su nurodytu pranešimu

  • patikrinkite, ar rps-min-limit įspėjimas nebuvo išjungtas (sėkmingai)

Ką dar gali padaryti Balerteris?

Pabandysiu paliesti svarbiausius, mano nuomone, Balerterio įgūdžius. Viską išsamiai galite pamatyti oficialioje svetainėje https://balerter.com

  • gauti duomenis iš

    • clickhouse

    • postgres

    • mySQL

    • prometheus

    • Loki

  • siųsti pranešimus kanalams

    • laisvas

    • telegrama

    • sistemos dienoraštis

    • pranešti (NS pranešimai jūsų kompiuteryje)

    • email

    • nesantarvė

  • kurkite diagramas pagal savo duomenis, įkelkite vaizdą į S3 suderinamą saugyklą ir pridėkite prie pranešimų (Pavyzdys su nuotraukomis)

  • leidžia keistis duomenimis tarp scenarijų – pasaulinė rakto/vertės saugykla

  • rašykite savo bibliotekas Lua ir naudokite jas scenarijuose (pagal numatytuosius nustatymus lua bibliotekos pateikiamos darbui su json, csv)

  • siųsti HTTP užklausas iš savo scenarijų (ir, žinoma, gauti atsakymus)

  • suteikia API (dar ne tokia funkcionali, kaip norėtume)

  • eksportuoja metrikas Prometheus formatu

Ką dar norėtumėte turėti?

Jau aišku, kad vartotojai ir mes norime turėti galimybę valdyti scenarijų paleidimą naudodami sintaksę cron. Tai bus padaryta prieš 1.0.0 versiją

Norėčiau palaikyti daugiau duomenų šaltinių ir pranešimų pateikimo kanalų. Pavyzdžiui, kažkas tikrai pasiilgs MongoDB. Elastinė paieška kai kuriems. Siųskite SMS ir (arba) skambinkite į savo mobilųjį telefoną. Norime, kad scenarijus būtų galima gauti ne tik iš failų, bet ir, pavyzdžiui, iš duomenų bazės. Galiausiai norime patogesnės svetainės ir geresnių projekto dokumentų.

Kažkam visada kažko trūksta) Čia pasikliaujame bendruomenės prašymu teisingai nustatyti prioritetus. Ir į pagalbą bendruomenei viską suvokti

užbaigiant

Mes naudojame Balerteris Jau kurį laiką jį turiu. Dešimtys scenarijų saugo mūsų ramybę. Tikiuosi, kad šis darbas bus naudingas dar kam nors.

Sveiki atvykę su savo problema ir viešaisiais ryšiais.

Šaltinis: www.habr.com

Добавить комментарий