3.2. 구성


Tempo Operator는 분산 추적 플랫폼(Tempo) 리소스를 생성하고 배포하기 위한 아키텍처 및 구성 설정을 정의하는 CRD(사용자 정의 리소스 정의) 파일을 사용합니다. 기본 구성을 설치하거나 파일을 수정할 수 있습니다.

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
추적 보존을 위한 구성 옵션입니다.
10
Tempo 배포자 구성 요소에 대한 구성 옵션입니다.
11
Tempo ingester 구성 요소에 대한 구성 옵션입니다.
12
Tempo compactor 구성 요소에 대한 구성 옵션입니다.
13
Tempo querier 구성 요소에 대한 구성 옵션입니다.
14
Tempo query-frontend 구성 요소에 대한 구성 옵션입니다.
15
Tempo 게이트웨이 구성 요소에 대한 구성 옵션입니다.
16
수집 및 쿼리 속도를 제한합니다.
17
ingestion rate limits를 정의합니다.
18
쿼리 속도 제한을 정의합니다.
19
Telemetry 데이터를 처리하도록 피연산자를 구성합니다.
20
검색 기능을 구성합니다.
21
Operator에서 이 CR을 관리할지 여부를 정의합니다. 기본값은 managed 입니다.

3.2.3. 쿼리 구성 옵션

분산 추적 플랫폼(Tempo)의 두 구성 요소인 querier 및 쿼리 프런트 엔드는 쿼리를 관리합니다. 이러한 두 구성 요소를 모두 구성할 수 있습니다.

querier 구성 요소는 ingesters 또는 백엔드 스토리지에서 요청된 추적 ID를 찾습니다. set 매개변수에 따라 querier 구성 요소는 ingesters 및 pull bloom 또는 인덱스를 백엔드에서 오브젝트 스토리지의 검색 블록으로 쿼리할 수 있습니다. querier 구성 요소는 GET /querier/api/traces/<trace_id >에서 HTTP 끝점을 노출하지만 직접 사용할 수는 없습니다. 쿼리를 쿼리 프런트 엔드로 보내야 합니다.

표 3.2. querier 구성 요소에 대한 구성 매개변수
매개변수설명

nodeSelector

노드 선택 제약 조건의 간단한 형식입니다.

유형: 오브젝트

replicas

구성 요소에 대해 생성할 복제본 수입니다.

유형: 정수; 형식: int32

허용 오차

구성 요소별 Pod 허용 오차입니다.

유형: array

쿼리 프런트 엔드 구성 요소는 들어오는 쿼리의 검색 공간을 분할합니다. 쿼리 프런트 엔드는 간단한 HTTP 끝점을 통해 추적을 노출합니다. GET /api/traces/<trace_id > . 내부적으로 쿼리 프런트 엔드 구성 요소는 blockID 공간을 구성 가능한 수의 shard로 분할한 다음 이러한 요청을 대기열에 넣습니다. querier 구성 요소는 스트리밍 gRPC 연결을 통해 쿼리 프런트 엔드 구성 요소에 연결하여 이러한 분할된 쿼리를 처리합니다.

표 3.3. 쿼리 프런트 엔드 구성 요소에 대한 구성 매개변수
매개변수설명

component

쿼리 프런트 엔드 구성 요소입니다.

유형: 오브젝트

component.nodeSelector

노드 선택 제약 조건의 간단한 형식입니다.

유형: 오브젝트

component.replicas

쿼리 프런트 엔드 구성 요소에 대해 생성할 복제본 수입니다.

유형: 정수; 형식: int32

component.tolerations

쿼리 프런트 엔드 구성 요소와 관련된 Pod 허용 오차입니다.

유형: array

jaegerQuery

Jaeger 쿼리 구성 요소와 관련된 옵션입니다.

유형: 오브젝트

jaegerQuery.enabled

활성화하면 Jaeger 쿼리 구성 요소jaegerQuery 를 생성합니다.

유형: 부울

jaegerQuery.ingress

Jaeger 쿼리 수신에 대한 옵션입니다.

유형: 오브젝트

jaegerQuery.ingress.annotations

ingress 오브젝트의 주석입니다.

유형: 오브젝트

jaegerQuery.ingress.host

ingress 오브젝트의 호스트 이름입니다.

유형: 문자열

jaegerQuery.ingress.ingressClassName

IngressClass 클러스터 리소스의 이름입니다. 이 수신 리소스를 제공하는 수신 컨트롤러를 정의합니다.

유형: 문자열

jaegerQuery.ingress.route

OpenShift 경로에 대한 옵션입니다.

유형: 오브젝트

jaegerQuery.ingress.route.termination

종료 유형입니다. 기본값은 edge 입니다.

type: string (enum: insecure, edge, passthrough, reencrypt)

jaegerQuery.ingress.type

Jaeger 쿼리 UI의 수신 유형입니다. 지원되는 유형은 ingress,route, none 입니다.

유형: 문자열(um: ingress, route)

jaegerQuery.monitorTab

모니터 탭 구성입니다.

유형: 오브젝트

jaegerQuery.monitorTab.enabled

Jaeger 콘솔에서 모니터 탭을 활성화합니다. PrometheusEndpoint 를 구성해야 합니다.

유형: 부울

jaegerQuery.monitorTab.prometheusEndpoint

범위 속도, 오류 및 기간(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의 모니터 탭 구성

추적 데이터에는 풍부한 정보가 포함되어 있으며, 이 데이터는 조정된 언어 및 프레임워크 전반에서 정규화됩니다. 따라서 추적에서 요청 속도, 오류 및 기간(RED) 지표를 추출할 수 있습니다. 메트릭은 모니터 탭의 Jaeger 콘솔에서 시각화할 수 있습니다.

지표는 사용자 워크로드 모니터링 스택에 배포된 Prometheus에 의해 수집기에서 스크랩되는 OpenTelemetry 수집기의 범위에서 파생됩니다. Jaeger UI는 Prometheus 끝점에서 이러한 지표를 쿼리하고 시각화합니다.

3.2.4.1. OpenTelemetry 수집기 구성

OpenTelemetry 수집기에는 추적에서 메트릭을 파생하고 Prometheus 형식으로 메트릭을 내보내는 spanmetrics 커넥터의 구성이 필요합니다.

OpenTelemetry Collector 사용자 정의 리소스 범위 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 내보내기를 스크랩할 수 있습니다.
2
Spanmetrics 커넥터는 추적 및 내보내기 메트릭을 수신합니다.
3
OpenTelemetry 프로토콜에서 기간을 수신하는 OTLP 수신자입니다.
4
Prometheus 내보내기는 Prometheus 형식으로 지표를 내보내는 데 사용됩니다.
5
Spanmetrics 커넥터는 추적 파이프라인에서 내보내기로 구성됩니다.
6
Spanmetrics 커넥터는 메트릭 파이프라인에서 수신자로 구성됩니다.

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 콘솔에서 모니터링 탭을 활성화합니다.
2
사용자 워크로드 모니터링의 Thanos Querier의 서비스 이름입니다.

3.2.4.3. 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

프런트 엔드 서비스의 2000ms 내에서 95%의 요청을 처리하지 않을 때 SLO에 대한 경고 규칙을 정의하는 PrometheusRule CR의 예

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%가 2000ms 미만인지 확인하기 위한 표현식입니다. 시간 범위([5m])는 스크랩 간격의 4배 이상이고 메트릭의 변경 사항을 수용할 수 있을 만큼 길어야 합니다.

3.2.5. 수신자 TLS 구성

TempoStack 또는 TempoMonolithic 인스턴스의 사용자 정의 리소스는 사용자 제공 인증서 또는 OpenShift의 서비스 제공 인증서를 사용하여 수신자의 TLS 구성을 지원합니다.

3.2.5.1. TempoStack 인스턴스에 대한 수신자 TLS 구성

시크릿에 TLS 인증서를 제공하거나 OpenShift Container Platform에서 생성한 서비스 제공 인증서를 사용할 수 있습니다.

  • 시크릿에 TLS 인증서를 제공하려면 TempoStack 사용자 정의 리소스에서 구성합니다.

    참고

    이 기능은 활성화된 Tempo Gateway에서 지원되지 않습니다.

    수신자의 경우 TLS 및 시크릿에서 사용자 제공 인증서 사용

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

    1
    Tempo Cryostat에서 활성화된 TLS.
    2
    사전에 적용하는 tls.key 키 및 tls.crt 인증서가 포함된 보안입니다.
    3
    선택 사항: 구성 맵의 CA를 사용하여 상호 TLS 인증(mTLS)을 활성화합니다.
  • 또는 OpenShift Container Platform에서 생성한 서비스 제공 인증서를 사용할 수 있습니다.

    참고

    이 기능에서는 mTLS(mutual TLS Authentication)가 지원되지 않습니다.

    OpenShift Container Platform에서 생성된 수신자 및 서비스 제공 인증서를 사용하는 경우 TLS

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

    1
    Tempo Cryostat에서 TLS에 대한 충분한 구성입니다.

3.2.5.2. TempoMonolithic 인스턴스에 대한 수신자 TLS 구성

시크릿에 TLS 인증서를 제공하거나 OpenShift Container Platform에서 생성한 서비스 제공 인증서를 사용할 수 있습니다.

  • 시크릿에 TLS 인증서를 제공하려면 TempoMonolithic 사용자 정의 리소스에서 구성합니다.

    참고

    이 기능은 활성화된 Tempo Gateway에서 지원되지 않습니다.

    수신자의 경우 TLS 및 시크릿에서 사용자 제공 인증서 사용

    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 Cryostat에서 활성화된 TLS.
    2
    사전에 적용하는 tls.key 키 및 tls.crt 인증서가 포함된 보안입니다.
    3
    선택 사항: 구성 맵의 CA를 사용하여 상호 TLS 인증(mTLS)을 활성화합니다.
  • 또는 OpenShift Container Platform에서 생성한 서비스 제공 인증서를 사용할 수 있습니다.

    참고

    이 기능에서는 mTLS(mutual TLS Authentication)가 지원되지 않습니다.

    OpenShift Container Platform에서 생성된 수신자 및 서비스 제공 인증서를 사용하는 경우 TLS

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

    1
    Tempo Cryostat에서 TLS에 대한 최소 구성입니다.

3.2.6. 멀티 테넌시

인증 및 권한 부여를 사용하는 멀티 테넌시는 Tempo Gateway 서비스에 제공됩니다. 인증에서는 OpenShift OAuth 및 Kubernetes TokenReview API를 사용합니다. 권한 부여는 Kubernetes SubjectAccessReview API를 사용합니다.

참고

Tempo Gateway 서비스는 OTLP/gRPC를 통해서만 추적의 수집을 지원합니다. OTLP/HTTP는 지원되지 않습니다.

두 개의 테넌트 devprod가 있는 샘플 Tempo CR

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(역할 기반 액세스 제어)의 ClusterRoleClusterRoleBinding 을 사용합니다. 기본적으로 사용자는 읽기 또는 쓰기 권한이 없습니다.

인증된 사용자가 devprod 테넌트의 추적 데이터를 읽을 수 있는 읽기 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
인증된 모든 사용자에게 추적 데이터에 대한 읽기 권한을 부여합니다.

otel-collector 서비스 계정에서 dev 테넌트의 추적 데이터를 쓸 수 있는 쓰기 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
추적 데이터를 내보낼 때 사용할 클라이언트의 서비스 계정 이름입니다. 클라이언트는 서비스 계정 토큰인 /var/run/secrets/kubernetes.io/serviceaccount/token 을 전달자 토큰 헤더로 보내야 합니다.
2
테넌트를 나열합니다.
3
create 값은 쓰기 작업을 활성화합니다.

RBAC와 함께 서비스 계정을 사용하여 데이터를 작성하는 OpenTelemetry 수집기에서 추적 데이터를 Tempo 인스턴스로 보낼 수 있습니다.

샘플 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 HTTP Exporter에 otlp/dev 를 지정할 수 있습니다.

3.2.7. 테인트 및 톨러레이션 사용

전용 노드에서 TempoStack Pod를 예약하려면 OpenShift 4의 nodeSelector 및 허용 오차를 사용하여 인프라 노드에 다른 TempoStack 구성 요소를 배포하는 방법을 참조하십시오.

3.2.8. 모니터링 및 경고 구성

Tempo Operator는 배포자, ingester 등과 같은 각 TempoStack 구성 요소에 대한 모니터링 및 경고를 지원하며 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

검증

웹 콘솔의 관리자 보기를 사용하여 구성이 성공했는지 확인할 수 있습니다.

  1. 모니터링 대상으로 이동하여 소스: 사용자에 대해 필터링한 다음 tempo-<instance_name>-<component> 형식의 서비스 모니터링의 상태가 Up 인지 확인합니다.
  2. 경고가 올바르게 설정되었는지 확인하려면 모니터링 경고 경고 규칙으로 이동하여 소스: 사용자 에 대해 필터링한 다음 TempoStack 인스턴스 구성 요소에 대한 경고 규칙을 사용할 수 있는지 확인합니다.

3.2.8.2. Tempo Operator 지표 및 경고 구성

웹 콘솔에서 Tempo Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화 확인란을 선택하여 Tempo Operator의 메트릭 및 경고를 생성할 수 있습니다.

설치 중에 확인란을 선택하지 않은 경우 Tempo Operator를 설치한 후에도 메트릭 및 경고를 수동으로 활성화할 수 있습니다.

프로세스

  • Tempo Operator가 설치된 프로젝트에서 openshift.io/cluster-monitoring: "true" 레이블을 추가합니다. 기본값은 openshift-tempo-operator입니다.

검증

웹 콘솔의 관리자 보기를 사용하여 구성이 성공했는지 확인할 수 있습니다.

  1. 모니터링 대상으로 이동하여 소스: 플랫폼을 필터링한 다음 Up 상태가 있어야 하는 tempo-operator 를 검색합니다.
  2. 경고가 올바르게 설정되었는지 확인하려면 모니터링 경고 경고 규칙으로 이동하여 소스: 플랫폼에 대한 필터링 및 Tempo Operator경고 규칙을 찾습니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.