ProHoster > Blog > administration > Nemt arbejde med komplekse advarsler. Eller historien om skabelsen af ​​Balerter

Nemt arbejde med komplekse advarsler. Eller historien om skabelsen af ​​Balerter

Nemt arbejde med komplekse advarsler. Eller historien om skabelsen af ​​Balerter

Alle elsker alarmer.

Det er selvfølgelig meget bedre at få besked, når noget er sket (eller blevet rettet), end at sidde og kigge på grafer og lede efter uregelmæssigheder.

Og der er skabt mange værktøjer til dette. Alertmanager fra Prometheus-økosystemet og vmalert fra VictoriaMetrics produktgruppe. Zabbix-meddelelser og advarsler i Grafana. Selvskrevne scripts i bash- og Telegram-bots, der med jævne mellemrum trækker en URL op og fortæller dig, hvis der er noget galt. Meget af alt.

Vi i vores virksomhed brugte også forskellige løsninger, indtil vi løb ind i kompleksiteten, eller rettere umuligheden, ved at skabe komplekse, sammensatte alarmer. Det, vi ønskede, og det, vi endte med at gøre, er under skæringen. TLDR: Sådan så open source-projektet ud Balerpresser

I temmelig lang tid levede vi godt med alarmer konfigureret i Grafana. Ja, det er ikke den bedste måde. Det anbefales altid at bruge nogle specialiserede løsninger, såsom Alertmanager. Og vi så også mod at flytte mere end én gang. Og så, lidt efter lidt, ville vi have mere.

Sig, hvornår et bestemt diagram er faldet/øget med XX% og har været der i N minutter sammenlignet med den foregående periode på M timer? Det ser ud til, at du kan prøve at implementere dette med Grafana eller Alertmanager, men det er ikke helt nemt. (Eller måske er det ikke muligt, vil jeg ikke sige nu)

Tingene bliver endnu mere komplicerede, når alarmbeslutningen skal træffes baseret på data fra forskellige kilder. Live eksempel:

Vi tjekker dataene fra to Clickhouse-databaser, sammenligner dem derefter med nogle data fra Postgres og beslutter os for en advarsel. Signalér eller annuller

Vi har akkumuleret en del lignende ønsker for, at vi skal tænke over vores beslutning. Og så forsøgte vi at kompilere den første liste over krav/egenskaber for denne tjeneste, som endnu ikke er oprettet.

  • få adgang til forskellige datakilder. For eksempel Prometheus, Clickhouse, Postgres

  • sende alarmer til forskellige kanaler - telegram, slack osv.

  • i tankeprocessen blev det klart, at jeg ikke ønskede en deklarativ beskrivelse, men evnen til at skrive manuskripter

  • køre scripts efter en tidsplan

  • nem opdatering af scripts uden at genstarte tjenesten

  • evnen til på en eller anden måde at udvide funktionaliteten uden at genopbygge tjenesten fra kildekoder

Denne liste er omtrentlig og højst sandsynligt ikke særlig nøjagtig. Nogle punkter ændrede sig, nogle døde. Alt er som det plejer.

Faktisk er det sådan, Balerters historie begyndte.

Nemt arbejde med komplekse advarsler. Eller historien om skabelsen af ​​Balerter

Jeg vil prøve at beskrive kort, hvad der skete til sidst, og hvordan det fungerer. (Ja, det er selvfølgelig ikke slutningen. Der er mange planer for produktudvikling. Jeg stopper lige ved i dag)

Hvordan fungerer det?

Du skriver et script i Lua, hvor du eksplicit sender anmodninger (til Prometheus, Clickhouse osv.). Du modtager svar og på en eller anden måde behandler og sammenligner dem. Slå derefter en form for advarsel til/fra. Balerter sender selv en notifikation til de kanaler, du har konfigureret (E-mail, telegram, slack osv.). Scriptet udføres med specificerede intervaller. Og... generelt er det alt)

Det er bedst at vise med et eksempel:

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

Hvad sker der her:

  • vi angiver, at dette script skal udføres hvert 10. sekund

  • angiv navnet på scriptet (til API, til visning i logfiler, til brug i test)

  • tilslut modulet til udlæsning af logfiler

  • tilslut et modul for at få adgang til klikhuset med navnet ch1 (selve forbindelsen er konfigureret i konfigurationen)

  • send en anmodning til clickhouse

  • i tilfælde af en fejl, viser vi en besked i loggen og afslutter

  • sammenligne forespørgselsresultatet med en konstant (i et levende eksempel kunne vi f.eks. få denne værdi fra Postgres-databasen)

  • aktivere eller deaktivere alarm med ID rps-min-limit

  • du vil modtage en meddelelse, hvis alarmstatussen er ændret

Eksemplet er ganske enkelt og forståeligt. Men selvfølgelig kan scripts i det virkelige liv være ret lange og komplekse. Det er nemt at blive forvirret og lave fejl.

Derfor er et logisk ønske modnet - at kunne skrive test til dine manuskripter. Og i version v0.4.0 dukkede dette op.

Test af scripts

Eksempeltest for vores script fra eksemplet ovenfor:

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

Trin for trin:

  • angiv navnet på det manuskript, som testen er skrevet til

  • testnavn (til logfiler)

  • tilslutte testmodulet

  • vi siger, hvilket resultat der skal returneres for en specifik anmodning til klikhuset ch1

  • vi tjekker, at alarmen (fejl) rps-min-grænsen med den angivne besked blev kaldt

  • kontrollere, at rps-min-limit advarslen ikke var deaktiveret (succes)

Hvad kan Balerter ellers?

Jeg vil forsøge at komme ind på de vigtigste, efter min mening, Balerter-færdigheder. Du kan se alt i detaljer på den officielle hjemmeside https://balerter.com

  • modtage data fra

    • klikhus

    • Postgres

    • mysql

    • Prometheus

    • Loke

  • sende notifikationer til kanaler

    • slæk

    • telegram

    • syslog

    • underrette (brugergrænseflademeddelelser på din computer)

    • e-mail

    • disharmoni

  • byg grafer baseret på dine data, upload billedet til S3-kompatibelt lager og vedhæft det til notifikationer (Eksempel med billeder)

  • giver dig mulighed for at udveksle data mellem scripts - global nøgle-/værdilagring

  • skriv dine egne biblioteker i Lua og brug dem i scripts (som standard leveres lua-biblioteker til at arbejde med json, csv)

  • send HTTP-anmodninger fra dine scripts (og modtag selvfølgelig svar)

  • giver en API (endnu ikke så funktionel, som vi ønsker)

  • eksporterer metrics i Prometheus-format

Hvad vil du ellers gerne kunne?

Det er allerede klart, at brugere og vi ønsker muligheden for at kontrollere lanceringen af ​​scripts ved hjælp af syntaksen cron. Dette vil blive gjort før version v1.0.0

Jeg vil gerne understøtte flere datakilder og underretningsleveringskanaler. For eksempel vil nogen helt sikkert savne MongoDB. Elastisk Søg efter nogle. Send SMS og/eller foretag opkald til din mobiltelefon. Vi ønsker at kunne modtage scripts ikke kun fra filer, men også for eksempel fra en database. I sidste ende ønsker vi en mere brugervenlig hjemmeside og bedre dokumentation for projektet.

Nogen mangler altid noget) Her stoler vi på fællesskabets anmodning for at kunne prioritere korrekt. Og til hjælp fra fællesskabet til at realisere alt

Afslutningsvis

Vi bruger Balerpresser Jeg har haft det i et stykke tid nu. Snesevis af scripts beskytter vores sindsro. Jeg håber, at dette arbejde vil være nyttigt for en anden.

Og velkommen med dit Issue og PR.

Kilde: www.habr.com

Tilføj en kommentar