メインコンテンツまでスキップ

Postman模擬サーバーの作成

このガイドでは、提供されているPostmanサンプルファイルを使用して、Datadog Log Ingestionアプリケーションプログラミングインターフェース（API）をローカルでシミュレートする方法を説明します。ライブのDatadogアカウントにデータを送信することなく、リクエスト形式の検証、エラーレスポンスのテスト、およびハンズオンガイドの例の実行が可能です。

前提条件​

  • Postman（デスクトップ版またはWeb版）。

  • このプロジェクトに含まれる3つのJSONファイル：

    ファイル目的
    DataPipeline-Environment.json再利用可能な変数（dd_site、mock_base_url、dd_api_key）を定義します。
    DataPipeline-postman-collection.jsonDatadog Log Ingestion API（/api/v2/logs）に実際のリクエストを送信します。
    DataPipeline-MockServer-Collection.jsonPostman模擬サーバーを使用して、同じエンドポイントの模擬レスポンスを設定します。

3つのファイルをすべてダウンロードしてください： Postmanファイルをダウンロード

1. ファイルをPostmanにインポートする​

  1. Postmanを開き、Import をクリックします。
  2. ダウンロードした3つのJSONファイルをすべて選択します。
  3. 右上の環境メニューから、Data Pipeline Environment を選択します。

ファイルをインポートすると、以下の項目が表示されます。

  • Data Pipeline Documentation Project（実際のAPIコレクション）。
  • Data Pipeline — Mock Server Collection（模擬サーバーコレクション）。
  • Data Pipeline Environment（環境設定）。

2. 模擬サーバーを作成する​

  1. Postmanの左サイドバーにある Mock Servers に移動します。
  2. Create Mock Server をクリックします。
  3. Data Pipeline—Mock Server Collection を選択します。
  4. デフォルト設定のまま、Create Mock Server をクリックします。

Postmanにより、一意の模擬サーバーアドレスが生成されます。例： https://a12b34cd-1234-5678.mock.pstmn.io

3. 環境変数を更新する​

  1. Environments > Data Pipeline Environment に移動します。
  2. mock_base_url 変数を見つけます。
  3. プレースホルダーを生成された模擬サーバーアドレスに置き換えます。
# 置換前
https://mock-server-url-from-postman.io

# 置換後
https://a12b34cd-1234-5678.mock.pstmn.io
  1. 環境設定を保存します。

4. 最初の模擬リクエストを送信する​

  1. Mock Server Collection 内の POST /api/v2/logs を開きます。
  2. 右上のメニューで Data Pipeline Environment がアクティブであることを確認します。
  3. Send をクリックします。

模擬サーバーは、実際のDatadogのレスポンスを模した 202 Accepted レスポンスを返します。 HTTP/1.1 202 Accepted

注意: 実際のDatadog Log Ingestion APIは、レスポンスボディのない 202 Accepted を返します。この模擬コレクションでは、テスト時の視認性を高めるために、最小限のJSONオブジェクトを返します。

{
  "status": "accepted",
  "message": "Log event received by mock server."
}

5. エラーレスポンスをテストする​

400 bad request レスポンスをテストするには、リクエストボディから message フィールドを削除します。このフィールドは、Datadog Log Ingestion APIにおいて必須です。

模擬サーバーは以下のJSONを返します。

{
  "errors": ["Invalid JSON"]
}

また、リクエストから DD-API-KEY ヘッダーを削除することで、401 unauthorized レスポンスをテストすることもできます。

6. ライブテストと模擬テストを切り替える​

どちらのコレクションも同じ環境ファイルを使用します。実際のテストと模擬テストを切り替えるには、使用するコレクションを変更します。

目的コレクションベースアドレス変数
実際のDatadogでテストするDataPipeline-postman-collection.json{{dd_site}} → datadoghq.com
ローカルまたはオフラインでテストするDataPipeline-MockServer-Collection.json{{mock_base_url}} → 生成された模擬アドレス

このアプローチにより、ライブデータをDatadogアカウントに送信する前に、リクエストとレスポンスの形式を検証できます。

リクエストフローの可視化​

Postman模擬サーバーのリクエストフロー

なぜ重要なのか​

この模擬サーバーのセットアップは、実際のAPI統合の開発やドキュメント作成時に使用するのと同じ検証パターンを示しています。

  • 実際のトラフィックを送信する前に、リクエスト構造と必須ヘッダー（DD-API-KEY、Content-Type）を確認する。
  • JSONペイロードが期待されるスキーマ（各オブジェクトに message フィールドが含まれるログオブジェクトの配列）と一致することを確認する。
  • APIのクォータを消費したり、本番のログインデックスを汚染したりすることなく、エラー処理（400、401、429）をテストする。
  • 安定して再現可能なエンドポイントに対して、ドキュメントの例を開発および検証する。

同じパターンは、**Galileoソフトウェア開発キット（SDK）**のドキュメント作成にも適用されます。インスツルメントされた関数を dev ログストリームでテストしてから production に昇格させることで、実際のユーザートラフィックが流れる前に評価メトリクスが正しく設定されていることを確認できます。