ブログ on OpenTelemetry

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

Mon, 26 Jan 2026 07:01:03 -0300

過去数年間にわたり、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"を追加します

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 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としてお寄せください。

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

Thu, 19 Jun 2025 19:03:26 +0900

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

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

Mon, 02 Jun 2025 17:24:17 +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のウェブサイトが多言語化されました！

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

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

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

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

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

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

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