Cluster Observability Operator


OpenShift Container Platform 4.17

OpenShift Container Platform에서 Cluster Observability Operator 구성 및 사용

Red Hat OpenShift Documentation Team

초록

Cluster Observability Operator를 사용하여 OpenShift Container Platform에서 관찰 가능 구성 요소를 배포하고 구성합니다.

1장. Cluster Observability Operator 릴리스 노트

COO(Cluster Observability Operator)는 관리자가 다양한 서비스 및 사용자가 사용할 수 있도록 독립적으로 구성할 수 있는 독립 실행형 모니터링 스택을 생성할 수 있는 선택적 OpenShift Container Platform Operator입니다.

COO는 OpenShift Container Platform의 기본 모니터링 기능을 보완합니다. 기본 플랫폼 및 CCMO(Cluster Monitoring Operator)에서 관리하는 사용자 워크로드 모니터링 스택과 병렬로 배포할 수 있습니다.

이 릴리스 노트에서는 OpenShift Container Platform의 Cluster Observability Operator 개발을 추적합니다.

1.1. Cluster Observability Operator 1.0

1.1.1. 새로운 기능 및 개선 사항

  • OpenShift Container Platform 플랫폼 모니터링에 대해 COO가 활성화됩니다. (COO-476)

    • COO 웹 서버에 대한 HTTPS 지원을 구현합니다. (COO-480)
    • COO 웹 서버에 대한 authn/authz를 구현합니다. (COO-481)
    • COO에서 지표를 수집하도록 ServiceMonitor 리소스를 구성합니다. (COO-482)
    • operatorframework.io/cluster-monitoring=true 주석을 OLM 번들에 추가합니다. (COO-483)
    • COO에 대한 경고 전략을 정의합니다. (COO-484)
    • 경고에 대해 PrometheusRule을 구성합니다. (COO-485)
  • 생성 시 지원 수준 주석이 UIPlugin CR에 추가되었습니다. 지원 수준은 DevPreview,TechPreview 또는 GeneralAvailability 의 값이 있는 플러그인 유형을 기반으로 합니다. (COO-318)
  • Prometheus CR에서 Alertmanager 스키마tlsConfig 필드를 구성할 수 있습니다. (COO-219)
  • 문제 해결 패널에 대한 확장된 기술 프리뷰는 Kubernetes 리소스와 추적을 비교하고 로그, 경고, 지표 및 네트워크 이벤트를 포함하여 다른 관찰 가능한 신호와 직접 관련된 지원을 추가합니다. (COO-450)

    • 웹 콘솔에서 모니터링 → 추적을 클릭하여 추적 페이지로 이동할 때 Tempo 인스턴스 및 테넌트를 선택할 수 있습니다. 프리뷰 문제 해결 패널은 openshift-tracing / platform instance 및 platform 테넌트에서만 작동합니다.
    • 문제 해결 패널은 관리자 관점에서 가장 잘 작동합니다. 일부 백엔드의 권한 부여 문제, 특히 메트릭 및 경고에 대한 Prometheus로 인해 개발자 관점에서 기능이 제한됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.

다음 표에서는 Cluster Observability Operator 및 OpenShift Container Platform 버전에 따라 사용 가능한 기능에 대한 정보를 제공합니다.

COO 버전OCP 버전분산 추적로깅문제 해결 패널

1.0+

4.12 - 4.15

1.0+

4.16+

1.1.2. CVE

1.1.3. 버그 수정

  • 이전에는 COO 설치의 기본 네임스페이스가 openshift-operators 였습니다. 이번 릴리스에서는 defaullt 네임스페이스가 openshift-cluster-observability-operator 로 변경됩니다. (COO-32)
  • 이전에는 korrel8r 에서 시계열 선택기 표현식만 구문 분석할 수 있었습니다. 이번 릴리스에서는 korrel8r 유효한 PromQL 표현식을 구문 분석하여 상관 관계에 사용하는 시계열 선택기를 추출할 수 있습니다. (COO-558)
  • 이전 버전에서는 Distributed Tracing UI 플러그인에서 Tempo 인스턴스를 볼 때 추적 기간을 보여주는 분산형 플롯 그래프가 올바르게 렌더링되지 않았습니다. 비틀란 크기가 너무 커서 x 및 y 축이 겹쳤습니다. 이번 릴리스에서는 그래프가 올바르게 렌더링됩니다. (COO-319)

1.2. 이전 기술 프리뷰 릴리스에서 사용 가능한 기능

다음 표에서는 이전 버전의 Cluster Observability Operator 및 OpenShift Container Platform에 따라 사용 가능한 기능에 대한 정보를 제공합니다.

COO 버전OCP 버전대시보드분산 추적로깅문제 해결 패널

0.2.0

4.11

0.3.0+, 0.4.0+

4.11 - 4.15

0.3.0+, 0.4.0+

4.16+

1.3. Cluster Observability Operator 0.4.1

Cluster Observability Operator 0.4.1에 대해 다음 권고를 사용할 수 있습니다.

1.3.1. 새로운 기능 및 개선 사항

  • Prometheus 및 Alertmanager에 대한 WebTLS를 구성할 수 있습니다.

1.3.2. CVE

1.3.3. 버그 수정

  • 이전에는 대시보드 UI 플러그인을 삭제할 때 consoles.operator.openshift.io 리소스에 console-dashboards-plugin 이 포함되어 있었습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-152)
  • 이전에는 웹 콘솔에 Red Hat COO의 올바른 아이콘이 표시되지 않았습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-353)
  • 이전에는 웹 콘솔에서 COO를 설치할 때 지원 섹션에 잘못된 링크가 포함되어 있었습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-354)
  • 이전에는 COO의 CSV(클러스터 서비스 버전)가 비공식 버전의 문서에 연결되어 있었습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-356)

1.4. Cluster Observability Operator 0.4.0

Cluster Observability Operator 0.4.0에서 다음 권고를 사용할 수 있습니다.

1.4.1. 새로운 기능 및 개선 사항

1.4.1.1. UI 플러그인 문제 해결
  • 이제 특정 시작 신호를 선택하고 집중할 수 있도록 문제 해결 UI 패널이 개선되었습니다.
  • 깊이를 선택하는 옵션과 함께 Korrel8r 쿼리를 더 잘 파악할 수 있습니다.
  • OpenShift Container Platform 버전 4.17 이상 사용자는 Application Launcher app launcher 에서 문제 해결 UI 패널에 액세스할 수 있습니다. 또는 4.16 이상 버전에서 모니터링경고를 클릭하여 웹 콘솔에서 액세스할 수 있습니다.

자세한 내용은 UI 플러그인 문제 해결을 참조하십시오.

1.4.1.2. 분산 추적 UI 플러그인
  • 분산 추적 UI 플러그인이 개선되었으며 Gantt 차트를 통해 추적을 탐색할 수 있습니다.

자세한 내용은 분산 추적 UI 플러그인 을 참조하십시오.

1.4.2. 버그 수정

  • 이전에는 모니터링로그를 클릭하여 웹 콘솔의 개발자 화면에서 액세스할 때 일반 사용자가 메트릭을 사용할 수 없었습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-288)
  • 이전에는 문제 해결 UI 플러그인에서 네트워크 관찰 기능에 잘못된 필터를 사용했습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-299)
  • 이전에는 문제 해결 UI 플러그인에서 Pod 레이블 검색에 잘못된 URL을 생성했습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-298)
  • 이전에는 Distributed tracing UI 플러그인에 권한 부여 취약점이 있었습니다. 이번 릴리스에서는 이 문제가 해결되었으며 Distributed tracing UI 플러그인이 다중 테넌트 TempoStackTempoMonolithic 인스턴스만 사용하여 강화되었습니다.

1.5. Cluster Observability Operator 0.3.2

Cluster Observability Operator 0.3.2에서 다음 권고를 사용할 수 있습니다.

1.5.1. 새로운 기능 및 개선 사항

  • 이번 릴리스에서는 MonitoringStack 구성 요소와 함께 허용 오차 및 노드 선택기를 사용할 수 있습니다.

1.5.2. 버그 수정

  • 이전에는 특정 버전의 OpenShift Container Platform에 설치할 때 로깅 UIPlugin이 Available 상태가 아니며 로깅 Pod가 생성되지 않았습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-260)

1.6. Cluster Observability Operator 0.3.0

Cluster Observability Operator 0.3.0에서 다음 권고를 사용할 수 있습니다.

1.6.1. 새로운 기능 및 개선 사항

  • 이번 릴리스에서는 Cluster Observability Operator가 향후 OpenShift Container Platform 관찰 기능 UI 플러그인 및 관찰 기능 구성 요소에 대한 백엔드 지원을 추가합니다.

1.7. Cluster Observability Operator 0.2.0

Cluster Observability Operator 0.2.0에서 다음 권고를 사용할 수 있습니다.

1.7.1. 새로운 기능 및 개선 사항

  • 이번 릴리스에서는 Cluster Observability Operator에서 OpenShift Container Platform 웹 콘솔 UI(사용자 인터페이스)의 관찰 기능 관련 플러그인 설치 및 관리를 지원합니다. (COO-58)

1.8. Cluster Observability Operator 0.1.3

Cluster Observability Operator 0.1.3에서 다음 권고를 사용할 수 있습니다.

1.8.1. 버그 수정

  • 이전 버전에서는 http://<prometheus_url>:9090/graph 에서 Prometheus 웹 사용자 인터페이스(UI)에 액세스하려고 하면 Error opening React index.html: open web/ui/static/react/index.html: no such file or directory. 이번 릴리스에서는 이 문제가 해결되어 Prometheus 웹 UI가 올바르게 표시됩니다. (COO-34)

1.9. Cluster Observability Operator 0.1.2

Cluster Observability Operator 0.1.2에서 다음 권고를 사용할 수 있습니다.

1.9.1. CVE

1.9.2. 버그 수정

  • 이전에는 특정 CSV(클러스터 서비스 버전) 주석이 COO의 메타데이터에 포함되지 않았습니다. 이러한 누락된 주석으로 인해 특정 COO 기능 및 기능이 패키지 매니페스트 또는 OperatorHub 사용자 인터페이스에 표시되지 않았습니다. 이번 릴리스에서는 누락된 주석이 추가되어 이 문제를 해결합니다. (COO-11)
  • 이전에는 COO의 자동 업데이트가 작동하지 않았으며 최신 버전의 Operator가 OperatorHub에서 최신 버전을 사용할 수 있더라도 이전 버전을 자동으로 대체하지 않았습니다. 이 릴리스에서는 이 문제가 해결되었습니다. (COO-12)
  • 이전에는 Thanos Querier가 127.0.0.1(localhost)의 포트 9090에서만 네트워크 트래픽을 수신 대기했습니다. 이로 인해 Thanos Querier 서비스에 도달하려고 하면 502 Bad Gateway 오류가 발생했습니다. 이번 릴리스에서는 구성 요소가 이제 기본 포트(10902)에서 수신 대기하도록 Thanos Querier 구성이 업데이트되어 문제를 해결합니다. 이러한 변경으로 인해 이제 서버 측 적용(SSA)을 통해 포트를 수정하고 필요한 경우 프록시 체인을 추가할 수도 있습니다. (COO-14)

1.10. Cluster Observability Operator 0.1.1

Cluster Observability Operator 0.1.1에 대해 다음 권고를 사용할 수 있습니다.

1.10.1. 새로운 기능 및 개선 사항

이번 릴리스에서는 제한된 네트워크 또는 연결이 끊긴 환경에서 Operator 설치를 지원하도록 Cluster Observability Operator를 업데이트합니다.

1.11. Cluster Observability Operator 0.1

이번 릴리스에서는 OperatorHub에서 Cluster Observability Operator의 기술 프리뷰 버전을 사용할 수 있습니다.

2장. Cluster Observability Operator 개요

COO(Cluster Observability Operator)는 고도의 사용자 지정 모니터링 스택을 생성하고 관리하기 위해 설계된 OpenShift Container Platform의 선택적 구성 요소입니다. 이를 통해 클러스터 관리자는 기본 OpenShift Container Platform 모니터링 시스템에 비해 각 네임스페이스에 대한 보다 맞춤화되고 자세한 보기를 제공하여 모니터링 요구 사항을 광범위하게 자동화할 수 있습니다.

COO는 다음 모니터링 구성 요소를 배포합니다.

  • Prometheus - 원격 쓰기를 사용하여 외부 엔드포인트에 지표를 보낼 수 있는 고가용성 Prometheus 인스턴스입니다.
  • Thanos Querier (선택 사항) - 중앙 위치에서 Prometheus 인스턴스 쿼리를 활성화합니다.
  • Alertmanager (선택 사항) - 다양한 서비스에 대한 경고 구성 기능을 제공합니다.
  • UI 플러그인 (선택 사항) - 모니터링, 로깅, 분산 추적 및 문제 해결을 위한 플러그인으로 관찰 기능 강화
  • Korrel8r (선택 사항) - 오픈 소스 Korrel8r 프로젝트에 의해 구동되는 관찰 가능성 신호 상관 관계를 제공합니다.

2.1. COO 기본 모니터링 스택 비교

COO 구성 요소는 기본 클러스터 내부 모니터링 스택과 독립적으로 작동합니다. 이 스택은 CCMO(Cluster Monitoring Operator)에서 배포 및 관리합니다. 두 Operator에서 배포한 스택 모니터링은 충돌하지 않습니다. CMO에서 배포한 기본 플랫폼 모니터링 구성 요소 외에도 COO 모니터링 스택을 사용할 수 있습니다.

COO와 기본 클러스터 내 모니터링 스택의 주요 차이점은 다음 표에 표시되어 있습니다.

기능COO기본 모니터링 스택

범위 및 통합

클러스터 및 워크로드 성능을 다루는 엔터프라이즈급 요구 사항에 대한 포괄적인 모니터링 및 분석을 제공합니다.

그러나 OpenShift Container Platform과 직접 통합되지 않으며 일반적으로 대시보드를 위해 외부 Grafana 인스턴스가 필요합니다.

클러스터 내의 핵심 구성 요소(예: API 서버 및 etcd, OpenShift별 네임스페이스)로 제한됩니다.

콘솔에 콘솔 대시보드 및 경고 관리를 포함하여 OpenShift Container Platform과 긴밀하게 통합됩니다.

구성 및 사용자 정의

데이터 보존 기간, 스토리지 방법 및 수집된 데이터 유형을 포함한 광범위한 구성 옵션.

COO는 SSA(Server-Side Apply)를 사용하여 사용자 지정 리소스에 있는 단일 구성 가능한 필드의 소유권을 사용자에게 위임할 수 있습니다.

제한된 사용자 지정 옵션이 포함된 기본 제공 구성입니다.

데이터 보존 및 스토리지

장기 데이터 보존, 기록 분석 및 용량 계획 지원

데이터 보존 시간이 단축되어 단기 모니터링 및 실시간 탐지에 중점을 둡니다.

2.2. COO 사용의 주요 이점

COO를 배포하면 기본 모니터링 스택을 사용하기 어려운 모니터링 요구 사항을 해결할 수 있습니다.

2.2.1. 확장성

  • COO 배포 모니터링 스택에 메트릭을 추가할 수 있습니다. 이는 지원을 손실하지 않고 핵심 플랫폼 모니터링에서는 불가능합니다.
  • 페더레이션을 통해 코어 플랫폼 모니터링에서 클러스터별 메트릭을 수신할 수 있습니다.
  • COO는 추세 예측 및 변칙 탐지와 같은 고급 모니터링 시나리오를 지원합니다.

2.2.2. 멀티 테넌시 지원

  • 사용자 네임스페이스당 모니터링 스택을 생성할 수 있습니다.
  • 네임스페이스당 여러 스택을 배포하거나 여러 네임스페이스에 대해 단일 스택을 배포할 수 있습니다.
  • COO를 사용하면 다른 팀에 대한 경고 및 수신자를 독립적으로 구성할 수 있습니다.

2.2.3. 확장성

  • 단일 클러스터에서 여러 모니터링 스택을 지원합니다.
  • 수동 샤딩을 통해 대규모 클러스터의 모니터링을 활성화합니다.
  • 메트릭이 단일 Prometheus 인스턴스의 기능을 초과하는 경우를 해결합니다.

2.2.4. 유연성

  • OpenShift Container Platform 릴리스 사이클과 분리되었습니다.
  • 릴리스 반복 속도가 빨라지고 변화하는 요구 사항에 신속하게 대응합니다.
  • 경고 규칙에 대한 독립적인 관리

2.3. COO 대상 사용자

COO는 특히 복잡한 멀티 테넌트 엔터프라이즈 환경에서 사용자 정의 기능, 확장성 및 장기 데이터 보존이 필요한 사용자에게 이상적입니다.

2.3.1. 엔터프라이즈급 사용자 및 관리자

엔터프라이즈 사용자에게는 고급 성능 분석, 장기 데이터 보존, 추세 예측 및 기록 분석을 포함하여 OpenShift Container Platform 클러스터에 대한 심층적인 모니터링 기능이 필요합니다. 이러한 기능을 통해 기업은 리소스 사용량을 더 잘 이해하고 성능 문제를 방지하며 리소스 할당을 최적화할 수 있습니다.

2.3.2. 멀티 테넌트 환경의 운영 팀

COO를 사용하면 멀티 테넌시 지원을 통해 다른 팀이 프로젝트 및 애플리케이션에 대한 모니터링 보기를 구성할 수 있으므로 유연한 모니터링 요구 사항이 있는 팀에 적합합니다.

2.3.3. 개발 및 운영 팀

COO는 개발 및 작업 중에 심층적인 문제 해결, 변칙 감지 및 성능 튜닝을 위해 세분화된 모니터링 및 사용자 지정 관찰 기능을 제공합니다.

2.4. Server-Side Apply를 사용하여 Prometheus 리소스 사용자 정의

server-Side Apply는 Kubernetes 리소스를 공동으로 관리할 수 있는 기능입니다. 컨트롤 플레인은 다양한 사용자와 컨트롤러가 Kubernetes 오브젝트 내에서 필드를 관리하는 방법을 추적합니다. 필드 관리자의 개념을 소개하고 필드의 소유권을 추적합니다. 이 중앙 집중식 제어는 충돌 감지 및 해결을 제공하며 의도하지 않은 덮어쓰기의 위험을 줄입니다.

Client-Side Apply와 비교하면 더 선언적이며 마지막으로 적용된 상태가 아니라 필드 관리를 추적합니다.

server-Side 적용
삭제하고 다시 생성할 필요 없이 리소스의 상태를 업데이트하여 선언적 구성 관리.
필드 관리
사용자는 다른 필드에 영향을 주지 않고 업데이트할 리소스의 필드를 지정할 수 있습니다.
관리형 필드
Kubernetes는 메타데이터 내의 managedFields 필드에 있는 각 오브젝트 필드를 관리하는 사용자에 대한 메타데이터를 저장합니다.
충돌
여러 관리자가 동일한 필드를 수정하려고 하면 충돌이 발생합니다. applier는 관리를 덮어쓰거나, 리클립싱(relinquish)하거나, 관리하도록 선택할 수 있습니다.
병합 전략
server-Side Apply는 작업자를 관리하는 작업자에 따라 병합 필드를 적용합니다.

프로세스

  1. 다음 구성을 사용하여 MonitoringStack 리소스를 추가합니다.

    MonitoringStack 오브젝트의 예

    apiVersion: monitoring.rhobs/v1alpha1
    kind: MonitoringStack
    metadata:
      labels:
        coo: example
      name: sample-monitoring-stack
      namespace: coo-demo
    spec:
      logLevel: debug
      retention: 1d
      resourceSelector:
        matchLabels:
          app: demo

  2. sample-monitoring-stack 이라는 Prometheus 리소스는 coo-demo 네임스페이스에 생성됩니다. 다음 명령을 실행하여 생성된 Prometheus 리소스의 관리형 필드를 검색합니다.

    $ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields

    출력 예

    managedFields:
    - apiVersion: monitoring.rhobs/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:labels:
            f:app.kubernetes.io/managed-by: {}
            f:app.kubernetes.io/name: {}
            f:app.kubernetes.io/part-of: {}
          f:ownerReferences:
            k:{"uid":"81da0d9a-61aa-4df3-affc-71015bcbde5a"}: {}
        f:spec:
          f:additionalScrapeConfigs: {}
          f:affinity:
            f:podAntiAffinity:
              f:requiredDuringSchedulingIgnoredDuringExecution: {}
          f:alerting:
            f:alertmanagers: {}
          f:arbitraryFSAccessThroughSMs: {}
          f:logLevel: {}
          f:podMetadata:
            f:labels:
              f:app.kubernetes.io/component: {}
              f:app.kubernetes.io/part-of: {}
          f:podMonitorSelector: {}
          f:replicas: {}
          f:resources:
            f:limits:
              f:cpu: {}
              f:memory: {}
            f:requests:
              f:cpu: {}
              f:memory: {}
          f:retention: {}
          f:ruleSelector: {}
          f:rules:
            f:alert: {}
          f:securityContext:
            f:fsGroup: {}
            f:runAsNonRoot: {}
            f:runAsUser: {}
          f:serviceAccountName: {}
          f:serviceMonitorSelector: {}
          f:thanos:
            f:baseImage: {}
            f:resources: {}
            f:version: {}
          f:tsdb: {}
      manager: observability-operator
      operation: Apply
    - apiVersion: monitoring.rhobs/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          .: {}
          f:availableReplicas: {}
          f:conditions:
            .: {}
            k:{"type":"Available"}:
              .: {}
              f:lastTransitionTime: {}
              f:observedGeneration: {}
              f:status: {}
              f:type: {}
            k:{"type":"Reconciled"}:
              .: {}
              f:lastTransitionTime: {}
              f:observedGeneration: {}
              f:status: {}
              f:type: {}
          f:paused: {}
          f:replicas: {}
          f:shardStatuses:
            .: {}
            k:{"shardID":"0"}:
              .: {}
              f:availableReplicas: {}
              f:replicas: {}
              f:shardID: {}
              f:unavailableReplicas: {}
              f:updatedReplicas: {}
          f:unavailableReplicas: {}
          f:updatedReplicas: {}
      manager: PrometheusOperator
      operation: Update
      subresource: status

  3. metadata.managedFields 값을 확인하고, 메타데이터사양 의 일부 필드가 MonitoringStack 리소스에서 관리되는지 확인합니다.
  4. MonitoringStack 리소스에서 제어하지 않는 필드를 수정합니다.

    1. MonitoringStack 리소스에서 설정하지 않은 필드인 spec.enforcedSampleLimit 를 변경합니다. prom-spec-edited.yaml 파일을 생성합니다.

      prom-spec-edited.yaml

      apiVersion: monitoring.rhobs/v1
      kind: Prometheus
      metadata:
        name: sample-monitoring-stack
        namespace: coo-demo
      spec:
        enforcedSampleLimit: 1000

    2. 다음 명령을 실행하여 YAML을 적용합니다.

      $ oc apply -f ./prom-spec-edited.yaml --server-side
      참고

      --server-side 플래그를 사용해야 합니다.

    3. 변경된 Prometheus 오브젝트를 가져오고 managedFieldsspec.enforcedSampleLimit 이 있는 섹션이 하나 더 있음을 확인합니다.

      $ oc get prometheus -n coo-demo

      출력 예

      managedFields: 1
      - apiVersion: monitoring.rhobs/v1
        fieldsType: FieldsV1
        fieldsV1:
          f:metadata:
            f:labels:
              f:app.kubernetes.io/managed-by: {}
              f:app.kubernetes.io/name: {}
              f:app.kubernetes.io/part-of: {}
          f:spec:
            f:enforcedSampleLimit: {} 2
        manager: kubectl
        operation: Apply

      1
      managedFields
      2
      spec.enforcedSampleLimit
  5. MonitoringStack 리소스에서 관리하는 필드를 수정합니다.

    1. 다음 YAML 구성을 사용하여 MonitoringStack 리소스에서 관리하는 필드인 spec.LogLevel 을 변경합니다.

      # changing the logLevel from debug to info
      apiVersion: monitoring.rhobs/v1
      kind: Prometheus
      metadata:
        name: sample-monitoring-stack
        namespace: coo-demo
      spec:
        logLevel: info 1
      1
      spec.logLevel 추가
    2. 다음 명령을 실행하여 YAML을 적용합니다.

      $ oc apply -f ./prom-spec-edited.yaml --server-side

      출력 예

      error: Apply failed with 1 conflict: conflict with "observability-operator": .spec.logLevel
      Please review the fields above--they currently have other managers. Here
      are the ways you can resolve this warning:
      * If you intend to manage all of these fields, please re-run the apply
        command with the `--force-conflicts` flag.
      * If you do not intend to manage all of the fields, please edit your
        manifest to remove references to the fields that should keep their
        current managers.
      * You may co-own fields by updating your manifest to match the existing
        value; in this case, you'll become the manager if the other manager(s)
        stop managing the field (remove it from their configuration).
      See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts

    3. spec.logLevel 필드는 observability-operator 에서 이미 관리하므로 Server-Side Apply를 사용하여 변경할 수 없습니다.
    4. --force-conflicts 플래그를 사용하여 변경 사항을 강제 적용합니다.

      $ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts

      출력 예

      prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied

      --force-conflicts 플래그를 사용하면 필드를 강제로 변경할 수 있지만 동일한 필드가 MonitoringStack 리소스에서도 관리되므로 Observability Operator는 변경 사항을 감지하고 MonitoringStack 리소스에서 설정한 값으로 되돌립니다.

      참고

      MonitoringStack 리소스에서 생성한 일부 Prometheus 필드는 MonitoringStack 사양 스탠자의 필드(예: logLevel )의 영향을 받습니다. 이는 MonitoringStack 사양 을 변경하여 변경할 수 있습니다.

    5. Prometheus 오브젝트에서 logLevel 을 변경하려면 다음 YAML을 적용하여 MonitoringStack 리소스를 변경합니다.

      apiVersion: monitoring.rhobs/v1alpha1
      kind: MonitoringStack
      metadata:
        name: sample-monitoring-stack
        labels:
          coo: example
      spec:
        logLevel: info
    6. 변경 사항이 수행되었는지 확인하려면 다음 명령을 실행하여 로그 수준을 쿼리합니다.

      $ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'

      출력 예

      info

참고
  1. 새 버전의 Operator가 이전에 액터에 의해 생성 및 제어되는 필드를 생성하면 액터에 의해 설정된 값이 재정의됩니다.

    예를 들어 MonitoringStack 리소스에서 생성하지 않는 enforcedSampleLimit 필드를 관리하고 있습니다. Observability Operator가 업그레이드되고 새 버전의 Operator가 enforcedSampleLimit 에 대한 값을 생성하는 경우 이전에 설정한 값을 덮어씁니다.

  2. MonitoringStack 리소스에서 생성한 Prometheus 오브젝트에는 모니터링 스택에서 명시적으로 설정하지 않은 일부 필드가 포함될 수 있습니다. 이러한 필드는 기본값이 있기 때문에 나타납니다.

3장. Cluster Observability Operator 설치

클러스터 관리자는 OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Cluster Observability Operator (COO)를 설치하거나 제거할 수 있습니다. OperatorHub는 클러스터에 Operator를 설치하고 관리하는 OLM(Operator Lifecycle Manager)과 함께 작동하는 사용자 인터페이스입니다.

3.1. 웹 콘솔에서 Cluster Observability Operator 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Cluster Observability Operator (COO)를 설치합니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 상자에 cluster observability Operator 를 입력합니다.
  3. 결과 목록에서 Cluster Observability Operator 를 클릭합니다.
  4. Operator에 대한 정보를 읽고 다음 설치 설정을 구성합니다.

    • 업데이트 채널stable
    • 버전1.0.0 이상
    • 설치 모드클러스터의 모든 네임스페이스(기본값)
    • 설치된 네임스페이스Operator 권장 네임스페이스: openshift-cluster-observability-operator
    • 이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화를선택합니다.
    • 업데이트 승인자동
  5. 선택 사항: 요구 사항에 맞게 설치 설정을 변경할 수 있습니다. 예를 들어 다른 업데이트 채널에 가입하거나, 이전 릴리스 버전의 Operator를 설치하거나, 새 버전의 Operator에 대한 업데이트에 대한 수동 승인이 필요한 경우 선택할 수 있습니다.
  6. 설치를 클릭합니다.

검증

  • Operator설치된 Operator 로 이동하여 Cluster Observability Operator 항목이 목록에 표시되는지 확인합니다.

3.2. 웹 콘솔을 사용하여 Cluster Observability Operator 설치 제거

OperatorHub를 사용하여 COO(Cluster Observability Operator)를 설치한 경우 OpenShift Container Platform 웹 콘솔에서 해당 Operator를 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.

프로세스

  1. Operator설치된 Operator 로 이동합니다.
  2. 목록에서 Cluster Observability Operator 항목을 찾습니다.
  3. 이 항목에 대해 kebab 를 클릭하고 Operator 설치 제거를 선택합니다.

검증

  • Operator설치된 Operator 로 이동하여 Cluster Observability Operator 항목이 더 이상 목록에 표시되지 않는지 확인합니다.

4장. 서비스를 모니터링하도록 Cluster Observability Operator 구성

COO(Cluster Observability Operator)에서 관리하는 모니터링 스택을 구성하여 서비스에 대한 메트릭을 모니터링할 수 있습니다.

서비스 모니터링을 테스트하려면 다음 단계를 따르십시오.

  • 서비스 엔드포인트를 정의하는 샘플 서비스를 배포합니다.
  • COO에서 서비스를 모니터링할 방법을 지정하는 ServiceMonitor 오브젝트를 생성합니다.
  • MonitoringStack 오브젝트를 생성하여 ServiceMonitor 오브젝트를 검색합니다.

4.1. Cluster Observability Operator의 샘플 서비스 배포

이 구성은 사용자 정의 ns1-coo 프로젝트에 prometheus-coo-example-app 이라는 샘플 서비스를 배포합니다. 서비스는 사용자 정의 버전 지표를 노출합니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 또는 네임스페이스에 대한 관리 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

  1. 네임스페이스, 배포 및 서비스에 대한 다음 구성 세부 정보가 포함된 prometheus-coo-example-app.yaml 이라는 YAML 파일을 생성합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns1-coo
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prometheus-coo-example-app
      name: prometheus-coo-example-app
      namespace: ns1-coo
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: prometheus-coo-example-app
      template:
        metadata:
          labels:
            app: prometheus-coo-example-app
        spec:
          containers:
          - image: ghcr.io/rhobs/prometheus-example-app:0.4.2
            imagePullPolicy: IfNotPresent
            name: prometheus-coo-example-app
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: prometheus-coo-example-app
      name: prometheus-coo-example-app
      namespace: ns1-coo
    spec:
      ports:
      - port: 8080
        protocol: TCP
        targetPort: 8080
        name: web
      selector:
        app: prometheus-coo-example-app
      type: ClusterIP
  2. 파일을 저장합니다.
  3. 다음 명령을 실행하여 클러스터에 구성을 적용합니다.

    $ oc apply -f prometheus-coo-example-app.yaml
  4. 다음 명령을 실행하고 출력을 관찰하여 포드가 실행 중인지 확인합니다.

    $ oc -n ns1-coo get pod

    출력 예

    NAME                                      READY     STATUS    RESTARTS   AGE
    prometheus-coo-example-app-0927545cb7-anskj   1/1       Running   0          81m

4.2. Cluster Observability Operator에서 서비스를 모니터링하는 방법 지정

"Cluster Observability Operator의 샘플 서비스 배포" 섹션에서 생성한 샘플 서비스에서 노출하는 메트릭을 사용하려면 /metrics 끝점에서 메트릭을 스크랩하도록 모니터링 구성 요소를 구성해야 합니다.

서비스 모니터링 방법을 지정하는 ServiceMonitor 오브젝트 또는 Pod를 모니터링할 방법을 지정하는 PodMonitor 오브젝트를 사용하여 이 구성을 생성할 수 있습니다. ServiceMonitor 오브젝트에는 Service 오브젝트가 필요합니다. PodMonitor 오브젝트는 MonitoringStack 오브젝트가 Pod에서 노출하는 메트릭 끝점에서 직접 메트릭을 스크랩할 수 있도록 하지 않습니다.

다음 절차에서는 ns1-coo 네임스페이스에서 prometheus-coo-example-app 이라는 샘플 서비스에 대한 ServiceMonitor 오브젝트를 생성하는 방법을 보여줍니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 또는 네임스페이스에 대한 관리 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • prometheus-coo-example-app 샘플 서비스를 ns1-coo 네임스페이스에 배포했습니다.

    참고

    prometheus-coo-example-app 샘플 서비스는 TLS 인증을 지원하지 않습니다.

프로세스

  1. 다음 ServiceMonitor 오브젝트 구성 세부 정보가 포함된 example-coo-app-service-monitor.yaml 이라는 YAML 파일을 생성합니다.

    apiVersion: monitoring.rhobs/v1
    kind: ServiceMonitor
    metadata:
      labels:
        k8s-app: prometheus-coo-example-monitor
      name: prometheus-coo-example-monitor
      namespace: ns1-coo
    spec:
      endpoints:
      - interval: 30s
        port: web
        scheme: http
      selector:
        matchLabels:
          app: prometheus-coo-example-app

    이 구성은 MonitoringStack 오브젝트가 prometheus-coo-example-app 샘플 서비스에서 노출하는 메트릭 데이터를 스크랩하기 위해 참조하는 ServiceMonitor 오브젝트를 정의합니다.

  2. 다음 명령을 실행하여 클러스터에 구성을 적용합니다.

    $ oc apply -f example-coo-app-service-monitor.yaml
  3. 다음 명령을 실행하고 출력을 관찰하여 ServiceMonitor 리소스가 생성되었는지 확인합니다.

    $ oc -n ns1-coo get servicemonitors.monitoring.rhobs

    출력 예

    NAME                         AGE
    prometheus-coo-example-monitor   81m

4.3. Cluster Observability Operator에 대한 MonitoringStack 오브젝트 생성

대상 prometheus-coo-example-app 서비스에서 노출하는 메트릭 데이터를 스크랩하려면 "Cluster Observability Operator에 대해 서비스 모니터링 방법 연결" 섹션에서 생성한 ServiceMonitor 오브젝트를 참조하는 MonitoringStack 오브젝트를 생성합니다. 그러면 이 MonitoringStack 오브젝트에서 서비스를 검색하고 노출된 지표 데이터를 스크랩할 수 있습니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 또는 네임스페이스에 대한 관리 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • prometheus-coo-example-app 샘플 서비스를 ns1-coo 네임스페이스에 배포했습니다.
  • ns1-coo 네임스페이스에 prometheus-coo-example-monitor 라는 ServiceMonitor 오브젝트를 생성했습니다.

프로세스

  1. MonitoringStack 오브젝트 구성에 대한 YAML 파일을 생성합니다. 이 예제에서는 example-coo-monitoring-stack.yaml 파일의 이름을 지정합니다.
  2. 다음 MonitoringStack 오브젝트 구성 세부 정보를 추가합니다.

    MonitoringStack 오브젝트의 예

    apiVersion: monitoring.rhobs/v1alpha1
    kind: MonitoringStack
    metadata:
      name: example-coo-monitoring-stack
      namespace: ns1-coo
    spec:
      logLevel: debug
      retention: 1d
      resourceSelector:
        matchLabels:
          k8s-app: prometheus-coo-example-monitor

  3. 다음 명령을 실행하여 MonitoringStack 오브젝트를 적용합니다.

    $ oc apply -f example-coo-monitoring-stack.yaml
  4. 다음 명령을 실행하고 출력을 검사하여 MonitoringStack 오브젝트를 사용할 수 있는지 확인합니다.

    $ oc -n ns1-coo get monitoringstack

    출력 예

    NAME                         AGE
    example-coo-monitoring-stack   81m

  5. 다음 명령을 실행하여 Prometheus의 활성 대상에 대한 정보를 검색하고, app=prometheus-coo-example-app 로 레이블이 지정된 대상만 나열하도록 출력을 필터링합니다. 이렇게 하면 이 특정 레이블을 사용하여 Prometheus에서 검색 및 적극적으로 모니터링하는 대상이 검증됩니다.

    $ oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/targets' | jq '.data.activeTargets[].discoveredLabels | select(.__meta_kubernetes_endpoints_label_app=="prometheus-coo-example-app")'

    출력 예

    {
      "__address__": "10.129.2.25:8080",
      "__meta_kubernetes_endpoint_address_target_kind": "Pod",
      "__meta_kubernetes_endpoint_address_target_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
      "__meta_kubernetes_endpoint_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz",
      "__meta_kubernetes_endpoint_port_name": "web",
      "__meta_kubernetes_endpoint_port_protocol": "TCP",
      "__meta_kubernetes_endpoint_ready": "true",
      "__meta_kubernetes_endpoints_annotation_endpoints_kubernetes_io_last_change_trigger_time": "2024-11-05T11:24:09Z",
      "__meta_kubernetes_endpoints_annotationpresent_endpoints_kubernetes_io_last_change_trigger_time": "true",
      "__meta_kubernetes_endpoints_label_app": "prometheus-coo-example-app",
      "__meta_kubernetes_endpoints_labelpresent_app": "true",
      "__meta_kubernetes_endpoints_name": "prometheus-coo-example-app",
      "__meta_kubernetes_namespace": "ns1-coo",
      "__meta_kubernetes_pod_annotation_k8s_ovn_org_pod_networks": "{\"default\":{\"ip_addresses\":[\"10.129.2.25/23\"],\"mac_address\":\"0a:58:0a:81:02:19\",\"gateway_ips\":[\"10.129.2.1\"],\"routes\":[{\"dest\":\"10.128.0.0/14\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"172.30.0.0/16\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"100.64.0.0/16\",\"nextHop\":\"10.129.2.1\"}],\"ip_address\":\"10.129.2.25/23\",\"gateway_ip\":\"10.129.2.1\",\"role\":\"primary\"}}",
      "__meta_kubernetes_pod_annotation_k8s_v1_cni_cncf_io_network_status": "[{\n    \"name\": \"ovn-kubernetes\",\n    \"interface\": \"eth0\",\n    \"ips\": [\n        \"10.129.2.25\"\n    ],\n    \"mac\": \"0a:58:0a:81:02:19\",\n    \"default\": true,\n    \"dns\": {}\n}]",
      "__meta_kubernetes_pod_annotation_openshift_io_scc": "restricted-v2",
      "__meta_kubernetes_pod_annotation_seccomp_security_alpha_kubernetes_io_pod": "runtime/default",
      "__meta_kubernetes_pod_annotationpresent_k8s_ovn_org_pod_networks": "true",
      "__meta_kubernetes_pod_annotationpresent_k8s_v1_cni_cncf_io_network_status": "true",
      "__meta_kubernetes_pod_annotationpresent_openshift_io_scc": "true",
      "__meta_kubernetes_pod_annotationpresent_seccomp_security_alpha_kubernetes_io_pod": "true",
      "__meta_kubernetes_pod_controller_kind": "ReplicaSet",
      "__meta_kubernetes_pod_controller_name": "prometheus-coo-example-app-5d8cd498c7",
      "__meta_kubernetes_pod_host_ip": "10.0.128.2",
      "__meta_kubernetes_pod_ip": "10.129.2.25",
      "__meta_kubernetes_pod_label_app": "prometheus-coo-example-app",
      "__meta_kubernetes_pod_label_pod_template_hash": "5d8cd498c7",
      "__meta_kubernetes_pod_labelpresent_app": "true",
      "__meta_kubernetes_pod_labelpresent_pod_template_hash": "true",
      "__meta_kubernetes_pod_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
      "__meta_kubernetes_pod_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz",
      "__meta_kubernetes_pod_phase": "Running",
      "__meta_kubernetes_pod_ready": "true",
      "__meta_kubernetes_pod_uid": "054c11b6-9a76-4827-a860-47f3a4596871",
      "__meta_kubernetes_service_label_app": "prometheus-coo-example-app",
      "__meta_kubernetes_service_labelpresent_app": "true",
      "__meta_kubernetes_service_name": "prometheus-coo-example-app",
      "__metrics_path__": "/metrics",
      "__scheme__": "http",
      "__scrape_interval__": "30s",
      "__scrape_timeout__": "10s",
      "job": "serviceMonitor/ns1-coo/prometheus-coo-example-monitor/0"
    }

    참고

    위의 예제에서는 jq 명령줄 JSON 프로세서를 사용하여 편의를 위해 출력을 포맷합니다.

4.4. 모니터링 스택 검증

모니터링 스택이 올바르게 작동하는지 확인하려면 예제 서비스에 액세스한 다음 수집된 지표를 확인합니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 또는 네임스페이스에 대한 관리 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • prometheus-coo-example-app 샘플 서비스를 ns1-coo 네임스페이스에 배포했습니다.
  • ns1-coo 네임스페이스에 prometheus-coo-example-monitor 라는 ServiceMonitor 오브젝트를 생성했습니다.
  • ns1-coo 네임스페이스에 example-coo-monitoring-stack 이라는 MonitoringStack 오브젝트를 생성했습니다.

프로세스

  1. example prometheus-coo-example-app 서비스를 노출할 경로를 생성합니다. 터미널에서 다음 명령을 실행합니다.

    $ oc expose svc prometheus-coo-example-app
  2. 브라우저 또는 명령줄에서 경로에 액세스하여 메트릭을 생성합니다.
  3. Prometheus Pod에서 쿼리를 실행하여 총 HTTP 요청 지표를 반환합니다.

    $ oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/query?query=http_requests_total'

    출력 예(상 편의를 위해 jq 를 사용하여 포맷됨)

    {
      "status": "success",
      "data": {
        "resultType": "vector",
        "result": [
          {
            "metric": {
              "__name__": "http_requests_total",
              "code": "200",
              "endpoint": "web",
              "instance": "10.129.2.25:8080",
              "job": "prometheus-coo-example-app",
              "method": "get",
              "namespace": "ns1-coo",
              "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
              "service": "prometheus-coo-example-app"
            },
            "value": [
              1730807483.632,
              "3"
            ]
          },
          {
            "metric": {
              "__name__": "http_requests_total",
              "code": "404",
              "endpoint": "web",
              "instance": "10.129.2.25:8080",
              "job": "prometheus-coo-example-app",
              "method": "get",
              "namespace": "ns1-coo",
              "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj",
              "service": "prometheus-coo-example-app"
            },
            "value": [
              1730807483.632,
              "0"
            ]
          }
        ]
      }
    }

5장. 관찰 기능 UI 플러그인

5.1. 관찰 기능 UI 플러그인 개요

COO(Cluster Observability Operator)를 사용하여 UI 플러그인을 설치 및 관리하여 OpenShift Container Platform 웹 콘솔의 관찰 기능을 개선할 수 있습니다. 플러그인은 기본 기능을 확장하여 문제 해결, 분산 추적 및 클러스터 로깅을 위한 새로운 UI 기능을 제공합니다.

5.1.1. 클러스터 로깅

로깅 UI 플러그인은 모니터링로그 페이지의 웹 콘솔에 로깅 데이터를 표시합니다. 필터, 쿼리, 시간 범위 및 새로 고침 속도를 지정할 수 있습니다. 결과에 접힌 로그 목록이 표시되어 각 로그에 대한 자세한 정보를 표시하도록 확장할 수 있습니다.

자세한 내용은 로깅 UI 플러그인 페이지를 참조하십시오.

5.1.2. 문제 해결

중요

Cluster Observability Operator 문제 해결 패널 UI 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift Container Platform 버전 4.16+의 문제 해결 패널 UI 플러그인은 오픈 소스 Korrel8r 프로젝트에서 제공하는 관찰 가능성 신호 상관 관계를 제공합니다. ObserveAlerting 페이지에서 제공되는 문제 해결 패널을 사용하여 다양한 데이터 저장소에서 메트릭, 로그, 경고, netflows 및 추가 관찰 가능성 신호 및 리소스를 쉽게 연결할 수 있습니다. OpenShift Container Platform 버전 4.17 이상 사용자는 Application Launcher app launcher 에서 문제 해결 UI 패널에도 액세스할 수 있습니다.

Korrel8r의 출력이 대화형 노드 그래프로 표시됩니다. 노드를 클릭하면 해당 노드의 특정 정보(예: 메트릭, 로그 또는 Pod)를 사용하여 해당 웹 콘솔 페이지로 자동으로 리디렉션됩니다.

자세한 내용은 UI 플러그인 문제 해결 페이지를 참조하십시오.

5.1.3. 분산 추적

중요

Cluster Observability Operator distributed tracing UI 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

분산 추적 UI 플러그인은 모니터링 → 추적 페이지의 웹 콘솔에 추적 관련 기능을 추가합니다. 프런트 엔드 및 마이크로 서비스 백엔드로 요청을 수행하여 분산 시스템의 코드 오류 및 성능 병목 현상을 식별할 수 있습니다. 클러스터에서 실행 중인 지원되는 TempoStack 또는 TempoMonolithic 다중 테넌트 인스턴스를 선택하고 시간 범위 및 쿼리를 설정하여 추적 데이터를 볼 수 있습니다.

자세한 내용은 분산 추적 UI 플러그인 페이지를 참조하십시오.

5.2. 로깅 UI 플러그인

로깅 UI 플러그인은 모니터링로그 페이지의 OpenShift Container Platform 웹 콘솔에 로깅 데이터를 표시합니다. 축소된 로그 목록으로 결과가 표시되므로 필터, 쿼리, 시간 범위 및 새로 고침 속도를 지정할 수 있으며 각 로그에 대한 자세한 정보를 표시하도록 확장할 수 있습니다.

OpenShift Container Platform 버전 4.16 이상에 Troubleshooting UI 플러그인을 배포한 경우 Korrel8r 서비스에 연결하고 ObserveLogs 페이지에서 ObserveMetrics 페이지에 있는 직접 링크를 PromQL 쿼리와 함께 추가합니다. 또한 ObserveAlerting 의 관리 관점 경고 세부 정보 페이지의 관련 로그 보기 링크를 선택한 ObserveLogs 페이지에 추가합니다.

플러그인의 기능은 다음과 같이 분류됩니다.

dev-console
개발자 화면에 로깅 보기를 추가합니다.
경고
Loki 규칙자에 정의된 로그 기반 경고와 웹 콘솔 경고를 병합합니다. 경고 세부 정보 뷰에 로그 기반 메트릭 차트를 추가합니다.
dev-alerts
Loki 규칙자에 정의된 로그 기반 경고와 웹 콘솔 경고를 병합합니다. 개발자 화면에 대한 경고 세부 정보 뷰에 로그 기반 지표 차트를 추가합니다.

COO(Cluster Observability Operator) 버전의 경우 OpenShift Container Platform 버전에서 이러한 기능에 대한 지원이 다음 표에 표시되어 있습니다.

COO 버전OCP 버전기능

0.3.0+

4.12

dev-console

0.3.0+

4.13

dev-console, alerts

0.3.0+

4.14+

dev-console, alerts, dev-alerts

5.2.1. Cluster Observability Operator 로깅 UI 플러그인 설치

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • 클러스터에 LokiStack 인스턴스가 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
  2. 탭 목록의 맨 오른쪽에 있는 UI 플러그인 탭을 선택하고 Create UIPlugin 을 클릭합니다.
  3. YAML 보기를 선택하고 다음 콘텐츠를 입력한 다음 Create:을 클릭합니다.

    apiVersion: observability.openshift.io/v1alpha1
    kind: UIPlugin
    metadata:
      name: logging
    spec:
      type: Logging
      logging:
        lokiStack:
          name: logging-loki
        logsLimit: 50
        timeout: 30s

5.3. 분산 추적 UI 플러그인

중요

Cluster Observability Operator distributed tracing UI 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

분산 추적 UI 플러그인은 ObserveTraces 의 OpenShift 웹 콘솔의 관리자 화면에 추적 관련 기능을 추가합니다. 프런트 엔드 및 마이크로 서비스 백엔드로 요청을 수행하여 분산 시스템의 코드 오류 및 성능 병목 현상을 식별할 수 있습니다.

5.3.1. Cluster Observability Operator distributed tracing UI 플러그인 설치

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • Cluster Observability Operator가 설치되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
  2. UI 플러그인 탭(tab 목록의 맨 오른쪽에 있음)을 선택하고 Create UIPlugin을 누릅니다.
  3. YAML 보기를 선택하고 다음 콘텐츠를 입력한 다음 Create:을 누릅니다.

    apiVersion: observability.openshift.io/v1alpha1
    kind: UIPlugin
    metadata:
      name: distributed-tracing
    spec:
      type: DistributedTracing

5.3.2. Cluster Observability Operator distributed tracing UI 플러그인 사용

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • Cluster Observability Operator distributed tracing UI 플러그인을 설치했습니다.
  • 클러스터에 TempoStack 또는 TempoMonolithic 다중 테넌트 인스턴스가 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 모니터링추적을 클릭합니다.
  2. TempoStack 또는 TempoMonolithic 다중 테넌트 인스턴스를 선택하고 추적을 로드할 시간 범위 및 쿼리를 설정합니다.

    추적은 추적 시작 시간, 기간 및 기간 수를 보여주는 묶인 플로트에 표시됩니다. 분산형 플롯 아래에는 추적 이름, 범위 수 및 기간 과 같은 정보를 보여주는 추적 목록이 있습니다.

  3. 추적 이름 링크를 클릭합니다.

    선택한 추적에 대한 추적 세부 정보 페이지에는 추적 내의 모든 범위의 Gantt Chart가 포함되어 있습니다. 구성된 특성의 분석을 표시하려면 범위를 선택합니다.

5.4. UI 플러그인 문제 해결

중요

Cluster Observability Operator 문제 해결 패널 UI 플러그인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift Container Platform 버전 4.16+의 문제 해결 UI 플러그인은 오픈 소스 Korrel8r 프로젝트에서 제공하는 관찰 가능성 신호 상관 관계를 제공합니다. 모니터링경고 에서 사용할 수 있는 문제 해결 패널을 사용하면 다양한 데이터 저장소에서 메트릭, 로그, 경고, netflows 및 추가 관찰 가능성 신호 및 리소스를 쉽게 연결할 수 있습니다. OpenShift Container Platform 버전 4.17 이상 사용자는 Application Launcher app launcher 에서 문제 해결 UI 패널에도 액세스할 수 있습니다.

문제 해결 UI 플러그인을 설치하면 korrel8r 라는 Korrel8r 서비스가 동일한 네임스페이스에 배포되며 상관 엔진에서 관련 관찰 가능성 신호 및 Kubernetes 리소스를 찾을 수 있습니다.

Korrel8r의 출력은 OpenShift Container Platform 웹 콘솔의 대화형 노드 그래프 형태로 표시됩니다. 그래프의 노드는 리소스 또는 신호 유형을 나타내며 에지는 관계를 나타냅니다. 노드를 클릭하면 해당 노드에 대한 특정 정보(예: 메트릭, 로그, Pod)를 사용하여 해당 웹 콘솔 페이지로 자동으로 리디렉션됩니다.

5.4.1. Cluster Observability Operator 문제 해결 UI 플러그인 설치

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • Cluster Observability Operator가 설치되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
  2. UI 플러그인 탭(tab 목록의 맨 오른쪽에 있음)을 선택하고 Create UIPlugin을 누릅니다.
  3. YAML 보기를 선택하고 다음 콘텐츠를 입력한 다음 Create:을 누릅니다.

    apiVersion: observability.openshift.io/v1alpha1
    kind: UIPlugin
    metadata:
      name: troubleshooting-panel
    spec:
      type: TroubleshootingPanel

5.4.2. Cluster Observability Operator 문제 해결 UI 플러그인 사용

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. 클러스터 버전이 4.17 이상인 경우 Application Launcher app launcher 에서 문제 해결 UI 패널에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • 상관된 로그를 시각화하려면 OpenShift Container Platform Logging을 설치했습니다.
  • 상관 관계가 있는 netflow를 시각화하려는 경우 OpenShift Container Platform Network Observability를 설치했습니다.
  • Cluster Observability Operator가 설치되어 있습니다.
  • Cluster Observability Operator 문제 해결 UI 플러그인을 설치했습니다.

    참고

    문제 해결 패널은 클러스터에 설치된 관찰 가능성 신호 저장소를 사용합니다. Kuberenetes 리소스, 경고 및 메트릭은 OpenShift Container Platform 클러스터에서 항상 사용할 수 있습니다. 기타 신호 유형을 사용하려면 선택적 구성 요소를 설치해야 합니다.

    • 로그: Red Hat (store)에서 제공하는 Red Hat Openshift Logging (collection) 및 Loki Operator
    • 네트워크 이벤트: Red Hat (store)에서 제공하는 Red Hat (collection) 및 Loki Operator에서 제공하는 네트워크 관찰 기능

    프로세스

    1. 웹 콘솔의 관리자 화면에서 모니터링경고로 이동한 다음 경고를 선택합니다. 경고에 관련 항목이 있는 경우 경고 세부 정보 페이지의 차트 위에 문제 해결 패널 링크가 표시됩니다.

      문제 해결 패널 링크

      패널 문제 해결 링크를 클릭하여 패널을 표시합니다.

    2. 패널은 쿼리 세부 정보와 쿼리 결과의 토폴로지 그래프로 구성됩니다. 선택한 경고는 Korrel8r 쿼리 문자열로 변환되고 korrel8r 서비스로 전송됩니다. 결과는 반환된 신호 및 리소스를 연결하는 그래프 네트워크로 표시됩니다. 이 그래프 현재 리소스에서 시작하여 시작점에서 3단계까지의 관련 오브젝트를 포함합니다. 그래프에서 노드를 클릭하면 해당 resouces에 대한 해당 웹 콘솔 페이지로 이동합니다.
    3. 문제 해결 패널을 사용하여 선택한 경고와 관련된 리소스를 찾을 수 있습니다.

      참고

      노드를 클릭하면 그래프에 표시된 것보다 더 적은 결과가 표시되는 경우가 있습니다. 이는 향후 릴리스에서 해결될 알려진 문제입니다.

      문제 해결 패널
      1. 경고(1): 이 노드는 그래프의 시작점이며 웹 콘솔에 표시된 KubeContainerWaiting 경고를 나타냅니다.
      2. pod(1): 이 노드는 이 경고와 연결된 단일 Pod 리소스가 있음을 나타냅니다. 이 노드를 클릭하면 관련 Pod를 직접 표시하는 콘솔 검색이 열립니다.
      3. 이벤트(2): Pod와 관련된 두 개의 Kuberenetes 이벤트가 있습니다. 이 노드를 클릭하여 이벤트를 확인합니다.
      4. 로그(74): 이 포드에는 이 노드를 클릭하여 액세스할 수 있는 74개의 로그 행이 있습니다.
      5. 지표(105): Pod와 관련된 많은 메트릭이 있습니다.
      6. 네트워크(6): 포드가 네트워크를 통해 통신했음을 나타내는 네트워크 이벤트가 있습니다. 그래프의 나머지 노드는 Pod가 통신한 Service,DeploymentDaemonSet 리소스를 나타냅니다.
      7. focus: 이 버튼을 클릭하면 그래프가 업데이트됩니다. 기본적으로 그래프의 노드를 클릭하면 그래프 자체는 변경되지 않습니다. 대신 기본 웹 콘솔 페이지가 변경되고 페이지의 링크를 사용하여 다른 리소스로 이동할 수 있지만 문제 해결 패널 자체는 열려 있고 변경되지 않은 상태로 유지됩니다. 문제 해결 패널의 그래프를 강제로 업데이트하려면 을 클릭합니다. 그러면 웹 콘솔의 현재 리소스를 시작점으로 사용하여 새 그래프가 표시됩니다.
      8. 쿼리 표시: 이 버튼을 클릭하면 몇 가지 실험적 기능이 활성화됩니다.

        실험적 기능
        1. 쿼리 숨기는 실험적 기능을 숨깁니다. Hide Query hides the experimental features.
        2. 그래프의 시작 지점을 식별하는 쿼리입니다. 그래프를 만드는 데 사용되는 Korrel8r 상관 엔진의 일부인 쿼리 언어는 실험적이며 향후 변경될 수 있습니다. 쿼리는 기본 웹 콘솔 창의 리소스에 대응하도록 focus 버튼에 의해 업데이트됩니다.
        3. 고위 깊이 는 더 작거나 더 큰 것을 표시하는 데 사용됩니다.

          참고

          큰 클러스터에서 큰 값을 설정하면 결과 수가 너무 크면 쿼리가 실패할 수 있습니다.

        4. 목표 클래스는 검색 대신 검색 방향을 목표로 합니다. 목표는 시작 지점에서 목표 클래스까지의 모든 경로를 표시하며, 이는 리소스 또는 신호 유형을 나타냅니다. 목표 클래스의 형식은 실험적이며 변경될 수 있습니다. 현재 다음 목표는 유효합니다.

          • k8s:RESOURCE[VERSION.[GROUP]] 은 일종의 kuberenetes 리소스를 식별합니다. 예: k8s:Pod 또는 k8s:Deployment.apps.v1.
          • 경고: 경고를 나타냅니다.
          • 메트릭: 메트릭 을 나타냅니다.
          • NetFlow:network 는 모든 네트워크 관찰 기능 네트워크 이벤트를 나타냅니다.
          • 로그: 저장된 로그를 나타내는LOG_TYPE. 여기서 LOG_TYPE애플리케이션,인프라 또는 감사 중 하나여야 합니다.

5.4.3. 예제 경고 생성

문제 해결 UI 패널에서 경고를 시작점으로 트리거하려면 의도적으로 잘못 구성된 컨테이너를 배포할 수 있습니다.

프로세스

  1. 명령줄 또는 웹 콘솔의 다음 YAML을 사용하여 시스템 네임스페이스에 손상된 배포를 생성합니다.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: bad-deployment
      namespace: default 1
    spec:
      selector:
        matchLabels:
          app: bad-deployment
      template:
        metadata:
          labels:
            app: bad-deployment
        spec:
          containers: 2
          - name: bad-deployment
            image: quay.io/openshift-logging/vector:5.8
    1
    원하는 경고를 유발하려면 시스템 네임스페이스(예: default)에 배포해야 합니다.
    2
    이 컨테이너는 구성 파일 없이 벡터 서버를 의도적으로 시작하려고 합니다. 서버는 몇 가지 메시지를 기록한 다음 오류와 함께 종료합니다. 또는 이러한 컨테이너를 잘못 구성하여 이로 인해 경고가 트리거될 수 있습니다.
  2. 경고를 확인합니다.

    1. 모니터링경고로 이동하여 모든 필터 지우기 를 클릭합니다. 보류 중 경고를 확인합니다.

      중요

      먼저 경고가 Pending (보류 중) 상태로 표시됩니다. 컨테이너가 잠시 충돌할 때까지 실행되지 않습니다. 보류 중 경고를 보면 발생하는 것을 확인하기 위해 기다릴 필요가 없습니다.

    2. KubeContainerWaiting,KubePodCrashLooping, KubePodNotReady 경고 중 하나를 선택하고 링크를 클릭하여 문제 해결 패널을 엽니다. 또는 패널이 이미 열려 있는 경우 "Focus" 버튼을 클릭하여 그래프를 업데이트합니다.

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.