OpenTelemetry 関連のサービス・マッピングとインフラストラクチャー相関
このトピックでは、 OpenTelemetry のデータを手動で Instana に送信するお客様向けのガイダンスを提供します。
OpenTelemetry Collectorの Instana ディストリビューション（ IDOT ） をご利用の場合、 IDOT ではデフォルトでサービスのマッピングとインフラストラクチャの相関付けが自動的に処理されるため、手動での設定を行う必要はありません。
このドキュメントの手順に従うことで、 OpenTelemetry と Instana を連携させ、テレメトリデータを手動で送信する際に、包括的なサービスマッピングとインフラストラクチャの相関分析を有効にすることができます。 このドキュメントでは、 Instana 内で、特に Kubernetes 環境および IBM ミドルウェアにおいて、最適なデータ連携と可視性を実現するために、 OpenTelemetry の特定のリソース属性を活用する方法について説明します。
OpenTelemetry サービスのマッピング
Instana OpenTelemetry のセマンティック規約に準拠し、メトリクス、スパン、およびログをサービスにマッピングします。 これらの規約は、属性名と使用方法を標準化することで、オブザーバビリティ・ツール間の一貫性と相互運用性を促進します。 これらの標準に準拠することで、 Instana は、テレメトリデータを自社の監視および可観測性プラットフォームにシームレスに統合することを保証しています。
サービスマッピングで使用される主な属性は以下の通りです：
- リソースの属性
service.name - トレース・スパン属性
peer.service
リソースの属性 service.name
この service.name 属性は、 OpenTelemetry 内のサービスを一意に識別します。 各アプリケーション、マイクロサービス、またはコンポーネントには固有の識別子が割り当てられており、 service.name これによりテレメトリデータの効果的なフィルタリング、分析、および可視化が可能になります。 Instana サービスに service.name マッピングし、トレース、メトリクス、ログを発行元アプリケーションに関連付けます。 一貫性があり、内容を明確に表す命名規則 service.name を採用することで、 Instana 内での正確なグループ化と可観測性の向上が図られます。
OpenTelemetry, では、可観測性環境の具体的な要件に応じて、アプリケーションのさまざまなレベルでこの service.name 属性を設定できます。 次の表では、設定 service.name 方法のさまざまな例を確認できます：
| レベル | 定義方法 | 例 | ユース・ケース |
|---|---|---|---|
| アプリケーション・コード | 手動による計測設定をアプリケーション内で直接行う | service.name="orders-service" |
アプリケーション内で がハードコーディング service.name されているか、設定されている場合 |
| 環境変数 | 環境 OTEL_SERVICE_NAME 変数を使用することで |
OTEL_SERVICE_NAME=payments-service |
複数のサービスにわたって自動インスツルメンテーションを使用する環境では一般的です |
| リソース属性 | キーと値のペアを使用して OTEL_RESOURCE_ATTRIBUTES |
OTEL_RESOURCE_ATTRIBUTES=service.name=inventory-service |
次のような他の属性と service.name 組み合わせるのに便利です host.id |
| コレクター構成 | OpenTelemetry のCollectorで、processor resource を使用する場合 |
service.name: shipping-service |
テレメトリデータがバックエンドに送信される前の集中管理 |
トレース・スパン属性 peer.service
OpenTelemetry, において、この peer.service 属性は、スパンが接続するリモートサービスの名前を指定し、データベース、メッセージブローカー、その他のマイクロサービスといった外部依存関係を特定するのに役立ちます。 Instana Instanapeer.service サービスにマッピングし、サービスの依存関係や相互作用を可視化します。
- 計測ライブラリ ：一部のライブラリは、適切に設定されると自動的に
peer.service設定されます。 例:- JDBC ： OpenTelemetry JDBC インストルメンテーションは、データベース接続の詳細から
peer.serviceこれを推測できます。 - HTTP クライアント ： Apache や HttpClient などの HTTP ライブラリは、リモートサービスのホスト名
peer.serviceに基づいて派生させることができます。
- JDBC ： OpenTelemetry JDBC インストルメンテーションは、データベース接続の詳細から
次の表では、 OpenTelemetry: における設定や構成 peer.service のさまざまな方法を確認できます
| レベル | 説明 | 例 | ユース・ケース |
|---|---|---|---|
| アプリケーション・コード | OpenTelemetry を使用して、コード peer.service 内で直接属性を設定します。 API |
span.setAttribute("peer.service", "backend-service") |
対象のサービスに関する具体的な知識があり、独自の名前を付けたい場合 |
| 設定ファイル （システムプロパティ） | OpenTelemetrypeer.service エージェントまたはSDKで使用されるシステムプロパティの値を定義します |
otel.instrumentation.common.peer-service-mapping: "api.example.com=example-api-service,1.2.3.4=cats-service" |
設定ファイル内で、特定のホスト名やIPアドレス、あるいはその両方をサービス名に割り当てたい場合 |
| 環境変数 | その peer.service 値を、アプリケーションからアクセス可能な環境変数として設定してください |
OTEL_INSTRUMENTATION_COMMON_PEER_SERVICE_MAPPING="api.example.com=example-api-service,1.2.3.4=cats-service" |
実行時の状況やデプロイ環境に応じて値を peer.service 動的に設定する必要がある場合（システムプロパティと同様ですが、環境変数を使用します） |
| 計測ライブラリ | OpenTelemetry ライブラリによって自動的に設定されます | peer.service="postgresql" |
データベースや HTTP クライアントなどの一般的なライブラリでは、これが自動的に peer.service 設定されるのが一般的です |
一般的なプロトコルのサービスマッピング
OpenTelemetry は peer.serviceservice.name 、やといった一般的な属性に加え、 HTTP、 RPC、データベース、メッセージングシステムなど、よく知られたプロトコルに関する包括的な意味論的規約を定義しています。
プロトコルの完全な一覧については、『 Trace Semantic Conventions 』を参照してください。
HTTP span属性
OpenTelemetry HTTP のspan要素に対して、トレースシステム全体での一貫性を保つためのセマンティックな規約を提供します。これには、 HTTP のリクエストやレスポンスに関する情報を提供する属性も含まれます。
次の表では、 OpenTelemetry: で span 属性を設定または構成 http するさまざまな方法を確認できます
| 属性 | 説明 | 例 |
|---|---|---|
http.method |
HTTP メソッド（GET、 POST ） | http.method="GET" |
http.route |
HTTP リクエストのルートまたはパス | http.route="/webshop/articles/:id" |
url.path |
URL の完全なパス構成要素 | url.path="/webshop/articles/4" |
http.host |
サーバーのホスト名 | http.host="api.example.com" |
http.target |
リクエストの URL をターゲットとする | http.target="/users" |
や http.host では多くの http.target 場合、サービスを推測できますが、動的ルーティングやサービスディスカバリでは、正確なマッピングを行うために、設定ファイルやサービスレジストリからの追加情報が必要になる場合があります。
リモートプロシージャコールは属性をまたがる
OpenTelemetry トレースシステム間で一貫性を保つため、リモートプロシージャコール（ RPC ）のスパンに対するセマンティックな規約を定義し、洞察を得るための属性も含まれています。 OpenTelemetry でのサービスマッピングに使用される主要な RPC の span 属性は、以下の通りです：
- rpc.method ：呼び出されるメソッドまたは関数を指定し、その操作に関する詳細情報を提供します。
- rpc.service ：呼び出されるサービスの名前を識別します。これは、 RPC の呼び出しを特定のサービスにマッピングするために不可欠です。
| 属性 | 説明 | 例 |
|---|---|---|
rpc.service |
リモートサービスの名前 | rpc.service="user-service" |
rpc.method |
呼び出されるメソッドまたは関数 | rpc.method="GetUserInfo" |
や を peer.service、 rpc.serviceRPCrpc.method などの他の属性と組み合わせることで、への呼び出しを対応するサービスにマッピングすることができます。
データベースのスパン属性
OpenTelemetry データベース・スパンに対してセマンティックな規約を定義し、トレースシステム間の一貫性を維持するとともに、データベースの操作や相互作用に関する有益な知見を提供する主要な属性を提供します。 これらの知見は、分散アプリケーションにおけるデータベースシステムのパフォーマンスや動作を理解する上で不可欠です。
次の表は、 OpenTelemetry におけるサービスマッピングに使用される主要なデータベーススパン属性です。
| 属性 | 説明 | 例 |
|---|---|---|
db.system |
データベースシステム（例： MySQL、 PostgreSQL ） | db.system="mysql" |
db.instance |
データベース・インスタンス名または識別子 | db.instance="my_database" |
db.name |
アクセスされるデータベースの名前 | db.name="users_db" |
db.statement |
実行されたSQLクエリまたはデータベースコマンド | db.statement="SELECT * FROM users" |
db.operation |
データベース操作の種類（例：SELECT、INSERT） | db.operation="SELECT" |
これらの属性は主にデータベースとのやり取りを記述するものですが、間接的にサービスのマッピングにも役立ちます。 たとえば、この db.instance 属性は、特定のデータベース・インスタンスとやり取りしているサービスを特定するのに役立つ可能性があります。
メッセージのスパン属性
OpenTelemetry メッセージング・スパンに対して、トレースシステム全体での一貫性を維持するためのセマンティックな規約を提供し、これには有益な情報を提供する属性も含まれます。
OpenTelemetry におけるサービスマッピングに使用される主要な Messaging span 属性は、以下の通りです：
| 属性 | 説明 | 例 |
|---|---|---|
messaging.system |
使用しているメッセージングシステム（例： Kafka、 RabbitMQ,、AMQP） | messaging.system="kafka" |
messaging.destination |
宛先アドレス（例：トピック名やキュー名など） | messaging.destination="user-events" |
messaging.operation |
実行された操作（例：SEND、RECEIVE、PUBLISH、SUBSCRIBE） | messaging.operation="SEND" |
これらの属性は、サービスが連携するメッセージングシステムや、使用する特定のトピックやキューに基づいて、サービスをマッピングするのに役立ちます。 たとえば、あるサービスが特定の Kafka トピックにメッセージを送信することがわかっている場合、この messaging.destination 属性を使ってそのサービスを特定することができます。
OpenTelemetry 関連インフラの相関関係
Instana OpenTelemetry のリソース属性および OpenTelemetry の「リソースのセマンティック規約」に記載されている多くの一般的な定義をサポートしています。 Instana OpenTelemetry のサービスフローとリソースをインフラストラクチャ・エンティティとして表示します。 これらのエンティティは、トレーススパンやログレコードに加え、プロセス、ホスト、コンテナなどの物理エンティティにも関連付けることができます。特に、 Instana エージェントが同じホスト上で実行されている場合は、そのように設定できます。
言語ベースの OpenTelemetry 自動インスツルメンテーションを使用している場合は、最新の OpenTelemetry エージェントをご利用ください。 最新のエージェントは、エンティティ、スパン、およびログレコード間の関連付けを確立するのに十分なリソース属性を生成します。
service.name に加え service.instance.id、リンクには以下のリソース属性が不可欠です：
Kubernetes 環境では、リソース k8s.pod.uid 属性は、 OpenTelemetry エンティティを Kubernetes ポッドに関連付ける上で極めて重要です。 これにより、これらのポッドに関連するスパン、ログ、メトリクス間の関連性が確立され、アプリケーションとインフラストラクチャのパフォーマンスを一元的に把握できるようになります。
相関戦略
Instana 利用可能なテレメトリデータに応じて、 OpenTelemetry のスパンとインフラストラクチャエンティティを関連付けるために、さまざまな戦略を採用しています：
戦略 1： OpenTelemetry のトレースとメトリクス（推奨）
サービスが OpenTelemetry のトレースとメトリクスの両方を送信する場合、以下の処理が行われます：
- Instana メトリクスデータから OpenTelemetry エンティティを作成します。
- OpenTelemetry spans は、resource 属性の
service.nameservice.instance.idおよび を使用して、自動的にこの OpenTelemetry エンティティにリンクされます。 このプロセスにより、以下の関連付けの連鎖が確立されます： OpenTelemetry span > OpenTelemetry entity。
OpenTelemetry エンティティは、さまざまなリソース属性を使用して、対応する既存のインフラストラクチャエンティティと関連付けます：
k8s.pod.uid- 「 Kubernetes 」ポッドへのリンク。相関チェーン： OpenTelemetry スパンの > OpenTelemetry エンティティ > Kubernetes ポッド > その他のインフラストラクチャ Kubernetes エンティティ
container.id- コンテナエンティティへのリンク。相関チェーン： OpenTelemetry スパン > OpenTelemetry エンティティ > コンテナエンティティ > その他のインフラストラクチャエンティティ
process.pidおよびhost.id- エンティティを処理するためのリンク。相関チェーン： OpenTelemetry スパン > OpenTelemetry エンティティ > Processエンティティ > その他のインフラストラクチャエンティティ
host.id- ホストエンティティへのリンク。相関チェーン： OpenTelemetry スパン > OpenTelemetry エンティティ > ホストエンティティ
同じサービスからのメトリクスとトレースの間で、リソース属性が一致していることを確認してください。 これらのリソース属性の設定方法については、 「設定例」 を参照してください。
戦略 2: OpenTelemetry のトレースのみ（ OpenTelemetry Collector を使用）
アプリケーションがメトリクスではなくトレース（スパン）のみを送信している場合は、Collector OpenTelemetry の spanmetrics コネクタ を使用して、スパンからメトリクスを生成してください。 これにより、戦略1と同じ相関戦略が可能になります。
connectors:
spanmetrics: null
service:
pipelines:
metrics:
receivers:
- spanmetrics
traces:
exporters:
- spanmetrics戦略 3： IBM ミドルウェアを使用した OpenTelemetry トレースのためのインフラストラクチャの連携
Instana OpenTelemetry のトレース機能と、 IBM ミドルウェア（ IBM MQ、 IBM App Connect Enterprise （ACE）、 IBM DataPower など）を連携させるためのインフラストラクチャを提供します。
- IBM MQ への呼び出しについては、 Instana IBM MQ センサーによって収集されるキューエンティティにリンクすることができます。
- IBM ACE への呼び出しについては、 Instana の「 IBM ACE 」センサーによって収集されるメッセージフローエンティティにリンクすることができます。
- IBM DataPower への呼び出しについては、 Instana の「 IBM DataPower 」センサーによって収集されたドメインエンティティにリンクすることができます。
通常、 OpenTelemetry から IBM ミドルウェアへの呼び出しに対するインフラストラクチャのリンクは自動的に作成されるため、追加の設定は不要です。 これらのリンクは通話詳細ページに表示されます。
次の例は、 IBM MQ キューエンティティへの Q1OpenTelemetry 呼び出しにおけるインフラストラクチャのリンクを示しています：
戦略 4：プロセスエンティティを用いた OpenTelemetry トレースのためのインフラストラクチャの相関付け
processprocess.pid、host.id、およびentity.type（値は ）相関チェーン： OpenTelemetry スパン > プロセスエンティティ > その他のインフラストラクチャエンティティ
process.pid制限事項：Kubernetes 環境では、この戦略を確実に適用することは困難です。その理由は、ほとんどの OpenTelemetry SDKがコンテナ内のプロセスID（PID）を提供しているのに対し、 Instana のプロセスエンティティは、インフラストラクチャの相関付けを行うためにホストレベルのプロセスPIDを使用するためです。
構成例
OpenTelemetry の公式デモでは、、 k8s.pod.uidservice.instance.id、、およびその他の OpenTelemetryservice.nameリソース属性の設定に関するベストプラクティスを紹介しています。
OpenTelemetry （ OTel ）の手動インスツルメンテーションを使用するアプリケーションでは、通常、は service.name アプリケーションコード内で定義されます。 ただし、 OTel の自動インスツルメンテーションを使用する場合は、環境 OTEL_SERVICE_NAME 変数（すべての言語用SDKでサポートされています）または を使用して設定する必要があります OTEL_RESOURCE_ATTRIBUTES。 以下の例は、それらの使い方を示しています：
- env:
- name: OTEL_SERVICE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.labels['app.kubernetes.io/component']
- name: OTEL_RESOURCE_ATTRIBUTES
value: service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo、 container.id、および k8s.pod.uid service.instance.idリソース属性を追加するには、 OpenTelemetry コレクターの および k8sattributes resource プロセッサを使用します。 トレースとメトリクスの両方を Instana まで送信してください。
OpenTelemetry のSDKでは、通常、resource process.pid 属性が自動的に設定されます。
OpenTelemetry のデータを Instana バックエンドに直接送信する場合にのみ、resource host.id 属性を指定する必要があります。 詳細については、 「 OpenTelemetry のデータを Instana バックエンドに送信する」 を参照してください。 OpenTelemetry のデータを Instana エージェントに送信する際、を指定 host.id する必要はありません。
アプリケーションがメトリクスではなくトレース（スパン）のみを送信する場合は、この spanmetrics コネクタを使用してください。 Instana OpenTelemetryspanmetrics エンティティを生成するために使用され、アプリケーションのスパンとインフラストラクチャエンティティ（ Kubernetes のポッドや物理ノードなど）との関連付けを可能にします。 spanmetrics Instana 内で完全な連携と可視性を確保するのに役立ちます。
以下の例は、インフラストラクチャの相関分析を最適化するために、 OpenTelemetry コレクターをプロセッサ k8sattributes 、 resource プロセッサ、および spanmetrics コネクタと組み合わせて設定する方法を示しています：
connectors:
spanmetrics: null
exporters:
otlp:
endpoint: instana-agent.instana-agent:4317
tls:
insecure: true
processors:
batch: {}
k8sattributes:
extract:
metadata:
- k8s.namespace.name
- k8s.deployment.name
- k8s.statefulset.name
- k8s.daemonset.name
- k8s.cronjob.name
- k8s.job.name
- k8s.node.name
- k8s.pod.name
- k8s.pod.uid
- k8s.pod.start_time
- container.id
passthrough: false
pod_association:
- sources:
- from: resource_attribute
name: k8s.pod.ip
- sources:
- from: resource_attribute
name: k8s.pod.uid
- sources:
- from: connection
resource:
attributes:
- action: insert
from_attribute: k8s.pod.uid
key: service.instance.id
receivers:
otlp:
protocols:
grpc:
endpoint: ${env:MY_POD_IP}:4317
http:
cors:
allowed_origins:
- http://*
- https://*
endpoint: ${env:MY_POD_IP}:4318
service:
pipelines:
logs:
exporters:
- otlp
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp
metrics:
exporters:
- otlp
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp
- spanmetrics
traces:
exporters:
- otlp
- spanmetrics
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp- OpenTelemetry （ OTel ）のアプリケーションですでにメトリクスが生成されている場合は、
spanmetricsコネクタを設定する必要はありません。 - パイプライン内で、この
k8sattributesプロセッサがあのresourceプロセッサの前に配置されていることを確認してください。 - プロセッサ
k8sattributespassthroughの属性を に設定しますfalse。 - プロセッサ
resourceは、エンティティを正しく識別するために、をservice.instance.idにk8s.pod.uidコピーします。 - OpenTelemetry
service.nameのSDKですでに提供されている場合は、そのまま使用し続けても構いません。 コレクターの設定でこれを上書きする必要はありません。 SDKで設定されていない場合、または複数のサービス間で命名規則を統一する必要がある場合にのみ、コレクター側でservice.name設定してください。
インフラストラクチャの相関関係が欠落している場合のトラブルシューティング
OpenTelemetry エンティティとの関連性が欠落しています
OpenTelemetry のスパンが OpenTelemetry のエンティティにリンクされていない場合は、以下の確認を行ってください：
- OpenTelemetry エンティティが存在することを確認してください：
- Instana のUIで、 [Infrastructure] > [Analyze Infrastructure] をクリックします。
- エンティティ・タイプの一覧から「 OpenTelemetry 」を選択してください。
- タグフィルターとして
service.instance.idまたはservice.nameを使用し、対応する OpenTelemetry エンティティを検索します。 - エンティティが存在しない場合は、サービスが OpenTelemetry メトリクス（トレースだけでなく）を送信していることを確認してください。
- リソースの属性が一致していることを確認する：
- OpenTelemetry のスパンにある および
service.instance.idリソースservice.name属性が、 OpenTelemetry エンティティの およびservice.instance.idservice.nameの値と一致していることを確認してください。 - OpenTelemetry コレクターを複数のパイプラインで使用する場合、同じサービスに対して、各パイプライン間でプロセッサの設定
resourceが一致していることを確認してください。
- OpenTelemetry のスパンにある および
Kubernetes ポッドとの相関関係が欠落しています
OpenTelemetry のスパンが Kubernetes のポッドと関連付けられていない場合は、以下の確認を行ってください：
- OpenTelemetry エンティティが存在することを確認してください：
- Instana のUIで、 [Infrastructure] > [Analyze Infrastructure ] > [ OpenTelemetry ] をクリックします。
- または
service.nameを使用してservice.instance.id、 OpenTelemetry エンティティをフィルタリングし、検索してください。
- 「 Kubernetes 」ポッドが「 OpenTelemetry 」エンティティのブレッドクラムに表示されているか確認してください：
- 「 OpenTelemetry 」エンティティの詳細を開きます。
- ページ上部のパンくずリストをご確認ください。
- パンくずリストに「 Kubernetes 」のポッドが表示されていれば、相関関係は正常に機能しています。
- Instana に ` Kubernetes ` ポッドが存在することを確認してください：
- Instana のUIで、 [Infrastructure ] > [Analyze Infrastructure ] > [Pods] をクリックします。
- [フィルター] を使用して
k8s.pod.uid、特定のポッドを検索します。 - ポッドが存在しない場合は、 Instana エージェントが同じ Kubernetes クラスター内で実行されていることを確認してください。
- OpenTelemetry データの値
k8s.pod.uidが、 Kubernetes にある実際のポッドの UID と一致していることを確認してください。
プロセスエンティティとの相関関係が欠落しています
OpenTelemetry のスパンがプロセスエンティティと関連付けられていない場合は、以下の確認を行ってください：
- 以下が
process.pid正しいことを確認してください：- Kubernetes 環境では、コンテナ内のPIDではなく、ホストレベルのプロセスPIDを使用するようにしてください。
- Instana のUIで、 [Infrastructure] > [Analyze Infrastructure ] > [Processes] をクリックします。
- プロセスエンティティの詳細を開き、左側のパネルでプロセスID を確認してください。
- OpenTelemetry
process.pidのスパンが、この値と一致していることを確認してください。
- 以下が
host.id正しいことを確認してください：- プロセスエンティティの詳細ページから、上部のパンくずリストを使用して、対応するホストエンティティに移動します。
- ホストエンティティの詳細画面の左パネルで、 ホストID を確認してください。
- OpenTelemetry
host.idのスパンが、この値と一致していることを確認してください。
コンテナエンティティとの関連性が欠落しています
OpenTelemetry のスパンがコンテナエンティティと関連付けられていない場合は、以下の確認を行ってください：
- OpenTelemetry エンティティが存在することを確認してください：
- Instana のUIで、 [Infrastructure] > [Analyze Infrastructure ] > [ OpenTelemetry ] をクリックします。
- または
service.nameを使用してservice.instance.id、 OpenTelemetry エンティティをフィルタリングし、検索してください。
- コンテナが「 OpenTelemetry 」エンティティのブレッドクラムに表示されているか確認してください：
- 「 OpenTelemetry 」エンティティの詳細を開きます。
- そのエンティティのパンくずリストを確認してください。
- パンくずリストにコンテナが表示されていれば、関連付けは正常に機能しています。
- Instana にコンテナエンティティが存在することを確認してください：
- Instana のUIで、 [Infrastructure] > [Analyze Infrastructure] をクリックします。
- 「 コンテナ 」を検索し、サポートされているコンテナランタイム（例：Containerd、 CRI-O、 Docker、 OTel、 Kubernetes、または Podman ）のいずれかを選択してください。
- [フィルター]
containerIdを使用して、特定のコンテナを検索します。 - コンテナが存在しない場合は、 Instana エージェントが同じホスト上で実行されていることを確認してください。
- OpenTelemetry
container.idのデータにある値が、実際のコンテナIDと一致していることを確認してください。
IBM ミドルウェアへの呼び出しにおいて、インフラストラクチャの相関関係が欠落しています
IBM ミドルウェアの OpenTelemetry トレースによって収集されたホスト名が、 Instana ミドルウェアセンサーによって収集されたホスト名と異なる場合、 InstanaInfrastructure: Correlation missing のUIにエラーメッセージが表示されることがあります。
IBM ミドルウェアがデプロイされている環境に応じて、この問題は OpenTelemetry の設定、または IBM ミドルウェアの設定で解決できます：
OpenTelemetry 設定
- Kubernetes 以外の環境
IBM ミドルウェアが標準の仮想マシン（ VM ）にデプロイされている場合、 OpenTelemetry への呼び出し用にホストエイリアスを次のように設定します：
この問題を解決するには、以下の手順に従って、 OpenTelemetry への呼び出しに対してホストエイリアスを設定してください：
IBM MQ、 IBM ACE、または IBM DataPower を実行しているサーバー上で、それぞれのサービスを停止し、環境変数をエクスポートします：
OTEL_RESOURCE_ATTRIBUTES=host.alias=<alias_of_the_host><alias_of_the_host> を、 Instana ミドルウェアセンサーによって収集されたホスト名に置き換えてください。
たとえば、 Instana IBM MQ のセンサーがホスト名を収集し、 IBM MQ OpenTelemetry
instmq1.example.comのトレースがホストの IP アドレスを収集する場合、変数は次のようにエクスポートする必要があります：OTEL_RESOURCE_ATTRIBUTES=host.alias=instmq1.example.comIBM MQ、 IBM ACE、または IBM DataPower を再起動してください。
- Kubernetes環境
IBM ミドルウェア（ IBM ACE、 IBM MQ、 DataPower など）を Kubernetes クラスタにインストールすると、それらはコンテナ内で実行されます。これは、標準的な VM 環境とは異なります。 VMとは異なり、コンテナは動的なホスト名やIPアドレスを持つため、 Instana では監視対象外の呼び出しが発生したり、インフラストラクチャの相関関係が正しく把握できなくなったりします。
この問題を解決するには、以下のステップを実行します。
IBM ミドルウェアのカスタムリソース（CR）インスタンスで環境変数をエクスポートします。 CRの設定ファイルの `deployment/demonset` セクションに、以下の環境変数を追加してください：
spec: containers: - env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: OTEL_RESOURCE_ATTRIBUTES value: "host.alias=$(POD_IP)"CRが関連するデプロイメントと再同期されるまでお待ちください。
必要に応じて、 IBM MQ、 IBM ACE、または IBM DataPower を再起動してください。
この設定により、各 IBM ミドルウェアコンテナが自身の POD_IP を host.alias 値として保持するようになり、インフラストラクチャの適切な相関関係が確保されます。
IBM ミドルウェアの設定
IBM App Connect Enterprise 統合サーバーでは、統合サーバー内のすべてのメッセージフローに対して OpenTelemetry トレースを設定し、スパンデータを OpenTelemetry コレクターにエクスポートすることができます。
ファイル server.conf.yaml のセクション ResourceManagers にあるサブ OpenTelemetryManager セクションで、テレメトリ・スパ openTelemetryHostName ンの属 Hostname 性を上書きするようにプロパティを設定します。 詳細については、 「統合サーバーの OpenTelemetry トレースの設定」 を参照してください。
OpenTelemetry に関するその他のリソース
- 実際の設定例。
- トラブルシューティングガイド。
- さまざまなテクノロジーの統合パターン。
- コミュニティから寄せられた解決策。