存取 CloudEvent 追蹤

根據您在 Knative Eventing 叢集上安裝的請求追蹤工具，請參閱對應的章節，以了解如何視覺化和追蹤您的請求。

開始之前

您必須有一個正在執行且已安裝 Eventing 元件的 Knative 叢集。了解更多。

設定追蹤

除了匯入器之外，Knative Eventing 追蹤是透過 knative-eventing 命名空間中的 config-tracing ConfigMap 來設定。

大多數匯入器不使用 ConfigMap，而是使用靜態 1% 取樣率。

您可以使用 config-tracing ConfigMap 來設定下列 Eventing 元件

• 訊息代理器
• 觸發器 (Triggers)
• InMemoryChannel
• ApiServerSource
• PingSource
• GitlabSource
• KafkaSource
• PrometheusSource

範例

以下範例 config-tracing ConfigMap 會取樣 10% 的所有 CloudEvents

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 可觀察性章節

• Zipkin
• Jaeger

範例

以下示範如何使用 Zipkin 在 Knative Eventing 中追蹤請求，使用 TestBrokerTracing 端對端測試。

在此範例中，假設有以下詳細資訊

• 所有事情都發生在 includes-incoming-trace-id-2qszn 命名空間中。
• Broker 名稱為 br。
• 有兩個與 Broker 相關聯的觸發器 (Triggers)
  • transformer - 篩選以僅允許類型為 transformer 的事件。將事件傳送到 Kubernetes 服務 transformer，該服務將回覆一個相同的事件，只是回覆事件的類型將為 logger。
  • logger - 篩選以僅允許類型為 logger 的事件。將事件傳送到 Kubernetes 服務 logger。
• 事件是由名為 sender 的 Pod 以類型 transformer 傳送到 Broker。

在這個情境下，事件的預期路徑和行為如下

1. sender Pod 將請求傳送到 Broker。
2. 前往 Broker 的 ingress Pod。
3. 前往 imc-dispatcher 通道 (imc 代表 InMemoryChannel)。
4. 前往兩個觸發器 (Triggers)。
   1. 前往觸發器 (Trigger) logger 的 Broker 篩選 Pod。觸發器的篩選器會忽略此事件。
   2. 前往觸發器 (Trigger) transformer 的 Broker 篩選 Pod。篩選器通過，因此會前往指向的 Kubernetes 服務，也稱為 transformer。
      1. transformer Pod 回覆修改後的事件。
      2. 前往 InMemory 分派器。
      3. 前往 Broker 的 ingress Pod。
      4. 前往 InMemory 分派器。
      5. 前往兩個觸發器 (Triggers)。
         1. 前往觸發器 (Trigger) transformer 的 Broker 篩選 Pod。觸發器的篩選器會忽略該事件。
         2. 前往觸發器 (Trigger) logger 的 Broker 篩選 Pod。篩選器通過。
            1. 前往 logger Pod。沒有回覆。

這是 Zipkin 中追蹤檢視的螢幕擷取畫面。所有紅色字母都已新增到螢幕擷取畫面中，並對應於本節稍早的預期

這是沒有註釋的相同螢幕擷取畫面。

如果您有興趣，這裡有追蹤的 原始 JSON。