【実務・中級編】Datadogコスト削減の技術:高騰するカスタムメトリクスとログ料金を抑える5つの対策 – 運用監視・オブザーバビリティ活用バイブル

Datadogの「底なし沼」から脱出せよ:コストを最適化し、オブザーバビリティの密度を高める5つの禁断の技術

Datadogは素晴らしい。だが、その便利さゆえに「とりあえず全部送る」という運用を続けていると、月末に届く請求書を見て震えることになる。エンジニアの生産性を高めるためのツールが、予算を圧迫して開発リソースを削る本末転倒な事態は避けなければならない。

私はこれまで数々の大規模システムのオブザーバビリティを設計してきたが、コスト削減の本質は「節約」ではなく「データの純度を高めること」にある。ノイズを排除すれば、アラートの精度は上がり、調査時間は短縮され、結果としてコストも下がる。

現場で即戦力となる、Datadogの「コスト最適化」と「生産性向上」の極意を伝授しよう。

—

1. カスタムメトリクスの「解剖」と「カーディナリティの死刑宣告」

コストの最大の敵は、無制限に増え続ける「カーディナリティ(タグの組み合わせ数)」だ。例えば、ユーザーIDやリクエストIDをタグに含めるのはアンチパターン中のアンチパターンである。

対策:

  • Metric Summaryでの特定: `Metrics > Summary` から、単位時間あたりのデータ点数(DPM)が高いメトリクスを特定せよ。
  • タグの正規化: コンテナIDやUUIDのような動的な値を含むタグは、Agentの設定で `tag_cardinality: low` に設定するか、あるいは `dogstatsd` の送信前で正規化(バケット化)せよ。

2. ログの「インジェスト・フィルタリング」の真髄

全てのログをDatadogに送る必要はない。`INFO`レベルのログを全量保管するのは、宝くじのハズレ券を金庫に保管するようなものだ。

対策:
Agentの `conf.d/datadog.yaml` で、`log_processing_rules` を使い、インジェスト前に不要なログを捨てろ。

logs:

  • type: file

path: /var/log/app/access.log
service: my-app
source: python
# 200 OKのログは解析不要なら弾く(コストを劇的に下げる)
log_processing_rules:

  • type: exclude_at_match

name: exclude_200_logs
pattern: “.HTTP/1.1\” 200″

3. 分散トレーシング(APM)の「インテリジェント・サンプリング」

APMは強力だが、100%サンプリングは富豪の遊びだ。重要なのは「エラーログ」と「レイテンシの高いリクエスト」を確実に残すことである。

設定のベストプラクティス(`datadog.yaml`):

apm_config:
# デフォルトのサンプリングレートを下げつつ、ルールベースで制御
sampler:
rules:
# 500エラーは100%保持する

  • name: “Keep 500 errors”

sample_rate: 1.0
match:

  • error: 1

# 正常系は5%のみ保持(統計的に十分)

  • name: “Keep 5% of healthy requests”

sample_rate: 0.05

4. チームの生産性を底上げする「神設定」

生産性を倍速にするキーボードショートカット

  • `g` + `d`: Dashboard一覧へジャンプ
  • `g` + `m`: Metrics Explorerへジャンプ
  • `t`: 時間範囲のクイック選択
  • 「/」キー: コマンドパレット。これを使わずに画面遷移しているエンジニアは、今すぐ癖を直すべきだ。

必須プラグイン・拡張機能

  • Datadog Helper (Browser Extension): ブラウザから現在表示しているページの情報をDatadogへ飛ばす際のコンテキスト切り替えが劇的に楽になる。

—

5. チーム開発における「設定の共有化」ルール

Datadogの設定が属人化すると、誰も修正できず「幽霊ダッシュボード」が乱立する。

1. Terraformによる管理: ダッシュボードやモニターは手動で作るな。`datadog_monitor` リソースとして定義し、Gitで管理せよ。コードレビューを通すことで、不要なモニターが作られるのを未然に防げる。
2. タグの共通規約: `env`, `service`, `version` は必須。これを守らないリソースは「警告」を出すモニターを設置せよ。
3. 「削除の儀式」: 四半期に一度、オーナーが不明なモニターとダッシュボードを削除する「ハウスキーピング・デイ」を設ける。

—

まとめ:賢いエンジニアは「データ」を選別する

オブザーバビリティとは、単に可視化することではない。「何を見ないか」を定義することこそが、最高峰のエンジニアの仕事だ。

コスト削減は、単なる節約ではなく「ノイズの除去」である。ノイズが消えれば、障害の予兆はより鮮明に浮かび上がる。今日から設定ファイルに手を入れ、あなたの監視環境を「コスト効率の良い、鋭利な刃物」へと進化させてほしい。

何か特定の技術スタック(Kubernetes, Serverless等)での詳細なチューニング方法が知りたい場合は、またいつでも聞いてくれ。現場で磨いた技術を惜しみなく提供しよう。

タイトルとURLをコピーしました