#監視は方法、警報は手段、解決策は目的です。
しかし、このような混乱に遭遇したことはありますか?たくさんのインジケーターを収集しましたが、どのインジケーターがアラームをトリガーすべきか、これらのアラームを対応するチームや個人に送信する方法、アラームをアップグレードする方法がわかりません。
以前 Prometheus Altermanager を使用したときは、チームごとに DingTalk グループを作成し、大量のタグを追加し、異なるタグを照合して異なるグループに送信しました。アラームをアップグレードしたい場合、多くの場合、 、これはしきい値のアップグレードによって行われますが、時間の経過とともに同じアラームをアップグレードするのは困難です。
しかし、ナイチンゲールのアラーム ルール管理はそれほど複雑ではなく (複雑なことは彼らが代わりにやってくれます)、また非常にエレガントです。ナイチンゲールとは『【ナイチンゲール監視】』で初めて出会ったんですが、やっぱり強いですね! 》 言及: Grafana はパネル管理の監視に優れており、N9e はアラーム ルールの管理に優れています。
今日は、ナイチンゲールのプレイを見てみましょう。これを見て、一般的なアラーム ルールの管理についてある程度理解できましたか?
組み込みアラーム ルールの複製に加えて、アラーム ルールをカスタマイズすることもできますが、全体的な構成は上記と同じです。
一般に、シールドされたアラームはそれほど重要なアラームではありません。
どのような状況でアラームがブロックされますか?
たとえば、アプリケーションを公開する場合、必ず問題が発生しますが、このとき、事前にいくつかのブロック ルールを作成して、アラーム メッセージの生成を回避できます。
シールド ルールもビジネス グループごとに分かれており、次のように新しいルールを追加して、メッセージ センターのアラームをブロックするルールを作成できます。
このようにして、一定の時間枠内では、アラーム情報は送信されなくなります。
生徒の中には、「いちいち追加するのはちょっと面倒ではないですか?」と言いたくなる人もいるかもしれません。
生成されたアクティブなアラームの場合は、ワンクリックでブロックできます。
過去のアラームの場合は、ワンクリックでブロックすることもできます。 ###############ほかに何か?
何かをブロックしたい場合は、自分で追加してください。
アラームのアップグレード
アラームが一定期間内に処理されなかった場合はどうすればよいですか?#server=notice のアラーム イベントが 1 時間以内に解決されない場合、サーバーをアップグレードします。アラーム レベルをレベル 1 に変更し、アラーム情報を上位グループに送信します。
ここでのルールはビジネスチームごとに分類して管理することもできます。
さらに、アクティブなアラームと過去のアラームも提供され、現在のアラーム情報と過去のアラーム記録を表示できます。アラームの自己修復
運用やメンテナンスの仕事が長くなると、多くの処理が繰り返し行われることが実際にわかるようになります。自動化されたスクリプトにより処理が行われるため、作業効率が向上するだけでなく、人的操作によるリスクもある程度軽減されます。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この点、どう思いますか?良いでしょうか?
とにかく、成功しませんでした。この時点で、このモジュールについて文句を言わなければなりません:
つまり、ここでは成功せず、フロントエンドがタイムアウトをスローしました。
バックエンドにはログがありません。
現在、ナイチンゲールはアラーム ルールの管理、アラーム チャネルの配布、アラームの抑制とアップグレードを比較的完了できます。さらに、FlashDuty はさまざまなクラスター アラームにアクセスできるため、ほとんどの企業にはこれで十分です。
アラームの自己修復をテストするときのみ、正常にテストできませんでした。これは私の環境に関連しているはずです。
以上が【ナイチンゲール監視】アラーム管理、すごい!の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。