访问 CloudEvent 跟踪

根据您在 Knative Eventing 集群上安装的请求跟踪工具，请参阅相应的章节了解有关如何可视化和跟踪请求的详细信息。

开始之前

您必须有一个运行 Knative 集群，并已安装 Eventing 组件。 了解更多.

配置跟踪

除了导入器之外，Knative Eventing 跟踪通过 knative-eventing 命名空间中的 config-tracing ConfigMap 进行配置。

大多数导入器 *不* 使用 ConfigMap，而是使用静态的 1% 采样率。

您可以使用 config-tracing ConfigMap 来配置以下 Eventing 组件

• 代理
• 触发器
• InMemoryChannel
• ApiServerSource
• PingSource
• GitlabSource
• KafkaSource
• PrometheusSource

示例

以下示例 config-tracing ConfigMap 对所有 CloudEvent 进行 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。 如果后端设置为 zipkin，则必须设置此选项。

• sample-rate: 指定采样率。 有效值为 0 到 1 之间的十进制数（解释为浮点型），表示对任何给定请求进行采样的概率。 例如，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 关联的触发器
  • transformer - 过滤仅允许类型为 transformer 的事件。 将事件发送到 Kubernetes 服务 transformer，该服务将回复相同的事件，除了回复的事件类型将为 logger。
  • logger - 过滤仅允许类型为 logger 的事件。 将事件发送到 Kubernetes 服务 logger。
• 事件由名为 sender 的 Pod 发送到 Broker，其类型为 transformer。

鉴于此场景，事件的预期路径和行为如下

1. sender Pod 将请求发送到 Broker。
2. 转到 Broker 的入站 Pod。
3. 转到 imc-dispatcher Channel（imc 代表 InMemoryChannel）。
4. 转到两个触发器。
   1. 转到触发器 logger 的 Broker 过滤器 Pod。 触发器的过滤器会忽略此事件。
   2. 转到触发器 transformer 的 Broker 过滤器 Pod。 过滤器通过，因此它转到指向的服务，该服务也名为 transformer。
      1. transformer Pod 以修改后的事件回复。
      2. 转到 InMemory 调度程序。
      3. 转到 Broker 的入站 Pod。
      4. 转到 InMemory 调度程序。
      5. 转到两个触发器。
         1. 转到触发器 transformer 的 Broker 过滤器 Pod。 触发器的过滤器会忽略该事件。
         2. 转到触发器 logger 的 Broker 过滤器 Pod。 过滤器通过。
            1. 转到 logger Pod。 没有回复。

这是 Zipkin 中的跟踪视图截图。 所有红色字母都已添加到截图中，并对应于本节前面的预期

这是没有注释的相同截图。

如果您有兴趣，这里有该跟踪的 原始 JSON。