(レガシー) Observability Pipelines をセットアップして、Datadog で再ハイドレート可能な形式でログを Amazon S3 と Datadog に送信する
Observability Pipelines は US1-FED Datadog サイトでは利用できません。
バージョン 1.8 以下の OP Worker をバージョン 2.0 以上にアップグレードすると、既存のパイプラインが破損します。OP Worker バージョン 1.8 以下を引き続き使用する場合は、OP Worker をアップグレードしないでください。OP Worker 2.0 以上を使用する場合は、OP Worker 1.8 以前のパイプラインを OP Worker 2.x に移行する必要があります。
Datadog では、OP Worker バージョン 2.0 以上への更新を推奨しています。OP Worker のメジャーバージョンにアップグレードして更新し続けることが、OP Worker の最新の機能、修正、セキュリティ更新を入手するために唯一サポートされた方法です。
概要
Observability Pipelines Worker は、ログの収集、処理、およびあらゆるソースからあらゆる宛先へのルーティングを行うことができます。Datadog を使用することで、Observability Pipelines Worker のすべてのデプロイを大規模に構築および管理できます。
このガイドでは、共通ツールクラスターに Worker をデプロイし、これを構成してログを Datadog で再ハイドレート可能な形式でクラウドストレージに送信してアーカイブする方法を説明します。
デプロイメントモード
観測可能性パイプラインのリモート構成は、非公開ベータ版です。アクセスについては、
Datadog サポートまたはカスタマーサクセスマネージャーにお問い合わせください。
リモート構成の非公開ベータ版に登録している場合、テキストエディタでパイプライン構成の更新を行い、手動で変更をロールアウトするのではなく、Datadog UI からリモートでワーカーに変更をロールアウトすることができます。パイプラインを作成してワーカーをインストールするときに、デプロイメント方法を選択します。
パイプラインのデプロイ後にデプロイメントモードを変更する方法については、デプロイメントモードの更新を参照してください。
仮定
- すでに Datadog を使用していて、観測可能性パイプラインを使用したい。
- 観測可能性パイプラインワーカーがデプロイされるクラスターや、集計されるワークロードへの管理アクセス権がある。
- すべての他のクラスターが接続されている環境の共通ツールクラスターまたはセキュリティクラスターを持っている。
前提条件
インストールする前に、以下があることを確認してください。
観測可能性パイプラインで、この 2 つを生成することができます。
プロバイダー固有の要件
マシンが Docker を実行できるように構成されていることを確認してください。
Kubernetes ノードでワーカーを実行するには、1 つの CPU と 512MB RAM が利用可能なノードが最低 2 台必要です。Datadog は、ワーカー用に別のノードプールを作成することを推奨しており、これは本番デプロイのための推奨構成でもあります。
EBS CSI ドライバーが必要です。インストールされているか確認するには、以下のコマンドを実行し、リストに ebs-csi-controller があるか確認してください。
kubectl get pods -n kube-system
Worker が正しい EBS ドライブをプロビジョニングするには StorageClass が必要です。すでにインストールされているか確認するには、以下のコマンドを実行し、リストに io2 があるか確認してください。
io2 が存在しない場合は、StorageClass YAML をダウンロードし、kubectl apply で適用してください。
AWS Load Balancer コントローラーが必要です。インストールされているか確認するには、以下のコマンドを実行し、リストに aws-load-balancer-controller があるか確認してください。
Datadog では、Amazon EKS >= 1.16 を使用することを推奨しています。
本番レ環境ベルの要件については、OPW アグリゲーターアーキテクチャのベストプラクティスを参照してください。
APT ベースの Linux にはプロバイダー固有の要件はありません。
APT ベースの Linux にはプロバイダー固有の要件はありません。
AWS アカウントで Worker を実行するには、そのアカウントへの管理者アクセス権と以下の情報が必要です。
- インスタンスが実行される VPC ID。
- インスタンスが実行されるサブネット ID。
- VPC が置かれている AWS リージョン。
Log Archives のセットアップ
後で Observability Pipelines Worker をインストールするときに、提供されるサンプル構成には Datadog で再ハイドレート可能な形式でログを Amazon S3 に送信するためのシンクが含まれています。この構成を使用するには、アーカイブ用の S3 バケットを作成し、Worker が S3 バケットに書き込むことを許可する IAM ポリシーをセットアップします。次に、S3 バケットを Datadog Log Archives に接続します。
AWS 料金を参照して、リージョン間データ転送料金とクラウドストレージコストへの影響を確認してください。
S3 バケットを作成し、IAM ポリシーをセットアップする
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- IAM ユーザーを作成し、上記のポリシーを関連付けます。IAM ユーザーのアクセス資格情報を作成します。これらの資格情報を
AWS_ACCESS_KEY と AWS_SECRET_ACCESS_KEY として保存します。
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- 上記で作成したポリシーを使用するためのサービスアカウントを作成します。
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- IAM ユーザーを作成し、上記のポリシーを関連付けます。IAM ユーザーのアクセス資格情報を作成します。これらの資格情報を
AWS_ACCESS_KEY と AWS_SECRET_ACCESS_KEY として保存します。
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- IAM ユーザーを作成し、上記のポリシーを関連付けます。IAM ユーザーのアクセス資格情報を作成します。これらの資格情報を
AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY として保存します。
Navigate to Amazon S3. Create an S3 bucket to send your archives to. Do not make your bucket publicly readable.
Create a policy with the following permissions. Make sure to update the bucket name to the name of the S3 bucket you created earlier.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*"
},
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<MY_BUCKET_NAME>"
}
]
}
- Terraform で作成された IAM インスタンスプロファイルにポリシーを関連付けます。これは
iam-role-name 出力で見つけることができます。
S3 バケットを Datadog Log Archives に接続する
後でアーカイブを再ハイドレートできるように、先ほど作成した S3 バケットを Datadog Log Archives に接続する必要があります。
- Datadog の Log Forwarding に移動します。
- + New Archive をクリックします。
- わかりやすいアーカイブ名を入力します。
- ログパイプラインを通過するすべてのログをフィルタリングして、このアーカイブにそれらのログが入らないようにするクエリを追加します。例えば、クエリ
observability_pipelines_read_only_archive を追加します。これは、パイプラインを通過するログにはこのタグが追加されていないと仮定して設定されています。 - AWS S3 を選択します。
- バケットが存在する AWS アカウントを選択します。
- S3 バケットの名前を入力します。
- オプションでパスを入力します。
- 確認文をチェックします。
- オプションで、タグを追加し、再ハイドレートのための最大スキャンサイズを定義します。詳細については、高度な設定を参照してください。
- Save をクリックします。
追加情報については、Log Archives ドキュメントを参照してください。
観測可能性パイプラインワーカーのインストール
Observability Pipelines Worker の Docker イメージは Docker Hub のこちらに公開されています。
サンプルパイプラインコンフィギュレーションファイルをダウンロードします。
Docker で Observability Pipelines Worker を起動するには、次のコマンドを実行します。
docker run -i -e DD_API_KEY=<API_KEY> \
-e DD_OP_PIPELINE_ID=<PIPELINE_ID> \
-e DD_SITE=<SITE> \
-e AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID> \
-e AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY> \
-e DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME> \
-e DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION> \
-p 8282:8282 \
-v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
datadog/observability-pipelines-worker run
各プレースホルダーを以下のように置き換えます。
<API_KEY> を Datadog API キーに。<PIPELINES_ID> を Observability Pipelines の構成 ID に。<SITE> を AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を先ほど作成した AWS 資格情報に。<AWS_BUCKET_NAME> をログを保存する S3 バケットの名前に。<BUCKET_AWS_REGION> をターゲットサービスの AWS リージョン に。./pipeline.yaml はステップ 1 でダウンロードした構成の相対または絶対パスである必要があります。
AWS EKS 用の Helm チャート値ファイルをダウンロードします。
Helm チャートで、これらのプレースホルダーを以下の情報で置き換えます。
datadog.apiKey を Datadog API キーに。datadog.pipelineId を Observability Pipelines の構成 ID に。site を serviceAccount.name の ${DD_ARCHIVES_SERVICE_ACCOUNT} をサービスアカウント名に。pipelineConfig.sinks.datadog_archives の ${DD_ARCHIVES_BUCKET} をログを保存する S3 バケットの名前に。pipelineConfig.sinks.datadog_archives の ${DD_ARCHIVES_SERVICE_ACCOUNT} を対象サービスの AWS リージョンに置き換えてください。
以下のコマンドでクラスターにインストールします。
helm repo add datadog https://helm.datadoghq.com
helm upgrade --install \
opw datadog/observability-pipelines-worker \
-f aws_eks.yaml
以下のコマンドを実行し、APT が HTTPS 経由でダウンロードするようにセットアップします。
sudo apt-get update
sudo apt-get install apt-transport-https curl gnupg
以下のコマンドを実行して、システム上に Datadog の deb リポジトリをセットアップし、Datadog のアーカイブキーリングを作成します。
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list"
sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_06462314.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
以下のコマンドを実行して、ローカルの apt リポジトリを更新し、Worker をインストールします。
sudo apt-get update
sudo apt-get install observability-pipelines-worker datadog-signing-keys
キーとサイト (<AWS_BUCKET_NAME> をログを保存する S3 バケットの名前に、<BUCKET_AWS_REGION> をターゲットサービスの AWS リージョンに置き換えます。
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME>
DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION>
EOF
ホストの /etc/observability-pipelines-worker/pipeline.yaml にサンプルコンフィギュレーションファイルをダウンロードします。
ワーカーを起動します。
sudo systemctl restart observability-pipelines-worker
以下のコマンドを実行して、システム上に Datadog の rpm リポジトリをセットアップします。
cat <<EOF > /etc/yum.repos.d/datadog-observability-pipelines-worker.repo
[observability-pipelines-worker]
name = Observability Pipelines Worker
baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_4F09D16B.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
EOF
注: RHEL 8.1 または CentOS 8.1 を使用している場合は、上記の構成で repo_gpgcheck=1 の代わりに repo_gpgcheck=0 を使用してください。
パッケージを更新し、ワーカーをインストールします。
sudo yum makecache
sudo yum install observability-pipelines-worker
キーとサイト (<AWS_BUCKET_NAME> をログを保存する S3 バケットの名前に、<BUCKET_AWS_REGION> をターゲットサービスの AWS リージョンに置き換えます。
sudo cat <<-EOF > /etc/default/observability-pipelines-worker
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
DD_ARCHIVES_BUCKET=<AWS_BUCKET_NAME>
DD_ARCHIVES_SERVICE_ACCOUNT=<BUCKET_AWS_REGION>
EOF
ホストの /etc/observability-pipelines-worker/pipeline.yaml にサンプルコンフィギュレーションファイルをダウンロードします。
ワーカーを起動します。
sudo systemctl restart observability-pipelines-worker
- サンプル構成をダウンロードします。
- サンプル構成を使用して既存の Terraform に Worker モジュールをセットアップします。
vpc-id、subnet-ids、region の値を構成の AWS デプロイメントに合わせて更新します。また、datadog-api-key と pipeline-id の値をパイプラインに合わせて更新します。
ロードバランシング
Docker の指示には本番環境向けのセットアップは含まれていません。代わりに、コンテナ化された環境でのロードバランシングに関する御社の基準を参照してください。ローカルマシンでテストしている場合、ロードバランサーの構成は不要です。
クラウドプロバイダーが提供するロードバランサーを使用します。
ロードバランサーは、デフォルトの Helm セットアップで構成されているオートスケーリングイベントに基づいて調整されます。ロードバランサーは内部向けで、ネットワーク内でのみアクセス可能です。
Datadog Agent の構成時に Helm から渡されたロードバランサーの URL を使用します。
AWS ロードバランサーコントローラーでプロビジョニングされた NLB を使用します。
Worker をスケーリングする際のロードバランサーの推奨事項については、容量計画とスケーリングを参照してください。
クロスアベイラビリティゾーンロードバランシング
提供されている Helm の構成は、ロードバランシングの簡素化を目指していますが、クロス AZ (アヴェイラビリティーゾーン) トラフィックの潜在的な価格的影響を考慮する必要があります。可能な限り、サンプルは複数のクロス AZ ホップが起こりうる状況を避けるよう努めています。
サンプルの構成では、このコントローラーで利用可能なクロスゾーンのロードバランシング機能は有効化されていません。これを有効にするには、service ブロックに以下のアノテーションを追加します。
service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true
詳細については、AWS Load Balancer Controller を参照してください。
インストールが単一マシンの構成であるため、組み込みのロードバランシング機能はありません。御社の基準に従って、独自のロードバランサーをプロビジョニングしてください。
インストールが単一マシンの構成であるため、組み込みのロードバランシング機能はありません。御社の基準に基づいて、独自のロードバランサーをプロビジョニングする必要があります。
Terraform モジュールはインスタンスに対応する NLB をプロビジョニングします。DNS アドレスは Terraform の lb-dns 出力に返されます。
バッファリング
Observability Pipelines には、ダウンストリームの障害に対するクラスターの耐性を高めるための複数のバッファリング戦略が含まれています。提供されるサンプル構成は、ディスクバッファを使用します。その容量は、Observability Pipelines デプロイメントでコアあたり 10Mbps で約 10 分間のデータを保持するように評価されています。これは、一時的な問題が解決するのに十分な時間であり、インシデント対応者が可観測性データに対して何をすべきかを決定するのにも役立ちます。
デフォルトでは、Observability Pipelines Worker のデータディレクトリは /var/lib/observability-pipelines-worker に設定されています。ホストマシンに、コンテナのマウントポイントに割り当てられた十分なストレージ容量があることを確認してください。
AWS の場合、Datadog は io2 EBS ドライブファミリーの使用を推奨します。代替として、gp3 ドライブも使用できます。
デフォルトでは、Observability Pipelines Worker のデータディレクトリは /var/lib/observability-pipelines-worker に設定されています。サンプル構成を使用している場合、バッファリングのために少なくとも 288GB の空きスペースがあることを確認してください。
可能であれば、別の SSD をその場所にマウントすることを推奨します。
デフォルトでは、Observability Pipelines Worker のデータディレクトリは /var/lib/observability-pipelines-worker に設定されています。サンプル構成を使用している場合、このディレクトリに少なくとも 288GB のスペースが利用可能であることを確認してください。
可能であれば、その場所に別の SSD をマウントすることをお勧めします。
デフォルトでは、各インスタンスに 288GB の EBS ドライブが割り当てられており、上記のサンプル構成では、これをバッファリングに使用するように設定されています。
Datadog Agent を Observability Pipelines Worker に接続する
Datadog Agent のログを Observability Pipelines Worker に送信するには、Agent 構成を次のように更新します。
observability_pipelines_worker:
logs:
enabled: true
url: "http://<OPW_HOST>:8282"
OPW_HOST は先ほど設定したロードバランサーやマシンの IP です。シングルホスト Docker ベースのインストールの場合、これは基盤となるホストの IP アドレスです。Kubernetes ベースのインストールでは、以下のコマンドを実行して EXTERNAL-IP をコピーすることで取得できます。
kubectl get svc opw-observability-pipelines-worker
Terraform のインストールでは、lb-dns 出力が必要な値を提供します。
この時点で、可観測性データは Worker に送信され、その後 S3 アーカイブに送られるはずです。
デプロイメントモードの更新
パイプラインをデプロイした後、手動で管理するパイプラインからリモート構成が有効なパイプラインへ、またはその逆など、デプロイメント方法を切り替えることもできます。
リモート構成のデプロイメントから手動管理のデプロイメントに切り替えたい場合
- Observability Pipelines に移動し、パイプラインを選択します。
- 設定歯車をクリックします。
- Deployment Mode で、manual を選択して有効にします。
DD_OP_REMOTE_CONFIGURATION_ENABLED フラグを false に設定し、ワーカーを再起動します。このフラグで再起動されていないワーカーはリモート構成が有効であり続け、つまりワーカーはローカルコンフィギュレーションファイルを通して手動で更新されません。
手動で管理していたデプロイメントからリモート構成のデプロイメントに切り替えたい場合
- Observability Pipelines に移動し、パイプラインを選択します。
- 設定歯車をクリックします。
- Deployment Mode で、Remote Configuration を選択して有効にします。
DD_OP_REMOTE_CONFIGURATION_ENABLED フラグを true に設定し、ワーカーを再起動します。このフラグで再起動されていないワーカーは UI にデプロイされた構成に対してポーリングされません。- バージョン履歴にあるバージョンをデプロイして、ワーカーが新しいバージョン構成を受け取れるようにします。バージョンをクリックします。Edit as Draft をクリックし、Deploy をクリックします。
アーカイブを再ハイドレートする
アーカイブからの再ハイドレートを参照して、Datadog でアーカイブを再ハイドレートして、それらのログの分析と調査を開始する手順を確認してください。
参考資料
