LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@issy929

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

Last updated at Posted at 2025-05-31

はじめに

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

当日の動画はこちら| YouTube

Xハッシュタグ：#JDDUG

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

アジェンダ

  • 発表
    • １. Datadog On-Callを本番導入した話（公開資料）
    • ２. プラットフォームとしての Datadog（公開資料）
    • ３. 無い機能なら作ってしまえ、カスタムメトリック（公開資料）
  • 会場スポンサーセッション
    • ４. Datadog RUM 本番導入までの道（公開資料なし）
  • LT
    • ５. On-Call 運用Tips(公開資料)
    • ６. Auth0ログをEvenrBridge経由でDatadogと連携（公開資料）
    • ７. Datadog Network Monitoring を活用して NAT Gateway 課金を 80％削減した話（公開資料）

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

1-001

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

  • Datadog On-Call が2025年1月にGAした
  • Datadog On-Call を選択した理由
    • ✅スケジュール管理やエスカレーションポリシーなど必要な機能がそろっている
    • ✅1ユーザーあたり$25のコストパフォーマンス
    • ✅ツールの統一性、Datadogに一元化
  • 主な機能
    • 通知先設定：電話、SMS、メール
      • Monitorの通知先は@oncall-{team名}で指定
    • スケジュール：On-Callを受ける日時を設定可能、スケジュールはカレンダーアプリ（Goolgeカレンダー、Outlook）に連携可能
      1-002
    • エスカレーションポリシー：On-Callを受けた人が指定時間内で電話に出ない場合、他の人にエスカレーションする
      • 「その日の担当に電話→３分で出ない→全員に電話」といったことができる
  • Datadog Incident Managerとの連携
  • 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の電話番号がスマートフォンの連絡先に自動登録・同期されるので便利
  • まとめ
    • コストは比較的安い
    • GA直後なので機能拡充は今後に期待
    • オブザーバビリティツールに統合されているのがよい
    • On-Callの予行練習はオススメ

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

2-001

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

  • Platform Engineering と Datadog
    • Platform Engineering とは
      • 組織において有用な抽象化を行ない、セルフサービスインフラストラクチャを構築するアプローチ
      • 有用な抽象化：ゴールデンパス
        • テンプレートの提供
        • ドキュメントの整備
        • モニタリング標準化
    • 開発者のためのDatadog
      2-002
    • 「有用な抽象化：ゴールデンパス」→Datadogでは何ができるか？
      • ✅テンプレートの提供
      • ✅ドキュメントの整備
      • ✅モニタリング標準化
    • Software Catalog
      • 開発者が管理するサービス一覧を集中的に可視化するビュー
    • まとめ
      • Datadogは開発者のプラットフォームとしての機能が豊富
      • Datadogは開発生産性を向上させるプラットフォームとなることに期待

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

3-001

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

  • きっかけ
    • バックエンドアプリの応答が遅い
    • アプリで使用しているあるTCPポートの接続超過がどうかを知りたい
  • ❌特定のポートの接続数のモニタリングはできない
    3-002
    • netstatかssコマンドを使って調べることはできる
    • ss -ant4 | grep ':22'| grep ESTAB | wc-l
  • カスタムメトリクスを作る方法
    • 公式ドキュメント「カスタム Agent チェックの書き方」を参考にする
    • Step1：コンフィグを作る（例：/conf.d/xxxx.yaml）
    • Step2：チェックと送信処理を作る（例：/checks.d/xxxx.py） 
      self.gauge(
    'custom_tcp.connections',
    int(xxxxxx),
    tags=['host:xxxxxx']
)
  • 監視アラート
    • アラートはその時点でのステータスしかわからない
      3-003
    • 本当にみたいのはこのような時系列BARではないか？
      3-004
    • 機能がないので、似たようなものを作成した
      3-005
  • まとめ
    • オンライン会議は、カスタムメトリクスを活用することで会議数や参加人数を可視化できた
    • ゲームは、利用者数を可視化できた
    • 監視アラートは時系列BARで可視化できた
  • 参考

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

4-001

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

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

5. On-Call 運用Tips

5-001

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

  • On-Callの料金
    • シートに応じた課金
      • シートあたり月額 $25
  • シートとは？　≒　オンコールの対象に含まれている人の数（参考：シートとは何ですか？）
    • On-Callのスケジュールに含まれている
    • エスカレーションポリシーに含まれている
    • 電話番号登録などの通知設定を有効化している
  • Slack連携はオススメ
    • GA前：入電されたら、Datadogの画面から直接Resolveボタンを押すまで電話が鳴り続けた
    • GA後：Slackの画面でResolveできるようになった
      5-002
      • 現時点では、プレビュー版。SlackとTeamsに対応している。
        5-003
  • 特定モニターだけエスカレーション
    • On-Callチームのルーティングで条件分岐
    • タグや優先度でフィルタリング
  • まとめ
    • On-Callの料金算出はややこしい
      • 架電対象者が課金対象ということを覚えておく
    • Slack連携オススメ
    • 特定モニターだけエスカレーションができる

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

6-001

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

  • 認証に対するログ
    6-002
    • いつ・だれが・どこで
    • ログインが成功したか、失敗したか。
    • 失敗理由は？
      • Rate Limit？
      • アカウントロック？
    • 異常な行動は？
  • Auth0管理画面でもモニタリングできるが、モニターで閲覧できる期間が限定的
    • Datadogで可視化する
      6-003
      6-004
  • Auth0のログをDatadogで見られるメリット
    • メトリクスの長期保存
      • 過去のメトリクスも見られるので過去の傾向からの分析ができる
    • 他のアプリケーションログと統合して相関分析
    • アラートが柔軟に設定可能

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

7-001

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

  • 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
  • Network Monitoringのここが便利
    • NAT Gatewayを経由する通信でクエリ可能
    • 送信元や送信先でクエリ可能
    • 操作性は、普段のDatadogと同じ

7-003

その他参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?