Dotcom-Monitorによる不眠症コレクションの監視

Insomnia を使用した内部 API テスト用の一連の統合テストがある場合は、Insomnia テスト コレクションを Dotcom-Monitor にアップロードして、40+ のグローバルな場所から API テストを行うことができます。

Dotcom-Monitor は、監視中に発生したエラーのアラート、監視場所の指定、監視スケジューラとフィルターの構成、監視結果に関するレポートの設定など、さまざまなオプションをサポートしています。 監視チェックを毎分から3時間ごとにスケジュールすることで、チームは監視設定の柔軟性を高めることができます。

はじめに

不眠症リクエストコレクションと設計文書

デバイス構成を開始する前に、Dotcom-Monitor が不眠症要求コレクションと設計ドキュメントの両方のインポートをサポートしていることに注意してください。 ただし、インポートされた設計ドキュメントとリクエストコレクションの処理方法には違いがあります
。

不眠症デザインドキュメントをドットコムモニターにアップロードして監視テストを実行すると、テストスイートリストから最初のスイートのみが実行されます。 ドキュメント内の他のすべてのテストスイートは無視されます。

不眠症リクエストコレクションをDotcom-Monitorにアップロードすると、コレクションが実行され、404、401、500などのネットワークおよび応答コードエラーの応答が検証されます。

不眠症収集監視装置のセットアップ

監視デバイスの作成方法の概要については、「監視デバイスのサポート技術情報 の作成 」を参照してください。

不眠症コレクションのグループに対して監視を設定する場合は、デバイスごとに 1 つのコレクションを設定することをお勧めします。 詳細については、ウィキの マルチターゲットの制限 の記事を参照してください。

テストで設定された条件が満たされない場合、またはコレクションの実行中にネットワーク エラーが検出された場合に

、Dotcom-Monitor でアラートを生成し、アラート通知を送信する場合は、必ずデバイス アラート設定を構成してください。

Insomnia Collection & Design Document のインポート

クリック 輸入 をクリックし、アップロードする Insomnia Collection または Document を含む JSON ファイルを選択します。 ザ 不眠症スクリプト に表示されます。 収集要求 節.

コレクションタイムアウト

収集タイムアウトは秒単位で測定され、デバイスがタスクを終了してエラーを発生させる前に、不眠症の要求とテストが完了するまで待機する期間を決定します。

スクリプトの準備

「 準備スクリプトの使用 」の記事を参照してください。

要求内のデータの保護

不眠症の要求と共に送信される機密情報を保護する方法については、 Dotcom-Monitor を使用した不眠症要求の機密データの保護 に関する記事を参照してください。

ネットワークエラーを無視する

ネットワークエラーには、DNS解決エラー、TCP接続のタイムアウト/エラー、またはサーバーが4xxまたは5xx応答ステータスコード(およびデータなし)で接続を終了またはリセットするインスタンスが含まれる場合があります。デフォルトでは、Dotcom-Monitor はエラーを生成し、実行中に発生した不眠症ネットワーク エラーに関するアラート通知を送信します。ネットワークエラーが問題にならない場合、またはネットワークエラーが予期されるシステム動作である場合は、このタイプのエラーを除外するようにInsomnia Collection監視デバイスを構成できます。

[ ネットワーク エラーを無視する ] オプションが [ はい ] に設定されている場合、Dotcom-Monitor は不眠症コレクションからの失敗した要求でエラーを発生 させず 、デバイスの状態を [アラート] に変更します。 ただし、セッション レポートの監視に HTTP エラーが表示されます。 このシナリオでは、Collection テスト スイートを使用して応答の有効性を検証します。

一般に、不眠症コレクションでインポートされたテストに完全に基づく監視結果を受け取る場合は、[ ネットワークエラーを無視 ]オプションを有効にすることをお勧めします。

エラーコードを無視する

「Web サービスおよびインターネット インフラストラクチャの監視で Web 要求エラーを無視する」を参照してください。

OAuth 2.0 ベースの API のモニタリング

一般に、OAuth 2.0 を使用したサービス API 呼び出しには、順番に実行される 2 つの手順が含まれます。 次に、付与されたベアラートークンを使用して、サービスからカスタムデータを要求します。

ただし、新しい環境で OAuth アクセス トークンを取得する際の未解決の不眠症の問題により、このトークンベースの認証は Dotcom-Monitor へのインポート時に失敗します。 つまり、2 番目の要求は、最初の要求で取得されたベアラー トークンへの参照を失います。

回避策として、ベアラー トークンを必要とする API 呼び出しは、Insomnia 内の 1 つの要求で処理できます。

Dotcom-Monitor を使用して Insomnia コレクションをインポートして監視するには、コレクションの最初の API 呼び出しで認証トークンを要求しないでください。 代わりに、OAuth 2 認証タイプを使用して、データ要求で直接認証を設定します。

 

このようにして、Insomnia コレクションがインポートされ、Dotcom-Monitor で正しく実行されます。