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

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

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

概要

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

  • ビジネスでミッションクリティカルな領域に、カスタム Synthetic ロケーションを作成します
  • Synthetic CI/CD テストを使用して本番環境に新機能をリリースする前に、内部 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 AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。
443 intake-v2.synthetics.datadoghq.com for versions >0.2.0 ブラウザのテストアーティファクト ()スクリーンショット、エラー、リソース をプッシュするためにプライベートロケーションで使用されます

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

: これらのドメインは、静的 IP アドレスのセットを指しています。これらのアドレスは、https://ip-ranges.datadoghq.eu、具体的には https://ip-ranges.datadoghq.eu/api.json (api.datadoghq.eu の場合) および https://ip-ranges.datadoghq.eu/synthetics-private-locations.json (intake-v2.synthetics.datadoghq.eu の場合) にあります。

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

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

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

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

プライベートロケーションの詳細を入力します。

  1. プライベートロケーションの名前および説明を指定します。
  2. プライベートロケーションに関連付けるタグを追加します。
  3. 既存の 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 は秘密情報を保存しないため、プライベートロケーション画面を離れる前に、これらの情報をローカルに保存してください。ワーカーをさらに追加する場合、または別のホストにワーカーをインストールする場合は、これらの秘密情報を再度参照できる必要があります。

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

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

次のコマンドを実行して、コンフィギュレーションファイルをコンテナにマウントすることでプライベートロケーションワーカーを起動します。<MY_WORKER_CONFIG_FILE_NAME>.json ファイルはルートホームフォルダーではなく /etc/docker 内に格納してください。

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 機能を追加してください。

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

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 機能を追加してください。

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

    kubectl apply -f private-location-worker-deployment.yaml
    
  1. Datadog Synthetics Private Location を Helm リポジトリに追加します。

    helm repo add datadog https://helm.datadoghq.com 
    helm repo update
    
  2. 以下を実行して事前に作成された JSON ファイルを使用して、リリース名 <RELEASE_NAME> でチャートをインストールします。

    helm install <RELEASE_NAME> datadog/synthetics-private-location --set-file configFile=<MY_WORKER_CONFIG_FILE_NAME>.json
    

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

以下に一致する新しい 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"
    ],
    ...
}

注:

タスク定義に環境変数を使用する場合、Fargate プライベートロケーションのデプロイには Datadog. の他の部分と異なる環境変数が使用されることにご留意ください。Fargate では、以下の環境変数を使用します。DATADOG_API_KEY, DATADOG_ACCESS_KEY, DATADOG_SECRET_ACCESS_KEY, DATADOG_PRIVATE_KEY.

プライベートロケーションファイアウォールオプションは 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 ファイルを作成します。

    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 機能を追加してください。

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

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

ヘルスチェックの設定

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

プライベートロケーションコンテナの /tmp/liveness.date ファイルは、Datadog から正常にポーリングされるごとに更新されます (デフォルトでは 2 秒)。例えば過去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
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": [
    "CMD-SHELL", "/bin/sh -c '[ $(expr $(cat /tmp/liveness.date) + 300000) -gt $(date +%s%3N) ]'"
  ],
  "timeout": 2,
  "interval": 10,
  "startPeriod": 30
}
"healthCheck": {
  "retries": 3,
  "command": [
    "CMD-SHELL", "/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 パラメーターを使用してプライベートロケーションを垂直にスケーリングして、プライベートロケーションで使用可能なスロットの数を調整することもできます。これらのスロットは、プライベートロケーションワーカーが並行して実行できるテストの数です。プライベートロケーションの 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/スロット) を割り当てることです。

その他の参考資料