Cluster Observability Operator
OpenShift Container Platform에서 Cluster Observability Operator 구성 및 사용
초록
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. 새로운 기능 및 개선 사항
-
Prometheus CR에서 Alertmanager
스키마
및tlsConfig
필드를 구성할 수 있습니다. (COO-219)
문제 해결 패널에 대한 확장된 기술 프리뷰는 Kubernetes 리소스와 추적을 비교하고 로그, 경고, 지표 및 네트워크 이벤트를 포함하여 다른 관찰 가능한 신호와 직접 관련된 지원을 추가합니다. (COO-450)
-
웹 콘솔에서 모니터링 → 추적을 클릭하여 추적 페이지로 이동할 때 Tempo 인스턴스 및 테넌트를 선택할 수 있습니다. 프리뷰 문제 해결 패널은
openshift-tracing / platform
instance 및platform
테넌트에서만 작동합니다. - 문제 해결 패널은 관리자 관점에서 가장 잘 작동합니다. 일부 백엔드의 권한 부여 문제, 특히 메트릭 및 경고에 대한 Prometheus로 인해 개발자 관점에서 기능이 제한됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.
-
웹 콘솔에서 모니터링 → 추적을 클릭하여 추적 페이지로 이동할 때 Tempo 인스턴스 및 테넌트를 선택할 수 있습니다. 프리뷰 문제 해결 패널은
다음 표에서는 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
에서 문제 해결 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 플러그인이 다중 테넌트
TempoStack
및TempoMonolithic
인스턴스만 사용하여 강화되었습니다.
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는 작업자를 관리하는 작업자에 따라 병합 필드를 적용합니다.
프로세스
다음 구성을 사용하여
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
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
-
metadata.managedFields
값을 확인하고,메타데이터
및사양
의 일부 필드가MonitoringStack
리소스에서 관리되는지 확인합니다. MonitoringStack
리소스에서 제어하지 않는 필드를 수정합니다.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
다음 명령을 실행하여 YAML을 적용합니다.
$ oc apply -f ./prom-spec-edited.yaml --server-side
참고--server-side
플래그를 사용해야 합니다.변경된 Prometheus 오브젝트를 가져오고
managedFields
에spec.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
MonitoringStack
리소스에서 관리하는 필드를 수정합니다.다음 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
추가
다음 명령을 실행하여 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
-
spec.logLevel
필드는observability-operator
에서 이미 관리하므로 Server-Side Apply를 사용하여 변경할 수 없습니다. --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
사양
을 변경하여 변경할 수 있습니다.Prometheus 오브젝트에서
logLevel
을 변경하려면 다음 YAML을 적용하여MonitoringStack
리소스를 변경합니다.apiVersion: monitoring.rhobs/v1alpha1 kind: MonitoringStack metadata: name: sample-monitoring-stack labels: coo: example spec: logLevel: info
변경 사항이 수행되었는지 확인하려면 다음 명령을 실행하여 로그 수준을 쿼리합니다.
$ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
출력 예
info
새 버전의 Operator가 이전에 액터에 의해 생성 및 제어되는 필드를 생성하면 액터에 의해 설정된 값이 재정의됩니다.
예를 들어
MonitoringStack
리소스에서 생성하지 않는enforcedSampleLimit
필드를 관리하고 있습니다. Observability Operator가 업그레이드되고 새 버전의 Operator가enforcedSampleLimit
에 대한 값을 생성하는 경우 이전에 설정한 값을 덮어씁니다.-
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 웹 콘솔에 로그인했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
-
키워드로 필터링 상자에
cluster observability Operator
를 입력합니다. - 결과 목록에서 Cluster Observability Operator 를 클릭합니다.
Operator에 대한 정보를 읽고 다음 설치 설정을 구성합니다.
- 업데이트 채널 → stable
- 버전 → 1.0.0 이상
- 설치 모드 → 클러스터의 모든 네임스페이스(기본값)
- 설치된 네임스페이스 → Operator 권장 네임스페이스: openshift-cluster-observability-operator
- 이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화를선택합니다.
- 업데이트 승인 → 자동
- 선택 사항: 요구 사항에 맞게 설치 설정을 변경할 수 있습니다. 예를 들어 다른 업데이트 채널에 가입하거나, 이전 릴리스 버전의 Operator를 설치하거나, 새 버전의 Operator에 대한 업데이트에 대한 수동 승인이 필요한 경우 선택할 수 있습니다.
- 설치를 클릭합니다.
검증
- Operator → 설치된 Operator 로 이동하여 Cluster Observability Operator 항목이 목록에 표시되는지 확인합니다.
추가 리소스
3.2. 웹 콘솔을 사용하여 Cluster Observability Operator 설치 제거
OperatorHub를 사용하여 COO(Cluster Observability Operator)를 설치한 경우 OpenShift Container Platform 웹 콘솔에서 해당 Operator를 제거할 수 있습니다.
사전 요구 사항
-
cluster-admin
클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 로그인했습니다.
프로세스
- Operator → 설치된 Operator 로 이동합니다.
- 목록에서 Cluster Observability Operator 항목을 찾습니다.
-
이 항목에 대해
를 클릭하고 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
클러스터 역할의 사용자로 또는 네임스페이스에 대한 관리 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
프로세스
네임스페이스, 배포 및 서비스에 대한 다음 구성 세부 정보가 포함된
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
- 파일을 저장합니다.
다음 명령을 실행하여 클러스터에 구성을 적용합니다.
$ oc apply -f prometheus-coo-example-app.yaml
다음 명령을 실행하고 출력을 관찰하여 포드가 실행 중인지 확인합니다.
$ 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 인증을 지원하지 않습니다.
프로세스
다음
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
오브젝트를 정의합니다.다음 명령을 실행하여 클러스터에 구성을 적용합니다.
$ oc apply -f example-coo-app-service-monitor.yaml
다음 명령을 실행하고 출력을 관찰하여
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
오브젝트를 생성했습니다.
프로세스
-
MonitoringStack
오브젝트 구성에 대한 YAML 파일을 생성합니다. 이 예제에서는example-coo-monitoring-stack.yaml
파일의 이름을 지정합니다. 다음
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
다음 명령을 실행하여
MonitoringStack
오브젝트를 적용합니다.$ oc apply -f example-coo-monitoring-stack.yaml
다음 명령을 실행하고 출력을 검사하여
MonitoringStack
오브젝트를 사용할 수 있는지 확인합니다.$ oc -n ns1-coo get monitoringstack
출력 예
NAME AGE example-coo-monitoring-stack 81m
다음 명령을 실행하여 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
오브젝트를 생성했습니다.
프로세스
example
prometheus-coo-example-app
서비스를 노출할 경로를 생성합니다. 터미널에서 다음 명령을 실행합니다.$ oc expose svc prometheus-coo-example-app
- 브라우저 또는 명령줄에서 경로에 액세스하여 메트릭을 생성합니다.
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 프로젝트에서 제공하는 관찰 가능성 신호 상관 관계를 제공합니다. Observe → Alerting 페이지에서 제공되는 문제 해결 패널을 사용하여 다양한 데이터 저장소에서 메트릭, 로그, 경고, netflows 및 추가 관찰 가능성 신호 및 리소스를 쉽게 연결할 수 있습니다. OpenShift Container Platform 버전 4.17 이상 사용자는 Application 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 서비스에 연결하고 Observe → Logs 페이지에서 Observe → Metrics 페이지에 있는 직접 링크를 PromQL 쿼리와 함께 추가합니다. 또한 Observe → Alerting 의 관리 관점 경고 세부 정보 페이지의 관련 로그 보기 링크를 선택한 Observe → Logs 페이지에 추가합니다.
플러그인의 기능은 다음과 같이 분류됩니다.
- dev-console
- 개발자 화면에 로깅 보기를 추가합니다.
- 경고
- Loki 규칙자에 정의된 로그 기반 경고와 웹 콘솔 경고를 병합합니다. 경고 세부 정보 뷰에 로그 기반 메트릭 차트를 추가합니다.
- dev-alerts
- Loki 규칙자에 정의된 로그 기반 경고와 웹 콘솔 경고를 병합합니다. 개발자 화면에 대한 경고 세부 정보 뷰에 로그 기반 지표 차트를 추가합니다.
COO(Cluster Observability Operator) 버전의 경우 OpenShift Container Platform 버전에서 이러한 기능에 대한 지원이 다음 표에 표시되어 있습니다.
COO 버전 | OCP 버전 | 기능 |
---|---|---|
0.3.0+ | 4.12 |
|
0.3.0+ | 4.13 |
|
0.3.0+ | 4.14+ |
|
5.2.1. Cluster Observability Operator 로깅 UI 플러그인 설치
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift Container Platform 웹 콘솔에 로그인했습니다.
- Cluster Observability Operator가 설치되어 있습니다.
-
클러스터에
LokiStack
인스턴스가 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
- 탭 목록의 맨 오른쪽에 있는 UI 플러그인 탭을 선택하고 Create UIPlugin 을 클릭합니다.
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 플러그인은 Observe → Traces 의 OpenShift 웹 콘솔의 관리자 화면에 추적 관련 기능을 추가합니다. 프런트 엔드 및 마이크로 서비스 백엔드로 요청을 수행하여 분산 시스템의 코드 오류 및 성능 병목 현상을 식별할 수 있습니다.
5.3.1. Cluster Observability Operator distributed tracing UI 플러그인 설치
사전 요구 사항
-
cluster-admin
클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 로그인했습니다.
- Cluster Observability Operator가 설치되어 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
- UI 플러그인 탭(tab 목록의 맨 오른쪽에 있음)을 선택하고 Create UIPlugin을 누릅니다.
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
다중 테넌트 인스턴스가 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔의 관리자 화면에서 모니터링 → 추적을 클릭합니다.
TempoStack
또는TempoMonolithic
다중 테넌트 인스턴스를 선택하고 추적을 로드할 시간 범위 및 쿼리를 설정합니다.추적은 추적 시작 시간, 기간 및 기간 수를 보여주는 묶인 플로트에 표시됩니다. 분산형 플롯 아래에는 추적
이름, 범위 수 및
목록이 있습니다.기간
과 같은 정보를 보여주는 추적추적 이름 링크를 클릭합니다.
선택한 추적에 대한 추적 세부 정보 페이지에는 추적 내의 모든 범위의 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
에서 문제 해결 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가 설치되어 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Cluster Observability Operator를 선택합니다.
- UI 플러그인 탭(tab 목록의 맨 오른쪽에 있음)을 선택하고 Create UIPlugin을 누릅니다.
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에서 문제 해결 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에서 제공하는 네트워크 관찰 기능
프로세스
웹 콘솔의 관리자 화면에서 모니터링 → 경고로 이동한 다음 경고를 선택합니다. 경고에 관련 항목이 있는 경우 경고 세부 정보 페이지의 차트 위에 문제 해결 패널 링크가 표시됩니다.
패널 문제 해결 링크를 클릭하여 패널을 표시합니다.
-
패널은 쿼리 세부 정보와 쿼리 결과의 토폴로지 그래프로 구성됩니다. 선택한 경고는 Korrel8r 쿼리 문자열로 변환되고
korrel8r
서비스로 전송됩니다. 결과는 반환된 신호 및 리소스를 연결하는 그래프 네트워크로 표시됩니다. 이 그래프 는 현재 리소스에서 시작하여 시작점에서 3단계까지의 관련 오브젝트를 포함합니다. 그래프에서 노드를 클릭하면 해당 resouces에 대한 해당 웹 콘솔 페이지로 이동합니다. 문제 해결 패널을 사용하여 선택한 경고와 관련된 리소스를 찾을 수 있습니다.
참고노드를 클릭하면 그래프에 표시된 것보다 더 적은 결과가 표시되는 경우가 있습니다. 이는 향후 릴리스에서 해결될 알려진 문제입니다.
-
경고(1): 이 노드는 그래프의 시작점이며 웹 콘솔에 표시된
KubeContainerWaiting
경고를 나타냅니다. -
pod(1): 이 노드는 이 경고와 연결된 단일
Pod
리소스가 있음을 나타냅니다. 이 노드를 클릭하면 관련 Pod를 직접 표시하는 콘솔 검색이 열립니다. - 이벤트(2): Pod와 관련된 두 개의 Kuberenetes 이벤트가 있습니다. 이 노드를 클릭하여 이벤트를 확인합니다.
- 로그(74): 이 포드에는 이 노드를 클릭하여 액세스할 수 있는 74개의 로그 행이 있습니다.
- 지표(105): Pod와 관련된 많은 메트릭이 있습니다.
-
네트워크(6): 포드가 네트워크를 통해 통신했음을 나타내는 네트워크 이벤트가 있습니다. 그래프의 나머지 노드는 Pod가 통신한
Service
,Deployment
및DaemonSet
리소스를 나타냅니다. - focus: 이 버튼을 클릭하면 그래프가 업데이트됩니다. 기본적으로 그래프의 노드를 클릭하면 그래프 자체는 변경되지 않습니다. 대신 기본 웹 콘솔 페이지가 변경되고 페이지의 링크를 사용하여 다른 리소스로 이동할 수 있지만 문제 해결 패널 자체는 열려 있고 변경되지 않은 상태로 유지됩니다. 문제 해결 패널의 그래프를 강제로 업데이트하려면 을 클릭합니다. 그러면 웹 콘솔의 현재 리소스를 시작점으로 사용하여 새 그래프가 표시됩니다.
쿼리 표시: 이 버튼을 클릭하면 몇 가지 실험적 기능이 활성화됩니다.
- 쿼리 숨기는 실험적 기능을 숨깁니다. Hide Query hides the experimental features.
- 그래프의 시작 지점을 식별하는 쿼리입니다. 그래프를 만드는 데 사용되는 Korrel8r 상관 엔진의 일부인 쿼리 언어는 실험적이며 향후 변경될 수 있습니다. 쿼리는 기본 웹 콘솔 창의 리소스에 대응하도록 focus 버튼에 의해 업데이트됩니다.
고위 깊이 는 더 작거나 더 큰 것을 표시하는 데 사용됩니다.
참고큰 클러스터에서 큰 값을 설정하면 결과 수가 너무 크면 쿼리가 실패할 수 있습니다.
목표 클래스는 검색 대신 검색 방향을 목표로 합니다. 목표는 시작 지점에서 목표 클래스까지의 모든 경로를 표시하며, 이는 리소스 또는 신호 유형을 나타냅니다. 목표 클래스의 형식은 실험적이며 변경될 수 있습니다. 현재 다음 목표는 유효합니다.
-
k8s:RESOURCE[VERSION.[GROUP]]
은 일종의 kuberenetes 리소스를 식별합니다. 예:k8s:Pod
또는k8s:Deployment.apps.v1
. -
경고: 경고를
나타냅니다. -
메트릭: 메트릭
을 나타냅니다. -
NetFlow:network
는 모든 네트워크 관찰 기능 네트워크 이벤트를 나타냅니다. -
로그: 저장된 로그를 나타내는LOG_TYPE
. 여기서LOG_TYPE
은애플리케이션
,인프라
또는감사
중 하나여야 합니다.
-
-
경고(1): 이 노드는 그래프의 시작점이며 웹 콘솔에 표시된
5.4.3. 예제 경고 생성
문제 해결 UI 패널에서 경고를 시작점으로 트리거하려면 의도적으로 잘못 구성된 컨테이너를 배포할 수 있습니다.
프로세스
명령줄 또는 웹 콘솔의 다음 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
경고를 확인합니다.
모니터링 → 경고로 이동하여 모든 필터 지우기 를 클릭합니다.
보류
중 경고를 확인합니다.중요먼저 경고가
Pending
(보류 중) 상태로 표시됩니다. 컨테이너가 잠시 충돌할 때까지 실행되지 않습니다.보류 중
경고를 보면 발생하는 것을 확인하기 위해 기다릴 필요가 없습니다.-
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.