🥇Lucru ușor cu alertele complexe. Sau povestea creării Balerter

Toată lumea iubește alertele.

Sigur, este mult mai bine să primești o notificare când se întâmplă (sau se repară) ceva, decât să stai și să te uiți la grafice în căutarea anomaliilor.

Și au fost create destule instrumente pentru asta. Alertmanager din ecosistemul Prometheus și vmalert din grupul de produse VictoriaMetrics. Notificările Zabbix și alertele din Grafana. Scripturi personalizate în bash și boți Telegram care interoghează periodic un URL și spun dacă ceva nu este în regulă. O mulțime de opțiuni.

Și noi, în compania noastră, am folosit diverse soluții până când ne-am lovit de complexitate sau, mai degrabă, imposibilitatea de a crea alerte compuse, așa cum ne doream. Ce ne-am dorit și ce am realizat în cele din urmă — detalii mai jos. TLDR: Așa a apărut proiectul open source Balerter

O perioadă destul de lungă am avut alerte configurate în Grafana și ne-am descurcat destul de bine. Da, acesta nu este cel mai bun mod. Este întotdeauna recomandat să folosești soluții specializate, cum ar fi Alertmanager. De mai multe ori ne-am gândit la o migrare. Apoi, încetul cu încetul, am început să ne dorim mai mult.

Să spui când un grafic a scăzut/creșt pe XX% și rămâne acolo de N minute comparativ cu perioada anterioară de M ore? Asta pare că poate fi realizat cu Grafana sau Alertmanager, dar nu este foarte simplu. (Și s-ar putea să nu fie posibil, nu pot spune acum)

Totul devine și mai complicat când decizia de alertă trebuie să se bazeze pe date din diverse surse. Un exemplu concret:

Verificăm datele din două baze Clickhouse, apoi le comparăm cu unele date din Postgres și luăm o decizie în legătură cu alertarea. Semnalăm sau anulăm

Am acumulat destule dorințe de acest gen pentru a începe să ne gândim la propria soluție. Așa că am încercat să întocmim prima listă de cerințe/funcționalități pentru acest serviciu, care nu a fost încă creat.

să ne adresăm la diverse surse de date. De exemplu, Prometheus, Clickhouse, Postgres
să trimitem alerte în diverse canale — telegram, slack etc.
în procesul de reflecție, a devenit clar că ne dorim nu o descriere declarativă, ci posibilitatea de a scrie scripturi
să ruleze scripturi conform unui program
actualizare ușoară a scripturilor fără a reporni serviciul
posibilitatea de a extinde funcționalitatea fără a recompila serviciul din surse

Aceasta este o listă aproximativă și, cel mai probabil, nu foarte precisă. Unele puncte s-au modificat, altele au căzut. Totul este ca de obicei.

Așa a început povestea Balerter.

Voi încerca să descriu pe scurt ce a ieșit până acum și cum funcționează. (Da, bineînțeles, acesta nu este finalul. Am multe planuri pentru dezvoltarea produsului. Mă voi opri la ziua de azi)

Cum funcționează?

Scrieți un script în Lua, unde trimiteți explicit cereri (în Prometheus, Clickhouse etc.). Primiți răspunsurile, le procesați cumva și le comparați. Apoi activați/dezactivați un anumit alert. Balerter va trimite notificarea în canalele pe care le-ați configurat (Email, telegram, slack etc.). Scriptul se execută cu o periodicitate specificată. Și... cam asta e)

Cel mai bine se arată printr-un exemplu:

-- @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("eroare la interogarea 'ch1' în clickhouse: " .. err)
    return
end

local resultRPS = res[1].rps

if resultRPS < minRequestsRPS then
    alert.error("rps-min-limit", "Numărul de cereri RPS este foarte mic: " .. tostring(resultRPS))
else
    alert.success("rps-min-limit", "Numărul de cereri RPS este ok")
end

Ce se întâmplă aici:

indicăm că acest script trebuie să fie executat la fiecare 10 secunde
indicăm numele scriptului (pentru API, pentru afișarea în jurnale, pentru utilizare în teste)
importăm modulul pentru a scrie jurnale
importăm modulul pentru accesul la Clickhouse cu numele ch1 (conexiunea este configurată în setările)
trimitem o cerere la Clickhouse
în caz de eroare, scriem un mesaj în jurnal și ieșim
comparam rezultatul cererii cu constantă (în exemplul real, am putea obține această valoare, de exemplu, dintr-o bază de date Postgres)
activăm sau dezactivăm alertul cu ID rps-min-limit
veți primi o notificare dacă starea alertului se schimbă

Exemplul este destul de simplu și ușor de înțeles. Totuși, desigur, în viața reală, scripturile pot fi oarecum complicate și aglomerate. Este ușor să te pierzi în ele și să faci greșeli.

De aceea a apărut o dorință logică - de a avea posibilitatea de a scrie teste pentru scripturile tale. Și în versiunea v0.4.0 aceasta a apărut.

Testarea scripturilor

Exemplu de test pentru scriptul nostru din exemplul de mai sus:

-- @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', 'Numărul de cereri RPS este foarte mic: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Numărul de cereri RPS este ok')

Pas cu pas:

indică numele scriptului pentru care este scris testul
numele testului (pentru jurnale)
importăm modulul de testare
discutăm despre rezultatul care trebuie să fie returnat la o anumită interogare în ClickHouse ch1
verificăm că alerta (eroare) rps-min-limit a fost apelată cu mesajul specificat
verificăm că alerta rps-min-limit nu a fost dezactivată (succes)

Ce altceva poate face Balerter?

Voi încerca să ating cele mai importante abilități ale Balerter, conform opiniei mele. Puteți verifica totul în detaliu pe site-ul oficial https://balerter.com

a obține date din
- clickhouse
- postgres
- mysql
- prometheus
- loki
a trimite notificări către canale
- slack
- telegram
- syslog
- notiify (notificări UI pe computerul dvs.)
- email
- discord
a construi grafice pe baza datelor dvs., a încărca imagini într-un stocare compatibilă S3 și a le atașa notificărilor (Exemplu cu imagini)
permițând schimbul de date între scripturi - un depozit global Key/Value
a scrie propriile biblioteci în Lua și a le folosi în scripturi (bibliotecile lua pentru lucrul cu json, csv sunt livrate implicit)
a trimite cereri HTTP din scripturile dvs. (și, bineînțeles, a primi răspunsuri)
oferă API (în prezent nu este la fel de funcțional pe cât ne-am dori)
exportă metrict în format Prometheus

Și ce ne-am dori să putem face în plus?

Este deja clar că utilizatorii și noi dorim posibilitatea de a gestiona lansarea scripturilor prin sintaxă cron. Acest lucru va fi realizat înainte de versiunea v1.0.0

Ne dorim să susținem mai multe surse de date și canale de livrare a notificărilor. De exemplu, cuiva sigur îi va lipsi MongoDB. Altcuiva Elastic Search. A trimite SMS și/sau a suna pe mobil. Vrem să putem obține scripturi nu doar din fișiere, ci și, de exemplu, din baze de date. În cele din urmă, vrem un site mai prietenos pentru proiect și o documentație mai bună.

Întotdeauna există pe cineva care să îi lipsească ceva) Aici ne punem speranțele în solicitările comunității pentru a stabili corect prioritățile. Și în ajutorul comunității pentru a realiza totul

În concluzie

Folosim Balerter la noi deja de ceva vreme. Zeci de scripturi ne protejează liniștea. Sper că această muncă va fi utilă și altora.

Și bun venit cu problemele și PR-urile dvs.

Sursa: habr.com