7.11. 모니터링 문제 조사


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

자체 메트릭을 사용할 수 없거나 Prometheus가 많은 디스크 공간을 사용하는 경우 다음 단계를 수행할 수 있습니다.

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

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

사전 요구 사항

  • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 사용자 정의 워크로드에 대한 모니터링을 활성화 및 구성하고 있어야 합니다.
  • user-workload-monitoring-config ConfigMap 오브젝트가 생성되어 있습니다.
  • 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 app 라벨이 이전 단계의 라벨 출력과 일치하는지 확인합니다.

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

      출력 예

      apiVersion: v1
      kind: Service
      # ...
      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의 Metrics 대상 페이지에서 끝점의 대상 상태를 확인합니다.

    1. OpenShift Container Platform 웹 콘솔에 로그인하고 관리자 관점에서 Observe → 대상으로 이동합니다.
    2. 목록에서 지표 엔드포인트를 찾고 Status 열에서 대상의 상태를 검토합니다.
    3. StatusDown 이면 끝점의 URL을 클릭하여 해당 메트릭 대상의 Target Details 페이지에서 자세한 정보를 확인합니다.
  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. 파일을 저장하여 변경 사항을 적용합니다.

      참고

      openshift-user-workload-monitoring 프로젝트의 prometheus-operator는 로그 수준 변경을 적용하면 자동으로 다시 시작됩니다.

    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 필드에서 다음 Prometheus Query Language (PromQL) 쿼리를 실행합니다. 이렇게 하면 스크랩 샘플 수가 가장 많은 10개의 메트릭이 반환됩니다.

    topk(10,count by (job)({__name__=~".+"}))
  3. 예상 스크랩 샘플 수 보다 많은 메트릭에 할당된 바인딩되지 않은 라벨 값의 수를 조사합니다.

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

    $ oc login -u <username> -p <password>
    $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})
    $ token=$(oc whoami -t)
    $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

    출력 예

    "status": "success",

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.