728x90
이번 글에서는 쿠버네티스 모니터링의 새로운 영역인 애플리케이션 레벨 모니터링으로 나아가겠습니다. 인프라 모니터링을 넘어 실제 애플리케이션의 성능과 상태를 추적하는 것은 전체 시스템 관찰성의 핵심입니다. 이번 에피소드에서는 다양한 애플리케이션 익스포터의 종류와 특징, 설치 및 구성 방법, 그리고 실제 워크로드에 적용하기 위한 전략을 살펴보겠습니다. 데이터베이스, 웹 서버, 메시징 시스템 등 다양한 애플리케이션을 모니터링하기 위한 익스포터를 소개하고, 이들이 제공하는 메트릭을 효과적으로 활용하는 방법을 실전 예제와 함께 알아보겠습니다.
📌 애플리케이션 모니터링의 중요성
인프라 모니터링만으로는 애플리케이션의 건강 상태와 성능을 완전히 파악하기 어렵습니다. 애플리케이션 레벨 모니터링이 중요한 이유를 살펴보겠습니다.
✅ 인프라 모니터링과 애플리케이션 모니터링의 차이
인프라 모니터링과 애플리케이션 모니터링은 서로 다른 관점에서 시스템을 관찰합니다.
- 인프라 모니터링
- 노드, 파드, 컨테이너 리소스 사용량
- 네트워크 트래픽 및 연결 상태
- 디스크 I/O 및 저장소 용량
- 클러스터 컴포넌트 상태
- 애플리케이션 모니터링
- 애플리케이션 응답 시간 및 지연 시간
- 요청 처리량 및 오류율
- 비즈니스 메트릭 (사용자 로그인, 트랜잭션 등)
- 내부 애플리케이션 상태 및 큐 깊이
# 인프라 모니터링 vs. 애플리케이션 모니터링 비교
# 아래는 각 모니터링 유형에서 수집되는 메트릭의 예시를 보여줍니다
# 인프라 메트릭 예시 (node-exporter에서 수집)
- node_cpu_seconds_total{mode="user"} # CPU의 user 모드 사용 시간을 초 단위로 측정
- node_memory_MemAvailable_bytes # 현재 사용 가능한 메모리 용량을 바이트 단위로 표시
- container_cpu_usage_seconds_total # 각 컨테이너의 CPU 사용 시간 누적값
# 애플리케이션 메트릭 예시 (애플리케이션 익스포터에서 수집)
- http_requests_total{status="200", path="/api"} # 성공적인(200) API 요청의 총 횟수를 경로별로 추적
- http_request_duration_seconds # HTTP 요청 처리에 소요된 시간(초)을 측정
- app_users_active # 현재 활성 상태인 사용자 수를 실시간으로 표시
- mysql_global_status_queries # MySQL 데이터베이스에서 실행된 쿼리 총 개수
✅ 애플리케이션 모니터링이 제공하는 이점
애플리케이션 레벨 모니터링을 통해 얻을 수 있는 주요 이점을 알아보겠습니다.
- 사용자 경험 통찰력
- 실제 사용자가 경험하는 성능 측정
- 서비스 수준 목표(SLO) 및 합의(SLA) 준수 여부 확인
- 성능 병목 현상의 정확한 위치 파악
- 문제 조기 발견
- 인프라는 정상이지만 애플리케이션에 문제가 있는 경우 감지
- 느린 데이터베이스 쿼리, 메모리 누수 등 내부 문제 식별
- 문제가 사용자에게 영향을 미치기 전에 조치 가능
- 비즈니스 메트릭 연계
- 기술적 메트릭과 비즈니스 성과 연결
- 예: 서버 응답 시간과 전환율/매출 간의 상관관계
- 데이터 기반 의사결정 지원
▶️ 실제 사례: 한 전자상거래 회사는 인프라 모니터링만으로는 결제 과정의 간헐적인 지연을 발견하지 못했습니다. 애플리케이션 레벨 모니터링을 도입한 후, 특정 결제 API 엔드포인트의 응답 시간 문제를 발견하고 해결하여 전환율을 15% 향상시켰습니다.
📌 Prometheus 익스포터 개요
Prometheus 익스포터는 다양한 애플리케이션과 서비스에서 메트릭을 수집하여 Prometheus가 이해할 수 있는 형식으로 변환하는 도구입니다.
✅ 익스포터의 기본 개념
익스포터의 작동 방식과 주요 특징을 살펴보겠습니다.
- 익스포터의 역할
- 애플리케이션 또는 서비스의 내부 메트릭 노출
- 메트릭을 Prometheus 형식으로 변환
- HTTP 엔드포인트(일반적으로 /metrics)를 통해 메트릭 제공
- 익스포터 배포 방식
- 사이드카 컨테이너: 애플리케이션 파드 내에 함께 배포
- 독립 파드: 애플리케이션과 별도로 배포
- 데몬셋: 클러스터의 모든 노드에 배포
- 주요 고려사항
- 메트릭 수집 빈도와 성능 영향
- 보안 및 인증 설정
- 고가용성 구성
# 익스포터 배포 방식 예시: 사이드카 패턴
# 이 YAML은 사이드카 패턴으로 애플리케이션과 익스포터를 배포하는 예시입니다
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-with-exporter # 배포 리소스의 이름
spec:
selector:
matchLabels:
app: myapp # 파드 선택을 위한 레이블 셀렉터
template:
metadata:
labels:
app: myapp # 파드에 적용할 레이블
# Prometheus가 자동으로 메트릭을 스크래핑하도록 어노테이션 추가
annotations:
prometheus.io/scrape: "true" # 이 파드를 스크래핑 대상으로 지정
prometheus.io/port: "9104" # 익스포터가 사용하는 포트
prometheus.io/path: "/metrics" # 메트릭 엔드포인트 경로
spec:
containers:
- name: myapp # 메인 애플리케이션 컨테이너
image: myapp:1.0 # 애플리케이션 이미지
ports:
- containerPort: 8080 # 애플리케이션 포트
# 애플리케이션 컨테이너 설정...
- name: myapp-exporter # 익스포터 사이드카 컨테이너
image: myapp-exporter:1.0 # 익스포터 이미지
ports:
- containerPort: 9104 # 익스포터가 메트릭을 노출하는 포트
# 익스포터가 애플리케이션에 접근하기 위한 환경 변수
env:
- name: MYAPP_URI
value: "http://localhost:8080/status" # 같은 파드 내에서 localhost로 접근
resources:
# 익스포터는 일반적으로 경량이지만, 리소스 제한을 설정하는 것이 좋음
limits:
memory: "128Mi" # 메모리 한도
cpu: "100m" # CPU 한도 (1 코어의 10%)
✅ 공식 vs 커뮤니티 익스포터
Prometheus 익스포터는 공식 및 커뮤니티에서 개발한 다양한 종류가 있습니다.
- 공식 익스포터
- Prometheus 팀에서 직접 관리
- 높은 품질과 안정성
- 일관된 설계 및 문서화
- 예: Node Exporter, Blackbox Exporter
- 커뮤니티 익스포터
- 다양한 개발자와 기업에서 기여
- 더 넓은 범위의 시스템 지원
- 품질과 유지보수 수준이 다양함
- 예: MySQL Exporter, Redis Exporter
▶️ 선택 기준: 익스포터를 선택할 때는 다음 요소를 고려하세요.
- 활발한 개발 및 유지보수 (최근 커밋 확인)
- 명확한 문서화
- 높은 GitHub 별점과 많은 사용자
- 보안 업데이트 빈도
- 기능 완성도 및 커스터마이징 가능성
📌 주요 애플리케이션 익스포터 소개
다양한 애플리케이션과 서비스를 위한 주요 익스포터를 카테고리별로 소개합니다.
✅ 데이터베이스 익스포터
데이터베이스 성능과 상태는 대부분의 애플리케이션에서 중요한 부분입니다.
- MySQL Exporter
- 쿼리 수행 시간, 연결 수, 버퍼 사용량 등 추적
- 복제 상태 및 지연 모니터링
- InnoDB 버퍼 풀 활용도
# MySQL Exporter 배포 예시
# 이 매니페스트는 MySQL 데이터베이스를 모니터링하기 위한 익스포터 배포를 정의합니다
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-exporter # 배포 이름
namespace: monitoring # 배포할 네임스페이스
spec:
selector:
matchLabels:
app: mysql-exporter # 파드 셀렉터
template:
metadata:
labels:
app: mysql-exporter # 파드 레이블
annotations:
prometheus.io/scrape: "true" # Prometheus 자동 검색 활성화
prometheus.io/port: "9104" # 익스포터 포트 지정
spec:
containers:
- name: mysql-exporter
image: prom/mysqld-exporter:v0.13.0 # 공식 MySQL 익스포터 이미지
ports:
- containerPort: 9104 # 익스포터가 메트릭을 노출하는 포트
name: metrics # 포트 이름 지정
env:
# 데이터베이스 연결 정보 환경 변수
- name: DATA_SOURCE_NAME # MySQL 연결 문자열을 위한 환경 변수
# 실제 환경에서는 Secret으로 관리해야 함
valueFrom:
secretKeyRef:
name: mysql-credentials # 인증 정보를 담고 있는 시크릿 이름
key: data-source-name # 형식: user:password@(hostname:port)/dbname
resources:
limits: # 리소스 한도 설정
memory: "128Mi" # 메모리 최대 사용량
cpu: "100m" # CPU 최대 사용량 (0.1 코어)
- PostgreSQL Exporter
- 트랜잭션 수, 행 연산, 인덱스 사용률
- WAL(Write-Ahead Log) 활동
- 쿼리 성능 및 잠금 상태
- MongoDB Exporter
- 작업 수, 연결 상태, 복제 상태
- 문서 작업 및 인덱스 크기
- 스토리지 엔진 통계
- Redis Exporter
- 메모리 사용량, 명령 실행 수, 네트워크 활동
- 키스페이스 통계 및 만료 정보
- 클라이언트 연결 및 차단된 클라이언트
▶️ 주요 DB 익스포터 메트릭: 데이터베이스 익스포터에서 특히 주목해야 할 메트릭들은 다음과 같습니다.
- 쿼리 응답 시간 분포 (히스토그램)
- 초당 쿼리 처리량
- 연결 풀 상태
- 캐시 효율성
- 디스크 I/O 활동
✅ 웹 서버 및 애플리케이션 서버 익스포터
웹 기반 애플리케이션의 프론트엔드와 미들웨어 모니터링을 위한 익스포터입니다.
- NGINX Exporter
- 활성 연결, 요청 처리량, 오류 수
- 응답 코드 분포 (2xx, 3xx, 4xx, 5xx)
- 업스트림 서버 상태
# NGINX Exporter ServiceMonitor 예시
# Prometheus Operator를 사용할 경우 ServiceMonitor를 통해 스크래핑 설정을 관리할 수 있습니다
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor # Prometheus Operator CRD
metadata:
name: nginx-exporter # ServiceMonitor 이름
namespace: monitoring # 리소스가 위치한 네임스페이스
spec:
selector:
matchLabels:
app: nginx-exporter # 모니터링할 서비스 선택기
endpoints:
- port: metrics # Service의 'metrics' 포트를 스크래핑
interval: 15s # 15초마다 메트릭 수집 (스크래핑 주기)
scrapeTimeout: 10s # 스크래핑 작업 시간 제한 (10초)
path: /metrics # 메트릭 엔드포인트 경로
relabelings: # 메트릭 레이블 재정의
- sourceLabels: # 원본 레이블
- __meta_kubernetes_pod_name
targetLabel: pod # 대상 레이블 (pod로 변환)
- sourceLabels:
- __meta_kubernetes_namespace
targetLabel: namespace # 대상 레이블 (namespace로 변환)
namespaceSelector: # 스크래핑할 네임스페이스 선택
matchNames:
- web-servers # 'web-servers' 네임스페이스에서만 스크래핑
- Apache Exporter
- 워커 상태, 요청 처리 시간
- 서버 성능 및 로드 통계
- 가상 호스트별 메트릭
- Tomcat Exporter
- JVM 메모리 및 가비지 컬렉션 통계
- 서블릿 및 JSP 처리 메트릭
- 데이터베이스 연결 풀 상태
- HAProxy Exporter
- 프론트엔드 및 백엔드 연결 상태
- 세션 속도 및 지연 시간
- 서버 상태 및 가중치
▶️ 웹 서버 모니터링 팁: 웹 애플리케이션을 효과적으로 모니터링하려면:
- 요청 지연 시간을 백분위수(예: 95%, 99%)로 측정하여 이상치 파악
- 오류율을 엔드포인트 및 상태 코드별로 분석
- 클라이언트 IP 또는 지역별 트래픽 패턴 식별
- 백엔드 서비스와의 통합 지점 모니터링
✅ 메시징 시스템 익스포터
분산 시스템에서 메시징 플랫폼은 중요한 구성 요소이며, 이를 위한 익스포터들이 있습니다.
- RabbitMQ Exporter
- 큐 깊이, 메시지 처리량, 소비자 수
- 채널 및 연결 상태
- 노드 상태 및 클러스터 건강도
- Kafka Exporter
- 브로커 상태, 컨슈머 그룹 지연
- 파티션 복제 상태
- 메시지 처리량 및 크기
# Kafka 익스포터 설정 예시
# 이 매니페스트는 Kafka 클러스터를 모니터링하기 위한 익스포터 배포를 정의합니다
apiVersion: apps/v1
kind: Deployment
metadata:
name: kafka-exporter # 배포 이름
namespace: messaging # 배포될 네임스페이스
spec:
selector:
matchLabels:
app: kafka-exporter # 파드 셀렉터
template:
metadata:
labels:
app: kafka-exporter # 파드 레이블
spec:
containers:
- name: kafka-exporter
image: danielqsj/kafka-exporter:latest # Kafka 익스포터 이미지
args:
# 각 Kafka 브로커 주소 지정
- "--kafka.server=kafka-broker-0.kafka-headless.messaging.svc:9092" # 첫 번째 브로커
- "--kafka.server=kafka-broker-1.kafka-headless.messaging.svc:9092" # 두 번째 브로커
- "--kafka.server=kafka-broker-2.kafka-headless.messaging.svc:9092" # 세 번째 브로커
- "--topic.filter=.*" # 모든 토픽을 모니터링 (정규식)
- "--group.filter=.*" # 모든 컨슈머 그룹 모니터링 (정규식)
ports:
- name: metrics # 포트 이름
containerPort: 9308 # 익스포터 메트릭 포트
resources: # 리소스 제한 설정
limits:
cpu: 200m # 최대 CPU 사용량 (0.2 코어)
memory: 256Mi # 최대 메모리 사용량
requests:
cpu: 100m # 요청 CPU 사용량 (0.1 코어)
memory: 128Mi # 요청 메모리 사용량
- ActiveMQ Exporter
- 큐 및 토픽 통계
- 브로커 메모리 사용량
- 지속성 저장소 성능
▶️ 중요 메시징 메트릭: 메시징 시스템에서 특히 집중해야 할 메트릭들:
- 메시지 지연 시간 (생산부터 소비까지)
- 큐 백로그 크기 및 성장률
- 데드 레터 큐 활동
- 컨슈머 그룹별 처리량
- 디스크 및 메모리 사용량
✅ 캐싱 및 인메모리 저장소 익스포터
캐싱 시스템은 애플리케이션 성능에 큰 영향을 미치며, 이를 모니터링하기 위한 익스포터들이 있습니다.
- Memcached Exporter
- 히트/미스 비율, 연결 수
- 메모리 사용량 및 항목 수
- 네트워크 I/O 통계
- Redis Exporter
- 메모리 사용량 및 단편화
- 명령어별 실행 통계
- 만료 및 제거 정책 효율성
[Redis Exporter에서 수집하는 주요 메트릭을 보여주는 대시보드 이미지]
▶️ 캐싱 시스템 모니터링 전략: 캐싱 시스템 모니터링 시 다음 사항에 주의하세요.
- 캐시 적중률이 낮다면 캐싱 전략 재검토 필요
- 메모리 한계에 도달하면 제거 정책 최적화
- 연결 포화도가 높으면 연결 풀 또는 클라이언트 설정 조정
- 키 만료 및 제거 속도 추적
✅ 클라우드 서비스 및 API 익스포터
클라우드 네이티브 환경에서 외부 서비스와의 통합을 모니터링하기 위한 익스포터들입니다.
- AWS Exporter
- EC2, RDS, S3 등의 서비스 메트릭
- 비용 및 사용량 데이터
- 할당량 및 제한 모니터링
- GCP Exporter
- GKE, Cloud SQL, Cloud Storage 메트릭
- 과금 정보 및 API 사용량
- 서비스 상태 및 성능
- Azure Exporter
- AKS, 가상 머신, 저장소 계정 메트릭
- 네트워크 및 보안 상태
- 리소스 그룹별 사용량
# AWS Exporter 설정 예시
# 이 ConfigMap은 AWS CloudWatch 메트릭을 Prometheus로 가져오기 위한 설정을 정의합니다
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-exporter-config # ConfigMap 이름
namespace: monitoring # 네임스페이스
data:
config.yml: |
region: us-west-2 # AWS 리전 지정
metrics:
# EC2 인스턴스 CPU 사용률 수집 설정
- aws_namespace: AWS/EC2 # AWS 메트릭 네임스페이스
aws_metric_name: CPUUtilization # 수집할 메트릭 이름
aws_dimensions: [InstanceId] # 메트릭을 구분하는 차원
aws_statistics: [Average, Maximum] # 수집할 통계 유형
# RDS 인스턴스 연결 수 수집 설정
- aws_namespace: AWS/RDS # RDS 네임스페이스
aws_metric_name: DatabaseConnections # 연결 수 메트릭
aws_dimensions: [DBInstanceIdentifier] # DB 인스턴스별 구분
aws_statistics: [Sum] # 합계 통계 수집
# S3 버킷 크기 수집 설정
- aws_namespace: AWS/S3 # S3 네임스페이스
aws_metric_name: BucketSizeBytes # 버킷 크기 메트릭
aws_dimensions: [BucketName, StorageType] # 버킷 및 스토리지 유형 차원
aws_statistics: [Average] # 평균 통계 수집
# 사용자 지정 태그 기반 필터링 - 특정 태그를 가진 리소스만 모니터링
aws_tag_select:
environment: [production, staging] # 환경 태그가 production 또는 staging인 리소스
application: [web, api, database] # 애플리케이션 태그가 web, api 또는 database인 리소스
▶️ 클라우드 모니터링 모범 사례: 클라우드 서비스 모니터링 시 고려할 사항:
- 비용 관련 메트릭도 함께 추적하여 비용 최적화
- 서비스 할당량 접근 시 사전 알림 설정
- 멀티 클라우드 환경에서 일관된 메트릭 정의
- API 속도 제한 및 할당량 모니터링
📌 애플리케이션 메트릭 노출 방법
애플리케이션이 직접 Prometheus 형식의 메트릭을 노출할 수 있는 방법을 알아보겠습니다.
✅ 코드 계측을 통한 내장 메트릭
애플리케이션 코드에 직접 계측 코드를 추가하여 메트릭을 노출하는 방법입니다.
- 주요 언어별 Prometheus 클라이언트 라이브러리
- Go: github.com/prometheus/client_golang
- Java: io.prometheus.client
- Python: prometheus_client
- Node.js: prom-client
- 일반적으로 계측하는 지표
- 요청 처리 시간 (히스토그램)
- 요청/응답 수 (카운터)
- 활성 연결 또는 작업 (게이지)
- 큐 크기 및 처리 시간
// Java Spring Boot 애플리케이션에서 Prometheus 메트릭 노출 예시
// Spring Boot 애플리케이션에 Prometheus 메트릭을 추가하는 예제 코드입니다
// 1. 의존성 추가 (build.gradle)
// implementation 'org.springframework.boot:spring-boot-starter-actuator' // Spring Boot Actuator
// implementation 'io.micrometer:micrometer-registry-prometheus' // Prometheus 메트릭 등록기
// 2. 설정 파일 (application.yml)
// management:
// endpoints:
// web:
// exposure:
// include: prometheus // /actuator/prometheus 엔드포인트 노출
// metrics:
// export:
// prometheus:
// enabled: true // Prometheus 메트릭 활성화
// 3. 코드에서 메트릭 정의 및 사용
import io.micrometer.core.instrument.MeterRegistry; // 메트릭 등록을 위한 레지스트리
import io.micrometer.core.instrument.Timer; // 지연 시간을 측정하는 타이머
import org.springframework.stereotype.Service;
@Service
public class OrderService {
// 주문 처리 수를 추적하는 카운터
private final Counter orderCounter;
// 주문 처리 시간을 측정하는 타이머
private final Timer orderProcessingTimer;
public OrderService(MeterRegistry registry) {
// 카운터 정의: 이름, 설명, 태그 지정
orderCounter = Counter.builder("app_orders_total")
.description("주문 처리 총 횟수")
.tag("type", "purchase") // 태그로 메트릭 분류
.register(registry);
// 타이머 정의: 주문 처리 시간 측정용
orderProcessingTimer = Timer.builder("app_order_processing_seconds")
.description("주문 처리에 소요된 시간")
.publishPercentiles(0.5, 0.95, 0.99) // 중앙값, 95%, 99% 백분위수 게시
.register(registry);
}
public void processOrder(Order order) {
// 타이머로 메서드 실행 시간 측정
orderProcessingTimer.record(() -> {
try {
// 주문 처리 로직...
// 성공한 경우 카운터 증가
orderCounter.increment();
} catch (Exception e) {
// 오류 처리 로직...
// 오류 카운터도 별도로 추적 가능
}
});
}
}
- 메트릭 유형과 용도
- 카운터: 증가만 하는 값 (요청 수, 작업 수, 오류 수)
- 게이지: 증가/감소하는 값 (메모리 사용량, 연결 수)
- 히스토그램: 분포 측정 (요청 지연 시간, 응답 크기)
- 서머리: 분위수 계산 (백분위수 기반 지연 시간)
- 레이블(태그) 효과적 사용
- 의미 있는 차원으로 데이터 분류 (경로, 상태 코드, 사용자 유형)
- 레이블 수는 적절히 제한 (카디널리티 폭발 방지)
- 일관된 명명 규칙 사용
▶️ 코드 계측 모범 사례:
- 메트릭 이름에 접두사 사용: app_, api_ 등
- 단위를 이름에 포함: _seconds, _bytes 등
- 성능 영향 최소화: 고성능 계측 라이브러리 사용
- 비즈니스 관련 메트릭도 포함: 사용자 활동, 트랜잭션 등
✅ 서비스 메시 및 프록시 활용
애플리케이션 코드를 수정하지 않고 메트릭을 수집하는 방법입니다.
- Istio 서비스 메시
- 사이드카 프록시를 통한 자동 메트릭 수집
- 서비스 간 트래픽, 지연 시간, 오류율 측정
- 상세한 네트워크 수준 통찰력 제공
# Istio의 메트릭 수집 설정 예시
# 이 매니페스트는 Istio 서비스 메시의 텔레메트리 설정을 정의합니다
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator # Istio 설치 및 구성을 위한 CRD
metadata:
namespace: istio-system # Istio 컴포넌트가 설치된 네임스페이스
spec:
meshConfig:
enablePrometheusMerge: true # Prometheus 어노테이션 자동 추가 기능 활성화
values:
telemetry:
enabled: true # 텔레메트리 기능 활성화
v2:
enabled: true # 새로운 텔레메트리 모델 사용 (Envoy 기반)
prometheus:
enabled: true # Prometheus 메트릭 수집 활성화
configOverride:
# 수집할 메트릭 커스터마이징
metrics:
# 요청 총 개수 메트릭 정의
- name: requests_total # 메트릭 이름
instance_name: requestcount.instance.istio-system # 인스턴스 이름
kind: COUNTER # 메트릭 유형: 카운터(증가만 함)
label_names: # 메트릭에 적용할 레이블
- reporter # 메트릭 보고자 (inbound/outbound)
- source_app # 요청 발신 애플리케이션
- source_version # 발신 애플리케이션 버전
- destination_app # 요청 수신 애플리케이션
- destination_version # 수신 애플리케이션 버전
- request_protocol # 사용된 프로토콜 (HTTP/gRPC 등)
- response_code # HTTP 응답 코드
- response_flags # Envoy 응답 플래그 (오류 정보)
- Envoy Proxy
- 마이크로서비스 경계에서 메트릭 수집
- L4/L7 트래픽 통계 제공
- 업스트림/다운스트림 연결 상태 모니터링
- NGINX Ingress Controller
- 인그레스 레벨에서 애플리케이션으로 들어오는 트래픽 모니터링
- 요청 볼륨, 응답 코드, 지연 시간 추적
- 백엔드 서비스 상태 모니터링
▶️ 서비스 메시 모니터링 이점:
- 애플리케이션 코드 수정 없이 일관된 메트릭 수집
- 서비스 간 통신에 대한 자세한 가시성 확보
- 자동화된 대시보드 및 알림 설정 용이
- 분산 추적과의 통합 가능
✅ 사용자 정의 익스포터 개발
기존 익스포터가 없거나 특별한 요구사항이 있는 경우 직접 익스포터를 개발할 수 있습니다.
- 사용자 정의 익스포터 개발 단계
- 애플리케이션 API 또는 상태 엔드포인트 식별
- Prometheus 클라이언트 라이브러리 사용
- 메트릭 수집 및 변환 로직 구현
- HTTP 서버로 노출
# Python으로 작성된 간단한 사용자 정의 익스포터 예시
# 이 코드는 RESTful API를 호출하여 메트릭을 수집하고 Prometheus 형식으로 노출합니다
import time
import requests
from prometheus_client import start_http_server, Gauge, Counter
# 메트릭 정의
# 현재 활성 사용자 수를 추적하는 게이지 메트릭
active_users = Gauge('app_active_users', 'Number of active users', ['region'])
# 총 트랜잭션 수를 추적하는 카운터 메트릭
transactions = Counter('app_transactions_total', 'Total number of transactions', ['type', 'status'])
# API에서 메트릭 수집
def collect_metrics():
try:
# API 엔드포인트에서 데이터 가져오기
response = requests.get('http://myapp-api:8080/stats', timeout=5)
data = response.json()
# 메트릭 값 설정
# 지역별 활성 사용자 수 설정
for region, count in data['active_users'].items():
active_users.labels(region=region).set(count)
# 새로운 트랜잭션 증가시키기
for tx in data['recent_transactions']:
transactions.labels(type=tx['type'], status=tx['status']).inc()
except Exception as e:
print(f"Error collecting metrics: {e}")
# 메인 함수
def main():
# 메트릭 서버 시작 (포트 9100에서 /metrics 엔드포인트 노출)
start_http_server(9100)
# 주기적으로 메트릭 수집
while True:
collect_metrics()
time.sleep(15) # 15초마다 수집
if __name__ == '__main__':
main()
- 사용자 정의 익스포터의 장점
- 특정 비즈니스 요구에 맞는 맞춤형 메트릭
- 기존 시스템과의 통합 유연성
- 내부 애플리케이션 로직에 대한 더 깊은 통찰력
- 최적화 및 보안 고려사항
- 메모리 사용량 및 성능 최적화
- 인증 및 TLS 지원
- 호스트 메트릭과 애플리케이션 메트릭 분리
▶️ 커스텀 익스포터 설계 원칙:
- 단일 책임 원칙 적용 (한 익스포터는 한 애플리케이션 담당)
- 장애 복원력 있는 설계 (대상 애플리케이션 장애 시에도 작동)
- 메트릭 이름과 레이블에 일관된 명명 규칙 적용
- 상세한 문서화 및 로깅 제공
📌 익스포터 관리 및 운영 전략
대규모 환경에서 여러 익스포터를 효과적으로 관리하기 위한 전략을 알아보겠습니다.
✅ 익스포터 배포 자동화
많은 수의 익스포터를 관리하기 위한 자동화 방법입니다.
- Helm 차트 활용
- 표준화된 익스포터 배포 템플릿
- 환경별 구성 값 분리
- 버전 관리 및 롤백 용이
# 익스포터 배포를 위한 Helm values.yaml 예시
# 이 파일은 여러 환경에 익스포터를 배포할 때 사용하는 구성 값을 정의합니다
# 공통 설정
global:
environment: production # 환경 이름 (production, staging, development)
scrapeInterval: 30s # 기본 스크래핑 간격
# MySQL 익스포터 설정
mysqlExporter:
enabled: true # MySQL 익스포터 활성화 여부
image:
repository: prom/mysqld-exporter # 이미지 저장소
tag: v0.13.0 # 이미지 버전 태그
resources: # 리소스 요청 및 제한
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 100m
memory: 128Mi
# 서비스 타겟 설정
targets:
- name: main-db # 주 데이터베이스
host: mysql-main.database.svc # 데이터베이스 서비스 호스트
port: 3306 # MySQL 포트
databases: # 모니터링할 데이터베이스 목록
- users
- orders
- name: analytics-db # 분석용 데이터베이스
host: mysql-analytics.database.svc
port: 3306
databases:
- metrics
- reports
# Redis 익스포터 설정
redisExporter:
enabled: true
image:
repository: oliver006/redis_exporter
tag: v1.20.0
# Redis 인스턴스 타겟 설정
targets:
- name: cache # 캐시용 Redis
host: redis-cache.cache.svc
port: 6379
- name: session # 세션 저장용 Redis
host: redis-session.cache.svc
port: 6379
- 운영자(Operator) 패턴
- 선언적 익스포터 관리
- 자동 검색 및 설정
- 상태 모니터링 및 복구
- GitOps 워크플로우
- 버전 관리된 익스포터 구성
- 변경 사항 자동 적용
- 감사 및 변경 추적 가능
▶️ 자동화 이점:
- 반복적인 수동 작업 감소
- 일관된 구성 보장
- 빠른 배포 및 확장 가능
- 변경 사항 추적 및 롤백 용이
✅ 성능 및 리소스 최적화
익스포터가 모니터링 대상에 미치는 영향을 최소화하는 방법입니다.
- 스크래핑 간격 조정
- 중요도에 따른 차등 적용
- 리소스 사용량 모니터링 및 튜닝
- 장기 추세와 단기 알림 분리
# 성능 최적화를 위한 ServiceMonitor 설정 예시
# 이 매니페스트는 메트릭 중요도에 따라 다른 스크래핑 간격을 설정합니다
# 중요 메트릭을 위한 ServiceMonitor (짧은 간격)
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: critical-metrics # 중요 메트릭을 위한 ServiceMonitor
namespace: monitoring
spec:
selector:
matchLabels:
metrics: critical # 중요 메트릭을 제공하는 서비스 선택
endpoints:
- port: metrics # 메트릭을 노출하는 포트
interval: 15s # 15초마다 스크래핑 (짧은 간격)
scrapeTimeout: 10s # 스크래핑 작업 제한 시간
honorLabels: true # 원본 메트릭 레이블 유지
namespaceSelector:
any: true # 모든 네임스페이스 대상
# 일반 메트릭을 위한 ServiceMonitor (중간 간격)
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: standard-metrics # 일반 메트릭을 위한 ServiceMonitor
namespace: monitoring
spec:
selector:
matchLabels:
metrics: standard # 일반 메트릭을 제공하는 서비스 선택
endpoints:
- port: metrics
interval: 30s # 30초마다 스크래핑 (중간 간격)
scrapeTimeout: 15s
namespaceSelector:
any: true
# 장기 추세 메트릭을 위한 ServiceMonitor (긴 간격)
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: trend-metrics # 장기 추세 메트릭을 위한 ServiceMonitor
namespace: monitoring
spec:
selector:
matchLabels:
metrics: trends # 추세 분석용 메트릭을 제공하는 서비스 선택
endpoints:
- port: metrics
interval: 5m # 5분마다 스크래핑 (긴 간격)
scrapeTimeout: 30s
namespaceSelector:
any: true
- 리소스 제한 설정
- 메모리 및 CPU 한도 설정
- 익스포터 우선순위 클래스 활용
- 전용 노드 또는 노드 풀 고려
- 필터링 및 샘플링
- 필요한 메트릭만 수집
- 고해상도 샘플링과 저해상도 샘플링 분리
- 집계 및 사전 계산 활용
▶️ 성능 모니터링 팁:
- 익스포터 자체의 성능 메트릭 모니터링
- 대규모 클러스터에서는 연합(Federation) 설정 고려
- 메트릭 보존 정책 최적화
- 높은 카디널리티 메트릭 처리 전략 수립
✅ 보안 및 인증 구성
익스포터 보안을 강화하는 방법입니다.
- TLS 암호화
- 메트릭 엔드포인트 TLS 활성화
- 인증서 관리 자동화
- 안전한 통신 보장
# 익스포터 TLS 설정 예시
# 이 매니페스트는 익스포터 엔드포인트에 TLS를 적용하는 설정을 보여줍니다
apiVersion: v1
kind: Secret
metadata:
name: exporter-tls # TLS 인증서를 담은 시크릿
namespace: monitoring
type: kubernetes.io/tls
data:
tls.crt: <base64_encoded_cert> # Base64로 인코딩된 TLS 인증서
tls.key: <base64_encoded_key> # Base64로 인코딩된 개인 키
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: secure-exporter
namespace: monitoring
spec:
selector:
matchLabels:
app: secure-exporter
template:
metadata:
labels:
app: secure-exporter
spec:
containers:
- name: exporter
image: my-exporter:1.0
args:
- "--web.listen-address=:9100" # 메트릭 서버 포트
- "--web.config.file=/etc/tls/web-config.yml" # TLS 설정 파일 경로
ports:
- containerPort: 9100
name: https # HTTPS 포트
volumeMounts:
- name: tls-config
mountPath: /etc/tls # TLS 설정과 인증서 마운트 위치
readOnly: true
volumes:
- name: tls-config
projected: # 여러 소스의 데이터를 하나의 볼륨으로 투영
sources:
- secret:
name: exporter-tls # TLS 인증서가 담긴 시크릿
- configMap:
name: web-config # TLS 웹 서버 설정
---
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
namespace: monitoring
data:
web-config.yml: |
tls_server_config:
cert_file: /etc/tls/tls.crt # 인증서 파일 경로
key_file: /etc/tls/tls.key # 키 파일 경로
client_auth_type: "RequestClientCert" # 클라이언트 인증 요청 (선택 사항)
http_server_config:
http2: true # HTTP/2 활성화
- 인증 메커니즘
- 기본 인증 설정
- 토큰 기반 인증
- OAuth 또는 OIDC 통합
- 네트워크 정책
- 익스포터 접근 제한
- Prometheus 서버만 접근 허용
- 네임스페이스 간 통신 제어
▶️ 보안 모범 사례:
- 최소 권한 원칙 적용
- 민감한 정보는 Secret으로 관리
- 정기적인 보안 감사 수행
- ServiceAccount 권한 최소화
✅ 통합 모니터링 전략
여러 익스포터를 통합하여 종합적인 모니터링 솔루션을 구축하는 방법입니다.
- 통합 대시보드
- 인프라와 애플리케이션 메트릭 상관관계 시각화
- 서비스 종속성 및 영향 표시
- 사용자 정의 뷰 제공
- 계층적 알림 구성
- 인프라 및 애플리케이션 알림 연계
- 중복 알림 방지
- 근본 원인 식별 지원
- 서비스 맵 및 종속성 추적
- 분산 추적과 메트릭 통합
- 서비스 간 호출 관계 시각화
- 전체 시스템 건강 상태 파악
▶️ 통합 전략 사례: 한 기업은 다음과 같은 계층적 모니터링 전략을 구현했습니다.
- 기반 인프라 (노드, 네트워크)
- 플랫폼 서비스 (데이터베이스, 메시징)
- 애플리케이션 컴포넌트 (마이크로서비스)
- 비즈니스 프로세스 (사용자 여정, 트랜잭션)
이러한 계층적 접근으로 문제 발생 시 상향식(bottom-up) 또는 하향식(top-down) 분석이 가능해졌습니다.
📌 Summary
이번 포스트에서는 애플리케이션 레벨 모니터링을 위한 다양한 익스포터에 대해 깊이 있게 알아보았습니다. 다음과 같은 내용을 다루었습니다:
- 애플리케이션 모니터링의 중요성: 인프라 모니터링만으로는 파악할 수 없는 애플리케이션 성능과 건강 상태를 추적하는 중요성에 대해 살펴보았습니다. 사용자 경험에 직접 영향을 미치는 응답 시간, 오류율, 비즈니스 메트릭을 모니터링하여 문제를 조기에 발견하고 해결할 수 있습니다.
- 익스포터 기본 개념: Prometheus 익스포터의 작동 방식, 배포 전략, 공식 및 커뮤니티 익스포터의 차이점에 대해 알아보았습니다. 적절한 익스포터 선택은 효과적인 모니터링 시스템 구축의 첫 단계입니다.
- 데이터베이스 익스포터: MySQL, PostgreSQL, MongoDB, Redis 등 주요 데이터베이스를 위한 익스포터의 특징과 설정 방법을 살펴보았습니다. 쿼리 성능, 연결 상태, 복제 지연과 같은 중요 메트릭을 추적하여 데이터베이스 성능 최적화에 활용할 수 있습니다.
- 웹 서버 및 메시징 시스템 익스포터: NGINX, Apache, Tomcat과 같은 웹 서버와 RabbitMQ, Kafka와 같은 메시징 시스템을 위한 익스포터 설정을 알아보았습니다. 이들 컴포넌트는 현대 분산 시스템의 핵심 요소로, 효과적인 모니터링이 필수적입니다.
- 클라우드 서비스 익스포터: AWS, GCP, Azure와 같은 클라우드 서비스의 메트릭을 수집하는 익스포터 활용법을 배웠습니다. 하이브리드 및 멀티 클라우드 환경에서 일관된 모니터링 체계를 구축하는 방법에 대해 알아보았습니다.
- 코드 계측 방법: 애플리케이션 코드에 직접 Prometheus 클라이언트 라이브러리를 통합하여 맞춤형 메트릭을 노출하는 방법을 살펴보았습니다. 다양한 프로그래밍 언어에서 카운터, 게이지, 히스토그램, 서머리 메트릭을 효과적으로 활용하는 방법을 배웠습니다.
- 서비스 메시 및 프록시 활용: Istio, Envoy, NGINX Ingress Controller와 같은 도구를 활용하여 코드 수정 없이 애플리케이션 메트릭을 수집하는 방법을 알아보았습니다. 특히 마이크로서비스 환경에서 서비스 간 통신을 모니터링하는 데 효과적인 접근법입니다.
- 사용자 정의 익스포터 개발: 기존 익스포터로 충족되지 않는 특별한 요구사항이 있을 때 직접 익스포터를 개발하는 방법과 모범 사례를 살펴보았습니다. 맞춤형 비즈니스 메트릭 수집을 통해 운영 및 비즈니스 인사이트를 모두 제공할 수 있습니다.
- 익스포터 관리 및 운영 전략: 대규모 환경에서 여러 익스포터를 효과적으로 관리하기 위한 배포 자동화, 성능 최적화, 보안 구성 방법을 알아보았습니다. 특히 Helm 차트, 운영자 패턴, GitOps 워크플로우를 활용한 관리 자동화가 중요합니다.
애플리케이션 레벨 모니터링은 인프라 모니터링을 보완하여 전체 시스템의 관찰성을 높이는 핵심 요소입니다. 적절한 익스포터 선택과 구성을 통해 애플리케이션 성능 문제를 조기에 감지하고, 사용자 경험을 개선하며, 데이터 기반 의사결정을 지원할 수 있습니다.
728x90
'Observability > Prometheus' 카테고리의 다른 글
| EP15 [Part 5: 애플리케이션 레벨 모니터링] 웹 애플리케이션 모니터링 (Airflow 등) (0) | 2025.03.25 |
|---|---|
| EP14 [Part 5: 애플리케이션 레벨 모니터링] 데이터베이스 모니터링 (MySQL, PostgreSQL) (0) | 2025.03.24 |
| EP12 [Part 4: Grafana 대시보드 마스터하기] 대시보드 베스트 프랙티스 (0) | 2025.03.24 |
| EP11 [Part 4: Grafana 대시보드 마스터하기] 대시보드 생성 및 커스터마이징 (0) | 2025.03.24 |
| EP10 [Part 4: Grafana 대시보드 마스터하기] Grafana 설치 및 기본 설정 (0) | 2025.03.24 |