はじめに

皆さんロギングやモニタリングのツールとして何を使ってますか？
自社ではDatadogを活用しています。ログのみならず、AWSやGCP等から収集したインフラメトリクス、さらにはトレースデータの可視化にも利用しておりシステム運用のツールとして必要不可欠な存在となっています。
ただ一点頭を悩ませている課題として、増加するDatadogコストの最適化がありました。
この記事では、その中でも特にログ周りで取り組んだアクションについて共有できればと思います

ログコストの課金体系について

公式ページにまとまっていますが、ログ利用に関する課金体系としては大きく2つあります。

ログの取り込み
Datadogへingestされる全てのログが対象となります。2024年4月時点で0.13$/GBとなります。
基本的にDatadogへ取り込まれた後でのコスト削減が不可となるため、ログ量を事前に最適化することが必要です。また、Rehydrateを利用したアーカイブログの復元においては、スキャン対象のログ量を減らすなどの工夫が必要です。
ログの保管、復元
Datadogへ取り込まれたログの保持に関するコストとなります。保持期間によって金額が異なりますが、いずれも100Mログイベント/月となります。
こちらのコストを抑えるには、インデックス対象のログイベント数を削減するか、保持期間を短くする等の対策が考えられます。

アクション1: ログ取り込み量の削減

Datadog展開初期においては、取り込み対象のログの精査を行なっておらずアプリケーションから吐き出されるログを全てDatadogへ送っていました。
この構成の場合、アプリケーションがスケールした場合線形的にログ量も増加してしまっていたため、Datadogで可視化が必要なログのみをDatadogへ送るように見直しを行いました。
自社ではログ転送のソフトウェアとしてfluentdを利用しており、application -> fluentd -> Datadogといった経路でDatadogへのログの転送を行っていました。

fluentdにて本番環境におけるdebugレベルのログ等、取り込みが不要なものはDatadogではなくS3等外部ストレージに保管し、本当に必要になった場合のみ取り出す構成へと変更しました。

アクション2: 環境毎のログ保持期間の見直し

自社ではセキュリティガバナンスを強化するために、本番と開発環境で異なるDatadog organizationを利用していました。
その際、ログの保持期間についてはそれぞれの環境で一律15日間としていましたが、開発環境においては長期間のログの保持が不要と判断し7日間の保持期間へ変更することで保管に関するコストを削減しました。

この点については後述するログのアーカイブ化を併用することで、7日以前のログもDatadog上で復元ができるようになりました。

アクション3: 不要なログインデックスの削除

必要最低限のログのみDatadogへ転送されていれば、ログイベント数も削減されるため、保管に関わるコストも最適化できるはずかと思います。ただし、Datadogの展開当時はfluentdの設定だけでは開発者によって設定濃度にバラツキがあり、うまくログ保管に関わるコストが最適化できていませんでした。

このような場合でもLog explorerを利用することでログメッセージパターン毎のイベント数の分析を行い、不要なログについては保管対象から除外することとしました。

Search画面Group infoからpatternsをクリックすると、ログパターン毎のイベント発生件数を調べる事ができます。検索条件として、ログレベルやtag情報等が利用できます。これらの条件で発生頻度が多く、かつ障害調査にもあまり利用されていないログパターンをindexの除外対象として、保管コストを削減しました。

index除外設定としては、サイドパネルのLogs -> Manage Log Retentionから対象index(デフォルトではmain)のAdd an Exclusion Filterをクリックします

設定画面から除外対象のログパターンを入力します。また、どの程度の割合を除外するかのパーセンテージ指定も可能です。

アクション4: 長期ログのアーカイブ化

保管期限を過ぎたログをDatadogへ復元したい場合Rehydrateを利用する事で可能です。
この機能を利用することで、DatadogへingestされたログをS3やGCS等の外部ストレージに長期保管ができ、必要に応じてそれらのログをDatadogへ復元する事が可能です。

このアーカイブ化されたログはインデックス除外の影響を受けないため、通常時はログの保管を行わないが、障害調査の際にだけ復元したいといったケースにも有効です。

一点ログ復元の際の注意点として、復元対象のログをqueryでフィルタする事が可能ですが、scan対象についてはフィルタが不可（対象archiveの検索対象期間全てのログが対象となってしまう）となります。

例えば単一のアーカイブに全てのシステムのログを集約してしまうと、復元時に単一システムのログが欲しい場合だけでもscanは全てのアーカイブログが対象となってしまいます。
TB単位のscanが発生した場合、復元時のコストも馬鹿にならないので、query条件を定義してログボリュームに応じた複数archiveへ分散させるような設定を行うことを推奨します。

削減効果とまとめ

これらの取り組みを継続的に行なった結果、実施前と比較して4-5割程度のログコストを削減することができました。しかし、一時的な対策にならない様に、ログボリュームに関する監視設定を入れる等継続的にコストを抑えられるようにしていきたいと思います。