Spring Boot Starterを使用したOpenTelemetryの導入プロセス

Spring Boot Starterは、OpenTelemetryを迅速かつ簡単にアプリケーションへ統合するためのモジュールです。
このセクションでは、Spring Boot Starterを活用してOpenTelemetryを導入する具体的な手順とベストプラクティスを解説します。
Spring Boot Starterを利用することで、コード量を最小限に抑えつつ効果的にトレーシングやメトリクス収集を行うことが可能です。

Spring Boot Starterとは何か、OpenTelemetryでの役割

Spring Boot Starterは、Spring Bootアプリケーションに特定の機能を簡単に追加するためのテンプレートです。
OpenTelemetry用のSpring Boot Starterは、分散トレーシングやメトリクス収集のための基本的な構成を含んでいます。
これにより、開発者は複雑な設定を行わずにOpenTelemetryの利点を利用できます。
例えば、HTTPリクエストやデータベースクエリのトレースを自動化できるため、手動で計装する必要が大幅に減少します。

依存関係の追加とGradle/Mavenの設定方法

OpenTelemetryを導入する第一歩は、プロジェクトに依存関係を追加することです。
Gradleを使用している場合は、`build.gradle`ファイルに以下を追加します：

implementation 'io.opentelemetry:opentelemetry-spring-boot-starter'

Mavenを使用している場合は、`pom.xml`に以下のように記述します：

<dependency>  
    <groupId>io.opentelemetry</groupId>  
    <artifactId>opentelemetry-spring-boot-starter</artifactId>  
</dependency>

これにより、必要なライブラリがダウンロードされ、プロジェクトに統合されます。

最初の設定と基本的なサンプルコードの解説

依存関係を追加した後、`application.properties`または`application.yml`ファイルでOpenTelemetryの設定を行います。
例えば、エクスポート先を指定する場合は以下のように記述します：

otel.exporter.otlp.endpoint=http://localhost:4317  
otel.resource.attributes=service.name=my-spring-service

これにより、トレースやメトリクスが正しいエクスポート先に送信されるようになります。

Spring Bootアプリケーションへの統合手順

設定が完了したら、アプリケーションを実行するだけでOpenTelemetryが自動的にトレーシングデータを収集します。
たとえば、HTTPエンドポイントへのリクエストやデータベースアクセスは、すべてトレースに含まれます。
必要に応じて、`Tracer`や`Meter`といったOpenTelemetry APIを使用してカスタムの計測を追加することも可能です。

導入後の基本的な動作確認とトラブルシューティング

OpenTelemetryの導入後は、トレーシングデータが期待通りに収集されているか確認します。
これは、JaegerやZipkinといったトレースビューアを使用して行うことが一般的です。
トラブルが発生した場合は、ログを確認して設定ミスやネットワークの問題を特定します。
また、エクスポート先が正しく構成されているかどうかを再確認することが重要です。
次に、以下のセクションを執筆します：「OpenTelemetryの依存関係の設定方法と注意点」。

OpenTelemetryの依存関係の設定方法と注意点

OpenTelemetryを活用するには、適切に依存関係を設定することが重要です。
依存関係とは、プロジェクトで使用する外部ライブラリやモジュールを指し、正確に設定することで、機能がスムーズに動作します。
このセクションでは、GradleやMavenを使った設定方法、バージョン管理、競合回避の方法を解説し、よくあるトラブルや解決策についても取り上げます。

GradleとMavenで依存関係を追加する手順

依存関係の設定は、OpenTelemetryを使用する際の最初のステップです。
Gradleを利用する場合、`build.gradle`ファイルに以下を記載します：

implementation 'io.opentelemetry:opentelemetry-api:1.22.0'  
implementation 'io.opentelemetry:opentelemetry-sdk:1.22.0'

一方、Mavenを使用する場合、`pom.xml`に以下を追加します：

<dependency>  
    <groupId>io.opentelemetry</groupId>  
    <artifactId>opentelemetry-api</artifactId>  
    <version>1.22.0</version>  
</dependency>  
<dependency>  
    <groupId>io.opentelemetry</groupId>  
    <artifactId>opentelemetry-sdk</artifactId>  
    <version>1.22.0</version>  
</dependency>

これにより、プロジェクトに必要なライブラリが含まれ、OpenTelemetryの基本機能を使用可能になります。

バージョン管理と最新の安定版ライブラリの選択

OpenTelemetryのバージョン管理は重要です。
APIとSDKのバージョンが一致していない場合、互換性の問題が発生する可能性があります。
そのため、常に最新の安定版を使用することが推奨されます。
また、リリースノートを確認し、新機能や修正点を把握することも大切です。

依存関係の競合を避けるためのベストプラクティス

プロジェクトで複数のライブラリを使用している場合、依存関係の競合が発生することがあります。
たとえば、異なるバージョンのライブラリが含まれると、コンパイルエラーやランタイムエラーが生じる可能性があります。
このような問題を防ぐには、`dependencyManagement`（Maven）や`dependency constraints`（Gradle）を使用してバージョンを固定化することが有効です。

OpenTelemetry APIとSDKの違いと選び方

OpenTelemetryには、APIとSDKという2つの主要なコンポーネントがあります。
APIは、トレースやメトリクスの記録に使用され、SDKはそれらを処理およびエクスポートする役割を果たします。
基本的な使用にはSDKが必要ですが、カスタム計装を行う場合はAPIの知識も不可欠です。
プロジェクトの要件に応じて適切なコンポーネントを選択することが重要です。

依存関係設定時のよくある問題とその解決方法

依存関係の設定では、特定のバージョンがリポジトリに存在しない場合や、競合が原因でビルドに失敗する場合があります。
このような問題が発生した際には、以下を試してください：
– リポジトリURLを確認し、必要なリポジトリが設定されているか確認する。
– 競合するライブラリの排除設定を行う。
例：`exclude`オプション（Gradle）や`exclusions`タグ（Maven）。
– 必要に応じて、直接的な依存関係を最小限に抑える。
次に、「環境変数を使用したOpenTelemetryの設定方法」を執筆します。

環境変数を使用したOpenTelemetryの設定方法

OpenTelemetryでは、環境変数を使用して設定を管理する方法が提供されています。
環境変数を使用することで、コードを変更せずに動的に設定を調整することが可能になり、特に異なる環境（開発、テスト、本番）での運用が簡便になります。
このセクションでは、環境変数の基本的な使用方法とその利点、具体例、トラブルシューティングについて詳しく解説します。

OpenTelemetryで環境変数を使用するメリット

環境変数を使用することで、コードの変更を最小限に抑えながら設定を変更できます。
これにより、以下のようなメリットがあります：
– 設定の変更が容易で、再デプロイを必要としない。
– 設定値が環境に依存する場合でも柔軟に対応可能。
– セキュリティ面での利点（環境変数に機密情報を格納することでコード内の露出を防ぐ）。
これらのメリットにより、特に大規模な分散システムでの管理が簡素化されます。

主要な環境変数の一覧とその役割

OpenTelemetryでは、さまざまな設定が環境変数を通じて行えます。
以下は主な環境変数とその役割です：
– `OTEL_EXPORTER_OTLP_ENDPOINT`: データを送信するエクスポート先のURL。
– `OTEL_RESOURCE_ATTRIBUTES`: サービス名やバージョンなど、リソース属性を指定。
– `OTEL_LOG_LEVEL`: ログの詳細度を設定（例：INFO、DEBUG）。
– `OTEL_TRACES_SAMPLER`: トレースデータのサンプリング戦略を指定。
– `OTEL_METRICS_EXPORT_INTERVAL`: メトリクスのエクスポート間隔を設定。
これらの変数を適切に設定することで、OpenTelemetryの動作を簡単にカスタマイズできます。

環境変数を設定する際の具体的な例と手順

環境変数は、一般的に以下のように設定します：
– Linux/MacOS:

  export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317  
  export OTEL_RESOURCE_ATTRIBUTES=service.name=my-service

– Windows:

  set OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317  
  set OTEL_RESOURCE_ATTRIBUTES=service.name=my-service

また、Dockerを使用する場合は、`docker run`コマンドで環境変数を設定できます：

docker run -e OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 my-container

環境変数の効果を確認する方法とテスト手法

設定した環境変数が正しく適用されているか確認するには、以下の方法を使用します：
1. ログの確認: OpenTelemetry SDKが初期化時に読み込んだ設定をログ出力します。
2. トレースビューアの確認: JaegerやZipkinを使用して、エクスポートされたデータが期待通りか確認します。
3. デバッグモードの有効化: `OTEL_LOG_LEVEL=DEBUG`を設定し、詳細なログを取得します。

複数環境での設定管理の工夫と注意点

複数環境で一貫性を保ちながら設定を管理するためには、以下の工夫が有効です：
– 環境ごとに異なる`.env`ファイルを使用し、必要な設定を分離する。
– コンテナオーケストレーションツール（例：Kubernetes）で`ConfigMap`や`Secrets`を利用して管理する。
– 設定のバージョン管理を行い、変更履歴を追跡可能にする。
注意点としては、セキュリティ情報（APIキーやパスワード）を直接コード内に埋め込まないようにすることが重要です。

OpenTelemetryによる自動計装の仕組みと動作の理解

自動計装は、OpenTelemetryの強力な機能の一つであり、コードを最小限に変更するだけでトレーシングやメトリクスの収集を可能にします。
このセクションでは、自動計装の仕組みと動作について深掘りし、どのようにして簡単に導入できるかを解説します。
また、収集データの内容や、トラブルシューティングの方法についても説明します。

自動計装とは何か、その基本的な仕組み

自動計装は、既存のアプリケーションコードに最小限の変更を加えるだけで、トレーシングやメトリクス収集の機能を利用可能にする技術です。
OpenTelemetryの自動計装では、ライブラリが提供するプリビルトのインスツルメント（計装ツール）がアプリケーションの特定の操作を自動的に監視します。
これにより、HTTPリクエスト、データベースクエリ、メッセージキュー操作などが自動的にトレースされます。
特に、Spring BootやNode.jsといった人気のあるフレームワークでは、この機能が簡単に利用できます。

OpenTelemetryでサポートされる自動計装の対象

OpenTelemetryの自動計装は、さまざまなフレームワークやライブラリで利用可能です。
以下は代表的な対象例です：
– HTTP通信: リクエストやレスポンスの詳細なトレースが可能。
– データベース: クエリの実行時間や結果の追跡。
– メッセージキュー: 送受信のトレース。
– gRPC通信: メソッド呼び出しの計測。
– その他の言語特有のライブラリ: Java、Python、Goなどで利用される特定のライブラリもサポートされています。
これにより、幅広い分散システムでの計測が可能になります。

自動計装を有効にする設定方法と具体例

自動計装を有効にするためには、環境変数を設定するか、起動時のオプションを指定します。
たとえば、Javaアプリケーションで自動計装を使用する場合、以下のようにエージェントを指定して起動します：

java -javaagent:/path/to/opentelemetry-javaagent.jar -jar my-app.jar

この設定により、HTTPリクエストやデータベースクエリが自動的に監視されます。
また、Spring Boot Starterを使用する場合、追加設定はほとんど不要で、自動的にトレースが有効化されます。

自動計装で収集できるデータの種類とその活用

自動計装によって収集されるデータは、主に以下の3つです：
– トレース: 各操作のタイミング、遅延、エラーの詳細を提供します。
– メトリクス: CPU使用率、リクエスト数、エラー率などの統計データ。
– ログ: 問題が発生した際の詳細情報を記録します。
これらのデータを組み合わせることで、システム全体の可観測性を向上させ、迅速なトラブルシューティングが可能になります。

自動計装の動作確認とデバッグの方法

自動計装が正しく動作しているか確認するには、以下の手順を行います：
1. トレースビューアを利用: JaegerやZipkinなどのトレースビューアを使用し、収集されたトレースデータを可視化します。
2. エクスポート先の確認: データが指定したエクスポート先に送信されているかをチェックします。
3. デバッグモードの有効化: 環境変数`OTEL_LOG_LEVEL=DEBUG`を設定することで、詳細なログを確認できます。
動作しない場合は、エージェントのパスや環境変数の設定を再確認してください。
次に、「手動計装を行うためのベストプラクティスと具体例」を執筆します。

手動計装を行うためのベストプラクティスと具体例

手動計装は、自動計装ではカバーできない特定の操作やビジネスロジックを追跡したい場合に役立ちます。
OpenTelemetry APIを利用することで、詳細なトレーシングやカスタムメトリクスを実現できます。
このセクションでは、手動計装の必要性とその方法、具体的な実装例、ベストプラクティスを解説します。

手動計装の必要性とその適用シナリオ

手動計装は、以下のようなシナリオで特に重要です：
– カスタムロジックのトレーシング: 特定のビジネスロジックやアルゴリズムのパフォーマンスを追跡。
– 複雑なトランザクション: 自動計装では完全にカバーできないトランザクションを監視。
– 詳細なエラー情報の収集: エラーが発生した場合の追加情報を取得。
手動計装を使用することで、システムの可観測性がさらに向上し、問題の診断が容易になります。

OpenTelemetry APIを使用した計装の基本例

OpenTelemetry APIを使用することで、カスタムのトレースを作成できます。
以下はJavaでの基本的な例です：

Tracer tracer = OpenTelemetry.getGlobalTracer("my-app");  
Span span = tracer.spanBuilder("custom-operation").startSpan();  
try {  
    // 計測対象の処理  
    System.out.println("Custom operation executed.");  
} finally {  
    span.end();  
}

この例では、`custom-operation`という名前のトレースが作成され、処理時間やエラー情報が記録されます。

SpanやContextの設定方法と利用例

Spanはトレースの基本単位であり、操作ごとの詳細を記録します。
以下は、属性を追加してSpanをカスタマイズする例です：

span.setAttribute("operation.id", 123);  
span.setAttribute("operation.status", "success");

また、Contextを使用することで、分散システム全体でトレース情報を共有できます。
これにより、サービス間の呼び出しが追跡可能になります。

手動計装を成功させるためのコード設計のポイント

手動計装を効果的に行うには、以下のポイントに注意してください：
– 一貫性のある命名規則: トレースやSpanの名前を分かりやすく設定する。
– 不要な計測を避ける: 重要でない操作を計測しないことでオーバーヘッドを削減。
– エラーハンドリングの強化: エラー発生時に詳細な情報を記録。
– リソース管理: Spanの開始と終了を確実に行い、リソースリークを防ぐ。

自動計装との併用時の注意点と効果的な運用方法

自動計装と手動計装を併用する場合、重複トレースの発生に注意が必要です。
自動計装がすでにカバーしている範囲を手動計装で再計測すると、データの冗長性が生じます。
これを避けるために、自動計装を有効にした状態で、必要最小限の手動計装を追加することが重要です。
また、設定ファイルや環境変数を利用して、計装範囲を制御することも推奨されます。
次に、「トレースデータを活用した可視化とデバッグの実践方法」を執筆します。

トレースデータを活用した可視化とデバッグの実践方法

トレースデータは、分散システムのパフォーマンスやエラーを可視化し、迅速にデバッグするための重要な情報源です。
このセクションでは、トレースデータの基本的な活用方法から、可視化ツールの使用、デバッグのベストプラクティスまでを解説します。
これにより、OpenTelemetryを最大限に活用してシステムの健全性を保つ方法を学べます。

トレースデータとは何か、その基本的な役割

トレースデータは、システム内の一連の操作を記録したものです。
これにより、リクエストがどのようにサービス間を移動したか、どの部分で遅延やエラーが発生したかを特定できます。
各トレースは、複数の`Span`で構成され、それぞれが特定の操作を表します。
このデータは、サービスのパフォーマンスを理解し、ボトルネックを特定するために役立ちます。

可視化ツールの選択と使用方法

トレースデータを可視化するために、以下のツールがよく使用されます：
– Jaeger: 分散トレースを可視化するためのオープンソースツール。
詳細なトレース情報を提供します。
– Zipkin: シンプルで使いやすい分散トレーシングツール。
基本的なトレース解析に最適。
– Grafana Tempo: Grafanaとの統合が可能で、メトリクスとトレースを一元管理できます。
ツールを使用する際は、OpenTelemetryのエクスポーター設定でトレースデータの送信先を指定します。
たとえば、以下のように設定します：

otel.exporter.otlp.endpoint=http://localhost:14250

これにより、トレースデータが指定したツールにエクスポートされます。

トレースデータを活用したボトルネックの特定方法

可視化ツールを活用して、以下の方法でシステムのボトルネックを特定できます：
1. 遅延の分析: 各Spanの実行時間を確認し、異常に長い操作を特定。
2. エラーの追跡: エラーが発生したトレースを調査し、根本原因を特定。
3. リソース使用率の分析: トレースデータとメトリクスを組み合わせて、CPUやメモリの使用状況を把握。
これにより、問題の根本原因を迅速に発見し、解決策を導き出すことが可能です。

トレースデータとログを組み合わせたデバッグの実践例

トレースデータとログを統合することで、より詳細なデバッグが可能になります。
たとえば、以下のような流れでデバッグを行います：
1. トレースビューアでエラー発生箇所を特定。
2. 関連するログを調査し、エラーの詳細情報を取得。
3. コードの再確認: エラーの原因となった操作やパラメータを分析。
これにより、単独のログやトレースデータではわからない問題の詳細を把握できます。

トレースデータを活用した継続的なモニタリングの方法

トレースデータを継続的に監視することで、問題の早期発見が可能です。
たとえば、以下の戦略が有効です：
– ダッシュボードの作成: Grafanaを使用してトレースデータの可視化を行い、リアルタイムで監視。
– アラートの設定: トレースの遅延やエラー率が一定値を超えた場合に通知を受け取る。
– 定期的なレビュー: トレースデータを定期的に分析し、パフォーマンスの傾向を把握。
これにより、システムのパフォーマンスや安定性を継続的に改善できます。
次に、「メトリクスの収集と監視」を執筆します。

メトリクスの収集と監視

メトリクスは、システムの健全性やパフォーマンスを継続的に把握するための重要なデータです。
OpenTelemetryを使用することで、メトリクスを簡単に収集し、監視ツールと統合してリアルタイムで管理できます。
このセクションでは、メトリクス収集の方法、監視のためのツール、収集したデータの活用方法について詳しく解説します。

OpenTelemetryによるメトリクス収集の仕組み

OpenTelemetryは、アプリケーションのメトリクスを自動的または手動で収集する仕組みを提供します。
メトリクスには、リクエスト数、エラーレート、レイテンシ、リソース使用率などがあります。
メトリクス収集の基本的な流れは以下の通りです：
1. 自動収集: OpenTelemetry SDKが、HTTPリクエストやデータベース操作などの標準的な操作からメトリクスを自動的に収集します。
2. 手動収集: カスタムメトリクスが必要な場合、APIを利用して収集します。
例えば、以下のようにカウンターを使用します：

Meter meter = OpenTelemetry.getMeter("my-app");  
LongCounter counter = meter.counterBuilder("requests_processed").build();  
counter.add(1);

このコードは、リクエスト処理のカウントを記録するメトリクスを作成します。

メトリクス監視ツールの選択と統合方法

収集したメトリクスを可視化するには、監視ツールとの統合が必要です。
以下は一般的なツールとその特徴です：
– Prometheus: オープンソースのメトリクス監視ツールで、データ収集とクエリ機能を提供。
– Grafana: メトリクスの可視化に特化したツールで、Prometheusと組み合わせて使用。
– AWS CloudWatch: クラウド環境のメトリクスをリアルタイムで監視可能。
統合は、エクスポーター設定を通じて行います。
たとえば、Prometheusとの統合では以下を設定します：

otel.exporter.prometheus.port=9464  
otel.exporter.prometheus.endpoint=/metrics

この設定により、PrometheusがOpenTelemetryのメトリクスを取得可能になります。

収集したメトリクスを活用したパフォーマンス分析

メトリクスを活用して、以下のようなパフォーマンス分析が可能です：
– トレンド分析: 過去のデータを元に、システム負荷の増加やリソース不足を予測。
– ボトルネックの特定: 高いレイテンシやエラー率を特定し、最適化の対象を明確化。
– リソース管理: メトリクスを基にCPUやメモリの使用状況を最適化。
これらの分析により、システムのパフォーマンスを向上させる具体的なアクションを導き出せます。

リアルタイムでのメトリクス監視とアラートの設定

リアルタイムでメトリクスを監視することは、システムの健全性を保つために重要です。
Grafanaなどのツールを使用すると、リアルタイムでダッシュボードを構築できます。
また、アラートを設定することで、問題が発生した際に迅速に対応できます。
たとえば、以下のようなアラートを設定します：
– レイテンシが特定の閾値を超えた場合に通知。
– CPU使用率が80%を超えた場合にアラートを発信。
このような設定により、潜在的な問題を早期に検知し、対応可能になります。

メトリクスデータを効率的に保存・管理する方法

メトリクスデータは、大量に生成されるため、効率的な保存と管理が求められます。
以下の方法が有効です：
– データ圧縮: 時系列データベース（例：InfluxDB）を使用し、ストレージを最適化。
– 保持ポリシーの設定: 古いデータを自動的に削除する設定を適用。
– データのアーカイブ: 長期的な分析のために、重要なメトリクスデータをアーカイブとして保存。
これにより、ストレージの無駄を省きつつ、必要なデータを適切に管理できます。
次に、「トラブルシューティング」を執筆します。

トラブルシューティング

OpenTelemetryを使用する際には、設定ミスや動作不良が原因で問題が発生することがあります。
これらの問題に迅速に対処するためのトラブルシューティングは、システムの可観測性を確保する上で重要です。
このセクションでは、OpenTelemetryのよくある問題とその解決方法、デバッグ手法、トラブルを回避するためのベストプラクティスを解説します。

よくある問題とその原因の特定

OpenTelemetryの導入時によく見られる問題として、以下が挙げられます：
– トレースやメトリクスがエクスポートされない: 設定ミスやエクスポート先の不具合が原因。
– エージェントが動作しない: Javaエージェントなどの設定が正しくない、またはライブラリの競合が発生している。
– データが重複して記録される: 自動計装と手動計装が重複している場合に発生。
これらの原因を特定するためには、ログやトレースビューアを活用して問題の詳細を確認する必要があります。

トラブル発生時の基本的なデバッグ手法

トラブルシューティングを行う際には、以下のデバッグ手法が有効です：
1. ログの確認: OpenTelemetryのログレベルを`DEBUG`に設定して詳細情報を取得します：

   OTEL_LOG_LEVEL=DEBUG

2. 設定ファイルの再確認: エクスポーター設定や環境変数の設定値を見直します。
3. 依存関係の競合を確認: プロジェクトの依存関係を確認し、バージョンの不一致や競合を解消します。
4. トレースビューアを利用: JaegerやZipkinでデータの送信状況を確認し、不足や誤送信がないかをチェックします。

エクスポート問題の解決方法

トレースやメトリクスがエクスポートされない場合、以下の解決策を試してください：
– エクスポーターの設定確認: 送信先のURLやポートが正しいことを確認します。
例えば、OTLPエクスポーターを使用している場合：

   otel.exporter.otlp.endpoint=http://localhost:4317

– ネットワーク問題の確認: サーバー間の接続が正常であることを確認します。
ファイアウォールやプロキシが通信を妨げている場合もあります。
– エクスポーターの動作確認: 別のツール（例：cURL）を使用して、エクスポート先にデータを送信できるかテストします。

パフォーマンス低下の原因と対処方法

OpenTelemetryの導入後にパフォーマンスが低下する場合、以下の対応が考えられます：
– サンプリング設定の調整: 全てのトレースを収集する代わりに、サンプリングを適用してデータ量を削減します：

   otel.traces.sampler=parentbased_always_off

– エクスポート間隔の最適化: メトリクスやトレースのエクスポート頻度を減らして負荷を軽減します。
– 不要な計装の削除: 必要のない操作やサービスの計装を無効化します。

トラブルを回避するためのベストプラクティス

問題を未然に防ぐためには、以下のベストプラクティスを実践することが重要です：
– 設定のバージョン管理: 設定ファイルや環境変数をソース管理ツールで管理し、変更履歴を追跡可能にする。
– 環境ごとのテスト: 開発環境と本番環境で設定を分け、事前にテストを行う。
– 監視ツールの活用: メトリクスやトレースデータを継続的に監視し、異常を早期に検出する。
これらの実践により、OpenTelemetryを安定して運用することが可能になります。

Spring Boot Starterを使用したOpenTelemetryの導入プロセス

OpenTelemetryとその基本的な役割についての詳細解説

OpenTelemetryとは何か、その目的と利点について

オープンソースプロジェクトとしての位置づけと歴史

分散トレーシングの基本概念とOpenTelemetryの関係性

メトリクスとログ収集を統合するOpenTelemetryの特徴

OpenTelemetryの導入がもたらすビジネス上のメリット