次の方法で共有

サンプリング オーバーライド - Azure Monitor Application Insights for Java

  • [アーティクル]

Note

サンプリング オーバーライド機能の一般提供は 3.5.0 以降です。

サンプリング オーバーライドを使用すると、既定のサンプリング率をオーバーライドできます。次に例を示します。

  • ノイズの多い正常性チェックでは、サンプリング率を 0 (または何らかの小さい値) に設定します。
  • ノイズの多い依存関係呼び出しでは、サンプリング率を 0 (または何らかの小さい値) に設定します。
  • 重要な要求の種類 (/login など) では、既定のサンプリングが低く構成されている場合でも、サンプリング率を 100 に設定します。

用語

サンプリング オーバーライドについて学習する前に、"スパン" という用語を理解しておく必要があります。 スパンは、次を表す一般的な用語です。

  • 着信要求。
  • 送信依存関係 (別のサービスへのリモート呼び出しなど)。
  • プロセス内の依存関係 (サービスのサブコンポーネントによって実行される操作など)。

サンプリング オーバーライドに関しては、次のスパンのコンポーネントが重要です。

  • 属性

スパン属性は、指定された要求または依存関係の標準とカスタムの両方のプロパティを表します。

作業の開始

開始するには、applicationinsights.json という名前の構成ファイルを作成します。 これを、applicationinsights-agent-*.jar と同じディレクトリに保存します。 次に示すテンプレートを使用します。

{
  "connectionString": "...",
  "sampling": {
    "percentage": 10,
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          ...
        ],
        "percentage": 0
      },
      {
        "telemetryType": "request",
        "attributes": [
          ...
        ],
        "percentage": 100
      }
    ]
  }
}

しくみ

telemetryType (Application Insights 3.4.0 では telemetryKind) は、request、dependency、trace (ログ)、または exception のいずれかである必要があります。

スパンが開始されると、いずれかのサンプリング オーバーライドが一致するかどうかを確認するために、その時点で存在するスパンと属性が使用されます。

一致は strict か regexp です。 正規表現の一致は、属性値全体に対して実行されます。そのため、その中のどこかに abc が含まれる値に一致することが望まれる場合、.*abc.* を使用する必要があります。 1 つのサンプリング オーバーライドに複数の属性条件を指定できます。その場合、そのすべてが一致対象のサンプリング オーバーライドに一致している必要があります。

いずれかのサンプリング オーバーライドが一致する場合は、そのサンプリング率を使用してスパンをサンプリングするかどうかを決定します。

一致する最初のサンプリング オーバーライドのみが使用されます。

サンプリング オーバーライドが一致しない場合:

  • そのスパンがトレースの最初のスパンである場合は、最上位のサンプリング構成が使用されます。
  • そのスパンがトレースの最初のスパンでない場合は、親のサンプリングの決定が使用されます。

例: 正常性チェックのテレメトリの収集の抑制

この例では、/health-checks へのすべての要求に対するテレメトリの収集が抑制されています。

この例では、通常は /health-checks で収集されるダウンストリームのスパン (依存関係) の収集も抑制されています。

{
  "connectionString": "...",
  "sampling": {
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          {
            "key": "url.path",
            "value": "/health-check",
            "matchType": "strict"
          }
        ],
        "percentage": 0
      }
    ]
  }
}

例: ノイズの多い依存関係呼び出しのテレメトリの収集の抑制

この例では、すべての GET my-noisy-key redis 呼び出しに対するテレメトリの収集が抑制されています。

{
  "connectionString": "...",
  "sampling": {
    "overrides": [
      {
        "telemetryType": "dependency",
        "attributes": [
          {
            "key": "db.system",
            "value": "redis",
            "matchType": "strict"
          },
          {
            "key": "db.statement",
            "value": "GET my-noisy-key",
            "matchType": "strict"
          }
        ],
        "percentage": 0
      }
    ]
  }
}

例: 重要な要求の種類のテレメトリを 100% 収集

この例では、/login のテレメトリが 100% 収集されます。

ダウンストリームのスパン (依存関係) は親のサンプリング決定を尊重するため (ダウンストリームのスパンのサンプリング オーバーライドは存在しません)、すべての '/login' 要求についても収集されます。

{
  "connectionString": "...",
  "sampling": {
    "percentage": 10
  },
  "sampling": {
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          {
            "key": "url.path",
            "value": "/login",
            "matchType": "strict"
          }
        ],
        "percentage": 100
      }
    ]
  }
}

サンプリングに使用できるスパン属性

スパンの属性名は、OpenTelemetry のセマンティック規則に基づいています。 (HTTP、メッセージング、データベース、RPC)

https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md

Note

アプリケーションの Application Insights Java によってキャプチャされた属性の正確なセットを確認するには、自己診断レベルを debug に設定し、テキスト "exporting span" で始まるデバッグ メッセージを探します。

Note

サンプリングに使用できるのはスパンの開始時に設定された属性のみであり、後でキャプチャされる http.response.status_code や要求期間などの属性は、OpenTelemetry Java 拡張機能を使用してフィルター処理できます。 要求の期間に基づいてスパンをフィルター処理する拡張機能のサンプルを次に示します。

トラブルシューティング

regexp を使用していて、サンプリング オーバーライドが機能しない場合は、.* 正規表現を試してください。 サンプリングが機能するようになった場合は、最初の正規表現に問題があることを意味します。こちらの正規表現のドキュメントを確認してください。

.* で機能しない場合は、application-insights.json file に構文の問題が存在している可能性があります。 Application Insights のログを確認し、警告メッセージが表示されているかどうかを確認してください。