🐶

Cloud Run に Datadog Agent をサイドカーでデプロイする際の注意点

2023/05/22に公開

GCP

TL;DR

この記事は Cloud Run のサイドカーデプロイを利用して Datadog Agent をデプロイする際の注意点をまとめたものです。

デプロイの際の手順やサイドカーデプロイの活用方法については、「Cloud Run で Datadog Agent をサイドカーとして動かす」でまとめています。

また、こちらの内容は Datadog 公式にはサポートされていない内容のため、ご注意ください。Datadog は Cloud Run ドキュメントの通り、専用のエージェントを用いた Cloud Run シングルコンテナのトレース・ログ・カスタムメトリクスの送信を~~ベータ版で公開~~ 正式にサポートしています。(2023年8月17日に一般公開(GA) されました)

イメージをビルドする際

アプリケーションの Dockerfile

アプリケーションの Dockerfile には、言語に応じたトレーサーとそれに必要な環境変数を定義する必要があります。
この時、デフォルトのlocalhostで動作するためDD_AGENT_HOSTを設定する必要はありません。

Python アプリケーションを例にとると、ENV で Datadog の標準タグに基づいたタグを環境変数に定義し、RUNでrequirements.txtに記載された dd-tracer をインストールした上で、CMDで明示的にトレーサーを起動します。

Dockerfile.python

FROM python:3

ENV DD_SERVICE="calendar"
ENV DD_ENV="dev"
ENV DD_VERSION="0.1.0"

WORKDIR /home

COPY requirements.txt /home
COPY /calendar /home/calendar

RUN pip install -r requirements.txt

# Run the application with Datadog
CMD ["ddtrace-run", "python", "calendar/app.py"]

Datadog Agent の Dockerfile

Datadog が公開している Docker イメージでは、既に EXPOSE 8126/tcpをしているため明示的にポートを解放する必要はありません。

この段階では、設定変更を行うためにdatadog.yamlを配置したり、ENV内で環境変数をしていして組み込むことができます。環境変数の設定は Cloud Run へのデプロイ時でも可能ですが、イメージビルドの際に組み込むことで設定が反映された状態での配布が可能となります。

Dockerfile.dd

FROM gcr.io/datadoghq/agent:latest
COPY config.yaml /etc/datadog-agent/datadog.yaml

EXPOSE 8126

ENV DD_API_KEY=<DD_API_KEY>
ENV DD_SITE=datadoghq.com
ENV DD_APM_ENABLED=true

アプリケーションの構成

Datadog のトレーサーはアプリケーションに直接手を加えることなく、トレースデータを自動計測(auto instrumentation)することが可能です。このデータはデフォルトで Unix ドメインソケット/var/run/datadog/apm.socketにトレースを送信しようとします。ソケットが存在しない場合、トレースはhttp://localhost:8126に送信されます。

この設定を変更したい場合は、DD_TRACE_AGENT_URLを使用して、http:またはunix:で始まる形で送信先を指定することができます。
また、これに合わせる形で Datadog Agent のリッスンするポートはEXPOSEする必要があります。

イメージをデプロイする際

Cloud Run YAML の記載方法

Cloud Run YAML のリファレンスは公式ドキュメントがあります。

Datadog Agent を正常に稼働させるためには、常にリソースを保つ必要があり、spec: template: metadata: annotations: run.googleapis.com/cpu-throttling: "false"で CPU throttling を無効化することで、 CPU を常時割り当てることができます。

これについては、「新しい CPU 割り当てコントロールにより Cloud Run 上でさらに多様なワークロードを実行」で詳しい説明があります。

裏側では Knative を利用しているので、resouces: requestとresouces: limitで明示的に CPU とメモリのサイズを指定することも可能です。

Datadog Agent を先に起動することで、トレースデータの送信を初めから確実に行うことができます。これは、spec: template: metadata: annotations: container-dependencies: '{"app":["dd-agent"]}'で依存関係を定義することで行え、3つ以上のコンテナについても定義可能です。

Cloud Build でのデプロイ

Google Cloud Shell を利用している間、Shell 上の操作は利用しているユーザの IAM 権限に基づいて操作の認可を行うことが可能です。しかし、Cloud Build でcloudbuild.yamlで Docker イメージのビルド・プッシュ・デプロイを定義していても、デプロイ時に権限エラーが表示されることがあります。

これはユーザーの権限があっても、 Cloud Build が持つ権限に Cloud Run へのデプロイ権限が付与されていない場合に発生するもので、その場合は Cloud Shell から直接デプロイをし直す必要があります。

トレースデータを確認する際

Datadog Serverless Monitoring

Datadog での Google Cloud リソースの Serverless Monitoring は Cloud Functions と Cloud Run について、ベータ版で提供されています。(2023/5/21 現在)
しかし、今回のようにサイドカーデプロイを行った Cloud Run リソースについては、正しくメトリクスデータが取得できずに Datadog の Serverless ページ上には表示されません。

メトリクスデータを併せて取得したい場合は、Datadog 公式の Cloud Run ドキュメントに基づいて、専用のエージェントを用いた Cloud Run シングルコンテナデプロイを行う必要があります。

Datadog APM

Datadog APM は送信された Datadog Agent のメトリクス情報を Infrastructure タブに自動的に表示しますが、前述の通りサイドカーデプロイの場合このデータは取得できません。

ビルドやデプロイの際に指定したタグ変数は、主にスパンタグとして適用され、表示の下部に JSON 形式にパースされて表示されます。

また、Cloud Run によるルートスパンは表示されず、アプリケーションのリクエストやハンドラをルートスパンとして表示します。

GitHubで編集を提案