支持控制台（Console）开发人员开始试用联系人

3.2. 配置

Tempo Operator 使用自定义资源定义(CRD)文件来定义创建和部署分布式追踪平台(Tempo)资源时要使用的架构和配置设置。您可以安装默认配置或修改该文件。

3.2.1. 配置后端存储

有关配置后端存储的详情，请参考 了解持久性存储 以及您选择的存储选项的适当配置主题。

3.2.2. TempoStack 配置参数简介

TempoStack 自定义资源 (CR)定义创建分布式追踪平台 (Tempo) 资源时要使用的架构和设置。您可以根据您的业务需求，修改这些参数以自定义您的实现。

TempoStack CR 示例

apiVersion: tempo.grafana.com/v1alpha1 1
kind: TempoStack 2
metadata: 3
  name: <name> 4
spec: 5
  storage: {} 6
  resources: {} 7
  replicationFactor: 1 8
  retention: {} 9
  template:
      distributor: {} 10
      ingester: {} 11
      compactor: {} 12
      querier: {} 13
      queryFrontend: {} 14
      gateway: {} 15
  limits: 16
    global:
      ingestion: {} 17
      query: {} 18
  observability: 19
    grafana: {}
    metrics: {}
    tracing: {}
  search: {} 20
managementState: managed 21

1
创建对象时要使用的 API 版本。
2
定义要创建的 Kubernetes 对象的种类。
3
唯一标识对象的数据，包括 name 字符串，UID, 和可选的 namespace。OpenShift Container Platform 会自动生成 UID 并使用创建对象的项目名称完成 namespace。
4
TempoStack 实例的名称。
5
包含 TempoStack 实例的所有配置参数。当需要一个适用于所有 Tempo 组件的通用定义时，在 spec 部分中定义它。当定义只与单个组件相关时，将其放在 spec.template.<component> 部分中。
6
存储在实例部署中指定。有关实例的存储选项的信息，请参阅安装页。
7
为 Tempo 容器定义计算资源。
8
在接受范围之前，必须确认经销商中的数据数量的整数值。
9
保留 trace 的配置选项。
10
Tempo distributor 组件的配置选项。
11
Tempo ingester 组件的配置选项。
12
Tempo compactor 组件的配置选项。
13
Tempo querier 组件的配置选项。
14
Tempo query-frontend 组件的配置选项。
15
Tempo gateway 组件的配置选项。
16
摄入（ingestion）和查询（query）率限制。
17
定义摄入率限制。
18
定义查询率限制。
19
配置操作对象以处理遥测数据。
20
配置搜索功能。
21
定义此 CR 是否由 Operator 管理。默认值为 managed。

其他资源

3.2.3. 查询配置选项

分布式追踪平台 (Tempo) 的两个组件，即 querier 和 query frontend，用于管理查询。您可以配置这两个组件。

querier 组件在 ingesters 或后端存储中查找请求的 trace ID。根据设置的参数，querier 组件可以查询 ingesters，并从后端拉取 bloom 或索引，以便在对象存储中搜索块。querier 组件在 GET /querier/api/traces/<trace_id> 公开 HTTP 端点，但不预期直接使用。查询必须发送到查询前端。

表 3.2. querier 组件的配置参数
参数描述值

nodeSelector

node-selection 约束的简单形式。

类型：对象

replicas

为组件创建的副本数。

类型：整数；格式： int32

容限（tolerations）

特定于组件的 pod 容限。

类型：数组

查询前端组件负责为传入的查询对搜索空间进行分片。查询前端通过简单的 HTTP 端点公开 trace：GET /api/traces/<trace_id>。在内部，查询 frontend 组件将 blockID 空间分成可配置的分片数量，然后对这些请求进行队列。querier 组件通过流 gRPC 连接连接到查询 frontend 组件，以处理这些分片查询。

表 3.3. 查询前端组件的配置参数
参数描述值

component

配置查询前端组件。

类型：对象

component.nodeSelector

节点选择约束的简单形式。

类型：对象

component.replicas

为查询前端组件创建的副本数。

类型：整数；格式： int32

component.tolerations

特定于查询前端组件的 Pod 容限。

类型：数组

jaegerQuery

特定于 Jaeger Query 组件的选项。

类型：对象

jaegerQuery.enabled

启用后，创建 Jaeger Query 组件jaegerQuery。

类型：布尔值

jaegerQuery.ingress

Jaeger Query ingress 的选项。

类型：对象

jaegerQuery.ingress.annotations

ingress 对象的注解。

类型：对象

jaegerQuery.ingress.host

ingress 对象的主机名。

类型：字符串

jaegerQuery.ingress.ingressClassName

IngressClass 集群资源的名称。定义哪个入口控制器提供此入口资源。

类型：字符串

jaegerQuery.ingress.route

OpenShift 路由的选项。

类型：对象

jaegerQuery.ingress.route.termination

终止类型。默认为 edge。

类型：字符串 (enum: insecure, edge, passthrough, reencrypt)

jaegerQuery.ingress.type

Jaeger Query UI 的 ingress 类型。支持的类型有 ingress、route 和 none。

类型：字符串 (enum: ingress, route)

jaegerQuery.monitorTab

monitor 选项卡配置。

类型：对象

jaegerQuery.monitorTab.enabled

在 Jaeger 控制台中启用 monitor 选项卡。必须配置 PrometheusEndpoint。

类型：布尔值

jaegerQuery.monitorTab.prometheusEndpoint

包含 span rate、error 和 duration (RED) 指标的 Prometheus 实例的端点。例如：https://thanos-querier.openshift-monitoring.svc.cluster.local:9091。

类型：字符串

TempoStack CR 中的查询前端组件的配置示例

apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: simplest
spec:
  storage:
    secret:
      name: minio
      type: s3
  storageSize: 200M
  resources:
    total:
      limits:
        memory: 2Gi
        cpu: 2000m
  template:
    queryFrontend:
      jaegerQuery:
        enabled: true
        ingress:
          route:
            termination: edge
          type: route

其他资源

3.2.4. 在 Jaeger UI 中配置 monitor 选项卡

跟踪数据包含丰富的信息，数据在检测的语言和框架中规范化。因此，请求率、错误和持续时间(RED)指标可以从 trace 中提取。指标可以在 Jaeger 控制台的 Monitor 选项卡中视觉化。

指标派生自 OpenTelemetry Collector 中的 span，由 user-workload 监控堆栈中部署的 Prometheus 从 Collector 中提取。Jaeger UI 从 Prometheus 端点查询这些指标，并视觉化它们。

3.2.4.1. OpenTelemetry Collector 配置

OpenTelemetry Collector 需要配置 spanmetrics 连接器，该连接器从 trace 中派生指标，并以 Prometheus 格式导出指标。

OpenTelemetry Collector 自定义资源，用于 span RED

kind: OpenTelemetryCollector
apiVersion: opentelemetry.io/v1alpha1
metadata:
  name: otel
spec:
  mode: deployment
  observability:
    metrics:
      enableMetrics: true 1
  config: |
    connectors:
      spanmetrics: 2
        metrics_flush_interval: 15s

    receivers:
      otlp: 3
        protocols:
          grpc:
          http:

    exporters:
      prometheus: 4
        endpoint: 0.0.0.0:8889
        add_metric_suffixes: false
        resource_to_telemetry_conversion:
          enabled: true # by default resource attributes are dropped

      otlp:
        endpoint: "tempo-simplest-distributor:4317"
        tls:
          insecure: true

    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [otlp, spanmetrics] 5
        metrics:
          receivers: [spanmetrics] 6
          exporters: [prometheus]

1
创建 ServiceMonitor 自定义资源，以启用 Prometheus exporter 的提取。
2
Spanmetrics 连接器接收 trace 和 exports 指标。
3
OTLP 接收器在 OpenTelemetry 协议中接收 span。
4
Prometheus exporter 用于导出 Prometheus 格式的指标。
5
Spanmetrics 连接器在 trace 管道中被配置为 exporter。
6
Spanmetrics 连接器在 metrics 管道中配置为接收器。

3.2.4.2. Tempo 配置

TempoStack 自定义资源必须指定以下内容： Monitor 选项卡已启用，Prometheus 端点则设置为 Thanos querier 服务，以从用户定义的监控堆栈查询数据。

带有启用的 Monitor 选项卡的 TempoStack 自定义资源

apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: redmetrics
spec:
  storage:
    secret:
      name: minio-test
      type: s3
  storageSize: 1Gi
  template:
    gateway:
      enabled: false
    queryFrontend:
      jaegerQuery:
        enabled: true
        monitorTab:
          enabled: true 1
          prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 2
        ingress:
          type: route

1
在 Jaeger 控制台中启用 Monitoring 选项卡。
2
来自 user-workload 监控的 Thanos Querier 的服务名称。

3.2.4.3. Span RED 指标和警报规则

spanmetrics 连接器生成的指标可用于警报规则。例如，对于有关较慢的服务或定义服务级别目标(SLO)的警报，连接器会创建一个 duration_bucket 直方图和 调用 计数器指标。这些指标具有标识服务、API 名称、操作类型和其他属性的标签。

表 3.4. 在 spanmetrics 连接器中创建的指标标签
标签描述值

service_name

由 otel_service_name 环境变量设置的服务名称。

frontend

span_name

操作的名称。

  • /
  • /customer

span_kind

标识服务器、客户端、消息传递或内部操作。

  • SPAN_KIND_SERVER
  • SPAN_KIND_CLIENT
  • SPAN_KIND_PRODUCER
  • SPAN_KIND_CONSUMER
  • SPAN_KIND_INTERNAL

PrometheusRule CR 示例，它为 SLO 定义了一个警告规则 - 在前端服务中，有 95% 的请求在 2000ms 内没有被处理完。

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: span-red
spec:
  groups:
  - name: server-side-latency
    rules:
    - alert: SpanREDFrontendAPIRequestLatency
      expr: histogram_quantile(0.95, sum(rate(duration_bucket{service_name="frontend", span_kind="SPAN_KIND_SERVER"}[5m])) by (le, service_name, span_name)) > 2000 1
      labels:
        severity: Warning
      annotations:
        summary: "High request latency on {{$labels.service_name}} and {{$labels.span_name}}"
        description: "{{$labels.instance}} has 95th request latency above 2s (current value: {{$value}}s)"

1
这个表达式检查，是否 95% 的前端服务器响应时间值低于 2000 ms。时间范围 ([5m]) 必须至少是提取间隔的四倍，并且足以适应指标的变化。

3.2.5. 配置接收器 TLS

TempoStack 或 TempoMonolithic 实例的自定义资源支持使用用户提供的证书或 OpenShift 的服务证书为接收器配置 TLS。

3.2.5.1. TempoStack 实例的接收器 TLS 配置

您可以在 secret 中提供 TLS 证书，或使用 OpenShift Container Platform 生成的服务证书。

  • 要在 secret 中提供 TLS 证书，请在 TempoStack 自定义资源中配置它。

    注意

    启用的 Tempo Gateway 不支持此功能。

    TLS 用于接收器并在 secret 中使用用户提供的证书

    apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoStack
# ...
spec:
# ...
  template:
    distributor:
      tls:
        enabled: true 1
        certName: <tls_secret> 2
        caName: <ca_name> 3
# ...

    1
    在 Tempo Distributor 上启用 TLS。
    2
    包含您提前应用的 tls.key 密钥和 tls.crt 证书的 secret。
    3
    可选：配置映射中的 CA 来启用 mutual TLS 身份验证 (mTLS)。

  • 另外，您可以使用 OpenShift Container Platform 生成的服务证书。

    注意

    此功能不支持 mutual TLS 身份验证 (mTLS)。

    用于接收器的 TLS 并使用 OpenShift Container Platform 生成的服务证书

    apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoStack
# ...
spec:
# ...
  template:
    distributor:
      tls:
        enabled: true 1
# ...

    1
    在 Tempo Distributor 为 TLS 进行足够配置。

其他资源

3.2.5.2. TempoMonolithic 实例的接收器 TLS 配置

您可以在 secret 中提供 TLS 证书，或使用 OpenShift Container Platform 生成的服务证书。

  • 要在 secret 中提供 TLS 证书，请在 TempoMonolithic 自定义资源中配置它。

    注意

    启用的 Tempo Gateway 不支持此功能。

    TLS 用于接收器并在 secret 中使用用户提供的证书

    apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoMonolithic
# ...
  spec:
# ...
  ingestion:
    otlp:
      grpc:
        tls:
          enabled: true 1
          certName: <tls_secret> 2
          caName: <ca_name> 3
# ...

    1
    在 Tempo Distributor 上启用 TLS。
    2
    包含您提前应用的 tls.key 密钥和 tls.crt 证书的 secret。
    3
    可选：配置映射中的 CA 来启用 mutual TLS 身份验证 (mTLS)。

  • 另外，您可以使用 OpenShift Container Platform 生成的服务证书。

    注意

    此功能不支持 mutual TLS 身份验证 (mTLS)。

    用于接收器的 TLS 并使用 OpenShift Container Platform 生成的服务证书

    apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoMonolithic
# ...
  spec:
# ...
  ingestion:
    otlp:
      grpc:
        tls:
          enabled: true
      http:
        tls:
          enabled: true 1
# ...

    1
    在 Tempo Distributor 为 TLS 的最小配置。

其他资源

3.2.6. 多租户

Tempo Gateway 服务中提供了带有身份验证和授权的多租户。身份验证使用 OpenShift OAuth 和 Kubernetes TokenReview API。授权使用 Kubernetes SubjectAccessReview API。

注意

Tempo Gateway 服务只支持通过 OTLP/gRPC 处理 trace。不支持 OTLP/HTTP。

带有两个租户的 Tempo CR 示例，dev 和 prod

apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoStack
metadata:
  name: simplest
  namespace: chainsaw-multitenancy
spec:
  storage:
    secret:
      name: minio
      type: s3
  storageSize: 1Gi
  resources:
    total:
      limits:
        memory: 2Gi
        cpu: 2000m
  tenants:
    mode: openshift 1
    authentication: 2
      - tenantName: dev 3
        tenantId: "1610b0c3-c509-4592-a256-a1871353dbfa" 4
      - tenantName: prod
        tenantId: "1610b0c3-c509-4592-a256-a1871353dbfb"
  template:
    gateway:
      enabled: true 5
    queryFrontend:
      jaegerQuery:
        enabled: true

1
必须设置为 openshift。
2
租户列表。
3
租户名称。在选择数据时，必须在 X-Scope-OrgId 标头中提供。
4
唯一的租户 ID。
5
启用执行身份验证和授权的网关。Jaeger UI 通过 http://<gateway-ingress>/api/traces/v1/<tenant-name>/search 公开。

授权配置使用 Kubernetes 基于角色的访问控制(RBAC)的 ClusterRole 和 ClusterRoleBinding。默认情况下，任何用户都没有读取或写入权限。

允许经过身份验证的用户读取 dev 和 prod 租户的 trace 数据的读取 RBAC 配置示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tempostack-traces-reader
rules:
  - apiGroups:
      - 'tempo.grafana.com'
    resources: 1
      - dev
      - prod
    resourceNames:
      - traces
    verbs:
      - 'get' 2
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tempostack-traces-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tempostack-traces-reader
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: system:authenticated 3

1
列出租户。
2
get 值可启用读取操作。
3
授予所有经过身份验证的用户的 trace 数据读取权限。

允许 otel-collector 服务帐户编写 dev 租户的 trace 数据的写入 RBAC 配置示例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: otel-collector 1
  namespace: otel
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tempostack-traces-write
rules:
  - apiGroups:
      - 'tempo.grafana.com'
    resources: 2
      - dev
    resourceNames:
      - traces
    verbs:
      - 'create' 3
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tempostack-traces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tempostack-traces-write
subjects:
  - kind: ServiceAccount
    name: otel-collector
    namespace: otel

1
导出 trace 数据时要使用的客户端的服务帐户名称。客户端必须将服务帐户令牌 /var/run/secrets/kubernetes.io/serviceaccount/token 发送为 bearer 令牌标头。
2
列出租户。
3
create 值启用写入操作。

追踪数据可以从 OpenTelemetry 收集器发送到 Tempo 实例，该收集器使用带有 RBAC 的服务帐户来写入数据。

OpenTelemetry CR 配置示例

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: cluster-collector
  namespace: tracing-system
spec:
  mode: deployment
  serviceAccount: otel-collector
  config: |
      extensions:
        bearertokenauth:
          filename: "/var/run/secrets/kubernetes.io/serviceaccount/token"
      exporters:
        otlp/dev: 1
          endpoint: tempo-simplest-gateway.tempo.svc.cluster.local:8090
          tls:
            insecure: false
            ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
          auth:
            authenticator: bearertokenauth
          headers:
            X-Scope-OrgID: "dev"
        otlphttp/dev: 2
          endpoint: https://tempo-simplest-gateway.chainsaw-multitenancy.svc.cluster.local:8080/api/traces/v1/dev
          tls:
            insecure: false
            ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
          auth:
            authenticator: bearertokenauth
          headers:
            X-Scope-OrgID: "dev"
      service:
        extensions: [bearertokenauth]
        pipelines:
          traces:
            exporters: [otlp/dev] 3

1
OTLP gRPC Exporter。
2
OTLP HTTP Exporter。
3
您可以为 OTLP gRPC Exporter 指定 otlp/dev，为 OTLP HTTP Exporter 指定 otlphttp/dev。

3.2.7. 使用污点和容限

要将 TempoStack pod 调度到专用节点上，请参阅 如何在 OpenShift 4 中使用 nodeSelector 和 tolerations 在 infra 节点上部署不同的 TempoStack 组件。

3.2.8. 配置监控和警报

Tempo Operator 支持每个 TempoStack 组件的监控和警报，如经销商、ingester 等，并公开有关 Operator 本身的升级和操作指标。

3.2.8.1. 配置 TempoStack 指标和警报

您可以启用 TempoStack 实例的指标和警报。

先决条件

  • 在集群中启用对用户定义的项目的监控。

流程

  1. 要启用 TempoStack 实例的指标，请将 spec.observability.metrics.createServiceMonitors 字段设置为 true ： 

    apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: <name>
spec:
  observability:
    metrics:
      createServiceMonitors: true

  2. 要为 TempoStack 实例启用警报，请将 spec.observability.metrics.createPrometheusRules 字段设置为 true ： 

    apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: <name>
spec:
  observability:
    metrics:
      createPrometheusRules: true

验证

您可以使用 Web 控制台的 Administrator 视图来验证配置是否成功：

  1. 进入 Observe Targets，过滤 Source: User, 检查 ServiceMonitors（格式为 tempo-<instance_name>-<component>）的状态为 Up。
  2. 要验证警报是否已正确设置，请转至 Observe Alerting Alerting rules，过滤 Source: User，并检查 TempoStack 实例组件的 Alert 规则 是否可用。

其他资源

3.2.8.2. 配置 Tempo Operator 指标和警报

从 web 控制台安装 Tempo Operator 时，您可以选择 Enable Operator recommended cluster monitoring on this Namespace 复选框，它允许创建 Tempo Operator 的指标和警报。

如果在安装过程中没有选择复选框，您可以在安装 Tempo Operator 后手动启用指标和警报。

流程

  • 在安装了 Tempo Operator 的项目中添加 openshift.io/cluster-monitoring: "true" 标签，默认为 openshift-tempo-operator。

验证

您可以使用 Web 控制台的 Administrator 视图来验证配置是否成功：

  1. 进入 Observe Targets，过滤 Source: Platform，并搜索 tempo-operator，它必须具有 Up 状态。
  2. 要验证警报是否已正确设置，请转至 Observe Alerting Alerting rules，过滤 Source: Platform，再找到 Tempo Operator 的 Alert 规则。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.