모니터링

프로세스

1. OpenShift Cluster Manager Hybrid Cloud Console에서 클러스터를 선택합니다.
2. 설정 탭을 클릭합니다.

3. 사용자 워크로드 모니터링 활성화 확인란을 클릭하여 옵션을 선택 해제한 다음 저장을 클릭합니다.

   사용자 워크로드 모니터링이 비활성화됩니다. Prometheus, Prometheus Operator 및 Thanos Ruler 구성 요소는 openshift-user-workload-monitoring 프로젝트에서 중지됩니다.

프로세스

1. 프로젝트 네임스페이스에 라벨을 추가합니다.

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. 모니터링을 다시 활성화하려면 네임스페이스에서 라벨을 제거합니다.

   $ oc label namespace my-project 'openshift.io/user-monitoring-'

   참고

   프로젝트에 대한 활성 모니터링 대상이 있는 경우 레이블을 추가한 후 Prometheus가 스크랩을 중지하는 데 몇 분이 걸릴 수 있습니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml 필드 아래에 다음 설정을 추가하여 Pod 토폴로지 분배 제약 조건을 구성합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 

   1

   
         topologySpreadConstraints:
         - maxSkew: <n> 

   2

   
           topologyKey: <key> 

   3

   
           whenUnsatisfiable: <value> 

   4

   
           labelSelector: 

   5

   
             <match_option>

   1

   Pod 토폴로지 분배 제약 조건을 설정할 구성 요소의 이름을 지정합니다.

   2

   maxSkew 에 대한 숫자 값을 지정합니다. 이 값은 균등하게 분배될 수 있는 Pod를 정의합니다.

   3

   topologyKey의 노드 라벨 키를 지정합니다. 이 키와 동일한 값이 있는 라벨이 있는 노드는 동일한 토폴로지에 있는 것으로 간주됩니다. 스케줄러는 균형 잡힌 수의 pod를 각 도메인에 배치하려고 합니다.

   4

   whenUnsatisfiable 의 값을 지정합니다. 사용 가능한 옵션은 DoNotSchedule 및 ScheduleAnyway 입니다. maxSkew 값을 사용하여 대상 토폴로지의 일치하는 Pod 수와 글로벌 최소값 간에 허용되는 최대 차이를 정의하도록 DoNotSchedule 을 지정합니다. 스케줄러에서 Pod를 계속 예약하지만 불일치를 줄일 수 있는 노드에 더 높은 우선 순위를 부여하려면 ScheduleAnyway 를 지정합니다.

   5

   일치하는 포드를 찾으려면 labelSelector 를 지정합니다. 이 라벨 선택기와 일치하는 Pod는 해당 토폴로지 도메인의 Pod 수를 확인하기 위해 계산됩니다.

   Thanos Ruler 구성 예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: monitoring
           whenUnsatisfiable: ScheduleAnyway
           labelSelector:
             matchLabels:
               app.kubernetes.io/name: thanos-ruler

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml 아래에 보존 시간 및 크기 구성을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         retention: <time_specification> 

   1

   
         retentionSize: <size_specification> 

   2

   1

   보존 시간: ms (밀리초), s (초), m (분), h (시간), d (일), w (주) 또는 y (년)가 직접 따르는 번호입니다. 1h30m15s 와 같은 특정 시간 동안 시간 값을 결합할 수도 있습니다.

   2

   보존 크기: 숫자 바로 뒤에 B (bytes), KB (kilobytes), MB (megabytes), GB (gigabytes), TB (terabytes), PB (petabytes), EB (exabytes)가 옵니다.

   다음 예제에서는 보존 시간을 24시간으로 설정하고 Prometheus 인스턴스의 보존 크기를 10GB로 설정합니다.

   Prometheus의 보존 시간 설정 예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         retention: 24h
         retentionSize: 10GB

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml 아래에 구성 요소의 로그 구성을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 

   1

   
         logLevel: <log_level> 

   2

   
       # ...

   1

   로그 수준을 설정하는 모니터링 스택 구성 요소를 지정합니다. 사용 가능한 구성 요소 값은 prometheus,alertmanager,prometheusOperator, thanosRuler 입니다.

   2

   구성 요소의 로그 수준을 지정합니다. 사용 가능한 값은 error,warn,info, debug 입니다. 기본값은 info 입니다.

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

4. 관련 프로젝트의 배포 또는 Pod 구성을 검토하여 로그 구성이 적용되었는지 확인합니다.

   • 다음 예제에서는 prometheus-operator 배포의 로그 수준을 확인합니다.

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

     출력 예

             - --log-level=debug

5. 구성 요소의 Pod가 실행 중인지 확인합니다.

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

   참고

   인식할 수 없는 logLevel 값이 ConfigMap 오브젝트에 포함된 경우 구성 요소의 Pod가 다시 시작되지 않을 수 있습니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml:에서 Prometheus의 queryLogFile 매개변수를 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         queryLogFile: <path> 

   1

   1

   쿼리가 기록될 파일의 전체 경로를 추가합니다.

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

4. 구성 요소의 포드가 실행 중인지 확인합니다. 다음 샘플 명령은 Pod 상태를 나열합니다.

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

   출력 예

   ...
   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
   ...

5. 쿼리 로그를 읽습니다.

   $ oc -n openshift-user-workload-monitoring exec prometheus-user-workload-0 -- cat <path>

   중요

   기록된 쿼리 정보를 검사한 후 구성 맵에서 설정을 되돌립니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 다음 예와 같이 data/config.yaml/prometheus 에 remoteWrite: 섹션을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com" 

   1

   
           <endpoint_authentication_credentials> 

   2

   1

   원격 쓰기 엔드 포인트의 URL입니다.

   2

   엔드 포인트의 인증 방법 및 자격 증명입니다. 현재 지원되는 인증 방법은 AWS Signature Version 4입니다. 인증 요청 헤더에서 HTTP를 사용한 Authorization, 기본 인증, OAuth 2.0 및 TLS 클라이언트입니다. 지원되는 인증 방법에 대한 샘플 구성은 지원되는 원격 쓰기 인증 설정을 참조하세요.

3. 인증 정보 뒤에 쓰기 재레이블 구성 값을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           <endpoint_authentication_credentials>
           writeRelabelConfigs:
           - <your_write_relabel_configs> 

   1

   1

   원격 엔드포인트에 보낼 메트릭에 대한 구성을 추가합니다.

   my_metric이라는 단일 메트릭 전달 예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           writeRelabelConfigs:
           - sourceLabels: [__name__]
             regex: 'my_metric'
             action: keep

   my_namespace 네임스페이스에서 my_metric_1 및 my_metric_2 라는 전달 메트릭의 예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           writeRelabelConfigs:
           - sourceLabels: [__name__,namespace]
             regex: '(my_metric_1|my_metric_2);my_namespace'
             action: keep

4. 파일을 저장하여 변경 사항을 적용합니다. 새 구성이 자동으로 적용됩니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml/prometheus/remoteWrite 의 writeRelabelConfigs: 섹션에서 클러스터 ID 재레이블 구성 값을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           <endpoint_authentication_credentials>
           writeRelabelConfigs: 

   1

   
             - <relabel_config> 

   2

   1

   원격 끝점에 보낼 지표의 쓰기 재라벨 구성 목록을 추가합니다.

   2 2

   원격 쓰기 엔드포인트로 전송된 지표의 레이블 구성을 대체합니다.

   다음 샘플은 클러스터 ID 레이블 cluster_id 를 사용하여 메트릭을 전달하는 방법을 보여줍니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           writeRelabelConfigs:
           - sourceLabels:
             - __tmp_openshift_cluster_id__ 

   1

   
             targetLabel: cluster_id 

   2

   
             action: replace 

   3

   3

   처음에 시스템은 __tmp_openshift_cluster_id___라는 임시 클러스터 ID 소스 레이블을 적용합니다. 이 임시 레이블은 지정한 클러스터 ID 레이블 이름으로 교체됩니다.

   원격 쓰기 스토리지로 전송되는 지표의 클러스터 ID 레이블 이름을 지정합니다. 메트릭에 이미 존재하는 라벨 이름을 사용하는 경우 해당 값을 이 클러스터 ID 레이블의 이름으로 덮어씁니다. 레이블 이름의 경우 __tmp_openshift_cluster_id__ 를 사용하지 마십시오. 최종 레이블 재지정 단계에서 이 이름을 사용하는 라벨이 제거됩니다.

   replace write relabel 작업은 임시 레이블을 발신 지표의 target 레이블로 대체합니다. 이 작업은 기본값이며 작업이 지정되지 않은 경우 적용됩니다.

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성이 자동으로 적용됩니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml/<component> 아래에 구성 세부 정보가 포함된 추가 AlertmanagerConfigs 섹션을 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       <component>: 

   1

   
         additionalAlertmanagerConfigs:
         - <alertmanager_specification> 

   2

   2

   추가 Alertmanager 인스턴스의 경우 < alertmanager_specification >을 인증 및 기타 구성 세부 정보로 바꿉니다. 현재 지원되는 인증 방법은 베어러 토큰 (bearerToken) 및 클라이언트 TLS (tlsConfig)입니다.

   1

   지원되는 외부 Alertmanager 구성 요소인 prometheus 또는 thanosRuler 두 가지로 <component >를 바꿉니다.

   다음 샘플 구성 맵은 클라이언트 TLS 인증이 있는 전달자 토큰을 사용하여 Thanos Ruler에 대한 추가 Alertmanager를 구성합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         additionalAlertmanagerConfigs:
         - scheme: https
           pathPrefix: /
           timeout: "30s"
           apiVersion: v1
           bearerToken:
             name: alertmanager-bearer-token
             key: token
           tlsConfig:
             key:
               name: alertmanager-tls
               key: tls.key
             cert:
               name: alertmanager-tls
               key: tls.crt
             ca:
               name: alertmanager-tls
               key: tls.ca
           staticConfigs:
           - external-alertmanager1-remote.com
           - external-alertmanager1-remote2.com

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

프로세스

1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config 구성 맵을 편집합니다.

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. data/config.yaml 아래에 모든 메트릭에 대해 추가하려는 레이블을 정의합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         externalLabels:
           <key>: <value> 

   1

   1

   < key>: <value >를 키-값 쌍으로 바꿉니다. 여기서 < key >는 새 레이블의 고유한 이름이며 < value >는 해당 값입니다.

   주의

   • prometheus 또는 prometheus_replica를 키 이름으로 사용하지 마십시오. 예약되어 있으며 덮어쓸 예정이기 때문입니다.
   • 클러스터를 키 이름으로 사용하지 마십시오. 이를 사용하면 개발자 대시보드에서 데이터를 볼 수 없는 문제가 발생할 수 있습니다.

   참고

   openshift-user-workload-monitoring 프로젝트에서 Prometheus는 메트릭을 처리하고 Thanos Ruler는 경고 및 레코딩 규칙을 처리합니다. user-workload-monitoring-config ConfigMap 오브젝트에서 prometheus에 대한 externalLabels를 설정하면 규칙에는 적용되지 않고 메트릭에 대한 외부 라벨만 구성됩니다.

   예를 들어 모든 시계열 및 경고에 리전 및 환경에 대한 메타데이터를 추가하려면 다음 예제를 사용합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         externalLabels:
           region: eu
           environment: prod

3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 재배포됩니다.

프로세스

1. OpenShift Dedicated 웹 콘솔에서 모니터링 → 메트릭 을 클릭합니다.

2. 하나 이상의 쿼리를 추가하려면 다음 작업을 수행합니다.

   Expand

   옵션	설명
   기존 쿼리를 선택합니다.	쿼리 선택 드롭다운 목록에서 기존 쿼리를 선택합니다.
   사용자 지정 쿼리를 생성합니다.	표현식 필드에 PromQL(Prometheus Query Language) 쿼리를 추가합니다. PromQL 표현식을 입력하면 자동 완성 제안이 드롭다운 목록에 표시됩니다. 이러한 제안에는 함수, 메트릭, 라벨 및 시간 토큰이 포함됩니다. 키보드 화살표를 사용하여 제안된 항목 중 하나를 선택한 다음 Enter를 눌러 표현식에 항목을 추가합니다. 해당 항목에 대한 간략한 설명을 보려면 제안된 항목 위에 마우스 포인터를 이동합니다.
   여러 쿼리를 추가합니다.	쿼리 추가를 클릭합니다.
   기존 쿼리를 복제합니다.	쿼리 옆에 있는 옵션 메뉴 를 클릭한 다음 쿼리 중복 을 선택합니다.
   쿼리가 실행되지 않도록 비활성화합니다.	쿼리 옆에 있는 옵션 메뉴 를 클릭하고 쿼리 비활성화 를 선택합니다.

   Show more

3. 생성한 쿼리를 실행하려면 쿼리 실행을 클릭합니다. 쿼리의 메트릭은 플롯에 시각화됩니다. 쿼리가 유효하지 않으면 UI에 오류 메시지가 표시됩니다.

   참고
   • 시계열 그래프를 그릴 때 대량의 데이터를 처리하는 쿼리는 시간 초과되거나 브라우저에 과부하가 걸릴 수 있습니다. 이를 방지하려면 그래프 숨기기 를 클릭하고 메트릭 테이블만 사용하여 쿼리를 조정합니다. 그런 다음 실행 가능한 쿼리를 검색한 후 플롯을 활성화하여 그래프를 그립니다.
   • 기본적으로 쿼리 테이블은 모든 메트릭과 해당 현재 값을 나열하는 확장된 보기를 표시합니다. 쿼리의 확장된 보기를 최소화하려면 ˅ 아래쪽 화살표를 클릭하세요.
4. 선택 사항: 페이지 URL을 저장하여 나중에 이 쿼리 세트를 다시 사용합니다.

5. 시각화된 메트릭을 살펴봅니다. 처음에 활성화된 모든 쿼리의 모든 메트릭이 플롯에 표시됩니다. 다음 작업을 수행하여 표시되는 메트릭을 선택합니다.

   Expand

   옵션	설명
   쿼리에서 모든 메트릭을 숨깁니다.	쿼리의 옵션 메뉴 를 클릭하고 모든 시리즈 숨기기 를 클릭합니다.
   특정 메트릭을 숨깁니다.	쿼리 테이블로 이동하여 메트릭 이름 옆에 있는 색상이 지정된 사각형을 클릭합니다.
   플롯으로 확대하고 시간 범위를 변경합니다.	다음 작업 중 하나를 수행합니다. 수평으로 플롯을 클릭하고 드래그하여 시간 범위를 시각적으로 선택합니다. 메뉴를 사용하여 시간 범위를 선택합니다.
   시간 범위를 재설정합니다.	확대/축소 재설정 을 클릭합니다.
   특정 시점에서 모든 쿼리에 대한 출력을 표시합니다.	관심 있는 시점에서 플롯 위로 마우스를 놓습니다. 쿼리 출력이 팝업 상자에 나타납니다.
   플롯을 숨깁니다.	그래프 숨기기를 클릭합니다.

   Show more

프로세스

1. OpenShift Dedicated 웹 콘솔에서 모니터링 → 대상으로 이동합니다. 지표 대상 페이지가 열리고 메트릭에 대해 스크랩되는 모든 서비스 끝점 대상 목록이 표시됩니다.

   이 페이지에는 기본 OpenShift Dedicated 및 사용자 정의 프로젝트의 대상에 대한 세부 정보가 표시됩니다. 이 페이지에는 각 대상에 대한 다음 정보가 나열됩니다.

   • 스크랩되는 서비스 끝점 URL
   • 모니터링 중인 ServiceMonitor 리소스
   • 대상의 up 또는 down 상태
   • 네임스페이스
   • 마지막 스크랩 시간
   • 마지막 스크랩의 기간

2. 선택 사항: 특정 대상을 찾으려면 다음 작업을 수행합니다.

   Expand

   옵션	설명
   대상 상태를 상태 및 소스로 필터링합니다.	필터 목록에서 필터 를 선택합니다. 다음 필터링 옵션을 사용할 수 있습니다. 상태 필터: Up. 현재 대상이 활성화되어 있고 메트릭에 대해 적극적으로 스크랩되고 있습니다. Down. 메트릭에 대한 대상이 현재 다운되어 있지 않습니다. 소스 필터: 플랫폼. 플랫폼 수준 대상은 AWS 프로젝트의 기본 Red Hat OpenShift Service에만 관련이 있습니다. 이러한 프로젝트는 AWS 기능에 핵심 Red Hat OpenShift Service를 제공합니다. 사용자 사용자 대상은 사용자 정의 프로젝트와 관련이 있습니다. 이러한 프로젝트는 사용자가 생성하며 사용자 정의할 수 있습니다.
   이름 또는 레이블로 대상을 검색합니다.	검색 상자 옆에 있는 텍스트 또는 레이블 필드에 검색어를 입력합니다.
   대상을 정렬합니다.	Endpoint Status,Namespace,Last Scrape 및 Scrape Duration 열 헤더 중 하나 이상을 클릭합니다.

   Show more

3. 대상의 끝점 열에서 URL을 클릭하여 대상 세부 정보 페이지로 이동합니다. 이 페이지에서는 다음 정보를 포함하여 대상에 대한 정보를 제공합니다.

   • 메트릭을 스크랩하는 끝점 URL
   • 대상의 현재 Up 또는 Down 상태
   • 네임스페이스에 대한 링크
   • ServiceMonitor 리소스 세부 정보 링크
   • 대상에 연결된 라벨
   • 지표에 대해 대상이 스크랩된 가장 최근의 시간

프로세스

1. OpenShift Dedicated 웹 콘솔에서 모니터링 → 대시보드 로 이동합니다.
2. 대시보드 목록에서 대시보드를 선택합니다. etcd 및 Prometheus 대시보드와 같은 일부 대시보드는 선택하면 추가 하위 메뉴가 생성됩니다.

3. 선택 사항: 시간 범위 목록에서 그래프의 시간 범위를 선택합니다.

   • 사전 정의된 기간을 선택합니다.

   • 시간 범위 목록에서 사용자 지정 시간 범위를 클릭하여 사용자 지정 시간 범위를 설정합니다.

     1. 시작 및 종료 날짜 및 시간을 입력하거나 선택합니다.
     2. 저장을 클릭하여 사용자 지정 시간 범위를 저장합니다.
4. 선택 사항: 새로 고침 간격을 선택합니다.
5. 대시보드 내에서 각각의 그래프로 마우스를 이동하여 특정 항목에 대한 세부 정보를 표시합니다.

프로세스

1. OpenShift Dedicated 웹 콘솔에서 모니터링 → 메트릭 을 클릭합니다.

2. 하나 이상의 쿼리를 추가하려면 다음 작업을 수행합니다.

   Expand

   옵션	설명
   기존 쿼리를 선택합니다.	쿼리 선택 드롭다운 목록에서 기존 쿼리를 선택합니다.
   사용자 지정 쿼리를 생성합니다.	표현식 필드에 PromQL(Prometheus Query Language) 쿼리를 추가합니다. PromQL 표현식을 입력하면 자동 완성 제안이 드롭다운 목록에 표시됩니다. 이러한 제안에는 함수, 메트릭, 라벨 및 시간 토큰이 포함됩니다. 키보드 화살표를 사용하여 제안된 항목 중 하나를 선택한 다음 Enter를 눌러 표현식에 항목을 추가합니다. 해당 항목에 대한 간략한 설명을 보려면 제안된 항목 위에 마우스 포인터를 이동합니다.
   여러 쿼리를 추가합니다.	쿼리 추가를 클릭합니다.
   기존 쿼리를 복제합니다.	쿼리 옆에 있는 옵션 메뉴 를 클릭한 다음 쿼리 중복 을 선택합니다.
   쿼리가 실행되지 않도록 비활성화합니다.	쿼리 옆에 있는 옵션 메뉴 를 클릭하고 쿼리 비활성화 를 선택합니다.

   Show more

3. 생성한 쿼리를 실행하려면 쿼리 실행을 클릭합니다. 쿼리의 메트릭은 플롯에 시각화됩니다. 쿼리가 유효하지 않으면 UI에 오류 메시지가 표시됩니다.

   참고
   • 시계열 그래프를 그릴 때 대량의 데이터를 처리하는 쿼리는 시간 초과되거나 브라우저에 과부하가 걸릴 수 있습니다. 이를 방지하려면 그래프 숨기기 를 클릭하고 메트릭 테이블만 사용하여 쿼리를 조정합니다. 그런 다음 실행 가능한 쿼리를 검색한 후 플롯을 활성화하여 그래프를 그립니다.
   • 기본적으로 쿼리 테이블은 모든 메트릭과 해당 현재 값을 나열하는 확장된 보기를 표시합니다. 쿼리의 확장된 보기를 최소화하려면 ˅ 아래쪽 화살표를 클릭하세요.
4. 선택 사항: 페이지 URL을 저장하여 나중에 이 쿼리 세트를 다시 사용합니다.

5. 시각화된 메트릭을 살펴봅니다. 처음에 활성화된 모든 쿼리의 모든 메트릭이 플롯에 표시됩니다. 다음 작업을 수행하여 표시되는 메트릭을 선택합니다.

   Expand

   옵션	설명
   쿼리에서 모든 메트릭을 숨깁니다.	쿼리의 옵션 메뉴 를 클릭하고 모든 시리즈 숨기기 를 클릭합니다.
   특정 메트릭을 숨깁니다.	쿼리 테이블로 이동하여 메트릭 이름 옆에 있는 색상이 지정된 사각형을 클릭합니다.
   플롯으로 확대하고 시간 범위를 변경합니다.	다음 작업 중 하나를 수행합니다. 수평으로 플롯을 클릭하고 드래그하여 시간 범위를 시각적으로 선택합니다. 메뉴를 사용하여 시간 범위를 선택합니다.
   시간 범위를 재설정합니다.	확대/축소 재설정 을 클릭합니다.
   특정 시점에서 모든 쿼리에 대한 출력을 표시합니다.	관심 있는 시점에서 플롯 위로 마우스를 놓습니다. 쿼리 출력이 팝업 상자에 나타납니다.
   플롯을 숨깁니다.	그래프 숨기기를 클릭합니다.

   Show more

프로세스

1. OpenShift Dedicated 웹 콘솔의 개발자 화면에서 모니터링 을 클릭하고 대시보드 탭으로 이동합니다.
2. 프로젝트: 드롭다운 목록에서 프로젝트를 선택합니다.
3. 대시보드 드롭다운 목록에서 대시보드 를 선택하여 필터링된 지표를 확인합니다.

4. 선택 사항: 시간 범위 목록에서 그래프의 시간 범위를 선택합니다.

   • 사전 정의된 기간을 선택합니다.

   • 시간 범위 목록에서 사용자 지정 시간 범위를 클릭하여 사용자 지정 시간 범위를 설정합니다.

     1. 시작 및 종료 날짜 및 시간을 입력하거나 선택합니다.
     2. 저장을 클릭하여 사용자 지정 시간 범위를 저장합니다.
5. 선택 사항: 새로 고침 간격을 선택합니다.
6. 대시보드 내에서 각각의 그래프로 마우스를 이동하여 특정 항목에 대한 세부 정보를 표시합니다.

프로세스

1. 다음 명령을 실행하여 인증 토큰을 추출합니다.

   $ TOKEN=$(oc whoami -t)

2. 다음 명령을 실행하여 alertmanager-main API 경로 URL을 추출합니다.

   $ HOST=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath='{.status.ingress[].host}')

3. 다음 명령을 실행하여 Alertmanager의 서비스 API 수신자를 쿼리합니다.

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v2/receivers"

프로세스

1. 다음 명령을 실행하여 전달자 토큰을 검색합니다.

   $ TOKEN=$(oc whoami -t)

2. 다음 명령을 실행하여 Prometheus 페더레이션 경로 URL을 가져옵니다.

   $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s-federate -ojsonpath='{.status.ingress[].host}')

3. /federate 경로에서 메트릭을 쿼리합니다. 다음 예제 명령은 메트릭 을 쿼리합니다.

   $ curl -G -k -H "Authorization: Bearer $TOKEN" https://$HOST/federate --data-urlencode 'match[]=up'

   출력 예

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

프로세스

1. 다음 명령을 실행하여 Prometheus에 연결할 인증 토큰을 추출합니다.

   $ TOKEN=$(oc whoami -t)

2. 다음 명령을 실행하여 thanos-querier API 경로 URL을 추출합니다.

   $ HOST=$(oc -n openshift-monitoring get route thanos-querier -ojsonpath='{.status.ingress[].host}')

3. 다음 명령을 사용하여 네임스페이스를 서비스가 실행 중인 네임스페이스로 설정합니다.

   $ NAMESPACE=ns1

4. 다음 명령을 실행하여 명령줄에서 자체 서비스의 메트릭을 쿼리합니다.

   $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}"

   출력에는 Prometheus가 스크랩하는 각 애플리케이션 Pod의 상태가 표시됩니다.

   포맷된 예제 출력

   {
     "status": "success",
     "data": {
       "resultType": "vector",
       "result": [
         {
           "metric": {
             "__name__": "up",
             "endpoint": "web",
             "instance": "10.129.0.46:8080",
             "job": "prometheus-example-app",
             "namespace": "ns1",
             "pod": "prometheus-example-app-68d47c4fb6-jztp2",
             "service": "prometheus-example-app"
           },
           "value": [
             1591881154.748,
             "1"
           ]
         }
       ],
     }
   }

   참고
   • 포맷된 예제 출력에서는 jq 와 같은 필터링 툴을 사용하여 형식이 지정된 JSON을 제공합니다. jq 사용에 대한 자세한 내용은 jq Manual (jq 문서)을 참조하세요.
   • 이 명령은 Thanos Querier 서비스의 즉각적인 쿼리 끝점을 요청하여 한 번에 선택기를 평가합니다.