3.6. 영구 스토리지 구성
영구 스토리지로 클러스터 모니터링을 실행하면 메트릭이 PV(영구 볼륨)에 저장되며 Pod를 다시 시작하거나 재생성할 수 있습니다. 메트릭 데이터가 데이터 손실에서 보호되어야 하는 경우 이상적입니다. 프로덕션 환경의 경우 영구 스토리지를 구성하는 것이 매우 좋습니다. 높은 IO 요구로 인해 로컬 스토리지를 사용하는 것이 이점이 됩니다.
권장되는 구성 가능한 스토리지 기술을 참조하십시오.
3.6.1. 영구 스토리지 사전 요구 사항
- 스토리지의 블록 유형을 사용합니다.
3.6.2. 로컬 영구 볼륨 클레임 구성
PV(영구 볼륨)를 사용하기 위한 구성 요소를 모니터링하는 경우 PVC(영구 볼륨 클레임)를 구성해야 합니다.
사전 요구 사항
-
dedicated-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. -
user-workload-monitoring-config
ConfigMap
오브젝트가 생성되어 있습니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
사용자 정의 프로젝트를 모니터링하는 구성 요소의 PVC를 구성하려면
ConfigMap
오브젝트를 편집합니다.openshift-user-workload-monitoring
프로젝트에서user-workload-monitoring-config
ConfigMap
오브젝트를 편집합니다.$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
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: 40Gi
파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작되고 새 스토리지 구성이 적용됩니다.
주의모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.
3.6.3. Prometheus 메트릭 데이터의 보존 시간 수정
기본적으로 AWS 모니터링 스택의 Red Hat OpenShift Service는 Prometheus 데이터의 보존 시간을 15일로 구성합니다. 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 시간을 수정하여 데이터 삭제 시간을 변경할 수 있습니다.
사전 요구 사항
-
dedicated-admin
역할의 사용자로 클러스터에 액세스할 수 있습니다. -
user-workload-monitoring-config
ConfigMap
오브젝트가 생성되어 있습니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 시간을 수정하려면
ConfigMap
오브젝트를 편집합니다.openshift-user-workload-monitoring
프로젝트에서user-workload-monitoring-config
ConfigMap
오브젝트를 편집합니다.$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
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>
<time_specification>
을ms
(밀리초),s
(초),m
(분),h
(시간),d
(일),w
(주) 또는y
(년)가 바로 따라오는 숫자로 바꿉니다.다음 예제에서는 사용자 정의 프로젝트를 모니터링하는 Prometheus 인스턴스의 보존 시간을 24시간으로 설정합니다.
apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheus: retention: 24h
파일을 저장하여 변경 사항을 적용합니다. 새 구성의 영향을 받는 Pod가 자동으로 다시 시작됩니다.
주의모니터링 구성 맵에 변경 사항이 저장되면 관련 프로젝트의 Pod 및 기타 리소스가 재배포될 수 있습니다. 해당 프로젝트에서 실행 중인 모니터링 프로세스도 다시 시작할 수 있습니다.