8장. 모니터링 문제 조사
8.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
app
라벨이 이전 단계의 라벨 출력과 일치하는지 확인합니다.$ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
출력 예
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
Prometheus UI에서 프로젝트의 대상 상태를 직접 확인하십시오.
openshift-user-workload-monitoring
프로젝트에서 Prometheus 인스턴스에 대한 포트 전달을 설정합니다.$ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090
- 웹 브라우저에서 http://localhost:9090/targets을 열고 Prometheus UI에서 직접 프로젝트의 대상 상태를 확인합니다. 대상과 관련된 오류 메시지를 확인합니다.
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
리소스를 만드는 방법에 대한 자세한 내용은 서비스 모니터링 방법 지정에서 참조하십시오.