コンテンツにスキップ

DataKit トレースの概要

現在、DataKit でサポートされているサードパーティのトレース データには次のものが含まれます。

  • DDTrace
  • Apache Jaeger
  • OpenTelemetry
  • SkyWalking
  • Zipkin
  • Cat
  • PinPoint

DataKit Tracing Frontend

Tracing Frontend は、さまざまな種類の Trace データを受け取る API です。通常、さまざまな Trace SDK によって送信されたデータを HTTP または gRPC 経由で受信します。 DataKit はこれらのデータを受信すると、統合されたスパン構造 に変換します。次に、処理のために Backend に送信します。

Tracing Frontend は、Span 構造の変換に加えて、Tracing Backend でのフィルター ユニットと演算ユニットの構成も完了します。

トレースデータ収集の共通設定

構成ファイル内のトレーサーは、現在構成されているトレーシング エージェントを指します。サポートされているすべてのトレース エージェントは、次の構成を使用できます。

  ## customer_tags is a list of keys contains keys set by client code like span.SetTag(key, value)
  ## that want to send to data center. Those keys set by client code will take precedence over
  ## keys in [inputs.tracer.tags]. DOT(.) IN KEY WILL BE REPLACED BY DASH(_) WHEN SENDING.
  customer_tags = ["key1", "key2", ...]

  ## Keep rare tracing resources list switch.
  ## If some resources are rare enough(not presend in 1 hour), those resource will always send
  ## to data center and do not consider samplers and filters.
  keep_rare_resource = false

  ## By default every error presents in span will be send to data center and omit any filters or
  ## sampler. If you want to get rid of some error status, you can set the error status list here.
  omit_err_status = ["404"]

  ## Ignore tracing resources map like service:[resources...].
  ## The service name is the full service name in current application.
  ## The resource list is regular expressions uses to block resource names.
  ## If you want to block some resources universally under all services, you can set the
  ## service name as "*". Note: double quotes "" cannot be omitted.
  [inputs.tracer.close_resource]
    service1 = ["resource1", "resource2", ...]
    service2 = ["resource1", "resource2", ...]
    "*" = ["close_resource_under_all_services"]

  ## Sampler config uses to set global sampling strategy.
  ## sampling_rate used to set global sampling rate.
  [inputs.tracer.sampler]
    sampling_rate = 1.0

  [inputs.tracer.tags]
    key1 = "value1"
    key2 = "value2"

  ## Threads config controls how many goroutines an agent cloud start.
  ## buffer is the size of jobs' buffering of worker channel.
  ## threads is the total number fo goroutines at running time.
  ## timeout is the duration(ms) before a job can return a result.
  [inputs.tracer.threads]
    buffer = 100
    threads = 8
    timeout = 1000
  • customer_tags: デフォルトでは、DataKit は関心のあるタグ (つまり、Guance トレースの詳細に表示されるmessage を除くフィールド) のみを選択します。

ユーザーがトレースによって報告された他のタグに興味がある場合は、この構成を追加して、DataKit にタグを取得するように指示できます。この構成の優先順位は [inputs.tracer.tags] よりも高くなります。

  • keep_rare_resource: 過去 1 時間以内にリsourceからのトレースが表示されなかった場合、システムはそのトレースをまれなトレースとみなし、データ センターに直接報告します。
  • omit_err_status: デフォルトでは、トレースにエラー ステータスのスパンがある場合、データはデータ センターに直接報告されます。ユーザーが HTTP エラー ステータスを持つ特定のトレースを無視する必要がある場合 (例: 429 リクエストが多すぎます)、この項目を設定することで DataKit にトレースを無視するように指示できます。
  • [inputs.tracer.close_resource]: ユーザーは、span_type がエントリであるリsource トレースを閉じるようにこの項目を構成できます。
  • [inputs.tracer.sampler]: DataKit の現在のグローバル サンプリング レート、構成例 を構成します。
  • [inputs.tracer.tags]: DataKit グローバル タグを customer_tags よりも低い優先度で構成します。
  • [inputs.tracer.threads]: 現在のトレース エージェントのスレッド キューを構成して、データ処理中に使用できる CPU およびメモリ リソースを制御します。
    • バッファ: ワークキューのキャッシュ。構成が大きくなるほど、メモリの消費量も増加します。同時に、エージェントに送信されたリクエストが正常にキューに入れられ、すぐに返される可能性が高くなります。それ以外の場合、それらは破棄され、429 エラーが返されます。
    • スレッド: 作業キュー内のスレッドの最大数。構成が大きくなるほど、より多くのスレッドが開始され、CPU 使用率が高くなります。通常、CPU コアの数として構成されます。
    • タイムアウト: タスクのタイムアウト。構成が大きくなるほど、バッファが占有される時間が長くなります。

DataKit Tracing Backend

DataKit バックエンドは、構成に従ってトレース データを操作する責任を負います。現在サポートされている操作には、トレース フィルターとサンプラーが含まれます。

DataKit Filters

  • user_rule_filter: DataKit のデフォルト フィルター。ユーザーの動作によってトリガーされます。
  • omit_status_code_filter: omit_err_status = ["404"] が設定されている場合、HTTP サービス下のトレースにステータス コード 404 のエラーが含まれている場合、データ センターには報告されません。
  • penetrate_error_filter: DataKit のデフォルト フィルター。トレース エラーによってトリガーされます。
  • close_resource_filter: [inputs.tracer.close_resource] で構成します。サービス名はサービスの完全名または *、リsource名はリsourceの正規表現です。
    • 例 1: 構成が login_server = ["^auth\_.*\?id=[0-9]*"] の場合、login_server サービス名 resource の下の auth_name?id=123 の形式のトレースが閉じられます。
    • 例 2: 構成が "*" = ["heart_beat"] のような場合、現在の DataKit の下にあるすべてのサービス上の heart_beat リソースが閉じられます。
  • keep_rare_resource_filter: keep_rare_resource = true が設定されている場合、まれであると判断されたトレースはデータ センターに直接報告されます。

現在の DataKit バージョンのフィルター (サンプラーもフィルターの一種です) の実行順序は固定されています。

error status penetration --> close resource filter --> omit certain http status code list --> rare resource keeper --> sampler
各 DataKit フィルターには、実行トレースを終了する機能があります。つまり、終了条件を満たすフィルターは後続のフィルターを実行しません。

DataKit Samplers

現在、DataKit はクライアントのサンプリング優先度設定 DDTrace Sampling Rules を尊重します。

  • 状況 1

DDTrace を例にとると、サンプリング優先度タグが DDTrace lib sdk またはクライアントで構成され、クライアントのサンプリング レートが環境変数 (DD_TRACE_SAMPLE_RATE) または起動パラメーター (dd.trace.sample.rate) によって 0.3 に構成され、DataKit のサンプリング レート (inputs.tracer.sampler) が指定されていない場合、データ センターに報告されるデータの量は総量の約 30% になります。

  • 状況 2

お客様が DataKit サンプリング レート (inputs.tracer.sampler) のみを構成した場合 (例: sampling_rate = 0.3)、この DataKit によって Data Center に報告されるデータ量は総量の約 30% になります。

Note 複数のサービスと複数の DataKit の分散展開で DataKit サンプリング レートを構成する場合、サンプリング効果を達成するには、サンプリング レートを同じサンプリング レートに均一に構成する必要があります。

  • 状況 3

つまり、クライアントのサンプリング レートは A として構成され、DataKit のサンプリング レートは B として構成されます。ここで、A と B は 0 より大きく、1 より小さいです。この場合、データ センターに報告されるデータの量は、総量の約 A*B% です。

Note 複数のサービスと複数の DataKit の分散展開で DataKit サンプリング レートを構成する場合、サンプリング効果を達成するには、サンプリング レートを同じサンプリング レートに均一に構成する必要があります。

Span 構造の説明

DataKit が DataKit Span データ構造を使用する方法に関する業務説明

  • DataKit Tracing データ構造の詳細については、DataKit Tracing Structure を参照してください。
  • 複数の DataKit Span データが DataKit Trace に配置されてトレース データが形成され、Data Center にアップロードされるため、すべての Span が TraceID を 1 つだけ持つことが保証されます。
  • DDTrace の場合、同じ TraceID を持つ DDTrace データがバッチでレポートされる場合があります。
  • 運用環境 (マルチサービス、マルチ DataKit 展開) では、完全なトレース データはバッチでデータ センターにアップロードされ、呼び出しの順序でデータ センターにアップロードされるわけではありません。
  • parent_id = 0 はルート スパンです。
  • span_type = entry は、service 内の最初の resource の呼び出し元、つまりその service 内の最初の span を表します。

FAQ

トレースの HTTP ステータスが 4xx エラーでも Span ステータスが OK になるのはなぜですか？

トレースシステムのスパン状態は、対象となる業務システムの実行状態を監視します。ほとんどの場合、ターゲット システムは、トランスポート層やネットワーク層、あるいは下位レベルのシステムではなく、ユーザーのビジネス システムに相当します。 HTTP もビジネス層にありますが、4xx エラーは顧客のビジネス層には入っておらず、HTTP プロトコル スタック内のクライアントに属しています。したがって、顧客ビジネス層に対応する API はこのクライアント エラーを正しく識別しているため、スパン ステータスはまだ OK です。

フィードバック

このページは役に立ちましたか？