別の監視システム

モデム 16 台、携帯電話事業者 4 社 = 送信速度 933.45 Mbit/s

導入

こんにちは！ この記事は、私たちが自分たちで新しい監視システムをどのように作成したかについて説明します。 既存のものとは、高頻度の同期メトリクスを取得できる機能と、リソース消費が非常に低いという点で異なります。 ポーリング レートは 0.1 ミリ秒に達し、メトリクス間の同期精度は 10 ナノ秒です。 すべてのバイナリ ファイルは 6 MB を占めます。

プロジェクトについて

かなり特殊な製品があります。 当社は、データ伝送チャネルのスループットとフォールトトレランスを要約するための包括的なソリューションを作成します。 これは、複数のチャネルがある場合です。たとえば、Operator1 (40Mbit/s) + Operator2 (30Mbit/s) + その他 (5 Mbit/s) です。結果は 40 つの安定した高速チャネルとなり、その速度は次のようになります。これ: (30+ 5+0.92)x75=0.92x69=XNUMX Mbit/秒。

このようなソリューションは、いずれか XNUMX つのチャネルの容量が不十分な場合に需要があります。 たとえば、交通機関、ビデオ監視システムとリアルタイム ビデオ ストリーミング、テレビやラジオの生放送、電気通信事業者のうち XNUMX 社の代表者のみが存在し、XNUMX つのモデム/チャネルの速度では十分ではない郊外の施設などです。 。
これらの分野ごとに、当社は別個のデバイスラインを製造していますが、それらのソフトウェア部分はほぼ同じであり、高品質の監視システムはそのメインモジュールの XNUMX つであり、これを正しく実装しなければ製品は不可能になります。

数年をかけて、私たちはマルチレベル、高速、クロスプラットフォーム、軽量のモニタリング システムを作成することに成功しました。 これが私たちが尊敬するコミュニティと共有したいことです。

問題の定式化

監視システムは、リアルタイム メトリクスとその他すべての XNUMX つの根本的に異なるクラスのメトリクスを提供します。 監視システムには次の要件のみがありました。

1. リアルタイムのメトリクスを高頻度で同期取得し、遅延なく通信管理システムに転送します。
   さまざまなメトリックの高頻度と同期は重要であるだけでなく、データ伝送チャネルのエントロピーを分析するためにも不可欠です。 30 つのデータ送信チャネルの平均遅延が 5 ミリ秒の場合、残りのメトリクス間の同期エラーがわずか 1 ミリ秒であると、結果のチャネルの速度が約 4% 低下します。 30 つのチャネルにわたってタイミングが 0.5 ミリ秒ずれると、速度の低下は簡単に 500% に低下する可能性があります。 さらに、チャネル内のエントロピーは非常に急速に変化するため、1 ミリ秒ごとに 2 回未満で測定すると、遅延が小さい高速チャネルでは高速度が低下します。 もちろん、このような精度はすべての指標やすべての条件に必要というわけではありません。 チャネルの遅​​延が XNUMX ミリ秒であり、そのようなもので作業する場合、XNUMX ミリ秒の誤差はほとんど目立ちません。 また、生命維持システムのメトリクスについては、XNUMX 秒という十分なポーリング レートと同期レートを備えていますが、監視システム自体は超高速のポーリング レートと超高精度のメトリクス同期で動作できる必要があります。
2. 最小限のリソース消費と単一スタック。
   最終デバイスは、道路上の状況を分析したり、人々の生体認証記録を実行したりできる強力な車載複合体、または特殊部隊の兵士がビデオを送信するために防弾チョッキの下に着用する手のひらサイズのシングルボード コンピューターのいずれかになります。通信状況が悪い場合でもリアルタイムに。 アーキテクチャとコンピューティング能力がこれほど多様であるにもかかわらず、私たちは同じソフトウェア スタックを使用したいと考えています。
3. アンブレラアーキテクチャ
   メトリクスはエンドデバイス上で収集および集約され、ローカルストレージを備え、リアルタイムかつ遡及的に視覚化される必要があります。 接続がある場合は、データを中央監視システムに転送します。 接続がない場合、送信キューは蓄積され、RAM を消費しないようにする必要があります。
4. 多くの監視システムを必要としないため、顧客の監視システムに統合するための API。 お客様は、あらゆるデバイスおよびネットワークからデータを単一の監視に収集する必要があります。

どうしたの

すでに印象的な長文の読者に負担をかけないように、すべての監視システムの例と測定値は示しません。 これは別の記事につながります。 ただ、1 ミリ秒未満の誤差で 64 つのメトリクスを同時に取得でき、86 MB の RAM を備えた ARM アーキテクチャと 64 MB の RAM を備えた x32_XNUMX アーキテクチャの両方で同等に効果的に動作する監視システムを見つけることができなかったとだけ言っておきます。 GBのRAM。 したがって、これらすべてを実行できる独自のプログラムを作成することにしました。 得られたものは次のとおりです。

さまざまなネットワーク トポロジの XNUMX つのチャネルのスループットを要約する

いくつかの主要な指標の視覚化

アーキテクチャ

デバイスとデータセンターの両方で、メインのプログラミング言語として Golang を使用しています。 マルチタスクの実装と、サービスごとに静的にリンクされた XNUMX つの実行可能バイナリ ファイルを取得できる機能により、作業が大幅に簡素化されました。 その結果、サービスをエンドデバイスに展開するためのリソース、方法、トラフィック、開発時間、コードのデバッグが大幅に節約されます。

このシステムは古典的なモジュール原理に従って実装されており、いくつかのサブシステムが含まれています。

1. メトリクスの登録。
   各メトリクスは独自のスレッドによって提供され、チャネル間で同期されます。 最大 10 ナノ秒の同期精度を達成することができました。
2. メトリクスのストレージ
   私たちは、時系列用に独自のストレージを作成するか、すでに利用可能なものを使用するかを選択していました。 データベースは、後続の視覚化の対象となる遡及データに必要です。つまり、0.5 ミリ秒ごとのチャネルの遅​​延やトランスポート ネットワークのエラー読み取り値に関するデータは含まれませんが、各インターフェイスの速度は 500 ミリ秒ごとに存在します。 クロスプラットフォームと低リソース消費に対する高い要件に加えて、処理できることが非常に重要です。 データはそれが保存される場所です。 これにより、膨大なコンピューティング リソースが節約されます。 私たちは 2016 年からこのプロジェクトで Tarantool DBMS を使用していますが、これに代わるものは今のところ考えられていません。 柔軟性があり、リソースを最適に消費し、十分以上の技術サポートを提供します。 Tarantool は GIS モジュールも実装しています。 もちろん、PostGIS ほど強力ではありませんが、位置関連のメトリクス (トランスポートに関連する) を保存するタスクには十分です。
3. 指標の可視化
   ここではすべてが比較的単純です。 ウェアハウスからデータを取得し、リアルタイムまたは遡及的に表示します。
4. 中央監視システムとのデータの同期。
   集中監視システムは、すべてのデバイスからデータを受信し、指定された履歴とともに保存し、API 経由でお客様の監視システムに送信します。 「頭」が歩き回ってデータを収集する従来の監視システムとは異なり、私たちは逆のスキームを採用しています。 接続があると、デバイス自体がデータを送信します。 これにより、デバイスが利用できなかった期間にデバイスからデータを受信し、デバイスが利用できない間はチャネルやリソースを読み込まないようにすることができるため、非常に重要な点です。 集中監視システムとしてInflux監視サーバーを使用しています。 類似物とは異なり、遡及データ (つまり、メトリクスを受信した時点とは異なるタイムスタンプを持つデータ) をインポートでき、収集されたメトリクスは Grafana によって視覚化され、ファイルで変更されます。 この標準スタックが選択されたのは、ほぼすべての顧客監視システムと既製の API 統合が備わっているためです。
5. 中央デバイス管理システムとのデータ同期。
   デバイス管理システムは、ゼロ タッチ プロビジョニング (ファームウェア、構成などの更新) を実装しており、監視システムとは異なり、デバイスごとの問題のみを受け取ります。 これらは、オンボード ハードウェア ウォッチドッグ サービスの動作と、CPU および SSD の温度、CPU 負荷、空き領域、ディスク上の SMART 状態などの生命維持システムのすべてのメトリクスのトリガーになります。 サブシステム ストレージも Tarantool 上に構築されています。 これにより、数千のデバイスにわたる時系列の集約が大幅に高速化され、これらのデバイスとのデータ同期の問題も完全に解決されます。 Tarantool は優れたキューイングと保証された配信システムを備えています。 この重要な機能はすぐに使えるようになりました。素晴らしいです。

ネットワーク管理システム

次のステップ

これまでのところ、私たちの最も弱い部分は中央監視システムです。 これは 99.9% が標準スタックに実装されており、いくつかの欠点があります。

1. InfluxDB は電源が失われるとデータを失います。 原則として、お客様はデバイスから取得したすべてのものを速やかに収集し、データベース自体には 5 分より古いデータは含まれませんが、将来的にはこれが面倒になる可能性があります。
2. Grafana には、データの集約と表示の同期に関して多くの問題があります。 最も一般的な問題は、データベースに、たとえば 2:00:00 から始まる 00 秒間隔の時系列が含まれており、Grafana が +1 秒から集計でデータを表示し始める場合です。 その結果、ユーザーは踊るグラフを見ることになります。
3. サードパーティの監視システムと API を統合するためのコードが多すぎる。 はるかにコンパクトにすることができ、もちろん Go で書き直すこともできます)

皆さんは、私がいなくても Grafana がどのようなものかを完全に見て、その問題点を知っていると思います。そのため、投稿に写真を多用することはしません。

まとめ

技術的な詳細についてはあえて説明せず、このシステムの基本設計のみを説明しました。 まず、システムを技術的に完全に説明するには、別の記事が必要になります。 第二に、誰もがこれに興味があるわけではありません。 知りたい技術的な詳細をコメントに記入してください。

この記事の範囲を超えて質問がある場合は、a.rodin @ qedr.com までご連絡ください。

出所： habr.com