TT Lab
はじめる
学ぶ 学習パス コース

OTCA — OpenTelemetry認定アソシエイト

テールサンプリングのポリシーとルーティング層

TT Labで続きを見る

目標

テールサンプリングのポリシーを5つ設計し、その前段にtrace IDのルーティング層を置き、バッファメモリを自分で計算して、その値をオペレーターのCRに反映します。

なぜ重要なのか

テールサンプリングは、「有効にすればコストが減る」機能ではありません。判定するにはすべてのスパンが到着する必要があるため、エージェントからコレクターまでのネットワークはまったく減らず、減るのはバックエンドの保存とインデックス作成だけです。代わりに、新たに3つを支払います。decision_waitの間、すべてのスパンを保持しておく必要があるメモリ、同じトレースを1つのインスタンスに集めるルーティング層、そしてその層を運用する複雑さです。そのため、導入の判断は勘ではなく掛け算で行います。1秒あたりのトレース数と待ち時間を掛けてnum_tracesを決め、そこにスパン数とサイズを掛けてメモリを決めます。この計算を飛ばすと、上限が足りないまま運用され、古いトレースが強制判定されてデータが消えるのにメトリクスは何の異常も報告しない、という状況に出くわします。

ステップ

  1. /root/otca-sampling/tailsampling.yamlを作成し、processors.tail_samplingにdecision_wait: 30s、num_traces: 300000、expected_new_traces_per_sec: 10000を書いてください。
  2. policiesに2つのポリシーを入れてください。name: keep-errors(type: status_code、status_code.status_codesにERROR)と、name: keep-slow(type: latency、latency.threshold_ms: 800)です。
  3. name: drop-healthchecksポリシーを追加してください。type: string_attribute、string_attribute.key: http.route、valuesは/healthzと/readyz、そしてinvert_match: trueにします。
  4. name: vip-slowポリシーを追加してください。type: andで、and.and_sub_policyに2つの下位ポリシーを入れます。type: string_attributeでtenant.tierがenterpriseのものと、type: latencyでthreshold_ms: 300のものです。最後にname: baseline(type: probabilistic、probabilistic.sampling_percentage: 2)を追加して、ポリシーを合計5個にしてください。
  5. /root/otca-sampling/loadbalancing.yamlに前段のルーティング層を書いてください。exporters.loadbalancingにrouting_key: traceID、resolver.dns.hostnameはotel-tailsamplerを含むサービスアドレス、resolver.dns.port: 4317にします。service.pipelines.tracesのエクスポーターは[loadbalancing]の1つだけで、プロセッサーにtail_samplingを入れてはいけません。
  6. /root/otca-sampling/buffer-memory.txtに計算結果を3行で書いてください。num_traces_required=(10,000 trace/s × 30s)、buffer_mb=(10,000 × 30 × 12スパン × 1.2KBをMBに換算して四捨五入)、buffer_mb_with_headroom=(その2倍)です。各行は、スペースなしの키=값の形式です(プレースホルダーはキーと値です)。
  7. ネームスペースotca-samplingを作成し、/root/otca-sampling/collector-cr.yamlにCRを書いてください。apiVersion: opentelemetry.io/v1beta1、kind: OpenTelemetryCollector、metadata.name: otel-tailsampler、metadata.namespace: otca-sampling、spec.mode: deployment、spec.replicas: 3にします。spec.configの中には、ステップ1–4のtail_sampling(ポリシー5個そのまま)を入れ、spec.config.service.pipelines.traces.processorsは、tail_samplingがbatchより前に来て、batchが最後になるように書いてください。

参考

tail_samplingの基本値

/root/otca-sampling/tailsampling.yamlを作成し、processors.tail_samplingにdecision_wait: 30s、num_traces: 300000、expected_new_traces_per_sec: 10000を書いてください。

decision_waitは、トレースのすべてのスパンが到着するまでの時間的な余裕です。短すぎると不完全なトレースで判定し、長すぎるとメモリが急増します。num_tracesは、1秒あたりのトレース数と待ち時間の積から決まります。

結果ベースのポリシー2つ

policiesに2つのポリシーを入れてください。name: keep-errors(type: status_code、status_code.status_codesにERROR)と、name: keep-slow(type: latency、latency.threshold_ms: 800)です。

テールサンプリングが存在する理由が、この2つのポリシーです。ヘッドサンプリングでは確率的にしか得られないものを、ルールで100%保持します。各ポリシーは、nameとtype、そしてtypeと同じ名前の設定ブロックを持ちます。

ヘルスチェックの除外

name: drop-healthchecksポリシーを追加してください。type: string_attribute、string_attribute.key: http.route、valuesは/healthzと/readyz、そしてinvert_match: trueにします。

ポリシーはすべて「残す条件」です。そのため、特定のルートを除くには、一致を反転させるオプションが必要です。属性値のリストで一致を判定するポリシータイプを使ってください。

andの複合ポリシーと基本確率

name: vip-slowポリシーを追加してください。type: andで、and.and_sub_policyに2つの下位ポリシーを入れます。type: string_attributeでtenant.tierがenterpriseのものと、type: latencyでthreshold_ms: 300のものです。最後にname: baseline(type: probabilistic、probabilistic.sampling_percentage: 2)を追加して、ポリシーを合計5個にしてください。

2つの条件を同時に満たすときだけ残すには、複合ポリシーが必要です。下位ポリシーも、それぞれnameとtypeを持つ完全なポリシーです。最後に、残りのための確率ポリシーを置きます。

前段のルーティング層

/root/otca-sampling/loadbalancing.yamlに前段のルーティング層を書いてください。exporters.loadbalancingにrouting_key: traceID、resolver.dns.hostnameはotel-tailsamplerを含むサービスアドレス、resolver.dns.port: 4317にします。service.pipelines.tracesのエクスポーターは[loadbalancing]の1つだけで、プロセッサーにtail_samplingを入れてはいけません。

判定層の前には、同じトレースのスパンを1つのインスタンスに集める層が必要です。通常のロードバランサーでは足りず、トレースIDをキーに使うエクスポーターを使います。この前段の層は、判定を行いません。

バッファメモリの計算

/root/otca-sampling/buffer-memory.txtに計算結果を3行で書いてください。num_traces_required=(10,000 trace/s × 30s)、buffer_mb=(10,000 × 30 × 12スパン × 1.2KBをMBに換算して四捨五入)、buffer_mb_with_headroom=(その2倍)です。各行は、スペースなしの키=값の形式です(プレースホルダーはキーと値です)。

1秒あたりのトレース数に、待ち時間を掛け、トレースあたりのスパン数を掛け、スパンのサイズを掛けます。KBをMBに換算するときは1024で割り、小数点は四捨五入します。num_tracesの必要値は、最初の2項だけを掛ければ出ます。

OpenTelemetryCollector CR

ネームスペースotca-samplingを作成し、/root/otca-sampling/collector-cr.yamlにCRを書いてください。apiVersion: opentelemetry.io/v1beta1、kind: OpenTelemetryCollector、metadata.name: otel-tailsampler、metadata.namespace: otca-sampling、spec.mode: deployment、spec.replicas: 3にします。spec.configの中には、ステップ1–4のtail_sampling(ポリシー5個そのまま)を入れ、spec.config.service.pipelines.traces.processorsは、tail_samplingがbatchより前に来て、batchが最後になるように書いてください。

ノードごとに起動するデプロイモードでは、1つのトレースのスパンが複数のノードに散らばり、判定ができません。CRの中の設定は、コレクターの設定ファイルと同じ構造で、プロセッサーの順序のルールもそのまま適用されます。CRDがない環境なので、ファイルを書くだけにして、ネームスペースだけを実際に作成します。