728x90
이번 글에서는 쿠버네티스 모니터링 시스템에서 중요한 측면인 메트릭 보존 정책에 대해 알아보겠습니다. 효과적인 메트릭 보존 정책은 스토리지 비용을 관리하면서도 필요한 기간 동안 중요한 모니터링 데이터를 유지하는 균형을 찾는 데 필수적입니다. 이 글에서는 Prometheus와 같은 시계열 데이터베이스에서 메트릭 데이터를 효율적으로 관리하기 위한 다양한 전략, 장기 저장소 옵션, 데이터 다운샘플링 방법, 그리고 보존 정책을 자동화하는 방법을 실제 구현 예제와 함께 살펴보겠습니다.
📌 메트릭 보존의 중요성과 과제
시간이 지남에 따라 수집되는 모니터링 데이터의 양은 기하급수적으로 증가할 수 있으며, 이를 효과적으로 관리하는 것이 중요합니다.
✅ 메트릭 데이터 증가의 이해
모니터링 시스템에서 데이터가 어떻게 증가하는지 이해하는 것이 중요합니다.
- 시계열 데이터의 성장 요인
- 모니터링 대상 증가 (노드, 파드, 서비스 등)
- 스크래핑 빈도
- 메트릭 카디널리티 (레이블 조합 수)
- 보존 기간
- 데이터 증가 예측 계산
- 초당 샘플 수: 메트릭 수 × 스크래핑 빈도 × 대상 수
- 일일 데이터 증가량: 초당 샘플 수 × 평균 샘플 크기 × 86,400초
# 메트릭 데이터 증가 예측 계산 예시
# 환경 요소:
# - 100개의 노드
# - 각 노드당 1,000개의 메트릭
# - 15초 스크래핑 간격
# - 샘플당 평균 2바이트 (압축 후)
# 초당 샘플 수 계산:
# 모든 노드에서 수집하는 메트릭 총합을 스크래핑 간격으로 나눔
초당_샘플_수 = (100 * 1000) / 15 # = 6,667 샘플/초
# 일일 데이터 증가량:
# 초당 샘플 수에 샘플 크기를 곱하고 하루 동안의 초를 곱함
일일_데이터 = 6667 * 2 * 86400 # ≈ 1.15 GB/일
# 2주 보존 시 필요한 스토리지:
# 일일 데이터 양에 보존 일수를 곱함
이주_스토리지 = 1.15 * 14 # ≈ 16.1 GB
# 레이블 카디널리티 증가 시(예: 5배):
# 카디널리티가 높아지면 필요한 스토리지도 비례하여 증가
수정된_일일_데이터 = 1.15 * 5 # ≈ 5.75 GB/일
수정된_이주_스토리지 = 5.75 * 14 # ≈ 80.5 GB
- 실제 데이터 증가 모니터링
- Prometheus 자체 메트릭 활용
- 스토리지 사용량 추세 분석
- 대시보드 기반 용량 계획
✅ 보존 정책 결정시 고려 사항
효과적인 보존 정책을 설계할 때 고려해야 할 요소들입니다.
- 비즈니스 요구사항
- 규제 및 감사 요구사항
- 장기 추세 분석 필요성
- 장애 사후 분석 타임라인
- 기술적 제약
- 스토리지 용량
- 쿼리 성능 요구사항
- 비용 제약
- 데이터 가치 변화
- 시간 경과에 따른 세부 정보의 가치 감소
- 장기 추세 데이터의 중요성
- 이상 징후 탐지를 위한 기준선 데이터
# Prometheus 보존 정책 설정 예시
# 이 설정은 Prometheus가 15일 동안 데이터를 보존하도록 구성합니다.
# Prometheus는 이 기간이 지난 데이터를 자동으로 삭제합니다.
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-k8s # Prometheus 리소스의 이름
namespace: monitoring # 배포될 네임스페이스
spec:
# 다른 Prometheus 설정...
# 데이터 보존 설정
retention: 15d # 15일 동안 데이터 보존 (시간 기반 보존)
retentionSize: 512GB # 최대 512GB까지 데이터 보존 (용량 기반 보존)
# 두 조건 중 먼저 도달하는 시점에 데이터 삭제
# 블록 기반 스토리지 세부 설정
blockSize: 2h # 2시간 단위로 블록 생성
# 작은 블록은 메모리 사용량을 줄이지만, 너무 많은 블록은 관리 오버헤드 증가
# 스토리지 압축 설정
tsdb:
outOfOrderTimeWindow: 30m # 늦게 도착한 샘플을 받아들일 시간 윈도우
# 시간 순서가 맞지 않는 샘플 처리에 중요
# 스토리지 볼륨 설정
storage:
volumeClaimTemplate:
spec:
storageClassName: fast-ssd # 빠른 SSD 스토리지 클래스 사용
resources:
requests:
storage: 750Gi # 스토리지 용량 요청
▶️ 실제 사례: 한 기업은 초기에 모든 메트릭을 30일간 보존하도록 설정했으나, 데이터 증가로 인해 스토리지 비용이 급증했습니다. 분석 결과, 대부분의 문제 해결은 7일 이내의 데이터만 필요했고, 장기 추세 분석은 시간별 집계 데이터로 충분했습니다. 따라서 보존 정책을 세분화하여 원본 데이터는 7일, 시간별 집계 데이터는 90일, 일별 집계 데이터는 1년으로 조정했습니다. 이를 통해 스토리지 비용을 70% 절감하면서도 필요한 분석 기능을 유지할 수 있었습니다.
📌 Prometheus 데이터 저장소 이해하기
효과적인 보존 정책을 설계하기 위해서는 Prometheus의 데이터 저장 방식을 이해하는 것이 중요합니다.
✅ TSDB(Time Series Database) 아키텍처
Prometheus의 시계열 데이터베이스(TSDB) 구조에 대해 알아보겠습니다.
- 블록 기반 스토리지
- 시간 범위에 따른 블록 구성
- 메모리 내 버퍼와 디스크 저장소 구조
- 압축 및 인코딩 메커니즘
- 데이터 압축 원리
- 델타 인코딩 (연속 타임스탬프)
- XOR 압축 (유사한 값)
- 고정 해상도 표현
- 블록 컴팩션 과정
- 작은 블록을 큰 블록으로 병합
- 비활성 블록 압축
- 중복 데이터 정리
# Prometheus 데이터 디렉토리 구조 예시
# 이는 Prometheus가 데이터를 저장하는 디렉토리 구조를 보여줍니다.
/data
|-- 01EXAMPLEBLOCK1 # 2시간 블록 (최근) - 각 블록은 특정 시간 범위의 데이터를 저장
| |-- meta.json # 블록 메타데이터 - 시간 범위, 통계 정보 등
| |-- index # 시계열 인덱스 - 빠른 검색을 위한 메트릭 이름, 레이블 등의 인덱스
| |-- chunks # 압축된 샘플 데이터 - 실제 시계열 데이터 값
|
|-- 01EXAMPLEBLOCK2 # 더 오래된 블록 (12시간) - 컴팩션으로 여러 작은 블록이 합쳐진 결과
| |-- meta.json
| |-- index
| |-- chunks
|
|-- 01EXAMPLEBLOCK3 # 더 오래된 블록 (2일) - 더 오래된 데이터를 포함하는 더 큰 블록
| |-- meta.json
| |-- index
| |-- chunks
|
|-- wal # 쓰기 예정 로그(Write-Ahead Log) - 메모리의 데이터를 디스크에 기록하기 전에 보관
|-- 000001 # WAL 세그먼트 파일 - 순차적으로 생성되며, 장애 복구에 사용됨
|-- 000002 # 번호가 증가하면서 생성되는 WAL 세그먼트 파일들
|-- 000003 # 블록으로 컴팩션되면 삭제됨
✅ 스토리지 효율성 최적화
Prometheus 스토리지를 최적화하는 방법을 알아보겠습니다.
- 샘플 수집 빈도 조정
- 메트릭 유형별 차등화된 스크래핑 간격
- 중요도에 따른 우선순위 지정
- 변화 속도에 맞는 빈도 설정
- 카디널리티 관리
- 레이블 수 최소화
- 고카디널리티 레이블 제한
- 레이블 값 정규화
- 스토리지 컴팩션 튜닝
- 블록 크기 최적화
- 컴팩션 주기 조정
- 압축 레벨 설정
# 스크래핑 간격 차등화 예시
# 이 설정은 중요도가 다른 대상에 대해 다른 스크래핑 간격을 적용합니다.
# Prometheus 설정 (prometheus.yaml 또는 ConfigMap)
scrape_configs:
# 중요 시스템 메트릭 - 짧은 간격 (15초)
- job_name: 'critical-metrics' # 중요 메트릭을 위한 작업 정의
scrape_interval: 15s # 15초마다 스크래핑 - 변화를 빠르게 감지
kubernetes_sd_configs: # 쿠버네티스 서비스 디스커버리 설정
- role: pod # Pod를 대상으로 메트릭 수집
relabel_configs: # 레이블 재작성 규칙
- source_labels: [__meta_kubernetes_pod_label_criticality] # Pod의 criticality 레이블 확인
regex: 'high' # 'high' 값을 가진 Pod만 선택
action: keep # 조건에 맞는 대상만 유지
# 일반 애플리케이션 메트릭 - 중간 간격 (30초)
- job_name: 'app-metrics' # 일반 애플리케이션 메트릭 작업
scrape_interval: 30s # 30초마다 스크래핑 - 적당한 빈도로 수집
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_criticality]
regex: 'medium'
action: keep
# 느리게 변하는 메트릭 - 긴 간격 (60초)
- job_name: 'slow-changing-metrics' # 천천히 변하는 메트릭 작업
scrape_interval: 60s # 60초마다 스크래핑 - 자주 변하지 않는 데이터
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_criticality]
regex: 'low'
action: keep
# 개발/테스트 환경 메트릭 - 매우 긴 간격 (2분)
- job_name: 'dev-metrics' # 개발/테스트 환경 메트릭 작업
scrape_interval: 120s # 2분마다 스크래핑 - 중요도 낮은 환경
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace] # 네임스페이스로 구분
regex: '.*-dev|.*-test' # 개발/테스트 네임스페이스 패턴 매칭
action: keep
▶️ 스토리지 최적화 사례: 한 대규모 쿠버네티스 클러스터 운영 팀은 Prometheus 스토리지 사용량이 급증하여 분석한 결과, 일부 사용자 정의 메트릭이 Pod ID를 레이블로 사용하여 카디널리티가 매우 높은 문제를 발견했습니다. 이를 해결하기 위해 Pod ID 대신 Deployment 또는 StatefulSet 이름을 사용하도록 변경하고, 예측 가능한 패턴을 가진 값(예: UUID)을 상수로 대체하는 레이블 재작성 규칙을 구현했습니다. 그 결과 스토리지 사용량이 65% 감소했고, 쿼리 성능도 40% 향상되었습니다.
📌 장기 메트릭 저장 전략
장기적인 메트릭 데이터를 보존하기 위한 다양한 접근 방식을 살펴보겠습니다.
✅ 다단계 스토리지 아키텍처
메트릭 데이터의 연령과 가치에 따른 다단계 저장 전략입니다.
- 핫 스토리지 (단기 보존)
- Prometheus 서버의 로컬 스토리지
- 고성능 SSD 기반
- 최근 데이터 (7-15일)
- 고해상도 원본 데이터
- 웜 스토리지 (중기 보존)
- 원격 저장소 (Thanos, Cortex 등)
- 중간 성능 저장소
- 중기 데이터 (30-90일)
- 필터링 및 집계 데이터
- 콜드 스토리지 (장기 보존)
- 저비용 대용량 스토리지
- 장기 데이터 (1년 이상)
- 고도로 집계된 데이터
- 비정기적 접근용
# Thanos를 활용한 다단계 스토리지 구성 예시
# 이 설정은 Thanos를 사용하여 Prometheus 데이터를 장기 저장소로 전송합니다.
# Thanos Sidecar 설정 - Prometheus와 함께 배포됨
apiVersion: monitoring.coreos.com/v1
kind: Prometheus # Prometheus 커스텀 리소스 정의
metadata:
name: prometheus-k8s # Prometheus 인스턴스 이름
namespace: monitoring # 배포될 네임스페이스
spec:
# Prometheus 기본 설정...
thanos: # Thanos 관련 설정 섹션
# Thanos Sidecar 이미지
image: quay.io/thanos/thanos:v0.26.0 # 사용할 Thanos 이미지 및 버전
# 블록 관련 설정
blockSize: 2h # 2시간 단위로 블록 생성
retention: 7d # Prometheus 자체는 7일만 보관 (핫 스토리지)
# 객체 스토리지 설정
objectStorageConfig: # 장기 저장을 위한 객체 스토리지 설정
name: thanos-objstore-config # 스토리지 설정을 담고 있는 Secret 이름
key: objstore.yaml # Secret 내의 설정 파일 키
---
# 객체 스토리지 설정 Secret
apiVersion: v1
kind: Secret # 보안 정보를 위한 Secret 리소스
metadata:
name: thanos-objstore-config # Secret 이름
namespace: monitoring # 네임스페이스
type: Opaque # 일반 Secret 타입
stringData: # 문자열 데이터 (자동으로 Base64 인코딩됨)
objstore.yaml: | # 객체 스토리지 설정 파일
type: S3 # S3 호환 스토리지 사용
config:
bucket: "metrics-longterm" # S3 버킷 이름 - 장기 메트릭 저장용
endpoint: "s3.amazonaws.com" # S3 엔드포인트 URL
region: "us-west-2" # AWS 리전
access_key: "${AWS_ACCESS_KEY}" # 접근 키 (실제로는 환경 변수 또는 IAM 역할 사용)
secret_key: "${AWS_SECRET_KEY}" # 비밀 키 (실제로는 환경 변수 또는 IAM 역할 사용)
insecure: false # TLS 사용 (보안 연결)
---
# Thanos Compactor 설정 - 장기 저장소 최적화
apiVersion: apps/v1
kind: Deployment # 배포 리소스 타입
metadata:
name: thanos-compactor # Compactor 이름
namespace: monitoring # 네임스페이스
spec:
replicas: 1 # 단일 인스턴스로 실행 (중복 컴팩션 방지)
selector:
matchLabels:
app: thanos-compactor # 이 배포에 속한 파드 선택 레이블
template:
metadata:
labels:
app: thanos-compactor # 파드 레이블
spec:
containers:
- name: thanos # 컨테이너 이름
image: quay.io/thanos/thanos:v0.26.0 # Thanos 이미지
args:
- "compact" # Thanos Compactor 모드로 실행
- "--log.level=info" # 로깅 레벨 설정
- "--data-dir=/var/thanos/compactor" # 임시 작업 디렉토리
- "--objstore.config-file=/etc/thanos/objstore.yaml" # 객체 스토리지 설정 파일 경로
- "--wait" # 지속적인 컴팩션 수행 (데몬 모드)
- "--downsampling.enable" # 다운샘플링 활성화 - 데이터 크기 감소
# 다운샘플링 설정: 다른 해상도별 보존 기간 설정
- "--retention.resolution-raw=14d" # 원본 해상도 데이터는 14일 보관
- "--retention.resolution-5m=90d" # 5분 해상도 데이터는 90일 보관 (웜 스토리지)
- "--retention.resolution-1h=1y" # 1시간 해상도 데이터는 1년 보관 (콜드 스토리지)
volumeMounts:
- name: objstore-config # 마운트할 볼륨 이름
mountPath: /etc/thanos # 컨테이너 내부 마운트 경로
- name: data # 데이터 볼륨
mountPath: /var/thanos/compactor # 컨테이너 내부 작업 디렉토리
volumes:
- name: objstore-config # 객체 스토리지 설정 볼륨
secret:
secretName: thanos-objstore-config # 사용할 Secret 이름
- name: data # 임시 데이터 볼륨
emptyDir: {} # 임시 디렉토리 (파드 종료 시 삭제됨)
✅ 메트릭 다운샘플링
장기 저장을 위한 데이터 해상도 조정 기법입니다.
- 다운샘플링 원리
- 시간 경과에 따른 해상도 감소
- 집계 함수 적용 (평균, 최대, 최소, 합계)
- 스토리지 요구 사항 감소
- 다운샘플링 수준 설계
- 원본 데이터 (15초 또는 30초 해상도)
- 중간 해상도 (5분 또는 15분 집계)
- 저해상도 (1시간 또는 1일 집계)
- 데이터 보존 기간 차등화
- 원본 데이터: 7-14일
- 중간 해상도: 30-90일
- 저해상도: 1년 이상
# Prometheus Recording Rules를 사용한 다운샘플링 예시
# 이 설정은 원본 메트릭을 5분, 1시간으로 집계하는 룰을 정의합니다.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule # Prometheus 규칙 커스텀 리소스
metadata:
name: downsampling-rules # 규칙 이름
namespace: monitoring # 네임스페이스
spec:
groups:
# 5분 단위 다운샘플링 룰
- name: downsampling-5m # 규칙 그룹 이름
interval: 5m # 5분마다 실행 - 집계 주기
rules:
# CPU 사용률 5분 평균
- record: cpu:usage:5m:avg # 새로 생성될 메트릭 이름
expr: avg by (node) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
# CPU 사용률을 5분 평균으로 계산
# 메모리 사용량 5분 평균
- record: memory:usage:5m:avg # 메모리 사용량 집계 메트릭
expr: avg by (node) (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
# 사용 중인 메모리 계산
# API 요청 수 5분 합계
- record: api:requests:5m:sum # API 요청 집계 메트릭
expr: sum by (endpoint, status_code) (rate(http_requests_total[5m]) * 300)
# 5분 동안의 총 요청 수 계산 (rate에 300초 곱함)
# 1시간 단위 다운샘플링 룰
- name: downsampling-1h # 1시간 집계 규칙 그룹
interval: 1h # 1시간마다 실행
rules:
# CPU 사용률 1시간 평균
- record: cpu:usage:1h:avg # 1시간 CPU 평균 메트릭
expr: avg_over_time(cpu:usage:5m:avg[1h])
# 5분 집계 메트릭을 1시간 동안 평균
# 메모리 사용량 1시간 평균
- record: memory:usage:1h:avg # 1시간 메모리 평균 메트릭
expr: avg_over_time(memory:usage:5m:avg[1h])
# 5분 집계 메트릭을 1시간 동안 평균
# API 요청 수 1시간 합계
- record: api:requests:1h:sum # 1시간 API 요청 합계
expr: sum_over_time(api:requests:5m:sum[1h])
# 5분 집계 메트릭의 1시간 합계
# CPU 사용률 1시간 최대값 (피크 파악용)
- record: cpu:usage:1h:max # 1시간 내 CPU 최대값
expr: max_over_time(cpu:usage:5m:avg[1h])
# 부하 피크 탐지를 위한 최대값 집계
# 메모리 사용량 1시간 최대값
- record: memory:usage:1h:max # 1시간 내 메모리 최대값
expr: max_over_time(memory:usage:5m:avg[1h])
# 메모리 사용량 피크 탐지
✅ 원격 저장소 통합
Prometheus의 장기 스토리지 한계를 극복하기 위한 원격 저장소 활용 방법입니다.
- Thanos 아키텍처
- 사이드카 기반 업로드
- 전역 쿼리 뷰
- 다운샘플링 및 컴팩션
- Cortex 활용
- 멀티테넌트 지원
- 수평적 확장성
- 고가용성 설계
- Grafana Mimir와 Loki
- 메트릭과 로그 통합
- 확장 가능한 쿼리 성능
- 복잡한 상관 관계 분석
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-k8s # Prometheus 인스턴스 이름
namespace: monitoring # 배포될 네임스페이스
spec:
# 기본 Prometheus 설정...
# 원격 쓰기 설정
remoteWrite:
# 모든 메트릭을 Cortex로 전송
- url: "http://cortex-distributor.cortex.svc:9009/api/v1/push" # Cortex API 엔드포인트
queueConfig:
capacity: 10000 # 대기열 용량 (샘플 수) - 네트워크 문제 시 버퍼 역할
maxShards: 200 # 최대 동시 전송 샤드 수 - 병렬 처리 수준 조절
maxSamplesPerSend: 2000 # 한 번에 전송할 최대 샘플 수 - 배치 크기
batchSendDeadline: 5s # 배치 전송 데드라인 - 배치가 차지 않아도 이 시간 후 전송
minBackoff: 30ms # 최소 재시도 간격 - 실패 시 지수 백오프의 시작점
maxBackoff: 5s # 최대 재시도 간격 - 백오프 상한선
writeRelabelConfigs:
# 필요한 경우 레이블 재작성 규칙 추가
# 예: 불필요한 레이블 삭제
- sourceLabels: [__name__] # 메트릭 이름을 기준으로
regex: "go_.*" # go_ 로 시작하는 내부 메트릭
action: drop # 원격 저장소로 전송하지 않음 (로컬만 저장)
# 고해상도 데이터는 짧은 기간 동안만 보관 (로컬)
retention: 7d # 로컬 데이터베이스는 7일만 보관 (Cortex가 장기 저장소 역할)
▶️ 장기 저장 성공 사례: 글로벌 e커머스 플랫폼은 여러 지역에 분산된 쿠버네티스 클러스터에서 Prometheus를 사용했지만, 규제 요구사항으로 3년간 메트릭을 보존해야 했습니다. Thanos를 도입하여 원본 데이터는 14일, 5분 샘플링 데이터는 90일, 시간별 샘플링 데이터는 3년간 S3에 저장하는 다단계 전략을 구현했습니다. 지역별 쿼리가 기본이지만 필요시 글로벌 쿼리도 가능한 아키텍처를 구축했고, 이로 인해 규제 요구사항을 충족하면서도 스토리지 비용을 80% 절감했습니다.
📌 메트릭 선별 및 필터링 전략
효과적인 메트릭 관리를 위한 선별 및 필터링 방법을 알아보겠습니다.
✅ 중요 메트릭 식별
모든 메트릭을 동일하게 취급하지 않고 중요도에 따라 구분합니다.
- 골든 시그널 기반 접근
- RED(Rate, Errors, Duration) 메트릭
- USE(Utilization, Saturation, Errors) 메트릭
- 비즈니스 KPI 관련 메트릭
- 메트릭 우선순위 지정
- 필수(P0): 알림 및 중요 대시보드용
- 중요(P1): 문제 진단용
- 선택(P2): 심층 분석용
- 디버깅(P3): 개발 중에만 필요
- 중요 메트릭의 특성
- 액션 가능성
- 예측 가치
- 낮은 노이즈
- 안정성과 신뢰성
# 중요도별 메트릭 레이블링 및 선택적 원격 저장 예시
# 이 설정은 메트릭 중요도에 따라 레이블을 추가하고 보존 정책을 다르게 적용합니다.
apiVersion: monitoring.coreos.com/v1
kind: Prometheus # Prometheus 커스텀 리소스
metadata:
name: prometheus-k8s # Prometheus 인스턴스 이름
namespace: monitoring # 배포 네임스페이스
spec:
# 기본 설정...
# 메트릭 재레이블링 (수집 시)
metricRelabelConfigs:
# 중요도 레이블 추가 - 모든 메트릭에 기본 중요도 설정
- targetLabel: priority # 추가할 레이블 이름
replacement: p0 # 기본값으로 P0 (필수) 지정
# 특정 메트릭을 P1 (중요)로 분류
- sourceLabels: [__name__] # 메트릭 이름을 기준으로
regex: '(node_cpu|node_memory|kube_pod_status).*' # 시스템 관련 메트릭
targetLabel: priority # priority 레이블 업데이트
replacement: p1 # P1 (중요) 설정
# 디버그 메트릭을 P3로 분류
- sourceLabels: [__name__] # 메트릭 이름을 기준으로
regex: '.*_debug_.*|go_.*' # 디버그 관련 메트릭이나 내부 메트릭
targetLabel: priority # priority 레이블 업데이트
replacement: p3 # P3 (디버깅용) 설정
# 원격 쓰기 설정 - 중요도에 따라 다른 저장소로 전송
remoteWrite:
# P0 (필수) 메트릭만 장기 저장소로 전송 (3년 보존)
- url: "http://longterm-storage/3y-retention" # 장기 저장소 엔드포인트
writeRelabelConfigs:
- sourceLabels: [priority] # priority 레이블 기준
regex: p0 # P0(필수) 메트릭만 선택
action: keep # 조건에 맞는 메트릭만 유지
# P0, P1 메트릭을 중기 저장소로 전송 (90일 보존)
- url: "http://midterm-storage/90d-retention" # 중기 저장소 엔드포인트
writeRelabelConfigs:
- sourceLabels: [priority] # priority 레이블 기준
regex: p[01] # P0 또는 P1 메트릭 선택
action: keep # 조건에 맞는 메트릭만 유지
# P0, P1, P2 메트릭을 단기 저장소로 전송 (30일 보존)
- url: "http://shortterm-storage/30d-retention" # 단기 저장소 엔드포인트
writeRelabelConfigs:
- sourceLabels: [priority] # priority 레이블 기준
regex: p[012] # P0, P1 또는 P2 메트릭 선택
action: keep # 조건에 맞는 메트릭만 유지
✅ 메트릭 필터링 기법
불필요한 메트릭을 필터링하여 스토리지 효율성을 높이는 방법입니다.
- 수집 시점 필터링
- 스크래핑 구성에서 제외
- 레이블 기반 필터링
- 불필요한 타겟 제외
- 레이블 단순화
- 고카디널리티 레이블 제거
- 불필요한 레이블 드롭
- 레이블 변환 및 표준화
- 원격 저장소 전송 전 필터링
- 메트릭 이름 기반 필터링
- 환경별 선별 전송
- 사용 빈도에 따른 필터링
# 메트릭 필터링을 위한 상세 구성 예시
# 이 설정은 필요한 메트릭만 수집하고 불필요한 정보는 필터링합니다.
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus-k8s
namespace: monitoring
spec:
# 기본 설정...
# 전역 스크래핑 설정
scrapeInterval: 30s # 기본 스크래핑 간격
scrapeTimeout: 10s # 스크래핑 타임아웃
evaluationInterval: 30s # 규칙 평가 간격
# 메트릭 필터링 설정
# 1. 글로벌 레이블 재작성 (모든 메트릭에 적용)
metricRelabelConfigs:
# UUID와 같은 고유 ID 제거하여 카디널리티 감소
- sourceLabels: [pod_id] # Pod ID 레이블에서
regex: '(.+)' # 모든 값에 대해
targetLabel: pod_id # 같은 레이블에
replacement: 'redacted' # 'redacted'로 대체 (값 표준화)
# 개발용 메트릭 제외
- sourceLabels: [__name__] # 메트릭 이름에서
regex: '.*_dev_.*|.*_test_.*|.*_debug_.*' # 개발/테스트/디버그 패턴 확인
action: drop # 해당 메트릭 수집 제외
# 특정 네임스페이스의 불필요한 상세 메트릭 제외
- sourceLabels: [__name__, namespace] # 메트릭 이름과 네임스페이스 조합으로
regex: 'kube_pod_container_resource_requests.+;dev-.*' # 개발 환경의 상세 리소스 요청 메트릭
action: drop # 해당 메트릭 수집 제외
# 2. 특정 작업별 필터링 (스크래핑 구성에서)
scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs:
- role: node
relabel_configs:
# 노드 이름만 유지하고 다른 불필요한 레이블 삭제
- action: labelmap # 쿠버네티스 메타 레이블 변환
regex: __meta_kubernetes_node_label_(.+) # 노드 레이블 선택
# 노드 익스포터 특정 메트릭만 수집
metric_relabel_configs:
# 중요한 메트릭 그룹만 포함 (화이트리스트 방식)
- sourceLabels: [__name__]
regex: 'node_cpu_.*|node_memory_.*|node_disk_.*|node_network_.*|node_load.*'
action: keep # 조건에 맞는 메트릭만 유지
# 필요 없는 네트워크 인터페이스 제외
- sourceLabels: [__name__, device]
regex: 'node_network_.*; (lo|br.*|docker.*)' # 루프백/브릿지/도커 인터페이스
action: drop # 해당 메트릭 수집 제외
✅ 자동화된 보존 정책 관리
보존 정책을 효율적으로 관리하는 자동화 방법입니다.
- 동적 보존 정책
- 스토리지 사용량 기반 조정
- 메트릭 중요도에 따른 차등 적용
- 계절적 패턴 고려
- 메트릭 생명주기 관리
- 생성 시점 추적
- 사용 빈도 모니터링
- 자동 보관 및 삭제
- 정책 관리 자동화 도구
- 커스텀 컨트롤러
- 스토리지 모니터링 통합
- 알림 기반 조치
# 동적 보존 정책 관리 컨트롤러 예시
# 이 설정은 메트릭 보존 정책을 자동으로 관리하는 컨트롤러를 정의합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: metric-retention-controller # 동적 보존 정책 관리 컨트롤러
namespace: monitoring
spec:
replicas: 1 # 단일 인스턴스로 실행
selector:
matchLabels:
app: metric-retention-controller
template:
metadata:
labels:
app: metric-retention-controller
spec:
serviceAccountName: prometheus-operator # 필요한 권한을 가진 서비스 계정
containers:
- name: controller
image: custom/retention-controller:v1.0 # 커스텀 컨트롤러 이미지
args:
- "--config=/etc/config/retention-rules.yaml" # 설정 파일
- "--prometheus-url=http://prometheus-k8s.monitoring.svc:9090" # Prometheus API
- "--check-interval=1h" # 점검 주기
- "--apply-changes=true" # 변경 자동 적용
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 50m
memory: 64Mi
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: retention-controller-config
---
# 보존 정책 컨트롤러 설정
apiVersion: v1
kind: ConfigMap
metadata:
name: retention-controller-config
namespace: monitoring
data:
retention-rules.yaml: |
# 기본 보존 정책
defaultRetention: 15d
# 스토리지 기반 동적 정책
storageBasedPolicies:
- storageThreshold: 85% # 스토리지 사용량이 85% 이상이면
retentionAdjustment: -3d # 보존 기간을 3일 줄임
- storageThreshold: 95% # 스토리지 사용량이 95% 이상이면
retentionAdjustment: -7d # 보존 기간을 7일 줄임
emergencyAction: true # 긴급 조치 플래그
- storageThreshold: 70% # 스토리지 사용량이 70% 미만이면
retentionAdjustment: +2d # 보존 기간을 2일 늘림
maxRetention: 30d # 최대 30일까지 늘림
# 메트릭 유형별 보존 정책
metricSpecificPolicies:
- namePattern: ".*_total" # 누적 카운터는
priority: high # 중요도 높음
minRetention: 30d # 최소 30일 보존
- namePattern: "go_.*|process_.*" # 내부 프로세스 메트릭은
priority: low # 중요도 낮음
maxRetention: 7d # 최대 7일 보존
- namePattern: ".*_bucket" # 히스토그램 버킷은
priority: medium # 중요도 중간
downsampleAfter: 3d # 3일 후 다운샘플링
# 알림 설정
alertConfig:
slackWebhook: "https://hooks.slack.com/services/xxx/yyy/zzz"
emailRecipients: "monitoring-team@example.com"
thresholdAlerts:
- threshold: 90%
message: "스토리지 사용량이 90%를 초과했습니다. 보존 기간을 자동으로 줄입니다."
- threshold: 95%
message: "스토리지 사용량이 95%를 초과했습니다. 긴급 정책 적용 중입니다."
▶️ 자동화 보존 정책 사례: 한 금융 서비스 회사는 규제 요구사항에 따라 거래 관련 메트릭을 최소 2년간 보존해야 했지만, 다른 메트릭은 그보다 짧은 기간 보존이 가능했습니다. 이들은 메트릭 이름 패턴과 레이블을 기반으로 분류하는 커스텀 컨트롤러를 개발하여 중요 거래 메트릭은 Thanos를 통해 장기 저장소로 전송하고, 일반 시스템 메트릭은 14일, 디버깅 메트릭은 3일만 보존하도록 자동화했습니다. 또한 스토리지 사용량이 90%를 초과하면 자동으로 비중요 메트릭의 보존 기간을 줄이고 알림을 발생시키는 기능을 구현했습니다. 이 시스템 덕분에 수동 개입 없이도 규제 요구사항을 충족하면서 스토리지 비용을 최적화할 수 있었습니다.
📌 실전 구현: Prometheus 메트릭 보존 정책 아키텍처
지금까지 배운 개념들을 종합하여 실제 프로덕션 환경에 적용할 수 있는 종합 아키텍처를 설계해 보겠습니다.
✅ 멀티 단계 보존 아키텍처
아래 설계는 규모가 큰 쿠버네티스 환경에서 Prometheus 메트릭 데이터를 효율적으로 관리하기 위한 종합적인 아키텍처입니다.
# 멀티 단계 보존 아키텍처 개요
+--------------------------------+
| 애플리케이션 / 인프라 서비스 |
+----------------+---------------+
| 메트릭 노출
v
+----------------+---------------+
| Prometheus 서버 (핫 스토리지) |
| - 원본 데이터: 7일 |
| - 고해상도, 고성능 쿼리 |
+----------------+---------------+
| |
| 원격 쓰기 | Thanos 사이드카
v v
+------+------+ +-------+--------+
| Cortex 클러스터| | Thanos 컴포넌트 |
| - P0/P1 메트릭 | | - 모든 메트릭 |
| - 30일 보존 | | - 컴팩션/다운샘플|
+------+------+ +-------+--------+
| |
v v
+------+------+ +-------+--------+
| 관계형 DB | | 객체 스토리지 |
| - 집계 데이터 | | - 원본: 30일 |
| - 1년 보존 | | - 5m: 90일 |
+-------------+ | - 1h: 1년 |
+----------------+
✅ 프로덕션 구현 단계
실제 환경에서 효과적인 메트릭 보존 정책을 구현하기 위한 단계별 접근법입니다.
- 현재 상태 분석
- 현재 메트릭 수집량 측정
- 성장률 예측
- 쿼리 패턴 분석
- 메트릭 분류 및 우선순위 지정
- 중요도 기반 분류
- 레이블 전략 최적화
- 스크래핑 주기 차등화
- 다단계 스토리지 구현
- 핫 스토리지 구성
- 장기 저장소 설정
- 다운샘플링 규칙 정의
- 모니터링 및 관리 자동화
- 스토리지 사용량 모니터링
- 동적 정책 조정
- 성능 영향 측정
# 종합적인 메트릭 보존 아키텍처 구현 예시
# 이 설정은 Prometheus와 Thanos를 사용한 멀티 단계 보존 아키텍처를 구현합니다.
# 이 아키텍처는 단기, 중기, 장기 데이터 보존을 효율적으로 관리합니다.
# 1. Prometheus 설정 - 단기 데이터 저장 계층(핫 스토리지)
apiVersion: monitoring.coreos.com/v1 # Prometheus Operator CRD API 버전
kind: Prometheus # Prometheus 커스텀 리소스 정의
metadata:
name: prometheus-k8s # Prometheus 인스턴스 이름
namespace: monitoring # 모니터링 네임스페이스에 배포
spec:
replicas: 2 # 고가용성 확보를 위한 복제본 2개 실행
# 한 인스턴스가 실패해도 서비스 유지
version: v2.35.0 # 사용할 Prometheus 버전 지정
retention: 7d # 핫 스토리지 보존 기간 (7일)
# 최신 고해상도 데이터는 7일만 유지
retentionSize: 500GB # 최대 스토리지 크기 제한
# 500GB 초과 시 오래된 데이터부터 삭제
# Thanos 사이드카 설정 - Prometheus와 함께 실행되어 장기 저장소 연결
thanos:
image: quay.io/thanos/thanos:v0.26.0 # Thanos 이미지 및 버전 지정
version: v0.26.0 # Thanos 버전 명시
objectStorageConfig: # 객체 스토리지 연결 설정
name: thanos-objstore-config # S3 같은 객체 스토리지 접근 정보가 있는 시크릿 이름
key: objstore.yaml # 시크릿 내 설정 파일 키
# 메트릭 재레이블링으로 카디널리티 관리 - 스토리지 효율성 향상을 위한 설정
metricRelabelConfigs:
# 고카디널리티 레이블 제거 - 스토리지 사용량 감소
- sourceLabels: [pod_name] # pod_name 레이블 선택 (고유값이 많음)
regex: '(.+)' # 모든 pod_name 값에 매칭
targetLabel: pod_id # pod_id 레이블로 처리
replacement: '' # 값을 비워서 실질적으로 제거
action: labeldrop # 해당 레이블 자체를 완전히 삭제
# 중요도 레이블 추가 - 선별적 장기 저장을 위한 분류
- sourceLabels: [__name__] # 메트릭 이름 기준으로
regex: '(container_.*|kube_pod_container_status_.*|kube_deployment_status_.*)'
# 컨테이너와 쿠버네티스 상태 관련 중요 메트릭
targetLabel: retention_class # retention_class 레이블 추가
replacement: 'critical' # 'critical' 값 부여 (높은 중요도)
# 원격 쓰기 설정 (Cortex로) - 추가 저장 및 처리를 위한 외부 시스템 연결
remoteWrite:
- url: "http://cortex-distributor.cortex.svc:9009/api/v1/push" # Cortex API 엔드포인트
writeRelabelConfigs: # 원격 저장 전 필터링 규칙
- sourceLabels: [retention_class] # retention_class 레이블 확인
regex: 'critical' # 'critical' 값을 가진 메트릭만
action: keep # 선택해서 Cortex로 전송 (나머지는 제외)
---
# 2. Thanos 컴포넌트 설정 - 장기 저장 및 쿼리 계층
# 2.1 Thanos 쿼리 컴포넌트 - 여러 데이터 소스에 분산된 메트릭을 통합 조회
apiVersion: apps/v1
kind: Deployment
metadata:
name: thanos-query # 쿼리 서비스 이름
namespace: monitoring # 네임스페이스
spec:
replicas: 2 # 고가용성 확보를 위한 복제본 수
selector:
matchLabels:
app: thanos-query # 파드 선택자
template:
metadata:
labels:
app: thanos-query # 파드 레이블
spec:
containers:
- name: thanos # 컨테이너 이름
image: quay.io/thanos/thanos:v0.26.0 # Thanos 이미지
args:
- "query" # 쿼리 컴포넌트로 실행
- "--log.level=info" # 로그 레벨 설정
- "--query.replica-label=replica" # 복제본 구분을 위한 레이블
- "--store=dnssrv+_grpc._tcp.thanos-store.monitoring.svc" # Store Gateway 연결
# DNS SRV 레코드를 통한 서비스 디스커버리
- "--store=dnssrv+_grpc._tcp.thanos-sidecar.monitoring.svc" # Sidecar 연결
# Prometheus의 실시간 데이터와 장기 저장소 모두 쿼리
ports:
- name: http # HTTP 포트 (UI 및 API용)
containerPort: 10902 # Thanos 쿼리 HTTP 포트
- name: grpc # gRPC 포트 (내부 통신용)
containerPort: 10901 # Thanos 내부 통신 포트
---
# 2.2 Thanos Store Gateway - 객체 스토리지의 데이터를 쿼리 가능하게 함
apiVersion: apps/v1
kind: StatefulSet # 영구 스토리지가 필요해 StatefulSet 사용
metadata:
name: thanos-store # Store Gateway 이름
namespace: monitoring # 네임스페이스
spec:
replicas: 3 # 여러 복제본으로 부하 분산 및 가용성 확보
selector:
matchLabels:
app: thanos-store # 파드 선택자
serviceName: "thanos-store" # 헤드리스 서비스 이름 (StatefulSet용)
template:
metadata:
labels:
app: thanos-store # 파드 레이블
spec:
containers:
- name: thanos # 컨테이너 이름
image: quay.io/thanos/thanos:v0.26.0 # Thanos 이미지
args:
- "store" # Store Gateway로 실행
- "--log.level=info" # 로그 레벨
- "--data-dir=/var/thanos/store" # 로컬 캐시 디렉토리
- "--objstore.config-file=/etc/thanos/objstore.yaml" # 객체 스토리지 설정
# 인덱스 캐시 및 청크 풀 설정으로 성능 최적화
- "--index-cache-size=5GB" # 메타데이터 인덱스 캐시 크기 (쿼리 속도 향상)
- "--chunk-pool-size=4GB" # 데이터 청크 메모리 풀 (메모리 효율화)
volumeMounts:
- name: data # 캐시 저장용 볼륨
mountPath: /var/thanos/store # 마운트 경로
- name: thanos-objstore-config # 객체 스토리지 설정 볼륨
mountPath: /etc/thanos # 마운트 경로
readOnly: true # 읽기 전용으로 마운트
volumeClaimTemplates: # StatefulSet의 영구 볼륨 설정
- metadata:
name: data # 볼륨 이름
spec:
storageClassName: standard # 스토리지 클래스
resources:
requests:
storage: 100Gi # 각 복제본당 100GB 용량 요청
---
# 2.3 Thanos Compactor - 장기 저장소의 데이터 다운샘플링 및 최적화
apiVersion: apps/v1
kind: Deployment
metadata:
name: thanos-compact # Compactor 이름
namespace: monitoring # 네임스페이스
spec:
replicas: 1 # 단일 인스턴스로 실행 (중복 컴팩션 방지)
selector:
matchLabels:
app: thanos-compact # 파드 선택자
template:
metadata:
labels:
app: thanos-compact # 파드 레이블
spec:
containers:
- name: thanos # 컨테이너 이름
image: quay.io/thanos/thanos:v0.26.0 # Thanos 이미지
args:
- "compact" # Compactor로 실행
- "--log.level=info" # 로그 레벨
- "--data-dir=/var/thanos/compact" # 임시 작업 디렉토리
- "--objstore.config-file=/etc/thanos/objstore.yaml" # 객체 스토리지 설정
- "--wait" # 지속적인 컴팩션 수행 (데몬 모드로 실행)
- "--downsampling.enable" # 다운샘플링 활성화 (데이터 압축)
# 메트릭 해상도별 보존 기간 설정 - 시간이 지날수록 해상도 감소
- "--retention.resolution-raw=30d" # 원본 해상도 데이터는 30일 보존
# 모든 원시 데이터 포인트 유지
- "--retention.resolution-5m=90d" # 5분 해상도 데이터는 90일 보존
# 5분 간격으로 집계된 중간 해상도
- "--retention.resolution-1h=1y" # 1시간 해상도 데이터는 1년 보존
# 1시간 간격으로 집계된 낮은 해상도
volumeMounts:
- name: data # 임시 작업용 볼륨
mountPath: /var/thanos/compact # 마운트 경로
- name: thanos-objstore-config # 객체 스토리지 설정 볼륨
mountPath: /etc/thanos # 마운트 경로
readOnly: true # 읽기 전용으로 마운트
volumes:
- name: data # 임시 데이터 볼륨
emptyDir: {} # 임시 디렉토리 (파드 종료 시 삭제됨)
- name: thanos-objstore-config # 객체 스토리지 설정
secret:
secretName: thanos-objstore-config # 시크릿 이름
---
# 3. Grafana 대시보드 설정 - 메트릭 보존 상태 및 스토리지 모니터링
apiVersion: v1
kind: ConfigMap # 설정 맵 리소스
metadata:
name: grafana-dashboards-retention # 대시보드 설정 이름
namespace: monitoring # 네임스페이스
data:
metric-retention-overview.json: | # 대시보드 JSON 정의
{
"dashboard": {
"title": "메트릭 보존 및 스토리지 현황", # 대시보드 제목
"panels": [
{
"title": "Prometheus 스토리지 사용량", # 첫 번째 패널 - 스토리지 모니터링
"type": "graph", # 그래프 형식
"datasource": "Prometheus", # 데이터 소스
"targets": [
{
"expr": "prometheus_tsdb_storage_blocks_bytes{job=\"prometheus-k8s\"}",
# Prometheus 블록 스토리지 사용량 메트릭
"legendFormat": "{{instance}} - 블록 크기" # 범례 형식
}
]
},
{
"title": "샘플 수집 속도", # 두 번째 패널 - 샘플 수집률 모니터링
"type": "graph", # 그래프 형식
"datasource": "Prometheus", # 데이터 소스
"targets": [
{
"expr": "rate(prometheus_tsdb_head_samples_appended_total{job=\"prometheus-k8s\"}[5m])",
# 초당 수집되는 샘플 수 계산 (5분 평균)
"legendFormat": "{{instance}} - 초당 샘플 수" # 범례 형식
}
]
},
{
"title": "중요도별 메트릭 수", # 세 번째 패널 - 중요도 분류별 메트릭 수
"type": "graph", # 그래프 형식
"datasource": "Prometheus", # 데이터 소스
"targets": [
{
"expr": "count by (retention_class) (count by (retention_class, __name__, job) ({__name__=~\".+\"}))",
# retention_class별 고유 메트릭 수 집계
"legendFormat": "{{retention_class}}" # 범례 형식 (critical, 기타 등)
}
]
}
]
}
}▶️ 종합 구현 사례: 한 대규모 전자상거래 플랫폼은 피크 시즌에 트래픽이 10배 이상 증가하는 특성을 고려하여 유연한 메트릭 보존 정책을 구현했습니다. 이들은 Prometheus, Thanos, Grafana Mimir를 조합하여 세 가지 중요도 등급으로 메트릭을 분류했습니다:
- 비즈니스 중요 메트릭 (주문 처리, 결제 성공률, 카트 전환율):
- 원본 데이터 30일 보존 (Prometheus + Thanos)
- 5분 집계 데이터 180일 보존 (Mimir)
- 1시간 집계 데이터 3년 보존 (객체 스토리지)
- 시스템 중요 메트릭 (CPU, 메모리, 디스크, 네트워크):
- 원본 데이터 14일 보존
- 5분 집계 데이터 90일 보존
- 1시간 집계 데이터 1년 보존
- 일반 메트릭 (내부 상태, 디버그 정보):
- 원본 데이터 3일 보존
- 집계 데이터 저장 안 함
또한 피크 시즌(11월~1월)에는 수집 빈도와 보존 정책을 자동으로 조정하는 스케줄러를 구현했습니다. 이 통합 시스템은 초당 50만 개 이상의 샘플을 처리하면서도 쿼리 성능을 유지했고, 규제 요구사항을 충족하면서 스토리지 비용을 연간 60% 절감했습니다.
📌 Summary
이번 글에서는 쿠버네티스 환경에서 Prometheus 메트릭 데이터의 효과적인 보존 정책에 대해 알아보았습니다. 다음과 같은 내용을 다루었습니다:
- 메트릭 데이터 증가 이해: 모니터링 시스템에서 카디널리티, 스크래핑 빈도, 보존 기간이 스토리지 요구사항에 어떤 영향을 미치는지 살펴보고, 데이터 증가를 예측하는 방법을 계산 예제와 함께 알아보았습니다.
- Prometheus 저장소 최적화: TSDB 아키텍처의 블록 기반 스토리지, 데이터 압축 원리, 컴팩션 과정을 이해하고, 샘플 수집 빈도 조정과 카디널리티 관리를 통한 스토리지 효율성 최적화 방법을 구체적인 설정 예제와 함께 확인했습니다.
- 장기 메트릭 저장 전략: 핫-웜-콜드 다단계 스토리지 아키텍처를 구현하는 방법과 시간 경과에 따른 데이터 다운샘플링 전략, Thanos, Cortex, Mimir와 같은 원격 저장소 통합 방법을 살펴보았습니다.
- 메트릭 선별 및 필터링: 골든 시그널(RED, USE) 기반의 중요 메트릭 식별, 우선순위 지정, 효과적인 필터링 기법을 통한 스토리지 최적화 방법을 알아보았습니다.
- 자동화된 보존 정책 관리: 스토리지 사용량 기반 동적 보존 정책, 메트릭 생명주기 관리, 자동화 도구 구현 방법을 코드 예제와 함께 다루었습니다.
- 종합 구현 사례: 현실 세계의 대규모 환경에서 중요도별로 메트릭을 분류하고 차등화된 보존 정책을 적용한 성공 사례를 살펴보았습니다.
효과적인 메트릭 보존 정책은 단순히 데이터 저장 기간을 설정하는 것 이상의 전략적 접근이 필요합니다. 비즈니스 요구사항과 기술적 제약 사이에서 적절한 균형을 찾고, 데이터의 가치에 따라 차등화된 보존 전략을 적용함으로써 스토리지 비용을 최적화하면서도 필요한 모니터링 기능을 유지할 수 있습니다. 지속적인 모니터링과 정책 개선을 통해 장기적으로 확장 가능한 모니터링 인프라를 구축하는 것이 중요합니다.
728x90
'Observability > Prometheus' 카테고리의 다른 글
| EP18 [Part 6: 고급 모니터링 전략] 보안 및 성능 최적화 (0) | 2025.03.25 |
|---|---|
| EP17 [Part 6: 고급 모니터링 전략] 고성능 모니터링 설정 (0) | 2025.03.25 |
| EP15 [Part 5: 애플리케이션 레벨 모니터링] 웹 애플리케이션 모니터링 (Airflow 등) (0) | 2025.03.25 |
| EP14 [Part 5: 애플리케이션 레벨 모니터링] 데이터베이스 모니터링 (MySQL, PostgreSQL) (0) | 2025.03.24 |
| EP13 [Part 5: 애플리케이션 레벨 모니터링] 다양한 애플리케이션 익스포터 소개 (0) | 2025.03.24 |