(レガシー) Datadog で Observability Pipelines をセットアップする

Docs > Observability Pipelines（観測データの制御） > (LEGACY) Observability Pipelines Documentation > (レガシー) Observability Pipelines Worker のセットアップ > (レガシー) Datadog で Observability Pipelines をセットアップする

バージョン 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][1] は、ログを収集、処理し、あらゆるソースからあらゆる宛先へルーティングできます。Datadog を使用することで、Observability Pipelines Worker のすべてのデプロイメントを大規模に構築および管理できます。このガイドでは、共通ツールクラスターに Worker をデプロイし、Datadog Agent を構成してログとメトリクスを Worker に送信する方法を説明します。

Observability Pipelines アグリゲーターを通じてデータを送信する複数のワークロードクラスターの図。

## デプロイメントモード

観測可能性パイプラインのリモート構成は、非公開ベータ版です。アクセスについては、Datadog サポートまたはカスタマーサクセスマネージャーにお問い合わせください。

リモート構成の非公開ベータ版に登録している場合、テキストエディタでパイプライン構成の更新を行い、手動で変更をロールアウトするのではなく、Datadog UI からリモートでワーカーに変更をロールアウトすることができます。パイプラインを作成してワーカーをインストールするときに、デプロイメント方法を選択します。

パイプラインのデプロイ後にデプロイメントモードを変更する方法については、デプロイメントモードの更新を参照してください。

前提条件

すでに Datadog を使用しており、Observability Pipelines を利用したい。
Observability Pipelines Worker がデプロイされるクラスター、および集約されるワークロードに管理者アクセス権がある。
すべての他のクラスターが接続されている環境の共通ツールまたはセキュリティクラスターがある。

必要条件

インストールする前に、以下があることを確認してください。

有効な Datadog API キー。
パイプライン ID。これらは Observability Pipelines で生成できます。

プロバイダー固有の要件

マシンが Docker を実行するように構成されていることを確認してください。

Kubernetes ノードで Worker を実行するには、最低でも 1 CPU と 512MB の RAM を持つ 2 つのノードが必要です。Datadog は、Worker 用の別個のノードプールを作成することを推奨しており、これは本番環境デプロイメントの推奨構成でもあります。

[EBS CSI ドライバー][1]が必要です。インストールされているか確認するには、次のコマンドを実行し、リストに ebs-csi-controller があるか確認します。 shell kubectl get pods -n kube-system
Workers が適切な EBS ドライブをプロビジョニングするために、StorageClass が必要です。インストールされているか確認するには、次のコマンドを実行し、リストに io2 があるか確認します。 shell kubectl get storageclass io2 が存在しない場合、[StorageClass YAML][2] をダウンロードして kubectl apply で適用します。
[AWS Load Balancer コントローラー][3]が必要です。インストールされているか確認するには、次のコマンドを実行し、リストに aws-load-balancer-controller があるか確認します。 shell helm list -A
Datadog は Amazon EKS >= 1.16 の使用を推奨しています。本番環境レベルの要件については、[OPW アグリゲーターアーキテクチャのベストプラクティス][4]を参照してください。 [1]: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html [2]: /resources/yaml/observability_pipelines/helm/storageclass.yaml [3]: https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html [4]: /ja/observability_pipelines/legacy/architecture/

Kubernetes ノードで Worker を実行するには、最低でも 1 CPU と 512MB の RAM を持つ 2 つのノードが必要です。Datadog は、Worker 用の別個のノードプールを作成することを推奨しており、これは本番環境デプロイメントの推奨構成でもあります。本番環境レベルの要件については、[OPW アグリゲーターアーキテクチャのベストプラクティス][1]を参照してください。 [1]: /ja/observability_pipelines/legacy/architecture/

APT ベースの Linux にはプロバイダー固有の要件はありません。

RPM ベースの Linux にはプロバイダー固有の要件はありません。

Worker を AWS アカウントで実行するには、そのアカウントへの管理者アクセスが必要です。Worker インスタンスを実行するために次の情報を収集してください。

インスタンスが実行される VPC ID。
インスタンスが実行されるサブネット ID。
VPC がある AWS リージョン。

CloudFormation インストールは Remote Configuration のみをサポートします。

CloudFormation インストールは非本番環境レベルのワークロードにのみ使用してください。

インスタンスが実行される VPC ID。
インスタンスが実行されるサブネット ID。
VPC が置かれている AWS リージョン。

Observability Pipelines Worker のインストール

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> \
  -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> をに置き換えてください。./pipeline.yaml はステップ 1 でダウンロードした構成への相対または絶対パスである必要があります。

AWS EKS 用の Helm チャート値ファイルをダウンロードします。
Helm チャートで、datadog.apiKey と datadog.pipelineId の値をパイプラインに合わせて置き換え、site の値にはを使用します。その後、以下のコマンドでクラスターにインストールします。
```
helm repo add datadog https://helm.datadoghq.com
```
```
helm repo update
```
```
helm upgrade --install \
    opw datadog/observability-pipelines-worker \
    -f aws_eks.yaml
```

Azure AKS 用の Helm チャート値ファイルをダウンロードします。
Helm チャートで、datadog.apiKey と datadog.pipelineId の値をパイプラインに合わせて置き換え、site の値にはを使用します。その後、以下のコマンドでクラスターにインストールします。
```
helm repo add datadog https://helm.datadoghq.com
```
```
helm repo update
```
```
helm upgrade --install \
  opw datadog/observability-pipelines-worker \
  -f azure_aks.yaml
```

Google GKE 用の Helm チャート値ファイルをダウンロードします。
Helm チャートで、datadog.apiKey と datadog.pipelineId の値をパイプラインに合わせて置き換え、site の値にはを使用します。その後、以下のコマンドでクラスターにインストールします。
```
helm repo add datadog https://helm.datadoghq.com
```
```
helm repo update
```
```
helm upgrade --install \
  opw datadog/observability-pipelines-worker \
  -f google_gke.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
```

キーとサイト () を Worker の環境変数に追加します。

sudo cat <<-EOF > /etc/default/observability-pipelines-worker
DD_API_KEY=<API_KEY>
DD_OP_PIPELINE_ID=<PIPELINE_ID>
DD_SITE=<SITE>
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
```

キーとサイト () を Worker の環境変数に追加します。

sudo cat <<-EOF > /etc/default/observability-pipelines-worker
DD_API_KEY=<API_KEY>
DD_OP_PIPELINE_ID=<PIPELINE_ID>
DD_SITE=<SITE>
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 の値をパイプラインに合わせて更新します。

CloudFormation インストールは非本番環境レベルのワークロードにのみ使用してください。

Worker を AWS アカウントにインストールするには、CloudFormation テンプレートを使用してスタックを作成します。

Worker 用の CloudFormation テンプレートをダウンロードします。
CloudFormation console で、Create stack をクリックし、With new resources (standard) オプションを選択します。
Template is ready オプションが選択されていることを確認し、Upload a template file を選択します。 Choose file をクリックして、先ほどダウンロードした CloudFormation テンプレートファイルを追加します。Next をクリックします。
Specify stack details で、スタックの名前を入力します。
CloudFormation テンプレートのパラメーターを入力します。特に注意が必要なものがあります。
- APIKey と PipelineID には、前の必要条件セクションで取得したキーと ID を入力します。
- VPCID と SubnetIDs には、以前に選択したサブネットと VPC を入力します。
- 他のパラメーターは Worker デプロイメントのための妥当なデフォルトに設定されていますが、必要に応じて調整できます。
Next をクリックします。
パラメーターが正しいことを確認し、IAM の必要な権限のチェックボックスをクリックし、Submit をクリックしてスタックを作成します。

CloudFormation はここでインストールを処理します。Worker インスタンスは起動し、必要なソフトウェアをダウンロードし、自動的に実行を開始します。

サンプル構成で使用されるソース、トランスフォーム、シンクの詳細については、構成を参照してください。データの変換に関する詳細は、データの操作を参照してください。

ロードバランシング

本番環境向けのセットアップは 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 を参照してください。

クラウドプロバイダーが提供するロードバランサーを使用します。これらは、デフォルトの Helm セットアップで構成されているオートスケーリングイベントに基づいて調整されます。ロードバランサーは内部向けなので、あなたのネットワーク内からのみアクセス可能です。

Datadog Agent の構成時に Helm から渡されたロードバランサーの URL を使用します。

Worker をスケーリングする際のロードバランサーの推奨事項については、容量計画とスケーリングを参照してください。

クロスアベイラビリティゾーンロードバランシング

クラウドプロバイダーが提供するロードバランサーを使用します。それらはデフォルトの Helm セットアップが構成されたオートスケーリングイベントに基づいて調整されます。ロードバランサーは内部向けであり、ネットワーク内でのみアクセス可能です。

Datadog Agent の構成時に Helm から渡されたロードバランサーの URL を使用します。

Worker をスケーリングする際のロードバランサーの推奨事項については、容量計画とスケーリングを参照してください。

クロスアベイラビリティゾーンロードバランシング

グローバルアクセスはデフォルトで有効になっています。これは共有ツールクラスターで必要とされる可能性が高いためです。

インストールの単一マシンの性質上、ロードバランシングの組み込みサポートは提供されていません。会社の基準を使用して独自のロードバランサーをプロビジョニングする必要があります。

NLB は Terraform モジュールによってプロビジョニングされ、インスタンスを指すように構成されます。DNS アドレスは Terraform の lb-dns 出力で返されます。

CloudFormation インストールは非本番環境レベルのワークロードにのみ使用してください。

NLB は CloudFormation テンプレートによってプロビジョニングされ、AutoScaling グループを指すように構成されます。DNS アドレスは CloudFormation の LoadBalancerDNS 出力で返されます。

バッファリング

Observability Pipelines には、ダウンストリームの障害に対するクラスターの耐性を高めるための複数のバッファリング戦略が含まれています。提供されるサンプル構成は、ディスクバッファを使用します。その容量は、Observability Pipelines デプロイメントでコアあたり 10Mbps で約 10 分間のデータを保持するように評価されています。これは、一時的な問題が解決するのに十分な時間であり、インシデント対応者が可観測性データに対して何をすべきかを決定するのにも役立ちます。

デフォルトでは、Observability Pipelines Worker のデータディレクトリは /var/lib/observability-pipelines-worker に設定されています。ホストマシンがコンテナのマウントポイントに十分なストレージ容量を割り当てていることを確認してください。

AWS の場合、Datadog は io2 EBS ドライブファミリーを使用することを推奨しています。代替として、gp3 ドライブも使用できます。

Azure AKS の場合、Datadog は default (managed-csi とも呼ばれる) ディスクを使用することを推奨しています。

Google GKE の場合、Datadog は SSD でバックアップされた premium-rwo ドライブクラスを使用することを推奨しています。HDD でバックアップされた standard-rwo クラスでは、バッファが有用となるための十分な書き込み性能を提供できない可能性があります。

デフォルトでは、Observability Pipelines Worker のデータディレクトリは /var/lib/observability-pipelines-worker に設定されています。サンプル構成を使用している場合、このディレクトリに少なくとも 288GB のスペースが利用可能であることを確認してください。

可能であれば、別の SSD をその場所にマウントすることを推奨します。

デフォルトでは、各インスタンスに 288GB の EBS ドライブが割り当てられ、上記のサンプル構成はそれをバッファリングに使用するように設定されています。

この CloudFormation テンプレートによって作成された EBS ドライブは、それらが作成されたインスタンスのライフサイクルに関連付けられています。これは、例えば AutoScaling グループによってインスタンスが終了された場合にデータが失われることを意味します。 このため、CloudFormation インストールは非本番環境レベルのワークロードにのみ使用してください。

デフォルトでは、各インスタンスに 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 出力が必要な値を提供します。CloudFormation インストールの場合、LoadBalancerDNS CloudFormation 出力に正しい URL があります。

この時点で、可観測性データは Worker に送られ、データ処理が可能です。

デプロイメントモードの更新

パイプラインをデプロイした後、手動で管理するパイプラインからリモート構成が有効なパイプラインへ、またはその逆など、デプロイメント方法を切り替えることもできます。

リモート構成のデプロイメントから手動管理のデプロイメントに切り替えたい場合

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 をクリックします。

データを活用する

提供されたサンプル構成には、Observability Pipelines のツールを示し、Datadog に送信されるデータが正しい形式であることを保証する例の処理ステップが含まれています。

ログの処理

サンプルの Observability Pipelines 構成は次のことを行います。

Observability Pipelines Worker に Datadog Agent から送信されたログを収集します。
Observability Pipelines Worker を通過するログにタグを付けます。これは、クラスターを更新する際に、まだ Worker にシフトする必要があるトラフィックを判断するのに役立ちます。また、ロードバランサーを通じてログがどのようにルーティングされているかを示し、バランスの不均衡がある場合に役立ちます。
Worker を通過するログのステータスを修正します。Datadog Agent がコンテナからログを収集する方法のため、提供された .status 属性はメッセージの実際のレベルを正しく反映していません。これは、ログが Worker から受信されるバックエンドのパースルールで問題が発生するのを防ぐために削除されます。

構成例には、次の 2 つの重要なコンポーネントがあります。

logs_parse_ddtags: 文字列に格納されているタグを構造化データにパースします。
logs_finish_ddtags: Datadog Agent が送信するような形式になるようにタグを再エンコードします。

内部的には、Datadog Agent はログタグを 1 つの文字列の CSV として表現します。これらのタグを効果的に操作するには、取り込みエンドポイントに送信する前に、パース、修正、そして再エンコードする必要があります。これらのステップは、これらのアクションを自動的に実行するように設計されています。パイプラインに加える修正、特にタグの操作に関しては、この 2 つのステップの間に行う必要があります。

この時点で、環境は Observability Pipelines 用に構成されており、データが流れています。特定のユースケースに合わせてさらに構成が必要な場合がありますが、提供されたツールが出発点を提供します。