ホスティングプラットフォーム向けOpenTelemetry：トレースを安全に運用する

OpenTelemetry、シグナル、バックエンドを明確に区別する

OpenTelemetry, （通称OTel）は、モニタリングポータルではなく、テレメトリデータを永続的に保存することもありません。 これは、仕様、API、SDK、計測機能、OpenTelemetry Protocol（OTLP）、およびコレクターからなる、ベンダー中立な統合プラットフォームです。アプリケーションはこのプラットフォームを利用してデータを生成、処理、エクスポートしますが、検索、保存、権限管理、アラート通知は、選択されたバックエンドの役割のままです。

その3人 信号 さまざまな運用上の疑問に答えます。トレースはリクエストの個々のステップを時間的・論理的に整理し、メトリクスは状態を測定データ系列として集約し、ログは個々のイベントを記録します。 堅牢なオブザーバビリティの実践では、これらを組み合わせて活用します。トレースは異常なリクエストを特定し、メトリクスはその発生頻度を時間軸に沿って示し、関連付けられたログはエラーメッセージや追加の詳細情報を提供します。

ホスティング・プラットフォームにとっては、ここから明確な役割分担が導き出されます。OTelはテレメトリの生成と共有を統一しますが、ターゲットシステムに取って代わるものではありません。 したがって、計測機能の導入に先立ち、各チームは、どのバックエンドがどのデータを受け入れるか、そのデータがどのくらいの期間必要か、そして誰がそのデータを閲覧できるかを明確に定義しておく必要があります。こうした決定があって初めて、技術的なデータ出力経路やデータ量を適切に管理できるようになるのです。

ホスティングの境界を越えてトレースコンテキストを渡す

分散トレースは、プロセスやネットワークの境界を越えて、論理トランザクションの各ステップを結びつけます。ある トレースコンテキスト これには、プロセス全体のトレースIDや、個々の操作のスパンIDなどが含まれています。スパンは親子関係を形成することができ、これらが組み合わさることで、観測された作業の有向非循環グラフが記述されます。

HTTPでは、このコンテキストは通常、W3C Trace Contextとして渡されます。特にヘッダー内で traceparent. サービスは受信側のコンテキストを受け取り、自身の処理部分に対応するスパンを生成します。発信側の呼び出しを行う際には、そのコンテキストを再度渡す必要があります。これが制御可能な遷移で行われない場合、バックエンドでのリクエストは個別のトレースに分割されてしまいます。

チェックアウトの際、リバースプロキシがリクエストをアプリケーションに転送することがあります。アプリケーションは、キャッシュを確認したり、データベースにクエリを実行したり、決済サービスやメールAPIを呼び出したりします。これらの移行箇所に計測機能を組み込み、コンテキストを伝播させれば、トレースを通じてこれらのステップの順序を追跡することができます。 キューやバックグラウンドジョブについても、コンテキストがメッセージに付随して渡され、コンシューマー側で復元される限り、同じ原理が適用されます。

しかし、長い外部HTTPスパンは、計測対象となったこの操作の観測された所要時間を示すに過ぎません。それがDNS、ネットワーク、再試行、相手側、あるいは自社システムの負荷のいずれが原因であったかを証明するものではありません。 したがって、トレースは診断の出発点に過ぎず、原因の特定には、適切なメトリクスやログ、および関連コンポーネントの技術的な検証が必要となります。

ホスティングモデルがOTelの裁量の幅を決定する

OpenTelemetryが実用可能かどうかは、まずホスティングモデルによって決まります。最低限の要件として、アプリケーションの設定、あるいは少なくとも環境変数を制御できることが必要です。SDKは、言語の実装に応じて、プログラム経由または環境設定によって構成できますが、実際にサポートされている範囲については、使用する言語とバージョンを確認する必要があります。

VPS、専用サーバー、およびコンテナ上では、コレクター、ネットワークパス、プロセス環境を通常は自分で制御できます。公式のサンプルでは、ローカルのOTLP受信者に対して以下のポートが指定されています。 4317 gRPC用および 4318 HTTPの場合。ただし、これをもって一般的な開放推奨となるわけではありません。本番環境でのアクセス可能性、ファイアウォールルール、および認証は、それぞれのプラットフォームに合わせて設定する必要があります。

一方、従来の共有ホスティングでは、常時稼働するコレクターや、自動インスツルメンテーションのためのプロセスインジェクションに必要な権限が不足していることがよくあります。ゼロコードソリューションは複数の言語エコシステム向けに存在しますが、その利用可能性は実行時間、デプロイ方法、およびプラットフォームの承認状況によって異なります。 したがって、OTelの機能に基づいて計画を立てるのではなく、具体的なホスティング環境において許可されている設定方法やエクスポート方法に基づいて計画を立てるようにしてください。

計装と職務のアイデンティティを戦略的に計画する

まずは、理解しやすい 職務上のアイデンティティ. リソースは、サービスやその実行環境など、テレメトリを生成するエンティティを表します。これに使用されるリソース属性は、管理された形で一貫性を持って定義してください。具体的にどの属性が自動的に利用可能か、あるいは追加で設定が必要かは、言語の実装、計測手法、およびバージョンによって異なります。

その後、実際に使用されている言語のランタイムとそのバージョンについて、ゼロコードまたは自動インスツルメンテーションを確認してください。 OpenTelemetryのドキュメントには、Java、JavaScript、.NET、PHP、Python、Goなどに対する対応手法が記載されています。これらは多くの場合、HTTP、データベース、またはクライアントライブラリの境界を捕捉しますが、その範囲、成熟度、およびサポートされるライブラリは実装ごとに異なります。

自動生成されたスパンは、主に技術的な遷移を示します。 「注文承認」や「請求書作成」といった業務上のステップについては、診断に関連する場合に限り、コード内に適切な計測ポイントを追加してください。これにより、すべての関数呼び出しにテレメトリ情報を過剰に付与することなく、どの操作で処理が失敗しているかを特定できるようになります。

その他のリソース属性には、ホスト、プロセス、コンテナ、Kubernetes環境に関する情報などが含まれる場合があります。言語実装が自動的に設定する属性や、適用されるセマンティックな規約については、SDK、インストルメンテーション、バージョンごとに個別に確認する必要があります。 同じ実行環境の識別が追跡可能となるよう、値は管理されたデプロイメントメタデータから取得する必要があります。

複数の顧客プロジェクトにおいて、命名規則はクライアントおよび展開コンセプトの一部となります。テレメトリによって、プロジェクトが誤って統合されたり、共通の属性を通じてアクセスが容易になったりしてはなりません。アプリケーションアーキテクチャ、分離、スケーリングがどのように関連しているかについては、以下の記事でも解説されています。 マルチテナント対応のSaaSホスティング. テレメトリ自体については、業務上必要であり、かつ個人情報保護法の観点から審査済みの場合に限り、顧客固有の識別子を収集すること。

コレクターアーキテクチャと安全なエクスポート

ダイレクトエクスポートでは、各アプリケーションがOTLPデータを指定されたバックエンドに直接送信します。 これにより、追加のコンポーネントを省くことができますが、宛先アドレス、アクセスデータ、およびエクスポート設定が複数のデプロイメントに分散されます。この方式は、バックエンドへのアクセスが確実であり、エクスポート前の中央処理を必要としない、小規模で明確に区切られた環境に適しています。

地元の コレクター ホストまたはポッドごとに、アプリケーションに近い場所でテレメトリデータを受信します。アプリケーションはローカルエンドポイントにデータを送信し、コレクターがデータを集約して、再送信、処理、転送を行います。Linuxホストの場合、このドキュメントでは、このパターンをアプリケーションを localhost 送信してもらう。

一方、中央のゲートウェイ・コレクターは、バックエンドへの接続、ルーティング、および統一された処理ルールを一元化します。しかし、これにより運用上の依存関係が追加されるため、これを確実に確保し、容量に見合った計画を立てる必要があります。 大規模な環境では、すべてのアプリケーションを中央のインスタンスに直接接続する代わりに、ローカルコレクターとゲートウェイを組み合わせることも可能です。

非生産的な例として、レシーバーがOTLPを受信し、設定されたパイプラインがテレメトリを処理し、エクスポーターがそれをバックエンドに転送します。 OTelの概要では、基本的に個人情報のエンリッチメント、変換、およびクリーニングもコレクターのタスクとして説明されています。ただし、どの具体的なコンポーネントがシグナルをサポートしているか、またその成熟度はどの程度であるかは、選択したコレクターのディストリビューションおよびバージョンごとに個別に確認する必要があります。

地域の事例で頻繁に使用されるOTLPポート 4317 gRPC用および 4318 HTTPについては、本番環境での運用に対する一律の許可は設定されていません。 セキュリティゾーン、ファイアウォールルール、およびプラットフォームのガイドラインに基づいてアクセス設定を定義してください。S14では、コンポーネントが追加の権限を必要としない限り、安全で認証された接続、およびroot権限や管理者権限を使用しない運用を推奨しています。S14は可変的な開発ブランチを main 記載されている場合、これらの仕様は、使用前に実際に使用されるCollectorバージョンのドキュメントと照合する必要があります。

負荷および故障パターンに応じたサンプリングの選択

フル収集によって生成されるテレメトリデータが過剰になる場合、サンプリングによって、どのトレースを保存またはさらに処理するかを決定します。まずは事前にテスト済みの小さなサンプリング率から始め、バックエンドにおける典型的なリクエスト、エラー、およびレイテンシの異常値が依然として十分に把握できるかどうかを確認してください。 適切なサンプリング率は一概に決まるものではなく、トラフィック、診断目的、およびデータ保持期間によって異なります。

時点では ヘッドサンプリング 決定はトレースの開始時に行われます。親ベースの比率に基づく戦略では、親スパンのサンプリング決定を引き継ぎ、新しいルートに対して割当率を決定します。これにより選択の根拠が明確になりますが、後から判明したエラーを、以前に除外されたトレースに事後的に組み込むことはできません。

テールサンプリングは、コレクターに受信されたトレースデータを、設定されたポリシーに基づいて分析します。S12は、動的な開発ブランチのみを表示します。 main また、このプロセッサはトレース用のベータ版であり、状態依存型であると指定されています。この段階には、トレースサイズの制限や内部シャードなど、複数の決定戦略と容量オプションが含まれています。これらは、特定の安定版リリースにおける保証された特性ではありません。 したがって、本番環境での運用には、まずCollector Contribのバージョンとディストリビューションを決定し、その後、それらのバージョンに紐づくオプション、デフォルト値、およびリソース要件を確認する必要があります。

記録された main- 効果的なサンプリング判定を行うためには、トレース内のすべてのスパンが同一のコレクタインスタンスに到達する必要があります。プロセッサはデフォルトでデータをメモリに保持しており、そこに記述された tail_storage-この拡張機能は実験的なものであり、フィーチャーゲートによって制限されており、すべてのシャーディング構成と組み合わせられるわけではありません。これらの情報はあくまで検証の参考としてのみ提供されています。リリースの予定が確定していないため、これに基づいて信頼性の高いルーティングの構想を立てたり、本番環境への導入を承認したりすることはできません。

エクスポート前の機密テレメトリを制限する

テレメトリは、その内容が限定されている場合にのみ、運用上有用です。Baggageは、サービスやプロセスをまたいで自由に選択したキー・値ペアを伝播させ、トレース、メトリクス、またはログとして利用可能にすることができます。 これにより、機密性の高いBaggageの値が、意図せず下流のリソースや外部リソースに到達してしまう可能性があります。そのため、サービス間で情報を共有する前には、その内容を必ず確認してください。

時点では 手荷物 この範囲は特に重要です。個人データ、セッションID、パスワード、APIキーなどはこれに含まれません。 技術的な割り当てのために、すべてのトランジションで必ずしも必要とされない値は、Baggageとして作成すべきではありません。そうしないと、ネットワーク呼び出しにおける自動的な値の受け渡しにより、その値を処理できるシステムの範囲が拡大してしまいます。

データの最小化は、計測の段階から始まります。具体的な診断に必要なフィールドのみを収集してください。 さらに、アプリケーションやライブラリに依存するスパン属性、ログフィールド、URL、ヘッダー、データベース情報については、本番環境以外のサンプルデータを使用して確認してください。これは慎重なアーキテクチャ上のルールであり、実際にどの内容が収集されるかは、SDK、計測設定、構成、およびバージョンによって異なります。

Collectorは、基本的にテレメトリデータを処理、補完、変換し、個人情報が含まれていないかを確認することができます。 ただし、具体的なフィルタ、属性、または変換コンポーネントは、配布版、対応信号、およびバージョンステータスによって異なります。したがって、対象となるリリースを確認した上で、どのコンポーネントがどのフィールドを処理するかを決定し、一般的なコレクターの説明を特定の構成に対する承認とみなさないでください。

メトリクスについては、チームは事前に、具体的な運用上の課題に対してどの属性が本当に必要かを明確に定義しておくべきです。 個別のリクエストIDやユーザーID、および完全なURLは、単に念のためという理由でディメンションとして取り込まないこと。代表的なサンプルデータを用いて、計測が実際に生成する属性値を確認し、定義された分析に意図されたルート、サービス、またはエラークラスのみを許可するようにする。

処理ルールにはバージョン管理を行い、本番環境への展開前に、本番環境とは異なる代表的なサンプルデータを用いて検証を行う必要があります。 これにより、診断に必要な情報が失われていないか、あるいは機密性の高い値が引き続きエクスポートされていないかを確認できます。保存期間、権限管理、アクセスログ、および削除方針は、選択したバックエンドのアーキテクチャに追加されるものであり、OpenTelemetry自体によって規定されるものではありません。

Collectorを安定して稼働させ、エラーを特定する

スパンが欠落している場合や、想定されていたフローが複数のトレースに分割されている場合は、サービス間の移行点からトラブルシューティングを開始します。まず、送信側のリクエストがコンテキストを引き継いでいるか、そして次のサービスがそれを読み取っているかを確認してください。W3Cトレースコンテキストには traceparent 実際にこの転送をサポートし、上書きしないコンポーネントのみをリンクします。

続いてパイプラインの処理が行われます。設定されたレシーバーがデータを受信すると、プロセッサが期待される信号を通過させ、エクスポーターは目的地に到達するでしょうか？個別の検証を行うことで、バックエンドの問題が誤って計測エラーと見なされるのを防ぎます。 コレクターの稼働データと明確に区別されたテストリクエストにより、損失を特定の段階に特定しやすくなります。

エクスポートエラーが発生した場合は、DNS、到達可能性、証明書、および認証の確認が必要となります。S14では、コレクター接続において、使用されるコンポーネントに追加の権限が必要ない限り、安全で認証された通信チャネルを使用し、ルート権限や管理者権限なしで運用することを推奨しています。ただし、このドキュメントでは、開発中のブランチについて記載されています。 main; したがって、本番運用を開始する前に、これらのセキュリティに関する注意事項を、実際に使用するCollectorバージョンのドキュメントおよび設定内容と照らし合わせて確認してください。

もう1つの稼働指標は メモリプレッシャー. ターゲットシステムの応答が遅れたり、障害が発生したりした場合、キュー、再試行、および処理に時間がかかる処理がメモリを消費する可能性があります。メモリ制限やキューの容量制限は、負荷や障害時の挙動に合わせて設定する必要があり、本番運用前にその影響を確認する必要があります。 制限が設定されていない場合、コレクター自体が不安定になる可能性があります。

したがって、診断にあたっては、アプリケーションのトレースだけでなく、拒否または破棄されたデータ、キュー、エクスポートエラー、およびコレクターのリソースも監視する必要があります。変更は段階的に行います。まずパイプラインまたはサービスを1つ変更し、その後、データの完全性やストレージへの影響を確認します。 そうすることで、どの設定変更がエラー状況を改善したか、あるいは悪化させたかを特定できるようになります。

プラットフォームチームのためのアーキテクチャ上の決定を行う

小規模で範囲が明確に定義されたアプリケーションの場合、アクセス情報、ネットワーク経路、データルールを確実に把握していれば、バックエンドへの直接エクスポートで十分です。 複数のサービスがある場合、ホストごとにローカルコレクターを配置するか、エージェントに近い配置パターンを採用するアーキテクチャも考えられますが、これは一般的な推奨事項ではありません。S10では、Linux向けにホスト上で個別に稼働するコレクターについて規定しています。Pod、エージェント、ゲートウェイの各バリエーションについては、デプロイメントパターンや各プラットフォームの要件に基づいて検討する必要があります。

成長中のプラットフォームでは、多くの場合、役割の分離が有効に機能します。 ローカルコレクターはデータを受け取り、集約することができ、中央のゲートウェイコレクターはルーティング、統一されたフィルタリング、および複数のバックエンドへの接続を担当することができます。しかし、この役割分担により、可用性、容量、およびアクセス保護の計画が必要となる追加のサービスが生まれます。

多くの顧客プロジェクトにおいて、テレメトリの分離は、意図的に決定すべきアーキテクチャ上の判断事項です。 プロジェクトごとに異なるアクセス範囲が必要な場合、エクスポート先、バックエンドの権限、およびリソースの識別子を適切に計画・検証する必要があります。自由に設定できる属性はテレメトリの記述に用いられますが、本記事では、これらを技術的に実施されるアクセス制御の代替として扱うものではありません。

キャッシュ、キュー、データベースなどの分散型依存関係は、診断の必要性を高めますが、それだけで一律にすべてを網羅的に把握すべき理由にはなりません。特にRedisクラスターの場合、個々のサービスやバックグラウンドプロセッサは、処理フローの異なる部分しか把握できないことがあります。この記事は 大規模ホスティングプラットフォーム向けのRedisクラスター・シャーディング このようなキャッシュ層のアーキテクチャを分類する。テレメトリにおいては、コンテキストの境界とデータ量を意図的に制御することが依然として重要である。

したがって、この決定は以下を結びつける バックエンドへの依存の排除 実際の運用コストを伴います。コレクターは、ターゲットの切り替えや並列供給を容易にしますが、キャパシティ計画やエラー処理の代わりにはなりません。プラットフォームチームは、各ターゲットがどのデータを受け取るか、誰がアクセス権を持つか、そしてエクスポート時のどのような障害が発生してもアプリケーションに影響が及ばないようにすべきかを明確に定義する必要があります。

段階的な展開は、1つのサービスと、診断上重要な移行ポイントをいくつか含めて開始されます。 その後、代表的な負荷条件下で、コンテキストの連続性、フィルタリングルール、エクスポートの安定性、およびメモリ動作が検証されます。これらの基準が明確に満たされていることが確認されて初めて、他の言語、クライアント、またはバックエンドへの展開が進められます。これによりリスクが抑制され、責任の所在が不明確な大規模なパイプラインが形成されるのを防ぐことができます。