監視ソリューションは、デバイスにクエリを実行してデバイスから監視情報を取得するか、デバイス自体がコードを使用してAPIを使用して監視システムにデータをプッシュすることができます。 どちらも同じように機能しますが、ユースケースは異なります。 デバイスにリモートでクエリを実行できるとは限りません。つまり、デバイス自体にデータを監視プラットフォームに送信するように依頼する方が簡単です。 プッシュメトリックの詳細と、それを使用するのが最も理にかなっている場合については、読み続けてください。
このブログでは、以下について説明します。
- プッシュメトリックのユースケース
- プッシュメトリックの詳細なユースケース
- プルの代わりにプッシュメトリックを使用する利点
- プッシュメトリックの制限
- メトリックをプッシュするためのLogicMonitorのアプローチ
- 顧客フィードバック
プッシュメトリックのユースケース
コンピューティングアーキテクチャがより一時的で一時的なステートレスインスタンスに進化するにつれて、コレクターをバイパスしてデータを直接 監視プラットフォーム 摂取のために不可欠です。 プッシュメトリックのいくつかの著名な幅広いユースケースは次のとおりです。
サーバーレスコンピューティングサービスの監視
AWS Lambdaなどのサーバーレスコンピューティングサービスは、データ取り込みのプッシュモデルに最適です。
カスタムメトリックモニタリング
プッシュメトリクスRESTAPIは、外部エンティティを定義または構成する必要なしに、アプリ自体の内部からデータをレポートする機能を提供します。 これは、DevOps環境のヘルスメトリクス（CI / CDパイプラインメトリクス、自動スケーリングアプリケーションメトリクスなど）や、新規注文数などのビジネスメトリクスを監視するのに役立ちます。
一時的なリソースの監視
今日のコンピューティングインスタンスの多くは、本質的に一時的なものです（たとえば、コンテナー、バッチジョブ、クラスターとして実行されるサービス、スクリプト、cronジョブなど）。 それらの場所、存続時間（TTL）、およびその他の属性は完全にトランザクションです。 通常、これらのインスタンスもステートレスであり、それら自体に関する履歴情報はありません。 従来のリソース監視方法を使用してこれらの一時的なリソースからデータを取得することは、複雑な作業です。 一方、データのプッシュは非常に効率的な監視モデルです。
プッシュメトリックの詳細なユースケース
| ユースケース/説明 | メトリック |
|---|---|
| 一時的なコンピューティングで実行されているアプリケーション 自動スケーリングをサポートするコンテナ/ VM | コンテナ内で実行されているアプリケーションによって提供されるAPI呼び出しの数 -コンテナ内で実行されているアプリケーション内から、API呼び出しをインターセプトし、定期的にレポートします アプリケーションによるリソース使用率 -コンテナ内で実行されているアプリケーション内から、API呼び出しをインターセプトし、定期的にレポートします |
| カスタムビジネス指標 ビジネスサービスのビジネスメトリックをプッシュします（複数のホスト/コンテナーで実行）。 ビジネスアプリケーションの言語にとらわれません。 | 新規注文数 出荷された注文の数 購入率 |
| IoTデバイス | 温度 生産数 デバイスの可用性 |
| サーバーレスコンピューティングサービス AWSラムダ | XNUMX分あたりのLambda関数が呼び出される回数 -呼び出された関数内から、呼び出しごとにデータを送信します ラムダインスタンスの処理時間/ライフタイム -呼び出された関数を終了する前に、リクエストを処理して送信するのにかかる時間を計算します |
| 合成モニタリング | 商品在庫 レスポンス エラー |
| チケット管理システム 例としてJiraを使用すると、チケットはさまざまな利害関係者によって作成されるため、JIRA REST APIを使用して、チケットに関するカスタムデータを収集し、LogicMonitorに送信できます。 | 新しいチケットの数 クローズされたチケットの数 優先利害関係者のために作成されたチケットの数 |
| 一時的なシステム Lambda 関数は、S3、DynamoDB、 キネシス、SNS、CloudWatch。 呼び出しは純粋にランダムであり、実行されるコードは呼び出しごとにステートレスです。 したがって、インスタント データのみをレポートできます。 | cronジョブ -処理されたタスクの数 スクリプト -イベントの送信、リモートアクション、またはチケットの作成のいずれかのために起動されたスクリプト実行のステータス -ログを解析してメトリックを送信する CPU使用率、メモリ使用率、ディスクI / O、ネットワーク使用率をOSで監視するためのスクリプト -各コンテナおよびすべてのコンテナ全体で使用されているインフラストラクチャ -PowerShellスクリプトまたは実行可能ファイルを使用してデータを収集し、定期的にLogicMonitorに送信します -OpenTelemetry、Nagios、またはその他のテクノロジー用のエクスポータープラグインも使用できます |
プルの代わりにプッシュメトリックを使用する利点は何ですか？
デバイスが定期的にインターネットに接続し、動的IPアドレスを持っている場合、従来のプルメカニズムを使用して監視データを抽出することはできません。 ここでのプッシュメトリックは、監視データにアクセスする唯一の方法です。
プッシュメトリックのいくつかの制限は何ですか？
プッシュメトリクスで採用されているプッシュモデルは、理論的には、監視システムが大規模なIoT環境で受信するデータの量を制御することを困難にする可能性があります。 大規模なセンサーネットワークのプッシュメトリックを活用している場合、これは理論的には監視プラットフォームを圧倒する可能性があります。 また、プラットフォームと通信するすべてのデバイスにローカルTLS証明書を適用する必要があるため、メトリックをプッシュするためのセキュリティを構成するのは困難です。
メトリックをプッシュするためのLogicMonitorのアプローチ
LogicMonitorの プッシュメトリック機能 専用APIを介してメトリックをLogicMonitorプラットフォームに直接送信できるため、LogicMonitorコレクターを介してデータをルーティングする必要がなくなります。 取り込まれると、これらのメトリックはLogicMonitorを介して収集された他のすべてのメトリックと一緒に表示され、メトリックの監視とアラートのための単一のガラス板を提供します。
弊社のデータソースで従来採用されているプルモデルとは対照的に、プッシュメトリックで採用されているプッシュモデルは、コレクターのインストールが面倒または実行不可能な多くのユースケースで有益です。
プッシュメトリックによる可観測性の有効化
お客様のNunoRosa、エンタープライズアーキテクトおよびモニタリングスペシャリストに インフォシス 新しいプッシュメトリクス機能に関する彼の考え。 これが彼が言わなければならなかったことです：
「LogicMonitorのプッシュメトリクスAPIは、インテグレーターが外部ソースから生データをプッシュできるようにするエンドポイントを提供します。 LogicMonitorと他のアプリケーション間の双方向性により、メトリックをプッシュする機能（つまり、アラートに添付されたServiceNowインシデント情報、およびLogicMonitorコンソールからインシデントの進行状況と相互作用を確認する機能）によって新たな勢いが得られます。 メトリックをプッシュする機能により、ビジネス中心のデータをLogicMonitorに送信することもできます。 追加の可観測性を可能にする 運用インテリジェンスに移行し、ユーザーオーディエンスを多様化して非技術的なペルソナを含めます。
サーバーレスコンピューティングは、大企業内でトレンドになりつつあり、電力使用量（PuE）を最適化することでグリーンポリシーの主要なアクセラレーターになりつつあります。 プッシュメトリクスは、新しい監視機能の要件に適応するためになくてはならないものになるでしょう。」
