Lätt arbete med komplexa varningar. Eller historien bakom Balerter

Alla älskar notifieringar.

Självklart är det mycket bättre att få en notifikation när något har hänt (eller fixats) än att sitta och titta på diagram och leta efter anomalier.

Och det har skapats en hel del verktyg för detta. Alertmanager från Prometheus-ekosystemet och vmalert från VictoriaMetrics-produktgruppen. Zabbix-notifieringar och alertar i Grafana. Skript på bash och Telegram-botar som regelbundet kollar en viss URL och meddelar om något är fel. Det finns mycket.

Vi, i vårt företag, använde också olika lösningar tills vi stötte på svårigheter, eller snarare, oförmågan att skapa komplexa, sammansatta alertar. Vad vi ville och vad vi slutligen gjorde - under rubriken. TLDR: Så föddes open source-projektet Balerter

Vi levde ganska länge bra med alertar som var inställda i Grafana. Ja, det är inte den bästa vägen. Det rekommenderas alltid att använda några specialiserade lösningar, som Alertmanager. Och vi har också flera gånger övervägt att flytta. Och sedan, sakta men säkert, började vi vilja ha mer.

Att säga när en viss graf har fallit/ökat med XX% och har varit där i N minuter jämfört med den föregående perioden på M timmar? Det verkar som att man kan försöka genomföra detta med Grafana eller Alertmanager, men det är ganska komplicerat. (Eller kanske inte, jag kan inte säga just nu)

Allt blir ännu mer komplicerat när beslutet om en alert måste fattas baserat på data från olika källor. Ett aktuellt exempel:

Vi kontrollerar data från två Clickhouse-databaser, jämför dem sedan med viss data från Postgres och fattar beslut om alerten. Signalera eller avbryt.

Vi har samlat ganska många liknande önskemål så att vi började tänka på en egen lösning. Och då försökte vi sammanställa en första lista över krav/möjligheter för denna, ännu oexisterande, tjänst.

• att kontakta olika datakällor. Till exempel, Prometheus, Clickhouse, Postgres.

• skicka alertar till olika kanaler - telegram, slack osv.

• i tankeprocessen blev det klart att vi ville ha möjligheten att skriva skript istället för en deklarativ beskrivning.

• köra skript enligt schema.

• lätta att uppdatera skript utan att starta om tjänsten.

• möjlighet att utöka funktionaliteten utan att behöva kompilera om tjänsten från källkoden.

Detta är en preliminär lista och är troligen inte helt exakt. Några punkter har förändrats, andra har försvunnit. Som vanligt.

Egentligen så började historien om Balerter just så.

Jag ska försöka kort beskriva vad som blev resultatet och hur det fungerar. (Ja, det är klart, detta är inte slutet. Många planer för produktutveckling. Jag stannar bara vid dagens datum)

Hur fungerar det?

Du skriver ett skript i Lua där du tydligt skickar förfrågningar (till Prometheus, Clickhouse etc.). Du får svar och bearbetar dem på något sätt och jämför. Efter det aktiverar eller inaktiverar du någon alert. Balerter skickar själv meddelandet till de kanaler du har konfigurerat (E-post, Telegram, Slack etc.). Skriptet körs med en angiven frekvens. Och… det är egentligen allt)

Det är bäst att visa med ett exempel:

-- @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 < minRequestsRPS then
    alert.error("rps-min-limit", "Requests RPS är väldigt låga: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end 

Vad som händer här:

• vi anger att det här skriptet ska köras var tionde sekund

• vi anger namnet på skriptet (för API, för visning i loggar, för användning i tester)

• vi laddar modulen för loggutskrift

• vi laddar modulen för att få tillgång till Clickhouse med namnet ch1 (själv anslutningen konfigureras i konfigurationsfilen)

• vi skickar en förfrågning till Clickhouse

• i händelse av ett fel – skriver vi ett meddelande i loggen och går ut

• vi jämför resultatet av förfrågningen med konstanten (i ett verkligt exempel skulle vi kunna få detta värde exempelvis från databasen Postgres)

• vi aktiverar eller inaktiverar alerten med ID rps-min-limit

• du får ett meddelande om statusen på alerten har ändrats

Exemplet är ganska enkelt och tydligt. Men i verkligheten kan skripten naturligtvis bli ganska komplexa och svåra. Det är lätt att bli förvirrad och göra misstag.

Därför föddes en rimlig önskan – att kunna skriva tester för sina skript. Och i version v0.4.0 kom detta.

Testning av skript

Ett exempel på test för vårt skript från ovanstående exempel:

-- @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 är väldigt låga: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')

Steg för steg:

• vi anger namnet på skriptet för vilket testet är skrivet

• namnet på testet (för loggar)

• vi laddar testningsmodulen

• Vi pratar om vilket resultat som ska returneras vid en viss fråga till ClickHouse. ch1

• Vi kontrollerar att en alert (error) rps-min-limit har anropats med det angivna meddelandet.

• Vi kontrollerar att alerten rps-min-limit inte har stängts av (success).

Vad mer kan Balerter göra?

Jag ska försöka ta upp de viktigaste funktionerna enligt min åsikt. Du kan titta på allt i detalj på den officiella webbplatsen. https://balerter.com

• hämta data från

  • clickhouse

  • postgres

  • mysql

  • prometheus

  • loki

• skicka meddelanden till kanaler

  • slack

  • telegram

  • syslog

  • notiify (UI-meddelanden på din dator)

  • e-post

  • discord

• bygga grafer baserade på dina data, ladda upp bilder till S3-kompatibel lagring och bifoga till meddelanden (Exempel med bilder)

• möjliggör datadelning mellan skript – globalt Key/Value-lagringssystem.

• skriva egna bibliotek i Lua och använda dem i skripten (standard kommer lua-bibliotek för att arbeta med json, csv).

• skicka HTTP-förfrågningar från dina skript (och självklart ta emot svar också).

• tillhandahåller API (ännu inte så funktionellt som önskat).

• exporterar mätvärden i Prometheus-format.

Vad skulle vi vilja kunna mer?

Det är redan tydligt att användarna och vi vill ha möjlighet att styra körningen av skripten med hjälp av syntaxen cron. Detta kommer att göras före version v1.0.0.

Vi vill stödja fler datakällor och kanaler för att skicka meddelanden. Till exempel kommer någon definitivt att sakna MongoDB. Någon annan Elastic Search. Skicka SMS och/eller göra samtal till mobiltelefoner. Vi vill kunna hämta skript inte bara från filer utan också, till exempel, från databaser. I slutändan vill vi ha en mer användarvänlig webbplats för projektet och bättre dokumentation.

Det saknas alltid något för någon) Här hoppas vi på feedback från gemenskapen för att korrekt ställa in prioriteringarna. Och på gemenskapens hjälp för att genomföra allt.

Avslutningsvis

Vi använder Balerter har funnits hos oss ganska länge nu. Dussintals skript står vakt över vår frid. Jag hoppas att detta arbete kommer att vara till nytta för andra.

Och välkommen med dina issue och PR.

Källa: habr.com