複雑なアラートでも簡単に作業できます。 またはバレルターの創設の歴史

複雑なアラートでも簡単に作業できます。 またはバレルターの創設の歴史

誰もがアラートを好みます。

もちろん、座ってグラフを眺めて異常を探すよりも、何かが起こったとき (または修正されたとき) に通知を受け取る方がはるかに優れています。

そして、そのために多くのツールが作成されています。 Prometheus エコシステムの Alertmanager と VictoriaMetrics 製品グループの vmalert。 Grafana の Zabbix 通知とアラート。 bash および Telegram ボットで自分で作成したスクリプト。定期的に URL を取得して、何か問題があるかどうかを通知します。 すべてがたくさんあります。

私たちの会社でも、複雑な複合アラートの作成の複雑さ、またはむしろ不可能に遭遇するまで、さまざまなソリューションを使用していました。 私たちが望んでいたもの、そして最終的にやったことは、カットの下にあります。 TLDR: オープンソース プロジェクトはこうして誕生した バレルター

かなり長い間、私たちは Grafana で設定されたアラートを使用してうまく暮らしてきました。 はい、これは最善の方法ではありません。 Alertmanager などの特殊なソリューションを使用することを常にお勧めします。 そして、複数回の引っ越しも視野に入れました。 そして、少しずつ、もっと欲しいと思うようになりました。

特定のチャートが XX% 下落/上昇し、前の期間の M 時間と比較して N 分間そこにいたとします。 Grafana や Alertmanager を使えば実装できそうですが、なかなか簡単ではありません。 (あるいは不可能かもしれません、今は言いません)

さまざまなソースからのデータに基づいてアラートの決定を下す必要がある場合、事態はさらに複雑になります。 ライブの例:

XNUMX つの Clickhouse データベースのデータを確認し、Postgres のデータと比較して、アラートを決定します。 合図またはキャンセル

私たちは、自分たちの決定について考えてほしいという同様の欲求をかなり多く蓄積してきました。 そして、このサービスの要件/機能の最初のリストを作成しようとしましたが、これはまだ作成されていません。

  • さまざまなデータソースにアクセスします。 例: プロメテウス、クリックハウス、Postgres

  • 電報、スラックなど、さまざまなチャネルにアラートを送信します。

  • 考えていくうちに、宣言的な記述が欲しいのではなく、スクリプトを書く能力が欲しいことが明らかになりました。

  • スケジュールに従ってスクリプトを実行する

  • サービスを再起動せずにスクリプトを簡単に更新

  • ソースコードからサービスを再構築することなく、何らかの方法で機能を拡張できる機能

このリストはおおよそのものであり、あまり正確ではない可能性があります。 いくつかの点が変化し、いくつかは死亡した。 すべていつも通りです。

実際、これがバレルターの歴史の始まりです。

複雑なアラートでも簡単に作業できます。 またはバレルターの創設の歴史

最終的に何が起こったのか、そしてそれがどのように機能するのかを簡単に説明してみます。 (はい、もちろんこれで終わりではありません。商品開発の予定はたくさんあります。今日はこのくらいにしておきます)

それはどのように動作しますか?

Lua でスクリプトを作成し、(Prometheus、Clickhouse などに) リクエストを明示的に送信します。 回答を受け取り、何らかの方法で処理して比較します。 次に、何らかのアラートをオン/オフにします。 Balerter 自体は、設定したチャネル (電子メール、電報、Slack など) に通知を送信します。 スクリプトは指定された間隔で実行されます。 そして...一般的にはそれだけです)

例を挙げて示すのが最善です。

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

何が起きてる:

  • このスクリプトは 10 秒ごとに実行する必要があることを示します

  • スクリプトの名前を示します(API、ログに表示、テストで使用)

  • ログ出力用モジュールを接続します

  • 名前のクリックハウスにアクセスするモジュールを接続します ch1 (接続自体は構成で構成されます)

  • クリックハウスにリクエストを送信する

  • エラーが発生した場合は、ログにメッセージを表示して終了します。

  • クエリ結果を定数と比較します (実際の例では、この値は、たとえば Postgres データベースから取得できます)

  • ID を使用してアラートを有効または無効にする rps-min-limit

  • アラートステータスが変更された場合は通知を受け取ります

この例は非常にシンプルでわかりやすいです。 ただし、もちろん、現実のスクリプトは非常に長く複雑になる場合があります。 混乱して間違いを犯すのは簡単です。

したがって、スクリプトのテストを作成できるようになりたいという論理的な欲求が成熟しました。 そしてバージョンv0.4.0ではこれが登場しました。

スクリプトのテスト

上記の例からのスクリプトのテスト例:

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

段階的に:

  • テストが書かれたスクリプトの名前を示します

  • テスト名 (ログ用)

  • テストモジュールを接続します

  • クリックハウスへの特定のリクエストに対してどのような結果を返すべきかを指定します。 ch1

  • 指定されたメッセージを含むアラート (エラー) rps-min-limit が呼び出されたことを確認します。

  • rps-min-limit アラートが無効になっていないことを確認します (成功)

バレルターは他に何ができるでしょうか?

私の意見では、最も重要なバレターのスキルについて触れてみたいと思います。 公式サイトで詳しく見ることができます https://balerter.com

  • ~からデータを受信する

    • クリックハウス

    • ポストグレス

    • mysqlの

    • プロメテウス

    • ロキ

  • チャネルに通知を送信する

    • スラック

    • 電報

    • syslog

    • 通知 (コンピュータ上の UI 通知)

    • email

    • 不和

  • データに基づいてグラフを作成し、画像を S3 互換ストレージにアップロードして通知に添付します (写真付きの例)

  • スクリプト間でデータを交換できる - グローバル キー/値ストレージ

  • Lua で独自のライブラリを作成し、スクリプトで使用します (デフォルトでは、json、csv を操作するために lua ライブラリが提供されています)

  • スクリプトから HTTP リクエストを送信します (もちろん、応答も受信します)。

  • API を提供します (まだ期待どおりに機能していません)

  • メトリクスを Prometheus 形式でエクスポートします

他に何ができるようになりたいですか?

ユーザーと私たちが次の構文を使用してスクリプトの起動を制御できる機能を望んでいることはすでに明らかです。 cron。 これはバージョン v1.0.0 より前に行われます。

より多くのデータ ソースと通知配信チャネルをサポートしたいと考えています。 たとえば、MongoDB が恋しくなる人は間違いなくいるでしょう。 いくつかの弾性検索。 携帯電話に SMS を送信したり、電話をかけたりできます。 ファイルからだけでなく、たとえばデータベースからもスクリプトを受信できるようにしたいと考えています。 最終的には、よりユーザーフレンドリーな Web サイトと、プロジェクトに関するより優れたドキュメントが必要になります。

誰かが常に何かを見逃しています) ここでは、優先順位を正しく設定するためにコミュニティのリクエストに依存します。 そしてコミュニティの助けを借りてすべてを実現します

結論

を使用しております バレルター 私はもうかなり長い間それを持っています。 数十のスクリプトが私たちの心の平穏を守っています。 この作品が誰かの役に立つことを願っています。

問題と PR を歓迎します。

出所: habr.com

コメントを追加します