【イベントレポート】2025/5/28 Japan Datadog User Group Meetup#10


## はじめに

2025/5/28（水）に開催された「Japan Datadog User Group Meetup#10」に参加しましたので、イベントレポートを執筆しました。

https://datadog-jp.connpass.com/event/349693/

[当日の動画はこちら| YouTube](https://www.youtube.com/watch?v=35JcoUB8m6M)

Xハッシュタグ：[#JDDUG](https://x.com/search?q=%23JDDUG)

:::note warn
本記事は個人的なメモを共有する形でまとめておりますので、一部表現が簡略化されている場合があります。ご了承ください。
:::

## アジェンダ

- 発表
  - １. Datadog On-Callを本番導入した話（[公開資料](https://speakerdeck.com/sheepland/datadog-on-cal-now-in-production)）
  - ２. プラットフォームとしての Datadog（[公開資料](https://speakerdeck.com/aoto/datadog-as-platforms)）
  - ３. 無い機能なら作ってしまえ、カスタムメトリック（[公開資料](https://speakerdeck.com/ichirokano2/datadog-wu-iji-neng-narazuo-tutesimae-kasutamumetorituku)）
- 会場スポンサーセッション
  - ４. Datadog RUM 本番導入までの道（公開資料なし）
- LT
  - ５. On-Call 運用Tips([公開資料](https://www.docswell.com/s/WN_Tech-PR/56VPD9-2025-05-28-134350))
  - ６. Auth0ログをEvenrBridge経由でDatadogと連携（[公開資料](https://speakerdeck.com/kubell_hr/250528-yamashita)）
  - ７. Datadog Network Monitoring を活用して NAT Gateway 課金を 80％削減した話（[公開資料](https://speakerdeck.com/fohte/datadog-network-monitoring-wohuo-yong-site-nat-gateway-ke-jin-wo-80-percent-xue-jian-sitahua)）

## 1. Datadog On-Callを本番導入した話

![1-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/1-001.jpg?raw=true)

:::note info
DatadogのOn-Callを選択した理由や、設定方法、運用の工夫について紹介がありました。特に、スケジュール管理やエスカレーションポリシーの活用、通知の最適化について詳しく解説がありました。導入する場合は、予行練習をすることが重要だと言われていました。
:::

- [Datadog On-Call が2025年1月にGAした](https://www.datadoghq.com/blog/this-month-in-datadog-january-2025/#datadog-on-call-is-now-generally-available)
- Datadog On-Call を選択した理由
  - ✅スケジュール管理やエスカレーションポリシーなど必要な機能がそろっている
  - ✅1ユーザーあたり$25のコストパフォーマンス
  - ✅ツールの統一性、Datadogに一元化
- 主な機能
  - 通知先設定：電話、SMS、メール
    - Monitorの通知先は`@oncall-{team名}`で指定
  - [スケジュール](https://docs.datadoghq.com/ja/service_management/on-call/schedules/)：On-Callを受ける日時を設定可能、スケジュールはカレンダーアプリ（Goolgeカレンダー、Outlook）に連携可能
    ![1-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/1-002.jpg?raw=true)
  - [エスカレーションポリシー](https://docs.datadoghq.com/ja/service_management/on-call/escalation_policies/)：On-Callを受けた人が指定時間内で電話に出ない場合、他の人にエスカレーションする
    - 「その日の担当に電話→３分で出ない→全員に電話」といったことができる
- [Datadog Incident Manager](https://docs.datadoghq.com/ja/service_management/incident_management/)との連携
- Analytics
  - On-Callのメトリクスを見ることができる
  - Total On-Call、Mean Time To Acknowledgeなど
- 手動のOn-Callが可能
  - 重大な障害やセキュリティインシデントは検知できないこともある。Slackから即座にOn-Callできる仕組みは初動を早めるのに重要
- 導入にむけて
  - 予行練習をする
    - On-Callは英語音声なので慣れが必要
    - Slackから`/datadog page`というコマンドでOn-Call。事前にSlackとDatadogの連携設定が必要なので予行練習での動作確認は必須！
  - On-Callの運用を各プロダクトチームに任せる
    - スケジュールやエスカレーションポリシーの設定
    - 新メンバーへのオンボーディング
  - ドキュメントを作成する
    - 電話番号の設定方法
    - 電話の受け方
    - SlackとDatadogの連携設定
- 運用Tips
  - On-Callはアメリカから**複数の電話番号**で発信される
  - Datadogモバイルアプリを使うとOn-Callの電話番号がスマートフォンの連絡先に自動登録・同期されるので便利
    - [Set Up Your Mobile Device for Datadog On-Call](https://docs.datadoghq.com/ja/service_management/on-call/guides/configure-mobile-device-for-on-call/?tab=ios)
- まとめ
  - コストは比較的安い
  - GA直後なので機能拡充は今後に期待
  - オブザーバビリティツールに統合されているのがよい
  - On-Callの予行練習はオススメ

## 2. プラットフォームとしての Datadog

![2-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/2-001.jpg?raw=true)

:::note info
開発者がDatadogを活用するための機能（自動計装、動的計装、ソースコード統合など）について解説がありました。Datadogの機能を活用すれば、開発生産性を向上するプラットフォームになることが期待されると言われていました。
:::

- Platform Engineering と Datadog
  - Platform Engineering とは
    - 組織において有用な抽象化を行ない、セルフサービスインフラストラクチャを構築するアプローチ
    - 有用な抽象化：ゴールデンパス
      - テンプレートの提供
      - ドキュメントの整備
      - モニタリング標準化
  - 開発者のためのDatadog
    ![2-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/2-002.jpg?raw=true)
    - 参考資料：JDDUG#3「開発者とマニアのためのDatadog」（[資料](https://speakerdeck.com/aoto/datadog-for-developers-and-geeks)）
    - [自動計装（Automatic Instrumentaition）](https://docs.datadoghq.com/ja/tracing/trace_collection/automatic_instrumentation/?tab=singlestepinstrumentation)：Datadog APM SDK
    - [動的計装（Dynamic Instrumentaition）](https://docs.datadoghq.com/ja/dynamic_instrumentation/)：あとから任意の箇所でプローブを作成できる
      - 参考資料：「DynamicなInstrumentation」（[資料](https://speakerdeck.com/yutakihara/datadog-de-dynamicnainstrumentation-9db32ed6-a86b-408c-a772-8b79dda6caab)）
      - [Live Debugger](https://docs.datadoghq.com/ja/tracing/live_debugger/)
      - [Autocomplete and Search](https://docs.datadoghq.com/ja/dynamic_instrumentation/symdb/java/?tab=%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E5%BC%95%E6%95%B0)
    - [ソースコード統合（Source Code Integration）](https://docs.datadoghq.com/ja/integrations/guide/source-code-integration/?tab=go)：Gitリポジトリと連携
    - [IDE Plugin](https://www.datadoghq.com/product/platform/ides/)：IDEから開発中のコードをDatadogのオブザーバビリティを参照したり連携できる
    - Telemetry without Limits：監視データはすべて送信
  - 「有用な抽象化：ゴールデンパス」→Datadogでは何ができるか？
    - ✅テンプレートの提供
      - [Workflow Automation](https://www.datadoghq.com/product/workflow-automation/) & [App Builder](https://www.datadoghq.com/product/app-builder/)：GitHub/AWSに接続してテンプレートリソース作成のワークフローを準備
    - ✅ドキュメントの整備
      - [Notebooks](https://docs.datadoghq.com/ja/notebooks/)
    - ✅モニタリング標準化
      - [統合サービスタグ](https://docs.datadoghq.com/ja/getting_started/tagging/unified_service_tagging/?tab=kubernetes)：`DD_ENV`、`DD_SERVICE`、`DD_VERSION`
      - [Log Pipeline](https://docs.datadoghq.com/ja/api/latest/logs-pipelines/)：ログは**JSON形式**にすること。効率的にパースできる
  - [Software Catalog](https://docs.datadoghq.com/ja/internal_developer_portal/software_catalog/)
    - 開発者が管理するサービス一覧を集中的に可視化するビュー
  - まとめ
    - Datadogは開発者のプラットフォームとしての機能が豊富
    - Datadogは開発生産性を向上させるプラットフォームとなることに期待

## 3. 無い機能なら作ってしまえ、カスタムメトリック

![3-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/3-001.jpg?raw=true)

:::note info
Datadogには、標準でさまざまなメトリクスがあるが、固有のアプリケーションに特化したメトリクスはない。効率よくアプリケーションを監視するためにカスタムメトリクスを活用した方法を紹介されました。
:::

- きっかけ
  - バックエンドアプリの応答が遅い
  - アプリで使用しているあるTCPポートの接続超過がどうかを知りたい
- ❌特定のポートの接続数のモニタリングはできない
  ![3-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/3-002.jpg?raw=true)
  - `netstat`か`ss`コマンドを使って調べることはできる
  - `ss -ant4 | grep ':22'| grep ESTAB | wc-l`
- [カスタムメトリクス](https://docs.datadoghq.com/ja/metrics/custom_metrics/)を作る方法
  - 公式ドキュメント「[カスタム Agent チェックの書き方](https://docs.datadoghq.com/ja/developers/custom_checks/write_agent_check/)」を参考にする
  - Step1：コンフィグを作る（例：/conf.d/xxxx.yaml）
  - Step2：チェックと送信処理を作る（例：/checks.d/xxxx.py）
    ```python
    self.gauge(
        'custom_tcp.connections',
        int(xxxxxx),
        tags=['host:xxxxxx']
    )
    ```
- 監視アラート
  - アラートはその時点でのステータスしかわからない
    ![3-003](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/3-003.jpg?raw=true)
  - 本当にみたいのはこのような`時系列BAR`ではないか？
    ![3-004](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/3-004.jpg?raw=true)
  - 機能がないので、似たようなものを作成した
    ![3-005](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/3-005.jpg?raw=true)
- まとめ
  - オンライン会議は、カスタムメトリクスを活用することで会議数や参加人数を可視化できた
  - ゲームは、利用者数を可視化できた
  - 監視アラートは時系列BARで可視化できた
- 参考
  - [Jitsi Meet](https://github.com/jitsi/jitsi-meet)〜OSSのWeb会議システム
  - [Datadog カスタムメトリックスの課金](https://docs.datadoghq.com/ja/account_management/billing/custom_metrics/?tab=countrate)
    - メトリクス名とタグ値 (ホストタグを含む) の組み合わせ
  - [Datadogのカスタムメトリクスによる予期せぬコスト増加を回避する](https://zenn.dev/tkaga/articles/291af41d8e43b0)

## 4. Datadog RUM 本番導入までの道

![4-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/4-001.jpg?raw=true)

:::note info
Datadog RUMの導入プロセスを説明から、サンプリングレートの決定方法や、セキュリティ対策としてのデータマスキング、フロントエンドのUX改善への応用について詳しく解説されました。
:::

- Datadog RUMとは
  - Real User Monitoring
  - フロントエンドのパフォーマンスをリアルタイムに監視
    - 画面のレンダリング速度、エラー率、Core web vitals、平均滞在時間、**フラストレーションシグナル**...
  - 基本概念
    - Session：サイトに滞在している間に発生するデータ
    - View：ページアクセスで発生するデータ
    - User Action：ボタンクリックなど
    - セッション数に比例して課金
  - 導入方法：SDKの初期化コードを書くだけで簡単
    ![4-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/4-002.jpg?raw=true)
- なぜ導入したか
  - フロントエンドの可観測性がない
    - 画面が真っ白になるエラーがユーザー問い合わせ以外で気づけない
    - MTTR（Mean Time To Repair：平均復旧時間 / 平均修復時間）の遅延につながる
  - APIレスポンスは早いが画面描写が遅いケースを検知できない
    - UI改善サイクルが困難
- サンプリングレート
  - 本番導入時にはセッション数を見積もる必要がある
  - 先にステージング環境へRUMを導入し、E2Eテストで１セッションごとの平均APIリクエスト数を算出して見積をおこう
  - 予算の範囲内になるようにサンプリングレートを決定
- セキュリティ
  - Datadogにどのレベルまでデータを送ってよいか
    - ❌ユーザーの業務データ
    - ✅事業所ID、加入プラン
  - RUM経由で顧客データが送信されてしまうパターン
    - ボタンのラベルText内容が送信されてしまった。
    - Datadog送信前にマスキングすることで解決
      - ⚠ ただし、過度なマスキングはログ分析できなくなるので注意
- フロントで発生した謎エラー
  - [ResizeObserver](https://developer.mozilla.org/ja/docs/Web/API/ResizeObserver) loop completed with undelivered notifications...
    - 一般的なJavaScriptのエラーでユーザー影響はほとんどないらしい
    - RUM SDKの画面要素監視と自社ウェブアプリケーション（画面の要素サイズ変更部分）の相性問題で発生している
    - RUMを使ってエラー発生とユーザーへの影響（画面描画速度）を調査した
    　![4-003](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/4-003.jpg?raw=true)
      - UXの良さを示す`Core Web Vitals`にも差がない
      - エラー発生有無で画面描画速度に変化はない
- [RUM とAPMは関連付け](https://docs.datadoghq.com/ja/tracing/other_telemetry/rum/?tab=%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6rum)られるので、フロントエンドとバックエンドを一気通貫で分析できる
  - RUM SDKにパラメータを追加することで導入可能
    - allowedTracingUrls
    - traceContextInjection
    - traceSampleRate
- 今後の展望
  - RUMのメトリクスやモニターはSLOに活用できる
  - [複合条件モニター](https://docs.datadoghq.com/ja/monitors/types/composite/)
  - 重要な画面の`Core Web Vitals`をSLI（サービス レベル指標）とするSLO（サービス レベル目標）を作成

## 5. On-Call 運用Tips

![5-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/5-001.jpg?raw=true)

:::note info
Datadog On-Callの運用に関する実践的なTipsを紹介しました。料金の仕組みやSlack連携の活用方法、特定のモニターだけエスカレーションを分ける方法など、運用をスムーズにするための工夫を解説されました。
:::

- [On-Call](https://docs.datadoghq.com/ja/service_management/on-call/)の料金
  - シートに応じた課金
    - シートあたり月額 $25
- シートとは？　≒　オンコールの対象に含まれている人の数（参考：[シートとは何ですか？](https://www.datadoghq.com/ja/pricing/?product=incident-response#incident-response-%e3%82%b7%e3%83%bc%e3%83%88%e3%81%a8%e3%81%af%e4%bd%95%e3%81%a7%e3%81%99%e3%81%8b)）
  - On-Callのスケジュールに含まれている
  - エスカレーションポリシーに含まれている
  - 電話番号登録などの通知設定を有効化している
- Slack連携はオススメ
  - GA前：入電されたら、Datadogの画面から直接`Resolve`ボタンを押すまで電話が鳴り続けた
  - GA後：Slackの画面で`Resolve`できるようになった
    ![5-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/5-002.jpg?raw=true)
    - 現時点では、プレビュー版。SlackとTeamsに対応している。
    ![5-003](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/5-003.jpg?raw=true)
- 特定モニターだけエスカレーション
  - On-Callチームのルーティングで条件分岐
  - タグや優先度でフィルタリング
- まとめ
  - On-Callの料金算出はややこしい
    - 架電対象者が課金対象ということを覚えておく
  - Slack連携オススメ
  - 特定モニターだけエスカレーションができる

## 6. Auth0ログをEvenrBridge経由でDatadogと連携

![6-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/6-001.jpg?raw=true)

:::note info
Auth0のログをAWS EventBridge経由でDatadogに送信し、可観測性を向上させる方法を紹介されました。ログのマスキングや長期保存の仕組み、他のアプリケーションログとの相関分析、アラート設定の工夫について詳しく説明されました。
:::

- 認証に対するログ
  ![6-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/6-002.jpg?raw=true)
  - いつ・だれが・どこで
  - ログインが成功したか、失敗したか。
  - 失敗理由は？
    - Rate Limit？
    - アカウントロック？
  - 異常な行動は？
- Auth0管理画面でもモニタリングできるが、モニターで閲覧できる期間が限定的
  - Datadogで可視化する
  ![6-003](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/6-003.jpg?raw=true)
  ![6-004](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/6-004.jpg?raw=true)
- Auth0のログをDatadogで見られるメリット
  - メトリクスの長期保存
    - 過去のメトリクスも見られるので過去の傾向からの分析ができる
  - 他のアプリケーションログと統合して相関分析
  - アラートが柔軟に設定可能

## 7. Datadog Network Monitoring を活用して NAT Gateway 課金を 80％削減した話

![7-001](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/7-001.jpg?raw=true)

:::note info
Datadogのネットワークモニタリング機能を活用し、AWSのNATゲートウェイの課金を80％削減した事例を紹介されました。トラフィックの可視化により、アプリケーションの通信経路分析が可能であると解説されました。
:::

- [Network Monitoring](https://www.datadoghq.com/product/network-monitoring/) はネットワークコスト削減に活用できる
- NAT Gatewayはコスト高い
  - S3通信だけはGateway Endpoint導入で50％削減した
  - AWSのCost Explorerでは利用料はわかるが、コストの分析には使えない
  - VPCフローログでは膨大なログの分析は難しく、知りたいことの一部しか調査できず、問題解決には至らなかった
    - ドメイン名などで分析したいが、IPアドレスしかない
    - NAT Gateway を経由したかどうかわからない
- Datadogは保存には課金されるが、分析には課金がないのが強み
- Network Monitoring を使うことでボトルネックが特定できた
  - データ分析基盤への送信（40％）
  - BigQueryへの通信（20％）
  - Datadog Agent自体の通信（20％）
  ![7-002](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/7-002.jpg?raw=true)
- Network Monitoringのここが便利
  - NAT Gatewayを経由する通信でクエリ可能
  - 送信元や送信先でクエリ可能
  - 操作性は、普段のDatadogと同じ

![7-003](https://github.com/ishiharatma/public-contents-images/blob/main/jddug-10-20250528/400/7-003.jpg?raw=true)

## その他参考

https://www.event-site.info/ddt2025/

https://speakerdeck.com/nulabinc/techniques-for-a-successful-datadog-trial

https://www.datadoghq.com/blog/user-group-program/