ProHoster > Blog > administracja > Łatwa praca ze złożonymi alertami. Albo historia powstania Balertera

Łatwa praca ze złożonymi alertami. Albo historia powstania Balertera

Łatwa praca ze złożonymi alertami. Albo historia powstania Balertera

Wszyscy uwielbiają alerty.

Oczywiście znacznie lepiej jest zostać powiadomionym, gdy coś się wydarzyło (lub zostało naprawione), niż siedzieć i patrzeć na wykresy i szukać anomalii.

I do tego stworzono wiele narzędzi. Alertmanager z ekosystemu Prometheus oraz vmalert z grupy produktów VictoriaMetrics. Powiadomienia i alerty Zabbix w Grafanie. Samodzielnie napisane skrypty w botach bash i Telegram, które okresowo pobierają adres URL i informują, czy coś jest nie tak. Dużo wszystkiego.

My w naszej firmie również korzystaliśmy z różnych rozwiązań, aż natknęliśmy się na złożoność, a raczej niemożność tworzenia złożonych, złożonych alertów. To, czego chcieliśmy i co ostatecznie zrobiliśmy, jest poniżej normy. TLDR: Tak pojawił się projekt open source Balerator

Przez dość długi czas dobrze sobie radziliśmy z alertami skonfigurowanymi w Grafanie. Tak, to nie jest najlepszy sposób. Zawsze zaleca się skorzystanie z wyspecjalizowanych rozwiązań, np. Alertmanager. Rozważaliśmy także możliwość przeprowadzki więcej niż raz. A potem, krok po kroku, chcieliśmy więcej.

Powiedzmy, kiedy dany wykres spadł/wzrósł o XX% i był tam przez N minut w porównaniu z poprzednim okresem M godzin? Wygląda na to, że możesz spróbować zaimplementować to za pomocą Grafany lub Alertmanagera, ale nie jest to całkiem łatwe. (A może nie jest to możliwe, nie powiem teraz)

Sprawa komplikuje się jeszcze bardziej, gdy decyzję o powiadomieniu należy podjąć w oparciu o dane z różnych źródeł. Przykład na żywo:

Sprawdzamy dane z dwóch baz Clickhouse, następnie porównujemy je z niektórymi danymi z Postgresa i decydujemy się na alert. Sygnał lub anuluj

Nagromadziliśmy całkiem sporo podobnych pragnień, abyśmy zastanowili się nad naszą decyzją. A potem próbowaliśmy stworzyć pierwszą listę wymagań/możliwości tej usługi, która jeszcze nie powstała.

  • uzyskać dostęp do różnych źródeł danych. Na przykład Prometheus, Clickhouse, Postgres

  • wysyłaj alerty na różne kanały - telegram, slack itp.

  • w trakcie myślenia stało się jasne, że nie chcę deklaratywnego opisu, ale umiejętności pisania skryptów

  • uruchamianie skryptów zgodnie z harmonogramem

  • łatwa aktualizacja skryptów bez ponownego uruchamiania usługi

  • możliwość pewnego rozszerzenia funkcjonalności bez konieczności przebudowywania usługi z kodów źródłowych

Ta lista jest przybliżona i najprawdopodobniej niezbyt dokładna. Niektóre punkty uległy zmianie, niektóre umarły. Wszystko jest jak zwykle.

Właściwie tak zaczęła się historia Balertera.

Łatwa praca ze złożonymi alertami. Albo historia powstania Balertera

Postaram się pokrótce opisać co się ostatecznie wydarzyło i jak to działa. (Tak, oczywiście, to nie koniec. Planów rozwoju produktu jest wiele. Na tym poprzestanę)

Jak to działa?

Piszesz skrypt w Lua, w którym wyraźnie wysyłasz żądania (do Prometheusa, Clickhouse itp.). Otrzymujesz odpowiedzi, które w jakiś sposób przetwarzasz i porównujesz. Następnie włącz/wyłącz jakiś rodzaj alertu. Balerter sam wyśle ​​powiadomienie do skonfigurowanych przez Ciebie kanałów (E-mail, telegram, Slack itp.). Skrypt jest wykonywany w określonych odstępach czasu. I... ogólnie to wszystko)

Najlepiej pokazać to na przykładzie:

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

Co tu się dzieje:

  • wskazujemy, że ten skrypt powinien być wykonywany co 10 sekund

  • wskazać nazwę skryptu (dla API, do wyświetlenia w logach, do wykorzystania w testach)

  • podłącz moduł do wysyłania logów

  • podłącz moduł, aby uzyskać dostęp do domku z nazwą ch1 (same połączenie jest skonfigurowane w konfiguracji)

  • wyślij zapytanie do Clickhouse

  • w przypadku błędu wyświetlamy komunikat w logu i wychodzimy

  • porównaj wynik zapytania ze stałą (w żywym przykładzie moglibyśmy tę wartość uzyskać np. z bazy Postgres)

  • włączyć lub wyłączyć alert z identyfikatorem rps-min-limit

  • otrzymasz powiadomienie, jeśli status alertu ulegnie zmianie

Przykład jest dość prosty i zrozumiały. Jednakże, oczywiście, w prawdziwym życiu skrypty mogą być dość długie i złożone. Łatwo się pomylić i popełnić błąd.

Dlatego dojrzało logiczne pragnienie - móc pisać testy dla swoich skryptów. A w wersji v0.4.0 pojawiło się to.

Testowanie skryptów

Przykładowy test naszego skryptu z powyższego przykładu:

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

Krok po kroku:

  • podać nazwę skryptu, dla którego napisany jest test

  • nazwa testu (dla logów)

  • podłącz moduł testujący

  • mówimy, jaki wynik powinien zostać zwrócony w przypadku konkretnego żądania do Clickhouse ch1

  • sprawdzamy, czy został wywołany alert (błąd) rps-min-limit z podanym komunikatem

  • sprawdź, czy alert Rps-min-limit nie został wyłączony (sukces)

Co jeszcze potrafi Balerter?

Postaram się poruszyć najważniejsze, moim zdaniem, umiejętności Balertera. Wszystko szczegółowo można zobaczyć na oficjalnej stronie internetowej https://balerter.com

  • odbierać dane z

    • dom kliknięć

    • Postgres

    • mysql

    • prometheus

    • Loki

  • wysyłaj powiadomienia do kanałów

    • luźny

    • telegram

    • syslog

    • powiadamiaj (powiadomienia interfejsu użytkownika na Twoim komputerze)

    • E-mail

    • niezgoda

  • twórz wykresy na podstawie swoich danych, przesyłaj obraz do pamięci kompatybilnej z S3 i dołącz go do powiadomień (Przykład ze zdjęciami)

  • umożliwia wymianę danych pomiędzy skryptami - globalne przechowywanie kluczy/wartości

  • pisz własne biblioteki w Lua i używaj ich w skryptach (domyślnie dostarczane są biblioteki Lua do pracy z json, csv)

  • wysyłaj żądania HTTP ze swoich skryptów (i oczywiście otrzymuj odpowiedzi)

  • zapewnia API (jeszcze nie tak funkcjonalne, jak byśmy chcieli)

  • eksportuje metryki w formacie Prometheus

Co jeszcze chciałbyś umieć?

Jest już jasne, że użytkownikom i nam zależy na możliwości kontrolowania uruchamiania skryptów za pomocą składni cron. Zostanie to zrobione przed wersją v1.0.0

Chciałbym obsługiwać więcej źródeł danych i kanałów dostarczania powiadomień. Na przykład komuś na pewno będzie brakować MongoDB. Elastyczne Szukaj niektórych. Wysyłaj SMS-y i/lub dzwoń na swój telefon komórkowy. Chcemy mieć możliwość odbierania skryptów nie tylko z plików, ale też np. z bazy danych. Docelowo chcemy bardziej przyjaznej dla użytkownika strony internetowej i lepszej dokumentacji projektu.

Zawsze komuś czegoś brakuje) Tutaj zdajemy się na prośbę społeczności, aby prawidłowo ustalić priorytety. I z pomocą społeczności, aby wszystko zrealizować

Na zakończenie

Używamy Balerator Mam to już od jakiegoś czasu. Dziesiątki skryptów strzegą naszego spokoju ducha. Mam nadzieję, że ta praca przyda się komuś innemu.

Witamy ze swoim problemem i PR.

Źródło: www.habr.com

Dodaj komentarz