15장. 모니터링 문제 조사
15.1. 사용자 정의 메트릭을 사용할 수 없는 이유 확인
ServiceMonitor
리소스를 사용하면 사용자 정의 프로젝트에서 서비스에 의해 노출되는 메트릭을 사용하는 방법을 확인할 수 있습니다. ServiceMonitor
리소스를 생성했지만 메트릭 UI에서 해당 메트릭을볼 수 없는 경우 이 프로세스에 설명된 단계를 수행하십시오.
사전 요구 사항
-
cluster-admin
클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다. - 사용자 정의 워크로드에 대한 모니터링을 활성화 및 구성하고 있어야 합니다.
-
user-workload-monitoring-config
ConfigMap
오브젝트가 생성되어 있습니다. -
ServiceMonitor
리소스가 생성되어 있습니다.
프로세스
서비스 및
ServiceMonitor
리소스 구성에서 해당 라벨이 일치하는지 확인합니다.서비스에 정의된 라벨을 가져옵니다. 다음 예제에서는
ns1
프로젝트의prometheus-example-app
서비스를 쿼리합니다.$ oc -n ns1 get service prometheus-example-app -o yaml
출력 예
labels: app: prometheus-example-app
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
리소스 라벨을 확인할 수 있습니다.
openshift-user-workload-monitoring
프로젝트에서 Prometheus Operator의 로그를 검사합니다.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
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
OpenShift Container Platform 웹 콘솔 UI의 지표 대상 페이지에서 끝점의 대상 상태를 확인합니다.
-
OpenShift Container Platform 웹 콘솔에 로그인하고 관리자 관점에서 Observe
Targets 로 이동합니다. - 목록에서 지표 엔드포인트를 찾고 Status 열에서 대상의 상태를 검토합니다.
- Status 가 Down 이면 엔드포인트의 URL을 클릭하여 해당 지표 대상의 대상 세부 정보 페이지에 대한 자세한 정보를 확인합니다.
-
OpenShift Container Platform 웹 콘솔에 로그인하고 관리자 관점에서 Observe
openshift-user-workload-monitoring
프로젝트에서 Prometheus Operator의 디버그 수준 로깅을 구성합니다.openshift-user-workload-monitoring
프로젝트에서user-workload-monitoring-config
ConfigMap
오브젝트를 편집합니다.$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
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 # ...
파일을 저장하여 변경 사항을 적용합니다.
참고openshift-user-workload-monitoring
프로젝트의prometheus-operator
는 로그 수준 변경을 적용하면 자동으로 다시 시작됩니다.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가 수행한 모든 호출을 표시합니다.
prometheus-operator
Pod가 실행되고 있는지 확인합니다.$ oc -n openshift-user-workload-monitoring get pods
참고구성 맵에 인식할 수 없는 Prometheus Operator
loglevel
값이 포함된 경우prometheus-operator
Pod가 재시작되지 않을 수 있습니다.-
디버그 로그를 검토하여 Prometheus Operator에서
ServiceMonitor
리소스를 사용하고 있는지 확인합니다. 기타 관련 오류에 대한 로그를 확인합니다.
추가 리소스
- 사용자 정의 워크로드 모니터링 구성 맵 생성
-
ServiceMonitor
또는PodMonitor
리소스 를 생성하는 방법에 대한 자세한 내용은 서비스 모니터링 방법 지정 에서 참조하십시오. - 관리자 관점에서 메트릭 대상 액세스를참조하십시오.