- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
HTTP テストでは、アプリケーションの API エンドポイントに HTTP リクエストを送信し、応答時間、ステータスコード、ヘッダー、本文のコンテンツなど、定義された条件と応答を確認することができます。
HTTP テストは、ネットワークの外部または内部からのテストの実行の好みに応じて、管理ロケーションとプライベートロケーションの両方から実行することができます。HTTP テストは、スケジュール、オンデマンド、または CI/CD パイプライン内で直接実行することができます。
HTTP
テストの作成を選択した後、テストのリクエストを定義します。
HTTP Method を選択し、クエリする URL を指定します。使用可能なメソッドは、GET
、POST
、PATCH
、PUT
、HEAD
、DELETE
、OPTIONS
です。http
と https
の両方の URL がサポートされています。
Advanced Options を使用して HTTP リクエストを加工します (オプション)。
user-agent
ヘッダー) をオーバーライドすることもできます。<COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2>
の形式を使用して複数のクッキーを設定します。クライアント証明書: クライアント証明書 (.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
HTTP Basic Auth: HTTP 基本認証資格情報を追加します。
Digest Auth: ダイジェスト認証の資格情報を追加します。
NTLM: NTLM 認証の資格情報を追加します。NTLMv2 と NTLMv1 の両方をサポートします。
AWS Signature v4: Access Key ID と Secret Access Key を入力します。Datadog は、リクエストの署名を生成します。このオプションは、SigV4 の基本的な実装を使用します。AWS S3 などの特定の署名はそのままではサポートされていません。
AWS S3 バケットへの “Single Chunk” 転送リクエストでは、リクエストの本文を sha256 エンコードした x-amz-content-sha256
をヘッダーとして追加します (本文が空の場合: x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
)。
OAuth 2.0: クライアント資格情報またはリソース所有者のパスワードのどちらかを付与するかを選択し、アクセストークンの URL を入力します。選択内容に応じて、クライアント ID とシークレット、またはユーザー名とパスワードを入力します。ドロップダウンメニューから、API トークンを基本認証ヘッダーとして送信するか、クライアント資格情報を本文に送信するかを選択します。オプションで、オーディエンス、リソース、スコープなどの追加情報を提供できます (Resource Owner Password を選択した場合は、クライアント ID とシークレットも提供します)。
text/plain
、application/json
、text/xml
、text/html
、application/x-www-form-urlencoded
、GraphQL
、または None
) を選択します。http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>
) を指定します。HTTP テストに名前を付けます。
HTTP テストに env
タグとその他のタグを追加します。次に、これらのタグを使用して、Synthetic Monitoring ホームページで Synthetic テストをすばやくフィルタリングできます。
Test URL をクリックして、リクエストのコンフィギュレーションをテストします。画面の右側に応答プレビューが表示されます。
アサーションは、期待されるテスト結果が何であるかを定義します。Test URL をクリックすると、response time
、status code
、header
、content-type
の基本的なアサーションが、取得された応答に基づいて追加されます。テストで監視するには、少なくとも 1 つのアサーションを定義する必要があります。
タイプ | 演算子 | 値の型 |
---|---|---|
本文 | contains 、does not contain 、is 、is not 、matches 、does not match 、jsonpath 、xpath | 文字列 正規表現 |
ヘッダー | contains 、does not contain 、is 、is not 、matches 、does not match | 文字列 正規表現 |
response time | is less than | 整数 (ms) |
ステータスコード | is 、is not 、matches 、does not match | 整数 正規表現 |
HTTP テストでは、br
、deflate
、gzip
、identity
の content-encoding
ヘッダーを使用して本文を解凍することが可能です。
New Assertion をクリックするか、応答プレビューを直接クリックすることで、API テストごとに最大 20 個のアサーションを作成できます。
アサーションで OR
ロジックを実行するには、matches regex
コンパレータを使って (200|302)
のように複数の期待値を持つ正規表現を定義します。たとえば、サーバーが 200
あるいは 302
というステータスコードで応答したときに HTTP テストを成功させたいことがあるでしょう。ステータスコードが 200 あるいは 302 であれば、 status code
アサーションは成功します。body
や header
アサーションに OR
ロジックを追加することもできます。
テストがレスポンス本文にアサーションを含まない場合、本文のペイロードはドロップし、Synthetics Worker で設定されたタイムアウト制限内でリクエストに関連するレスポンスタイムを返します。
テストがレスポンス本文に対するアサーションを含み、タイムアウトの制限に達した場合、Assertions on the body/response cannot be run beyond this limit
というエラーが表示されます。
HTTP テストを実行するロケーションを選択します。HTTP テストは、ネットワークの外部または内部のどちらからテストを実行するかの好みによって、管理ロケーションとプライベートロケーションの両方から実行できます。
Datadog’s out-of-the-box managed locations allow you to test public-facing websites and endpoints from regions where your customers are located.
Americas | APAC | EMEA |
---|---|---|
Canada Central (AWS) | Hong Kong (AWS) | Cape Town (AWS) |
Northern California (AWS) | Mumbai (AWS) | Frankfurt (AWS) |
Northern Virginia (AWS) | Seoul (AWS) | Ireland (AWS) |
Ohio (AWS) | Singapore (AWS) | London (AWS) |
Oregon (AWS) | Sydney (AWS) | Paris (AWS) |
São Paulo (AWS) | Tokyo (AWS) | Stockholm (AWS) |
Virginia (Azure) | Osaka (AWS) | Milan (AWS) |
Jakarta (AWS) | Bahrain (AWS) |
The Datadog for Government site (US1-FED) uses the following managed location:
Americas |
---|
US-West |
HTTP テストは次の頻度で実行できます。
アラート条件で、テストが失敗しアラートをトリガーする状況を設定します。
アラートの条件を An alert is triggered if your test fails for X minutes from any n of N locations
に設定すると、次の 2 つの条件が当てはまる場合にのみアラートがトリガーされます。
テストが失敗した場合、Y
ミリ秒後に X
回再試行することができます。再試行の間隔は、警告の感性に合うようにカスタマイズしてください。
ロケーションのアップタイムは、評価ごとに計算されます (評価前の最後のテスト結果がアップかダウンか)。合計アップタイムは、構成されたアラート条件に基づいて計算されます。送信される通知は、合計アップタイムに基づきます。
以前に定義されたアラート条件に基づいて、テストによって通知が送信されます。このセクションを使用して、チームに送信するメッセージの方法と内容を定義します。
モニターの構成方法と同様、メッセージに @notification
を追加するか、ドロップダウンボックスでチームメンバーと接続されたインテグレーションを検索して、通知を受信するユーザーやサービスを選択します。
テストの通知メッセージを入力します。このフィールドでは、標準のマークダウン形式のほか、以下の条件付き変数を使用できます。
条件付き変数 | 説明 |
---|---|
{{#is_alert}} | テストがアラートを発する場合に表示します。 |
{{^is_alert}} | テストがアラートを発しない限り表示します。 |
{{#is_recovery}} | テストがアラートから回復したときに表示します。 |
{{^is_recovery}} | テストがアラートから回復しない限り表示します。 |
{{#is_renotify}} | モニターが再通知したときに表示します。 |
{{^is_renotify}} | モニターが再通知しない限り表示します。 |
{{#is_priority}} | モニターが優先順位 (P1~P5) に一致したときに表示します。 |
{{^is_priority}} | モニターが優先順位 (P1~P5) に一致しない限り表示します。 |
テストが失敗した場合に、テストで通知メッセージを再送信する頻度を指定します。テストの失敗を再通知しない場合は、Never renotify if the monitor has not been resolved
オプションを使用してください。
Create をクリックすると、テストの構成とモニターが保存されます。
詳しくは、Synthetic テストモニターの使用をご覧ください。
To create a local variable, click Create a Local Variable. You can select one of the following available builtins to add to your variable string:
n
digits.n
letters.n
characters.n
units.n
units.To obfuscate local variable values in test results, select Hide and obfuscate variable value. Once you have defined the variable string, click Add Variable.
HTTP テストの URL、高度なオプション、アサーションで、Settings ページで定義されたグローバル変数を使用することができます。
変数のリストを表示するには、目的のフィールドに {{
と入力します。
テストが 1 つ以上のアサーションを満たさない場合、またはリクエストが時期尚早に失敗した場合、テストは FAILED
と見なされます。場合によっては、エンドポイントに対してアサーションをテストすることなくテストが実際に失敗することがあります。
よくあるエラーは以下の通りです。
CONNREFUSED
CONNRESET
DNS
INVALID_REQUEST
SSL
TIMEOUT
TIMEOUT
には 2 種類あります。TIMEOUT: The request couldn't be completed in a reasonable time.
は、リクエストの持続時間がテスト定義のタイムアウト (デフォルトは 60 秒に設定されています) に当たったことを示します。
各リクエストについて、ネットワークウォーターフォールに表示されるのは、リクエストの完了したステージのみです。例えば、Total response time
だけが表示されている場合、DNS の解決中にタイムアウトが発生したことになります。TIMEOUT: Overall test execution couldn't be completed in a reasonable time.
は、テスト時間 (リクエスト+アサーション) が最大時間 (60.5s) に達したことを示しています。MALFORMED_RESPONSE
デフォルトでは、Datadog 管理者および Datadog 標準ロールを持つユーザーのみが、Synthetic HTTP テストを作成、編集、削除できます。Synthetic HTTP テストの作成、編集、削除アクセスを取得するには、ユーザーをこれら 2 つのデフォルトのロールのいずれかにアップグレードします。
カスタムロール機能を使用している場合は、synthetics_read
および synthetics_write
権限を含むカスタムロールにユーザーを追加します。
アカウントにカスタムロールを使用しているお客様は、アクセス制限が利用可能です。
組織内の役割に基づいて、HTTP テストへのアクセスを制限することができます。HTTP テストを作成する際に、(ユーザーのほかに) どのロールがテストの読み取りと書き込みを行えるかを選択します。