Dynamic な Instrumentation 2025.05.08 Yuta Kihara #JDDUG FUKUOKA 🎉 

内容 なぜDynamic Instrumentation? Dynamic Instrumentationって何？ 02 01 03 Dynamic Instrumentationの仕組みは？ 04 Dynamic Instrumentationのオーバーヘッドは？ 05 Dynamic Instrumentationのユースケース 06 検証して得られた Tips 

なぜ Dynamic Instrumentation? ① 実際のお客様から Dynamic Instrumentation(DI)が『画期的』 だとFeedbackをいただいた。 3 ② 事例などもあんまり上がっていないので、使われていない・そもそも知られていないのでは？ ⭐ この画期的な機能を理解してDynamic Instrumentationの価値をもっと普及させたい。 

Dynamic Instrumentation, 動的な計装 ...って何？ 『再起動することなく 、サードパーティのライブラリを含むアプリケーションのコードの任意の場所 で、実行中の本番シス テムにインスツルメンテーションを追加することができます。』 つまり「後からでも観測する仕組み (計装)を動的に追加できる 」→ ⭐ Probe 4 公式ドキュメント SRE/開発エンジニア Probe 作成 実行中のアプリにエラー解析の ためにLogを動的に作成・確認 

Probeについて、その種類 Probe(プローブ)という用語が出てきました。Probeは英語で『探査』と訳されます。 Dynamic Instrumentationにおいて、Probeは実行中のアプリケーションの挙動を調査（Probe）するた めのブレークしないブレークポイント ⇨ 実行中のLocal変数の値も確認できる。 Probeには４種類あります。 5 Probeの種類 目的 Log Probe アプリのコード内で特定の場所のログをローカル変数含めて収集する。 Span Probe 特定の関数の開始・終了時間を測定し、トレースを作成する。 Metric Probe 特定のコードの実行回数や数値を測定する。 Span Tag Probe 既存のトレーススパンにカスタムタグを追加する。 

Dynamic Instrumentation 仕組み 6 

DIの仕組み ざっくり10ステップ 7 Datadog Backend Datadog UI 1. Probe作成 サーバー 実行中のアプリ tracer library Datadog Agent 2. Probe設定を保存 3. 最新のProbe設定をポーリング 4. 最新の設定を返す Loop 5.Bytecodeの 修正・追加 6.Logs/Span..が 　生成される 7.機密キーワードは 保護される 8. Probeで収集された Telemetry Dataを送信 9. Sensitive Data Scanner 　の適用 10. 収集された Telemetry Dataを表示 

Dynamic Instrumentation Overhead 8 

①Dynamic InstrumentationのOverheadは？ ● 結論、公開している Benchmarkはないです。 ● Metric, Span, Span Tag, Simple Log (例：log.Info("X:", x)) のパフォーマンスへの影響は無視できる レベルです。 ● 唯一影響が大きいのは「Enriched Log」（メソッド内のすべての変数値をキャプチャするもの）です が、これには厳格なレート制限 が適用されています。 ● 気にするのはEnriched Logのみだが、Performanceに影響が出ない仕組みがあります。 ⇨ ガードレイル 9 

②Dynamic Instrumentationのガードレイルとは？ ● Logのレート制限（どの言語にも同じ制限が適用されます。） ○ Simple Log：5,000回/秒 ■ ほぼすべての実行でパフォーマンス影響なく、ログが出力されると考えられます。 ○ Enriched Log：1回/秒 ■ Enriched Logのキャプチャおよびシリアライズの制限 ● オブジェクトの参照を3階層まで追跡 ● 文字列の最大長: 255文字まで ● 1クラスあたりの最大フィールド数は20個まで ● コレクション（配列、リスト、マップ、セットなど）の最大要素数は 100個まで ● Call Stack Trace ● Caught and uncaught exceptions 10 公式docにも記載あり。 * 一部記載ない点はLibrary Engineerから共有いただいた情報 

Dynamic Instrumentation ユースケース 11 

シナリオ1 本番環境の実データで障害 /エラー解析 12 お客様から連絡があり、〇〇のページで XXのデータが表示されていないみたいです！ 調査中ですがおそらく、 〇〇が原因だと思います。修正してデプロイ済みです。確認お願いします。 Browserの種類・ Versionも違うし、調査も動作確認も時間がかかる。。他の開発タスクが終わらない。。 〇〇のパターンだと、同じ事象が発生するみたいです。 色々なパターンで動作確認お願いします。 営業/CS エンジニア 調査 CODE修正 動作確認 デプロイ while True: 調査; 営業/CS エンジニア 

シナリオ1 本番環境の実データで障害 /エラー解析 13 Argu 1 Argu 2 Argu 3 * Error Tracking のページからもDynamic InstrumentationでProbeの作成が可能です。 

シナリオ2 パフォーマンス監視観点 Profiler x DI 14 いつも発生する訳ではないですが、ある条件が重なった時に〇〇の処理で CPU時間が非常に長くなる。 Profilerだけだと確かにコードレベルでボトルネックの特定はできるが、なぜ？の断定ができないな。。。 この条件の時に CPU時間が長くなってしまっていたのか、 Method内部の変数から分かるかも！ Profilerと合わせてボトルネックになっている Methodに、DIを活用して一時的に Log Probeを作成すれば、処理 内の変数・詳細な Contextを把握することができるぞ！ DD User DD User DD User DD User 

シナリオ2 パフォーマンス監視観点 Profiler x DI 15 

シナリオ2 パフォーマンス監視観点 Profiler x DI 16 

シナリオ3 自動計装が非対応の LibraryにDIでSpan追加 17 APMで、〇〇の Libraryも自動計装に対応してますか？〇〇の処理も実行時間など可視化できたらな。。 Custom Instrumentationを使用することで自動計装に対応していないライブラリの Spanを収集可能ですよ！ わお！！わざわざコードに修正しなくてもパフォーマンスを測れるのは便利だな、使ってみよう！ おお、そうなんですね！もしかして、 Custom Instrumentationってコードの修正が必要でしょうか？ DD先生 DD User DD User DD User Dynamic Instrumentationを使えば、コードの修正することなく Spanを追加できますよ！ DD先生 

シナリオ3 自動計装が非対応の LibraryにDIでSpan追加 18 

シナリオ4 SREチームでビジネス指標を収集・活用 19 最近、経営層からの要請で、ビジネス KPIをもっと可視化する必要が出てきた。ただ、現状の Datadogのダッ シュボードには技術的な SLIはあるが、売上や決済失敗率みたいなビジネス指標が足りてない。 開発チームと協力できればいいけど、最近のロードマップを見ると厳しそうだね そうですね。開発チームも新機能開発で手一杯だから、データを取るための実装っていうのは後回しになりが ちですし …。でも、もし SRE側でやれることがあれば、自分たちで進めるのもアリですね。 そんな機能があるんですか？！それって APMとは別機能で、追加でコストがかかるんですかね？ Dynamic Instrumentationを活用いただくとコードの修正など無しで、 SREチームのみで売上データなどのビジ ネス指標を収集することが可能です。具体的には Log Probe、Span Tag Probe を使用して。。。 SRE Lead DD 先生 SRE Engineer DD 先生 いいえ、通常の APMライセンスでご利用いただける機能になりますので、追加コストもかかりません。 

Dynamic Instrumentationの価値・まとめ 20 本番環境の実データで障害 /エラー解析 →MTTDの短縮 + 開発エンジニアの開発生産性の向上 SREチームでビジネス指標を収集・活用　 →EngとBizのコラボ促進 、全ての関係者で使えること＝ O11yの価値 パフォーマンス監視観点 Profiler x DI　 →サービスパフォーマンスの向上（レイテンシーの短縮 etc..） 自動計装が非対応の LibraryにDIでSpan追加　 → 監視運用・開発コストの削減 

Dynamic Instrumentation 検証して得られた Tips 21 

Dynamic Instrumentationサポート言語と前提条件 サポート言語 ● Java, Python, .NET in GA, Node.js and Ruby in Preview , Go/PHP は開発中...のステータス ● PreviewのNode.jsとRubyはDIの中でも使える機能に制限があるため注意です(e.g. Metrics, Spans, and Span Tagsは非対応)。 前提条件 ● Datadog Agent 7.45.0 以降がサービスと一緒にインストールされていること。 ● その Agent でリモート構成(RC)が有効になっていること。→ Default で有効化されている ● Azure App Services やAWS Lambdaなどのサーバーレス環境にはまだ対応していません。 ● 言語ごとにTracer のVersionのCompatibilityがあるので、要確認。 ● DIを設定できるメンバーには、Datadog Userの権限の付与を行う。 ○ debugger_read(DIページの閲覧権限) , debugger_write(DIの設定書き込み権限), debugger_capture_variables(メソッドのパラ メータやローカル変数のキャプチャする権限)のPermissionの３つが必要 推奨条件 ● 統合サービスタグ付けの設定 ● Autocomplete and Search (Preview機能)の有効化 →自動補完機能でかなり便利 ● Source Code Integrationの設定 22 

DD_DYNAMIC_INSTRUMENTATION_ENABLEDを忘れずに https://docs.datadoghq.com/ja/dynamic_instrumentation/enabling/ 23 DI有効化を入れないと、いつまで待ってもクルクルしてます 

有効化後、 2つ目にチェックマーク確認 ✅ 24 

25 まずは、推奨されてるコード連携を無しで作成してみる Create Instrumentationボタンをクリック 

Source Code Integration (SCI)の設定がないと。。 26 『どこに Probeを挿入するか』の設定で、 Method(どのクラス、どのメソッド )と Line(どのファイルで、何行目 )をGithubなどで確認する必要がある。 

Lineを選択→ Fileで該当キーワード表示（ SCIあり） Source Code Integration（SCI）の設定がされている場合は、 Probeを挿入する方法において Lineを選択すると、 SCI無しと 比較して直感的に指定したい場所を選択できます。 Probeを挿入する方法において、 Methodを選択した場合 は、SCIの設定がない場合と変わらずに明示的にどのクラス のどのメソッド名かを指定する必要があります。 Fileの入力欄にキーワードを入力すると自動でマッチする ファイル名を表示されます。 27 

Lineを選択した際に Source Codeを表示（SCIあり） 28 ファイルが選択されると右側に Source Codeが表示されます。 そしてファイルの何行目に Probeを挿入したいかをクリックすれば Lineの入力欄に自動で反映されます。 

実行時間や戻り値、変数を Log Probeに出力が可能 29 変数がオブジェクトの場合は最大 5段階までの属性値を確認できます。 ある条件にマッチした時だけ Logを出力させることもできます。 該当のソースコード 

Probe作成後の画面 (SCI設定無し) 30 作成した Probeの場所（クラス名： OwnerController, メソッド名 : findOwner） が表示されます。 Probeの種類と作成した内容 (Logの場合は指定した変数や実行時間 )を 確認できます。 SCIが有効化されていないと表示されます。 

Probe作成後の画面 (SCI設定あり) 作成時に Lineを選択した場合のみ、 Probe 作成後の画面で、ソースコードが表示されます。 もし、Methodを選択した場合は、 SCI設定があっても Probe作成後の画面でソースコードは表示されません。 31 

該当の処理が実行されると、 Probeが生成される 32 一つ該当のログをクリックしてみます。 

⓪ DI によって生成された Log Probe 全体 普段のLogと異なる見え方なので、 それぞれ３つのパートに分けて 見ていきます。 33 

① DI によって生成された Log Probe -メッセージ - 34 Source名は自動的に dd_debuggerに指定されてあります。 datadog.api_key_uuidは生データではなく、 Hash化されてあります。 Logメッセージ内には、変数 (実行時間や、戻り値の属性値 )の実際の値を確認できます。 

② DI によって生成された Log Probe -Event 属性- 35 メソッドの処理の実行時間（ Duration）を確認できます。 TraceとLogの紐付けの設定を有効化している場合は Log ProbeもTraceと紐付いて見えます。 

③ DI によって生成された Log Probe -Stacktrace- 36 Stacktraceのタブでは、該当の Method内で使われている Private変数を確認できます。 またLog Probe内で指定した戻り値が Ownerというオブジェクトなので、その属性値（ firstName, lastName, address, city, telephone）も確認できます。 

④おまけ DI によって生成された Log Probe -JSON- Snapshot ID Probe ID Location (Probe挿入箇所) Duration などがdebugger属性として 付与されています。 37 

Sensitive Data Scannerのルールも適用可能 38 

source:dd_debuggerで自動でScanner ルールが適用 39 

Exception Replay エラー発生時の変数を把握可能 40 現在 Preview機能: https://docs.datadoghq.com/ja/tracing/error_tracking/exception_replay 

Autocomplete and Search (Preview) Method名 自動補完 41 https://docs.datadoghq.com/ja/dynamic_instrumentation/symdb/ 

THANK YOU