現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability

Observability Conference Tokyo 2025

https://o11ycon.jp/sessions/1017868/

Transcript

1. @AoToLog_ #o11yconjp 27th Oct, Observability Conference Tokyo 2025 Speaker: Kento Kimura 現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ
2. @AoToLog_ #o11yconjp 話すひと • 所属： Technical Solutions / Sales Engineering • 担当： パブリッククラウドのアーキテクト知識を活かした 　 Datadog のプリセールス技術支援 • 資格：　OpenTelemetry Certified Associate(OTCA) を(ほぼ)最速で取得 • コミュニティ： Google Cloud のユーザーコミュニティ「Jagu'e'r」 Datadog のユーザーコミュニティ「JDDUG」 AWS のユーザーコミュニティ「JAWS」 • カンファレンス： 初登壇！ 木村 健人 (Kento Kimura) Datadog Japan GK
3. @AoToLog_ #o11yconjp 01 現場の壁を超える計装 04 これからの展望 03 「計装注入」が拓く世界 02 OpenTelemetry から学ぶ 話すこと
4. @AoToLog_ #o11yconjp 01 現場の壁を超える計装 04 これからの展望 03 「計装注入」が拓く世界 02 OpenTelemetry から学ぶ XX 各言語における計装のしくみ 話すこと 話さないこと XX XX OpenTelemetry Collector について eBPF 計装(OBI) の詳細
5. @AoToLog_ #o11yconjp 現場の壁を超える計装
6. @AoToLog_ #o11yconjp アプリケーションシステムの課題 新規システム開発と言語・技術選定 クラウド・コンテナ技術の普及やマイクロサービスアーキテクチャの浸透で、 これまで以上にシステム開発言語の多様化が進む • 開発チームごとに技術選定・意志決定がされる • 企業内の統一・標準化にも工数が必要 • 横断チームに求められる技術範囲の肥大化 チーム・サービスごとの技術選定は 大規模組織では足並みが揃えづらい オブザーバビリティの習熟度も異なり、 横断的な取り組みに負荷がかかる PYPL PopularitY of Programming Language より 任意のプログラミング言語の時系列人気度グラフを作成
7. @AoToLog_ #o11yconjp アプリケーションシステムの課題 レガシーシステムの残存・負債 日本の企業はメインフレーム・オンプレミス上の老朽化した既存 IT システム いわゆる「レガシーシステム」を高い割合で保守している • 過去の資産の塩漬け • ブラックボックスによる移行障壁 • 肥大化・複雑化した実装 IPA「DX白書2023」 図表1-31「レガシーシステムの状況」より引用・作成 「レガシーシステム」にどのような機能があり、 どのように動いているかがわからない 再構築・機能追加・廃棄・現状維持などの 意思決定を支持する指標がない！！
8. @AoToLog_ #o11yconjp オブザーバビリティをはじめよう オブザーバビリティとは、つまり… 外部シグナルからシステムの内部状態を推測できる能力 システム ？ 外部シグナル システムの 内部状態 入力 出力 “ “
9. @AoToLog_ #o11yconjp オブザーバビリティをはじめよう オブザーバビリティの要素：計装・転送(収集・送信)・保存・可視化 計装を施せれば、外部にシグナルを転送し保存・可視化できる 入力 出力 システム 計装 転送 バックエンド 保存・ 可視化 ymotongpoo 『書籍『入門 OpenTelemetry』』 逆井（さかさい） 『大規模システムへの OpenTelemetry Collector 導入の勘所と OpAMP に見る未来』
10. @AoToLog_ #o11yconjp システムA (言語A) 計装 システムB (言語B) 計装 転送 バックエンド 保存・ 可視化 システムγ (言語γ) 計装 システムC (言語C) 計装 レガシー システム 計装 転送 バックエンド 保存・ 可視化 計測 オブザーバビリティをはじめるためのイメージ図 オブザーバビリティをはじめよう 多言語・分散システム • 複数言語間で同一の信頼性指標 • 分散システム間の依存関係 • システムの問題箇所の特定 レガシーシステム • パフォーマンス指標の高度化 • ブラックボックスの可視化 • 管理・影響が少ない監視手法
11. @AoToLog_ #o11yconjp 計装を阻む、現場の壁 多言語・分散システム • 言語ごとに計装手法が異なるため、 整備をするオーバーヘッドが高い • 大規模環境で計装し忘れたサービスが 原因でトレースが繋がらない レガシーシステム • システム・コードベースが古く、 変更承認プロセスが重い・できない • 運用・開発担当者が異なり、 コードの変更に責任を持てない 1. 複数の環境に同時に 2. コードの変更を伴わず 言語による設定の違いを意識せずに広く設定を適用したい
12. @AoToLog_ #o11yconjp 手動計装 テレメトリーシグナルを取得するために、 アプリケーションコードに直接 API/SDK の実装を施す計装方式 (単に「計装」とも呼ぶ) 自動計装 テレメトリーシグナルを取得するために、 アプリケーションコードに変更を加えず、 言語特有の機能で関数をラップして、 SDK の実装を施す計装方式 「計装注入」というアプローチ 「計装注入」 言語ごとに異なる自動計装の仕組みを自動的に注入するために、 コンテナ・プロセス単位でシステム機能を利用する計装方式 ※このセッションを話すにあたり、日本語の熟語を作りました(広めていきたい) 言語による設定の違いを意識せずに広く設定を適用できる
13. @AoToLog_ #o11yconjp OpenTelemetry から学ぶ
14. @AoToLog_ #o11yconjp OpenTelemetry ができること Cloud Native Computing Foundation(CNCF) の Incubating プロジェクト 目的：テレメトリー(Primary Signals) を計装・生成・送信する フレームワークとツールキットの開発・仕様策定 ◦ Specifications(仕様) ▪ OpenTelemetry Protocol(OTLP) ▪ Open Agent Management(OpAMP), OTel Arrow, Semantic Conventions ◦ OpenTelemetry API, SDK ▪ Language API & SDK ▪ Zero-code Instrumentation(自動計装) ◦ OpenTelemetry Collector ▪ Receiver, Processor, Exporter ▪ Extension, Connector
15. @AoToLog_ #o11yconjp OpenTelemetry ができること /Organizer の資料 Cloud Native Computing Foundation(CNCF) の Incubating プロジェクト 目的：テレメトリー(Primary Signals) を計装・生成・送信する フレームワークとツールキットの開発・仕様策定 ◦ Specifications(仕様) ▪ OpenTelemetry Protocol(OTLP) ▪ Open Agent Management(OpAMP), OTel Arrow, Semantic Conventions ◦ OpenTelemetry API, SDK ▪ Language API & SDK ▪ Zero-code Instrumentation(自動計装) ◦ OpenTelemetry Collector ▪ Receiver, Processor, Exporter ▪ Extension, Connector
16. @AoToLog_ #o11yconjp OpenTelemetry ができること オブザーバビリティの要素：計装・転送(収集・送信)・保存・可視化 OpenTelemetry の実装は計装・転送のみ 入力 出力 システム 計装 転送 バックエンド 保存・ 可視化 ◆参考 　ymotongpoo 『書籍『入門 OpenTelemetry』』 　逆井（さかさい）『大規模システムへの OpenTelemetry Collector 導入の勘所と OpAMP に見る未来』
17. @AoToLog_ #o11yconjp OpenTelemetry ができること 入力 出力 システム 計装 転送 バックエンド 保存・ 可視化 API・SDK Collector OTLP OTel Arrow 計装：OpenTelemetry API・SDK 転送：OpenTelemetry Collector 仕様：OTLP, OTel Arrow　 言語ごとの計装の仕組みと 転送設定をそれぞれ実装する必要が… ◆参考 　ymotongpoo 『書籍『入門 OpenTelemetry』』 　逆井（さかさい）『大規模システムへの OpenTelemetry Collector 導入の勘所と OpAMP に見る未来』
18. @AoToLog_ #o11yconjp OpenTelemetry ができること 入力 出力 システム 計装 転送 バックエンド 保存・ 可視化 ◆参考 　ymotongpoo 『書籍『入門 OpenTelemetry』』 　逆井（さかさい）『大規模システムへの OpenTelemetry Collector 導入の勘所と OpAMP に見る未来』 API・SDK Collector OTLP OTel Arrow 計装：OpenTelemetry API・SDK 転送：OpenTelemetry Collector 仕様：OTLP, OTel Arrow　 言語ごとの計装の仕組みと 転送設定をそれぞれ実装する必要が… OpenTelemetry の各言語の計装を まるっと一括で行いたい！！ OpenTelemetry の「計装注入」
19. @AoToLog_ #o11yconjp 「計装注入」に関わるところ OpenTelemetry Operator OTel の Kubernetes Operator 実装 Operator が自動計装ツールをポッドに 組み込む設定を入れることで、 各言語の自動計装が実現できる！ OpenTelemetry Injector OTel の Linux 共有ライブラリ実装 プロセスの起動時の動的リンカーで 共有ライブラリをプリロードして、 各言語の自動計装が実現できる！ サポート言語・対象 • Java • Node.js • Python • .Net • Go サポート言語 • Java • Node.js • .Net • Python • Apache httpd • Nginx • SDK(環境変数)
20. @AoToLog_ #o11yconjp 「計装注入」に関わるところ OpenTelemetry Operator OTel の Kubernetes Operator 実装 Operator が自動計装ツールをポッドに 組み込む設定を入れることで、 各言語の自動計装が実現できる！ OpenTelemetry Injector OTel の Linux 共有ライブラリ実装 プロセスの起動時の動的リンカーで 共有ライブラリをプリロードして、 各言語の自動計装が実現できる！ サポート言語・対象 • Java • Node.js • Python • .Net • Go サポート言語 • Java • Node.js • .Net • Python • Apache httpd • Nginx • SDK(環境変数)
21. @AoToLog_ #o11yconjp OpenTelemetry Operator の紹介 • OpenTelemetry コンポーネントを管理するKubernetes Operator の実装 ◦ OpenTelemetry Collector ◦ OpenTelemetry 自動計装エージェント ◦ OpAMPBridge • 任意の方法で既存の Kubernetes クラスターに実装可能 ◦ kubectl apply -f opentelemetry-operator.yaml ◦ Helm Chart • Injecting Auto-instrumentation(自動計装の注入=「計装注入」) ◦ Pod 内の任意のコンテナを annotations で指定し、言語ごとに計装注入可能 ▪ instrumentation.opentelemetry.io/inject-[lang_name]: true ◦ 複数言語を同一ポッド上でアノテーションする場合 ▪ instrumentation.opentelemetry.io/[lang_name]-container-names : app
22. @AoToLog_ #o11yconjp OpenTelemetry Operator 「計装注入」の仕組み Admission Controller の Mutating Admission Webhook 機能 • Kubernetes API サーバーへのリクエストの認証・承認の後、 リソースが永続化される前にリクエストをインターセプトし変更を加える • 変更が加えられたリソースはスキーマと設定値の検証後に永続化 Kubernetes API Server API ハンドラ 認証 認可 Mutating Admission スキーマ 検証 Validading Admission etcd 永続化 Webhook ハンドラ Request Response 計装注入 の Webhook の実装はここ 　　opentelemetry-operator/internal/ webhook/podmutation/webhookhandler.go
23. @AoToLog_ #o11yconjp Kubernetes API Server OpenTelemetry Operator 「計装注入」の構造 API ハンドラ 認証 認可 Mutating Admission スキーマ 検証 Validading Admission etcd 永続化 App App OTel /otel-auto- instrumentation Mutatingwebhook ns opentelemetry- operator-mutation opentelemetry- instrumentation Testmutatingwebhook ns App OTel Request Response Mutating
24. @AoToLog_ #o11yconjp OpenTelemetry Operator 「計装注入」の構造 App kind: Pod metadata: annotations: instrumentation.opentelemetry.io/inject-[lang_name]: "true" spec: containers: - name: app image: image App OTel /otel-auto- instrumentation kind: Pod metadata: annotations: instrumentation.opentelemetry.io/inject-◯: "true" spec: containers: - name: app image: image env: - 計装に必要な環境変数 “環境変数の設定値” vomumeMounts: - name: otel-auto-instrumentation mountPath: /otel-auto-instrumentation initContainers: - name: opentelemetry-auto-instrumentation image: 自動計装ツールイメージ command: [“自動計装を利用するエントリポイント”] vomumeMounts: - name: otel-auto-instrumentation mountPath: /otel-auto-instrumentation volumes: - name: otel-auto-instrumentation emptyDir: {} kind: Pod metadata: annotations: instrumentation.opentelemetry.io/inject-[lang_name]: "true" spec: containers: - name: app image: image Mutating kind: MutatingWebhookConfiguration metadata: name: mutating-webhook-configuration webhooks: - admissionReviewVersions: 中略 rules: - apiGroups: - opentelemetry.io resources: - instrumentations kind: Instrumentation metadata: name: my-instrumentation spec: [lang_name]: image: 自動計装ツールイメージ version: "バージョン" ： 計装注入
25. @AoToLog_ #o11yconjp 「計装注入」に関わるところ OpenTelemetry Operator OTel の Kubernetes Operator 実装 Operator が自動計装ツールをポッドに 組み込む設定を入れることで、 各言語の自動計装が実現できる！ OpenTelemetry Injector OTel の Linux 共有ライブラリ実装 プロセスの起動時の動的リンカーで 共有ライブラリをプリロードして、 各言語の自動計装が実現できる！ サポート言語・対象 • Java • Node.js • Python • .Net • Go サポート言語 • Java • Node.js • .Net • Python • Apache httpd • Nginx • SDK(環境変数)
26. @AoToLog_ #o11yconjp OpenTelemetry Injector の紹介 • OpenTelemetry 自動計装を動的に読み込む Linux 共有ライブラリの実装 ◦ Zig で記述される Linux 共有オブジェクトライブラリ ◦ OpenTelemetry 自動計装エージェント → DEB, RPM パッケージとして配布 • 任意の方法で既存の Linux ホストに実装可能 ◦ /etc/ld.so.preload ファイルへの記述 ◦ LD_PRELOAD 環境変数の設定 • 共有オブジェクトライブラリ(libotelinject.so)=「計装注入」が 自動計装の設定をプロセスの起動時に入れてくれる ◦ アプリケーション言語ごとに読み込む自動計装エージェントが異なる ▪ dotnet_auto_instrumentation_agent_path_prefix ▪ jvm_auto_instrumentation_agent_path ▪ nodejs_auto_instrumentation_agent_path
27. @AoToLog_ #o11yconjp OpenTelemetry Injector の紹介 • OpenTelemetry 自動計装を動的に読み込む Linux 共有ライブラリの実装 ◦ Zig で記述される Linux 共有オブジェクトライブラリ ◦ OpenTelemetry 自動計装エージェント → DEB, RPM パッケージとして配布 • 任意の方法で既存の Linux ホストに実装可能 ◦ /etc/ld.so.preload ファイルへの記述 ◦ LD_PRELOAD 環境変数の設定 • 共有オブジェクトライブラリ(libotelinject.so)=「計装注入」 ◦ アプリケーション言語ごとに読み込む自動計装エージェントを変える ▪ dotnet_auto_instrumentation_agent_path_prefix ▪ jvm_auto_instrumentation_agent_path ▪ nodejs_auto_instrumentation_agent_path • OpenTelemetry Injector って Zig で書かれているの！？ • Python もサポートされていなかったっけ？ • どのようにアプリケーション言語を判別しているの？
28. @AoToLog_ #o11yconjp OpenTelemetry Injector の歴史 • OpenTelemetry 自動計装を動的に読み込む Linux 共有ライブラリの実装 2025/06 Splunk の寄贈により、初期の OpenTelemetry Injector が誕生 • C 言語ベースの「計装注入」共有オブジェクトライブラリ • Java, Node.js, .NET, Python をサポート 2025/08 dash0 が寄贈する、新版の OpenTelemetry Injector に置き換え • Zig 言語ベースの「計装注入」共有オブジェクトライブラリ • Java, Node.js, .NET をサポート
29. @AoToLog_ #o11yconjp OpenTelemetry Injector と本セッションの歴史 • OpenTelemetry 自動計装を動的に読み込む Linux 共有ライブラリの実装 2025/06 Splunk の寄贈により、初期の OpenTelemetry Injector が誕生 • C 言語ベースの「計装注入」共有オブジェクトライブラリ • Java, Node.js, .NET, Python をサポート 2025/08 Observability Conference Tokyo 2025 のプロポーザルを提出 dash0 が寄贈する、新版の OpenTelemetry Injector に置き換え • Zig 言語ベースの「計装注入」共有オブジェクトライブラリ • Java, Node.js, .NET をサポート 2025/09 Observability Conference Tokyo 2025 のプロポーザルが採択😇 プロポーザル提出時とは違う「OTel Injector」について話します！！
30. @AoToLog_ #o11yconjp OpenTelemetry Injector の歴史 chore: import Dash0 Zig injector #63 open-telemetry/opentelemetry-injector/pull/63 要約すると… 1. libc への依存性解消・互換性の向上 ◦ 一部のコンテナで機能しない問題を解消 2. 環境変数処理の改善 ◦ 環境変数の上書きを条件付きに 3. K8s リソース属性の取得 ◦ Pod, NS の属性追加が可能に 単純な構造に書き換えたから、 これからはこれをベースに開発するよ
31. @AoToLog_ #o11yconjp OpenTelemetry Injector の歴史 chore: import Dash0 Zig injector #63 open-telemetry/opentelemetry-injector/pull/63 要約すると… 1. libc への依存性解消・互換性の向上 ◦ 一部のコンテナで機能しない問題を解消 2. 環境変数処理の改善 ◦ 環境変数の上書きを条件付きに 3. K8s リソース属性の取得 ◦ Pod, NS の属性追加が可能に 単純な構造に書き換えたから、 これからはこれをベースに開発するよ
32. @AoToLog_ #o11yconjp OpenTelemetry Injector 「計装注入」の構造 Linux 動的リンカー(ld.so)でプリロードする共有ライブラリを指定する機能 • 全プロセス共通で同一の共有ライブラリをプリロードする • プロセスが各言語固有の環境変数を読み取る際(getenv())に、 共有ライブラリが各言語の自動計装に必要な環境変数値を書き換える • OTel のサービス名(OTEL_SERVICE_NAME)もここで設定される Linux Dynamic Linker execve() システムコール 動的リンカ 起動 プリロード の確認 ELF 依存関係 の解析 シンボル解決 プログラム 実行 1. /etc/ld.so.preload 2. 環境変数 LD_PRELOAD 3. 実行ファイル 4. 依存ライブラリ 5. glibc 計装注入 の libotelinject.so の実装はここ 　　opentelemetry-injector/src/root.zig
33. @AoToLog_ #o11yconjp OpenTelemetry Injector 「計装注入」の仕組み Linux Dynamic Linker execve() システムコール 動的リンカ 起動 プリロード の確認 ELF 依存関係 の解析 シンボル解決 プログラム 実行 実行ファイル libotelinject.so libotelinject.so 実行ファイル 依存ファイル glibc OTel Library 言語ランタイム 各言語アプリ 各言語ランタイムが環境変数を読み取る際(getenv())に プリロードされた共有ライブラリが環境変数に自動計装設定を計装注入する 計装注入
34. @AoToLog_ #o11yconjp 「計装注入」が拓く世界
35. @AoToLog_ #o11yconjp オブザーバビリティの潮流と計装 手動計装 自動計装 「計装注入」 アプリへの実装 アプリケーション自体に 直接実装を施すため、 言語と OTel 両方に固有の知識 が求められる アプリ機能の活用 アプリケーションの機能を活用し OTel 実装を自動的に施すため、 言語機能の固有の知識のみ が求められる コンテナ・プロセス機能 Kubernetes や Linux 機能など アプリケーション言語や OTel に 限らない共通の知識が求められる O11y オブザーバビリティの導入に 積極的かつ固有のユースケースに 適応した小回りのきく組織 O11y オブザーバビリティを広く 効率的に活用し、横断的に 複数のチームに適用できる組織 O11y オブザーバビリティの導入に 制限がありながらも、 統制を効かせて進める組織 初期 現在 低 高 導 入 コ ス ト
36. @AoToLog_ #o11yconjp オブザーバビリティの潮流と計装 手動計装 自動計装 「計装注入」 アプリへの実装 アプリケーション自体に 直接実装を施すため、 言語と OTel 両方に固有の知識 が求められる アプリ機能の活用 アプリケーションの機能を活用し OTel 実装を自動的に施すため、 言語機能の固有の知識のみ が求められる コンテナ・プロセス機能 Kubernetes や Linux 機能など アプリケーション言語や OTel に 限らない共通の知識が求められる O11y オブザーバビリティの導入に 積極的かつ固有のユースケースに 適応した小回りのきく組織 O11y オブザーバビリティを広く 効率的に活用し、横断的に 複数のチームに適用できる組織 O11y オブザーバビリティの導入に 制限がありながらも、 統制を効かせて進める組織 初期 現在 低 高 導 入 コ ス ト ※「計装注入」が制限なく適用できるのであれば”真”
37. @AoToLog_ #o11yconjp 「計装注入」の制限を知る 1. 自動計装が確立している言語のみ「計装注入」ができる ◦ 「計装注入」はあくまでも自動計装が前提 ◦ 「計装注入」の方式によっては自動計装ができないこともある 2. Kubernetes や Linux の機能を使って、各言語で異なる設定を吸収する ◦ Kubernetes や Linux の理解が浅いと、トラブルシュートが困難になる ◦ 便利な機能であるが故に、攻撃手法としての使われ方も把握したい 3. 単純な手動計装や自動計装と比較して柔軟性に劣る ◦ トレースの粒度やリソース属性の制御が最低限となる ◦ 計装対象の指定が最低限となる 4. 「計装注入」の手法は模索中=標準化されていない ◦ Splunk → dash0 の変更のように OTel 内でも大幅な変更があり得る ◦ ベンダーの「計装注入」機能も少しずつ実装が異なる
38. @AoToLog_ #o11yconjp 「計装注入」とセキュリティ Mutating Admission Webhook 機能 • サイドカー(バックドア)注入 自動計装エージェントと同様に、 ポッドに対してバックドアとなる サイドカーを注入して、k8s クラスター に自由に侵入できるようにする Linux 共有ライブラリのプリロード • 動的リンクハイジャッキング 正常なプログラムの実行に優先して 不正なプログラムを実行させながら、 その攻撃を正常なプログラムの実行に 紛れ込ませることができる 便利が故に攻撃にも使われる機能たち 唯一の対抗策は、オブザーバビリティを高めて 攻撃と脅威を検出できる体制を整えること
39. @AoToLog_ #o11yconjp
40. @AoToLog_ #o11yconjp
41. @AoToLog_ #o11yconjp eBPF 計装(OBI)について OpenTelemetry eBPF Instrumentation (OBI) • 一般的なメトリクスとトランザクションレベルのトレース • 「計装注入」と同様に言語の違いを意識しない実装が可能 • 幅広い言語に対応 ◦ Java, .NET, Go, Python, Ruby, Node.js, C, C++, Rust • 軽量で再起動不要！ • root または準ずる昇格された権限が必要 ◆引用 　OpenTelemetry eBPF Instrumentation(https://opentelemetry.io/docs/zero-code/obi/) 強めの制限もあるが、 言葉を並べると使い勝手が良さそう…！ (事例が聞きたい😉)
42. @AoToLog_ #o11yconjp これからの展望
43. @AoToLog_ #o11yconjp OpenTelemetry プロジェクトへの貢献 • OpenTelemetry プロジェクトはのコントリビューター(貢献者)は それぞれの SIG(Special Interest Group) ごとに活動している ◦ OpenTelemetry Injector SIG(通称 ZIG🤪) は生まれたばかり！ ◦ 興味のある SIG の CNCF Slack チャンネル(#otel-xx)から覗いてみよう！ • コントリビュートのしかた ◦ ドキュメントやプロジェクトへのコントリビュートは先人方がやっている 、 まずは興味を持つところから！ ◆引用 　OpenTelemetryにコントリビュートしてみた(https://paper2.hatenablog.com/entry/2025/01/25/143031) 　OpenTelemetryの 公式ドキュメント日本語化プロジェクトにコミットする一連の流れ(https://zenn.dev/msksgm/articles/20250314-translate-otel-docs-into-ja) 　OpenTelemetry Collector internals(https://speakerdeck.com/ymotongpoo/opentelemetry-collector-internals)
44. @AoToLog_ #o11yconjp まとめ • 計装は外部シグナルを生成し、システムの内部状態を推測するため =オブザーバビリティの入り口 • 「計装注入」は言語特有のオブザーバビリティの設定を必要とせずに、 Kubernetes, Linux の機能で自動計装を挿入するアプローチ ◦ Kubernetes の Mutating Admission Webhook 機能 ◦ Linux の共有オブジェクトライブラリのプリロード機能 • 便利な機能の仕組みを知っておくことで、現在の制限・今後の展望・ セキュリティリスクを正しく理解できる • OpenTelemetry のプロジェクトはリアルタイムに更新されるので、 今からでも貢献するチャンスはたくさんある
45. @AoToLog_ #o11yconjp まだ、見るセッションが決まっていない？ ピーク時165万スパン/秒に立ち向かえ！ オブザーバビリティコストを効率化する ABEMA におけるトレースサンプリングの実践的事例 山本 哲也 SRE, AbemaTV 株式会社 逆井 啓佑 Sales Engineer, Datadog / Co-Organizer, Observability Conference Tokyo
46. @AoToLog_ #o11yconjp Thank you! Datadog スポンサーブースへお越しください🐶