Alle elsker alerter.
Selvfølgelig er det meget bedre at få en meddelelse, når noget er sket (eller er blevet løst), end at sidde og kigge på grafer og lede efter anomalier.
Og der er mange værktøjer skabt til dette. Alertmanager fra Prometheus-økosystemet og vmalert fra VictoriaMetrics-produktgruppen. Zabbix-beskeder og alerter i Grafana. Håndskrevne bash-scripts og Telegram-bots, der periodisk henter en bestemt URL og informerer, hvis noget er galt. Der er meget.
Vi i vores virksomhed har også brugt forskellige løsninger, indtil vi stødte på kompleksiteten, eller rettere sagt umuligheden af at oprette komplekse, sammensatte alerter. Hvad vi ønskede, og hvad vi i sidste ende har gjort - mere om dette nedenfor. TLDR: Så blev open source-projektet
I lang tid havde vi det godt med alerterne, der var opsat i Grafana. Ja, det er ikke den bedste vej. Det anbefales altid at bruge nogle specialiserede løsninger som Alertmanager. Og vi har også set mod at flytte flere gange. Og så, langsomt, ønskede vi os mere.
At sige, hvornår en given graf er faldet/stiget med XX% og har været der i N minutter sammenlignet med den forrige periode på M timer? Det virker som noget, der kan realiseres med Grafana eller Alertmanager, men det er ret svært. (Eller måske kan det ikke lade sig gøre, jeg kan lige nu ikke sige det.)
Det bliver endnu mere kompliceret, når beslutningen om en alert skal træffes ud fra data fra forskellige kilder. Et konkret eksempel:
Vi kontrollerer data fra to Clickhouse-databaser, sammenligner derefter med nogle data fra Postgres og træffer en beslutning om, hvorvidt vi skal sende en alert. Signalisere eller annullere.
Vi har samlet mange sådanne ønsker, så vi begyndte at tænke på vores eget løsning. Og så forsøgte vi at lave den første liste over krav/muligheder for denne endnu ikke eksisterende service.
At kunne tilgå forskellige datakilder. For eksempel Prometheus, Clickhouse, Postgres.
At sende alerter til forskellige kanaler - telegram, slack osv.
I løbet af overvejelserne blev det klart, at vi ikke ønsker en deklarativ beskrivelse, men muligheden for at skrive scripts.
At køre scripts efter en tidsplan.
Nem opdatering af scripts uden at genstarte tjenesten.
Muligheden for at udvide funktionaliteten uden at skulle genkompilere tjenesten fra kildekoderne.
Dette er en vejledende liste og er sandsynligvis ikke helt præcis. Nogle punkter blev ændret, mens andre døde. Som sædvanligt.
Faktisk er det præcis sådan, historien om Balerter begyndte.
Jeg vil kort beskrive, hvad resultatet blev, og hvordan det fungerer. (Ja, selvfølgelig er det ikke slutningen. Der er mange planer for produktudviklingen. Jeg vil blot koncentrere mig om i dag)
Hvordan fungerer det?
Du skriver et script i Lua, hvor du tydeligt sender forespørgsler (til Prometheus, Clickhouse osv.). Du modtager svar og behandler dem på en eller anden måde og sammenligner dem. Derefter tænder/slukker du en eller anden alert. Balerter sender selv notifikationer til de kanaler, du har indstillet (Email, Telegram, Slack osv.). Scriptet kører med en angivet frekvens. Og… det er faktisk det hele)
Det er bedst at vise det 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' forespørgselsfejl: " .. err)
return
end
local resultRPS = res[1].rps
if resultRPS < minRequestsRPS then
alert.error("rps-min-limit", "Requests RPS er meget lave: " .. tostring(resultRPS))
else
alert.success("rps-min-limit", "Requests RPS ok")
end Hvad der sker her:
vi angiver, at dette script skal køre hvert 10. sekund
vi angiver navnet på scriptet (til API, til visning i logs, til brug i tests)
vi tilslutter modulet til logføring
vi tilslutter modulet til adgang til Clickhouse med navnet
ch1(selve forbindelsen konfigureres i konfigurationsfilen)vi sender en forespørgsel til Clickhouse
i tilfælde af fejl - vi logger en besked og afslutter
vi sammenligner forespørgselsresultatet med konstanten (i et reelt eksempel kunne vi f.eks. få denne værdi fra en Postgres-database)
vi tænder eller slukker alerten med ID
rps-min-limitdu vil modtage en notifikation, hvis alertens status ændres
Eksemplet er ret simpelt og forståeligt. Men naturligvis kan scripts i virkeligheden være ret omfattende og komplekse. Det er let at blive forvirret og lave fejl.
Derfor er ønsket om at have mulighed for at skrive tests til sine scripts opstået. Og i version v0.4.0 er dette blevet tilgængeligt.
Testning af scripts
Et eksempel på test for vores script fra ovenstående eksempel:
-- @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 er meget lave: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')Trinserne:
vi angiver navnet på scriptet, som testen er skrevet til
navn på testen (til logs)
vi tilslutter testmodulet
Vi taler om, hvilket resultat der skal returneres ved en bestemt forespørgsel til ClickHouse
ch1Vi kontrollerer, at alerten (fejl) rps-min-limit blev kaldt med den angivne besked
Vi kontrollerer, at alerten rps-min-limit ikke blev deaktiveret (success)
Hvad kan Balerter ellers?
Jeg vil forsøge at berøre de vigtigste funktioner i Balerter, efter min mening. Du kan se alt i detaljer på den officielle hjemmeside
modtage data fra
clickhouse
postgres
mysql
prometheus
loki
sende meddelelser til kanaler
slack
telegram
syslog
notiify (UI-meddelelser på din computer)
email
discord
bygge grafer på dine data, uploade billeder til et S3-kompatibelt lager og vedhæfte dem til meddelelser ()
giver mulighed for at udveksle data mellem scripts — globalt Key/Value-lager
skrive dine egne biblioteker i Lua og bruge dem i scripts (der leveres som standard lua-biblioteker til arbejde med json, csv)
sende HTTP-forespørgsler fra dine scripts (og modtage svar, naturligvis)
tilbyder API (stadig ikke så funktionelt, som vi gerne ville)
eksporterer metrics i Prometheus-format
Hvad vil du gerne kunne endnu?
Det er allerede klart, at brugerne og vi ønsker muligheden for at styre kørsel af scripts med syntaks cron. Det vil blive gjort inden version v1.0.0
Vi ønsker at understøtte flere datakilder og kanaler til levering af meddelelser. For eksempel vil nogen helt sikkert mangle MongoDB. Nogen Elastic Search. Sende SMS og/eller foretage opkald til mobiltelefonen. Vi vil gerne kunne modtage scripts ikke kun fra filer, men også f.eks. fra databaser. Til sidst ønsker vi en mere brugervenlig hjemmeside til projektet og bedre dokumentation.
Alle mangler altid noget) Her håber vi på samfundets forespørgsler for at opstille de rigtige prioriteter. Og samfundets hjælp til at realisere alt
Afslutningsvis
Vi bruger har allerede haft det i et stykke tid. Duskere af scripts står vagt om vores fred. Jeg håber, dette arbejde vil være nyttigt for nogen andre.
Og velkommen med dine problemer og PR.
Kilde: habr.com
