S3 内のログを Datadog に連携して、Datadog Pipelines で扱ってみる
概要
S3 に出力したログを Datadog に連携して、Pipelines 機能で扱ってみます。
S3 に配置されるログとしては、下記形式の Nginx のアクセスログを扱います。
10.0.1.164 - - [30/Jan/2026:09:55:14 +0000] "GET / HTTP/1.1" 200 615 "-" "ELB-HealthChecker/2.0" "-"
S3 に配置したログの Datadog への連携
Datadog Forwarder 経由で S3 に配置したログを Datadog に連携します。
Datadog Forwarder は AWS から Datadog にログを送信するための Lambda 関数で、公式ドキュメント記載のクイックリンクから CloudFormation スタックを作成して利用できます。
この際、API キーとサイトの指定が必要です。
API キーは Organization Settings から発行可能です。
サイトは US1 なら datadoghq.com、AP1 なら ap1.datadoghq.com になります。
https:// は不要なのでご注意下さい。
CloudFormation スタックの作成が完了すると、 DatadogIntegration-ForwarderStack-xxxxxx-Forwarder-xxxxxxxxxx という名前で Lambda 関数が作成されました。
続いて、ログを保管している S3 からイベントトリガーを設定します。
ここまで完了すると S3 に配置されたログが Datadog 側で確認できるようになります。
Datadog の Pipelines 機能で扱う
この状態だとログメッセージを上手くパースできていないので、HTTP ステータスも上手く認識できていません。
Pipeline 機能のページに移動します。
Nginx 用のパイプラインは設定されていましたが、Datadog エージェント経由では無いためにサービスタグが付与されておらず、上手く認識できていないようです。
Pipeline Scanner で確認した所、S3 アクセスログとして処理されていることがわかりました。
Datadog ではインテグレーションパイプラインライブラリが存在して、各ログフォーマットを扱うための処理が予め定義されています。
「Once Datadog receives the first log with the corresponding source, the installation will be automatically triggered.」と記載されている通り、該当ログが検出されたら自動で追加されます。
ただし、この形でインストールされたパイプラインは編集することができません。
今回は FILTER 条件を編集する必要があるため、Nginx 用のパイプラインをクローンして、S3 から連携されたログが上手く認識されるようにします。
クローンすれば、編集できるようになります。
FILTER 条件を host:バケット名 に変更して Update をクリックします。
この状態だと、作成した Nginx 用のパイプラインと S3 アクセスログ用のパイプラインの両方にマッチします。
S3 アクセルログ用の FILTER 条件を書き換えても良いですが、今回は利用していなかったので無効化します。
これで作成したパイプラインにのみマッチするようになりました。
良い感じにパースできています。
Status Remapper が設定されたので、HTTP ステータスコードによる重要度の識別もできるようになりました。
インデックスするログを選択する
続いて、ヘルスチェック用のリクエストはインデックスしないようにします。
より詳細には user-agent が ELB-HealthChecker/2.0 であるものはインデックス化しないよう設定します。
@http.useragent:ELB-HealthChecker/2.0 でフィルタリングして、インデックス化から除外します。
設定後、ヘルスチェック用のリクエストがインデックス化されないようになりました。
最後に
今回は Nginx のアクセスログを扱いましたが、その他のログ形式でもインテグレーションパイプラインライブラリで公開されているパイプラインからクローンして、FILTER 条件を変更すれば簡単に扱うことができます。
是非試してみて下さい！
