現在の監視に関しては、間違いなく Prometheus が最も人気のあるプロジェクトです。マシンとネットワーク デバイスのみを監視する場合は、依然として Zabbix と競合できます。デバイスだけでなく、アプリケーション、Kubernetes、その他のインフラストラクチャも監視したい場合は、Prometheus が最適です。選択。 Zookeeper の新しいバージョン、RabbitMQ の新しいバージョン、Nginx vts など、Prometheus プロトコルのインジケーター公開のサポートが組み込まれているオープン ソース プロジェクトもいくつかあります。プロメテウスの影響は明らかです。
多くのシナリオで言及される Prometheus という言葉は、実際には Prometheus プロジェクト自体だけでなく、インジケーター形式、送信プロトコル、クエリ言語、さまざまな Exporter コレクター、Prometheus によって定義されたさまざまな互換性のあるストレージなどを含む Prometheus エコシステムを指します。
Prometheus エコシステムでは、コレクションにはさまざまな Exporter が使用でき、ストレージには VictoriaMetrics が使用でき、画像の表示には Grafana が使用できるようですが、なぜ別の「Nightingale」と呼ばれるオープンソース プロジェクトが存在するのでしょうか。プロメテウスと提携していますか？この記事では、1 つまたは 2 つを調査してみます。
ナイチンゲールの紹介
ナイチンゲール公式 Web サイトからのナイチンゲール プロジェクト紹介の抜粋:
Nightingale Monitor は、オールインワン設計コンセプトを採用したオープンソースのクラウドネイティブな観察および分析ツールであり、データ収集、視覚化、監視および警報、およびデータ分析を統合します。企業にすぐに使えるレベル監視、分析、アラーム機能を提供します。 Nightingale は 2020 年 3 月 20 日に v1 バージョンを github でリリースし、累計で 100 以上のバージョンが存在します。
Nightingale はもともと Didi によって開発およびオープンソース化されており、2022 年 5 月 11 日に中国コンピュータ連盟オープンソース開発委員会 (CCF ODC) に寄贈され、CCF ODC 設立後に寄附を受けた最初のオープンソース プロジェクトとなりました。 Nightingale のコア R&D チームは、2014 年から数えて Open-Falcon プロジェクトの最初のコア R&D スタッフでもあり (Open-Falcon は 2014 年にオープンソース化されました)、モニタリングにおいて良い仕事をしてきました。
- バックエンドコード: https://github.com/ccfos/nightingale
- フロントエンドコード: https://github.com/n9e/fe
プロジェクトの紹介を読んだ後では、Nightingale が監視システムであることしか知りませんが、Prometheus との違いは何ですか? まだ見ていません。心配しないで、まずプロメテウスの問題を見てみましょう。
プロメテウス問題
プロメテウスの収集、保管、画像閲覧はすべて非常にうまく解決されました。一部の企業にとっては、これは次のような問題を引き起こす可能性があります。
- 企業には多数の Prometheus セットがあり、ルールが複数の yaml に分散しているため、管理が不便です。
- 私は、社内のすべてのチームにモニタリング機能を公開し、すべてのことをモニタリング チームに頼らずに済む、使いやすく権限が分離された UI を実現したいと考えています。
- Promql を直接使用してデータをクエリしたり、アラーム ルールを構成したりするのは少し難しいですが、知識を蓄積して一般ユーザーがすぐに使用できるように、ルール ライブラリとクエリ ステートメントを組み込むことはできますか?
- 異なる有効時間を持つ異なるルールをサポートしたり、組み込みのアラーム自己修復メカニズムを提供したりするなど、アラーム ルールがより柔軟になることが望まれます。
ナイチンゲールはそのために作られたのです。実際、Nightingale の古いバージョンは自己完結型で Open-Falcon から派生したものでしたが、Prometheus の人気が高まるにつれて、Nightingale は Prometheus エコシステムを採用し始めました。ナイチンゲールは、時系列データのアラーム エンジンとみなすことができます。もちろん、Nightingale にはグラフやダッシュボードを表示する機能もあり、Elasticsearch、Loki、TDEngine のデータも表示できます。ただし、現状では、Nightingale のアラーム機能が最も多くの人に使用されており、ほとんどのダッシュボードは依然として Grafana を使用しています。ナイチンゲールが使用する典型的なアーキテクチャは次のとおりです。
ナイチンゲールはプロメテウスを完全に置き換えることができるでしょうか?
実際には、それは代替関係ではなく、相乗関係です。 Nightingale の見解では、Prometheus は主にタイミング ライブラリとして使用されます。Prometheus に加えて、VictoriaMetrics、Thanos、M3DB、TDEngine などの他のタイミング ライブラリも選択できます。 Nightingale は、時系列ライブラリのアラーム エンジンとしてのみ使用できます。Prometheus や他の時系列ライブラリと接続して、Nightingale でアラーム ルールを一元管理し、異常データの判断やアラーム イベントの生成、その後の配信通知を行うことができます。アラームの自己修復およびその他のロジック。
さらに、複数のコンピュータ室がある場合、タイミング ライブラリが複数のコンピュータ室に分散しており、コンピュータ室間のネットワークが良好ではなく、ネットワークが断片化していてもアラームに影響を与えずにエッジコンピュータ室を自律させたい、ナイチンゲールも非常に適しています。この場合、ナイチンゲールはこれをエッジ コンピュータ ルーム展開モードと呼んでいます。ネットワークが切断されていても、データは中央で均一に表示されます。アラーム ルールを一元管理できます。アーキテクチャ図は次のとおりです。
上の例では、3 つのコンピューター ルームの展開アーキテクチャが示されています。コンピューター ルーム A と中央コンピューター ルーム間のネットワーク リンクは非常に良好ですが、コンピューター ルーム B と中央コンピューター ルーム間のネットワーク リンクはそれぞれあまり良好ではありません。コンピュータルームにはタイミングライブラリがあります。したがって、中央コンピュータ室のナイチンゲール警報エンジンは、中央コンピュータ室とコンピュータ室 A のタイミング ライブラリを直接処理します。コンピュータ室 B のタイミング ライブラリは、コンピュータ室 B の警報エンジン、つまり n9e-edge によって処理されます。図では、n9e-edge が中央コンピュータ室のナイチンゲールから処理され、ローカルコンピュータ室のタイミングライブラリ上でアラーム判定を行います。
このようにして、コンピュータ室 B と中央コンピュータ室の間のネットワークが分離されていても、アラーム ルールは n9e-edge メモリ内で同期されているため、コンピュータ室 B のアラーム エンジンは引き続きコンピュータ ルームのアラーム判定作業を処理できます。通常、コンピュータ室 B の 2 つのタイミング ライブラリ。監視システム全体の高可用性が向上しました。
プロメテウスの代わりにナイチンゲールを使用するシーンは何ですか?
鍵となるのは、どのような問題点があるかによって異なります。この段階で Prometheus の 1 点を使用すれば、問題は大幅に解決されます。どの企業でも、技術ツールの移行にはさまざまな抵抗が生じるのは当然です。
アラーム ルールの管理とエッジ コンピューター ルームのアラームの高可用性に問題点がある場合は、Nightingale を試してみてください。どのツールにもそれぞれ長所と短所があるので、シナリオに応じて選択してください。
ナイチンゲールはさまざまな監視システムからアラームを受信し、統合されたイベント通知を提供できますか?
一部の友人は、ナイチンゲールがさまざまなタイミング ライブラリに接続し、アラームの判断を行い、アラーム イベントを生成して配布できることを知り、私の他の監視システムで生成されたアラームもナイチンゲールで送信できるのではないかと考えました。これにより、アラーム通知テンプレートや連絡先、認証ログイン権限などを一元管理できます。
実際、これは不可能です。これは典型的なイベント OnCall 要件であり、さまざまな監視システム (Prometheus、Zabbix、Open-Falcon、Blue Whale、さまざまなクラウド監視、ElastAlert など) からアラームを収集し、統合されたアラームの収束とノイズ削減、スケジュール設定を実行します。要求とアップグレード、条件に基づく柔軟な配布など。これをうまく実行したい場合は、別の製品を使用する価値があります。この製品を OnCall 製品と呼びます。 OnCall 製品と各監視システムの関係は次のとおりです。
つまり、監視システム (さまざまな種類のクラウド監視を含む) は、データの収集、保存、視覚的分析、およびアラームの決定の問題を解決することに重点を置き、アラーム イベントの生成を担当します。その後、アラーム イベントはシステムに引き渡されます。 OnCall センターは処理を担当し、コンバージェンスとノイズの低減、抑制とシールド、アラーム イベントのフィルタリングと配信、その他多くの事項を担当します。
優れた OnCall 製品は、PagerDuty、FlashDuty、Opsgenie などの商用製品です。自分で Google で必要なものを見つけることができます。
ナイチンゲールにはプロメテウスよりも興味深い機能がありますか?
ここではいくつかのシステム図を取り上げて簡単に紹介します。
Nightingale はデータを収集しませんが、市販されているさまざまなコレクターと接続できます。その中で、categraf コレクターと Nightingale 間の接続が最もスムーズです。カテゴリーf をコレクターとして使用すると、マシンのさまざまなメタ情報を収集できます。軽量のマシン層を構築します。
Nightingale にはアラームの自己修復機能が組み込まれており、アラームが発生すると、アラームが発生したマシン上でスクリプトを自動的に実行できます。スクリプト内に自動修復ロジックを記述することができます。
Nightingale には組み込みのインジケーター ビューがあり、v7 ベータ 3 バージョンでリリースされます。また、一般的に使用される多くの promql 組み込みも提供され、クリックするだけでクエリが実行でき、初心者ユーザーにとって非常に使いやすいものになります。
まとめ
すでにプロメテウスがあるのに、なぜナイチンゲールが必要なのでしょうか?この記事は、この質問に対する回答です。これがお役に立てば幸いです。読んでいただきありがとうございます。
高校生が成人式として独自のオープンソースプログラミング言語を作成―ネットユーザーの鋭いコメント： アップル、M4チップ RustDeskをリリース 不正行為横行で国内サービス停止 雲峰氏がアリババを辞任。将来的には、Windows プラットフォームの タオバオ (taabao.com) で独立したゲームを制作する予定です。Web バージョンの最適化作業を再開し、 プログラマの目的地、 Visual Studio Code 1.89 が最も一般的に使用される Java LTS バージョンである Java 17 をリリースします。Windows 10 には、市場シェアは70%、Windows 11は減少し続けるOpen Source Daily | GoogleはオープンソースのRabbit R1を支持、Microsoftの不安と野心;