ProHoster > Blog > Uprava > Enostavno delo s kompleksnimi opozorili. Ali zgodovina Balerterja

Enostavno delo s kompleksnimi opozorili. Ali zgodovina Balerterja

Enostavno delo s kompleksnimi opozorili. Ali zgodovina Balerterja

Vsi imajo radi opozorila.

Seveda je veliko bolje biti obveščen, ko se je nekaj zgodilo (ali je bilo popravljeno), kot pa sedeti in gledati grafe ter iskati anomalije.

In za to je bilo ustvarjenih veliko orodij. Alertmanager iz ekosistema Prometheus in vmalert iz skupine izdelkov VictoriaMetrics. Zabbix obvestila in opozorila v Grafani. Samonapisani skripti v botih bash in Telegram, ki občasno prikažejo nekaj URL-jev in vam sporočijo, če je kaj narobe. Veliko vsega.

Tudi v našem podjetju smo uporabljali različne rešitve, dokler nismo naleteli na kompleksnost, oziroma nemožnost izdelave kompleksnih, sestavljenih opozoril. Kar smo želeli in kar smo na koncu naredili, je pod mejo. TLDR: Tako se je pojavil odprtokodni projekt Balerter

Kar dolgo smo dobro živeli z opozorili, konfiguriranimi v Grafani. Da, to ni najboljši način. Vedno je priporočljiva uporaba nekaterih specializiranih rešitev, kot je Alertmanager. In tudi večkrat smo pogledali proti selitvi. In potem smo malo po malo želeli več.

Recimo, ko je določen grafikon padel/zrasel za XX % in je bil tam N minut v primerjavi s prejšnjim obdobjem M ur? Zdi se, da lahko poskusite to implementirati z Grafano ali Alertmanagerjem, vendar ni povsem enostavno. (Ali morda ni mogoče, ne bom rekel zdaj)

Stvari postanejo še bolj zapletene, ko je treba odločitev o opozorilu sprejeti na podlagi podatkov iz različnih virov. Primer v živo:

Podatke preverimo v dveh bazah Clickhouse, jih primerjamo z nekaterimi podatki iz Postgresa in se odločimo za opozorilo. Signal ali preklic

Podobnih želja se nama je nabralo kar nekaj, da razmisliva o svoji odločitvi. In potem smo poskušali sestaviti prvi seznam zahtev/zmožnosti te storitve, ki še ni izdelan.

  • dostop do različnih virov podatkov. Na primer Prometheus, Clickhouse, Postgres

  • pošiljanje opozoril na različne kanale - telegram, slack itd.

  • v procesu razmišljanja je postalo jasno, da ne želim deklarativnega opisa, ampak sposobnost pisanja skriptov

  • izvajanje skriptov po urniku

  • enostavno posodabljanje skriptov brez ponovnega zagona storitve

  • zmožnost nekako razširiti funkcionalnost brez ponovne gradnje storitve iz izvornih kod

Ta seznam je približen in najverjetneje ni zelo točen. Nekatere točke so se spremenile, nekatere so umrle. Vse je kot ponavadi.

Pravzaprav se je tako začela zgodovina Balerterja.

Enostavno delo s kompleksnimi opozorili. Ali zgodovina Balerterja

Poskušal bom na kratko opisati, kaj se je na koncu zgodilo in kako deluje. (Ja, seveda, to še ni konec. Načrtov za razvoj izdelka je veliko. Ustavila se bom danes)

Kako deluje?

V Lui napišete skript, kjer eksplicitno pošiljate zahteve (Prometheusu, Clickhouseu itd.). Dobiš odgovore in jih nekako predelaš in primerjaš. Nato vklopite/izklopite nekakšno opozorilo. Balerter bo sam poslal obvestilo na kanale, ki ste jih konfigurirali (e-pošta, telegram, slack itd.). Skript se izvaja v določenih intervalih. In ... na splošno je to vse)

Najbolje je pokazati s primerom:

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

Kaj se tukaj dogaja:

  • nakazujemo, da je treba ta skript izvajati vsakih 10 sekund

  • navedite ime skripta (za API, za prikaz v dnevnikih, za uporabo v testih)

  • priključite modul za izpis dnevnikov

  • povežite modul za dostop do klikne hiše z imenom ch1 (sama povezava je konfigurirana v konfiguraciji)

  • pošlji povpraševanje na clickhouse

  • v primeru napake prikažemo sporočilo v dnevniku in izstopimo

  • primerjajte rezultat poizvedbe s konstanto (v primeru v živo bi to vrednost lahko pridobili na primer iz baze podatkov Postgres)

  • omogočite ali onemogočite opozorilo z ID-jem rps-min-limit

  • prejeli boste obvestilo, če se je stanje opozorila spremenilo

Primer je precej preprost in razumljiv. Seveda pa so lahko scenariji v resničnem življenju precej dolgi in zapleteni. Lahko se zmedeš in delaš napake.

Zato je dozorela logična želja - da bi lahko pisali teste za svoje skripte. In v različici v0.4.0 se je to pojavilo.

Testiranje skriptov

Primer testa za naš skript iz zgornjega primera:

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

Korak za korakom:

  • navedite ime skripta, za katerega je test napisan

  • testno ime (za dnevnike)

  • priključite testni modul

  • povemo, kakšen rezultat je treba vrniti za določeno zahtevo v Clickhouse ch1

  • preverimo, ali je bilo klicano opozorilo (napaka) rps-min-limit z navedenim sporočilom

  • preverite, ali opozorilo o omejitvi min-rps ni bilo onemogočeno (uspeh)

Kaj še lahko naredi Balerter?

Poskušal se bom dotakniti najpomembnejših, po mojem mnenju, baličarskih veščin. Vse si lahko podrobno ogledate na uradni spletni strani https://balerter.com

  • prejemati podatke od

    • klikhouse

    • postgres

    • mysql

    • prometheus

    • Loki

  • pošiljanje obvestil kanalom

    • Slack

    • telegram

    • syslog

    • obvestila (obvestila uporabniškega vmesnika na vašem računalniku)

    • E-naslov

    • neskladje

  • sestavite grafe na podlagi svojih podatkov, naložite sliko v shrambo, združljivo s S3, in jo pripnite obvestilom (Primer s slikami)

  • omogoča izmenjavo podatkov med skripti - globalno shranjevanje ključev/vrednosti

  • napišite svoje lastne knjižnice v Lua in jih uporabite v skriptih (privzeto so knjižnice lua na voljo za delo z json, csv)

  • pošiljanje zahtev HTTP iz vaših skriptov (in prejemanje odgovorov, seveda)

  • ponuja API (še ni tako funkcionalen, kot bi želeli)

  • izvozi meritve v formatu Prometheus

Kaj bi še radi počeli?

Že zdaj je jasno, da uporabniki in mi želimo možnost nadzora zagona skriptov s sintakso cron. To bo storjeno pred različico v1.0.0

Rad bi podprl več podatkovnih virov in kanalov za dostavo obvestil. Na primer, nekdo bo zagotovo pogrešal MongoDB. Elastično iskanje za nekatere. Pošiljajte SMS in/ali kličite na svoj mobilni telefon. Želimo, da bi lahko prejemali skripte ne le iz datotek, ampak tudi na primer iz baze podatkov. Na koncu želimo uporabniku prijaznejšo spletno stran in boljšo dokumentacijo za projekt.

Nekomu vedno nekaj manjka) Tukaj se zanašamo na zahtevo skupnosti, da pravilno določimo prioritete. In k pomoči skupnosti, da vse realiziramo

Na koncu

Uporabljamo Balerter Imam ga že kar nekaj časa. Na desetine skriptov varuje naš duševni mir. Upam, da bo to delo koristno še komu.

In dobrodošli s svojo številko in PR.

Vir: www.habr.com

Dodaj komentar