ProHoster > Blog > Administración > Traballo sinxelo con alertas complexas. Ou a historia da creación de Balerter

Traballo sinxelo con alertas complexas. Ou a historia da creación de Balerter

Traballo sinxelo con alertas complexas. Ou a historia da creación de Balerter

Todo o mundo adora as alertas.

Por suposto, é moito mellor ser notificado cando algo aconteceu (ou arranxado) que sentarse a mirar gráficos e buscar anomalías.

E para iso creáronse moitas ferramentas. Alertmanager do ecosistema Prometheus e vmalert do grupo de produtos VictoriaMetrics. Notificacións e alertas de Zabbix en Grafana. Scripts autoescritos en bash e robots de Telegram que periódicamente sacan algún URL e che indican se algo está mal. Moito de todo.

Nós, na nosa empresa, tamén utilizamos diferentes solucións ata que nos topamos coa complexidade, ou, mellor dito, coa imposibilidade de crear alertas complexas e compostas. O que queriamos e o que acabamos facendo é por debaixo do corte. TLDR: Así apareceu o proxecto de código aberto Empacadora

Durante bastante tempo vivimos ben coas alertas configuradas en Grafana. Si, esta non é a mellor maneira. Sempre se recomenda utilizar algunhas solucións especializadas, como Alertmanager. E tamén buscamos movernos máis dunha vez. E despois, pouco a pouco, queriamos máis.

Di cando un determinado gráfico caeu/aumentou un XX% e estivo alí durante N minutos en comparación co período anterior de M horas? Parece que podes tentar implementar isto con Grafana ou Alertmanager, pero non é moi sinxelo. (Ou quizais non sexa posible, non o digo agora)

As cousas complícanse aínda máis cando a decisión de alerta debe tomarse a partir de datos de diferentes fontes. Exemplo en directo:

Comprobamos os datos de dúas bases de datos de Clickhouse, despois comparámolos con algúns datos de Postgres e decidimos unha alerta. Sinalar ou cancelar

Acumulamos moitos desexos similares para que pensemos na nosa decisión. E despois tentamos compilar a primeira lista de requisitos/capacidades deste servizo, que aínda non foi creada.

  • acceder a diferentes fontes de datos. Por exemplo, Prometheus, Clickhouse, Postgres

  • enviar alertas a varias canles: telegram, slack, etc.

  • no proceso de pensar, quedou claro que non quería unha descrición declarativa, senón a capacidade de escribir guións

  • executando scripts nunha programación

  • fácil actualización de scripts sen reiniciar o servizo

  • a capacidade de expandir dalgún xeito a funcionalidade sen reconstruír o servizo a partir dos códigos fonte

Esta lista é aproximada e probablemente non sexa moi precisa. Algúns puntos cambiaron, outros morreron. Todo é como sempre.

En realidade, así comezou a historia de Balerter.

Traballo sinxelo con alertas complexas. Ou a historia da creación de Balerter

Intentarei describir brevemente o que pasou ao final e como funciona. (Si, por suposto, este non é o final. Hai moitos plans para o desenvolvemento de produtos. Voume parar hoxe)

Como funciona isto?

Escribes un guión en Lua onde envías solicitudes explícitamente (a Prometheus, Clickhouse, etc.). Recibes respostas e, dalgún xeito, procesalas e comparalas. A continuación, activa/desactiva algún tipo de alerta. O propio Balerter enviará unha notificación ás canles que teña configuradas (correo electrónico, telegrama, slack, etc.). O script execútase a intervalos especificados. E... en xeral, iso é todo)

O mellor é mostrar cun exemplo:

-- @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á pasando aquí:

  • indicamos que este script debe executarse cada 10 segundos

  • indicar o nome do script (para a API, para mostrar nos rexistros, para usar en probas)

  • conectar o módulo para a saída de rexistros

  • conectar un módulo para acceder ao clickhouse co nome ch1 (a propia conexión está configurada na configuración)

  • enviar unha solicitude a clickhouse

  • en caso de erro, mostramos unha mensaxe no rexistro e saímos

  • compare o resultado da consulta cunha constante (nun exemplo en directo, poderiamos obter este valor, por exemplo, da base de datos Postgres)

  • activar ou desactivar a alerta con ID rps-min-limit

  • recibirá unha notificación se o estado da alerta cambiou

O exemplo é bastante sinxelo e comprensible. Non obstante, por suposto, na vida real os guións poden ser bastante longos e complexos. É fácil confundirse e cometer erros.

Polo tanto, madurou un desexo lóxico: poder escribir probas para os teus guións. E na versión v0.4.0 apareceu isto.

Proba de scripts

Exemplo de proba para o noso script do exemplo 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')

Os pasos:

  • indicar o nome do guión para o que se escribe a proba

  • nome da proba (para rexistros)

  • conectar o módulo de proba

  • dicimos que resultado debe ser devolto para unha solicitude específica ao clickhouse ch1

  • comprobamos que se chamou a alerta (erro) rps-min-limit coa mensaxe especificada

  • comproba que a alerta de rps-min-limit non estaba desactivada (éxito)

Que máis pode facer Balerter?

Tentarei tocar as habilidades máis importantes, na miña opinión, de Balerter. Podes ver todo en detalle na páxina web oficial https://balerter.com

  • recibir datos de

    • clickhouse

    • postgres

    • mysql

    • prometeo

    • loki

  • enviar notificacións ás canles

    • holgazán

    • telegrama

    • syslog

    • notificar (notificacións da IU no seu ordenador)

    • correo electrónico

    • discordia

  • constrúe gráficos baseados nos seus datos, cargue a imaxe a un almacenamento compatible con S3 e axúdaa ás notificacións (Exemplo con imaxes)

  • permítelle intercambiar datos entre scripts: almacenamento global de clave/valor

  • escribe as túas propias bibliotecas en Lua e utilízaas en scripts (por defecto, as bibliotecas Lua se proporcionan para traballar con json, csv)

  • enviar solicitudes HTTP desde os seus scripts (e recibir respostas, por suposto)

  • proporciona unha API (aínda non tan funcional como nos gustaría)

  • exporta métricas en formato Prometheus

Que máis che gustaría poder facer?

Xa está claro que os usuarios e nós queremos a posibilidade de controlar o lanzamento de scripts mediante a sintaxe cron. Isto farase antes da versión v1.0.0

Gustaríame admitir máis fontes de datos e canles de entrega de notificacións. Por exemplo, alguén definitivamente botará de menos MongoDB. Busca elástica para algúns. Envía SMS e/ou fai chamadas ao teu teléfono móbil. Queremos poder recibir scripts non só de ficheiros, senón tamén, por exemplo, dunha base de datos. Ao final, queremos un sitio web máis amigable e unha mellor documentación para o proxecto.

A alguén sempre lle falta algo) Aquí confiamos na solicitude da comunidade para establecer as prioridades correctamente. E á axuda da comunidade para darse conta de todo

En conclusión

Usamos Empacadora Téñoo desde hai bastante tempo. Decenas de guións gardan a nosa tranquilidade. Espero que este traballo sexa útil para outra persoa.

E benvido co teu número e PR.

Fonte: www.habr.com

Engadir un comentario