CloudEvent トレースへのアクセス¶

Knative Eventing クラスターにインストールしたリクエストトレースツールに応じて、リクエストの可視化とトレースの方法については、対応するセクションを参照してください。

始める前に¶

Eventing コンポーネントがインストールされた Knative クラスターが実行されている必要があります。詳細はこちら。

トレースの構成¶

インポーターを除き、Knative Eventing のトレースは knative-eventing 名前空間の config-tracing ConfigMap を介して構成されます。

ほとんどのインポーターは ConfigMap を使用せず、代わりに静的な 1% のサンプリングレートを使用します。

config-tracing ConfigMap を使用して、次の Eventing コンポーネントを構成できます

ブローカー
トリガー
InMemoryChannel
ApiServerSource
PingSource
GitlabSource
KafkaSource
PrometheusSource

例

次の config-tracing ConfigMap の例は、すべての CloudEvents の 10% をサンプリングします

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-tracing
  namespace: knative-eventing
data:
  backend: "zipkin"
  zipkin-endpoint: "http://zipkin.istio-system.svc.cluster.local:9411/api/v2/spans"
  sample-rate: "0.1"

構成オプション¶

次のオプションを使用して、config-tracing を構成できます

backend: 有効な値は zipkin または none です。デフォルトは none です。
zipkin-endpoint: トレースを送信する zipkin コレクターへの URL を指定します。backend が zipkin に設定されている場合は設定する必要があります。
sample-rate: サンプリングレートを指定します。有効な値は 0 から 1 までの小数 (float64 として解釈) で、特定のリクエストがサンプリングされる確率を示します。たとえば、値が 0.5 の場合は、各リクエストに 50% のサンプリング確率が与えられます。
debug: デバッグを有効にします。有効な値は true または false です。指定しない場合は、デフォルトで false になります。デバッグモードを有効にするには true に設定します。これにより、sample-rate が 1.0 に強制され、すべてのスパンがサーバーに送信されます。

`config-tracing` ConfigMap を表示する¶

現在の構成を表示するには

kubectl -n knative-eventing get configmap config-tracing -oyaml

`config-tracing` ConfigMap を編集およびデプロイする¶

ConfigMap の変更を編集してすぐにデプロイするには、次のコマンドを実行します

kubectl -n knative-eventing edit configmap config-tracing

Eventing でトレースにアクセスする¶

トレースにアクセスするには、Zipkin または Jaeger ツールを使用します。これらのツールを使用してトレースにアクセスする方法の詳細については、Knative Serving の可観測性に関するセクションを参照してください

例¶

次は、TestBrokerTracing エンドツーエンドテストを使用して、Zipkin で Knative Eventing のリクエストをトレースする方法を示します。

この例では、次の詳細を想定します

すべてが includes-incoming-trace-id-2qszn 名前空間で発生します。
ブローカーの名前は br です。
ブローカーに関連付けられた 2 つのトリガーがあります
- transformer - タイプが transformer のイベントのみを許可するフィルター。イベントを Kubernetes サービス transformer に送信します。このサービスは、返信されたイベントのタイプが logger になる以外は、同一のイベントを返信します。
- logger - タイプが logger のイベントのみを許可するフィルター。イベントを Kubernetes サービス logger に送信します。
タイプが transformer のイベントが、sender という名前のポッドによってブローカーに送信されます。

このシナリオでは、イベントの予期されるパスと動作は次のとおりです

sender ポッドがリクエストをブローカーに送信します。
ブローカーのイングレスポッドに移動します。
imc-dispatcher チャネルに移動します (imc は InMemoryChannel の略)。
両方のトリガーに移動します。
1. トリガー logger のブローカーのフィルターポッドに移動します。トリガーのフィルターはこのイベントを無視します。
2. トリガー transformer のブローカーのフィルターポッドに移動します。フィルターが通過するため、指定された Kubernetes サービス (同じく transformer という名前) に移動します。
  1. transformer ポッドが変更されたイベントで応答します。
  2. InMemory ディスパッチャーに移動します。
  3. ブローカーのイングレスポッドに移動します。
  4. InMemory ディスパッチャーに移動します。
  5. 両方のトリガーに移動します。
    1. トリガー transformer のブローカーのフィルターポッドに移動します。トリガーのフィルターはイベントを無視します。
    2. トリガー logger のブローカーのフィルターポッドに移動します。フィルターが通過します。
      1. logger ポッドに移動します。返信はありません。

これは、Zipkin のトレースビューのスクリーンショットです。すべての赤い文字はスクリーンショットに追加されており、このセクションの先頭にある期待値に対応しています

Annotated Trace

これは、注釈がない同じスクリーンショットです。

Raw Trace

興味がある場合は、トレースの生の JSONはこちらにあります。