ブログ on OpenTelemetry

OpenTelemetry Spring Boot スターターが安定版になりました

Sat, 13 Jun 2026 10:26:42 +0000

OpenTelemetry Spring Boot スターターが安定版になったことをお知らせします。

Spring Boot スターターは、Spring Boot アプリケーションを OpenTelemetry で計装するプロセスを簡素化する強力なツールです。 OpenTelemetry Java エージェントに代わる軽量で柔軟な選択肢を提供し、Spring Boot アプリケーションのオブザーバビリティをこれまで以上に容易にします。

このブログ記事では、Spring スターターをいつ使うべきか、安定版とは実際に何を意味するのか、主な機能は何か、そしてどのような課題に直面したかを説明します。最後のパートでは、GraalVM ネイティブイメージアプリケーションを使用して、スターターの機能のいくつかを実演します。

すぐに始めたい場合は、Spring スターターのドキュメントをご覧ください。

Spring スターターを使うべきタイミング

Spring スターターを使用したいシナリオをいくつか紹介します。

OpenTelemetry Java エージェントが動作しない Spring Boot ネイティブイメージアプリケーション
OpenTelemetry Java エージェントの起動オーバーヘッドが要件を超える場合
別のモニタリング Java エージェントがすでに使用されており、OpenTelemetry Java エージェントとの互換性の問題を引き起こしている場合
Spring Boot 設定ファイル（application.properties、application.yml）を使用して OpenTelemetry Spring Boot スターターを設定したい場合（OpenTelemetry Java エージェントでは機能しません）
動的な認証ヘッダーなどの OpenTelemetry Spring Boot スターターのプログラム設定に Spring Bean を使用する場合（OpenTelemetry Java エージェントではこのためにエクステンションが必要です）
コード依存関係を使用: JVM オプション（たとえば Docker ファイル内）を追加する必要はありません。pom.xml または build.gradle ファイルに依存関係と BOM を追加するだけです

少し意外かもしれませんが、Spring ネイティブイメージアプリケーションを構築しない場合、デフォルトの推奨事項はバイトコード計装を使用した OpenTelemetry Java エージェントです。後で見るように、Spring スターターの計装よりも多くのすぐに使える計装を提供します。

KubeCon + CloudNativeCon Japan 2025で、 OpenTelemetryのトークとアクティビティに参加しよう

Wed, 10 Jun 2026 15:06:40 -0400

OpenTelemetryプロジェクトは、KubeCon + CloudNativeCon Japan（参加登録）および東京で同時開催されるCommunity Day（2025年6月14日〜17日）で、OpenTelemetryコミュニティのメンバーと一緒に過ごすことを皆さんにご案内します。

この記事では、KubeCon期間中に予定されているOpenTelemetry関連のすべてのアクティビティを紹介しています。カンファレンス開始前に、随時更新情報をチェックしてください！

Community Day

これは6月15日に開催される無料のイベントで、本カンファレンスに先立ち、クラウドネイティブコミュニティと交流する貴重な機会です。

Community Dayでは、KubeCon + CloudNativeCon Japanの参加者と、さまざまな地域ミートアップコミュニティ、Special Interest Group（SIG）やCloud Native Community Japanのサブグループのメンバーが一堂に会し、クラウドネイティブエコシステムにおける協業、学び、貢献を促進します。このイベントは、クラウドネイティブ開発やコミュニティ参加のさまざまな側面を対象とする複数のテーマ・トラックに分かれて構成されています。今すぐ登録しましょう！

KubeConトーク一覧

⚡ Lightning Talk: OTel 2025: The Latest Milestones and What’s Next（OTel 2025：最新の進展と今後の展望）
Steve Flanders（Contributor）
6月17日（火）• 11:51 - 11:56
Full Lifecycle API Management in Kubernetes With Envoy and WebAssembly（EnvoyとWebAssemblyを使ったKubernetesでのフルライフサイクルAPI管理）
Brandon Kang（Akamai Technologies）& Mostafa Radwan（Datadog）
6月17日（火）• 14:10 - 14:40
Navigating Millions of Kafka Events in Real Time With OTel（OTelで数百万のKafkaイベントをリアルタイム処理）
Siddharth Vijay（Baazi Games）& Shivay Lamba（Couchbase）
6月17日（火）• 14:10 -14:40

LLM 呼び出しの内側: OpenTelemetry による GenAI オブザーバビリティ

Fri, 05 Jun 2026 16:58:42 +0900

AI エージェントに単純な質問をしたら、回答までに 45 秒もかかった、ということを想像してみてください。原因はモデルでしょうか。それともツール呼び出しが遅かったのでしょうか。あるいはリトライのループに陥っていたのでしょうか。アプリケーションが LLM を呼び出すたびに、モデル呼び出し、ツール実行、トークンのやり取りといった一連の処理が裏側で起きています。オブザーバビリティがなければ、原因は推測するしかありません。

OpenTelemetry の Generative AI 向けセマンティック規約は、この内側を可視化します。 GenAI 操作の記録方法を標準化しており、呼び出されたモデル、入出力のトークン数、そして明示的に有効化した場合にはプロンプト、応答、ツール呼び出し、ツールの実行結果の中身までを記録します。

この記事では、以下を順に紹介します。

LLM を活用したアプリケーションから GenAI のテレメトリーをエクスポートする。
そのテレメトリーを受信して表示できるよう、オブザーバビリティツールを設定する。
GenAI ビジュアライザーを使って、GenAI のトレース、メトリクス、イベントを探索する。

GenAI テレメトリーをエクスポートする

このチュートリアルでは、多くの開発者がすでにインストール済みであることから、テレメトリーを発生させるツールとして VS Code Copilot を使います。ただし、多くのコーディングアシスタントが OpenTelemetry によるモニタリングをサポートしています。

VS Code Copilot は、エージェントとのやり取りごとにトレース、メトリクス、イベントを出力します。
OpenAI Codex は、API リクエスト、ツール呼び出し、セッションについて、構造化ログイベントと OTel メトリクスをエクスポートします。
Claude Code は OTel でメトリクスとログイベントをエクスポートし、トレース対応はベータ版で提供されています。

すでに使っているツールをモニタリングするだけでなく、自分の GenAI アプリケーションに OpenTelemetry を組み込めば、LLM とのやり取りの様子を可視化できます。

テレメトリーエクスポートを設定する

テレメトリーをエクスポートするには、いくつかの設定が必要です。 VS Code Copilot の場合は、設定画面を開いて copilot otel で検索してください。

OpenTracing 互換性要件の非推奨化

Fri, 05 Jun 2026 16:09:11 +0900

2026年3月19日、OpenTelemetry Specification プロジェクトは PR #4938 をマージし、仕様における OpenTracing 互換性要件を非推奨としました。

この変更は、エコシステムがすでに到達している状況に合わせて仕様を更新するものです。 OpenTracing は何年も前にアーカイブされており、新しいインテグレーションは、OpenTracing のシム要件の上に構築するのではなく、ネイティブの OpenTelemetry API および SDK を使用することが期待されています。

これは仕様要件の非推奨化であり、互換性に関する記述を即座に削除するものでも、既存のシムの成果物を今すぐ削除することを求めるものでもありません。

何が変わるのか

仕様における OpenTracing 互換性要件が非推奨になります。
新しい SDK や実装において、新たに OpenTracing 互換性を実装することはもはや必須ではありません。
既存の OpenTracing シムは、非推奨期間中、後方互換性のために引き続きサポートできます。
新しい作業では、新たな OpenTracing への依存を導入するのではなく、ネイティブの OpenTelemetry API、SDK、および OTLP ベースのワークフローを対象とすべきです。

なぜ今なのか

OpenTracing 自体は何年も前にアーカイブされており、エコシステムでの採用はネイティブの OpenTelemetry API と OTLP ベースのワークフローに収束してきました。このプロジェクトには、PR #4715 での Zipkin エクスポーターの非推奨化など、過去の非推奨化作業から、こうした段階的なアプローチの前例もあります。

タイムラインとポリシー

仕様の非推奨化: 2026年3月より有効。
仕様からの最も早い削除時期: マージされた仕様本文に記載のとおり、2027年3月より前にはなりません。

ユーザーは何をすべきか

まだ OpenTracing シムに依存している場合、今こそネイティブの OpenTelemetry API および SDK への移行を計画する良い時期です。

宣言的設定のジャーニー: トレースにおけるヘルスチェックエンドポイントを無視するのに5年かかった理由

Fri, 05 Jun 2026 16:08:55 +0900

過去数年間にわたり、Java OpenTelemetryに対する最も持続的に人気のある機能リクエストのひとつは、効率的にヘルスチェックエンドポイントのスパンをドロップする（またはその他の価値が低くコストのかかるエンドポイントをドロップする）機能でした。このイシューは2020年8月に最初に提起されましたが、驚くほど長い間、包括的なソリューションは見つかりませんでした。なぜこの一見単純な問題を解決するのに5年もかかったのでしょうか？その答えは、OpenTelemetryの設定システムの基本原則と、より堅牢で柔軟なアプローチである宣言的設定へのジャーニーにあります。

OpenTelemetryは、当初から設定のために環境変数に依存していました。これは環境変数が言語を問わず普遍的に利用可能であり、解析が容易であるという理由からの選択でした。しかし、より複雑な設定のユースケースの必要性が高まるにつれて、単純な文字列ベースの環境変数の制限がますます明らかになり、高度な設定の管理が煩雑かつ困難になりました。

宣言的設定の導入は、YAMLファイルを活用してOpenTelemetryの設定を定義する強力な進化です。この変化により、任意のツリー構造のソースからデータを読み取ることが可能になり、複雑な設定へのアプローチが根本的に変わります。このポストを通じて、宣言的設定が過去の課題に対してどのようにエレガントなソリューションを提供するかを探り、Javaにおけるヘルスチェック除外などの実用的なユースケースでその即時的な影響を示します。

はじめに

設定ファイルは言語に依存しないため、一度ファイルを作成すれば、すべてのSDKで使用できます。唯一の例外は、特定の言語名を持ち、その言語にのみ関連するパラメーターです（たとえばinstrumentation/development.java.spring_batchパラメーター）。

宣言的設定は 実験的 であるため、まだ変更される可能性があることに注意してください。

次の例は、開始するために使用できる基本的な設定ファイルです。

file_format: '1.0-rc.1'

resource:
 attributes_list: ${OTEL_RESOURCE_ATTRIBUTES}
 detection/development:
 detectors:
 - service: # OTEL_SERVICE_NAMEから"service.instance.id"と"service.name"を追加します

propagator:
 composite:
 - tracecontext:
 - baggage:

tracer_provider:
 processors:
 - batch:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_TRACES_ENDPOINT:-http://localhost:4318/v1/traces}

meter_provider:
 readers:
 - periodic:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_METRICS_ENDPOINT:-http://localhost:4318/v1/metrics}

logger_provider:
 processors:
 - batch:
 exporter:
 otlp_http:
 endpoint: ${OTEL_EXPORTER_OTLP_LOGS_ENDPOINT:-http://localhost:4318/v1/logs}

実験的な宣言的設定オプションを有効にするには、アプリケーションにOTEL_EXPERIMENTAL_CONFIG_FILE=/path/to/otel-config.yamlを渡すだけです。この変数は、執筆時点ではJavaエージェントとJavaScriptでのみ機能します。

レガシー環境における OpenTelemetry セキュリティプラクティスの適用

Fri, 05 Jun 2026 16:04:50 +0900

製造業をはじめとするレガシー環境において、組織がモダンなオブザーバビリティのアプローチを模索する中で、OpenTelemetry は注目を集めつつあります。しかし、こうしたプラクティスを従来型のシステムに適用すると、これまでとは異なるセキュリティ上の課題が生じます。レガシーインフラの制約は、セキュリティ制御をどこにどのように適用すべきかを根本的に変えてしまいます。

レガシー環境や産業環境には、次のような特徴がよくみられます。

変更や計装が不可能なシステム
長い機器のライフサイクルと限られたパッチ適用の機会
フラットなネットワーク、もしくはセグメンテーションが弱いネットワーク
一般的な PII ではない、機密性の高い運用データ

本記事では、こうした環境で OpenTelemetry を保護する際に何が異なるのか、そしてそれに応じてアプローチをどのように適応させればよいのかに焦点を当てます。

なぜレガシー環境は異なるのか

クラウドネイティブシステムにおけるセキュリティのガイダンスは、次のような前提に立っています。

サービスは計装可能である
暗号化と認証はどこでも強制できる
システムは定期的にパッチを適用できる

レガシー環境や産業環境では、これらの前提が成り立たないことがよくあります。

その結果、セキュリティはどこにでも理想的な制御を適用することではなくなります。 テレメトリーパイプラインの正しい場所に制御を配置し、可視性とリスクのバランスを取ることが重要になります。

レガシーシステム特有のセキュリティ課題

システムを変更できない

多くの産業システムは、エージェントを実行できず、モダンなライブラリをサポートできず、まったく変更できません。これは次のことを意味します。

ソースにおけるモダンな TLS や認証のサポートが限定的、あるいは一貫していない
SDK を用いた直接的な計装ができない
中継機能（Collector、ブリッジ、ログパイプライン）に依存する

ソースシステムがモダンな制御を強制できない場合、セキュリティの負担はより多く Collector、中継システム、ネットワーク境界へと移ります。

脆弱な、あるいは存在しないネットワークセグメンテーション

レガシー環境のネットワークアーキテクチャは、モダンなオブザーバビリティを念頭に設計されていないことがよくあります。セグメンテーションが最小限のフラットあるいは共有ネットワーク上で動作するものもあれば、レガシーなプロトコルが混在する深くネストされたネットワークに依存するものもあります。いずれの場合も、テレメトリー収集を導入することで次のような事態が起こり得ます。

意図しないネットワークセグメントに対して新たな受信エンドポイントが露出する
Collector やブリッジへの意図しない横方向アクセスが許容される
これまで分離されていたゾーンの間に予期せぬ経路が生まれる

このような環境では、Collector の配置は Collector の設定と同じくらい重要です。ネットワーク境界、ファイアウォール、プロトコルゲートウェイに対して Collector がどこに位置するのかを慎重に評価してください。

限られたパッチ適用と長いライフサイクル

産業システムはアップグレードなしで何年も稼働することがあります。 Collector の配置方法によって、パッチ適用の戦略は決まります。一般的なモデルは 2 つあります。

Collector を外部ブリッジとして配置する（推奨）:

Collector はレガシーシステムの境界の外側（別のホスト、VM、コンテナ上）で動作し、産業環境とオブザーバビリティバックエンドの間のブリッジとして機能します。このモデルでは、次のような利点があります。

AIエージェントオブザーバビリティ - 標準の進化とベストプラクティス

Tue, 26 May 2026 18:06:05 +0900

2025年、AIエージェントの年

AIエージェントは、2025年の人工知能における次の大きな飛躍になりつつあります。自律的なワークフローからインテリジェントな意思決定まで、AIエージェントは業界を横断する数多くのアプリケーションを強化するでしょう。しかし、この進化に伴い、特に企業のニーズに合わせてこれらのエージェントを拡張する場合、AIエージェントのオブザーバビリティが非常に重要になります。適切な監視、トレース、ロギングのメカニズムがなければ、AIエージェント駆動型アプリケーションの問題を診断し、効率を改善し、信頼性を確保することは困難です。

AIエージェントとはなにか

AIエージェントとは、LLMの能力、外界に接続するツール、高レベルの推論を組み合わせて使用し、望ましい最終目標や状態を達成するアプリケーションのことです。別の言い方では、エージェントは、LLMが自身のプロセスやツールの使い方を動的に指示し、タスクを達成する方法を制御するシステムとして扱うこともできます。

Image credit: Google AI Agent Whitepaper.

AIエージェントについての情報は他にも以下を参照してください。

オブザーバビリティのかなたへ

通常、アプリケーションからのテレメトリーは、アプリケーションの監視とトラブルシューティングのために使用されます。 AIエージェントの場合、その非決定論的な性質から、テレメトリーは、評価ツールのインプットとして使用することで、エージェントの品質から継続的に学び、改善するためのフィードバックループとしても使用されます。

生成AIのためのオブザーバビリティと評価ツールがさまざまなベンダーから提供されていることを考えると、ベンダーやフレームワーク固有のフォーマットによるロックインを避けるために、エージェントアプリによって生成されるテレメトリーの形状に関する標準を確立することが重要です。

AIエージェントのオブザーバビリティの現状

AIエージェントのエコシステムが成熟し続けるにつれて、標準化された強固なオブザーバビリティの必要性がより明らかになってきています。いくつかのフレームワークが組み込みの計装を提供する一方で、他のフレームワークはオブザーバビリティツールとの統合に依存しています。この断片的な状況は、生成AIオブザーバビリティプロジェクトとOpenTelemetryの新たなセマンティック規約の重要性を強調しています。これらは、テレメトリーデータがどのように収集され報告されるかを統一することを目的としています。

AIエージェントアプリケーションとAIエージェントフレームワークの比較

AIエージェントアプリケーションとAIエージェントフレームワークを区別することは極めて重要です。

OpenTelemetry が CNCF の Graduated プロジェクトに

Fri, 22 May 2026 19:35:22 +0900

本日、Cloud Native Computing Foundation（CNCF）は OpenTelemetry が Graduated になったことを発表しました。

Graduated はプロジェクトにとって重要なマイルストーンであり、OpenTelemetry のコミュニティとエコシステムの強さを反映するものです。 OpenTracing と OpenCensus の統合以降、数千人ものコントリビューター、メンテナー、エンドユーザー、そして多くの組織が、OpenTelemetry を業界全体で利用される、オープンでベンダーニュートラルなオブザーバビリティフレームワークへと育てる手助けをしてきました。

このマイルストーンはコミュニティのものです。

コード、ドキュメント、仕様、言語 SDK、セマンティック規約、バグ報告、レビュー、コミュニティサポート、アドボカシー、そしてエンドユーザー体験を寄せてくださったすべての方々に感謝します。 OpenTelemetry は、毎日プロジェクトに時間と専門知識を投じ続けてくれる人々のおかげで存在しています。

また、Graduated のプロセスを通じて OpenTelemetry を支えてくださった CNCF コミュニティ、Technical Oversight Committee のスポンサー、そしてエンドユーザーの皆様にも感謝しています。

Graduated はゴールではありません。 OpenTelemetry コミュニティは、グローバル規模のクラウドネイティブソフトウェアのために、相互運用可能で高品質なオブザーバビリティの標準とツールを構築することに、これからも取り組み続けます。

この旅の一員でいてくださり、ありがとうございます。この先に何が待っているのか、私たちはワクワクしています。

Ecosystem Explorer プロジェクトの紹介

Tue, 19 May 2026 21:31:49 +0900

OpenTelemetry は広大です。 Java エージェントだけでも、240 を超えるさまざまな自動計装が含まれています。 Collector には数百ものコンポーネントがあります。 Python、JavaScript、Go、.NET には、それぞれ独自の計装ライブラリエコシステムがあり、それぞれに独自のパターンや規約があります。

2025 Developer Experience Survey では、ユーザーは「ドキュメントをたどるのが難しく、OpenTelemetry ウェブサイトと GitHub リポジトリを行き来する必要がある」、また「さまざまな情報源から情報をつなぎ合わせなければならない」ことが多いと回答しました。主要な情報源として opentelemetry.io を利用しているユーザーは約半数にすぎず、それ以外のユーザーは GitHub、ベンダードキュメント、あるいは答えを見つけられる場所を参照しています。

そして、ドキュメントを見つけられたとしても、それが基本的な疑問に答えてくれるとは限りません。実際にどのテレメトリーシグナルを受け取ることになるのでしょうか。 OpenTelemetry Getting Started Survey では、回答者の 65% が、計装が実際に何を生成するのかを示すリファレンス実装を求めていることがわかりました。 OpenTelemetry 2025 Year in Review post で述べられているように、既存の OpenTelemetry Registry はユーザーがコンポーネントを見つける助けになりますが、次のような疑問に答えるために「必要な情報の深さを常に提供しているわけではありません」。どのライブラリが計装されているのか。どのスパン、メトリクス、属性を出力するのか。それはバージョンごとにどのように変わるのか。

OpenTelemetry の導入の中心には、根本的なジレンマがあります。あるコンポーネントがどのテレメトリーを生成するのか（どのスパン、メトリクス、属性なのか）を理解するには、多くの場合、まずそれをデプロイしなければなりません。 OpenTelemetry が自分たちのニーズに合うか評価している人に、それを求めるのは大きな負担です。

私たちはそれを解決するものを構築しています。約 1 年にわたってプロトタイプに取り組んだ後、新しいサイトが explorer.opentelemetry.io で公開されましたが、まだまだ開発途上です。

Java エージェントエコシステム

Java エージェントは、私たちが最初に完全にマッピングしたエコシステムです。 240 を超える計装がインデックス化され、検索可能になっています。名前で閲覧したり、計装タイプでフィルタリングしたり、各計装が出力するスパン、メトリクス、属性を正確に示す詳細ページを掘り下げたりできます。設定オプションはドキュメント化され、それが影響するテレメトリーにマッピングされています。

バージョンサポートも組み込まれています。 Explorer は複数の Java エージェントリリースを追跡するため、特定のバージョンがどのテレメトリーを生成するのか、あるいはバージョン間で何が変わったのかを確認できます。これは、アップグレードを計画するときや、リリース後にテレメトリーの見え方が変わった理由をデバッグするときに特に役立ちます。

毎晩実行される自動化があります。新しい Java エージェントバージョンがリリースされると、パイプラインがそれを検出し、メタデータを抽出し、レジストリを更新するため、手動での介入は不要です。

Java で初期アプローチを検証しました。今度は、新しいエコシステムへ拡張するための助けが必要です。

OpenTelemetry 日本コミュニティ向けアンケート

Mon, 04 May 2026 09:31:32 +0900

このレポートは、日本の開発者やエンジニアにおける OTel の認知度、導入状況、コミュニティ参加の現状を把握するために実施された、OpenTelemetry 日本コミュニティ向けアンケートの結果をまとめたものです。このアンケートは、開発、SRE、DevOps、プラットフォームエンジニアリングといった役割の実務者を対象とし、CNCF コミュニティチャネル、および X (旧 Twitter)、Qiita、Zenn といった日本のソーシャルプラットフォームを通じて配布されました。目的は、日本の技術エコシステムにおいて OTel の利用とエンゲージメントを意義ある形で拡大できる、データドリブンな戦略を立案することです。

主なポイント

OTel の導入については、本アンケートには成熟した層からの回答が集まりました。 61.47% がすでに本番環境で稼働させており、さらに 25.69% が評価中です。両者を合わせると回答者の約 87% を占めます。
シグナルの収集ではトレースが 93% で最も多く、メトリクスが先行する傾向にある世界の OTel アンケートとは対照的な結果となっています。
コミュニティの満足度は高く、NPS は +49 を記録しました。ただし 27.37% は中立 (パッシブ) であり、ドキュメントの改善やコミュニティへの働きかけによって、推奨者へと転換できる余地があります。
Go のユーザーは導入への意欲が最も強く、評価段階の 39% と比較して本番運用が 76% と数値が跳ね上がっており、いずれの言語よりも大きな伸びを示しています。
回答者の 86% がカンファレンスに参加していますが、KubeCon Japan 2025 への参加は 25% にとどまっており、今後の開催に向けて、まだリーチできていない大きな潜在層があることを示唆しています。
Twitter/X は 2 番目に多く利用されている情報源 (83%) ですが、OpenTelemetry はそこに公式アカウントを持っておらず、また日本でよく使われている Zenn や Qiita にも存在感がありません。日本の利用者と関わっていきたいのであれば、これに対処することを検討すべきです。

回答者属性と背景

回答者の構成は 開発チーム に大きく偏っており (44.95%)、次いで SRE が 22.94% で 2 番目に大きなグループとなっています。 DevOps、プラットフォームエンジニアリング、セールスエンジニアリングが中位層を形成し、運用担当 (Operations) と専任のオブザーバビリティ担当を合わせても 7% 未満にとどまります。地理的には、東京を含む 関東地方 に大きく集中しており (76.15%)、近畿地方 (大阪・京都圏) が 12.84% で大きく離された 2 位となっています。これは日本のテック産業における東京の存在感を考えれば驚くことではありませんが、これらの都市圏以外の日本の開発者層を完全に代表しているとは言えない可能性があることは、留意しておく必要があります。

Span Events APIの非推奨化

Thu, 26 Mar 2026 19:22:32 +0900

OpenTelemetryはSpan Event APIを非推奨化します。この記事では、この変更を行う理由、その概要、そして準備のために必要なことを説明します。要約すると以下のとおりです。

イベントを送信する2つの重複した方法（スパンイベントとログベースのイベント）によって生じる混乱と重複を解消したいと考えています。
新しいコードは、現在のスパンに関連付けられたログとしてイベントを記録すべきです。
古い「スパンイベント」スタイルは段階的に廃止されますが、スパン上のイベントを表示する既存のデータとビューは引き続き機能します。

なぜSpan Event APIを非推奨にするのか？

現在、OpenTelemetryはトレースと相関するイベントを送信するための主要な方法を2つ提供しています。

Tracing APIのSpan.AddEventまたはSpan.RecordExceptionメソッドを使用して作成されるスパンイベント。
Logs APIを介して（直接、またはOpenTelemetryにブリッジされたロギングライブラリを通じて）送信され、アクティブなコンテキストに関連付けられるログベースのイベント。

同じ概念に対して競合する2つのAPIを持つことには、いくつかの欠点があります。

計装の作成者に対するガイダンスの分断。 ライブラリやフレームワークの作者は、非常に似たデータを送信するための2つの方法のいずれかを選択しなければなりません。選択が異なると、エコシステム全体でユーザーエクスペリエンスに一貫性がなくなります。
ユーザーにとっての重複した概念。 オペレーターはスパンイベントとログイベントの両方、それらのエクスポート方法、およびバックエンドでの扱いを理解しなければなりません。
進化の遅延。 イベントモデルの改善（たとえば、スキーマ、属性、後方互換性に関するもの）は、2か所で仕様策定と実装が必要になります。

OpenTelemetryコミュニティは、よりシンプルなメンタルモデルへの収束を進めています。 イベントはLogs APIを介して送信される名前付きのログであり、スパン上の特別なケースとしてではなく、コンテキストを通じてトレースやメトリクスと相関するというモデルです。この変更は、OpenTelemetryがイベントを表現する方法を統一するものとして重要です。この方向性の背景については、以前のブログ記事OpenTelemetry Logging and Youを参照してください。

同時に、スパンイベントが今日広く使用されていることも認識しています。多くのバックエンドは専用のトレースビューでスパンイベントを表示しており、一部のユーザーは親スパンと同じOTLPエクスポートペイロードにイベントが含まれることに依存しています。

OTEP 4430: Span Event API非推奨化計画のプランは、以下の目標のバランスを取ることを目指しています。

新しいイベントはLogs APIを通じて送信すべきという明確で一貫したガイダンスの提供。
互換性レイヤーを通じて、トレース内のスパンイベントに依存する既存のワークフローの保持。

つまり、スパンに付随するイベントを見る機能ではなく、スパンイベントを記録するためのAPIを非推奨化するということです。

何が変わるのか？

非推奨化は新しいイベントの記録方法に焦点を当てています。

ログベースのイベントに対するOTLPサポートはすでに安定しており、Logs APIはスパンイベントがこれまで持っていたすべてのものを、より豊富なメタデータとより柔軟なエクスポートおよびフィルタリング機能とともに記録できます。
トレース仕様は、ログベースのイベントの送信を優先してSpan.AddEventやSpan.RecordExceptionなどのAPIを非推奨化します。
言語APIとSDKはログベースのイベントをファーストクラスとして扱い、必要に応じてそれらのイベントをスパンイベントとして表示できる互換性オプションを提供します。
計装とセマンティック規約は、次のメジャーバージョンでスパンイベントからログベースのイベントへと段階的に移行しながら、それまでは既存の動作を安定した状態に保ちます。

何が変わらないのか？

Span Event APIが非推奨化されても、ユーザーエクスペリエンスのいくつかの重要な側面は意図的に保持されます。

シグナル間の相関は同じように機能し続けます。 ログベースのイベントは引き続きOpenTelemetryコンテキストに関連付けられます。
既存のデータは有効なままです。 すでにスパンイベントを使用しているデータは、サポートされているOTLPトレースモデルの一部として残ります。

非推奨化は、新しいコードでイベントを送信する単一の推奨方法を提供するものであり、スパン上のイベントへの可視性を削除するものではありません。

何をすべきか？

まず何より、この移行が安全で段階的であり、現在依存しているワークフローと互換性があるものにしたいと考えています。

役割に応じて、今後の変更がどのように影響するか、そして何ができるかを以下に示します。

コントリビューターの募集: OpenTelemetry for Kotlin

Mon, 15 Dec 2025 21:01:52 +0900

なぜOpenTelemetry for Kotlinを立ち上げるのか？

Kotlin Multiplatform（KMP）は、ブラウザ、サーバー、デスクトップ環境など、さまざまなプラットフォームでKotlinのコードを実行できます。従来、KotlinはAndroidとJVMで最も人気がありましたが、KMPの登場により、異なるプラットフォーム間でコードを共有するために使用するユーザーが着実に増加しています。

Embraceは、KMPプロジェクトで使用できるOpenTelemetry仕様のKotlin実装を寄贈する提案を公開しました。これにより、KMPおよびKotlinプロジェクトは、1つのAPIで多くの異なるプラットフォーム向けのテレメトリーを取得できるようになります。このAPIは、可能な限りプラットフォームに依存しないOpenTelemetryの実装として設計されており、AndroidとiOSの重要なユースケースに対応するため、モバイルフレンドリーであることを目指しています。

opentelemetry-javaはJVM上で動作するKotlinアプリをサポートしていますが、これはJava相互運用に依存しており、Kotlinらしい慣用的なAPIだと「感じられません」。さらに、opentelemetry-javaはJVM上でしか動作しませんが、Kotlinは非JVMターゲットにもデプロイできます。

コントリビューターの募集

Kotlin MultiplatformでOpenTelemetryを使用することに興味がある方、ぜひご協力ください！コードベースのメンテナンス、定期的なSpecial Interest Group（SIG）ミーティングへの参加、SDKの発展に貢献してくださるコントリビューターを募集しています。

コントリビューターになることに興味がある方、または興味を持ちそうな方をご存知の方は、寄贈の提案にコメントしてください。

コントリビューターにはならないけれども、これまでのプロジェクトへのフィードバックや試用を したい という方は、こちらのリポジトリをご覧いただき、ご意見をissueとしてお寄せください。

OpenTelemetryのウェブサイトが多言語化されました！

Wed, 19 Feb 2025 23:16:58 +0900

OpenTelemetry のウェブサイトが多言語で利用可能になったことをお知らせします！ローカライゼーションチームはすでに、ウェブサイトのページを中国語、日本語、ポルトガル語、スペイン語に翻訳し始めています。

OpenTelemetryプロジェクトは、世界中の貢献者とユーザーを得るまでに成長しました。ウェブサイトを多言語で利用できるようにすることは、母国語に関係なく、誰もがプロジェクトに貢献できるようにするための重要なステップです。また、この取り組みによって、エンドユーザーが多言語のドキュメントにアクセスできるようになり、OpenTelemetryをより簡単に学び、理解できるようになることを嬉しく思います。

希望の言語でウェブサイトにアクセスするには、ページ右上の言語セレクターから選択してください。

ぜひこの取り組みに貢献してください。ローカライゼーションに貢献する仲間は、Slackチャンネル #otel-docs-localization にいます。すでにサポートされている言語に堪能な方は、翻訳やレビューを手伝ってください。あなたの言語がまだサポートされておらず、翻訳を手伝いたい場合は、issueを作成してください。

あなたの貢献は有意義な影響をもたらします！

私たちは、これを可能にしてくれたすべての貢献者に感謝し、これらの新しい言語によるドキュメントが、OpenTelemetryのユーザー体験をどのように向上させるかを楽しみにしています。