검색

2.10. 영구 스토리지 구성

download PDF

영구 스토리지로 클러스터 모니터링을 실행하면 메트릭이 PV(영구 볼륨)에 저장되며 Pod를 다시 시작하거나 재생성할 수 있습니다. 데이터 손실에서 메트릭 또는 경고 데이터가 필요한 경우 이상적입니다. 프로덕션 환경의 경우 영구 스토리지를 구성하는 것이 매우 좋습니다. 높은 IO 요구로 인해 로컬 스토리지를 사용하는 것이 이점이 됩니다.

2.10.1. 영구 스토리지 사전 요구 사항

  • 디스크가 가득 차지 않도록 충분한 로컬 영구 스토리지를 전용으로 지정합니다. 필요한 스토리지의 양은 Pod 수에 따라 달라집니다.
  • 각 복제본에 대해 하나의 PV(영구 볼륨 클레임)에서 PV(영구 볼륨)를 클레임할 준비가 되어 있는지 확인합니다. Prometheus 및 Alertmanager에는 두 개의 복제본이 있으므로 전체 모니터링 스택을 지원하는 데 4개의 PV가 필요합니다. Local Storage Operator에서 PV를 사용할 수 있지만 동적으로 프로비저닝된 스토리지를 활성화한 경우에는 사용할 수 없습니다.
  • 영구 볼륨을 구성할 때 FilesystemvolumeMode 매개변수의 스토리지 유형 값으로 사용합니다.

    참고

    영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume 오브젝트에서 volumeMode: Block 에 설명된 원시 블록 볼륨을 사용하지 마십시오. Prometheus는 원시 블록 볼륨을 사용할 수 없습니다.

    중요

    Prometheus는 POSIX 호환이 아닌 파일 시스템을 지원하지 않습니다. 예를 들어 일부 NFS 파일 시스템 구현은 POSIX와 호환되지 않습니다. 스토리지를 위해 NFS 파일 시스템을 사용하려면 공급 업체에 NFS 구현이 완전히 POSIX와 호환되는지 확인하십시오.

2.10.2. 로컬 영구 볼륨 클레임 구성

PV(영구 볼륨)를 사용하기 위한 구성 요소를 모니터링하는 경우 PVC(영구 볼륨 클레임)를 구성해야 합니다.

사전 요구 사항

  • 핵심 OpenShift Container Platform 모니터링 구성 요소인 경우:

    • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • cluster-monitoring-config ConfigMap 오브젝트를 생성하셨습니다.
  • 사용자 정의 프로젝트를 모니터링하는 구성 요소를 구성하는 경우:

    • cluster-admin 클러스터 역할의 사용자로 또는 openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config-edit 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • user-workload-monitoring-config ConfigMap 오브젝트가 생성되어 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

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

    • 핵심 OpenShift Container Platform 프로젝트를 모니터링하는 구성 요소의 PVC를 구성하려면 다음을 수행합니다.

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

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 아래의 구성 요소에 대한 PVC 구성을 추가합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

        volumeClaimTemplate을 지정하는 방법에 대한 내용은 PersistentVolumeClaims에 대한 Kubernetes 문서를 참조하십시오.

        다음 예제는 핵심 OpenShift Container Platform 구성 요소를 모니터링하는 Prometheus 인스턴스의 로컬 영구 스토리지를 요청하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi

        위의 예에서 Local Storage Operator에 의해 생성된 스토리지 클래스를 local-storage라고 합니다.

        다음 예제는 Alertmanager에 대한 로컬 영구 스토리지를 요청하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi
    • 사용자 정의 프로젝트를 모니터링하는 구성 요소의 PVC를 구성하려면 다음을 수행합니다.

      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 아래의 구성 요소에 대한 PVC 구성을 추가합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

        volumeClaimTemplate을 지정하는 방법에 대한 내용은 PersistentVolumeClaims에 대한 Kubernetes 문서를 참조하십시오.

        다음 예제는 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 로컬 영구 스토리지를 요청하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi

        위의 예에서 Local Storage Operator에 의해 생성된 스토리지 클래스를 local-storage라고 합니다.

        다음 예제에서는 Thanos Ruler의 로컬 영구 스토리지를 요청하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi
        참고

        thanosRuler 구성 요소의 스토리지 요구 사항은 평가되는 규칙 수와 각 규칙이 생성하는 샘플 수에 따라 달라집니다.

  2. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작되고 새 스토리지 구성이 적용됩니다.

    참고

    클러스터 관리자가 사용자 정의 프로젝트에 대한 모니터링을 활성화하지 않는 한 user-workload-monitoring-config ConfigMap 오브젝트에 적용되는 구성이 활성화되어 있지 않습니다.

    주의

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

2.10.3. 영구 스토리지 볼륨 크기 조정

OpenShift Container Platform은 기본 StorageClass 리소스가 영구 볼륨 크기 조정을 지원하는 경우에도 StatefulSet 리소스에서 사용하는 기존 영구 스토리지 볼륨 크기 조정을 지원하지 않습니다. 따라서 더 큰 크기의 기존 PVC(영구 볼륨 클레임)의 스토리지 필드를 업데이트해도 이 설정은 연결된 PV(영구 볼륨)로 전파되지 않습니다.

그러나 수동 프로세스를 사용하면 PV의 크기를 조정할 수 있습니다. Prometheus, Thanos Ruler 또는 Alertmanager와 같은 모니터링 구성 요소의 PV의 크기를 조정하려면 구성 요소가 구성된 적절한 구성 맵을 업데이트할 수 있습니다. 그런 다음 PVC에 패치를 적용하고 pod를 삭제하고 분리합니다. 포드를 고립하면 StatefulSet 리소스가 즉시 다시 생성되고 새 PVC 설정으로 Pod에 마운트된 볼륨의 크기를 자동으로 업데이트합니다. 이 과정에서 서비스 중단이 발생하지 않습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 핵심 OpenShift Container Platform 모니터링 구성 요소인 경우:

    • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • cluster-monitoring-config ConfigMap 오브젝트를 생성하셨습니다.
    • 핵심 OpenShift Container Platform 모니터링 구성 요소를 위해 하나 이상의 PVC를 구성했습니다.
  • 사용자 정의 프로젝트를 모니터링하는 구성 요소를 구성하는 경우:

    • cluster-admin 클러스터 역할의 사용자로 또는 openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config-edit 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • user-workload-monitoring-config ConfigMap 오브젝트가 생성되어 있습니다.
    • 사용자 정의 프로젝트를 모니터링하는 구성 요소에 대해 하나 이상의 PVC를 구성했습니다.

절차

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

    • 핵심 OpenShift Container Platform 프로젝트를 모니터링하는 구성 요소의 PVC의 크기를 조정하려면 다음을 수행합니다.

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

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 아래의 구성 요소에 대한 PVC 구성에 대한 새 스토리지 크기를 추가합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3
        1
        코어 모니터링 구성 요소를 지정합니다.
        2
        스토리지 클래스를 지정합니다.
        3
        스토리지 볼륨의 새 크기를 지정합니다.

        다음 예제에서는 핵심 OpenShift Container Platform 구성 요소를 모니터링하는 Prometheus 인스턴스의 로컬 영구 스토리지를 100GB로 설정하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 100Gi

        다음 예제에서는 Alertmanager의 로컬 영구 스토리지를 40GB로 설정하는 PVC를 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi
    • 사용자 정의 프로젝트를 모니터링하는 구성 요소의 PVC의 크기를 조정하려면 다음을 수행합니다.

      참고

      사용자 정의 프로젝트를 모니터링하는 Thanos Ruler 및 Prometheus 인스턴스의 볼륨의 크기를 조정할 수 있습니다.

      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 에서 모니터링 구성 요소에 대한 PVC 구성을 업데이트합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3
        1
        코어 모니터링 구성 요소를 지정합니다.
        2
        스토리지 클래스를 지정합니다.
        3
        스토리지 볼륨의 새 크기를 지정합니다.

        다음 예제는 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 PVC 크기를 100GB로 구성합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 100Gi

        다음 예제에서는 Thanos Ruler의 PVC 크기를 20GB로 설정합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 20Gi
        참고

        thanosRuler 구성 요소의 스토리지 요구 사항은 평가되는 규칙 수와 각 규칙이 생성하는 샘플 수에 따라 달라집니다.

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

    주의

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

  3. 업데이트된 스토리지 요청으로 모든 PVC를 수동으로 패치합니다. 다음 예제는 openshift-monitoring 네임스페이스의 Prometheus 구성 요소의 스토리지 크기를 100Gi로 조정합니다.

    $ for p in $(oc -n openshift-monitoring get pvc -l app.kubernetes.io/name=prometheus -o jsonpath='{range .items[*]}{.metadata.name} {end}'); do \
      oc -n openshift-monitoring patch pvc/${p} --patch '{"spec": {"resources": {"requests": {"storage":"100Gi"}}}}'; \
      done
  4. --cascade=orphan 매개변수를 사용하여 기본 StatefulSet을 삭제합니다.

    $ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan

2.10.4. Prometheus 메트릭 데이터의 보존 시간 및 크기 수정

기본적으로 Prometheus는 다음 기간 동안 지표 데이터를 유지합니다.

  • 코어 플랫폼 모니터링: 15 일
  • 사용자 정의 프로젝트 모니터링: 24 시간

보존 필드에 시간 값을 지정하여 보존 시간을 수정하여 데이터 삭제 시간을 변경할 수 있습니다. retentionSize 필드에 크기 값을 지정하여 보존 메트릭 데이터가 사용하는 최대 디스크 공간을 구성할 수도 있습니다. 데이터가 이 크기 제한에 도달하면 Prometheus는 사용된 디스크 공간이 제한보다 다시 될 때까지 가장 오래된 데이터를 먼저 삭제합니다.

이러한 데이터 보존 설정의 동작은 다음과 같습니다.

  • 크기 기반 보존 정책은 영구 블록, WAL(Write-ahead 로그) 데이터, m-mapped 청크를 포함하여 /prometheus 디렉터리의 모든 데이터 블록 디렉터리에 적용됩니다.
  • /wal/head_chunks 디렉터리의 데이터는 보존 크기 제한으로 계산되지만 Prometheus는 크기 또는 시간 기반 보존 정책에 따라 이러한 디렉터리에서 데이터를 제거하지 않습니다. 따라서 /wal/head_chunks 디렉터리에 설정된 최대 크기보다 낮은 보존 크기 제한을 설정하면 /prometheus 데이터 디렉터리에 데이터 블록을 유지하지 않도록 시스템을 구성했습니다.
  • 크기 기반 보존 정책은 Prometheus가 새 데이터 블록을 잘라내는 경우에만 적용되며 WAL에는 최소 3시간 이상의 데이터가 포함된 후 2시간마다 발생합니다.
  • retention 또는 retentionSize 에 대한 값을 명시적으로 정의하지 않으면 보존 시간은 코어 플랫폼 모니터링의 경우 15일, 사용자 정의 프로젝트 모니터링의 경우 24시간으로 설정됩니다. 보존 크기는 설정되지 않았습니다.
  • retentionretentionSize 둘 다에 대한 값을 정의하는 경우 두 값이 모두 적용됩니다. 데이터 블록이 정의된 보존 시간 또는 정의된 크기 제한을 초과하는 경우 Prometheus는 이러한 데이터 블록을 제거합니다.
  • retentionSize 값을 정의하고 보존을 정의하지 않으면 retention Size 값만 적용됩니다.
  • retention Size 값을 정의하지 않고 보존 값만 정의하는 경우 보존 값만 적용됩니다.
  • retentionSize 또는 retention 값을 0 으로 설정하면 기본 설정이 적용됩니다. 기본 설정은 코어 플랫폼 모니터링의 경우 보존 시간을 15일로 설정하고 사용자 정의 프로젝트 모니터링의 경우 24시간으로 설정합니다. 기본적으로 보존 크기는 설정되지 않습니다.
참고

데이터 압축은 2시간마다 수행됩니다. 따라서 PV(영구 볼륨)가 압축하기 전에 채워지고 보존Size 제한을 초과할 수 있습니다. 이러한 경우 KubePersistentVolumeFillingUp 경고가 PV의 공간이 retentionSize 제한보다 작을 때까지 실행됩니다.

사전 요구 사항

  • 핵심 OpenShift Container Platform 모니터링 구성 요소인 경우:

    • cluster-admin 클러스터 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • cluster-monitoring-config ConfigMap 오브젝트를 생성하셨습니다.
  • 사용자 정의 프로젝트를 모니터링하는 구성 요소를 구성하는 경우:

    • 클러스터 관리자가 사용자 정의 프로젝트에 대한 모니터링을 활성화했습니다.
    • cluster-admin 클러스터 역할의 사용자로 또는 openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config-edit 역할의 사용자로 클러스터에 액세스할 수 있습니다.
    • user-workload-monitoring-config ConfigMap 오브젝트가 생성되어 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
주의

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

절차

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

    • 핵심 OpenShift Container Platform 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 시간 및 크기를 수정하려면 다음을 수행합니다.

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

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
      2. data/config.yaml 아래에 보존 시간 및 크기 구성을 추가합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: <time_specification> 1
              retentionSize: <size_specification> 2
        1
        보존 시간: ms (밀리초), s (초), m (분), h (시간), d (일), w (주), y (년)가 바로 따르는 번호입니다. 1h30m15s 와 같은 특정 시간에 대한 시간 값을 결합할 수도 있습니다.
        2
        보존 크기: B (바이트), KB (KB), MB (메가바이트), GB (기가바이트), TB (terabytes), PB (petabytes) 및 WebAssembly(exabytes)가 올립니다.

        다음 예제에서는 주요 OpenShift Container Platform 구성 요소를 모니터링하는 Prometheus 인스턴스의 보존 시간을 24시간으로 설정하고 보존 크기를 10GB로 설정합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: 24h
              retentionSize: 10GB
    • 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 시간 및 크기를 수정하려면 다음을 수행합니다.

      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 아래에 보존 시간 및 크기 구성을 추가합니다.

        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 (바이트), KB (KB), MB (메가바이트), GB (기가바이트), TB (terabytes), PB (petabytes) 또는 4.9(exabytes)가 뒤에 오는 숫자입니다.

        다음 예제에서는 보존 시간을 24시간으로 설정하고 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 크기를 10GB로 설정합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: 24h
              retentionSize: 10GB
  2. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작됩니다.

2.10.5. Thanos Ruler 메트릭 데이터의 보존 시간 수정

기본적으로 사용자 정의 프로젝트의 경우 Thanos Ruler는 메트릭 데이터를 24시간 동안 자동으로 유지합니다. openshift-user-workload-monitoring 네임스페이스의 user-workload-monitoring-config 구성 맵에 시간 값을 지정하여 이 데이터가 유지되는 기간을 변경하도록 보존 시간을 수정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자가 사용자 정의 프로젝트에 대한 모니터링을 활성화했습니다.
  • cluster-admin 클러스터 역할의 사용자로 또는 openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config-edit 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • user-workload-monitoring-config ConfigMap 오브젝트가 생성되어 있습니다.
주의

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

절차

  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 아래에 보존 시간 구성을 추가합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: <time_specification> 1
    1
    보존 시간을 ms (밀리초), s (초), m (분), h (시간), d (일), w (주) 또는 y (년)로 바로 따라 지정합니다. 1h30m15s 와 같은 특정 시간에 대한 시간 값을 결합할 수도 있습니다. 기본값은 24h 입니다.

    다음 예제에서는 Thanos Ruler 데이터에 대해 보존 시간을 10일로 설정합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          retention: 10d
  3. 파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작됩니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.