こんにちは、エンジニアリングGの安田(@dasoran2)です。7月に入社してAI・機械学習チームに所属しています。趣味は猫耳で入社早々会社では猫耳エンジニアとしての地位を確立しつつあります。
今回は転職早々ではあるものの、自分のチームでDatadogをトライアル導入したのでその話を書きます。
本稿は以下のような内容をお話しします。
- Datadogを選んだ理由
- DatadogでのDocker監視の概要
- Datadogでハマったところ
事の発端
チーム内でレスポンスタイムに問題が発生して、その原因を調査する機会がありました。
しかし、メトリクスがCloudWatchで収集されているもののほかになく、それ以上を取るにはインスタンスやコンテナの中に入って収集する必要がありました。そのため、迅速な対応ができずこの状況を打破したいと考え各種導入検討を開始しました。
Datadogを選んだ理由
基本的にはメトリクスが取れればよかったためDatadog以外も検討したのですが、最終的にはDatadogを選択しました。
小さな理由としては
- UIが綺麗
- ダッシュボードのカスタマイズ性の高さ
- レスポンスに対する悪評がなかった
などありますが、大きな理由は
- Dockerのメトリクス取得をしっかりサポートしている
- AWSのリソースが取れる
- しかも(現状)無料
この点でした。
そして特にDockerのメトリクス取得がかなりよかったのでこの魅力をお伝えしたいと思います。
DatadogでDockerのメトリクスを取得する
DatadogはmackerelやNewRelicと同じく専用のAgentをサーバーで動かすことでメトリクスを取得します。詳しくは以下のURLを確認してください。
Agentは
- Linux上で動くパッケージ
- Dockerイメージ
二種類から選ぶことになります。理由は後述しますが、Dockerの監視をする場合はDocker版のAgentを使うことを強く推奨します。
Agentを動かし始めると、AgentがDatadogにデータを送信しDatadog側がサーバーを認識する仕組みになっています。
システムのメトリクスのほかにもちろんですがミドルウェアのメトリクスを取ることもできます。ミドルウェアのメトリクスを取るには基本的には*2設定を追加するだけで大丈夫です。どういったミドルウェアのメトリクスが取れるのかは以下を確認していただければわかりますが、かなり広範囲をカバーしています。
Docker自体のメトリクスを取得する
DatadogでDockerのメトリクスを取得するにはDocker integrationを使用します。
Docker自体のメトリクスを取得するには前述の通り設定を追加と有効になります。ただし、Docker版のAgentを使った場合はデフォルトで有効になっています。
このintegrationを導入すると
- コンテナのCPU使用率
- コンテナのメモリ使用率
- 動いているコンテナの総数
などが取れます。
また以下のようなかっこいいダッシュボードで一覧を確認できるようになります。
Dockerの中のミドルウェアのメトリクスを取得する
Docker自体のメトリクスはともかく、今やアプリケーション自体がDockerの中で動いているのでDockerの中のJVMやミドルウェアのメトリクスが取得したくなります。
ここがDatadogで一番よかったところで、Datadogはテンプレート的な設定を用意すると動いているコンテナのIP等を自動で解決してメトリクスを取得してくれる仕組みがあります。それがAutoDiscoveryです！
このテンプレートは全ての設定で使えるのですが、例えば
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を使って監視します。
ここの説明を読む分に明記されていないと思うのですが、実はDocker版Agentには通常版とJVMを含んだ版があります。
ここを見ると
- latest
- latest-jmx
この2つがあり、latest-jmxでないとintegrationが動きません
3.Datadogの5系のAgentと6系のAgentのドキュメントがぐちゃぐちゃ
よく読んでいないのが悪いのですが、主要バージョンとして5系と6系があるらしくドキュメントも両方あります。 不便だと思ったのは、バージョンごとにドキュメントが独立しているのではなく同じネームスペースに両方のバージョンのドキュメントが混在していることです。
これは気をつけましょうくらいですが、共有のために書いておきます。
Datadogを導入した結果
Datadogを導入した結果、
- 普通のメトリクスが取れるようになった
- ダッシュボードで監視できるようになった
- Dockerコンテナ上のプロセスもいい感じに取得できるようになった
というわけで、いってしまえば当たり前の環境が手に入りました。
こういったサービスの中でDatadogでよかった、というとやはりDocker内のプロセス監視がお手軽だった点です。
また、Dashboardが非常に見やすく満足度は結構高かったです。
地味に嬉しかった点として、細かく欲しい機能が存在したことがあります。
- SAML認証とか
- slack通知とか
- LBとかのネットワーク系とか
個別個別は他のサービスにもありますが、その対応の広さは魅力でした。
まとめ
まとめとしては
DatadogのDocker監視よかったよ！
これに尽きます。
今回導入にあまり時間を使いたくなかったのでフルマネージドで監視するにはかなりありな選択肢だと思いました。
We're Hiring!
この会社に入社してまだ一月と少しですが、早速こういった「やりたい！」を業務で取り組ませていただけました。他にも様々な仕事にチャレンジできる環境です。
逆にやりたいことが沢山ありすぎて手が回りません！一緒に取り組んでくれる方、お待ちしています！
