Eenvoudig omgaan met complexe waarschuwingen. Of het verhaal van de creatie van Balerter

Iedereen houdt van meldingen.

Natuurlijk is het veel beter om een notificatie te krijgen wanneer er iets is gebeurd (of gerepareerd is), dan te zitten kijken naar grafieken en anomalieën te zoeken.

Er zijn veel tools voor dit doel ontwikkeld. Alertmanager uit het Prometheus-ecosysteem en vmalert uit de VictoriaMetrics-productgroep. Notificaties van Zabbix en meldingen in Grafana. Zelfgeschreven scripts in bash en Telegram-bots die regelmatig een bepaalde URL aanroepen en zeggen als er iets mis is. Heel veel opties.

Wij, in ons bedrijf, hebben ook verschillende oplossingen gebruikt totdat we stuitten op de complexiteit, of beter gezegd, de onmogelijkheid om complexe, samengestelde meldingen te creëren. Wat we wilden en wat we uiteindelijk hebben gedaan — onder de kat. TLDR: Zo is het open source-project ontstaan Balerter

Een lange tijd leefden we goed met meldingen ingesteld in Grafana. Ja, dit is niet de beste weg. Het is altijd aan te raden om gespecialiseerde oplossingen te gebruiken, zoals Alertmanager. En we hebben ook meerdere keren gekeken naar migratie. En toen, langzaam maar zeker, wilden we meer.

Zeggen wanneer een bepaalde grafiek is gedaald/stegen met XX% en al N minuten daar is vergeleken met de vorige periode van M uren? Dat lijkt iets dat je zou kunnen proberen te implementeren met Grafana of Alertmanager, maar het is vrij lastig. (Of misschien is het niet mogelijk, dat kan ik nu niet zeggen)

Alles wordt nog ingewikkelder wanneer de beslissing over een melding moet worden genomen op basis van gegevens uit verschillende bronnen. Een levend voorbeeld:

We controleren gegevens uit twee Clickhouse-databases, vergelijken het vervolgens met enkele gegevens uit Postgres en nemen een beslissing over de melding. Signaliseren of annuleren.

We hebben genoeg van dit soort wensen verzameld, dat we over onze eigen oplossing zijn gaan nadenken. En toen hebben we geprobeerd een eerste lijst van vereisten/mogelijkheden op te stellen voor deze nog niet gerealiseerde service.

• toegang krijgen tot verschillende gegevensbronnen. Bijvoorbeeld Prometheus, Clickhouse, Postgres.

• meldingen versturen naar verschillende kanalen — telegram, slack, enzovoort.

• during the thinking process it became clear that we wanted not a declarative description, but the possibility of writing scripts.

• scripts scheduled to run.

• easy updating of scripts without restarting the service.

• the ability to somehow extend functionality without rebuilding the service from source code.

Dit is een indicatieve lijst en, waarschijnlijk, niet heel nauwkeurig. Sommige punten zijn veranderd, andere zijn komen te vervallen. Alles zoals gewoonlijk.

Eigenlijk is dit precies hoe het verhaal van Balerter begon.

Ik zal proberen kort te beschrijven wat het resultaat is en hoe het werkt. (Ja, natuurlijk is dit niet het einde. Er zijn veel plannen voor productontwikkeling. Ik stop gewoon bij vandaag.)

How does it work?

Je schrijft een script in Lua, waar je expliciet verzoeken verstuurt (in Prometheus, Clickhouse, enz.). Je ontvangt antwoorden en verwerkt en vergelijkt ze op een bepaalde manier. Vervolgens schakel je een bepaalde alert in of uit. Balerter zal automatisch meldingen versturen naar de kanalen die je hebt ingesteld (Email, Telegram, Slack, enz.). Het script wordt uitgevoerd met de opgegeven periodiciteit. En… dat is in feite alles.)

Het beste is om het met een voorbeeld te laten zien:

-- @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 zijn erg laag: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Requests RPS ok")
end 

Wat hier gebeurt:

• we geven aan dat dit script elke 10 seconden moet worden uitgevoerd

• we geven de naam van het script op (voor API, weergeven in logs, voor gebruik in tests)

• we laden de module voor logboekregistratie

• we laden de module voor toegang tot Clickhouse met de naam ch1 (de eigenlijke verbinding wordt ingesteld in de configuratie)

• we versturen een verzoek naar Clickhouse

• in geval van een fout geven we een bericht in het logboek weer en verlaten we

• we vergelijken het resultaat van de aanvraag met een constante (in een live voorbeeld zouden we deze waarde bijvoorbeeld uit een Postgres-database kunnen halen)

• we schakelen de alert met ID rps-min-limit

• je krijgt een melding als de status van de alert verandert

Het voorbeeld is vrij eenvoudig en duidelijk. Echter, in de praktijk kunnen scripts behoorlijk uitgebreid en complex zijn. Het is gemakkelijk om je daarin te verliezen en fouten te maken.

Daarom is de wens ontstaan om tests voor je scripts te kunnen schrijven. En in versie v0.4.0 is dit gerealiseerd.

Script testen

Een voorbeeldtest voor ons script uit het bovenstaande voorbeeld:

-- @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 zijn erg laag: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')

Stap voor stap:

• we geven de naam van het script op waarvoor de test is geschreven

• de naam van de test (voor de logs)

• we laden de testmodule

• we discuss what result to return for a specific query to ClickHouse ch1

• we check that the alert (error) rps-min-limit was triggered with the specified message

• we check that the rps-min-limit alert was not disabled (success)

What else can Balerter do?

I will try to touch on the most important skills of Balerter, in my opinion. You can view everything in detail on the official website https://balerter.com

• to retrieve data from

  • clickhouse

  • postgres

  • mysql

  • prometheus

  • loki

• to send notifications to channels

  • slack

  • telegram

  • syslog

  • notiify (UI notifications on your computer)

  • e-mail

  • discord

• to build graphs based on your data, upload images to S3 compatible storage, and attach them to notifications (Example with images)

• allows data exchange between scripts — a global Key/Value storage

• to write your libraries in Lua and use them in scripts (default Lua libraries are included for working with json, csv)

• to send HTTP requests from your scripts (and of course receive responses)

• provides an API (not as functional as we would like for now)

• exports metrics in Prometheus format

What else would we like to be able to do?

It is already clear that users and we want the ability to control script execution using syntax cron. This will be done before version v1.0.0

We want to support more data sources and notification delivery channels. For example, some will definitely miss MongoDB. Others will need Elastic Search. To send SMS and/or make calls to mobile phones. We want to be able to receive scripts not only from files, but also, for example, from a database. Ultimately, we want a more user-friendly website for the project and better documentation.

Someone always lacks something) Here we hope for community feedback to properly prioritize. And for community assistance to implement everything

Ter conclusie

Wij gebruiken Balerter has been around for quite a while. Dozens of scripts stand guard over our peace of mind. I hope this work will be useful to someone else.

And welcome with your Issues and PR.

Bron: habr.com