1. はじめに：この記事にかいてあること
こんにちは、京セラコミュニケーションシステム（KCCS）の横辻です。私たちの部門では、SnowflakeやAWSなどのクラウド基盤に対して、Datadogを活用した運用監視設計やデータの可視化を行なっています。このブログでは、実務で得たナレッジやAI活用Tipsを中心に発信していければと思います。
今回は、データ分析基盤の監視を提供しようとした際に、運用上の課題に直面したため、その解決方法を紹介します。
Datadogのメトリクスアラートで他ソースを結合(JOIN)して通知内容をリッチにしたいと思ったことはありませんでしょうか。その解決策として、真っ先に思い浮かぶのが『リファレンステーブル（Reference Table）』を活用したデータの紐付けかもしれません。
結論から述べますと、2026年2月現在、Datadogの標準機能では以下の状況です。
- ダッシュボード : メトリクスと他ソース(リファレンステーブル)の「JOIN」が可能。
- モニター（アラート）: メトリクスとリファレンステーブルの結合は未対応。
つまり、可視化する分には標準機能で足りますが、「アラート通知に付加情報を載せたい」というニーズを満たすには、一工夫必要です。
本記事では、メトリクスアラートを一度ログAPIへ「ループバック」させることでアラート通知への情報の後付けを実現した方法を共有します。
※本記事に掲載する設定値や構成は、一般化したサンプルに置き換えています。
背景
SnowflakeとDatadogをAgentlessインテグレーションで接続し、SQLを用いたカスタムクエリでQUERY_HISTORYなどのメトリクス監視を行っていました。運用の高度化にあたり、モニター通知にSnowflake側のテーブルには存在しない「処理ID」を紐付ける必要性が生じましたが、以下の2つの壁に直面しました。
- データの制約: 本番稼働中のDB（Snowflake）に対して、監視都合でカラム追加やVIEW変更を行うことは、影響範囲や管理コストの観点から困難である。
- 機能の制約: Datadogのメトリクスモニター単体では、外部のリファレンステーブルから「処理ID」をキーに情報をJOINする機能がサポートされていない。
2. 現場の課題：モニターにおける「JOIN不可」の壁
監視対象と制約条件
- 対象: Snowflakeにおけるquery_historyに記録された、ある処理の失敗検知。
- 監視ツール: Datadog（Snowflake Agentlessインテグレーションによるカスタムメトリクス監視）。
- 制約: Snowflake側のテーブル/ビュー定義は変更不可。
メトリクスとリファレンステーブルの結合はダッシュボード上では実現できます。しかし、モニター機能で実装することは出来ません。そして、通知に「処理ID」を載せるためには、メトリクスモニターの枠を超えたアーキテクチャが必要でした。
3. 解法：メトリクスをログへ「転生」させるループバック構成
「モニターでできないなら、ログの機能を使えばいい」 と思いついたのが、今回のループバック構成です。
アーキテクチャの概要
- Metrics モニター: Snowflakeの異常を検知。
- Webhook: Datadog自身の「Log Ingestion API」へ、必要な変数をJSON形式でPOSTする。
-
Log Pipeline: ログとして投入されたデータをパイプラインで処理。
- Lookup Processor (Reference Table): ログ内のIDをキーに、リファレンステーブルから「処理ID」をマッピング。
- Log Monitor: エンリッチメントされたログをトリガーに、Slack等へ最終的な通知を行う。
（※本画像はNotebookLMを利用して生成しました）
※重要※
本構成では、Log Ingestion(取り込み)コストが発生します。特に高頻度で発生するメトリクスモニターに適用すると、予期せぬ課金につながる可能性があるため、サンプリングやLog Pipelineのフィルター機能、Index機能を活用し必要なアラートのみをログ化する設計が肝要です。
4. 実装詳細
メッセージ欄サンプル
{{#is_alert}}
テーブル名：{{table_name.name}}
エラーコード：{{error_code.name}}
@webhook-loopback_to_log
{{/is_alert}}
Webhookによる「ログの再定義」
メトリクスモニターの通知先にWebhookを指定し、Datadog自身の「Log Ingestion API」へPOSTリクエストを送信（ループバック）します。
Webhook設定例
-
Payload例:
Log APIに送りたい内容を入れます
{
"ddsource": "monitor_loopback",
"ddtags": "$TAGS",
"message": "$TEXT_ONLY_MSG",
"service": "alert_enrichment_bot",
"title": "$EVENT_TITLE"
}
-
CUSTOM HEADERS:
DD-API-KEY をセットし、認証を通します。
{
"DD-API-KEY": "xxxxxxxxxxxxxxxxxxxxxxxxx",
"Content-Type": "application/json"
}
ログパイプラインでのエンリッチメント
取り込まれたログに対し、Grok ParserとLookup Processorを適用します。特定の属性をキーに、CSV(リファレンステーブル)から「処理ID」をログ属性として付加します。これにより、最終的な通知メッセージ内で {{@process_id}} のように変数が使えるようになります。
Grok parser
Lookup Processor
ローカルからCSVアップロードのほか、各クラウドサービスとの接続も可能です。
Reference table
Snowflake上の元データには含まれない「処理ID」を結合することで、後続のLogモニターで利用可能なフィールドとして使用可能になります。
最後に、情報付与されたログを検知して、実際に通知を送る「Log Monitor」を作成します。ここで、Reference Tableから取得した「処理ID」を通知メッセージに埋め込みます。
メッセージ設定例
{{#is_alert}}以下の処理でエラーが発生しました。対応をお願いします。
処理ID: {{@process_id}}
エラーコード: {{@error_code}}
@slack-my-team-channel
{{/is_alert}}
想定通りに通知（処理IDが含まれていること）が確認できれば、実装は完了です。
注意（制限）
ログモニターにはグループ化による制限があります。例えばグループ化の上限である4つのファセットを使用する場合、ログモニターは各ファセットにつき上位5つの値のみを評価できます。仮に条件に一致するログが6件あった場合、上位5件しかトリガーされないことになります。
これを防ぐためには、①ファセットを減らす②ログからカスタムメトリクスを作成し、再度メトリクスモニターを作成するなどの検討が必要です。構成がさらに一段階複雑になるため、本記事では省略しております。
参考：ログモニター > 検索クエリを定義する
まとめ
「ダッシュボードではJOINできるのに、モニター通知ではできない」壁も、ログ機能へのループバックを組み合わせることで乗り越えることができました。
一工夫必要ですが、その分、運用の質を大きく向上させる強力な手段です。同様の課題を抱えている方の参考になれば幸いです。
弊社では、DatadogやMSPサービスを用いて、現場で日々直面する課題を技術の力でどう解決していくかを今後も継続して発信していきます！
参考URL
https://docs.datadoghq.com/ja/metrics/reference_table_joins_with_metrics/
https://docs.datadoghq.com/ja/reference_tables/
https://docs.datadoghq.com/ja/service_management/events/pipelines_and_processors/lookup_processor/
https://docs.datadoghq.com/ja/integrations/webhooks/
https://docs.datadoghq.com/ja/monitors/types/log/
https://biz.kccs.co.jp/service/operation-maintenance/