[Prometheus + Exporter 예시]
✅ 얻는 것:
- 통합 모니터링 (한 곳에서)
- 오픈소스 (무료)
- 커스터마이징 자유도
- 벤더 락인 없음
❌ 잃는 것 / 대가:
- 구축/운영 시간 (누군가 해야 함)
- 리소스 (서버, Pod)
- 학습 곡선 (PromQL, Alert 설정)
- 깊은 분석 한계
2. 팀 상황 평가
□ 팀 규모는?
2명 → 관리 부담 큼 (SaaS 고려)
20명 → 직접 구축 가능
□ 예산은?
시간이 많고 돈이 없음 → 오픈소스
시간이 없고 돈이 있음 → SaaS (Datadog)
□ 인프라는?
AWS/Azure → CloudWatch 이미 있음
온프레미스 → 직접 구축 필요
□ 긴급도는?
장애 감지 급함 → Prometheus (빠름)
쿼리 최적화 급함 → DB 전용 툴
□ 기존 스택은?
ELK 이미 있음 → Elastic APM 고려
Grafana 쓰는 중 → Prometheus 추가 쉬움
💰 비용 감각
시간 비용 계산
[Prometheus 직접 구축]
- 초기 구축: 1주일 (40시간)
- 월 유지보수: 8시간
- 엔지니어 시급: 5만원
초기: 200만원
월: 40만원
[Datadog SaaS]
월: 100만원
→ 3개월 후부터 SaaS가 저렴!
+ 기능은 더 많고 학습 곡선 낮음
이거 구축하느라 못한 것:
- 비즈니스 기능 개발
- 기술 부채 해결
- 성능 최적화
→ "정말 지금 필요한 일인가?"
📊 단계별 접근 (점진적 개선)
Phase 1: 생존 확인 (1주)
✅ 서비스 살아있나?
✅ 치명적 에러 있나?
도구:
- Kubernetes Liveness Probe
- 클라우드 기본 모니터링 (CloudWatch)
- 간단한 Health Check 엔드포인트
Phase 2: 핵심 지표 (2-4주)
✅ 응답 시간
✅ 에러율
✅ 리소스 사용률 (CPU, 메모리)
도구:
- Prometheus + Node Exporter
- 기본 Grafana 대시보드
- 간단한 Alert (Slack)
Phase 3: 상세 분석 (1-3개월)
✅ 쿼리별 성능
✅ 트랜잭션 추적
✅ 로그 집계
도구:
- APM (Datadog, New Relic)
- DB 전용 툴 (Percona PMM)
- ELK Stack
Phase 4: 비즈니스 메트릭 (지속적)
✅ 주문 완료율
✅ 사용자 전환율
✅ 매출 영향 추적
도구:
- 커스텀 메트릭
- 비즈니스 대시보드
- 자동화된 리포트
⚠️ 흔한 실수
❌ 완벽주의 함정
나쁜 접근:
"Prometheus, Grafana, Loki, Jaeger, ELK 다 세팅!"
→ 3개월 걸림
→ 지침
→ 운영 부담
→ 포기
좋은 접근:
"일단 Prometheus + Node Exporter로 CPU/메모리만"
→ 1주일
→ 즉시 가치 확인
→ 필요하면 점진적 추가
❌ 무료 = 저렴 착각
오픈소스는 "라이선스 무료"일 뿐
실제 비용:
- 구축 시간
- 학습 시간
- 유지보수 시간
- 서버 리소스
- 장애 대응 시간
→ 총 소유 비용(TCO) 계산 필요
🎯 의사결정 프레임워크
도구 선택 결정표
상황
추천
스타트업 (2-5명)
클라우드 기본 + Prometheus
성장기 (5-20명)
Prometheus + 일부 SaaS
중대형 (20명+)
계층별 전문 도구
클라우드 중심
CloudWatch + X-Ray
온프레미스
Prometheus + ELK
예산 제로
Prometheus + Loki + Grafana
빠른 결과 필요
Datadog 같은 SaaS
MySQL 모니터링 예시
Q: Prometheus로 MySQL 모니터링해야 하나?
판단 기준:
□ 빠른 장애 감지 목적? → Yes
□ 쿼리 상세 분석 목적? → No (Percona PMM)
□ AWS RDS 사용 중? → No (CloudWatch로 충분)
□ 10개 이상 MySQL 서버? → Yes (표준화)
□ 무료로 시작하고 싶음? → Yes
결론:
- Kubernetes + 여러 MySQL → Prometheus 좋음
- AWS RDS → CloudWatch로 충분
- 쿼리 튜닝 필요 → 전용 툴 병행
🚨 알람 피로 관리
나쁜 알람 vs 좋은 알람
구분
나쁜 알람
좋은 알람
빈도
매일 10번
주 1-2번 (진짜 문제)
액션
뭘 해야 할지 모름
명확한 대응 방법
중요도
모두 Critical
3단계 분리
임계값
너무 민감
적절한 여유
알람 설정 원칙
# ❌ 나쁜 예- alert: MySQLConnections expr: mysql_connections > 50 # → 매일 울림, 무시됨# ✅ 좋은 예- alert: MySQLConnectionsCritical expr: mysql_connections > 150 for: 5m # 5분 이상 지속 labels: severity: critical annotations: summary: "MySQL 커넥션 풀 고갈 임박" action: "1. 슬로우 쿼리 확인 2. 스케일 아웃 고려"
알람 계층 구조
Critical (즉시 대응):
- 서비스 다운
- 데이터 손실 위험
- 보안 침해 의심
→ PagerDuty, 전화
Warning (근무시간 내):
- 성능 저하
- 리소스 80% 사용
- 비정상적 패턴
→ Slack, 이메일
Info (주간 리포트):
- 트렌드 변화
- 용량 계획 참고
- 최적화 기회
→ 이메일, 대시보드
💡 실무 체크리스트
새 모니터링 도구 도입 전
□ 이미 있는 모니터링 도구로는 안 되나?
(재발명 금지)
□ 팀에서 누가 관리할 건가?
(3개월 후에도)
□ 온보딩 비용은?
(새 팀원이 배우는 시간)
□ 총 소유 비용(TCO)을 계산했나?
(구축 + 운영 + 기회 비용)
□ 실패했을 때 롤백 가능한가?
(위험 관리)
□ 이게 정말 지금 가장 중요한 일인가?
(우선순위)