このセクションでは、ドットコムモニター監視ツールを使用してアプリケーションを開発するソフトウェア開発者を支援します。

データを消費する XML フィード を使用したり、インストールされている監視エージェントを監視および更新する Dotcom-Monitor API と対話するなど、Dotcom-Monitor Web サイト インターフェイスを超えて監視データを表示および操作する方法はいくつかあります。

XML フィードを使用すると、開発者は必要なデータをサブスクライブし、独自のカスタム レポートを使用して独自の形式で表示できます。 詳細については 、「XML レポート サービス (XRS) ツールの使用 」を参照してください。

Dotcom-Monitor API ユーザーは、独自のカスタム スクリプトまたはアプリケーションを作成して、設定を操作し、独自のカスタマイズされた環境で監視対象データを表示できます。 当社のシステムは、HTTP(S) 要求 (GET、POST、PUT、DELETE) を介してデータを操作するための最も一般的なメソッドを使用して、プログラムで Dotcom-Monitor Web サイトとの対話を可能にする REST API を使用します。 ほとんどすべてのドットコムモニタオブジェクトはREST APIを介してアクセスでき、ドットコムモニタサービス機能のほぼすべての側面を管理することができます。 API 呼び出しを使用すると、デバイスやタスクの作成と削除、延期と開始、アラート グループ、テンプレート、フィルター、スケジューラの作成と管理、デバイスの状態情報、およびその他の多くのオプションを取得できます。

一般に、ドットコムモニタ API は次のタスクで使用できます。

  • ドットコムモニタ監視ソリューションとのサードパーティ統合。
  • データのダウンロードとアップロード。
  • データの変更。

REST API を使用して実行される最も一般的なアクション:

  • 監視プラットフォーム、デバイス、ターゲット、スケジューラ、ロケーション、アラートグループ、フィルタ、アラートテンプレートのリストにアクセスする。
  • プラットフォーム、デバイス、ターゲットに関する詳細情報にアクセスする。
  • デバイス、ターゲット、スケジューラ、アラートグループ、テンプレート、フィルタの編集。
  • 新しいドットコムモニタオブジェクト(デバイス、ターゲット、スケジューラなど)を作成します。
  • 監査オブジェクトの管理。

カスタムコレクタAPI

別の メトリックスビュー API は、プラットフォームに関係なく、任意のソースから任意のメトリックをアップロードするためのメソッドのセットは、Dotcom-Monitor Inc.に、さらなる処理と分析を行います。

ドットコムモニタ API は、10 種類のリソースに分かれています。

  • プラットフォーム: すべての監視タスクは、5 つの異なるプラットフォームのいずれかに分類されます。
  • デバイス: 監視対象デバイスは、単一の監視タスク、一連の監視タスク、タスクを含む監視スクリプト、または 3 つのタスクの組み合わせを含む監視タスクの整理された”セット”です。
  • タスク: タスクとは、ターゲット (URL、メール サーバー、FTP サーバーなど) の監視など、任意の単一の監視アクティビティです。
  • 周波数: 監視セッションを実行する頻度を定義します。
  • スケジューラ: スケジューラーは、タスクがいつ実行されるか、実行されないかの詳細です。
  • 場所: Dotcom-Monitor の世界規模の監視ネットワーク内で利用可能な監視場所。
  • アラート グループ: グループを設定すると、レポートやアラートの受信者がグループに配置されます。 グループ内の各受信者は、固有の通知テンプレートを持つことができます。
  • アラート テンプレート: テンプレートは、アラートの形式を定義します。
  • フィルタ: フィルターは、監視応答の処理方法と表示方法を決定する一連のルールです。
  • 監査: 各アカウントの変更に関する履歴情報を提供します。

API 要求の前に、Dotcom モニターで 認証 する必要があります。 60 秒間の非アクティブ状態の後、認証は期限切れになります。

次の表は、各リソースの種類でサポートされている要求の種類とアクションを示しています。 詳細については 、「監視方法 」セクションを参照してください。

リソースの種類 リクエスト方法 URI(s) 形容
プラットホーム 取得 /プラットフォーム 利用可能なプラットフォームのリストを返す
デバイス 取得 /デバイス/{platform} プラットフォーム別にデバイスリストを取得します。
取得 /デバイス/{deviceId} デバイス情報の取得
投稿 /デバイス?動詞=PUT 新しいデバイスの作成
置く /デバイス
投稿 /デバイス/ {deviceId} /無効アラート/ アラートを無効にする
投稿 /デバイス/{deviceId} デバイスの編集
投稿 /デバイス/ {deviceId} ?動詞=削除 デバイスの削除
削除 /デバイス/{deviceId}
タスク 取得 /デバイス/ {deviceid} /タスク デバイスの下でタスクの一覧を取得する
投稿 /タスク?動詞=PUT 新しいタスクの作成
置く /タスク
取得 /タスク/{TaskId} タスク情報の取得
投稿 /タスク/{TaskId} タスクの編集
投稿 /タスク/ {TaskId} ?動詞=削除 タスクの削除
削除 /タスク/{TaskId}
周波数 取得 /周波数/{platform_name} 利用可能なfreqを取得します。 プラットフォーム別。
スケジューラ 取得 /スケジューラ スケジューラの一覧を取得する
取得 /スケジューラ/{Scheduler_ID} 特定のスケジューラ情報を取得する
投稿 /スケジューラ?動詞=PUT 新しいスケジューラの作成
置く スケジューラ
投稿 /スケジューラ/{スケジューラ ID} スケジューラの編集
投稿 /スケジューラ/ {Scheduler_Id} ?動詞=削除 スケジューラの削除
削除 /スケジューラ/{Scheduler_Id}
場所 取得 /場所/{platform_name} 利用可能な場所の一覧を取得する
アラート グループ 取得 /グループ アラート グループの一覧を取得する
投稿 /グループ?動詞=PUT/グループ 警告グループの作成
置く グループ/グループ
取得 /グループ/{Group_ID} アラート グループ情報の取得
投稿 /グループ/{Group_ID} 警告グループの編集
投稿 /グループ/ {Group_Id} ?動詞=削除 グループの削除
削除 グループ/{Group_Id}
アラート テンプレート 取得 /テンプレート アラート テンプレートの一覧を取得する
投稿 /テンプレート?動詞=PUT/テンプレート 新しい警告テンプレートの作成
置く /テンプレート/テンプレート
取得 /テンプレート/{Template_ID} アラート テンプレート情報の取得
投稿 /テンプレート/{Template_ID} 警告テンプレートの編集
投稿 /テンプレート/ {Template_Id} ?動詞=削除 テンプレートの削除
削除 /テンプレート/{Template_Id}
フィルター 取得 /フィルター フィルタの一覧を取得する
投稿 /フィルター?動詞=PUT 新しいフィルターの作成
置く /フィルター
取得 /フィルター/{filter_ID} 特定のフィルター情報を取得する
投稿 /フィルター/{filter_ID} フィルターの編集
投稿 /フィルター/ {filter_ID} ?動詞=削除 フィルタの削除
削除 /フィルター/{filter_ID}
監査 取得 /監査/リスト 最新の 24 時間の現在のユーザーのリストの監査済みオブジェクトを取得します。
取得 /監査/オブジェクト/{サンプル ID} 特定の ID の監査内容を取得する
投稿 /監査/リスト 監査対象オブジェクトのフィルター処理されたリストを取得します。
  • Web API Monitoring: How to Start and What Approach to Use

    「Web API の監視」トピックを始める前に、さまざまな種類のソフトウェア間でデータを交換するためによく使用されるアプローチについて簡単に説明します。

    すべてのビジネス プロセスが単一のソフトウェア製品で実行されている最新の企業を想像するのは難しいです。 一般に、複数のデスクトップアプリケーションと Web アプリケーションを使用して、ライフサイクル全体を通じてビジネスオペレーションをサポートします。 一部のアプリケーションは関連ソフトウェア製品と対話できますが、他のアプリケーションでは追加の構成やサードパーティのサービスが必要です。 たとえば、ソフトウェア統合をサポートするためにソフトウェア市場に導入された一般的なプラクティスは次のとおりです。

    • Web サービス。
    • FTP経由でのファイル交換。
    • 非構造化 HTTP 要求。
    • Web ソケット、専用ポートなどの他のアプローチ

    他のすべてのソフトウェア統合アプローチには、標準化されたデータ交換プロセスはありませんが、Webサービスは標準化された統合方法を提供します。 Web サービスは、アプリケーションがネットワークを介して相互に通信できるようにするテクノロジです。 簡単に言えば、Webサービスはインターネット上のアドレスであり、データを取得したり、アクションを実行するためにアクセスできるリンクです。 通常、HTTP を介して実行される Web サービスは Web API と呼ばれます。 HTTP をトランスポート プロトコルとして使用する利点は、Web サービスをプログラミング言語から独立させることです。 Web サービスの場合、クライアントがリソースに要求を出し、応答を提供する API サーバーは、任意のプログラミング言語またはフレームワークを使用できます。 このように、接続したいアプリケーションが同じプログラミング言語を使用して開発されているかどうかは問題ではありません。

    Web API は通常、次のテクノロジを使用して実装されます。

    • XML-RPC (拡張マークアップ言語リモート プロシージャ コール) – HTTP をトランスポート プロトコルとして使用し、XML を使用して呼び出しをエンコードするプロトコル。
    • JSON-RPC (JSON リモート プロシージャ コール) – メッセージを除く XML-RPC の類似点は JSON 形式で転送されます。
    • SOAP (簡易オブジェクト アクセス プロトコル) – メッセージ構造を記述するために XML に基づく WSDL (Web サービス記述言語) を使用する標準化されたプロトコル。
    • REST (表現状態転送) – プロトコルではなく、HTTP プロトコルのメソッドに基づくネットワーク内のソフトウェア対話のアーキテクチャ。
    • 特定のタスクに対して動作するように設計された特殊なプロトコル (API サーバーへのクエリを作成し、その API からクライアント アプリケーションにデータを読み込むために使用する GraphQL など)。

    API モニタリングとは

    アプリケーション用の Web API を実装し、公開を検討したら、すべての API 関数がアプリケーションのビジネス ロジックに従って動作することを確認する必要があります。 さらに、API サービスの利用者であるか、サード パーティ製アプリケーションにサービスを提供しているかに関係なく、Web API のパフォーマンスを把握しておくことは非常に重要です。 API サービスのパフォーマンスが低下すると、関連するビジネスに大きな損失が生じ、ユーザーのエクスペリエンスに影響を与える可能性があります。

    API 監視の主な目的は、API 内のすべてのエラーが発生したときに、ユーザーが気付く前に、事前に検出して修正することです。

    なぜ Web アプリケーションまたは Web サイトの API を監視する必要があるのですか? WEB アプリケーションが正しく動作することを確認するのに十分な UI テストがなぜできないのですか? 実際のユーザーの動作をシミュレートする UI テストは、実際の方法です (Dotcom-Monitor EveryStep スクリプト ツールを使用して実際のブラウザーで Web アプリケーションをテストする利点を参照してください)。 ただし、UI を通じて監視する傾向がある Web サイトの機能は、API 監視テストで既にチェックできます。 たとえば、オンライン ストアの在庫アイテムの一覧を読み込む API 呼び出しは、バックエンドで変更されましたが、UI 上で同じままであり、システムは Web サイト上の対応するユーザー アクションのリストを返しません。 この場合、UI 監視はエラーを返しますが、エラーの本当の原因は検出されません (接続の問題、サーバーの過負荷、UI エラー、不正な API 呼び出しなど)。 一方、Web API の監視では、ターゲット API エンドポイントへの呼び出しが応答を返さないことが示されます。 追加の API 呼び出し結果の検証では、応答コンテンツ検証を使用できます。

    API モニタリングのしくみ

    Web API の監視では、リソースとこれらのリソースへのアクセスに重点を置いています。 Web API では、リソースはさまざまな種類の情報を提供します。 リソースには URL (一様リソース ロケーター) を使用してアクセスできます。 ブラウザーで特定の URL に移動すると、その URL に対応するリソースに接続します。 Postman などのアプリケーションからリソースの URL アドレスに API 要求を送信したり、CURL を使用したりする場合も同様です。 リソースに対して実行するアクションを Web サービスに対して明確にするために、GET (読み取り)、POST (作成)、PUT (更新)、DELETE (削除) などの HTTP メソッドが使用されます。 Dotcom モニタを使用して RESTful API を監視する方法の詳細については 、「REST ペイロード – Web API にプッシュする方法」を参照してください。

    各要求の後に、API サーバーからの応答が続きます。 応答は、要求に応答して API から返されるデータです。 応答は、JSON オブジェクトを含むさまざまなデータを返すことができます。

    要求パラメーターを含み、リソースへのアクセスを提供するリソースへのパス全体を Web API エンドポイントと呼びます。 たとえば、API 呼び出しを送信するエンドポイントは次のようになります。

    http://example.com/wp-json/wp/v2/tests

    簡単に言うと、エンドポイントは、Web サイトやアプリケーションの Web API 監視呼び出しを実行する際にチェックするものです。 一般に、API エンドポイントの監視手順には次のものがあります。

    • エンドポイントへの要求。
    • API サーバーからの応答。
    • 応答の検証と分析。

    ドットコムモニターを API 監視ツールとして使用する利点

    Dotcom-Monitor は、あらゆる種類の Web API 監視に使用できる包括的なソリューションです (SOAP Web サービス監視REST Web API 監視の設定方法を参照してください)。 また、Web アプリケーション、Web サイト、単一の Web ページ、Web サーバー、その他の種類の Web リソースの監視ツールも提供しています。

    監視プロセスを新しいレベルに引き上げるために、Dotcom-Monitorは、ユーザーが実際のブラウザウィンドウでターゲットWebアプリケーションをテストすることができます。 ブラウザベースのテストでは、監視テストが現実のシナリオにできるだけ近い状態で実行され、実際のユーザー エクスペリエンスが繰り返されます。 デスクトップやモバイルブラウザーエンジンなど、アプリケーションまたは Web サイトを実行するブラウザー エンジンの中から選択できます。

    要素ごとのウォーターフォール チャート、スクリーンショット、ビデオを使用した詳細なパフォーマンス レポートは、UI のシーンの背後で正確に何が起こるかを完全に理解できます。

    高度にカスタマイズされたドットコムモニターの警告システムは、効率的なアラート通知サービスを提供します。 監視中にエラーが検出されたときに、専用アドレスにアラート通知を送信するようにシステムを構成できます。 ナレッジベースの「アラート配信メカニズム」の記事で、サポートされている アラートメカニズム を参照してください。