- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
プライベートロケーションから、内部用アプリケーションの監視や、パブリックインターネットから接続できないプライベートエンドポイントの監視を行えます。これは以下にも使用できます。
プライベートロケーションは、プライベートネットワーク内のどこにでもインストールできる Docker コンテナとして提供されます。作成してインストールしたら、管理ロケーションと同じように、Synthetic テストをプライベートロケーションに割り当てることができます。
プライベートロケーションワーカーは、HTTPS を使用してテストコンフィギュレーションを Datadog のサーバーからプルし、スケジュールまたはオンデマンドでテストを実行して、テスト結果を Datadog のサーバーに返します。次に、管理ロケーションから実行されているテストを視覚化する方法とまったく同じ方法で、プライベートロケーションのテスト結果を視覚化できます。
Continuous Testing テストでプライベートロケーションを使用するには、v1.27.0 以降が必要です。
プライベートロケーションは、プライベートネットワーク内のどこにでも設置できる Docker コンテナです。プライベートロケーションのワーカーイメージ]3には、Google Container Registry からアクセスできます。ホスト上に Dockerエンジンがあり、Linux コンテナモードで動作可能であれば、Linux ベースの OS や Windows OS 上で動作させることができます。
テストコンフィギュレーションを取得してテスト結果を送信するには、プライベートロケーションのワーカーが以下の Datadog API エンドポイントにアクセスする必要があります。
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.datadoghq.com | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。 |
443 | バージョン 0.2.0 以降、1.4.0 以下は intake-v2.synthetics.datadoghq.com | ブラウザのテストアーティファクト (スクリーンショット、エラー、リソースなど) をプッシュするためにプライベートロケーションで使用されます。 |
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.datadoghq.eu | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。 |
注: これらのドメインは、静的 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
の場合) にあります。
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.us3.datadoghq.com | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。 |
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.ap1.datadoghq.com | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。 |
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.us5.datadoghq.com | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。 |
ポート | エンドポイント | 説明 |
---|---|---|
443 | intake.synthetics.ddog-gov.com | AWS Signature Version 4 プロトコルに基づく社内プロトコルを使用して、テストコンフィギュレーションをプルし、テスト結果を Datadog にプッシュするためにプライベートロケーションで使用されます。バージョン 1.32.0 以降では、これらのリクエストは連邦情報処理規格 (FIPS) に準拠しています。 |
プライベートロケーションは、Admin ロールを持つユーザーのみが作成できます。詳しくは、権限を参照してください。
Synthetic Monitoring > Settings > Private Locations に移動し、Add Private Location をクリックします。
プライベートロケーションの詳細を入力します。
Name
と API key
フィールドのみが必須です。生成されたコンフィギュレーションファイルをカスタマイズして、プライベートロケーションを構成します。ステップ 3 でプロキシや予約 IP のブロックなどの初期構成パラメーターを追加すると、ステップ 4 で生成したコンフィギュレーションファイルは自動的に更新されます。
詳細オプションにアクセスして、内部ネットワークの設定に基づいた構成を調整することができます。help
コマンドの詳細については、構成を参照してください。
プライベートロケーションと Datadog 間のトラフィックがプロキシを経由する必要がある場合は、http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>
の形式でプロキシ URL を指定し、生成されたコンフィギュレーションファイルに proxyDatadog
パラメーターを追加します。
デフォルトでは、Synthetic ユーザーは任意の IP を使用してエンドポイントで Synthetic テストを作成できます。ユーザーがネットワーク内の機密性の高い内部 IP でテストを作成できないようにする場合は、Block reserved IPs ボタンを切り替えて、予約済み IP 範囲のデフォルトセット (IPv4 アドレスレジストリおよび IPv6 アドレスレジストリ) をブロックし、生成されたコンフィギュレーションファイルで関連する enableDefaultBlockedIpRanges
パラメーターを true
に設定します。
テストするエンドポイントの一部がブロックされた予約済み IP 範囲の 1 つまたは複数にある場合は、その IP または CIDR、あるいはその両方を許可リストに追加して、生成されたコンフィギュレーションファイルに関連する allowedIPRanges
パラメーターを追加できます。
プライベートロケーションのコンフィギュレーションファイルに適切なオプションを追加した後、このファイルを作業ディレクトリにコピーアンドペーストしてください。このコンフィギュレーションファイルには、プライベートロケーションの認証、テスト構成の復号化、およびテスト結果の暗号化のためのシークレットが含まれています。
Datadog はシークレットを保存しないので、View Installation Instructions をクリックする前に、ローカルに保存してください。
注: ワーカーをさらに追加する場合、または、他のホストにワーカーをインストールする場合は、これらの秘密情報を再度参照できる必要があります。
タスクの定義では、環境変数 DATADOG_API_KEY
、DATADOG_ACCESS_KEY
、DATADOG_SECRET_ACCESS_KEY
、DATADOG_PUBLIC_KEY_PEM
、DATADOG_PRIVATE_KEY
を使用することが可能です。
次でプライベートロケーションを起動します。
次のコマンドを実行して、コンフィギュレーションファイルをコンテナにマウントすることでプライベートロケーションワーカーを起動します。<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 コンテナを起動し、プライベートロケーションでテストを実行できるようにします。Datadog は、適切な再起動ポリシーを使用して、コンテナをデタッチモードで実行することをお勧めします。
カスタムルート証明書をプライベートロケーションにアップロードして、API やブラウザテストで独自の .pem
ファイルを使用して SSL ハンドシェイクを実行させることができます。
プライベートロケーションのコンテナをスピンアップする際には、プライベートロケーションの構成ファイルをマウントするのと同じように、関連する証明書 .pem
ファイルを /etc/datadog/certs
にマウントします。これらの証明書は信頼できる CA とみなされ、テストの実行時に使用されます。
管理者用のプライベートロケーションのパラメーターについては、構成を参照してください。
次で 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 機能を追加してください。
次でコンテナを起動します。
docker-compose -f docker-compose.yml up
カスタムルート証明書をプライベートロケーションにアップロードして、API やブラウザテストで独自の .pem
ファイルを使用して SSL ハンドシェイクを実行させることができます。
プライベートロケーションのコンテナをスピンアップする際には、プライベートロケーションの構成ファイルをマウントするのと同じように、関連する証明書 .pem
ファイルを /etc/datadog/certs
にマウントします。これらの証明書は信頼できる CA とみなされ、テストの実行時に使用されます。
管理者用のプライベートロケーションのパラメーターについては、構成を参照してください。
Podman の構成は Docker と非常に似ていますが、ICMP テストに対応するため、追加機能として NET_RAW
を設定する必要があります。
コンテナが動作するホストから、sysctl -w "net.ipv4.ping_group_range = 0 2147483647"
を実行します。
このコマンドを実行すると、コンフィギュレーションファイルをコンテナにマウントしてプライベートロケーションのワーカーが起動します。コンテナにマウントするために、<MY_WORKER_CONFIG_FILE_NAME>.json
ファイルがアクセス可能であることを確認します。
podman run --cap-add=NET_RAW --rm -it -v $PWD/<MY_WORKER_CONFIG_FILE_NAME>.json:/etc/datadog/synthetics-check-runner.json gcr.io/datadoghq/synthetics-private-location-worker:latest
ブロックされた予約 IP アドレスを構成している場合、プライベートロケーションのコンテナに NET_ADMIN
Linux 機能を追加します。
このコマンドは、Podman コンテナを起動し、プライベートロケーションでテストを実行できるようにします。Datadog は、適切な再起動ポリシーを使用して、コンテナをデタッチモードで実行することをお勧めします。
プライベートロケーションワーカーを安全にデプロイするために、コンテナ内の /etc/datadog/synthetics-check-runner.json
以下に Kubernetes Secret リソースを設定しマウントしてください。
以下を実行し、以前に作成した JSON ファイルで Kubernetes Secret を作成します。
kubectl create secret generic private-location-worker-config --from-file=<MY_WORKER_CONFIG_FILE_NAME>.json
デプロイを使用して、プライベートロケーションに関連付けられている望ましい状態を記述します。次の 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
secret:
secretName: private-location-worker-config
注: 予約済み IP をブロックした場合は、プライベートロケーションコンテナに NET_ADMIN
Linux 機能を追加してください。
コンフィギュレーションを適用します。
kubectl apply -f private-location-worker-deployment.yaml
OpenShift の場合、プライベートロケーションを anyuid
SCC で実行します。これは、ブラウザテストを実行するために必要です。
構成パラメーターに、すでに構成されているシークレットを指す環境変数を設定することができます。シークレットを指定した環境変数を作成するには、Kubernetes のドキュメントを参照してください。
あるいは
Datadog Synthetics Private Location を Helm リポジトリに追加します。
helm repo add datadog https://helm.datadoghq.com
helm repo update
先に作成した 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"
],
...
}
注:
NET_ADMIN
機能を付与してください。DATADOG_API_KEY
、DATADOG_ACCESS_KEY
、DATADOG_SECRET_ACCESS_KEY
、DATADOG_PUBLIC_KEY_PEM
、DATADOG_PRIVATE_KEY
の環境変数を使用する場合、それらを "command": [ ]
セクションに入れる必要はありません。以下に一致する 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 を監視することができます。
以下を実行し、以前に作成した JSON ファイルで Kubernetes Secret を作成します。
kubectl create secret generic private-location-worker-config --from-file=<MY_WORKER_CONFIG_FILE_NAME>.json
デプロイを使用して、プライベートロケーションに関連付けられている望ましい状態を記述します。次の 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 機能を追加してください。
コンフィギュレーションを適用します。
kubectl apply -f private-location-worker-deployment.yaml
オーケストレーターがワーカーが正しく動作していることを確認できるように、ライブネスプローブまたはレディネスプローブを追加します。
レディネスプローブの場合、プライベートロケーションデプロイメントでポート 8080
のプライベートロケーションステータスプローブを有効にする必要があります。詳細については、プライベートロケーションの構成を参照してください。
healthcheck:
retries: 3
test: [
"CMD", "wget", "-O", "/dev/null", "-q", "http://localhost:8080/liveness"
]
timeout: 2s
interval: 10s
start_period: 30s
livenessProbe:
httpGet:
path: /liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
readinessProbe:
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
httpGet:
path: /readiness
port: 8080
livenessProbe:
httpGet:
path: /liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
readinessProbe:
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
httpGet:
path: /readiness
port: 8080
"healthCheck": {
"retries": 3,
"command": [
"CMD-SHELL", "/usr/bin/wget", "-O", "/dev/null", "-q", "http://localhost:8080/liveness"
],
"timeout": 2,
"interval": 10,
"startPeriod": 30
}
"healthCheck": {
"retries": 3,
"command": [
"CMD-SHELL", "wget -O /dev/null -q http://localhost:8080/liveness || exit 1"
],
"timeout": 2,
"interval": 10,
"startPeriod": 30
}
livenessProbe:
httpGet:
path: /liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
readinessProbe:
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
httpGet:
path: /readiness
port: 8080
プライベートロケーションコンテナの /tmp/liveness.date
ファイルは、Datadog から正常にポーリングされるごとに更新されます (デフォルトでは 2 秒)。例えば過去1分間にフェッチされないなど一定期間ポーリングが行われないと、コンテナは異常だとみなされます。
以下のコンフィギュレーションを使い、livenessProbe
でコンテナにヘルスチェックを設定します。
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 にレポートを開始すると、プライベートロケーションステータスが緑に表示されます。
また、Settings ページの Private Locations リストに表示される REPORTING
ヘルスステータスを見ることができます。
内部エンドポイントの 1 つで速度テストを起動して最初の内部エンドポイントのテストを開始し、期待される応答が得られるかどうかを確認します。
注: Datadog はプライベートロケーションからアウトバウンドトラフィックのみを送信し、インバウンドトラフィックは送信されません。
API、マルチステップ API、またはブラウザテストを作成し、関心のあるプライベートロケーションを選択します。
プライベートロケーションは、Datadog が管理するロケーションと同様に使用できます。プライベートロケーションに Synthetic テストを割り当て、テスト結果を視覚化し、Synthetic メトリクスを取得するなど、様々なことが可能です。
1 つのプライベートロケーションに単一のコンフィギュレーションファイルで複数のコンテナを実行できるため、ワーカーを追加または削除することでプライベートロケーションを水平スケーリングできます。このとき、concurrency
パラメーターを必ず設定し、プライベートロケーションで実行するテストのタイプおよび数と一致するワーカーリソースを割り当てます。
プライベートロケーションコンテナが取り扱うことのできるロードを増加してプライベートロケーションを垂直にスケーリングすることもできます。同様に、concurrency
パラメーターを使用して、ワーカーが実行できるテストの最大数を調整し、ワーカーに割り当てられたリソースを必ず更新してください。
詳しくは、プライベートロケーションのディメンションを参照してください。
プライベートロケーションを Continuous Testing に使用するには、concurrency
パラメーターに値を設定し、並列化を制御してください。詳しくは、Continuous Testing を参照してください。
最初はプライベートロケーションから実行するテストの数と種類に見合ったリソースを追加しますが、プライベートロケーションの規模を縮小すべきか拡大すべきかを知る最も簡単な方法は、厳密にモニターすることです。プライベートロケーションモニタリングは、すぐに使えるメトリクスやモニターと同様に、プライベートロケーションのパフォーマンスや状態に関する洞察を提供します。
詳しくは、プライベートロケーションモニタリングを参照してください。
デフォルトでは、Datadog Admin ロールを持つユーザーのみが、プライベートロケーションの作成、プライベートロケーションの削除、プライベートロケーションのインストールガイドラインにアクセスすることができます。
Datadog Admin ロールおよび Datadog Standard ロール]20を持つユーザーは、プライベートロケーションの表示、プライベートロケーションの検索、プライベートロケーションへの Synthetic テストの割り当てを行うことができます。ユーザーをこれら 2 つのデフォルト ロールのいずれかにアップグレードして、Private Locations ページへのアクセスを許可してください。
カスタムロール機能を使用している場合、ユーザーを synthetics_private_location_read
と synthetics_private_location_write
権限を含むカスタムロールに追加してください。