搜索

3.2. 配置

download PDF

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

3.2.1. 自定义部署

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

3.2.1.1. 默认配置选项

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

通用 Tempo YAML 文件示例

apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: name
spec:
  storage: {}
  resources: {}
  storageSize: 200M
  replicationFactor: 1
  retention: {}
  template:
      distributor:{}
      ingester: {}
      compactor: {}
      querier: {}
      queryFrontend: {}
      gateway: {}

表 3.2. Tempo 参数
参数描述默认值

apiVersion:

创建对象时要使用的 API 版本。

tempo.grafana.com/v1alpha1

tempo.grafana.com/v1alpha1

kind:

定义要创建的 Kubernetes 对象的种类。

tempo

 

metadata:

唯一标识对象的数据,包括 name 字符串,UID, 和可选的 namespace

 

OpenShift Container Platform 会自动生成 UID 并使用创建对象的项目名称完成 namespace

name:

对象的名称。

TempoStack 实例的名称。

tempo-all-in-one-inmemory

spec:

要创建的对象的规格。

包含 TempoStack 实例的所有配置参数。当需要所有 Tempo 组件的通用定义时,会在 spec 节点下定义它。当定义与单个组件相关时,它将放置在 spec/template/<component> 节点下。

N/A

resources:

分配给 TempoStack 实例的资源。

  

storageSize :

ingester PVC 的存储大小。

  

replicationFactor:

复制因素的配置。

  

retention:

保留 trace 的配置选项。

  

storage:

定义存储的配置选项。所有与存储相关的选项都必须放在 storage 下,而不是放在 allInOne 或其他组件选项下。

  

template.distributor:

Tempo distributor 的配置选项。

  

template.ingester:

Tempo ingester 的配置选项。

  

template.compactor:

Tempo compactor 的配置选项。

  

template.querier:

Tempo querier 的配置选项。

  

template.queryFrontend:

Tempo query-frontend 的配置选项。

  

template.gateway:

Tempo gateway 的配置选项。

  

最低要求配置

以下是使用默认设置创建分布式追踪平台(Tempo)部署所需的最小值:

apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
  name: simplest
spec:
  storage: 1
    secret:
      name: minio
      type: s3
  resources:
    total:
      limits:
        memory: 2Gi
        cpu: 2000m
  template:
    queryFrontend:
      jaegerQuery:
        enabled: true
        ingress:
          type: route
1
本节指定部署的对象存储后端,它需要一个含有凭据的 secret 才能访问对象存储。

3.2.1.2. 存储配置

您可以在 spec.storage 下的 TempoStack 自定义资源中为分布式追踪平台(Tempo)配置对象存储。您可以从支持的多个存储供应商中选择。

表 3.3. Tempo Operator 用来定义分布式追踪存储的一般存储参数
参数描述默认值

spec.storage.secret.type

要在部署中使用的存储类型。

内存。内存存储仅适用于开发、测试、演示和概念验证环境,因为数据在 pod 关闭时不会保留。

内存

storage.secretname

包含设置对象类型凭证的 secret 名称。

 

N/A

storage.tls.caName

CA 是包含 CA 证书的 ConfigMap 对象的名称。

  
表 3.4. 所需的 secret 参数
存储供应商

Secret 参数

{odf-full}

name: tempostack-dev-odf # example

bucket: <bucket_name> # requires an ObjectBucketClaim

endpoint: https://s3.openshift-storage.svc

access_key_id: <data_foundation_access_key_id>

access_key_secret: <data_foundation_access_key_secret>

MinIO

请参阅 MinIO Operator

name: tempostack-dev-minio # example

bucket: <minio_bucket_name> # MinIO documentation

endpoint: <minio_bucket_endpoint>

access_key_id: <minio_access_key_id>

access_key_secret: <minio_access_key_secret>

Amazon S3

name: tempostack-dev-s3 # example

bucket: <s3_bucket_name> # Amazon S3 documentation

endpoint: <s3_bucket_endpoint>

access_key_id: <s3_access_key_id>

access_key_secret: <s3_access_key_secret>

Microsoft Azure Blob Storage

name: tempostack-dev-azure # example

container: <azure_blob_storage_container_name> # Microsoft Azure documentation

account_name: <azure_blob_storage_account_name>

account_key: <azure_blob_storage_account_key>

Google Cloud Storage on Google Cloud Platform (GCP)

name: tempostack-dev-gcs # example

bucketname: <google_cloud_storage_bucket_name> # requires a bucket created in a GCP project

key.json: <path/to/key.json> # requires a service account in the bucket’s GCP project for GCP authentication

3.2.1.3. 查询配置选项

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

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

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

nodeSelector

node-selection 约束的简单形式。

类型:对象

replicas

为组件创建的副本数。

类型:整数;格式: int32

容限(tolerations)

特定于组件的 pod 容限。

类型:数组

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

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

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 类型。支持的类型有 ingressroutenone

类型:字符串 (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.1.3.1. 其他资源

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

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

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

3.2.1.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.1.4.2. Tempo 配置

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

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

kind: TempoStack
apiVersion: tempo.grafana.com/v1alpha1
metadata:
  name: simplest
spec:
  template:
    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.1.4.3. Span RED 指标和警报规则

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

表 3.7. 在 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.1.5. 多租户

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

注意

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

带有两个租户的 Tempo CR 示例,devprod

apiVersion: tempo.grafana.com/v1alpha1
kind:  TempoStack
metadata:
  name: simplest
spec:
  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)的 ClusterRoleClusterRoleBinding。默认情况下,任何用户都没有读取或写入权限。

允许经过身份验证的用户读取 devprod 租户的 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:
          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"
      service:
        extensions: [bearertokenauth]
        pipelines:
          traces:
            exporters: [otlp/dev]

3.2.2. 配置监控和警报

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

3.2.2.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.2.1.1. 其他资源

3.2.2.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 OperatorAlert 规则
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.