本文档采用自动化机器翻译技术翻译。尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。若出现任何内容不一致情况，请以原始英文版本为准，且原始英文版本为权威文本。

请求追踪

通过负载均衡器、服务网格以及集群间实现可观测性

SUSE Observability 可以观察不同集群中服务和 Pod 之间的连接，或者当连接通过服务网格或负载均衡器时。观察这些连接是通过 request tracing 完成的。被追踪的请求将在拓扑视角中产生连接，以便深入了解应用程序之间的依赖关系，并帮助找到事件的根本原因。

它是如何工作的

请求追踪是通过将一个唯一的头部（X-Request-ID 头部）注入所有 HTTP 流量中来完成的。这个唯一的头部通过安装在 SUSE Observability 代理中的 eBPF 探针在客户端和服务器上被观察到。这些观察结果被发送到 SUSE Observability，SUSE Observability 利用这些观察结果来理解哪些客户端和服务器是连接的。

X-Request-Id 头部由边车注入，该边车可以被 SUSE Observability 代理自动注入。边车是通过一个变更 webhook 注入的，该 webhook 将边车注入每个定义了 http-header-injector.stackstate.io/inject: enabled 注释的 Pod 中。在 OpenShift 上不支持边车注入。

如果您的应用程序已经有一个代理或负载均衡器，部署在启用了 Istio 服务网格的 Kubernetes 集群中，或者通过对您自己的代码进行插桩，也可以添加 X-Request-Id 头部。这样做的好处是不需要额外的边车。

启用追踪头部注入边车

启用追踪头部注入是一个两步过程：

通过在安装 SUSE Observability 代理时将 --set httpHeaderInjectorWebhook.enabled=true 添加到 helm 升级调用中，将变更 webhook 安装到集群中。默认情况下，边车注入器会生成自己的自签名证书，需要集群角色将这些证书安装到集群中。在更受限的环境中，您也可以管理自己的证书。
对于每个处理 http(s) 请求的端点的 Pod，放置注释 http-header-injector.stackstate.io/inject: enabled 以注入边车。

启用变更的网络钩子仅在 pod 重启后生效

如果注释在网络钩子安装之前放置。安装网络钩子在 pod 重启之前没有效果。

禁用追踪头注入

禁用追踪头注入可以通过反向过程完成：

从所有 pod 中移除 http-header-injector.stackstate.io/inject: enabled 注释。
在没有 --set httpHeaderInjectorWebhook.enabled=true 设置的情况下重新部署 SUSE Observability 代理。

禁用变更的网络钩子仅在 pod 重启后生效

如果跳过步骤 1，仅禁用变更的网络钩子，则所有 pod 需要重启以去除边车。

开销

请求追踪为每个被注入和观察的 HTTP 请求头增加了少量固定的处理器开销。确切的开销取决于运行的系统，因此建议先在验收环境中启用此功能以观察影响，然后再迁移到生产环境。边车每个部署的 pod 至少需要 25Mb 的内存，最多可达 40Mb。

将追踪头 ID 添加到现有代理

要从现有代理添加 X-Request-Id 头，有两个属性很重要：

每个请求/响应对必须获得一个唯一的 ID。
X-Request-Id 头应添加到请求和响应中，以便在客户端和服务器上都能观察到。

在 envoy 中添加追踪头 ID

在 envoy 中，可以通过为 http 连接设置 generate_request_id: true 和 always_set_request_id_in_response: true 来启用 X-Request-Id 头。

Istio

可以使用 Envoy 过滤器来为 Envoy 设置追踪头。

添加追踪头 ID 与 envoy 过滤器

使用 kubectl 将以下定义应用于 Kubernetes 集群，

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: responsed-x-request-id-always
  namespace: istio-system
spec:
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: ANY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
      patch:
        operation: MERGE
        value:
          typed_config:
            '@type': >-
              type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
            always_set_request_id_in_response: true
            generate_request_id: true
            preserve_external_request_id: true
  priority: 0

为您的应用程序进行插桩

也可以从客户端向每个请求添加 X-Request-Id 头，或在服务器端向每个响应添加该头。确保每个请求/响应都有唯一的 X-Request-Id 值是很重要的。此外，X-Request-Id 要求如果请求中已经存在一个 ID，则响应应包含相同的 ID。

支持的系统/技术

HTTP/1.0 和 HTTP/1.1，支持 keepAlive
在未加密流量中进行追踪头注入和追踪观察。
对 OpenSSL 加密流量进行追踪观察。
与 LinkerD 一起进行追踪头注入。
任何在请求和响应中转发 X-Request-Id 头的负载均衡器
任何在请求和响应中转发 X-Request-Id 头的跨集群网络解决方案

已知问题

我的 Pod 没有注入边车。

为了确保您的设置正常，首先验证以下步骤是否已完成：

在代理安装期间设置了 --set httpHeaderInjectorWebhook.enabled=true 标志
Pod 已设置 http-header-injector.stackstate.io/inject: enabled
Pod 已重新启动

如果这没有解决问题，可能存在以下问题：

集群网络策略

集群可以设置网络策略，防止 Kubernetes 控制平面 apiserver 联系注入边车的 mutatingvalidationwebhook。要验证这一点，请查看 kube-apiserver 的日志，该日志位于 kube-system 命名空间中，或者可能由您的云服务提供商管理。在这些日志中应该能找到如下错误：

Failed calling webhook, failing open stackstate-agent-http-header-injector-webhook.stackstate.io: failed calling webhook "stackstate-agent-http-header-injector-webhook.stackstate.io": failed to call webhook: Post "https://stackstate-agent-http-header-injector.monitoring.svc:8443/mutate?timeout=10s": context deadline exceeded

如果发生这种情况，请确保调整您的集群网络策略，以便 apiserver 可以访问 mutatingvalidationwebhook。