この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先日、DatadogでECSのコンテナのモニタリングをできるようにしたのですが、さっそく 青いぷにょぷにょ にFargate化されてしまい、監視できなくなってしまいました。（もちろん開発環境の話です。）Fargate内のコンテナのリソースについては、supervisordなどを使いコンテナ内にdd-agentのプロセスを起動することで収集できるのではと想像していたのですが、現状ではコンテナのリソースを収集する手段が提供されていないということが、以下の記事にかかれていました。
ちなみに、記事にかかれているDocker Stats APIとは...
Display a live stream of container(s) resource usage statistics
docker stats | Docker Documentation
ふむふむ、dd-agentはECSが提供しているこのようなAPIを使ってコンテナのリソースを収集していたのですね。確かにFargateがこのようなインターフェイスを提供していなければお手上げですね。
ということで、Fargateのコンテナのモニタリングについて記事を書く目論見が外れたので、代わりにdocker-dd-agentがどのようにしてECSのコンテナのリソースを収集しているのか、詳しく見てみることにしました。
なお、この記事は限られた時間の中で調べたことをそのまま書いたチラシの裏です。この記事を何かの参考にされる場合は、鵜呑みにせず信頼できる一次情報を確認するようにしてください。
docker-dd-agentの中身
Dockerfile
まずはDockerfileを見てみます。
https://github.com/DataDog/docker-dd-agent/blob/master/Dockerfile
大まかには以下の流れであることがわかりました。
- dd-agentのインストール
- ヘルスチェック
- 設定（環境に応じて）
- supervisordを起動
最後にCMDコマンドで supervisord を起動しているので、どうやら複数プロセスが動いていることがわかりました。supervisord を使ってコンテナに複数のプロセスを動かすというパターンは、ノウハウとしては知っていましたが実際に見るのは初めてです。
supervisord
次にsupervisordが起動しているプロセスを見てみます。
https://github.com/DataDog/docker-dd-agent/blob/master/dogstatsd/supervisor.conf
supervisordを見るのは初めてなので大まかな理解ですが、datadog-agentの正体は、forwarder,dogstatsd,trace-agentの3つのプロセスからなることがわかりました。
Architecture
これらのプロセスについては、dd-agentのWikiに説明がありました。
https://github.com/DataDog/dd-agent/wiki/Agent-Architecture
1. The collector (agent.py), responsible for gathering system and application metrics from the machine.
2. The forwarder (ddagent.py), responsible for buffering and communicating with Datadog HQ over SSL.
3. dogstatsd (dogstatsd.py), responsible for aggregating local metrics sent from your code
4. supervisord, responsible for keeping all previous processes up and running.
graphite ---(tcp/17124)--->
|
|
dogstatsd ---(http)------> |
| |
v v
collector ---(http)---> forwarder ---(https)---> datadoghqforwarder
Architectureによると、それぞれのリソース収集プロセスが集めた情報をdatadoghqに送る役割のプロセスのようです。
dogstatsd
DogStatsDは、Datadog Agent 3.0以上に同胞されているメトリクス集約サーバです。DogStatsDは、StatsDプロトコルをサポートすると共に、datadog専用の機能にも対応するよう拡張されています。
https://docs.datadoghq.com/ja/guides/dogstatsd/
ちなみにStatsDとは？
https://github.com/etsy/statsd
A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP or TCP and sends aggregates to one or more pluggable backend services (e.g., Graphite).
ふむふむ。datadog用に拡張されたStatsDのようですね。
trace-agent
APM用のエージェントです。DD_APM_ENABLED=trueのときのみ起動するようです。使ってない時はDD_APM_ENABLED=falseにしておきましょう。（今まで使ってないのに起動していました）
その他
その他に、docker-dd-agentコンテナの起動時のログを見ると他にいくつかのプロセスが起動していることがわかりました。
2017-12-14 06:52:14,739 CRIT Supervisor running as root (no user in config file)
2017-12-14 06:52:14,809 INFO RPC interface 'supervisor' initialized
2017-12-14 06:52:14,810 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2017-12-14 06:52:14,810 INFO supervisord started with pid 1
2017-12-14 06:52:15,812 INFO spawned: 'process-agent' with pid 11
2017-12-14 06:52:15,813 INFO spawned: 'trace-agent' with pid 12
2017-12-14 06:52:15,814 INFO spawned: 'forwarder' with pid 13
2017-12-14 06:52:15,815 INFO spawned: 'dogstatsd' with pid 14
2017-12-14 06:52:15,822 INFO spawned: 'jmxfetch' with pid 15
2017-12-14 06:52:15,826 INFO spawned: 'go-metro' with pid 16
2017-12-14 06:52:15,834 INFO spawned: 'collector' with pid 17
2017-12-14 06:52:17,968 INFO success: go-metro entered RUNNING state, process has stayed up for > than 2 seconds (startsecs)
2017-12-14 06:52:18,969 INFO success: jmxfetch entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)
2017-12-14 06:52:20,978 INFO success: process-agent entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2017-12-14 06:52:20,978 INFO success: trace-agent entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2017-12-14 06:52:20,978 INFO success: forwarder entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2017-12-14 06:52:20,978 INFO success: dogstatsd entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2017-12-14 06:52:20,978 INFO success: collector entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
2017-12-14 06:52:20,979 INFO exited: go-metro (exit status 0; expected)
2017-12-14 06:52:23,961 INFO exited: jmxfetch (exit status 0; expected)- process-agent: 不明
- jmxfetch: JMX Imagesの場合のみ必要ということがREADMEに記載がありました。起動後すぐに終了しているのは正しい動作のようです。
- go-metro: 不明。こちらも起動がすぐに終了しています。（いいんだろうか）
終わりに
はい。本当にちょっとだけでした。本当はもう少しECSとdd-agentのインターフェイス部分まで迫りたかったのですが、時間の都合でここまでとなります。
学びとしては、
- 自分が使っているツールについてはちゃんと隅々までドキュメントを読んでから使おう（今回も不要なプロセスが動いていることが分かりました）
- 限られた時間の中で、全く知らない事を調査するのは面白いですし、これも一つの技術なので訓練次第でもっと効率良く出来そうと思いました。
あとやはり↑の2つの大きな妨げとなっているのは英語を読む力の無さですね。来年こそは英語をね、はい。
15
