클라우드

열공하는웅2·2025년 11월 17일

Grafana alertmanager monitoring openstack prometheus

클라우드

목록 보기

12/13

■ Monitoring 정리본

1. 모니터링이 필요한 이유

쿠버네티스를 실제 운영할 때는 다음과 같은 상황을 대비해 모니터링 시스템 구축이 필수적이다.

사용자의 요청이 갑자기 증가하여 부하가 커질 때
인프라나 애플리케이션에 장애가 발생할 때
애플리케이션의 일반적인 리소스 패턴을 파악하고 싶을 때
기타 예측이 어려운 상황 발생 대비

이를 위해 CPU, RAM뿐 아니라 HDD 사용량, 네트워크 I/O, 초당 요청 수, 특정 어플리케이션의 지연 등 다양한 지표를 관찰해야 한다.

쿠버네티스 자체에는 완전한 모니터링 도구가 내장되어 있지 않기 때문에,
Datadog, NewRelic, AWS CloudWatch 같은 상용 플랫폼을 사용하거나 여러 오픈소스 도구를 조합해 구축한다.

2. 쿠버네티스 오픈소스 모니터링 구성

가장 널리 사용되는 오픈소스 기반 모니터링 스택은 다음과 같다.

(1) Prometheus

뛰어난 성능과 확장성, 다양한 도구와 높은 호환성을 가진 시계열(time-series) 데이터베이스
쿠버네티스 모니터링의 핵심 구성 요소
Prometheus는 /metrics 경로로 노출된 메트릭 데이터를 수집하여 시계열 형태로 저장한다.

(2) Grafana

Prometheus가 수집한 데이터를 시각화하는 도구
대시보드를 구성하여 CPU, 메모리, 네트워크 사용량 등 다양한 지표를 시각적으로 확인할 수 있다.

(3) Alertmanager

Prometheus와 연동하여 Slack, 이메일 등으로 경보(Alerts)를 발송한다.

3. CAdvisor와 Exporter

쿠버네티스 모니터링에서는 각 노드·컨테이너의 상태를 수집할 수 있도록 모니터링 데이터를 노출해야 한다.

(1) CAdvisor

Google이 만든 컨테이너 모니터링 도구
CPU, 메모리, 네트워크 사용량 등 컨테이너 리소스 정보를 /metrics 경로로 제공
웹 UI는 단기 데이터만 제공하고 장기 저장은 불가능 → Prometheus가 수집해 저장하는 방식으로 사용

(2) Exporter

특정 서버나 시스템 정보를 Prometheus가 이해할 수 있는 /metrics 형식으로 출력하는 인터페이스
CAdvisor도 넓은 의미에서는 Exporter의 일종
예: Node Exporter(노드 메트릭), Nginx Exporter(웹서버 메트릭) 등

4. 데이터 수집 구조 요약

Exporter 또는 CAdvisor가 /metrics 형태로 메트릭 노출
Prometheus가 주기적으로 /metrics 데이터를 스크랩 → 저장
Grafana가 Prometheus에 저장된 데이터를 시각화
Alertmanager가 임계값 초과 시 알림 발송

📘 Monitoring 추가 정리본

🟦 1. Metrics 수집 방식

쿠버네티스에서는 각 구성 요소가 /metrics 경로로 메트릭 정보를 노출하고,
Prometheus가 해당 경로를 주기적으로 스크랩하여 데이터를 수집한다.

외부에서 /metrics로 요청을 보내면 텍스트 기반(metrics format) 형태로 정보를 확인 가능
이 데이터를 시각화 도구(Grafana 등)와 연동하면 그래픽 대시보드 형태로 시각적 모니터링이 가능하다.

🟩 2. Dashboard (Kubernetes Dashboard)

쿠버네티스 Dashboard는 다음과 같은 역할을 하는 웹 기반 GUI 관리 도구이다.

✔ 기능

실행 중인 Pods, Deployments, Services 등 리소스를 GUI로 조회/관리
kubectl CLI로 처리하던 내용을 브라우저에서 클릭으로 처리 가능
리소스 생성, 스케일 조절, 상태 확인 등의 작업도 지원

즉, CLI에 익숙하지 않은 사용자에게 친숙한 관리 화면을 제공하는 도구이다.

📘 Monitoring 메트릭 수집 정리

1. 메트릭 수준(Level)의 종류

모니터링 데이터는 다음 세 가지 수준으로 나뉜다.

● 호스트(Host) 레벨

OS 전체 리소스 정보 (CPU, RAM, Disk, Network 등)

● 컨테이너(Container) 레벨

특정 컨테이너의 CPU, 메모리, I/O 등 세부 자원 사용량

● 어플리케이션(App) 레벨

앱 내부에서 제공하는 HTTP 요청 수, 에러율, 사용자 수 등
(일부 앱만 제공 → 도구 추가 필요)

쿠버네티스에서는 주로 인프라 + 컨테이너 레벨의 모니터링 데이터를 사용함.

2. cAdvisor 실행 예시 (Docker 방식)

a) Docker run 예시 (읽기 전용으로 실행)

docker run \
  --volume=/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

✔ 목적: 호스트 정보를 읽기 위해 rootfs, sys 등 주요 경로를 읽기 전용(ro) 으로 마운트
✔ 브라우저에서 http://<노드IP>:8080/containers 접속 → cAdvisor UI 확인 가능

3. 메트릭 확인

● 브라우저 예시

Ubuntu Firefox에서 아래 주소로 접속:

https://192.168.100.111:8080/containers

● cAdvisor에서 직접 확인

curl localhost:8080/metrics

출력 예시:

container_cpu_usage_seconds_total
container_memory_usage_bytes
등 다양한 컨테이너 메트릭이 제공됨.

4. Prometheus로의 확장

cAdvisor가 제공하는 /metrics 데이터를 Prometheus가 수집하면,
컨테이너 단위의 시간 기반(Time-series) 모니터링이 가능해진다.

또한 인프라 수준의 메트릭은 Node Exporter,
앱 수준의 메트릭은 라이브러리 + exporter 를 사용해 수집 가능하다.

📘 Monitoring 메트릭 수집 정리

1. 메트릭 수준(Level)의 종류

모니터링 데이터는 다음 세 가지 수준으로 나뉜다.

● 호스트(Host) 레벨

OS 전체 리소스 정보 (CPU, RAM, Disk, Network 등)

● 컨테이너(Container) 레벨

특정 컨테이너의 CPU, 메모리, I/O 등 세부 자원 사용량

● 어플리케이션(App) 레벨

앱 내부에서 제공하는 HTTP 요청 수, 에러율, 사용자 수 등
(일부 앱만 제공 → 도구 추가 필요)

쿠버네티스에서는 주로 인프라 + 컨테이너 레벨의 모니터링 데이터를 사용함.

2. cAdvisor 실행 예시 (Docker 방식)

a) Docker run 예시 (읽기 전용으로 실행)

docker run \
  --volume=/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

3. 메트릭 확인

● 브라우저 예시

Ubuntu Firefox에서 아래 주소로 접속:

https://192.168.100.111:8080/containers

● cAdvisor에서 직접 확인

curl localhost:8080/metrics

출력 예시:

container_cpu_usage_seconds_total
container_memory_usage_bytes
등 다양한 컨테이너 메트릭이 제공됨.

4. Prometheus로의 확장

cAdvisor가 제공하는 /metrics 데이터를 Prometheus가 수집하면,
컨테이너 단위의 시간 기반(Time-series) 모니터링이 가능해진다.

또한 인프라 수준의 메트릭은 Node Exporter,
앱 수준의 메트릭은 라이브러리 + exporter 를 사용해 수집 가능하다.

📘 OpenStack으로 SDN 구축하기

🟦 1. SDN + OpenStack 개념

클라우드 환경에서 SDN(Software Defined Network)을 구축할 때,
오픈소스 클라우드 플랫폼인 OpenStack을 사용한다.

OpenStack을 활용하면 다음과 같은 소프트웨어 정의 네트워크 기능(SDN) 을 만들 수 있다:

VLAN 생성
가상 스위치(Switch)
가상 라우터(Router)
각 VM, 노드, Pod들을 연결하는 가상 네트워크

즉, SDN 기반의 IaaS 인프라를 직접 구성할 수 있게 된다.

🟩 2. Cloud SDN 실습을 위한 환경 구성

OpenStack을 설치하려면 아래와 같은 VM 또는 물리 머신 환경이 필요하다:

RAM: 8GB
HDD: 약 80GB
CPU: 최소 1 Core, 권장 2 Core
가상화 옵션(VT-x/AMD-V) 활성화
네트워크: NAT 또는 브리지 모드 가능

가상머신(VMware 등)에
Ubuntu 20.04 Server (ubuntu-20.04-live-server-amd64.iso) 를 설치해서 실습 환경을 구성한다.

💡 참고
Ubuntu 20.04 Server 설치 화면은 Desktop 설치 방식과 일부 차이가 있음.

🟨 3. DevStack을 이용한 OpenStack SDN 구성

SDN 실습에서는 DevStack을 사용해 OpenStack을 빠르게 설치한다.

DevStack은 다음과 같은 OpenStack 네트워크·시스템 관리를 위한 주요 모듈이 포함된 설치 도구이다:

Neutron: OpenStack의 SDN/네트워크 담당
Nova: VM(서버) 생성 및 관리
Ironic: 베어메탈 서버 관리(Lifecycle)
Cinder/Swift: 스토리지 관리
Keystone: 인증
Glance: 이미지 관리

즉, DevStack으로 설치하면 “SDN을 포함한 OpenStack 전체 구성요소”를 한 번에 구축할 수 있다.

📘 OpenStack 네트워크 구성 흐름과 외부 클라우드 연동

🟦 1. OpenStack 네트워크 구성 방식

OpenStack 네트워크 구축은 원격에서 RDO(Remote Data Object) 를 사용해 작업할 수도 있지만,
실습 환경에서는 주로 Horizon 대시보드를 사용해 다음 요소들을 GUI 기반으로 설정한다:

Network
Subnet
DHCP Service

이 과정을 통해 OpenStack 내부 가상 네트워크 구조를 만들고,
이를 기반으로 OpenStack API 사용도 가능해진다.

🟩 2. 외부 클라우드(AWS/Azure)와 네트워크 연동

AWS나 Azure 같은 외부 클라우드에서 VM(Pod) 을 만든 뒤,
이 VM을 OpenStack에서 만든 네트워크와 연결하는 것도 가능하다.

즉,
OpenStack 내부 가상 네트워크 ↔ 외부 클라우드 VM
두 환경을 통신하도록 구성할 수 있다.

🟨 3. 다양한 네트워크 분리·연결 기술

OpenStack에서는 다음과 같은 기술을 사용해 네트워크를 논리적으로 분리하거나 연결한다:

VLAN
VXLAN
GRE
Network Namespaces
OpenFlow Rules

또한 AWS처럼

독립적인 가상머신 파드를 생성하고
이를 VLAN/Subnet에 묶은 뒤
VRouter를 연결하여 외부와 통신시키는 구성도 가능하다.

🟦 1. OpenStack = 직접 구축하는 클라우드 (Self-Hosted Cloud)

🟧 2. AWS = 이미 완성된 클라우드 서비스 (Public Cloud)

🟦 1) 철학의 차이 (근본 개념)

구분	OpenStack	AWS
개념	오픈소스로 직접 설치해 운영하는 클라우드 플랫폼	Amazon이 제공하는 완성형 클라우드 서비스
누구 기준?	운영자/엔지니어가 직접 설치·설정	사용자/기업이 바로 사용
예시	“우리가 AWS 같은 걸 직접 구축한다”	“AWS를 돈 내고 바로 쓴다”

📌 요약
→ OpenStack은 직접 만드는 AWS
→ AWS는 이미 만들어져 있는 서비스

🟦 2) 설치 vs 사용

구분	OpenStack	AWS
설치 필요?	✔ 직접 설치 필요 (DevStack, TripleO, Kolla 등)	❌ 설치 필요 없음
유지보수	✔ 직접 (네트워크, 스토리지, 인증 등)	❌ AWS가 다 관리
OS 패치/장애처리	✔ 직접 해결해야 함	❌ AWS 엔지니어가 해결

📌 OpenStack = 설치·업데이트·장애처리 전부 ‘직접’
📌 AWS = 버튼 클릭으로 바로 사용

🟦 3) 기능 비교 (비슷하지만 이름만 다름)

기능 영역	OpenStack	AWS
컴퓨팅	Nova	EC2
스토리지(블록)	Cinder	EBS
스토리지(오브젝트)	Swift	S3
네트워크	Neutron	VPC
이미지 관리	Glance	AMI
대시보드	Horizon	콘솔(console)

📌 AWS에서 되는 거의 모든 기능이 OpenStack에도 있음
→ 차이는 "누가 관리하느냐".

🟦 4) 네트워크 구조 차이 (중요🔥)

구분	OpenStack	AWS
네트워크 구성	✔ 직접 라우터, 서브넷, 포트 등을 설정해야 함	❌ AWS가 자동 구성, 사용자는 VPC/Subnet만 고르면 됨
DHCP/라우터	Neutron이 직접 동작	AWS 내부에서 자동 운영
보안그룹	어그레이드 필요함	간단하게 규칙 추가 가능

📌 너가 지금 고생 중인 "포트 DOWN / DVR / geneve" 같은 문제는
AWS에서는 절대 발생하지 않는 문제
→ AWS가 내부에서 모든 네트워크를 자동으로 안정적으로 운영하기 때문.

🟦 5) 가격

구분	OpenStack	AWS
비용	오픈소스 무료	사용량 기반 과금 $$$
운영 비용	서버/스토리지/네트워크 인프라 비용 필요	서버 비용 없이 바로 사용

📌 OpenStack은 소프트웨어는 무료지만
물리 장비 비용 + 엔지니어 인건비가 많이 든다.

🟦 6) 확장성 / 안정성

구분	OpenStack	AWS
확장성	운영자 실력에 따라 천차만별	전 세계 수준의 무한 확장
안정성	각 조직/기업의 운영 능력에 따라 다름	SLA 99.99%, 자동 복구
IoT/AI/ML 서비스	제한적 (별도 시스템 구축 필요)	매우 풍부

🟦 7) 실제 사용 목적

OpenStack	AWS
기업 내부 프라이빗 클라우드	글로벌 서비스 운영
데이터센터 자체 구축	스타트업, IT 서비스
연구/교육 환경	대규모 트래픽 처리
ISP(통신사) 클라우드	AI/ML, IoT 플랫폼

🟧 한 줄 요약

OpenStack = AWS를 직접 만들어서 우리가 운영하는 시스템

AWS = 이미 완성된 클라우드를 돈 내고 쓰는 시스템

둘 다 “클라우드 플랫폼”이지만
실제로는 목적과 역할이 완전히 다르다.

열공하는웅2

훌륭한 it 엔지니어 꿈나무

이전 포스트

쿠버네티스5

다음 포스트

클라우드

클라우드

■ Monitoring 정리본

1. 모니터링이 필요한 이유

2. 쿠버네티스 오픈소스 모니터링 구성

(1) Prometheus

(2) Grafana

(3) Alertmanager

3. CAdvisor와 Exporter

(1) CAdvisor

(2) Exporter

4. 데이터 수집 구조 요약

📘 Monitoring 추가 정리본

🟦 1. Metrics 수집 방식

🟩 2. Dashboard (Kubernetes Dashboard)

✔ 기능

📘 Monitoring 메트릭 수집 정리

1. 메트릭 수준(Level)의 종류

● 호스트(Host) 레벨

● 컨테이너(Container) 레벨

● 어플리케이션(App) 레벨

2. cAdvisor 실행 예시 (Docker 방식)

a) Docker run 예시 (읽기 전용으로 실행)

3. 메트릭 확인

● 브라우저 예시

● cAdvisor에서 직접 확인

4. Prometheus로의 확장

📘 Monitoring 메트릭 수집 정리

1. 메트릭 수준(Level)의 종류

● 호스트(Host) 레벨

● 컨테이너(Container) 레벨

● 어플리케이션(App) 레벨

2. cAdvisor 실행 예시 (Docker 방식)

a) Docker run 예시 (읽기 전용으로 실행)

3. 메트릭 확인

● 브라우저 예시

● cAdvisor에서 직접 확인

4. Prometheus로의 확장

📘 OpenStack으로 SDN 구축하기

🟦 1. SDN + OpenStack 개념

🟩 2. Cloud SDN 실습을 위한 환경 구성

🟨 3. DevStack을 이용한 OpenStack SDN 구성

📘 OpenStack 네트워크 구성 흐름과 외부 클라우드 연동

🟦 1. OpenStack 네트워크 구성 방식

🟩 2. 외부 클라우드(AWS/Azure)와 네트워크 연동

🟨 3. 다양한 네트워크 분리·연결 기술

🟦 1. OpenStack = 직접 구축하는 클라우드 (Self-Hosted Cloud)

🟧 2. AWS = 이미 완성된 클라우드 서비스 (Public Cloud)

🟦 1) 철학의 차이 (근본 개념)

🟦 2) 설치 vs 사용

🟦 3) 기능 비교 (비슷하지만 이름만 다름)

🟦 4) 네트워크 구조 차이 (중요🔥)

🟦 5) 가격

🟦 6) 확장성 / 안정성

🟦 7) 실제 사용 목적

🟧 한 줄 요약

쿠버네티스5

클라우드 보안

0개의 댓글