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

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

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

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

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

今日は、ナイチンゲールのプレイを見てみましょう。

警報ルール

軍隊と馬は動いていませんが、食料と草が優先されます。

アラートを送信するには、まず自分のニーズが何であるかを知る必要があります。つまり、どの指標をアラートする必要があるかを理解する必要があります。

たとえば、システム レベルでは、CPU、メモリ、ディスク、IO、その他の指標を考慮する必要があり、アプリケーション レベルでは、アプリケーションの飽和、障害率、遅延などを考慮する必要があります。ビジネスレベルでは、このトランザクションが何回失敗したか、どこで失敗したかなどを考慮する必要があります。

レベルが異なると、考慮される監視指標とアラーム戦略も異なります。

ナイチンゲールのアラーム ルールは、組み込みルールとカスタム ルールに分かれています。

組み込みルールは、誰もが使用できるしきい値を下げ、すべての人に一連の普遍的なルールを提供するように設計されています。主な内容は次のとおりです。

#組み込みアラーム ルールは、ルールに追加しない限り有効になりません。特定のルールが気に入った場合は、そのルールをアクティブなルールに複製できます。たとえば、Linux TIME_WAIT アラーム ルールをデフォルトのビジネス グループに複製しました。

#次に、アラーム ルールの概要に移動すると、新しいアラーム ルールがデフォルトのビジネス グループに追加されていることがわかります。

これを見た後、何かインスピレーションが湧きましたか?

実際の状況に応じて複数の業務グループを作成し、複数の業務グループに関係するアラーム ルールを個別に管理できますか?

フロントオフィスとミドルオフィスの 2 つのチームがあると仮定すると、指標を別々に分類できます。

原則として、デフォルトでインポートされたルールは有効ではないため、追加の構成が必要です。

アラーム ルール名をクリックして、設定ページに入ります。

#アラーム条件、データ ソース、アラーム レベル、その他の構成をカスタマイズできます。上記で構成した情報は次のように要約されます。

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

次のステップは追加の構成です。

有効な構成は、アラーム ルールが有効になる期間とビジネス グループを構成するために使用されます。通知設定とは、警報が発生した場合にどのチャンネルを使ってどの場所に通知するかという通知媒体を設定することです。

ただし、通知設定で追加の設定を行うこともできます:

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

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

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

ブロック アラーム

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

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

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

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

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

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

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

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

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

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

アラームが一定期間内に処理されなかった場合はどうすればよいですか?

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

これは解決できないアラームであるため、アップグレードしてより多くの人に知らせてください。

ナイチンゲールでは、アラームのアップグレードをサブスクリプション ルールに実装できます。

たとえば、今回の構成は次のとおりです。

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

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

さらに、アクティブなアラームと過去のアラームも提供され、現在のアラーム情報と過去のアラーム記録を表示できます。

アラームの自己修復

運用やメンテナンスの仕事が長くなると、多くの処理が繰り返し行われることが実際にわかるようになります。自動化されたスクリプトにより処理が行われるため、作業効率が向上するだけでなく、人的操作によるリスクもある程度軽減されます。

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

アラームに対処するときは、問題を解決するために、まずその背後にある本当の理由を突き止める必要があります。したがって、アラームの自動修復を行うには、自動化された操作のリスクが非常に低いことを理解し、何度も試したことが必要です。 cd /opt/aaa;rm -rf ./ 操作は使用しないでください。

ナイチンゲールでは、ibex テンプレートを使用してアラームの自己修復を実装します。現在、ibex-server 側は独自にデプロイする必要があり、ibex-agent 側は Categraf に統合されています。

ibex-server のデプロイ

https://github.com/flashcatcloud/ibex/releases にアクセスしてバイナリ パッケージをダウンロードします。ダウンロード後、次のものが表示されます。ファイル:

# 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

次に、/etc/server.conf 構成ファイルを変更し、主にデータベース構成を変更します。

最後にサーバーを起動します:

nohup ./ibex server &> server.log &

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

システム構成 -> 通知構成で- >アラーム自己修復モジュール構成に対応するサーバー アドレス:

自己修復のテスト

次に、次のページに進みます。アラームの自己修復 - >次のようにスクリプトを自己修復スクリプトに追加します:

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

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

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

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

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

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

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

概要

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

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

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

# しかし、具体的な原因は判明しておらず、入手可能なトラブルシューティング情報も少なすぎます。

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