17.4. 가시성


17.4.1. 통신사 핵심 CNF 클러스터의 관찰성

OpenShift Container Platform은 플랫폼과 해당 플랫폼에서 실행되는 워크로드 모두에서 성능 지표와 로그 등 방대한 양의 데이터를 생성합니다. 관리자는 다양한 도구를 사용하여 사용 가능한 모든 데이터를 수집하고 분석할 수 있습니다. 다음은 시스템 엔지니어, 설계자 및 관리자를 위한 관찰성 스택 구성 모범 사례 개요입니다.

명시적으로 언급하지 않는 한, 이 문서의 내용은 Edge 및 Core 배포를 모두 참조합니다.

17.4.1.1. 모니터링 스택 이해

모니터링 스택은 다음 구성 요소를 사용합니다.

  • Prometheus는 OpenShift Container Platform 구성 요소와 워크로드에서 메트릭을 수집하고 분석합니다(구성된 경우).
  • Alertmanager는 알람의 라우팅, 그룹화, 음소거를 처리하는 Prometheus의 구성 요소입니다.
  • Thanos는 메트릭의 장기 저장을 처리합니다.

그림 17.2. OpenShift 컨테이너 플랫폼 모니터링 아키텍처

참고

단일 노드 OpenShift 클러스터의 경우 클러스터가 분석 및 보존을 위해 모든 메트릭을 허브 클러스터로 전송하므로 Alertmanager와 Thanos를 비활성화해야 합니다.

17.4.1.2. 주요 성과 지표

시스템에 따라 사용 가능한 측정값이 수백 개일 수 있습니다.

주의해야 할 몇 가지 주요 지표는 다음과 같습니다.

  • etcd 응답 시간
  • API 응답 시간
  • Pod 재시작 및 예약
  • 리소스 사용량
  • OVN 건강
  • 전체 클러스터 운영자 상태

따라야 할 좋은 규칙은 특정 지표가 중요하다고 판단되면 해당 지표에 대한 알림을 제공하는 것입니다.

참고

다음 명령을 실행하여 사용 가능한 메트릭을 확인할 수 있습니다.

$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data
Copy to Clipboard Toggle word wrap
17.4.1.2.1. PromQL의 쿼리 예

다음 표에서는 OpenShift Container Platform 콘솔을 사용하여 메트릭 쿼리 브라우저에서 탐색할 수 있는 몇 가지 쿼리를 보여줍니다.

참고

콘솔의 URL은 https://<OpenShift 콘솔 FQDN>/monitoring/query-browser입니다. 다음 명령을 실행하면 OpenShift 콘솔 FQDN을 얻을 수 있습니다.

$ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}'
Copy to Clipboard Toggle word wrap
Expand
표 17.1. 노드 메모리 및 CPU 사용량
지표쿼리

노드별 CPU % 요청

(노드)별 합계 (sum_over_time(kube_pod_container_resource_requests{resource="cpu"}[60m]))/(노드)별 합계 (sum_over_time(kube_node_status_allocatable{resource="cpu"}[60m])) *100

전체 클러스터 CPU % 사용률

(관리형 클러스터)의 합계 (시간당 합계(kube_pod_container_resource_requests{resource="memory"}[60m]))/(관리형 클러스터)의 합계 (시간당 합계(kube_node_status_allocatable{resource="cpu"}[60m])) *100

노드별 메모리 % 요청

(노드)별 합계 (sum_over_time(kube_pod_container_resource_requests{resource="memory"}[60m]))/(노드)별 합계 (sum_over_time(kube_node_status_allocatable{resource="memory"}[60m])) *100

전체 클러스터 메모리 사용률(%)

(1-(sum by (managed_cluster)(avg_over_timenode_memory_MemAvailable_bytes[60m] ))/(managed_cluster)(avg_over_time(kube_node_status_allocatable{resource="memory"}[60m])))*100에 의한 합계

Expand
표 17.2. 동사별 API 대기 시간
지표쿼리

GET

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="GET"}[60m])))

PATCH

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="패치"}[60m])))

POST

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="POST"}[60m])))

LIST

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="목록"}[60m])))

PUT

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="PUT"}[60m])))

삭제

히스토그램 분위수(0.99, (le, 관리형 클러스터)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver|openshift-apiserver", 동사="삭제"}[60m])))

결합된

histogram_quantile(0.99, (le,managed_cluster)에 대한 합계(apiserver_request_duration_seconds_bucket{apiserver=~"(openshift-apiserver|kube-apiserver)", verb!="WATCH"}[60m])))

Expand
표 17.3. etcd
지표쿼리

fsync 99번째 백분위수 지연 시간(인스턴스당)

histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))

fsync 99번째 백분위수 지연 시간(클러스터당)

(managed_cluster)에 의한 합계 (histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[60m])))

지도자 선거

sum(rate(etcd_server_leader_changes_seen_total[1440m]))

네트워크 지연 시간

histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[5m]))

Expand
표 17.4. 운영자 건강
지표쿼리

저하된 운영자

(managed_cluster, name)에 따른 합계 (avg_over_time(cluster_operator_conditions{condition="Degraded", name!="version"}[60m]))

클러스터당 저하된 총 연산자

(managed_cluster)의 합계 (avg_over_time(cluster_operator_conditions{condition="Degraded", name!="version"}[60m] ))

17.4.1.2.2. 메트릭 저장을 위한 권장 사항

기본적으로 Prometheus는 영구 스토리지를 사용하여 저장된 지표를 백업하지 않습니다. Prometheus Pod를 다시 시작하면 모든 메트릭 데이터가 손실됩니다. 플랫폼에서 사용 가능한 백엔드 스토리지를 사용하도록 모니터링 스택을 구성해야 합니다. Prometheus의 높은 IO 요구 사항을 충족하려면 로컬 스토리지를 사용해야 합니다.

Telco 코어 클러스터의 경우 Prometheus의 영구 저장소로 Local Storage Operator를 사용할 수 있습니다.

블록, 파일, 객체 스토리지를 위한 Ceph 클러스터를 구축하는 Red Hat OpenShift Data Foundation(ODF)도 통신사 코어 클러스터에 적합한 후보입니다.

RAN 단일 노드 OpenShift 또는 Far Edge 클러스터에서 시스템 리소스 요구 사항을 낮게 유지하려면 모니터링 스택에 대한 백엔드 스토리지를 프로비저닝해서는 안 됩니다. 이러한 클러스터는 모든 측정 항목을 허브 클러스터로 전달하며, 여기서 타사 모니터링 플랫폼을 프로비저닝할 수 있습니다.

17.4.1.3. 에지 모니터링

에지의 단일 노드 OpenShift는 플랫폼 구성 요소의 설치 공간을 최소한으로 유지합니다. 다음 절차는 모니터링 공간이 작은 단일 노드 OpenShift 노드를 구성하는 방법의 예입니다.

사전 요구 사항

  • Red Hat Advanced Cluster Management(RHACM)를 사용하는 환경의 경우 Observability 서비스를 활성화했습니다.
  • 허브 클러스터는 Red Hat OpenShift Data Foundation(ODF)을 실행하고 있습니다.

프로세스

  1. 다음 예와 같이 ConfigMap CR을 만들고 monitoringConfigMap.yaml 로 저장합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
     data:
     config.yaml: |
       alertmanagerMain:
         enabled: false
       telemeterClient:
         enabled: false
       prometheusK8s:
          retention: 24h
    Copy to Clipboard Toggle word wrap
  2. 단일 노드 OpenShift에서 다음 명령을 실행하여 ConfigMap CR을 적용합니다.

    $ oc apply -f monitoringConfigMap.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예와 같이 NameSpace CR을 만들고 monitoringNamespace.yaml 로 저장합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: open-cluster-management-observability
    Copy to Clipboard Toggle word wrap
  4. 허브 클러스터에서 다음 명령을 실행하여 허브 클러스터에 네임스페이스 CR을 적용합니다.

    $ oc apply -f monitoringNamespace.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 예와 같이 ObjectBucketClaim CR을 만들고 monitoringObjectBucketClaim.yaml 로 저장합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: multi-cloud-observability
      namespace: open-cluster-management-observability
    spec:
      storageClassName: openshift-storage.noobaa.io
      generateBucketName: acm-multi
    Copy to Clipboard Toggle word wrap
  6. 허브 클러스터에서 다음 명령을 실행하여 ObjectBucketClaim CR을 적용합니다.

    $ oc apply -f monitoringObjectBucketClaim.yaml
    Copy to Clipboard Toggle word wrap
  7. 다음 예와 같이 비밀 CR을 만들고 monitoringSecret.yaml 로 저장합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: multiclusterhub-operator-pull-secret
      namespace: open-cluster-management-observability
    stringData:
      .dockerconfigjson: 'PULL_SECRET'
    Copy to Clipboard Toggle word wrap
  8. 허브 클러스터에서 다음 명령을 실행하여 Secret CR을 적용합니다.

    $ oc apply -f monitoringSecret.yaml
    Copy to Clipboard Toggle word wrap
  9. 다음 명령을 실행하여 허브 클러스터에서 NooBaa 서비스에 대한 키와 백엔드 버킷 이름을 가져옵니다.

    $ NOOBAA_ACCESS_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
    Copy to Clipboard Toggle word wrap
    $ NOOBAA_SECRET_KEY=$(oc get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
    Copy to Clipboard Toggle word wrap
    $ OBJECT_BUCKET=$(oc get objectbucketclaim -n open-cluster-management-observability multi-cloud-observability -o json | jq -r .spec.bucketName)
    Copy to Clipboard Toggle word wrap
  10. 다음 예와 같이 버킷 저장소에 대한 비밀 CR을 만들고 monitoringBucketSecret.yaml 로 저장합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-object-storage
      namespace: open-cluster-management-observability
    type: Opaque
    stringData:
      thanos.yaml: |
        type: s3
        config:
          bucket: ${OBJECT_BUCKET}
          endpoint: s3.openshift-storage.svc
          insecure: true
          access_key: ${NOOBAA_ACCESS_KEY}
          secret_key: ${NOOBAA_SECRET_KEY}
    Copy to Clipboard Toggle word wrap
  11. 허브 클러스터에서 다음 명령을 실행하여 Secret CR을 적용합니다.

    $ oc apply -f monitoringBucketSecret.yaml
    Copy to Clipboard Toggle word wrap
  12. 다음 예와 같이 MultiClusterObservability CR을 만들고 monitoringMultiClusterObservability.yaml 로 저장합니다.

    apiVersion: observability.open-cluster-management.io/v1beta2
    kind: MultiClusterObservability
    metadata:
      name: observability
    spec:
      advanced:
        retentionConfig:
          blockDuration: 2h
          deleteDelay: 48h
          retentionInLocal: 24h
          retentionResolutionRaw: 3d
      enableDownsampling: false
      observabilityAddonSpec:
        enableMetrics: true
        interval: 300
      storageConfig:
        alertmanagerStorageSize: 10Gi
        compactStorageSize: 100Gi
        metricObjectStorage:
          key: thanos.yaml
          name: thanos-object-storage
        receiveStorageSize: 25Gi
        ruleStorageSize: 10Gi
        storeStorageSize: 25Gi
    Copy to Clipboard Toggle word wrap
  13. 허브 클러스터에서 다음 명령을 실행하여 MultiClusterObservability CR을 적용합니다.

    $ oc apply -f monitoringMultiClusterObservability.yaml
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 네임스페이스의 경로와 포드를 확인하여 서비스가 허브 클러스터에 배포되었는지 확인합니다.

    $ oc get routes,pods -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                         HOST/PORT                                                                                        PATH      SERVICES                          PORT          TERMINATION          WILDCARD
    route.route.openshift.io/alertmanager        alertmanager-open-cluster-management-observability.cloud.example.com        /api/v2   alertmanager                      oauth-proxy   reencrypt/Redirect   None
    route.route.openshift.io/grafana             grafana-open-cluster-management-observability.cloud.example.com                       grafana                           oauth-proxy   reencrypt/Redirect   None 
    1
    
    route.route.openshift.io/observatorium-api   observatorium-api-open-cluster-management-observability.cloud.example.com             observability-observatorium-api   public        passthrough/None     None
    route.route.openshift.io/rbac-query-proxy    rbac-query-proxy-open-cluster-management-observability.cloud.example.com              rbac-query-proxy                  https         reencrypt/Redirect   None
    
    NAME                                                           READY   STATUS    RESTARTS   AGE
    pod/observability-alertmanager-0                               3/3     Running   0          1d
    pod/observability-alertmanager-1                               3/3     Running   0          1d
    pod/observability-alertmanager-2                               3/3     Running   0          1d
    pod/observability-grafana-685b47bb47-dq4cw                     3/3     Running   0          1d
    <...snip…>
    pod/observability-thanos-store-shard-0-0                       1/1     Running   0          1d
    pod/observability-thanos-store-shard-1-0                       1/1     Running   0          1d
    pod/observability-thanos-store-shard-2-0                       1/1     Running   0          1d
    Copy to Clipboard Toggle word wrap

    1
    대시보드는 나열된 그래피나 경로에서 접근할 수 있습니다. 이를 사용하면 관리되는 모든 클러스터의 메트릭을 볼 수 있습니다.

Red Hat Advanced Cluster Management의 관찰성에 대한 자세한 내용은 관찰성을 참조하세요.

17.4.1.4. 경고

OpenShift Container Platform에는 많은 수의 알림 규칙이 포함되어 있으며, 이러한 알림 규칙은 릴리스마다 변경될 수 있습니다.

17.4.1.4.1. 기본 알림 보기

다음 절차에 따라 클러스터의 모든 알림 규칙을 검토하세요.

프로세스

  • 클러스터의 모든 알림 규칙을 검토하려면 다음 명령을 실행하세요.

    $ oc get cm -n openshift-monitoring prometheus-k8s-rulefiles-0 -o yaml
    Copy to Clipboard Toggle word wrap

    규칙에는 설명을 포함하고 추가 정보 및 완화 단계에 대한 링크를 제공할 수 있습니다. 예를 들어, etcdHighFsyncDurations 에 대한 규칙은 다음과 같습니다.

          - alert: etcdHighFsyncDurations
            annotations:
              description: 'etcd cluster "{{ $labels.job }}": 99th percentile fsync durations
                are {{ $value }}s on etcd instance {{ $labels.instance }}.'
              runbook_url: https://github.com/openshift/runbooks/blob/master/alerts/cluster-etcd-operator/etcdHighFsyncDurations.md
              summary: etcd cluster 99th percentile fsync durations are too high.
            expr: |
              histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket{job=~".*etcd.*"}[5m]))
              > 1
            for: 10m
            labels:
              severity: critical
    Copy to Clipboard Toggle word wrap
17.4.1.4.2. 알림 알림

OpenShift Container Platform 콘솔에서 알림을 볼 수 있지만, 관리자는 알림을 전달할 외부 수신기를 구성해야 합니다. OpenShift Container Platform은 다음과 같은 수신기 유형을 지원합니다.

  • PagerDuty: 제3자 사고 대응 플랫폼
  • Webhook: POST 요청을 통해 알림을 받고 필요한 모든 조치를 취할 수 있는 임의의 API 엔드포인트
  • 이메일: 지정된 주소로 이메일을 보냅니다.
  • Slack: Slack 채널이나 개별 사용자에게 알림을 보냅니다.

17.4.1.5. 작업 부하 모니터링

기본적으로 OpenShift Container Platform은 애플리케이션 워크로드에 대한 메트릭을 수집하지 않습니다. 워크로드 지표를 수집하도록 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • 클러스터에서 작업 부하 측정 항목을 수집하기 위해 엔드포인트를 정의했습니다.

프로세스

  1. 다음 예와 같이 ConfigMap CR을 만들고 monitoringConfigMap.yaml 로 저장합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true 
    1
    Copy to Clipboard Toggle word wrap
    1
    작업 부하 모니터링을 활성화하려면 true 로 설정합니다.
  2. 다음 명령을 실행하여 ConfigMap CR을 적용합니다.

    $ oc apply -f monitoringConfigMap.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예와 같이 ServiceMonitor CR을 만들고 monitoringServiceMonitor.yaml 로 저장합니다.

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        app: ui
      name: myapp
      namespace: myns
    spec:
      endpoints: 
    1
    
      - interval: 30s
        port: ui-http
        scheme: http
        path: /healthz 
    2
    
      selector:
        matchLabels:
          app: ui
    Copy to Clipboard Toggle word wrap
    1
    엔드포인트를 사용하여 작업 부하 측정 항목을 정의합니다.
    2
    Prometheus는 기본적으로 /metrics 경로를 스크래핑합니다. 여기서 사용자 정의 경로를 정의할 수 있습니다.
  4. 다음 명령을 실행하여 ServiceMonitor CR을 적용합니다.

    $ oc apply -f monitoringServiceMonitor.yaml
    Copy to Clipboard Toggle word wrap

Prometheus는 기본적으로 /metrics 경로를 스크래핑하지만 사용자 지정 경로를 정의할 수 있습니다. 스크래핑을 위해 이 엔드포인트를 공개하고 관련성이 있다고 생각되는 측정항목을 제공하는 것은 애플리케이션 공급업체의 몫입니다.

17.4.1.5.1. 작업 부하 알림 생성

클러스터의 사용자 워크로드에 대한 알림을 활성화할 수 있습니다.

프로세스

  1. 다음 예와 같이 ConfigMap CR을 만들고 monitoringConfigMap.yaml 로 저장합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        enableUserWorkload: true 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    작업 부하 모니터링을 활성화하려면 true 로 설정합니다.
  2. 다음 명령을 실행하여 ConfigMap CR을 적용합니다.

    $ oc apply -f monitoringConfigMap.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예와 같이 알림 규칙에 대한 YAML 파일인 monitoringAlertRule.yaml 을 만듭니다.

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: myapp-alert
      namespace: myns
    spec:
      groups:
      - name: example
        rules:
        - alert: InternalErrorsAlert
          expr: flask_http_request_total{status="500"} > 0
    # ...
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 알림 규칙을 적용합니다.

    $ oc apply -f monitoringAlertRule.yaml
    Copy to Clipboard Toggle word wrap
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat