監視システムの典型的なアーキテクチャ図。左から右に見ると、コレクターは監視データの収集を担当します。収集されたデータはサーバーに送信された後、通常、タイミング ライブラリに直接書き込まれます。次に、時系列ライブラリ内のデータを分析および視覚化します。分析の最も一般的な部分は、アラーム ルールの判断、つまり図のアラーム エンジンです。アラーム エンジンはアラーム イベントを生成した後、それをさまざまなメディアを通知するためのアラーム送信モジュール。視覚化は比較的シンプルで、つまりグラフ上にデータを表示することで、さまざまな監視データをさまざまなチャートを通じて合理的にレンダリングするため、ユーザーが表示、比較、日常検査を行うのに便利です。
1.コレクター
コレクターは監視データを収集する役割を果たします。典型的な配備方法は 2 つあります。1 つは監視オブジェクトに従って配備する方法です。たとえば、コレクターをすべてのマシンに配備して、CPU、メモリ、ハードディスク、IO、およびネットワークを収集します。もう 1 つは、中央マシンをプローブとして選択する、多数のマシンの PING 接続を同時に検出する、または多数の MySQL インスタンスに接続して、コマンドを実行してデータを収集するなどのリモート プローブ方法です。
- Telegraf は InfluxData の製品です。オープン ソース プロトコルは MIT です。非常にオープンで、多くの外部貢献者がいます。主に InfluxDB で使用されます。もちろん、Telegraf はモニタリング データを Prometheus、Graphite、Datadog、OpenTSDB、その他多くのストレージにプッシュすることもできますが、InfluxDB との接続が最もスムーズです。
- エクスポーターは、Prometheus エコシステムで特別に使用されるコンポーネントです。Prometheus エコシステムのコレクターは分散しています。各コレクション ターゲットには、対応するエクスポーター コンポーネントがあります。たとえば、MySQL には mysqld_exporter があり、Redis には redis_exporter があり、スイッチには snmp_exporter があり、JVM には jmx_exporter があります。
- Grafana-Agent は Grafana が提供する All-In-One コレクターで、インジケーター データの収集だけでなく、ログ データやリンク データの収集も可能です。オープン ソース プロトコルは Apache 2.0 で、比較的オープンです。Grafana-Agent は、Loki エコシステムのログ コレクター Promtail を統合します。リンク データの場合、Grafana-Agent は OpenTelemetry Collector を統合します。
- Categraf の位置付けは、メトリクス、ログ、トレースの収集をサポートする Grafana-Agent の位置付けと似ています。Categraf は Prometheus の生態に焦点を当てています。ラベルは定常状態の構造です。数値的な時系列データのみを収集し、リモート書き込みを通じてデータをバックエンド ストレージにプッシュします。リモート書き込みプロトコルをサポートするすべての時系列ライブラリPrometheus、VictoriaMetrics、M3DB、Thanos などの接続が可能です。お待ちください。
コレクターがデータを収集した後、それをサーバーにプッシュする必要があります。通常、2 つの方法があります。1 つはタイミング ライブラリに直接プッシュする方法、もう 1 つは最初に Kafka にプッシュし、次に Kafka を通じてタイミング ライブラリに書き込む方法です。
2. タイミングライブラリ
監視システムのアーキテクチャにおいて、中心となるのはタイミング ライブラリです。古い監視システムはリレーショナル データベースを直接再利用します。たとえば、Zabbix は MySQL を直接使用して時系列データを保存します。MySQL はトランザクション シナリオの処理に優れていますが、時系列シナリオには最適化されていません。容量に明らかなボトルネックがあります。
OpenTSDBは HBase パッケージをベースとしており、その後開発が続けられ、Cassandra パッケージをベースとしたバージョンもあります。基盤となるストレージが HBase に基づいているため、一般的に小規模な企業は利用できず、国内のユーザー層も比較的小さいため、時系列データベースを選択する場合、OpenTSDB を選択する人はほとんどいません。
InfluxDB は、時系列ストレージ シナリオ向けに特別に設計されたストレージ エンジン、データ構造、アクセス インターフェイスを備えており、中国で広く使用されており、Grafana、Telegraf などとうまく統合でき、エコロジーが非常に完成しています。ただし、InfluxDB のオープン ソース バージョンはスタンドアロン バージョンであり、オープン ソース クラスター バージョンはありません。やはり営利企業であり、健全な発展を図るためにはお金も稼がなければなりませんので、この点は我々としても考慮する必要があると思います。
TDEngine はInfluxDB の国内版と言えます。TDEngine は、IoT デバイスのシナリオに最適化されており、優れたパフォーマンスを備えており、Grafana や Telegraf と統合することもでき、デバイスの監視に特化したシナリオには適しています。TDEngine のクラスター バージョンはオープン ソースであり、InfluxDB と比較して非常に魅力的です。TDEngine は時系列データを保存するだけでなく、ストリーミング コンピューティングもサポートしているため、ユーザーは導入するコンポーネントの数を減らすことができます。
M3DBは Uber の時系列データベースで、M3 は Uber の 66 億件という膨大な量の監視指標に抵抗すると主張しています。さらに、M3DB はクラスター版も含めて完全にオープンソースですが、アーキテクチャが比較的複雑で、CPU とメモリの使用量が比較的多いため、中国ではあまり普及していません。M3DB のアーキテクチャ コードには分散システム設計に関する多くの知識が含まれており、学ぶのに適したプロジェクトです。
VM と呼ばれる VictoriaMetrics は、非常にシンプルで明確なアーキテクチャを備えています。データ移行の問題を回避するためにマージ読み取りメソッドを採用しています。クラウド上に仮想マシンのバッチを構築し、クラウドにハード接続するための非常に軽量で信頼性の高いクラスターメソッドです。ディスク、VM クラスターをデプロイし、単一のコピーを使用します。
TimescaleDB は、PostgreSQL の拡張機能としてサービスを提供する timescale.inc が開発した時系列データベースです。
3. 警報エンジン
アラーム エンジンの中核的な役割は、アラーム ルールを処理し、アラーム イベントを生成することです。一般に、ユーザーは数百、場合によっては数千のアラーム ルールを設定し、一部の非常に大規模な企業では数万のアラーム ルールを設定する必要がある場合があります。各ルールには、データのフィルタリング条件、しきい値、実行頻度などが含まれています。豊富な構成を備えた監視システムもあり、ルールの有効期間、継続時間、監視時間などの構成もサポートしています。
通常、アラーム エンジンには 2 つのアーキテクチャがあり、1 つはデータ トリガーで、もう 1 つは定期的なポーリングです。
データ トリガーとは、サーバーが監視データを受信した後、それをタイミング データベースに保存するだけでなく、データのコピーをアラーム エンジンに転送することを意味します。アラーム エンジンが監視データを受信するたびに、アラーム ルールが関連付けられているかどうかを判断し、アラームを作成する必要があります。監視データの量が比較的大きいため、アラーム ルールの量も比較的大きくなる可能性があるため、アラーム エンジンは断片的に展開されます。つまり、複数のインスタンスが展開されます。
定期的なポーリング、シンプルなアーキテクチャ、通常は 1 つのルールと 1 つのコルーチン、ユーザーが設定した実行頻度に応じて、定期的なクエリの判断で十分です。アクティブにクエリが実行されるため、インデックス相関計算を行うのが簡単です。このようなアーキテクチャは、プロメテウス、ナイチンゲール、グラファナなどに似ています。イベントが生成された後は、通常、アラーム送信用の別のモジュールに渡されます。このモジュールはイベントの集約と収束を担当し、さまざまな条件に応じてさまざまな受信者およびさまざまな通知メディアにイベントを送信します。
4. データ表示
監視データの視覚化も非常に一般的かつ重要な要件であり、Grafana は業界で最も成功しています。Grafana はプラグイン アーキテクチャを採用しており、さまざまな種類のデータ ソースをサポートでき、グラフも非常に豊富で、基本的にはオープン ソース分野の事実上の標準と見なすことができます。Grafana は多くの企業の商用製品に直接組み込まれており、その人気の高さがわかります。
通常、監視データの視覚化には 2 種類の要件があります。1 つはリアルタイム クエリで、もう 1 つはダッシュボード (ダッシュボード) の監視です。インスタントクエリは一時的なアイデアです。たとえば、オンラインで問題が発生した場合、監視データを追跡し、オンサイトのトラブルシューティングの問題を復元する必要があります。これには、表示してすぐに見つけるのに便利なインジケーターの閲覧機能が必要です。希望のインジケーター。日常の点検やトラブルシューティングに使用される監視パネルは、上級技術者によって作成され、特に注目すべき指標がいくつか配置されており、ある程度の思考のきっかけとなり、知識の蓄積に強い効果があります。特定のコンポーネントの原理を理解したい場合は、通常、このコンポーネントの監視ダッシュボードからインスピレーションが得られます。
この記事はGeek Timeの「運用保守監視システム実践ノート」から7月のDay29の学習ノートです、お勧めの講座です。