7.11. 모니터링 문제 조사


OpenShift Container Platform에는 핵심 플랫폼 구성 요소에 대한 모니터링을 제공하는 사전 구성된 사전 설치된 자체 업데이트 모니터링 스택이 포함되어 있습니다. OpenShift Container Platform 4.12에서 클러스터 관리자는 선택 옵션으로 사용자 정의 프로젝트에 대한 모니터링을 활성화할 수 있습니다.

다음 문제가 발생하는 경우 다음 절차를 사용하십시오.

  • 자체 메트릭을 사용할 수 없습니다.
  • Prometheus는 많은 디스크 공간을 사용하고 있습니다.
  • Prometheus에서 KubePersistentVolumeFillingUp 경고가 실행됩니다.

7.11.1. 사용자 정의 메트릭을 사용할 수 없는 이유 확인

ServiceMonitor 리소스를 사용하면 사용자 정의 프로젝트에서 서비스에 의해 노출되는 메트릭을 사용하는 방법을 확인할 수 있습니다. ServiceMonitor 리소스를 생성했지만 메트릭 UI에서 해당 메트릭을볼 수 없는 경우 이 프로세스에 설명된 단계를 수행하십시오.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 사용자 정의 프로젝트에 대한 모니터링을 활성화 및 구성했습니다.
  • ServiceMonitor 리소스가 생성되어 있습니다.

절차

  1. 서비스 및 ServiceMonitor 리소스 구성에서 해당 라벨이 일치하는지 확인합니다.

    1. 서비스에 정의된 라벨을 가져옵니다. 다음 예제에서는 ns1 프로젝트의 prometheus-example-app 서비스를 쿼리합니다.

      $ oc -n ns1 get service prometheus-example-app -o yaml

      출력 예

        labels:
          app: prometheus-example-app

    2. ServiceMonitor 리소스 구성의 matchLabels 정의가 이전 단계의 라벨 출력과 일치하는지 확인합니다. 다음 예제에서는 ns1 프로젝트의 prometheus-example-monitor 서비스 모니터를 쿼리합니다.

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      출력 예

      apiVersion: v1
      kind: ServiceMonitor
      metadata:
        name: prometheus-example-monitor
        namespace: ns1
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      참고

      프로젝트 보기 권한이 있는 개발자로서 서비스 및 ServiceMonitor 리소스 라벨을 확인할 수 있습니다.

  2. openshift-user-workload-monitoring 프로젝트에서 Prometheus Operator의 로그를 검사합니다.

    1. openshift-user-workload-monitoring 프로젝트의 Pod를 나열합니다.

      $ oc -n openshift-user-workload-monitoring get pods

      출력 예

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

    2. prometheus-operator pod의 prometheus-operator 컨테이너에서 로그를 가져옵니다. 다음 예에서 Pod는 prometheus-operator-776fcbbd56-2nbfm입니다.

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      서비스 모니터에 문제가 있는 경우 로그에 다음과 유사한 오류가 포함될 수 있습니다.

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
  3. OpenShift Container Platform 웹 콘솔 UI의 지표 대상 페이지에서 끝점의 대상 상태를 확인합니다.

    1. OpenShift Container Platform 웹 콘솔에 로그인하고 관리자 관점에서 Observe Targets 로 이동합니다.
    2. 목록에서 지표 엔드포인트를 찾고 Status 열에서 대상의 상태를 검토합니다.
    3. StatusDown 이면 엔드포인트의 URL을 클릭하여 해당 지표 대상의 대상 세부 정보 페이지에 대한 자세한 정보를 확인합니다.
  4. openshift-user-workload-monitoring 프로젝트에서 Prometheus Operator의 디버그 수준 로깅을 구성합니다.

    1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    2. prometheusOperatorlogLevel:debugdata / config.yaml 아래에 추가하여 로그 수준을 debug로 설정합니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...
    3. 파일을 저장하여 변경 사항을 적용합니다. 영향을 받는 prometheus-operator Pod가 자동으로 재배포됩니다.
    4. openshift-user-workload-monitoring 프로젝트의 prometheus-operator 배포에 debug 로그 수준이 적용되었는지 확인합니다.

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      출력 예

              - --log-level=debug

      디버그 수준 로깅은 Prometheus Operator가 수행한 모든 호출을 표시합니다.

    5. prometheus-operator Pod가 실행되고 있는지 확인합니다.

      $ oc -n openshift-user-workload-monitoring get pods
      참고

      구성 맵에 인식할 수 없는 Prometheus Operator loglevel 값이 포함된 경우 prometheus-operator Pod가 재시작되지 않을 수 있습니다.

    6. 디버그 로그를 검토하여 Prometheus Operator에서 ServiceMonitor 리소스를 사용하고 있는지 확인합니다. 기타 관련 오류에 대한 로그를 확인합니다.

7.11.2. Prometheus가 많은 디스크 공간을 소비하는 이유 확인

개발자는 라벨을 생성하여 키-값 쌍의 형식으로 메트릭의 속성을 정의할 수 있습니다. 잠재적인 키-값 쌍의 수는 속성에 사용 가능한 값의 수에 해당합니다. 무제한의 잠재적인 값이 있는 속성을 바인딩되지 않은 속성이라고 합니다. 예를 들어, customer_id 속성은 무제한 가능한 값이 있기 때문에 바인딩되지 않은 속성입니다.

할당된 모든 키-값 쌍에는 고유한 시계열이 있습니다. 라벨에 있는 바인딩되지 않은 많은 속성을 사용하면 생성되는 시계열 수가 기하급수적으로 증가할 수 있습니다. 이는 Prometheus 성능에 영향을 미칠 수 있으며 많은 디스크 공간을 소비할 수 있습니다.

Prometheus가 많은 디스크를 사용하는 경우 다음 조치를 사용할 수 있습니다.

  • 가장 많은 시계열 데이터를 생성하는 라벨에 대한 자세한 내용은 Prometheus HTTP API를 사용하여 시계열 데이터베이스(TSDB) 상태를 확인합니다. 이를 위해서는 클러스터 관리자 권한이 필요합니다.
  • 수집 중인 스크랩 샘플 수를 확인합니다.
  • 사용자 정의 메트릭에 할당되는 바인딩되지 않은 속성의 수를 줄임으로써 생성되는 고유의 시계열 수를 감소합니다.

    참고

    사용 가능한 값의 제한된 집합에 바인딩되는 속성을 사용하면 가능한 키 - 값 쌍 조합의 수가 줄어듭니다.

  • 사용자 정의 프로젝트에서 스크랩할 수 있는 샘플 수를 제한합니다. 여기에는 클러스터 관리자 권한이 필요합니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 관리자 관점에서 Observe Metrics 로 이동합니다.
  2. Expression 필드에 PromQL(Prometheus Query Language) 쿼리를 입력합니다. 다음 예제 쿼리는 디스크 공간 소비가 증가할 수 있는 높은 카디널리티 메트릭을 식별하는 데 도움이 됩니다.

    • 다음 쿼리를 실행하면 스크랩 샘플 수가 가장 많은 10개의 작업을 확인할 수 있습니다.

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
    • 다음 쿼리를 실행하면 지난 시간에 가장 많은 시계열 데이터를 생성한 10개의 작업을 식별하여 시계열 churn을 정확하게 지정할 수 있습니다.

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
  3. 예상 스크랩 샘플 수보다 많은 메트릭에 할당된 바인딩되지 않은 라벨 값의 수를 조사합니다.

    • 메트릭이 사용자 정의 프로젝트와 관련된 경우 워크로드에 할당된 메트릭의 키-값 쌍을 확인합니다. 이는 애플리케이션 수준에서 Prometheus 클라이언트 라이브러리를 통해 구현됩니다. 라벨에서 참조되는 바인딩되지 않은 속성의 수를 제한하십시오.
    • 메트릭이 OpenShift Container Platform의 주요 프로젝트와 관련된 경우 Red Hat Customer Portal에서 Red Hat 지원 케이스를 생성하십시오.
  4. 클러스터 관리자로 로그인할 때 다음 명령을 실행하여 Prometheus HTTP API를 사용하여 TSDB 상태를 확인합니다.

    1. 다음 명령을 실행하여 Prometheus API 경로 URL을 가져옵니다.

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.status.ingress[].host})
    2. 다음 명령을 실행하여 인증 토큰을 추출합니다.

      $ TOKEN=$(oc whoami -t)
    3. 다음 명령을 실행하여 Prometheus의 TSDB 상태를 쿼리합니다.

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"

      출력 예

      "status": "success","data":{"headStats":{"numSeries":507473,
      "numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
      "maxTime":1712257935346},"seriesCountByMetricName":
      [{"name":"etcd_request_duration_seconds_bucket","value":51840},
      {"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
      ...

7.11.3. Prometheus에 대해 KubePersistentVolumeFillingUp 경고가 실행됨

클러스터 관리자는 Prometheus에 대해 KubePersistentVolumeFillingUp 경고가 트리거되는 문제를 해결할 수 있습니다.

openshift-monitoring 프로젝트의 prometheus-k8s-* Pod에서 클레임한 PV(영구 볼륨)가 남아 있는 총 공간이 3% 미만인 경우 발생합니다. 이로 인해 Prometheus가 비정상적으로 작동할 수 있습니다.

참고

KubePersistentVolumeFillingUp 경고 두 가지가 있습니다.

  • critical alert: mounted PV의 총 공간이 3% 미만이면 severity="critical" 라벨이 있는 경고가 트리거됩니다.
  • 경고 경고: mounted PV의 총 공간이 15 % 미만이고 4 일 이내에 채울 것으로 예상되는 경우 severity="warning" 라벨이 있는 경고가 트리거됩니다.

이 문제를 해결하려면 Prometheus TSDB(time-series database) 블록을 제거하여 PV에 더 많은 공간을 생성할 수 있습니다.

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 다음 명령을 실행하여 가장 오래된 것에서 최신으로 정렬된 모든 TSDB 블록의 크기를 나열합니다.

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
    -c prometheus --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'cd /prometheus/;du -hs $(ls -dt */ | grep -Eo "[0-9|A-Z]{26}")'
    1 2
    & lt;prometheus_k8s_pod_name >을 KubePersistentVolumeFillingUp 경고 설명에 언급된 Pod로 바꿉니다.

    출력 예

    308M    01HVKMPKQWZYWS8WVDAYQHNMW6
    52M     01HVK64DTDA81799TBR9QDECEZ
    102M    01HVK64DS7TRZRWF2756KHST5X
    140M    01HVJS59K11FBVAPVY57K88Z11
    90M     01HVH2A5Z58SKT810EM6B9AT50
    152M    01HV8ZDVQMX41MKCN84S32RRZ1
    354M    01HV6Q2N26BK63G4RYTST71FBF
    156M    01HV664H9J9Z1FTZD73RD1563E
    216M    01HTHXB60A7F239HN7S2TENPNS
    104M    01HTHMGRXGS0WXA3WATRXHR36B

  2. 제거할 수 있는 블록 수와 블록을 확인한 다음 블록을 제거합니다. 다음 예제 명령은 prometheus-k8s-0 Pod에서 가장 오래된 세 가지 Prometheus TSDB 블록을 제거합니다.

    $ oc debug prometheus-k8s-0 -n openshift-monitoring \
    -c prometheus --image=$(oc get po -n openshift-monitoring prometheus-k8s-0 \
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') \
    -- sh -c 'ls -latr /prometheus/ | egrep -o "[0-9|A-Z]{26}" | head -3 | \
    while read BLOCK; do rm -r /prometheus/$BLOCK; done'
  3. 마운트된 PV의 사용량을 확인하고 다음 명령을 실행하여 사용 가능한 공간이 충분한지 확인합니다.

    $ oc debug <prometheus_k8s_pod_name> -n openshift-monitoring \1
    --image=$(oc get po -n openshift-monitoring <prometheus_k8s_pod_name> \2
    -o jsonpath='{.spec.containers[?(@.name=="prometheus")].image}') -- df -h /prometheus/
    1 2
    & lt;prometheus_k8s_pod_name >을 KubePersistentVolumeFillingUp 경고 설명에 언급된 Pod로 바꿉니다.

    다음 예제 출력에서는 prometheus-k8s-0 Pod에서 클레임한 마운트된 PV가 남아 있는 공간의 63%를 보여줍니다.

    출력 예

    Starting pod/prometheus-k8s-0-debug-j82w4 ...
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme0n1p4  40G   15G  40G  37% /prometheus
    
    Removing debug pod ...

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.