こんにちは。ABEJAのインフラ管理してる村主 @rwle1221 です。

本ブログは Datadog Advent Calendar 2019 の8日目です。今日は ABEJA Platform というプロダクトで、なぜ Prometheus から Datadog に変えたのか。というお話したいと思います。

一人の方でも採用基準の参考になればと思います。

第一フェーズ：実は元々Datadogを使っていた

実は Prometheus の前は Datadog を使っていました。なぜ Datadog を使っていたかというと、Za○bix や Na○ios などは古い思想なので使う気になれなかったという単純な理由です。ただ、 Datadog は $18/host という値段で当初は数十台だったので数万円ほど発生していました。やはり少し高いなという印象です。

第二フェーズ：Prometheus の導入と挫折

Prometheus を使い始めた

2018年にKubernetesを一部で導入し始めました。Kubernetesを監視するならPrometheusがデファクトスタンダードになりつつあったので、 Prometheusも試してみようということでPrometheusも使い始めました。

Kubernetes x Prometheus の情報は非常に多く公開されており、PromQLは非常に書きやすくかなり使いやすいツールでした。

トラブル多発

しかし、言ってもオープンソースなので何かあれば自分でなんとかする必要があります。トラブルが発生したら、サーバの中に入りログを漁りエラーメッセージを探し出し、Webで調べ対応を打つ。そして対策を考えて対処する。

例えば、Prometheus自体が停止したりします。何故なのかを調べていくと、Dockerが落ちてるだけ、だったりディスクがフルで動いてなかったり、OOMで死んでたり、まぁ色々あります。そしてそれが発生しないように何かしら対処を施したり、監視ツールの監視をしたり。多い時は週に1,2回ほど何かが発生し、1,2人が数時間/週ほど取られていました。

こんなことしている場合ではなかった

弊社はスタートアップなのでエンジニアの人数は限られています。大規模な会社のように運用チームがあるわけではありません。 プロダクトを開発し顧客に価値を提供すること本業なので、監視ツールのお守りをすること自体に時間を取られていることが不毛に感じてきました。

こんなことしている場合じゃない。開発に集中したい！ということで、外部の方に委託出来ないか？と少しだけ考えてみました。外部業者に監視をお願いするとだいたいサーバ単位の課金になるので高い。なのでPrometheusに何かあった時に対処・運用してくれるだけで良い。でもPrometheus自体がまだ発展途上なのでノウハウ持ってる人（会社）も多くない。試行錯誤でも良いから誰か運用してくれないかな。

費用は見積ってもらっていないのでわからない。

ふと頭をよぎった。

「Datadog にしたら監視サーバの運用要らないので楽になるんじゃない？」

その時のサーバ台数でいくとDatadogの費用は10万円/月位でした。

仮に Promethes のサーバ台 + 外部へのPrometheus 運用 = 10万円/月 だとしたら（もっとかかると思う）、個人の手を介さないDatadogの方が良くない？と考え始めました。今後規模が大きくなるにつれてPrometheusへの負荷が厳しくなるし、Datadogはすでに大規模で使われているのでPrometheusに比べると安定していそう。そう思い始めましたが、監視ツールの変更の優先度は高くない（開発系タスクの方が優先度高い）ので一旦放置していました。言うても監視はある程度出来ているので

第三フェーズ：ログをどうするか問題

ログどうする

そう思い始めた頃に、アプリやサーバのログをもっと使いやすくする話が出てきていました。その当時は CloudWatch Logs を利用していて、ただの保管場所＋検索できるモノ位でした（今はInsightや色々機能は増えている）。圧倒的に使い勝手が悪く、統計取ったりエラーログを眺めたりする気が起きず、問題起きた時に調べる位でしか使えないモノでした。

じゃあどうしようかなと思った時に、Prometheusはログを収集する機能がもちろんないので、その時のデファクトである ElasticSearch + Kibana が頭の中で候補にあがりました。

まず極一部のログを可視化したい。ということでその時点で 5億/月位のデータ量がありました。その後に徐々に対象となるログを増やそうと思うと、数ヶ月毎に倍々で増えていくのが見えていて、且つサービスも成長していくので、1年で数倍、2年でさらに数倍。みたいな感じが想定されました。

それを ElasticSearch で受けながら運用することを想像すると、手が取られそう感が半端なかったです。

何度もいいますが、弊社はスタートアップなのでエンジニアの人数は限られています。出来るだけ開発に集中したい。

そして思い出したのです。そういえば Datadog が Log のサービスを提供し始めていたな。どうせモニタリングも Datadog に変えたいなーとか思っていたので、まずは Datadog の Logs を試してみるか。となりました。

Datadog Logs

結論から言うとかなり使いやすいです。Datadogの中で一番好きなサービスです。ちょっとだけ機能を解説します。

facets

facets という機能は、要はIndexです。そして Index はDatdogに自動で付与されるタグやログのKeyや自分で付与した任意のメタデータを対象にできます。

f:id:xwkns157:20191208142914p:plain:w250

中身までは公開できませんが、ログに出力されている Attribute を Index することもできるので、User Agent や Tracing ID、HTTP Methodなどを対象にすることもできますし、AWSのタグ（AZ, Instance ID）、Kubernetesのラベル（Service, Deployment Nameなど）もIntegrationすれば自動で付与され、それを Index することもできます。

以下のように Create Facets for xxx を選択するだけで Index してくれます。 Indexにあたり、メモリやストレージのパフォーマンスを気にしなくて良いのはかなり良いです。かなり多用しています。

f:id:xwkns157:20191208143822p:plain:w250

しかも、select box で絞り込んでいけるのもわかりやすいですね。絞り込んでいくにつれて「どこが何件ある」というのも可視化されています。

f:id:xwkns157:20191208144115p:plain:w250

導入方法の簡単さ

Datadog Logs の導入のシンプルさも良かったです。

Datadog Logs は Kubernetes の場合、 datadog-agent を daemonset としてデプロイし、その中でパラメータを変更するだけで収集してくれます。簡単ですね。その他でも 1コマンドでインストールし、少し設定ファイルを弄るだけです。

    - name: DD_LOGS_ENABLED
      value: "true"
    - name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
      value: "true"

ref: https://docs.datadoghq.com/ja/agent/kubernetes/daemonset_setup/?tab=k8sfile#log-collection

Fluentd もインストールするだけなら楽なのですが、パースする処理やどこに投げるか、バッファリング、リトライなどは全部自分で個別のサーバに設定したり自分で展開して回ったりする必要があります。

Datadog Logs は「とりあえず、まずログを投げてくれ。あとは Datadog 上で設定できるから」という思想です。なので、上のパラメータを渡すだけで Kubernetes 上の全 Pod のログを収集してくれます。そしてパースやマッピングなどの処理は Datadog 上で行うので、多数のサーバに展開する方法（AnsibleやChef、UserData）などを意識する必要はありません。

コスト

「一旦全部ログを投げたらめっちゃ高くなるんちゃうん？」という声が聞こえてきそうですが、そこは Datadog の良いところ。

Datadog Logs には Indexs という機能があり、その中でログのフィルタを行うことができます。そこで除外したログは課金対象に含まれないため、「一旦ログを全部投げてー」ということが成り立つわけです。割合も弄れるので、90%除外で10%だけサンプリングするようなコストコントロールをすることもできます。

f:id:xwkns157:20191208150239p:plain:w400

Datadog としては、Ingressのスケーラビリティ分だけ大変でしょうけど、入り口の設定の複雑さ、設定手間などのハードルを出来るだけ下げて、「まず使って欲しい。簡単で便利だから」ということなのでしょう。まんまとハマってしまいました。

さらに Archives という機能があり、Datadog Logs に収集したログをS3/GCSに保存することができます。これは Indexs でフィルタかけたログも残っているので、何かあれば Athena とかで見ることもできます。

なお、Datadog Logs の課金体型は以下を、何日残すか（7日間、15日間、Other）、一定量コミットするかにより変動します。

Datadog Logs への転送レコード数
Datadog Logs への転送量

参考までに、CloudWatch Logs より 1/4-5位のコスト感になりました。

ログをどうするか問題の結論

試した結果、Facets が強力で、導入が楽、コストコントロールもしやすく、何かあれば全ログを追える。その上で、ログ収集する上でインフラを気にしなくて良いのが気に入り、徐々にログを Datadog Logs に寄せました。

第四フェーズ：Datadog Logs と共に Promethes から Datadog へ移行

Datadog Logs は datadog-agent を前提としていますので、datadog-agent をインストールしログオプションを有効にすることで利用可能になります。

そのため、Datadog Logs を導入と共に、モニタリングも Prometheus から Datadog に切り替えていきました。

なぜPrometheusを辞めてDatadogを採用したのか、のまとめ

ログもモニタリングも それが事業のコアであればちゃんと構築し運用すること自体は厭わないのですが、コアでないなら時間を割きたくない というのが Datadog の一番の採用理由です。

もちろん問題が全く起きないかと言うとそうではないですが、今は数百台からメトリクスとログを投げています。事業の成長と共に Prometheus / ElasticSearch をスケーラブルに構築、運用することも可能ですが、ある時点を境に 「シャーディングだ」とか「抜本的に構成を変えよう」 とかになっていたと思います。そうするとそれなりの工数は割く必要があったりするので、多少の問題はもちろん起こりつつも、基盤の部分をマネージドされているのは非常にありがたいです。