yak shaving life

遠回りこそが最短の道

Datadog Agentを手元のマシンで動かして、ローカルのサーバを監視する


Datadogの新しいサービスを使い始めるときやcustom metricsを作りたいとき、まずローカルで動作確認したくなると思う。

「Datadog Agentをローカルで動かす方法」みたいな公式ドキュメントやブログ記事が意外となかったのでやり方をメモしておく。

ApplicationがDocker Containerとして動作する場合

dd-agentの公式イメージを使って、アプリケーションとDatadog Agentを同じネットワーク上で動かせば良い。具体的にはdocker-composeを使うのが簡単。 dd-agentの使い方についてはhttps://docs.datadoghq.com/agent/docker/?tab=standard、別のコンテナからTraceを取得する方法はhttps://docs.datadoghq.com/agent/docker/apm/?tab=linux#tracing-from-other-containersを見れば良いです。

下記は最低限の設定をしたdocker-compose.ymlの例。使っているサービスはAPMのみ。

version: '3.8'

services:
  app:
    ... (略)
  db:
    ... (略)
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
    environment:
      - DD_API_KEY=<YOUR_API_KEY>
      - DD_APM_ENABLED=true
      - DD_APM_NON_LOCAL_TRAFFIC=true

アプリケーション側でdatadog agentのhost名をdatadog-agentにしましょう。

# Javaの場合
DD_AGENT_HOST=datadog-agent
java -Ddd.agent.host=$DD_AGENT_HOST -jar yourApp.jar
# Rubyだとこう
Datadog.configure do |c|
  c.tracer hostname: 'datadog-agent'
end
// Go
tracer.Start(tracer.WithAgentAddr("datadog-agent"))

あとはdatadog-agentコンテナのログを眺めていればなんとなく動作が分かる。Trace何件送りました、みたいな。これがずっと0件だと何かしら間違っている可能性が高い。

結構簡単でよかった。

ApplicationがDockerizeされていない場合

やったことないけど多分同じ。DD_APM_NON_LOCAL_TRAFFIC=trueは要らなそう。この場合はdocker-compose使う必然性がないので公式に載ってる通りにdocker runすれば良いと思われるが、その場合はagentのポートまで指定したほうが良さそう。デフォルトは8126

補足

これはローカルからやってるテストですよーってのがちゃんと分かるように、DD_ENVなりなんなりに"local"とか"test"とか入れときましょう。