🐶

DatadogのコストアラートTIPS

2024/12/15に公開

はじめに

みなさん、こんにちは!
マネーフォワードでSREをやっているtatsuo48です。
この記事ではDatadogにおけるDatadog利用コストに対するアラート(コストアラート)について書きます。

なぜコストアラートが必要なの?

端的に言うと、Datadogを利用するにあたって、かけたコストに対して最大限の価値を得たいからです。
https://www.docswell.com/s/tatsuo48/5MX1DJ-datadog-cost-optimization-tips#p14

Datadogは従量課金という性質上、課金に対する意識が低い状態で利用すると、想定外の課金につながることがあります。
InfraHostの場合、Datadog Agentが入っていなくとも、AWSとのインテグレーションを有効化しているとCloudWatchMetricsを元に自動的にAWS上のホストを課金対象として認識します。
https://www.docswell.com/s/tatsuo48/5MX1DJ-datadog-cost-optimization-tips#p33

この挙動自体は有用だと思いますが、このような課金体系であることを知らない場合は大きな課金に繋がる場合もあります。以前のことですが、データ連携用に短時間大量のEC2インスタンスが稼働するケースがありました。本来、このケースでは、データ連携の失敗により異常に気付けるため個々のEC2インスタンスを監視する必要はありませんでした。
しかしながら、課金体系の理解が薄く意図せず課金が発生しており、課金額を押し上げる要因になっていました。

課金が発生していたとして、そこから価値を得ることができているなら必要な課金です。しかし、前述の通り残念ながら、この課金増からそれに見合った価値を得ることはできておりませんでした。

では、これを避けるためにはどうすればよいでしょうか?
一つには利用者のコスト意識を高める必要があります。そのためのツールとしてコストアラートが有用だと考えています。
コストアラートがあることで

  • 想定外のコストが発生
  • アラートが鳴る
  • 利用者がコスト増に気づき、課金体系の理解への学びにつながる

という寸法です。

というわけで、ここからは各Datadogサービスごとに分けて、どのようなアラートを設定すべきかTIPSをまとめていきます。

Infra Host

見るべきメトリクスは以下です。
datadog.estimated_usage.hosts

Agent入りのHostに関しては、一時的なスパイクは許容し、直近4時間の平均がしきい値を超えた場合にトリガーされるようにしています。

  • avg(last_4h):sum:datadog.estimated_usage.hosts{host_type:agent} > しきい値

AgentなしのHostですが、こちらも同じく直近4時間の平均に対してアラートをかけています。

  • avg(last_4h):max:datadog.estimated_usage.hosts{host_type:aws} > しきい値

APM Host

見るべきメトリクスは以下です。
datadog.estimated_usage.apm_hosts

比較的スパイクも少なく安定しているため、直近1日の平均を指定しています。環境次第で微調整することをおすすめします。

  • avg(last_1d):max:datadog.estimated_usage.apm_hosts{*} > しきい値

Logs

LogsはIngestedとIndexedにそれぞれ課金されるため、両方に設定しています。

Ingested Logs

見るべきメトリクスは以下です。
datadog.estimated_usage.logs.ingested_bytes

サービス単位でグルーピングし、過去1日、1時間というように2種類のアラートを設定しています。

  • sum(current_1d):sum:datadog.estimated_usage.logs.ingested_bytes{*} by {service}.as_count() > しきい値
  • sum(current_1h):sum:datadog.estimated_usage.logs.ingested_bytes{*} by {service}.as_count() > しきい値

RunBookには以下のDatadog謹製のダッシュボードを乗せています。
https://docs.datadoghq.com/logs/guide/best-practices-for-log-management/#review-the-estimated-usage-dashboard

Indexed Logs

見るべきメトリクスは以下です
datadog.estimated_usage.logs.ingested_events

こちらも同じくサービス単位でグルーピングし、2種類のアラートを設定しています。

  • sum(current_1d):sum:datadog.estimated_usage.logs.ingested_events{datadog_index:*,datadog_is_excluded:false} by {service}.as_count() > しきい値
  • sum(current_1h):sum:datadog.estimated_usage.logs.ingested_events{datadog_index:*,datadog_is_excluded:false} by {service}.as_count() > しきい値

RunBookには上記と同様のダッシュボードを記載しています。

Custom Metrics

使うのは以下の2つです。

  • datadog.estimated_usage.metrics.custom.by_metric
  • datadog.estimated_usage.metrics.custom

各メトリクスに対しては以下のアラートを設定しています。

  • avg(last_30m):sum:datadog.estimated_usage.metrics.custom.by_metric{*} by {metric_name} > しきい値

上記のアラートだけだと、各メトリクスはそんなに上がっていないが、全体感は上がっている際にキャッチできないため、サブ的に以下のアラートも設定しています。

  • avg(last_10m):sum:datadog.estimated_usage.metrics.custom{*} > しきい値

RunBookにはMetric Explorerで以下のクエリを実行した結果のURLを載せています。

sum:datadog.estimated_usage.metrics.custom.by_metric{*} by {metric_name}

まとめ

いかがでしたでしょうか?ぜひ、みなさんのDatadog環境でもアラートの設定を検討してみていただければと思います。
闇雲にコストを減らすだけでなく、コストに対してその価値があるか?をアラートを通して考え、コスト最適化を進めていきましょう🤝

参考資料

Discussion