サンプリング戦略: テレメトリの量とコストの削減
数百のマイクロサービスと毎秒数千のリクエストが存在する分散システムでは、 集める すべて順調です トラックであり、法外に高価です。の サンプリング （サンプリング）と、その代表的なサブセットを選択できる技術 トレースを実行し、容量を失うことなくデータ量とストレージのコストを削減します。 問題を診断します。
サンプリングと適切なバランスを見つけるという課題: サンプリングが少なすぎると、 視認性;サンプリングが多すぎるとコストが増加します。高度なサンプリング戦略 維持できるようにする エラーのあるすべてのトラック 遅いリクエスト、 「通常の」反復トラフィックのみを破棄します。
この記事で学べること
- ヘッドベースのサンプリング: トラックの先頭で決定
- テールベースのサンプリング: トレースの最後で決定
- 確率的サンプリングとレート制限
- コレクターでのサンプリングの構成
- コスト最適化戦略
- 精度とコストのトレードオフ
ヘッドベースのサンプリング
Il ヘッドベースのサンプリング トラックをサンプリングする決定を下す
初めに、最初のスパン (ルート スパン) にあります。その後、決定が伝達されます
フラグを介してすべてのダウンストリーム サービスに送信 sampled nel traceparent
ヘッダ。ルート スパンがサンプリングしないことを決定した場合、チェーン内のサービスは記録されません。
そのトラックのスパン。
主な利点は、 シンプルさ そして効率: の トラックが完了するのを待つことなく、決定は即座に行われます。 欠点は、決定の時点では要求の結果がわからないことです。 エラーのあるトラックは破棄される場合があります。
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.sampling import (
TraceIdRatioBased,
ParentBasedTraceIdRatio,
ALWAYS_ON,
ALWAYS_OFF,
)
# --- 1. Probability Sampler (25% delle tracce) ---
# Ogni traccia ha il 25% di probabilità di essere campionata
sampler_25 = TraceIdRatioBased(0.25)
# --- 2. ParentBased Sampler (rispetta la decisione del parent) ---
# Se il parent e campionato, il figlio e campionato
# Se non c'è parent, usa il ratio specificato
sampler_parent = ParentBasedTraceIdRatio(0.25)
# --- 3. Configurazione nel TracerProvider ---
provider = TracerProvider(
sampler=ParentBasedTraceIdRatio(0.25)
)
trace.set_tracer_provider(provider)
# --- 4. Configurazione via variabili d'ambiente ---
# OTEL_TRACES_SAMPLER=parentbased_traceidratio
# OTEL_TRACES_SAMPLER_ARG=0.25
ヘッドベースのサンプラーの種類
| サンプラー | 行動 | 一般的な使用方法 |
|---|---|---|
| 常時オン | すべてのトラックをサンプリング (100%) | 開発、テスト、低トラフィック サービス |
| 常にオフ | サンプリングを行わない (0%) | トレースを一時的に無効にする |
| TraceIdRatioBased | 固定パーセンテージをサンプリングする | ボリュームを減らすためのシンプルなアプローチ |
| 親ベース | 親の決定を尊重する | サービス間の一貫性を確保する |
テールベースのサンプリング
Il テールベースのサンプリング トラックをサンプリングする決定を下す dopo すべてのスパンが収集され、完全なトレースが分析されていることを確認します。 これにより、リクエストの結果に基づいてインテリジェントな決定が可能になります。 エラー、遅いリクエスト、および異常なトレースを含むすべてのトレース。 反復的かつ成功したトラフィック。
テールベースのサンプリングには、集中コンポーネント (通常は、 ゲートウェイ モード)、トレースのすべてのスパンを収集し、それらを組み立て、ポリシーを評価します。 サンプリングして、トラック全体を保持するか破棄するかを決定します。
# Configurazione tail_sampling nel Collector Gateway
processors:
tail_sampling:
# Tempo massimo per attendere tutti gli span di una traccia
decision_wait: 30s
# Numero massimo di tracce in attesa di decisione
num_traces: 100000
# Numero atteso di nuove tracce al secondo
expected_new_traces_per_sec: 1000
policies:
# Policy 1: mantenere TUTTE le tracce con errori
- name: errors-policy
type: status_code
status_code:
status_codes:
- ERROR
# Policy 2: mantenere le tracce lente (latenza > 2s)
- name: latency-policy
type: latency
latency:
threshold_ms: 2000
# Policy 3: mantenere tracce con attributi specifici
- name: vip-customers
type: string_attribute
string_attribute:
key: customer.tier
values:
- premium
- enterprise
# Policy 4: campionamento probabilistico per il resto
- name: probabilistic-policy
type: probabilistic
probabilistic:
sampling_percentage: 10
# Policy 5: rate limiting globale
- name: rate-limiting
type: rate_limiting
rate_limiting:
spans_per_second: 500
# Policy 6: policy composita (AND/OR)
- name: composite-policy
type: composite
composite:
max_total_spans_per_second: 1000
policy_order: [errors-policy, latency-policy, probabilistic-policy]
rate_allocation:
- policy: errors-policy
percent: 50
- policy: latency-policy
percent: 30
- policy: probabilistic-policy
percent: 20
ヘッドとテールのサンプリングの比較
ヘッドベースのサンプリングとテールベースのサンプリング
| 待ってます | 頭ベース | 尻尾ベース |
|---|---|---|
| 決断の瞬間 | トラックの始まり | トラックの終わり |
| 結果の知識 | No | はい (エラー、レイテンシ、属性) |
| 必要なリソース | 最小値 (分散) | 重要 (集中型) |
| 一貫性 | 常に一貫性のある | 孤立したスパンのリスク |
| 複雑 | 低い | 高 (専用インフラストラクチャ) |
| キャッチされたエラー | ランダムにサンプリングされた場合のみ | すべて (専用ポリシー) |
コスト最適化戦略
可観測性のコストはテレメトリの量に応じて増加します。最適化戦略 彼らは、トラックのボリュームを減らす、属性の数を減らすという 3 つの手段に焦点を当てています。 バックエンドでの保持を拡張し、最適化します。
# Strategia di ottimizzazione multi-livello
# 1. Filtrare il rumore nel Collector
processors:
filter:
traces:
span:
# Eliminare health check e readiness probe
- 'attributes["http.route"] == "/health"'
- 'attributes["http.route"] == "/ready"'
- 'attributes["http.route"] == "/metrics"'
# Eliminare richieste di asset statici
- 'attributes["http.route"] =~ "/static/.*"'
# 2. Rimuovere attributi ad alta cardinalita
attributes:
actions:
# Rimuovere header sensibili
- key: http.request.header.authorization
action: delete
- key: http.request.header.cookie
action: delete
# Troncare query SQL lunghe
- key: db.query.text
action: hash
# 3. Tail sampling intelligente
tail_sampling:
policies:
- name: keep-errors
type: status_code
status_code:
status_codes: [ERROR]
- name: keep-slow
type: latency
latency:
threshold_ms: 1000
- name: sample-rest
type: probabilistic
probabilistic:
sampling_percentage: 5
# 4. Batch per efficienza
batch:
send_batch_size: 2048
timeout: 10s
コスト最適化チェックリスト
- ノイズをフィルターで除去する: バックエンドの前にヘルスチェック、準備プローブ、静的資産を排除します。
- カーディナリティを確認する: メトリック ラベルを制限された値に制限します (メトリックあたり最大 5 ～ 7 ラベル)
- エラー時のテールサンプリング: エラーのあるトラックを 100% 保持し、残りをサンプリングします
- 差別化された保持力: 集計メトリックの保持期間は長期 (90 日間)、生のトレースの保持期間は短い (7 ～ 14 日間)
- 圧縮: コレクターで gzip/zstd を有効にして、ネットワーク トラフィックを削減します。
- ダウンサンプリングメトリクス: 過去のメトリクスの解像度を下げます (7 日後に 15 秒から 5 分に)
適応サンプリング
L'適応サンプリング それに応じてサンプリングレートを自動的に調整します 現在の交通量に合わせて。トラフィックが少ない場合は、より大きなパーセンテージをサンプリングします。 トラフィックが多い場合は、ボリュームを予算内に抑えるためにレートが低下します。
コレクター テール サンプリングのレート制限は、適応サンプリングの単純な形式です。
spans_per_second: 500 関係なく一定の最大音量を保証します
交通から。より洗練された戦略には、カスタム ソリューションまたは SaaS サービスが必要です
プラットフォームレベルで適応サンプリングを実装します。
結論と次のステップ
サンプリングは、大規模な可観測性を管理するための基本的なスキルです。選択 戦略の内容はトラフィック量、予算、可視性のレベルによって異なります。 必須です。推奨されるアプローチは、次のことを組み合わせることです。 ヘッドベースのサンプリング のために 基本的なボリュームの削減 テールベースのサンプリング それを確実にするために エラーと異常は常に捕捉されます。
黄金律は次のとおりです。 サンプルトラックではなく、メトリクスではありません。集計メトリクス トラフィックに依存しない固定コストがあり、高レベルの可視性を提供します。 アラートに必要です。トレースは高価ですが、詳細なデバッグにのみ必要です。
次の記事では、AIの可観測性、追跡方法を分析する 大規模言語モデルの呼び出し、トークンの使用状況、待ち時間の監視 AI エージェントの推論と動作。