7.11. 모니터링 문제 조사

절차

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. Status 가 Down 이면 엔드포인트의 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. prometheusOperator의 logLevel:debug를 data / 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 리소스를 사용하고 있는지 확인합니다. 기타 관련 오류에 대한 로그를 확인합니다.

절차

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={.spec.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},
      ...