---
title: "모니터링 전략"
description: "Alpacon에서 서버 상태와 성능을 살펴보는 전략을 세웁니다. CPU, 메모리, 디스크, 네트워크 메트릭 가운데 팀에 필요한 항목을 고르고 추세를 비교하세요. 알림의 우선순위를 정하고 장애 조사와 용량 계획에 기록을 활용하는 방법도 살펴봅니다. 실제 운영에 적용할 수 있습니다."
---

> Full documentation index: https://docs.alpacax.com/llms.ko.txt

# 모니터링 전략

<span id="모니터링-전략-가이드" />

# 모니터링 전략

효과적인 서버 모니터링 및 로깅 전략을 통해 시스템 안정성을 확보하고 장애를 사전에 예방할 수 있습니다.

---

## 핵심 모니터링 지표

Alpacon은 서버의 주요 성능 지표를 실시간으로 수집하고 시각화합니다.

### 기본 메트릭

다음 메트릭은 모든 서버에 대해 기본적으로 수집됩니다:

- **CPU 사용률**: 전체 CPU 사용 현황 모니터링
- **메모리 사용률**: 시스템 메모리 사용 및 여유 공간 추적
- **디스크 사용률**: 파티션별 용량 및 사용률 확인

### 고급 메트릭

보다 상세한 성능 분석을 위한 추가 메트릭:

- **디스크 I/O**: Peak/AVG 성능 및 디스크별 I/O 분석
- **네트워크 트래픽**: Peak/AVG 대역폭, bps/pps, 인터페이스별 트래픽 분석

자세한 내용은 [서버 상태 모니터링 - 모니터링 대시보드](/use/servers/monitor/#모니터링-대시보드)를 참고하세요.

---

## 메트릭 알림 설정

효과적으로 모니터링하려면 메트릭 알림을 적절히 설정해야 합니다.

### 규칙 설정 전략

1. **임계값 설정**

   - CPU 사용률: 지속적으로 80% 이상 유지 시 경고
   - 메모리 사용률: 90% 이상 도달 시 경고
   - 디스크 사용률: 85% 이상 도달 시 경고

2. **대응 우선순위 정하기**

   규칙마다 심각도(심각·경고·정보)를 따로 설정할 수 있습니다. 어떤 상황에 즉시 대응하고 어떤 상황을 지켜볼지 판단하세요. 예를 들어 디스크 95% 이상은 즉시 조치가 필요하고, CPU가 80% 이상으로 지속되면 지켜볼 만합니다.

3. **그룹별 규칙 적용**
   - 프로덕션 서버: 더 엄격한 임계값 적용
   - 개발/테스트 서버: 유연한 임계값 적용
   - 데이터베이스 서버: I/O 및 메모리 중심 모니터링

### 규칙 할당 방법

워크스페이스에서 미리 정의한 메트릭 알림을 서버에 할당할 수 있습니다.

1. 메트릭 앱에서 서버를 선택하고 **규칙** 탭 접근
2. 적용할 규칙 선택

규칙이 발동하면 Alpacon이 서버 소유자에게 자동으로 알립니다.

자세한 내용은 [서버 상태 모니터링 - 메트릭 알림](/use/servers/monitor/#메트릭-알림)을 참고하세요.

---

## 로그 관리

로그는 장애 분석 및 시스템 감사를 위한 핵심 자료입니다.

### Recent Logs

Alpamon 에이전트에서 생성된 로그를 확인하여 다음을 파악할 수 있습니다:

- 에이전트 상태 변화
- 연결 오류 및 재시도 이력
- 데이터 수집 실패 원인

### Recent Backhauls

서버에서 수집된 데이터의 전송 상태를 모니터링합니다:

- 백홀 작업 성공/실패 여부
- 전송 시간 및 데이터 크기
- 네트워크 문제로 인한 전송 지연 감지

자세한 내용은 [서버 상태 모니터링 - 로그 확인](/use/servers/monitor/#로그-보기)을 참고하세요.

---

## 모니터링 활용 시나리오

### 1. 성능 병목 감지

CPU, 메모리, 디스크 I/O 메트릭을 종합적으로 분석하여 성능 병목 지점을 식별합니다.

**예시**:

- CPU는 정상이나 디스크 I/O가 높음 → 디스크 성능 개선 필요
- 메모리 사용률이 지속적으로 증가 → 메모리 누수 가능성

### 2. 용량 계획

디스크 사용률 추세를 분석하여 용량 증설 시기를 예측합니다.

**권장 사항**:

- 매월 사용률 증가 추세 분석
- 디스크 85% 도달 시 용량 증설 검토 시작
- 예상 증가율 기반 선제적 용량 확보

### 3. 장애 대응

경고 알림 수신 시 신속한 대응 프로세스를 구축합니다.

**기본 대응 절차**:

1. 경고 알림 수신
2. 서버 상세 화면에서 현재 메트릭 확인
3. 로그 탭에서 최근 이벤트 분석
4. 필요 시 Websh를 통해 즉시 접속하여 조치

---

## 장애 대응 시나리오

실전에서 발생하는 주요 장애 상황별 대응 방법입니다.

### 시나리오 1: CPU 과부하

**징후**:

- CPU 사용률 95% 이상 지속
- 서비스 응답 속도 저하
- Critical 알림 반복 수신

**즉시 대응 (5분 이내)**:

```
1. 메트릭 앱 → 서버
   → CPU 사용률 추세 확인
   → 급증 시점 파악

2. 활동 탭 → Command History
   → 최근 실행 명령어 확인
   → 배포나 설정 변경 이력 확인

3. Websh로 즉시 접속
   → top 또는 htop 실행
   → CPU 점유율 높은 프로세스 식별

4. 임시 조치
   → 불필요한 프로세스 종료 (kill)
   → 부하 분산 또는 스케일링
```

**근본 원인 분석 (30분 이내)**:

```
5. 로그 탭 → Recent Logs
   → 에러 메시지 확인
   → 애플리케이션 로그 분석

6. 원인 파악 및 조치
   - 무한 루프 버그 → 핫픽스 배포
   - 트래픽 급증 → 캐싱, 스케일 아웃
   - 리소스 누수 → 재시작 스케줄링
```

### 시나리오 2: 메모리 부족

**징후**:

- 메모리 사용률 90% 이상
- OOM (Out Of Memory) 에러
- 서비스 갑작스러운 종료

**즉시 대응**:

```
1. 메트릭 앱 → 서버
   → 메모리 사용 추세 확인
   → 급증 또는 지속적 증가 패턴 파악

2. Websh 접속
   → free -h (메모리 현황)
   → ps aux --sort=-%mem | head -20
   → 메모리 점유율 Top 20 프로세스 확인

3. 임시 메모리 확보
   → 불필요한 서비스 중지
   → 캐시 정리 (drop_caches)
   → swap 활성화 확인

4. 장기 해결책
   - 메모리 누수 → 코드 수정 및 배포
   - 정상적 증가 → 서버 업그레이드
```

### 시나리오 3: 디스크 용량 부족

**징후**:

- 디스크 사용률 90% 이상
- "No space left on device" 에러
- 로그 기록 실패

**즉시 대응**:

```
1. 메트릭 앱 → 서버
   → 디스크 사용률 확인
   → 파티션별 사용 현황 파악

2. Websh 접속
   → df -h (파티션별 사용률)
   → du -sh /* | sort -hr | head -10
   → 용량 많이 차지하는 디렉토리 확인

3. 긴급 공간 확보
   → 오래된 로그 파일 삭제
   → 임시 파일 정리 (/tmp, /var/tmp)
   → 불필요한 패키지 제거
   → 백업 후 압축

4. 로그 순환 설정
   → logrotate 설정 확인
   → 로그 보존 기간 조정
   → 자동 정리 스크립트 구성
```

### 시나리오 4: 네트워크 트래픽 급증

**징후**:

- 네트워크 트래픽이 평상시 대비 300% 이상
- 대역폭 한계 도달
- 응답 지연 발생

**즉시 대응**:

```
1. 메트릭 앱 → 서버
   → 네트워크 트래픽 추세 확인
   → Peak vs AVG 비교
   → 인터페이스별 트래픽 분석

2. 트래픽 원인 파악
   → 접근 로그 분석
   → DDoS 공격 여부 확인
   → 정상 트래픽 급증 vs 비정상 트래픽

3. 대응 조치
   정상 트래픽 급증:
   → CDN 활성화
   → 캐싱 강화
   → 로드 밸런서 추가

   비정상 트래픽 (DDoS):
   → 방화벽 규칙 추가
   → IP 차단
   → DDoS 방어 서비스 활성화
```

### 시나리오 5: 디스크 I/O 병목

**징후**:

- 디스크 I/O wait 높음
- 쿼리 응답 속도 저하
- 애플리케이션 타임아웃

**즉시 대응**:

```
1. 메트릭 앱 → 서버
   → 디스크 I/O Peak/AVG 확인
   → 디스크별 I/O 분석

2. Websh 접속
   → iostat -x 1 10
   → I/O 대기율 (%iowait) 확인
   → iotop (I/O 높은 프로세스 식별)

3. 즉시 조치
   → I/O 집약적 작업 일시 중지
   → 백업/배치 작업 재스케줄링
   → 불필요한 파일 접근 최소화

4. 장기 해결책
   - 인덱스 최적화 (DB)
   - SSD로 업그레이드
   - Read replica 추가 (DB)
   - 캐싱 레이어 도입
```

---

## 사전 예방 전략

### 베이스라인 수립

정상 운영 시 메트릭 패턴을 기록하여 이상 징후를 빠르게 감지합니다.

**베이스라인 기록 항목**:

```
일일 패턴:
- 업무 시간 (9-18시) CPU: 평균 30-40%
- 야간 (0-6시) CPU: 평균 10-15%
- 점심 시간 (12-13시) 트래픽 감소

주간 패턴:
- 월요일 오전: 트래픽 증가 (주간 배치)
- 수요일 저녁: 서비스 배포
- 주말: 낮은 부하

월간 패턴:
- 매월 초: 정산 배치로 CPU/DB 부하 증가
- 디스크 사용률: 월 5GB 증가 (로그)
```

### 용량 계획

메트릭 추세를 분석하여 사전에 리소스를 확보합니다.

**계획 수립 방법**:

```
1. 과거 3개월 데이터 수집
   → 메트릭 앱 → 서버
   → 월별 Peak 및 AVG 기록

2. 증가율 계산
   → 디스크: 월 평균 10GB 증가
   → 메모리: 월 5% 증가
   → 트래픽: 월 15% 증가

3. 임계값 도달 시점 예측
   → 현재 디스크 60% → 6개월 후 90%
   → 3개월 전 용량 증설 계획

4. 예산 확보 및 실행
```

### 정기 점검

**일일 점검**:

- [ ] Critical 알림 확인 및 대응
- [ ] 주요 서버 메트릭 육안 확인
- [ ] 전날 대비 급격한 변화 체크

**주간 점검**:

- [ ] 모든 서버 메트릭 추세 분석
- [ ] 미해결 Warning 알림 검토
- [ ] 로그 에러 패턴 분석
- [ ] 디스크 사용률 증가 추세 확인

**월간 점검**:

- [ ] 메트릭 알림 임계값 재조정
- [ ] 베이스라인 업데이트
- [ ] 용량 계획 진행 상황 점검
- [ ] 장애 대응 시간 분석 및 개선

---

## 권장 사항

### 정기적인 검토

- **일일**: Critical 경고 및 이상 메트릭 확인
- **주간**: 서버별 메트릭 추세 분석
- **월간**: 메트릭 알림이 적절한지 검토하고 조정

### 효율적인 알림 관리

- 불필요한 경고를 최소화하여 알림 피로도 방지
- 서비스 상태에 가장 큰 영향을 주는 상황에 집중
- 알림 수신 채널을 팀 역할에 따라 차별화

### 문서화

- 각 서버의 정상 운영 기준선(baseline) 기록
- 과거 장애 사례 및 대응 방법 문서화
- 경고 발생 시 대응 매뉴얼 작성

---

## 관련 문서

- [서버 모니터링](/use/servers/monitor/): 서버 모니터링 기능 상세 안내
- [메트릭 알림](/use/servers/monitor/#메트릭-알림): 메트릭 알림 설정
- [그룹](/use/iam/groups/): 그룹별 서버 모니터링

Source: https://docs.alpacax.com/ko/learn/best-practices/monitoring/