【ナイチンゲール監視】アラーム管理、すごい！

#監視は方法、警報は手段、解決策は目的です。

しかし、このような混乱に遭遇したことはありますか?たくさんのインジケーターを収集しましたが、どのインジケーターがアラームをトリガーすべきか、これらのアラームを対応するチームや個人に送信する方法、アラームをアップグレードする方法がわかりません。

以前 Prometheus Altermanager を使用したときは、チームごとに DingTalk グループを作成し、大量のタグを追加し、異なるタグを照合して異なるグループに送信しました。アラームをアップグレードしたい場合、多くの場合、 、これはしきい値のアップグレードによって行われますが、時間の経過とともに同じアラームをアップグレードするのは困難です。

しかし、ナイチンゲールのアラーム ルール管理はそれほど複雑ではなく (複雑なことは彼らが代わりにやってくれます)、また非常にエレガントです。ナイチンゲールとは『【ナイチンゲール監視】』で初めて出会ったんですが、やっぱり強いですね！ 》 言及: Grafana はパネル管理の監視に優れており、N9e はアラーム ルールの管理に優れています。

警報ルール

アラームのデータ ソースは local_prometheus で、アラームがどのクラスターから来たかを示します。
• アラーム条件は、TIME_WAIT の合計数が 20000 を超えた場合にのみアラームがトリガーされることです。
• アラームレベルはレベル2で、一般的な重要レベルです。
• 実行頻度は 15 秒に 1 回です。アラーム ルールが 60 秒間継続して満たされた場合、アラームがトリガーされます。

• 復旧通知を開始します。つまり、アラームが復旧した場合は、このチャネルを通じて担当者にも通知されます。
• アラーム受信グループ、つまりビジネスグループ。
• 継続時間を観察する: アラームが回復した後、ビジネス グループに回復通知が送信されるまでにかかる時間を観察します。回避できる揮発性アラームはどれですか? アラームや回復などの問題。
• 繰り返し通知。つまり、この期間内にアラームが解決されなかった場合、通知が再度送信されます。もちろん、ここではアラームのエスカレーションは関係ありません。

これを見て、一般的なアラーム ルールの管理についてある程度理解できましたか?

組み込みアラーム ルールの複製に加えて、アラーム ルールをカスタマイズすることもできますが、全体的な構成は上記と同じです。

ブロック アラーム

一般に、シールドされたアラームはそれほど重要なアラームではありません。

どのような状況でアラームがブロックされますか?

たとえば、アプリケーションを公開する場合、必ず問題が発生しますが、このとき、事前にいくつかのブロック ルールを作成して、アラーム メッセージの生成を回避できます。

シールド ルールもビジネス グループごとに分かれており、次のように新しいルールを追加して、メッセージ センターのアラームをブロックするルールを作成できます。

このようにして、一定の時間枠内では、アラーム情報は送信されなくなります。

生徒の中には、「いちいち追加するのはちょっと面倒ではないですか？」と言いたくなる人もいるかもしれません。

生成されたアクティブなアラームの場合は、ワンクリックでブロックできます。

過去のアラームの場合は、ワンクリックでブロックすることもできます。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ほかに何か？

何かをブロックしたい場合は、自分で追加してください。

アラームのアップグレード

これは重要なアラームではありません - ルールを削除し、役に立たないままにしておきます。

#server=notice のアラーム イベントが 1 時間以内に解決されない場合、サーバーをアップグレードします。アラーム レベルをレベル 1 に変更し、アラーム情報を上位グループに送信します。

ここでのルールはビジネスチームごとに分類して管理することもできます。

アラームの自己修復

Nightingale はアラームの自己修復機能を提供します。機能は良いですが、欲張らないでください。

ibex-server のデプロイ

# ll
total 21536
drwxr-xr-x 3 root root 4096 Apr 19 10:44 etc
-rwxr-xr-x 1 root root 16105472 Nov 152021 ibex
-rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root 4096 Nov 152021 sql

ログイン後にコピー

mysql -uroot -p <sql/ibex.sql

nohup ./ibex server &> server.log &

クライアントを構成します

保存して終了し、クリックしてタスクを作成します:

内部の構成を変更する必要がない場合、または対応する構成を変更した後、すぐに実行することを選択します:

Atこの点、どう思いますか？良いでしょうか？

とにかく、成功しませんでした。この時点で、このモジュールについて文句を言わなければなりません:

• ibex-server のデプロイメントに何か前提条件はありますか?
• ibex-agent (categraf) の前提条件はありますか?
• 自己修復スクリプトの実行に失敗しました。クライアントにもサーバーにも特定の失敗ログはありません。
• N9e V6 のアラーム自己修復設定エントリを配置する方法バージョンをメッセージ通知モジュールに追加しますか?奇妙な
• 公式ドキュメント このモジュールは少し単純すぎます

つまり、ここでは成功せず、フロントエンドがタイムアウトをスローしました。

バックエンドにはログがありません。

概要

現在、ナイチンゲールはアラーム ルールの管理、アラーム チャネルの配布、アラームの抑制とアップグレードを比較的完了できます。さらに、FlashDuty はさまざまなクラスター アラームにアクセスできるため、ほとんどの企業にはこれで十分です。

アラームの自己修復をテストするときのみ、正常にテストできませんでした。これは私の環境に関連しているはずです。

• N9e モジュール全体は Helm を使用して K8s にデプロイされますが、
• ibex-server 側はバイナリ形式 ## でホストに直接デプロイされます。

以上が【ナイチンゲール監視】アラーム管理、すごい！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。