HTTP テスト

HTTP テスト

概要

HTTP テストを使用すると、アプリケーションの API エンドポイントに HTTP リクエストを送信して、リクエストに応答していること、および全体的な応答時間、ステータスコード、ヘッダーまたは本文のコンテンツなどの定義した条件を満たしていることを確認できます。

HTTP テストは、ネットワークの外部または内部のどちらからエンドポイントを監視するかによって、管理ロケーションおよびプライベートロケーションから実行できます。HTTP テストは、スケジュールオンデマンド、または **CI/CD パイプライン**内で直接実行できます。

コンフィギュレーション

作成するテストのタイプを選択した後 (HTTPSSLTCPDNS、または ICMP テスト)、テストのリクエストを定義できます。

リクエストを定義する

  1. HTTP Method を選択し、クエリする URL を指定します。使用可能なメソッドは、GETPOSTPATCHPUTHEADDELETEOPTIONS です。httphttps の両方の URL がサポートされています。
  2. Advanced Options を使用して HTTP リクエストを加工します (オプション)。
  • Follow redirects: 選択すると、リクエストを実行するときに HTTP テストで最大 10 個のリダイレクトをフォローします。
  • Request headers: HTTP リクエストに追加するヘッダーを定義します。デフォルトのヘッダー (たとえば、user-agent ヘッダー) をオーバーライドすることもできます。
  • Cookies: HTTP リクエストに追加するクッキーを定義します。<COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2> の形式を使用して複数のクッキーを設定します。
  • HTTP Basic Auth: HTTP 基本認証資格情報を追加します。
  • Body type: HTTP リクエストに追加するリクエスト本文のタイプ (text/plainapplication/jsontext/xmltext/html、または None) を選択します。
  • Request body: HTTP リクエスト本文のコンテンツを追加します。: リクエスト本文は最大サイズ 50 キロバイトに制限されています。
  • Ignore server certificate error: 選択すると、SSL 証明書の検証時にエラーが発生した場合でも、HTTP テストが接続を続行します。
  • クライアント証明書: クライアント証明書 (.crt) と関連する秘密キー (.key) を PEM 形式でアップロードして、mTLS を介して認証します。openssl ライブラリを使用して証明書を変換することができます。たとえば、PKCS12 証明書を PEM 形式の秘密キーと証明書に変換できます。
openssl pkcs12 -in <CERT>.p12 -out <CERT_KEY>.key -nodes -nocerts
openssl pkcs12 -in <CERT>.p12 -out <CERT>.cert -nokeys
  • Proxy URL: HTTP リクエストが通過する必要があるプロキシの URL (http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>) を指定します。
  • Proxy Header: プロキシへの HTTP リクエストに含めるヘッダーを追加します。
  • Do not save response body: レスポンスの本文が実行時に保存されないようにするには、このオプションを選択します。テスト結果に機密データを含めたくない場合に有用です。障害発生時のトラブルシューティングに影響を及ぼす可能性があるため、慎重に使用してください。セキュリティに関する詳細は、こちらでご確認ください。
  1. HTTP テストに名前を付けます。
  2. HTTP テストに env タグとその他のタグを追加します。次に、これらのタグを使用して、Synthetic Monitoring ホームページで Synthetic テストをすばやくフィルタリングできます。
  3. HTTP テストを実行するロケーションを選択します。HTTP テストは、ネットワークの外部または内部のどちらからエンドポイントを監視するかによって、管理ロケーションプライベートロケーションから実行できます。

Test URL をクリックして、リクエストのコンフィギュレーションをテストします。画面の右側に応答プレビューが表示されます。

テストの頻度を指定する

HTTP テストは次の頻度で実行できます。

  • On a schedule: 最も重要なエンドポイントにユーザーが常にアクセスできるようにします。Datadog で HTTP テストを実行する頻度を選択します。
  • Within your CI/CD pipelines: 欠陥のあるコードがカスタマーエクスペリエンスに影響を与える可能性があることを恐れずに出荷を開始します。
  • On-demand: チームにとって最も意味のあるときにいつでもテストを実行します。

アサーションを定義する

アサーションは、期待されるテスト結果が何であるかを定義します。Test URL を押すと、response timestatus codeheadercontent-type の基本的なアサーションが、取得された応答に基づいて追加されます。テストで監視するには、少なくとも 1 つのアサーションを定義する必要があります。

タイプ演算子値の型
本文contains, does not contain, is, is not,
matches, does not match,
jsonpath
String
Regex
String, Regex
ヘッダーcontainsdoes not containisis not
matchesdoes not match
String
_Regex
response timeis less than整数 (ms)
ステータスコードisis not整数

: HTTP テストでは、brdeflategzipidentitycontent-encoding ヘッダーを使用して本文の圧縮を解除することが可能です。

New Assertion をクリックするか、応答プレビューを直接クリックすることで、API テストごとに最大 20 個のアサーションを作成できます。

アラート条件を定義する

アラート条件で、テストが失敗しアラートをトリガーする状況を設定します。

アラート設定規則

アラートの条件を An alert is triggered if any assertion fails for X minutes from any n of N locations に設定すると、次の 2 つの条件が当てはまる場合にのみアラートがトリガーされます。

  • 直近 X 分間に、最低 1 個のロケーションで失敗 (最低 1 つのアサーションが失敗)、
  • 直近 X 分間に、ある時点で最低 n 個のロケーションで失敗。

高速再試行

テスト結果が失敗した場合、テストによって再試行をトリガーすることができます。デフォルトでは、再試行は最初に失敗したテスト結果の 300 ミリ秒後に実行されます。この間隔は API を介して構成できます。

ロケーションのアップタイムは、評価ごとに計算されます (評価前の最後のテスト結果がアップかダウンか)。合計アップタイムは、構成されたアラート条件に基づいて計算されます。送信される通知は、合計アップタイムに基づきます。

チームへの通知

以前に定義されたアラート条件に基づいて、テストによって通知が送信されます。このセクションを使用して、チームに送信するメッセージの方法と内容を定義します。

  1. モニターと同様、メッセージに@notification を追加するか、ドロップダウンボックスでチームメンバーと接続されたインテグレーションを検索して、通知を受信するユーザーやサービスを選択します。

  2. テストの通知メッセージを入力します。このフィールドでは、標準のマークダウン形式のほか、以下の条件付き変数を使用できます。

    条件付き変数説明
    {{#is_alert}}テストがアラートを発する場合に表示します。
    {{^is_alert}}テストがアラートを発しない限り表示します。
    {{#is_recovery}}テストがアラートから回復したときに表示します。
    {{^is_recovery}}テストがアラートから回復しない限り表示します。
  3. テストが失敗した場合に、テストで通知メッセージを再送信する頻度を指定します。テストの失敗を再通知しない場合は、Never renotify if the monitor has not been resolved オプションを使用してください。

メール通知には、このセクションで定義されているメッセージと、失敗したアサーションの要約が含まれます。 通知の例:

Save をクリックしてテストを保存し、Datadog にテストの実行を開始させます。

変数

ローカル変数を作成する

テストコンフィギュレーションフォームの右上隅にある Create Local Variable をクリックすると、ローカル変数を作成できます。以下の利用可能なビルトインのいずれかから値を定義できます。

{{ numeric(n) }}
n 桁の数字列を生成します。
{{ alphabetic(n) }}
n 文字のアルファベット文字列を生成します。
{{ alphanumeric(n) }}
n 文字の英数字文字列を生成します。
{{ date(n, format) }}
テストが開始された日付 + n 日の値を使用して、許容される形式のいずれかで日付を生成します。
{{ timestamp(n, unit) }}
テストが +/- n 選択単位で開始されたタイムスタンプの値を使用して、許容される単位のいずれかでタイムスタンプを生成します。

変数を使用する

HTTP テストの URL、高度なオプション、アサーションで、Settings で定義されたグローバル変数ローカルで定義された変数を使用できます。 変数のリストを表示するには、目的のフィールドに {{ と入力します。

テストの失敗

テストが 1 つまたは複数のアサーションを満たさない場合、またはリクエストが時期尚早に失敗した場合、テストは FAILED と見なされます。場合によっては、エンドポイントに対してアサーションをテストできずにテストが実際に失敗することがあります。これらの理由には次のものがあります。

CONNRESET
接続がリモートサーバーによって突然閉じられました。Web サーバーにエラーが発生した、応答中にシステムが停止した、Web サーバーへの接続が失われた、などの原因が考えられます。
DNS
テスト URL に対応する DNS エントリが見つかりませんでした。テスト URL の構成の誤り、DNS エントリの構成の誤りなどの原因が考えられます。
INVALID_REQUEST
テストのコンフィギュレーションが無効です (URL に入力ミスがあるなど)。
SSL
SSL 接続を実行できませんでした。詳細については、個別のエラーページを参照してください
TIMEOUT
リクエストを一定時間内に完了できなかったことを示します。TIMEOUT には 2 種類あります。
  • TIMEOUT: The request couldn’t be completed in a reasonable time. は、タイムアウトが TCP ソケットの接続レベルで発生したことを示します。
  • TIMEOUT: Retrieving the response couldn’t be completed in a reasonable time. は、タイムアウトがリクエストの実行全体 (TCP ソケット接続、データ転送、アサーション) で発生したことを示します。

その他の参考資料