ハマりやすいDatadogのログ・メトリクスの料金について改めてまとめてみた

はじめに

本投稿は、Datadog Advent Calendar 2023 の12/8の記事になります。

Datadogの料金体系については公式サイトで丁寧に説明されてはいるものの、検索するとハマり記事が多く出てくるように実際に自分で運用してみないとわからない落とし穴的なポイントも多いなと感じたため、この機会に改めてまとめてみることにしました。

想定読者 / 免責事項

この記事は主に以下の方を想定して書かれています。

• Datadogを利用したことがある、基本的な機能についてある程度の知識がある
• Datadogの利用や導入にあたってコア機能のコストを改めて確認しておきたい
• 小〜中程度の利用規模（Proプラン、月間数百〜数千ドル程度）

Datadogの機能についての紹介は省略しているためあらかじめご了承ください。
内容は運用の実体験や公式サイトの情報を踏まえた上で正確なものとなるよう心がけていますが、大規模な利用を含む特定のユースケースに関して必ずしも適用されない内容が含まれている可能性があることにご留意頂き、実際の運用の際にはご自身での情報収集をお願いいたします。

Datadogの料金体系

Datadogの料金体系は公式サイトで確認することができます。主なポイントとしては、

1. 完全従量課金制であること
2. ベースのホスト数課金に加え、サービスごとの追加料金がある
3. 追加料金の料金体系はサービスごとに異なる

という点が特徴です。

料金は使用したリソース分に対してのみ課金されます。ベースとなるのは Infra Host で、Agentをインストールしたサーバーの台数に応じて料金が決まります。

プランとしてFree, Pro, Enterpriseの3つが用意されています。Proが多くのユースケースにマッチするプランになると思いますが、100台以上の大規模利用になるとEnterpriseプランを契約することで高度な機能やサポートが利用可能になります。

加えて、幅広く用意されている付帯サービスを利用する場合は、サービスとその利用量に応じた追加料金が合算されます。パブリッククラウドの料金体系に近い感じですね。

利用にあたっては、各サービスの利用料金のページを事前によく確認し、想定しているユースケースに対して金額が予算に収まるかどうかの見積もりを行うことが肝要です。しかし、その機能の全体像をある程度理解しないと実際にそれぞれの数字がどう計算されるのか、特にサービス導入初期はイメージが湧きづらい部分もあるのが難しいところです。

この記事では、特に利用機会が多く、その割に料金の計算方法がやや複雑な2つの機能としてログとメトリクスについて解説していきます。

メトリクス

まずはメトリクスからです。
Datadogでは、各種インテグレーションが備えているビルトインのメトリクスに加えて、ユーザーが独自に定義するカスタムメトリクスを利用することができます。KPIに関連する値などアプリケーションに固有な指標を計測したいときに便利な機能です。

ポイント

• タグの一意な組み合わせ数（=メトリクス数）が、課金の単位となる
• 送信したデータ量、送信回数は料金に影響しない
• 月間のメトリクス数は、各時間の合計メトリクス数を月間に渡って平均した値として計算
• 100メトリクスごとに5ドル
• HistogramやDistributionタイプのメトリクスは5倍で計算
• 1ホストにつき100メトリクスの無料枠が存在する

説明

計算方法に関する詳細は公式ドキュメントに説明されています。

送信データ量ではなくタグの組み合わせ数に対してカウントされるのが最大の特徴です。
公式ドキュメントの例を使って説明すると、例えばAPIエンドポイントのレイテンシーをカスタムメトリクスを使って計測することを考えた場合、

• host:A、endpoint:X、status:200
• host:B、endpoint:X、status:400
• host:B、endpoint:X、status:500
• host:B、endpoint:Y、status:200

という4つのタグの組み合わせが記録されると、4メトリクスとして計算されることになります。
これを1時間あたりで合計が1ヶ月に渡って平均された値が月間のメトリクス数となり、100メトリクスあたり5ドルの料金がかかります。

タグが固定されており、かつそれぞれの組み合わせが時間によらず満遍なく発生する場合、このメトリクスに対する月間のカウントはそれぞれのタグのとりうる値の種類を掛け合わせたものとして概算することができます。つまり、上の例ではそれぞれhost = {A, B}、endpoint = {X, Y}、status = {200, 400, 500}がタグの値として考えられるため、月間のメトリクス数は 2 * 2 * 3 = 12 としてざっくり計算することができます。

ただし、時間ごとにカウントが平均されるため、常に送信されるメトリクスでない場合はその分割り引いて計算されることになります。例えば1日ごとに実行されるバッチ処理に対して毎回120のメトリクスが発生する場合、月間のカウント数は24時間に1回に希釈されて 120 / 24 = 5 として計算されることになります。

メトリクス数の計算方法のイメージ。実際はこの平均が月間に渡って計算される。1時間ごとにユニーク数が計算されるため、一部の時間帯でしか出現しないメトリクスは合算ではなく希釈されてカウントされることに注意

その他、細かい補足として次が挙げられます。

• HistogramやDistributionタイプのメトリクスに対しては、count/sum/min/max/avg それぞれに対して別のメトリクスが生成されるため、カウントが5倍がけで計算される
• 1インフラホストに対して100のカスタムメトリクス枠が付与されるため、従量課金の対象となるのはこの無料枠を超えた分に対してのみ

通常の使い方をしていれば、インフラホスト数に対する無料枠があるので追加料金がかからない場合も多いと思います。ただし、使い方を間違えて無邪気にタグをつけまくった場合、一気にメトリクス数が激増し破滅的な額の請求につながる可能性があるため注意して利用する必要があります。

イベントのカーディナリティが高く細かい粒度で分析を行う必要があるようなデータに対しては、後述するようにログの方が適している場合が多いです。メトリクスはあくまで全体の傾向を示すための粒度の粗いサマリーに用いるもの、メトリクスを使う場合はタグは最低限のものに絞る、と覚えておくのが良さそうです。

ログ

続いてログについてです。
システムを運用していくにあたってログは欠かせないものです。Datadogではログに対して検索はもちろん、タグごとのグルーピングやフィルタリングを用いた可視化、スタックトレースに基づいた自動グルーピング (Error Tracking)など幅広い機能がサポートされており、使いこなせると強力なツールになります。

クラウド組み込みのログソリューションに比べると料金はややお高めにはなりますが、後述するようにインデックス化するログを絞ることで料金のコントロールもできるため、特に重要度の高いログのみDatadogに取り込んで分析するなど柔軟に運用していくことができます。

ポイント

• ログの取り込みが1GBごとに0.10ドル
• ログのインデックス化が14日間保持の場合100万イベントにつき1.70ドル（オンデマンドの場合、1.5倍）
• Rehydrate機能を使った場合、スキャン（取り込み）とインデックス化にそれぞれ同様の料金がかかる

説明

公式サイトの情報はこちらから確認できます。

こちらは料金体系はシンプルではあるものの、Datadogのログ機能の全体像について理解する必要があるのが難しいポイントです。

このページにある通り、Datadogではログの取り込み (Ingest) とインデックス化 (Index) を分離することで、パイプラインを利用した柔軟なルーティング制御ができるようになっています。ここで、

• Ingest: 外部から送信されたログをスキャンし、ルーティング先を決定する
• Index: インデックスを作成し、Datadogのコンソールから検索できる状態で一定期間保存する

です。インデックス以外のルーティング先としては、メトリクスとして集計したり、クラウドストレージを使ったアーカイブへの保存を行うことができます。

インデックスされたログはあらかじめ指定した期間Datadogのサーバー上で保存されますが、その保持期間が過ぎた後は削除され検索ができなくなります。
インデックス化についてはこの保持期間に応じて料金がかかり、年間契約の場合3日間で1.06ドル、30日間で2.50ドルが100万イベントごとにかかります。（オンデマンドの場合はさらに1.5倍です）

ハマりやすいポイントとして、デフォルトでは 取り込まれたログが全てインデックス化される という点に注意が必要です。データ保持にかかる料金は比較的高額のため、無邪気に全てのログをインデックス化してしまうと大規模アプリケーションの場合一瞬で数百ドル単位の課金が発生してしまう可能性があります。¹

上の記事や公式ドキュメントでも解説されているように、Datadogのログ管理において推奨されるベストプラクティスとして、

• ログレベルに応じて除外フィルターを設定し、infoなど重要度の低いログは一部だけをインデックス化するようにする
• 取り込みすら不要なログはAgent側の絞り込みで弾く
• ログの重要度に応じてインデックスを複数作成し、異なる保持期間を設定する
• インデックス化しなかったログもクラウドストレージ上にアーカイブしておき、Rehydrate機能を使って必要に応じて後から復元できるようにする

という風に、あらかじめ適切にログパイプラインを構成しておくことが求められます。
具体的な設定方法は公式ドキュメントに詳しく説明されているため、一度目を通しておくと良さそうです。

以上を踏まえたログとメトリクスの使い分け

カスタムメトリクスは概念としても理解しやすく手軽に使いたくなる場面は多いですが、タグの組み合わせに対して課金されるという性質上、要素に分解して細かく分析を行いたいという用途にはあまり向いていません。

ログであれば任意の数設定できるタグ²に対してフィルタリングやグルーピングを行なって可視化することもでき、またログからメトリクスを生成することも可能です。何かの回数をカウントする（Incrementタイプ）という用途でメトリクスを使おうとしている場合は、まずはログを使って要件が実現できないかを検討してみるのが良いかと思います。

メトリクスを使うのは、「トラックしたい最小粒度がイベント数ではなく、全体で1つもしくはホスト数にしか比例しない時」に限るのが安全そうです。

Datadogを安全に使うために

ログに関しては、1日にインデックス化されるイベント数の上限を設定できるため、事前に予算内の値で設定しておくのが安全です。

その他、推定使用量メトリクスを使って課金対象の数値が爆伸びした際のアラートを設定することができます。
最低限よく利用するサービス、特にログとメトリクスについてはアラートを設定しておくのがオススメです。

カスタムメトリクスに対する上限の設定や実際の請求金額に対するメトリクス、テナント全体での予算設定といった機能は現時点では残念ながらサポートされていないようです。

まとめ

• カスタムメトリクスの料金は、データ量ではなくユニークなタグの組み合わせ数によって決まるので不用意にタグを増やさないよう注意
• ログはIngestとIndexでそれぞれ料金がかかるが、Indexが高いのでパイプラインを適切に設定してIndexされるログを絞るのがポイント
• イベント数に比例する粒度で分析したいものにはログを使い、ホスト数比例に収まるものにだけカスタムメトリクスを使う
• 推定使用量メトリクスを使って異変に気づけるようにしておく

参考にした記事

料金体系

メトリクス

ログ

推定使用量メトリクス

1. この状態（ログを絞らず全て取り込む）で運用する場合、Ingest分の料金は免除されるというおまけ要素があるっぽいです。（ソース不明） ↩

2. 同様の要件を達成できる機能としてイベント管理機能もありますが、こちらは2022年6月にアップデートされたばかりの機能のようで2023年12月現在まだベータ版となっています。 ↩