データ収集を監視する監視システムの1つ

監視システム-監視データ収集

インターネットの発展に伴い、運用と保守の複雑さは指数関数的に増加しました。それに関連するさまざまな運用と保守のプラットフォームの複雑さも指数関数的に増加しました。このシナリオでは、安定した作業のニーズを最大限に満たし、システムが比較的クリーンで分離されていることを確認する方法を追求し、議論してきました。モニタリングプラットフォームのトピックは非常に大きいですが、それでもここで少し説明したいと思います。ビジネスがより複雑になるにつれて、さまざまな形が出現します。ただし、一般に、取得、保存、およびアラームの3つの部分があります。この記事では、監視システムの最初の部分であるデータ収集について説明します。うまく書けない場合は、スプレーしないでください。ただし、それは可能です...

1.監視システムはどのようなデータを収集する必要がありますか？

監視システムでどのデータを収集する必要があるかというと、まず、どのデータを収集する必要があるかを理解する必要があります。監視システムは、リアルタイムのデータ表示に使用したり、履歴状態のレビューに使用したり、異常なアラームに使用したりできます。これらはすべて正確なデータを収集する必要があります。データ収集の目的は、さまざまなビジネスニーズを満たすのに十分なデータを収集することです。

基本データ
基本データ、サーバーの状態を監視するための基本的な指標。CPU、メモリ、ネットワーク、IO、その他のカテゴリを含め、ここではすべてをリストしません。
アプリケーションデータ
アプリケーションデータとは、サーバー上で実行されているアプリケーションのステータスデータを指します。たとえば、ポートの存続、プロセスの存続、プロセスのリソース消費などです。データのこの部分を最大限に活用すると、独自のサービスにサバイバルアラームを追加し、プロセスリソースの過去の占有率を追跡できます。
事業データ
上記2種類のデータに注意が必要ですが、通常の安定作業では、上記に問題がないだけでは不十分であり、事業に問題が生じる可能性があります。したがって、事業の運営状況を示す明確な指標が必要です。この指標をビジネス指標と呼びます。業務が完全に正常かどうかを判断するために、サービスがダウンしていなくても問題がないという意味ではありません。変更によって引き起こされる論理的な問題、誤ったデータの影響、およびデータが多すぎることによって引き起こされる応答タイムアウトは、アプリケーションの存続状況からは発見できません。一般的に言って、ビジネスのステータスを判断するために、トラフィック、インターフェイスエラー率、インターフェイス呼び出し遅延などの指標を観察することに慣れています。これらの指標は、さまざまな角度から事業の状況を判断するために使用できます。もちろん、ビジネスの状況に応じて、指標には他にも多くの側面があり、それらはすべてビジネス指標の範囲に含まれます。

データ・モデル

監視システムの監視収集方法について話すには、監視データモデルから始める必要があります。監視対象のデータは、実際には最も純粋な時系列データです。次に、監視システムを構築する場合、統一されたデータモデルを抽象化することが、設計とアーキテクチャの最初のステップである必要があります。一般的な時系列データは

、上図に示すように、データ名（メトリック名/メトリック）、ラベル（タグ/タグ）、タイムスタンプ（タイムスタンプ）、値（値）の4つの部分で構成されます。これはオープンファルコンデータモデルです。これはデータモデルがあります基本的な時系列モデルにいくつかのカスタマイズが行われ、endpointとcounterTypeの2つのフィールドが追加されました。

#####収集方法
監視システムの収集方法は、監視データのソースによって異なります。これは主に、デフォルトの収集、プラグイン、検出、ログ、および埋め込みポイントに分けられます。

デフォルトの収集
デフォルトのコレクションは通常、デフォルトのエージェントで収集されます。たとえば、CPU、メモリ、IOなどのマシンの基本的なインジケーター、およびプロセス監視の関連するインジケーターはすべてこのカテゴリに含まれます。このようなインジケーターは通常、エージェントで事前定義されており、インジケーターの量はそれほど増えません。
探索的コレクション
名前が示すように、外部検出ベースのコレクションはこのカテゴリに分類されます。ポート監視、Ping監視、HTTP監視、ネットワーク監視など。探索的コレクションはプラグインコレクションです。このタイプの取得は比較的軽量で、システムへの影響が少ないです。シンプルな構成で、効果をすばやく確認できます。このタイプの監視には、ネットワークモニタリング自体に加えて、ネットワークに大きく依存するという重要な機能があります。ネットワークが不安定になると、誤警報が発生する可能性が非常に高くなります。そのため、誤警報の発生をある程度防ぐことができる多点検出方式を採用することができます。
ビジネスの埋もれたポイント
ビジネス開発のクラスメートよりも優れている人は、自分のシステムをよく知っており、どのような状況でどのコア指標を観察する必要があるかを知っています。
したがって、ビジネスコレクションを標準化することが非常に必要です。原則を提案します。ビジネス指標の収集は揺るぎないコードの一部であるという原則を順守します（笑）。事業の安定性指標は、開発作業の内容の一つでなければなりません。モジュール自体の運用と保守は、プロジェクトの開発標準の1つである必要があります。このため、運用と保守では、安定した監視カバレッジ標準（コールトラフィック、リターンエラー率、インターフェイス遅延など）を提供する必要があります。対応するツールとプラットフォームのサポートなしでのすべての運用および保守標準の策定は、空の話です。したがって、監視システムは、さまざまな言語のビジネス埋め込みSDKと、迅速かつ簡単なデータ収集のためのプラットフォームも提供する必要があります。
ほとんどの開発チームには独自の開発フレームワークのセットがあります。ビジネスに深く入り込むことができる場合は、埋め込みポイントSDKをビジネスラインの統合開発フレームワークに直接統合することをさらに検討することもできます。
ログの監視
安定性の観点から、ほとんどの場合、ログの監視とビジネスの埋設ポイントは同じデータを取得します。ログの監視がより柔軟であるというだけです。サービスがクローズドソースプロジェクトである場合、または短期間で使用されるオープンソースコンポーネントを迅速に変更できない場合、ログの監視はすぐに有効になります。一般的に、ログの監視はオンラインログ収集とオフラインログ収集に分けられます。
1.オンラインログ収集は、一般的に柔軟性があります。さまざまなカスタム操作を使用して、ログの時間、内容、および大きさをフィルタリングおよび計算できます。必要な構成コストはわずかです。ただし、この種のログ収集はより煩わしく、マシンにエージェントをインストールする必要があり、リアルタイムのログ分析はCPUリソースを消費するため、オンラインサービスの安定性に影響を与える可能性があるため、リソース制限を行う必要があります。。
2.オフラインログ収集とは、ログを一律に収集し、中央で計算を処理することです。このコレクションの利点は、CPUリソースをあまり消費せず、ログの量にボトルネックがないことです。しかし同時に、それはまた多くのネットワークリソースを消費します。適時性に関しては、リアルタイム分析と比較して、多少の遅延があります。ログの大規模なバッチを集中処理するには、ログの形式を標準化する必要があるため、柔軟性が低下する可能性があります。
プラグインの収集
、埋め込みポイント、ログ、および検出の基本的なインジケーターがあります。他の人はどうですか？ユーザーが独自の収集方法を持っているが、データを監視システムに報告する必要がある場合、このシナリオはプラグイン収集で実現できます。プラグインコレクションは、監視システムによる収集サイクルを制御する方法を提供し、ユーザーはデータ収集を完了するために収集ロジックのサイクルを実装するだけで済みます。プラグインコレクションはより柔軟性があり、jumなどの特定のコレクションコマンドなどのユーザー定義のコレクションメソッドを提供できます。プラグインは、監視システムによって開発された標準化されたデータを報告するだけで済みます。プラグインの収集には、マシン上でプラグインスクリプトを定期的に実行する必要があるため、このスクリプトの監査を確認する必要があります。有害なアクションであろうとリソースの消費であろうと、オンラインの安定性に影響を与える隠れた危険になる可能性があります。
カスタムインデックスレポート
上記のいくつかの収集方法に加えて、監視システムはカスタムレポートの機能もサポートする必要があります。ユーザー定義の時系列はすべて、データの視覚化とアラーム機能に監視システムを使用することを望んでいます。現時点では、ローカルエージェントによって収集されたものであれ、別の中央コレクターによって収集されたものであれ、カスタムデータレポートインターフェイスを提供できます。カスタムインジケータのレポートにより、監視システムは本当に安定したインフラストラクチャになります。open-falconの収集エージェントは、このようなインターフェイスを提供します。ただし、カスタマイズはサポートされていますが、ユーザーのレポート動作を適切に規制することはできません。データが誤って報告されたり、不規則に使用されたりすることがあります。このとき、監視システムはダーティデータを管理する必要があります。

監視システムのデータ収集方法

一般に、2つの収集方法があります。センターからのアクティブプル（プロメテウス）とクライアントからの自動レポート（その他）です。

中央端でのアクティブプル（プロメテウス）とは、中央端がオンデマンドで収集端からデータを定期的にプルすることを意味します。このモデルの利点は、無駄なくオンデマンドでプルできることです。しかし、このモデルでは、センターに過度の圧力がかかっています。理論的には、パフォーマンスには大きなボトルネックがあります。
クライアントの自動レポート（その他）
は、すべてのデータが同じように扱われ、すべてがレポートされることを意味します。一般的に、収集には統合プロキシが使用され、次にマルチレベルコンポーネントが検討されるか、MQのレイヤーが追加されます。これらはすべて検討可能な設計です。一般的に、監視データの量が比較的多いと推定される場合。自己収集と集中レポートのモードを採用することをお勧めします。open-falconのデータ収集は、非常に優れたクライアント側の自動レポートモードです。