프로세스

1. ConfigMap 오브젝트를 편집합니다.

   1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

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

   2. data.config.yaml 아래의 구성을 키-값 쌍 < component_name>: <component_configuration >으로 추가합니다.

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

      이에 따라 <component> 및 <configuration_for_the_component>를 바꿉니다.

      다음 예제 ConfigMap 오브젝트는 Prometheus에 대한 데이터 보존 기간 및 최소 컨테이너 리소스 요청을 구성합니다. 이는 사용자 정의 프로젝트만 모니터링하는 Prometheus 인스턴스와 관련이 있습니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheus: 1
            retention: 24h 2
            resources:
              requests:
                cpu: 200m 3
                memory: 2Gi 4

      1

      Prometheus 구성 요소를 정의하면 후속 행은 해당 구성을 정의합니다.

      2

      사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스에 대해 24시간 데이터 보존 기간을 구성합니다.

      3

      Prometheus 컨테이너에 대한 200밀리코어의 최소 리소스 요청을 정의합니다.

      4

      Prometheus 컨테이너에 대한 메모리 2GiB의 최소 Pod 리소스 요청을 정의합니다.

2. 파일을 저장하여 ConfigMap 오브젝트에 대한 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작됩니다.

   주의

   모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.

절차

1. 사용자 정의 프로젝트를 모니터링하는 구성 요소를 이동하려면 ConfigMap 오브젝트를 편집합니다.

   1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

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

   2. data.config.yaml 에서 구성 요소에 대한 nodeSelector 제약 조건을 지정합니다.

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

      이에 따라 <component>를 바꾸고 <node_key>: <node_value>를 대상 노드를 지정하는 키-값 쌍의 맵으로 바꿉니다. 종종 단일 키-값 쌍만 사용됩니다.

      구성 요소는 각 지정된 키-값 쌍을 라벨로 갖는 노드에서만 실행할 수 있습니다. 노드에도 추가 라벨이 있을 수 있습니다.

      중요

      대부분의 모니터링 구성 요소는 클러스터의 다른 노드에서 여러 Pod를 사용하여 고가용성을 유지함으로써 배포됩니다. 모니터링 구성 요소를 라벨된 노드로 이동할 때 구성 요소의 탄력성을 유지하기 위해 일치하는 노드를 사용할 수 있는지 확인합니다. 하나의 라벨만 지정된 경우 별도의 노드 간에 구성 요소에 대한 모든 Pod를 배포할 수 있는 충분한 노드에 해당 라벨이 포함되어 있는지 확인합니다. 또는 개별 노드와 관련된 각 라벨을 여러 개 지정할 수 있습니다.

      참고

      nodeSelector 제약 조건을 구성한 후 모니터링 구성 요소가 Pending 상태인 경우 테인트(Taints) 및 톨러레이션(Tolerations)과 관련된 오류에 대한 Pod 로그를 확인합니다.

      예를 들어 사용자 정의 프로젝트의 구성 요소를 nodename: worker1, nodename: worker2 및 nodename: worker2의 라벨이 지정된 특정 작업자 노드로 이동하려면 다음을 사용합니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            nodeSelector:
              nodename: worker1
          prometheus:
            nodeSelector:
              nodename: worker1
              nodename: worker2
          thanosRuler:
            nodeSelector:
              nodename: worker1
              nodename: worker2

2. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 구성 요소는 새 노드로 자동 이동됩니다.

   주의

   모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.

절차

1. ConfigMap 오브젝트를 편집합니다.

   1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

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

   2. 구성 요소에 대한 tolerations를 지정합니다.

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

      이에 따라 <component> 및 <toleration_specification>을 바꿉니다.

      예를 들어 oc adm taint nodes node1 key1=value1:NoSchedule은 key1의 키와 value1의 값이 있는 node1에 테인트를 추가합니다. 이렇게 하면 해당 테인트에 허용 오차가 구성되지 않는 한 node1에 모니터링 구성 요소가 배포되지 않습니다. 다음 예제는 예제 테인트를 허용하도록 thanosRuler 구성 요소를 구성합니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          thanosRuler:
            tolerations:
            - key: "key1"
              operator: "Equal"
              value: "value1"
              effect: "NoSchedule"

2. 파일을 저장하여 변경 사항을 적용합니다. 새로운 구성 요소 배치 구성이 자동으로 적용됩니다.

   주의

   모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.

프로세스

1. ConfigMap 오브젝트를 편집합니다.

   1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

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

   2. data.config.yaml 아래의 구성 요소에 logLevel: <log_level >을 추가합니다.

      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

      로그 수준을 적용하려는 모니터링 구성 요소입니다.

      2

      구성 요소에 적용할 로그 수준입니다.

2. 파일을 저장하여 변경 사항을 적용합니다. 로그 수준 변경을 적용하면 구성 요소의 Pod가 자동으로 다시 시작됩니다.

   주의

   모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.

3. 관련 프로젝트의 배포 또는 Pod 구성을 검토하여 로그 수준이 적용되었는지 확인합니다. 다음 예제는 openshift-user-workload-monitoring 프로젝트의 prometheus-operator 배포에서 로그 수준을 확인합니다.

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

   출력 예

           - --log-level=debug

4. 구성 요소의 Pod가 실행 중인지 확인합니다. 다음 예제는 openshift-user-workload-monitoring 프로젝트의 Pod 상태를 나열합니다.

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

   참고

   인식할 수 없는 Prometheus Operator loglevel 값이 ConfigMap에 포함된 경우 Pod 구성 요소가 성공적으로 다시 시작되지 않을 수 있습니다.

절차

1. user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

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

2. data/config.yaml 아래의 alertmanager 섹션에 enabled: true 및 enableAlertmanagerConfig: true 를 추가합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   클러스터에서 사용자 정의 프로젝트에 대해 Alertmanager의 전용 인스턴스를 활성화하려면 enabled 값을 true 로 설정합니다. 값을 false 로 설정하거나 키를 완전히 생략하여 사용자 정의 프로젝트에 대한 Alertmanager를 비활성화합니다. 이 값을 false 로 설정하거나 키가 생략되면 사용자 정의 경고가 기본 플랫폼 Alertmanager 인스턴스로 라우팅됩니다.

   2

   사용자가 AlertmanagerConfig 오브젝트로 자체 경고 라우팅 구성을 정의할 수 있도록 enableAlertmanagerConfig 값을 true 로 설정합니다.

3. 파일을 저장하여 변경 사항을 적용합니다. 사용자 정의 프로젝트에 대한 Alertmanager의 전용 인스턴스는 자동으로 시작됩니다.

1. AWS 웹 콘솔에서 Red Hat OpenShift Service를 열고 모니터링 → 경고 → 경고 페이지로 이동합니다.
2. 선택 사항: 검색 목록에서 이름 필드를 사용하여 이름별로 경고를 검색합니다.
3. 선택 사항: 필터 목록에서 필터를 선택하여 상태, 심각도 및 소스별로 경고를 필터링합니다.
4. 선택 사항: 이름, 심각도, 상태 및 소스 열 헤더 중 하나 이상을 클릭하여 경고를 정렬합니다.

5. 경고 세부 정보 페이지로 이동하도록 경고 이름을 선택합니다. 페이지에는 경고 시계열 데이터를 설명하는 그래프가 포함되어 있습니다. 또한 다음을 포함하여 경고에 대한 정보를 제공합니다.

   • 경고에 대한 설명
   • 경고와 관련된 메시지
   • 경고에 연결된 라벨
   • 관리 경고 규칙에 대한 링크
   • 존재하는 경우 경고에 대한 음소거

1. 모니터링 → 경고 → 음소거 페이지로 이동합니다.
2. 선택 사항: 이름으로 검색 필드를 사용하여 이름으로 음소거를 필터링합니다.
3. 선택 사항: 필터 목록에서 필터를 선택하여 상태별로 음소거를 필터링합니다. 기본적으로 활성 및 보류 중 필터가 적용됩니다.
4. 선택 사항: 이름, 경고 실행 및 상태 열 헤더를 하나 이상 클릭하여 음소거를 정렬합니다.

5. 음소거의 이름을 선택하여 음소거 상세 정보 페이지로 이동합니다. 페이지에는 다음과 같은 세부 정보가 포함됩니다.

   • 경고 사양
   • 시작 시간
   • 종료 시간
   • 음소거 상태
   • 실행 경고 수 및 목록

1. 모니터링 → 경고 → 경고 규칙 페이지로 이동합니다.
2. 선택 사항: 필터 목록에서 필터를 선택하여 상태, 심각도 및 소스로 경고 규칙을 필터링합니다.
3. 선택 사항: 이름, 심각도, 경고 상태 및 소스 열 헤더 중 하나 이상을 클릭하여 경고 규칙을 정렬합니다.

4. 경고 규칙의 이름을 선택하여 경고 규칙 세부 정보 페이지로 이동합니다. 페이지는 경고 규칙에 대한 다음 세부 정보를 제공합니다.

   • 경고 규칙 이름, 심각도 및 설명
   • 경고를 실행하기 위한 조건을 정의하는 표현식
   • 경고가 실행되기 위한 조건이 true여야 하는 시간
   • 경고 규칙에 의해 관리되는 각 경고에 대한 그래프로, 경고가 실행되는 값을 표시
   • 경고 규칙에 의해 관리되는 모든 경고의 테이블

1. 모니터링 → < project_name> → 경고 페이지로 이동합니다.

2. 경고, 음소거 또는 경고 규칙에 대한 세부 정보를 표시합니다.

   • 경고 세부 정보는 경고 이름 왼쪽의 >를 선택한 다음 목록에 있는 경고를 선택하여 볼 수 있습니다.

   • 음소거 상세 정보는 경고 세부 정보 페이지의 음소거 기준 섹션에서 음소거를 선택하여 볼 수 있습니다. 음소거 상세 정보 페이지에는 다음 정보가 포함됩니다.

     • 경고 사양
     • 시작 시간
     • 종료 시간
     • 음소거 상태
     • 실행 경고 수 및 목록
   • 경고 규칙 세부 정보는 경고 페이지에 있는 경고 오른쪽의 메뉴에서 경고 규칙 보기를 선택하여 볼 수 있습니다.

1. 현재 활성화된 Alertmanager 구성을 파일 alertmanager.yaml로 출력합니다.

   $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. alertmanager.yaml에서 설정을 편집합니다.

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s 1
     group_interval: 5m 2
     repeat_interval: 12h 3
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=<your_service>" 4
       routes:
       - matchers:
         - <your_matching_rules> 5
         receiver: <receiver> 6
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   group_wait 값은 경고 그룹에 대한 초기 알림을 보내기 전에 Alertmanager 대기 기간을 지정합니다. 이 값은 알림을 보내기 전에 동일한 그룹에 대한 초기 경고를 수집하는 동안 Alertmanager가 대기하는 시간을 제어합니다.

   2

   group_interval 값은 Alertmanager가 초기 알림이 이미 전송된 경고 그룹에 추가된 새 경고에 대한 알림을 보내기 전에 경과해야 하는 시간을 지정합니다.

   3

   repeat_interval 값은 경고 알림을 반복하기 전에 전달해야 하는 최소 시간을 지정합니다. 각 그룹 간격마다 알림을 반복하려면 repeat_interval 값을 group_interval 값보다 적도록 설정합니다. 그러나 반복된 알림은 특정 Alertmanager Pod가 재시작되거나 다시 예약되는 경우와 같이 계속 지연될 수 있습니다.

   4

   서비스 값은 경고를 실행하는 서비스를 지정합니다.

   5

   & lt;your_matching_rules& gt; 값은 대상 경고를 지정합니다.

   6

   수신자 값은 경고에 사용할 수신자를 지정합니다.

   참고

   일치자 키 이름을 사용하여 노드와 일치하기 위해 경고가 충족해야 한다는 일치자를 나타냅니다. 더 이상 사용되지 않고 향후 릴리스에서 제거될 예정인 match 또는 match_re 키 이름을 사용하지 마십시오.

   또한 억제 규칙을 정의하는 경우 target_matchers 키 이름을 사용하여 대상 일치자 및 source_matchers 키 이름을 지정하여 소스 일치자를 나타냅니다. 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정인 target_match,target _match_re,source_match _re 키 이름을 사용하지 마십시오.

   다음 Alertmanager 설정 예제에서는 PagerDuty를 경고 수신자로 구성합니다.

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=example-app"
       routes:
       - matchers:
         - "severity=critical"
         receiver: team-frontend-page*
   receivers:
   - name: default
   - name: watchdog
   - name: team-frontend-page
     pagerduty_configs:
     - service_key: "_your-key_"

   이 설정을 사용하면 example-app 서비스에서 실행되는 critical 심각도 경고가 team-frontend-page 수신자를 사용하여 전송됩니다. 일반적으로 이러한 유형의 경고는 개인 또는 문제 대응팀으로 호출됩니다.

3. 파일에 새 설정을 적용합니다.

   $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

1. 웹 콘솔의 관리 → 클러스터 설정 → 구성 → Alertmanager → YAML 페이지로 이동합니다.
2. YAML 설정 파일을 수정합니다.
3. 저장을 선택합니다.

절차

1. 현재 활성화된 Alertmanager 설정을 alertmanager.yaml 파일에 출력합니다.

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. alertmanager.yaml에서 설정을 편집합니다.

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   경로와 일치하는 경고를 지정합니다. 이 예제에서는 service="prometheus-example-monitor" 라벨이 있는 모든 경고를 표시합니다.

   2

   경고 그룹에 사용할 수신자를 지정합니다.

3. 파일에 새 설정을 적용합니다.

   $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

절차

1. AWS 웹 콘솔의 Red Hat OpenShift Service의 개발자 관점에서 Observe → Dashboard 로 이동합니다.
2. Project: 목록에서 프로젝트를 선택합니다.
3. 모든 워크로드 목록에서 워크로드를 선택합니다.
4. 선택 사항: 시간 범위 목록에서 그래프의 시간 범위를 선택합니다.
5. 선택 사항: 새로 고침 간격을 선택합니다.
6. 대시보드 내에서 각각의 그래프로 마우스를 이동하여 특정 항목에 대한 세부 정보를 표시합니다.

절차

1. 메트릭 이름을 쿼리하고 프로젝트가 올바른지 확인합니다.

   1. OpenShift Container Platform 웹 콘솔의 개발자 관점에서 모니터링 → 메트릭 을 선택합니다.
   2. Project: 목록에서 메트릭을 보려는 프로젝트를 선택합니다.

   3. 쿼리 선택 목록에서 쿼리를 선택하거나 PromQL 표시를 선택하여 사용자 정의 PromQL 쿼리를 실행합니다.

      쿼리 선택 창에 지표 이름이 표시됩니다.

      쿼리는 프로젝트별로 수행해야 합니다. 표시된 메트릭은 선택한 프로젝트와 관련이 있습니다.

2. 메트릭을 원하는 Pod가 적극적으로 메트릭을 제공하고 있는지 확인합니다. Pod로 다음 oc exec 명령을 실행하여 podIP,포트, /metrics 를 대상으로 합니다.

   $ oc exec <sample_pod> -n <sample_namespace> -- curl <target_pod_IP>:<port>/metrics

   참고

   curl 이 설치된 포드에서 명령을 실행해야 합니다.

   다음 예제 출력에서는 유효한 버전 지표가 있는 결과를 보여줍니다.

   출력 예

     % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
   # HELP version Version information about this binary-- --:--:-- --:--:--     0
   # TYPE version gauge
   version{version="v0.1.0"} 1
   100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:-- 51000

   유효하지 않은 출력은 해당 애플리케이션에 문제가 있음을 나타냅니다.

3. PodMonitor CRD를 사용하는 경우 라벨 일치를 사용하여 PodMonitor CRD가 올바른 Pod를 가리키도록 구성되어 있는지 확인합니다. 자세한 내용은 Prometheus Operator 설명서를 참조하십시오.

4. ServiceMonitor CRD를 사용하고 Pod의 /metrics 끝점에 지표 데이터가 표시되는 경우 다음 단계에 따라 구성을 확인합니다.

   1. 서비스가 올바른 /metrics 엔드포인트를 가리키는지 확인합니다. 이 출력의 서비스 레이블 은 서비스 모니터 레이블 과 후속 단계의 서비스에서 정의한 /metrics 엔드포인트와 일치해야 합니다.

      $ oc get service

      출력 예

      apiVersion: v1
      kind: Service 1
      metadata:
        labels: 2
          app: prometheus-example-app
        name: prometheus-example-app
        namespace: ns1
      spec:
        ports:
        - port: 8080
          protocol: TCP
          targetPort: 8080
          name: web
        selector:
          app: prometheus-example-app
        type: ClusterIP

      1

      이 API를 서비스 API라고 지정합니다.

      2

      이 서비스에 사용되는 레이블을 지정합니다.

   2. serviceIP,port, /metrics 엔드포인트를 쿼리하여 이전에 실행한 curl 명령의 동일한 메트릭을 확인합니다.

      1. 다음 명령을 실행하여 서비스 IP를 찾습니다.

         $ oc get service -n <target_namespace>

      2. /metrics 엔드포인트를 쿼리합니다.

         $ oc exec <sample_pod> -n <sample_namespace> -- curl <service_IP>:<port>/metrics

         다음 예제에서 유효한 메트릭이 반환됩니다.

         출력 예

         % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                        Dload  Upload   Total   Spent    Left  Speed
         100   102  100   102    0     0  51000      0 --:--:-- --:--:-- --:--:--   99k
         # HELP version Version information about this binary
         # TYPE version gauge
         version{version="v0.1.0"} 1

   3. 레이블 일치를 사용하여 ServiceMonitor 오브젝트가 원하는 서비스를 가리키도록 구성되어 있는지 확인합니다. 이렇게 하려면 oc get service 출력의 Service 오브젝트를 oc get service monitor 출력의 ServiceMonitor 오브젝트와 비교합니다. 표시할 메트릭과 일치해야 하는 레이블입니다.

      예를 들어 이전 단계에서 Service 오브젝트에 app: prometheus-example-app 레이블이 있고 ServiceMonitor 오브젝트에 동일한 app: prometheus-example-app 일치 라벨이 있는지 확인하십시오.

5. 모든 항목이 유효한 것으로 확인되고 메트릭을 계속 사용할 수 없는 경우 지원 팀에 문의하여 추가 지원을 받으십시오.