DatadogでDocker監視が幸せになった話

こんにちは、エンジニアリングGの安田(@dasoran2)です。7月に入社してAI・機械学習チームに所属しています。趣味は猫耳で入社早々会社では猫耳エンジニアとしての地位を確立しつつあります。

今回は転職早々ではあるものの、自分のチームでDatadogをトライアル導入したのでその話を書きます。

本稿は以下のような内容をお話しします。

• Datadogを選んだ理由
• DatadogでのDocker監視の概要
• Datadogでハマったところ

*1

事の発端

チーム内でレスポンスタイムに問題が発生して、その原因を調査する機会がありました。

しかし、メトリクスがCloudWatchで収集されているもののほかになく、それ以上を取るにはインスタンスやコンテナの中に入って収集する必要がありました。そのため、迅速な対応ができずこの状況を打破したいと考え各種導入検討を開始しました。

Datadogを選んだ理由

基本的にはメトリクスが取れればよかったためDatadog以外も検討したのですが、最終的にはDatadogを選択しました。

小さな理由としては

• UIが綺麗
• ダッシュボードのカスタマイズ性の高さ
• レスポンスに対する悪評がなかった

などありますが、大きな理由は

• Dockerのメトリクス取得をしっかりサポートしている
• AWSのリソースが取れる
  • しかも(現状)ç„¡æ–™

この点でした。

そして特にDockerのメトリクス取得がかなりよかったのでこの魅力をお伝えしたいと思います。

DatadogでDockerのメトリクスを取得する

DatadogはmackerelやNewRelicと同じく専用のAgentをサーバーで動かすことでメトリクスを取得します。詳しくは以下のURLを確認してください。

docs.datadoghq.com

Agentは

• Linux上で動くパッケージ
• Dockerイメージ

二種類から選ぶことになります。理由は後述しますが、Dockerの監視をする場合はDocker版のAgentを使うことを強く推奨します。

Agentを動かし始めると、AgentがDatadogにデータを送信しDatadog側がサーバーを認識する仕組みになっています。

システムのメトリクスのほかにもちろんですがミドルウェアのメトリクスを取ることもできます。ミドルウェアのメトリクスを取るには基本的には*2設定を追加するだけで大丈夫です。どういったミドルウェアのメトリクスが取れるのかは以下を確認していただければわかりますが、かなり広範囲をカバーしています。

docs.datadoghq.com *3

Docker自体のメトリクスを取得する

DatadogでDockerのメトリクスを取得するにはDocker integrationを使用します。

docs.datadoghq.com

Docker自体のメトリクスを取得するには前述の通り設定を追加と有効になります。ただし、Docker版のAgentを使った場合はデフォルトで有効になっています。

このintegrationを導入すると

• コンテナのCPU使用率
• コンテナのメモリ使用率
• 動いているコンテナの総数

などが取れます。

また以下のようなかっこいいダッシュボードで一覧を確認できるようになります。

動いているDockerコンテナ一覧

Dockerの中のミドルウェアのメトリクスを取得する

Docker自体のメトリクスはともかく、今やアプリケーション自体がDockerの中で動いているのでDockerの中のJVMやミドルウェアのメトリクスが取得したくなります。

ここがDatadogで一番よかったところで、Datadogはテンプレート的な設定を用意すると動いているコンテナのIP等を自動で解決してメトリクスを取得してくれる仕組みがあります。それがAutoDiscoveryです！

docs.datadoghq.com

このテンプレートは全ての設定で使えるのですが、例えば

init_config:

instances:
  - nginx_status_url: http://localhost/nginx_status/

といったnginxの設定があります。DockerコンテナのIPが 172.16.0.5 *4 だとすると、

init_config:

instances:
  - nginx_status_url: http://172.16.0.5/nginx_status/

とすればホストからメトリクスが取得できます。しかし、当然ですがnginxのコンテナが何台動くかは事前には把握できない(するような設計にしたくない)ので、現実的ではなくなります。

ここでAutoDiscoveryを使うと

ad_identifiers:
  - httpd

init_config:

instances:
  - nginx_status_url: http://%%host%%/nginx_status/

とすれば、上で動いているコンテナのIPを勝手に解決してメトリクスを取得してくれるようになります。 ここで、ad_identifiersはDockerのshort image nameを指定しています。*5

これで、仮想マシン上で動いていたプロセスと同じようにDocker上のプロセスのメトリクスも取れるようになりました。

はまったところ

と、素敵なDocker監視生活を開始できたわけですが、結構ハマりポイントがあります。

1.AutoDiscoveryがきかない

はじめホストで直で動くAgentを使用してDocker integrationまでセットアップしたのですが、その後AutoDiscoveryがコンテナを見つけてくれず苦労しました。

よくよく前述のAutoDiscoveryのページを見てみると、

How to set it up

The Datadog Docker Agent automatically auto-discovers other containers.

と、Docker版Agentの話しかなく、どこにも明記はないもののDocker版のAgentでないと監視してくれないのではと気づきました。

真偽は不明ですが、同じ設定をDocker版Agentに食わせたところ動いたためおそらくそうなのだと思います。

ちなみにわりとlogを吐いてくれるので、agent.log*6を見ると解決することが多いです。他AutoDiscoveryだと

$ agent configcheck -v

このコマンドで現在の設定適用状況が確認できるのでこちらも活用しました。

2.JVMの監視をする場合イメージが違う

JVMの監視を行う場合、JMXを使って監視します。

docs.datadoghq.com

ここの説明を読む分に明記されていないと思うのですが、実はDocker版Agentには通常版とJVMを含んだ版があります。

datadog/agent - Docker hub

ここを見ると

• latest
• latest-jmx

この2つがあり、latest-jmxでないとintegrationが動きません

3.Datadogの5系のAgentと6系のAgentのドキュメントがぐちゃぐちゃ

よく読んでいないのが悪いのですが、主要バージョンとして5系と6系があるらしくドキュメントも両方あります。 不便だと思ったのは、バージョンごとにドキュメントが独立しているのではなく同じネームスペースに両方のバージョンのドキュメントが混在していることです。

これは気をつけましょうくらいですが、共有のために書いておきます。

Datadogを導入した結果

Datadogを導入した結果、

• 普通のメトリクスが取れるようになった
• ダッシュボードで監視できるようになった
• Dockerコンテナ上のプロセスもいい感じに取得できるようになった

というわけで、いってしまえば当たり前の環境が手に入りました。

こういったサービスの中でDatadogでよかった、というとやはりDocker内のプロセス監視がお手軽だった点です。

また、Dashboardが非常に見やすく満足度は結構高かったです。

今回作ったDashboard

地味に嬉しかった点として、細かく欲しい機能が存在したことがあります。

• SAML認証とか
• slack通知とか
• LBとかのネットワーク系とか

個別個別は他のサービスにもありますが、その対応の広さは魅力でした。

まとめ

まとめとしては

DatadogのDocker監視よかったよ！

これに尽きます。

今回導入にあまり時間を使いたくなかったのでフルマネージドで監視するにはかなりありな選択肢だと思いました。

We're Hiring!

この会社に入社してまだ一月と少しですが、早速こういった「やりたい！」を業務で取り組ませていただけました。他にも様々な仕事にチャレンジできる環境です。

逆にやりたいことが沢山ありすぎて手が回りません！一緒に取り組んでくれる方、お待ちしています！

*1:アイコンがかわいい

*2:Docker版のAgentでは、jmxを取るためにはJVMの入ったDockerイメージを使用する必要があります。はまったところ参照

*3:こちらはミドルウェア以外のインテグレーションを含んでいます。slackとか。

*4:特に数字に意味はない

*5:公式ドキュメントにありますが、これはimage nameに限りません。

*6:5系だとcollector.logだった気がする