ProHoster > Bloc > Administració > Treball fàcil amb alertes complexes. O la història de Balerter

Treball fàcil amb alertes complexes. O la història de Balerter

Treball fàcil amb alertes complexes. O la història de Balerter

A tothom li agraden les alertes.

Per descomptat, és molt millor rebre una notificació quan alguna cosa ha passat (o s'ha solucionat) que asseure's a mirar gràfics i buscar anomalies.

I s'han creat moltes eines per a això. Alertmanager de l'ecosistema Prometheus i vmalert del grup de productes VictoriaMetrics. Notificacions i alertes de Zabbix a Grafana. Seqüències d'ordres escrits personalment en robots bash i Telegram que periòdicament obren algun URL i us diuen si hi ha alguna cosa malament. Molt de tot.

Nosaltres, a la nostra empresa, també vam fer servir diferents solucions fins que ens vam trobar amb la complexitat, o, millor dit, amb la impossibilitat de crear alertes complexes i compostes. El que volíem i el que vam acabar fent està per sota del tall. TLDR: Així va aparèixer el projecte de codi obert Balerter

Durant força temps vam viure bé amb les alertes configurades a Grafana. Sí, aquesta no és la millor manera. Sempre es recomana utilitzar algunes solucions especialitzades, com ara Alertmanager. I també vam mirar més d'una vegada per moure'ns. I després, a poc a poc, vam voler més.

Digues quan un determinat gràfic ha baixat/ha augmentat un XX% i ha estat allà durant N minuts en comparació amb el període anterior de M hores? Sembla que podeu intentar implementar-ho amb Grafana o Alertmanager, però no és gens fàcil. (O potser no és possible, no ho diré ara)

Les coses es compliquen encara més quan la decisió d'alerta s'ha de prendre a partir de dades de diferents fonts. Exemple en viu:

Comprovem les dades de dues bases de dades de Clickhouse, després les comparem amb algunes dades de Postgres i decidim una alerta. Senyal o cancel·la

Hem acumulat molts desitjos similars perquè pensem en la nostra decisió. I després vam intentar compilar la primera llista de requisits/capacitats d'aquest servei, que encara no s'ha creat.

  • accedir a diferents fonts de dades. Per exemple, Prometeu, Clickhouse, Postgres

  • enviar alertes a diversos canals: telegrama, slack, etc.

  • en el procés de pensament, va quedar clar que no volia una descripció declarativa, sinó la capacitat d'escriure guions

  • executant scripts segons una programació

  • actualització fàcil dels scripts sense reiniciar el servei

  • la capacitat d'ampliar d'alguna manera la funcionalitat sense reconstruir el servei a partir dels codis font

Aquesta llista és aproximada i probablement no sigui molt precisa. Alguns punts van canviar, alguns van morir. Tot és com de costum.

De fet, així va començar la història de Balerter.

Treball fàcil amb alertes complexes. O la història de Balerter

Intentaré descriure breument què va passar al final i com funciona. (Sí, per descomptat, aquest no és el final. Hi ha molts plans per al desenvolupament de productes. M'aturaré avui)

Com funciona?

Escriu un script a Lua on envieu sol·licituds explícitament (a Prometheus, Clickhouse, etc.). Rebreu respostes i d'alguna manera les processeu i compareu. A continuació, activeu/desactiveu algun tipus d'alerta. El mateix Balerter enviarà una notificació als canals que hàgiu configurat (correu electrònic, telegrama, slack, etc.). L'script s'executa a intervals especificats. I... en general, això és tot)

El millor és mostrar-ho amb un exemple:

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

Que està passant aquí:

  • indiquem que aquest script s'ha d'executar cada 10 segons

  • indiqueu el nom de l'script (per a l'API, per mostrar-lo als registres, per utilitzar-lo en proves)

  • connecteu el mòdul per a la sortida de registres

  • connecteu un mòdul per accedir a la casa de clics amb el nom ch1 (la connexió en si es configura a la configuració)

  • enviar una sol·licitud a Clickhouse

  • en cas d'error, mostrem un missatge al registre i sortim

  • compareu el resultat de la consulta amb una constant (en un exemple en directe, podríem obtenir aquest valor, per exemple, de la base de dades de Postgres)

  • activar o desactivar l'alerta amb identificador rps-min-limit

  • rebreu una notificació si l'estat d'alerta ha canviat

L'exemple és bastant simple i comprensible. Tanmateix, per descomptat, a la vida real els guions poden ser bastant llargs i complexos. És fàcil confondre's i cometre errors.

Per tant, ha madurat un desig lògic: poder escriure proves per als vostres scripts. I a la versió v0.4.0 va aparèixer això.

Prova de guions

Exemple de prova per al nostre script de l'exemple anterior:

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

Pas a pas:

  • indica el nom del guió per al qual s'escriu la prova

  • nom de prova (per als registres)

  • connecteu el mòdul de prova

  • diem quin resultat s'ha de retornar per a una sol·licitud específica a la casa de clics ch1

  • comprovem que s'ha cridat l'alerta (error) rps-min-limit amb el missatge especificat

  • comproveu que l'alerta rps-min-limit no estigui desactivada (èxit)

Què més pot fer Balerter?

Intentaré tocar les habilitats més importants, al meu entendre, de Balerter. Podeu veure-ho tot en detall al lloc web oficial https://balerter.com

  • rebre dades de

    • casa de clics

    • postgres

    • mysql

    • prometeu

    • loki

  • enviar notificacions als canals

    • fluix

    • telegram

    • syslog

    • notificar (notificacions d'IU a l'ordinador)

    • correu electrònic

    • discòrdia

  • Creeu gràfics basats en les vostres dades, pengeu la imatge a l'emmagatzematge compatible amb S3 i adjunteu-la a les notificacions (Exemple amb imatges)

  • us permet intercanviar dades entre scripts: emmagatzematge global de claus/valors

  • escriviu les vostres pròpies biblioteques a Lua i utilitzeu-les en scripts (per defecte, les biblioteques lua es proporcionen per treballar amb json, csv)

  • enviar sol·licituds HTTP des dels vostres scripts (i rebre respostes, és clar)

  • proporciona una API (encara no tan funcional com voldríem)

  • exporta mètriques en format Prometheus

Què més t'agradaria poder fer?

Ja està clar que els usuaris i nosaltres volem la possibilitat de controlar el llançament dels scripts utilitzant la sintaxi cron. Això es farà abans de la versió v1.0.0

M'agradaria donar suport a més fonts de dades i canals de lliurament de notificacions. Per exemple, algú definitivament trobarà a faltar MongoDB. Cerca elàstica d'alguns. Envia SMS i/o truca al teu mòbil. Volem poder rebre scripts no només dels fitxers, sinó també, per exemple, d'una base de dades. Al final, volem un lloc web més fàcil d'utilitzar i una millor documentació per al projecte.

A algú sempre li falta alguna cosa) Aquí confiem en la sol·licitud de la comunitat per establir les prioritats correctament. I a l'ajuda de la comunitat per adonar-se de tot

en conclusió

Fem servir Balerter Fa temps que el tinc. Desenes de guions protegeixen la nostra tranquil·litat. Espero que aquest treball sigui útil a algú més.

I benvingut amb el vostre problema i relacions públiques.

Font: www.habr.com

Afegeix comentari