分散トレースでは、リクエストが分散システム内のあるサービスから別のサービスに移動するのを観察できます。 サービスの接続を理解したり、レイテンシーの問題を診断したり、その他の利点の中でも、多くの理由で非常に実用的です。
しかし、リクエストの大半がステータスコード200番で成功し、許容できないレイテンシーやエラーもなく終了する場合、そのようなデータが本当に必要でしょうか。 問題はここからです。 正しいインサイトを見つけるために、常に大量のデータが必要なわけではありません。 適切なデータのサンプリングが必要なだけです。
サンプリングの背後にある考え方は、オブザーバビリティバックエンドに送信するスパンを制御することであり、その結果、インジェストコストを削減することです。 異なる組織には、 なぜ サンプリングしたいのかだけでなく、 何 をサンプリングしたいのかについて独自の理由があるでしょう。 あなたは、サンプリング戦略を以下のようにカスタマイズしたいかもしれません。
サンプリングについて議論する際には、一貫した用語を使用することが重要です。 トレースまたはスパンは、「サンプリングされた」または「サンプリングされていない」と見なされます。
ときどきこれらの用語の定義が混同されることがあります。 誰かが「データをサンプリングアウトしている」と言ったり、処理またはエクスポートされていないデータは「サンプリングされた」と見なされると言ったりするのを見かけるかもしれません。 これらは間違った表現です。
ヘッドサンプリングは、サンプリングの決定をできるだけ早期に行うために用いられるサンプリング技術です。 スパンやトレースのサンプリングまたはドロップの決定は、トレース全体を検査することによって行われるわけではありません。
たとえば、ヘッドサンプリングのもっとも一般的な形式は、一貫した確率サンプリングです。 決定論的サンプリングと呼ばれることもあります。 この場合、サンプリングの決定は、トレースIDと、サンプリングするトレースの望ましい割合に基づいて行われます。 これにより、全トレースの5%など、一貫した割合で、スパンの欠損無く、全トレースがサンプリングされます。
ヘッドサンプリングの利点は以下の通りです。
ヘッドサンプリングの主な欠点は、トレース全体のデータに基づいてサンプリングの決定を下すことができないことです。 つまり、ヘッドサンプリングは雑な実装としては有効ですが、システム全体の情報を考慮しなければならないサンプリング戦略にはまったくもって不十分です。 たとえば、ヘッドサンプリングを使用して、エラーを含むすべてのトレースを確実にサンプリングすることは不可能です。 そのためには、テイルサンプリングが必要である。
テイルサンプリングとは、トレース内のすべてのスパンまたはほとんどのスパンを考慮して、トレースのサンプリングを決定することです。 テイルサンプリングは、ヘッドサンプリングでは不可能な、トレースの異なる部分から得られる特定の基準に基づいてトレースをサンプリングするオプションを提供します。
テイルサンプリングの使い方の例としては、以下のようなものがあります。
お分かりのように、テイルサンプリングは、より高度なことを可能にします。 テレメトリーをサンプリングしなければならない大規模なシステムでは、データ量とそのデータの有用性のバランスを取るために、ほとんどの場合、テイルサンプリングを使用する必要があります。
今日のテイルサンプリングには、主に3つの欠点があります。
最後に、システムによっては、テイルサンプリングがヘッドサンプリングと併用されることがあります。 たとえば、非常に大量のトレースデータを生成する一連のサービスは、最初にヘッドサンプリングを使ってトレースのごく一部だけをサンプリングし、テレメトリーパイプラインの後半でテイルサンプリングを使って、バックエンドにエクスポートする前に、より洗練されたサンプリング決定を行うことができます。 これは、テレメトリーパイプラインが過負荷にならないように保護するために、しばしば行われます。
OpenTelemetryコレクターには、以下のサンプリングプロセッサーがあります。
OpenTelemetry API & SDK の各言語固有の実装については、それぞれのドキュメントページでサンプリングのサポート状況を確認出来ます。
[i18n] feedback_question
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!