Application Insights にはカスタム サンプラーが含まれており、 OpenTelemetry と統合してテレメトリの量を減らし、コストを削減し、関心のある診断データを保持します。
重要
Application Insights クラシック API ソフトウェア開発キット (SDK) を使用する場合のサンプリングの詳細については、「 クラシック API サンプリング」を参照してください。
前提条件
続行する前に、次の内容を確認してください。
- データ収集メソッドの基本的な理解
- OpenTelemetry サンプリング概念の基本理解
- OpenTelemetry でインストルメント化されたアプリケーション
サンプリングが重要な理由
サンプリングは、大量のテレメトリを生成するアプリケーションに不可欠です。
サンプリングを行わないと、過剰なデータインジェストが問題を引き起こす可能性があります。
- ストレージと処理のコストを増やす
- Application Insights でテレメトリを調整するようにする
効果的なサンプリングは、コストを制御しながら、意味のある診断に十分なデータを保持します。
Application Insights OpenTelemetry ディストリビューションでは、サンプリングは 既定では有効になっていません 。 テレメトリ ボリュームを管理するには、サンプリングを明示的に有効にして構成する必要があります。
注
Application Insights で予期しない料金や高コストが表示される場合は、このガイドが役立ちます。 テレメトリの量が多い、データ インジェストの急増、サンプリングが正しく構成されていないなどの一般的な原因について説明します。 コストの急増、テレメトリボリューム、サンプリングが機能しない、データ上限、高インジェスト、または予期しない課金に関連する問題をトラブルシューティングする場合に特に便利です。 開始するには、「 Application Insights での高いデータ インジェストのトラブルシューティング」を参照してください。
Application Insights カスタム サンプラー
Azure Monitor OpenTelemetry ベースのディストリビューションには、カスタム サンプラーが含まれています。
- Live Metrics と Application Insights クラシック API SDK では、互換性のためにこのサンプラーが必要です。
- サンプラーは既定で無効になっています。 サンプラーを使用するには、サンプリングを明示的に有効にして構成する必要があります。
- 固定レート アルゴリズムを使用します。 たとえば、レートが 10% の場合、約 10% のトレースが Azure Monitor に送信されます。
- Azure Monitor Application Insights サービスは、このサンプラーを使用して完全なトレースを提示し、破損が発生しないようにしています。
利点
- Application Insights クラシック API ソフトウェア開発キット (SDK) を使用したアプリケーションとの相互運用性中の一貫したサンプリング決定。
- サンプラーはライブ メトリックの要件を認識しているため、Live Metrics との完全な互換性。
サンプリング率を構成するには、「 OpenTelemetry を使用して Application Insights でサンプリングを有効にする」を参照してください。
エッジ ケースの詳細とサンプリングについては、「 よく寄せられる質問」を参照してください。
インジェスト サンプリング (推奨されません)
インジェスト サンプリングは、ソース レベルの制御が不可能な場合のフォールバックです。 Azure Monitor インジェスト ポイントでデータを削除し、どのトレースとスパンを保持するかを制御しません。 これにより、破損したトレースに遭遇する可能性が高くなります。
それが唯一の実行可能または最も実用的なオプションであるシナリオは次のとおりです。
- アプリケーションのソース コードを変更することはできません。
- アプリケーションを再デプロイすることなく、すぐにテレメトリの量を減らす必要があります。
- 一貫性のない、または不明なサンプリング構成を持つ複数のソースからテレメトリを受け取ります。
インジェスト サンプリングを構成するには:
- Application Insights>Usage と推定コストに移動します。
- [データ サンプリング] を選択します。
- 保持するデータの割合を選択します。
日次上限の設定
予期しないコストを防ぐために日次上限を設定します。 この制限は、しきい値に達するとテレメトリ インジェストを停止します。
このキャップは、サンプリングの代わりではなく、最後の手段のコントロールとして使用します。 データ 量が急激に増加すると、上限が発生し、翌日にリセットされるまでテレメトリにギャップが生まれる可能性があります。
上限を構成するには、 Azure Monitor の日次上限の設定に関するページを参照してください。
よく寄せられる質問
Application Insights カスタム サンプラーは tail-based ですか?
Application Insights カスタムサンプラーは、事前ではなくスパンの作成後にサンプリングの決定を行うため、従来のヘッドベースのアプローチには従いません。 代わりに、スパンの生成が終了した時点でサンプリングの決定が行われ、スパンが完了した後、エクスポートの前に適用されます。
この動作はいくつかの点で末尾ベースのサンプリングに似ていますが、サンプラーは決定する前に、同じトレースから複数のスパンを収集するのを待機しません。 代わりに、トレース ID のハッシュを使用して、トレースの完全性を確保します。
このアプローチでは、トレースの完全性と効率がバランスを取り、完全なテールベースのサンプリングに関連するコストが高くなるのを回避します。
トレース全体の結果に基づいてサンプリングを決定するには (たとえば、トレース内のスパンが失敗したかどうかを判断する)、ダウンストリーム エージェントまたはコレクターで完全な末尾ベースのサンプリングが必要です。 この機能は現在サポートされていませんが、 フィードバック ハブから新機能として要求できます。
Application Insights カスタム サンプラーは、OpenTelemetry ヘッドベースまたはテールベースのサンプリングとどのように比較されますか?
| サンプリング メソッド | 決定のポイント | 長所 | 脆弱性 |
|---|---|---|---|
| Head-based | スパンが開始される前 | 待機時間が短く、オーバーヘッドが最小限 | 必要なトレース (エラーを含む) をサンプリングできます |
| Tail-based | 時間またはボリュームのしきい値に基づいてスパンをバッファー処理した後 | 高度に選択的なトレース サンプリング基準を許可する | コストの増加と処理遅延の追加 |
| App Insights カスタム サンプラー | スパン生成の終了 | トレースの完全性と効率性のバランスを取ります | ライブ メトリックとクラシック API の互換性に必要 |
依存関係、要求、またはその他のテレメトリの種類をさまざまなレートでサンプリングできますか?
いいえ。サンプラーは、トレース内のすべてのテレメトリの種類に固定レートを適用します。 要求、依存関係、およびその他のスパンは、同じサンプリング率に従います。 テレメトリの種類ごとに異なるレートを適用するには、OpenTelemetry スパン プロセッサまたは (インジェスト時間変換)[opentelemetry-overview.md#telemetry-routing] の使用を検討してください。
Application Insights カスタム サンプラーはサンプリングの決定をどのように伝達しますか?
Application Insights カスタム サンプラーは、既定で W3C トレース コンテキスト標準を使用してサンプリングの決定を伝達します。 この標準により、サンプリングの決定をサービス間で流すことができます。 ただし、サンプラーは、ダウンストリーム サービスの呼び出し後にスパン生成の終了時にサンプリングの決定を行うため、伝達には不完全なサンプリング情報が含まれます。 この制限は W3C トレース コンテキスト仕様に準拠していますが、ダウンストリーム サービスでは、この伝達されたサンプリング決定を確実に使用できません。
Application Insights カスタム サンプラーは、アップストリーム サービスからのサンプリング決定を尊重していますか?
いいえ。アップストリーム サービスが同じサンプリング アルゴリズムを使用している場合でも、Application Insights カスタム サンプラーは常に独立したサンプリング決定を行います。 W3C トレース コンテキスト ヘッダーを使用するサービスを含むアップストリーム サービスからのサンプリング決定は、ダウンストリーム サービスの決定に影響しません。 ただし、トレースの完全性を確保するために、トレース ID のハッシュに基づいてサンプルを実行します。 整合性を向上させ、トレースが破損する可能性を減らすには、同じサンプラーとサンプリング レートを使用するようにシステム内のすべてのコンポーネントを構成します。
Application Insights カスタム サンプラーを使用している場合でも、一部のトレースが不完全に表示されるのはなぜですか。
トレースが不完全に表示される理由はいくつかあります。
- 分散システム内のノードによって、決定を調整しないさまざまなサンプリング アプローチが使用されます。 たとえば、1 つのノードが OpenTelemetry ヘッド ベースのサンプリングを適用し、別のノードが Azure Monitor カスタム サンプラーを介してサンプリングを適用します。
- ノードが同じサンプリング アプローチを使用している場合でも、異なるノードが異なるサンプリング レートに設定されます。
- サービス側パイプラインでフィルター処理、サンプリング、またはレート キャップを設定すると、トレースの完全性を考慮せずに、この構成によってスパンがランダムにサンプリングされます。
1 つのコンポーネントが (W3C トレース コンテキスト ヘッダーを介して) サンプリングの決定を伝達せずにヘッド ベースのサンプリングを適用する場合、ダウンストリーム サービスはトレースを個別にサンプリングし、その結果、スパンが破棄される可能性があります。 その結果、トレースの一部は、Application Insights で表示されるときに常に使用できるわけではありません。