Synthetic テストをプライベートロケーションから実行する
セキュリティモニタリングが使用可能です セキュリティモニタリングが使用可能です

Synthetic テストをプライベートロケーションから実行する

この機能へのアクセスは制限されています。アクセス権をお持ちではない場合、Datadog サポートチームにお問い合わせください。

概要

プライベートロケーションから、内部用アプリケーションの監視や、パブリックインターネットから接続できないプライベート URL の監視を行えます。これは以下にも使用できます。

  • ビジネスでミッションクリティカルな領域に、カスタム Synthetic ロケーションを作成します
  • Synthetic CI テストインテグレーションを使用して本番環境に新機能をリリースする前に、内部 CI 環境でアプリケーションパフォーマンスを確認します
  • 内部ネットワークの内外両方からアプリケーションのパフォーマンスを比較します

プライベートロケーションは、プライベートネットワーク内のどこにでもインストールできる Docker コンテナとして提供されます。作成してインストールしたら、通常の管理対象の場所と同じように、Synthetic テストをプライベートロケーションに割り当てることができます。

プライベートロケーションワーカーは、HTTPS を使用してテストコンフィギュレーションを Datadog のサーバーからプルし、スケジュールまたはオンデマンドでテストを実行して、テスト結果を Datadog のサーバーに返します。次に、管理された場所から実行されているテストを視覚化する方法とまったく同じ方法で、プライベートロケーションのテスト結果を視覚化できます。

前提条件

Docker

プライベートロケーションワーカーは Docker コンテナとして出荷されます。公式の Docker イメージは Docker Hub からご利用いただけます。Docker エンジンをホストで利用できる場合は Linux ベース OS や Windows OS で実行できます。また、Linux コンテナモードで実行できます。

Datadog プライベートロケーションエンドポイント

テストコンフィギュレーションを取得してテスト結果を送信するには、プライベートロケーションのワーカーが以下の Datadog API エンドポイントにアクセスする必要があります。

ポートエンドポイント説明
443バージョン 0.1.6 以降の場合は intake.synthetics.datadoghq.com、バージョン 0.1.5 以前の場合は api.datadoghq.com/api/AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。
443intake-v2.synthetics.datadoghq.com for versions >0.2.0ブラウザのテストアーティファクト ()スクリーンショット、エラー、リソース をプッシュするためにプライベートロケーションで使用されます

: バージョン 0.1.6 以降の場合は curl intake.synthetics.datadoghq.com (バージョン 0.1.5 以前の場合は curl https://api.datadoghq.com) を使用して、Datadog site に対応するエンドポイントが、ワーカーを実行しているホストで利用可能かどうかを確認します。

ポートエンドポイント説明
443api.datadoghq.eu/api/AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。
443intake-v2.synthetics.datadoghq.eu for versions >0.2.0ブラウザのテストアーティファクト ()スクリーンショット、エラー、リソース をプッシュするためにプライベートロケーションで使用されます

: curl https://api.datadoghq.eu を使用して、ご利用の Datadog site に対応するエンドポイントが、ワーカーを実行するホストで利用可能かどうか確認します。

プライベートロケーションを設定する

プライベートロケーションを作成する

Synthetic Monitoring -> Settings -> Private Locations に移動し、Add Private Location をクリックします。

: プライベートロケーションを作成できるのは Admin ユーザーのみです。

プライベートロケーションの詳細を入力します。プライベートロケーションの名前説明を指定し、プライベートロケーションに関連付けたいタグを追加して、既存の API キーを 1 つ選択します。API キーを選択すると、プライベートロケーションと Datadog 間の通信が可能になります。既存の API キーがない場合は、Generate API key をクリックして専用ページで作成できます。

注: Name フィールドと API key フィールドのみが必須です。

次に、Save Location and Generate Configuration File をクリックしてプライベートロケーションを作成し、関連するコンフィギュレーションファイルを生成します (ステップ 3 に表示されます)。

プライベートロケーションを構成する

内部ネットワークの設定に応じて、プライベートロケーションコンフィギュレーションファイルに初期コンフィギュレーションパラメーター (プロキシおよび予約済み IP コンフィギュレーション) を追加できます。ステップ 2 で追加されたパラメーターは、自動的にステップ 3 のコンフィギュレーションファイルに反映されます。

プロキシコンフィギュレーション

プライベートロケーションと Datadog 間のトラフィックがプロキシを経由する必要がある場合は、http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT> の形式でプロキシ URL を指定し、生成されたコンフィギュレーションファイルに proxyDatadog パラメーターを追加します。

高度なプロキシコンフィギュレーションオプションが利用可能です。

予約済み IP のブロック

デフォルトでは、Synthetic ユーザーは任意の IP を使用してエンドポイントで Synthetic テストを作成できます。ユーザーがネットワーク内の機密性の高い内部 IP でテストを作成できないようにする場合は、Block reserved IPs ボタンを切り替えて、予約済み IP 範囲のデフォルトセット (IPv4 アドレスレジストリおよび IPv6 アドレスレジストリ) をブロックし、生成されたコンフィギュレーションファイルで関連する enableDefaultBlockedIpRanges パラメーターを true に設定します。

テストするエンドポイントの一部がブロックされた予約済み IP 範囲の 1 つまたは複数にある場合は、その IP または CIDR、あるいはその両方を許可リストに追加して、生成されたコンフィギュレーションファイルに関連する allowedIPRanges パラメーターを追加できます。

高度な予約済み IP コンフィギュレーションオプションが利用可能です。

高度なコンフィギュレーション

高度なコンフィギュレーションオプションが利用可能です。以下の help コマンドを実行することで確認できます。

docker run --rm datadog/synthetics-private-location-worker --help

コンフィギュレーションファイルを表示する

適切なオプションをプライベートロケーションコンフィギュレーションファイルに追加した後、ファイルを作業ディレクトリにコピーアンドペーストできます。

: コンフィギュレーションファイルには、プライベートロケーションの認証、テストコンフィギュレーションの復号、テスト結果の暗号といった秘密情報が含まれています。Datadog は秘密情報を保存しないため、プライベートロケーション画面を離れる前に、これらの情報をローカルに保存してください。ワーカーをさらに追加する場合、または別のホストにワーカーをインストールする場合は、これらの秘密情報を再度参照できる必要があります。

プライベートロケーションをインストールする

次でプライベートロケーションを起動します。

次のコマンドを実行して、コンフィギュレーションファイルをコンテナにマウントすることで、プライベートロケーションワーカーを起動します。

docker run --rm -v $PWD/<MY_WORKER_CONFIG_FILE_NAME>.json:/etc/datadog/synthetics-check-runner.json datadog/synthetics-private-location-worker:latest

注: 予約済み IP をブロックした場合は、必ずプライベートロケーションコンテナに NET_ADMIN Linux 機能を追加してください。

このコマンドは、Docker コンテナを起動し、プライベートロケーションでテストを実行できるようにします。適切な再起動ポリシーを使用して、コンテナをデタッチモードで実行することをお勧めします。

  1. 次で docker-compose.yml ファイルを作成します。

    version: "3"
    services:
        synthetics-private-location-worker:
            image: datadog/synthetics-private-location-worker:latest
            volumes:
                - PATH_TO_PRIVATE_LOCATION_CONFIG_FILE:/etc/datadog/synthetics-check-runner.json

注: 予約済み IP をブロックした場合は、必ずプライベートロケーションコンテナに NET_ADMIN Linux 機能を追加してください。

  1. 次でコンテナを起動します。

    docker-compose -f docker-compose.yml up
  1. 以下を実行し、以前に作成した JSON ファイルで Kubernetes ConfigMap を作成します。

    kubectl create configmap private-location-worker-config --from-file=<MY_WORKER_CONFIG_FILE_NAME>.json
  2. デプロイを利用して、プライベートロケーションに関連付けられている望ましい状態を記述します。次の private-location-worker-deployment.yamlファイルを作成します。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: datadog-private-location-worker
      namespace: default
    spec:
      selector:
        matchLabels:
          app: private-location
      template:
        metadata:
          name: datadog-private-location-worker
          labels:
            app: private-location
        spec:
          containers:
          - name: datadog-private-location-worker
            image: datadog/synthetics-private-location-worker
            volumeMounts:
            - mountPath: /etc/datadog/synthetics-check-runner.json
              name: worker-config
              subPath: <MY_WORKER_CONFIG_FILE_NAME>
          volumes:
          - name: worker-config
            configMap:
              name: private-location-worker-config

注: 予約済み IP をブロックした場合は、必ずプライベートロケーションコンテナに NET_ADMIN Linux 機能を追加してください。

  1. コンフィギュレーションを適用します。

    kubectl apply -f private-location-worker-deployment.yaml

以下に一致する新しい EC2 タスク定義を作成します。各パラメーターは、以前に生成したプライベートロケーションコンフィギュレーションファイルにある対応する値に置き換えてください。

{
    ...
    "containerDefinitions": [
        {
            "command": [
                "--site='...'",
                "--locationID='...'",
                "--accessKey='...'",
                "--datadogApiKey='...'",
                "--secretAccessKey='...'",
                "--privateKey='-----BEGIN RSA PRIVATE KEY-----XXXXXXXX-----END RSA PRIVATE KEY-----'",
                "--publicKey.pem='-----BEGIN PUBLIC KEY-----XXXXXXXX-----END PUBLIC KEY-----'",
                "--publicKey.fingerprint='...'"
            ],
            ...
            "image": "datadog/synthetics-private-location-worker:latest",
            ...
        }
    ],
    ...
    "compatibilities": [
        "EC2"
    ],
    ...
}

注: 予約済み IP をブロックした場合は、必ず linuxParametersを構成して、プライベートロケーションコンテナに NET_ADMIN 機能を付与してください。

以下に一致する新しい Fargate タスク定義を作成します。各パラメーターは、以前に生成したプライベートロケーションコンフィギュレーションファイルにある対応する値に置き換えてください。

{
    ...
    "containerDefinitions": [
        {
            "command": [
                "--site='...'",
                "--locationID='...'",
                "--accessKey='...'",
                "--datadogApiKey='...'",
                "--secretAccessKey='...'",
                "--privateKey='-----BEGIN RSA PRIVATE KEY-----XXXXXXXX-----END RSA PRIVATE KEY-----'",
                "--publicKey.pem='-----BEGIN PUBLIC KEY-----XXXXXXXX-----END PUBLIC KEY-----'",
                "--publicKey.fingerprint='...'"
            ],
            ...
            "image": "datadog/synthetics-private-location-worker:latest",
            ...
        }
    ],
    ...
    "compatibilities": [
        "EC2",
        "FARGATE"
    ],
    ...
}

注: プライベートロケーションファイアウォールオプションは AWS Fargate ではサポートされていません。したがって、enableDefaultBlockedIpRanges パラメーターは true に設定できません。

Datadog は既に Kubernetes および AWS と統合されているため、すぐに EKS を監視することができます。

  1. 以下を実行し、以前に作成した JSON ファイルで Kubernetes ConfigMap を作成します。

    kubectl create configmap private-location-worker-config --from-file=<MY_WORKER_CONFIG_FILE_NAME>.json
  2. デプロイを利用して、プライベートロケーションに関連付けられている望ましい状態を記述します。次を作成します。

    private-location-worker-deployment.yaml file:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: datadog-private-location-worker
    namespace: default
    spec:
    selector:
      matchLabels:
        app: private-location
    template:
      metadata:
        name: datadog-private-location-worker
        labels:
          app: private-location
      spec:
        containers:
          - name: datadog-private-location-worker
            image: datadog/synthetics-private-location-worker
            volumeMounts:
              - mountPath: /etc/datadog/
                name: worker-config
        volumes:
          - name: worker-config
            configMap:
              name: private-location-worker-config

注: 予約済み IP をブロックした場合は、必ずセキュリティコンテキストを構成して、プライベートロケーションコンテナに NET_ADMIN Linux 機能を追加してください。

  1. コンフィギュレーションを適用します。

    kubectl apply -f private-location-worker-deployment.yaml

ヘルスチェックの設定

ヘルスチェックメカニズムを追加すると、オーケストレーターはワーカーが正しく実行していることを確認できます。

プライベートロケーションコンテナの /tmp/liveness.date ファイルは、Datadog から正常にポーリングされるごとに更新されます (デフォルトでは 500ミリ秒)。例えば過去1分間にフェッチされないなど一定期間ポーリングが行われないと、コンテナは異常だとみなされます。

以下のコンフィギュレーションを使い、コンテナにヘルスチェックを設定します。

healthcheck:
  retries: 3
  test: [
    "CMD", "/bin/sh", "-c", "'[ $$(expr $$(cat /tmp/liveness.date) + 300000) -gt $$(date +%s%3N) ]'"
  ]
  timeout: 2s
  interval: 10s
  start_period: 30s
livenessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - '[ $(expr $(cat /tmp/liveness.date) + 300000) -gt $(date +%s%3N) ]'
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
"healthCheck": {
  "retries": 3,
  "command": [
    "/bin/sh", "-c", "'[ $(expr $(cat /tmp/liveness.date) + 300000) -gt $(date +%s%3N) ]'"
  ],
  "timeout": 2,
  "interval": 10,
  "startPeriod": 30
}
"healthCheck": {
  "retries": 3,
  "command": [
    "/bin/sh", "-c", "'[ $(expr $(cat /tmp/liveness.date) + 300000) -gt $(date +%s%3N) ]'"
  ],
  "timeout": 2,
  "interval": 10,
  "startPeriod": 30
}
livenessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - '[ $(expr $(cat /tmp/liveness.date) + 300000) -gt $(date +%s%3N) ]'
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

内部エンドポイントをテストする

1 つ以上のプライベートロケーションコンテナが Datadog にレポートを開始すると、プライベートロケーションステータスが緑に設定されます。

次に、内部エンドポイントの 1 つで速度テストを起動して最初の内部エンドポイントのテストを開始し、期待される応答が得られるかどうかを確認できます。

Synthetic テストをプライベートロケーションから起動する

プライベートロケーションから Datadog への報告が正確なら、Settings ページのプライベートロケーションのリストに OK のヘルスステータスが表示されます。

次に、任意の API またはブラウザテスト作成フォームに移動し、対象の Private locations にチェックマークを付けて、スケジュールに従って Synthetic テストを実行することができます。

プライベートロケーションは、他の Datadog 管理ロケーションと同じように使用できます。具体的には、プライベートロケーションに Synthetic テストを割り当て、テスト結果を視覚化し、Synthetic メトリクスを取得するなどが可能です。

プライベートロケーションのサイズ変更

プライベートロケーションにワーカーを追加または削除することで、簡単に水平スケーリングすることができます。単一のコンフィギュレーションファイルで、1 つのプライベートロケーションに対して複数のコンテナを実行できます。これにより、ワーカー 1 がテストを処理している時にワーカー 2 が次のテストのリクエストを送信するなど、各ワーカーが空きスロットの数に応じて N 件のテストの実行リクエストを送信します。

また、concurrency パラメーターの値を利用して、プライベートロケーションワーカーが並行して実行できるテストの数を調整することもできます。

ハードウェア要件

CPU/メモリ

  • 基本要件: 150mCores/150MiB

  • スロットごとの追加要件:

プライベートロケーションテストタイプ推奨される同時実行範囲CPU/メモリの推奨
API テストとブラウザテストの両方を実行するプライベートロケーション1〜50スロットあたり 150mCores/1GiB
API テストのみを実行するプライベートロケーション1〜200スロットあたり 20mCores/5MiB
ブラウザテストのみを実行するプライベートロケーション1〜50スロットあたり 150mCores/1GiB

例: API テストとブラウザテストの両方を実行し、concurrency をデフォルトの 10 に設定したプライベートロケーションの場合、安全な使用のための推奨値は〜1.5 コア (150mCores + (150mCores*10 スロット)) と〜10GiB メモリ (150M + (1G*10 スロット)) です。

ディスク

ディスクサイズに対して推奨されるのは、〜10MiB/スロット (API のみのプライベートロケーションの場合は 1MiB/スロット) を割り当てることです。

その他の参考資料