[OpenStack Project] VMware 없이 노트북 서버로 kolla-ansible OpenStack 설치 [5]

서론

• Prometheus + Granfan를 이용해서 Openstack의 상태와 서버(노트북)의 상태 모니터링

---

• 클라우드 엔지니어의 모니터링 대상은 크게 물리 - 서비스 - 리소스로 나눈다.
  • 인프라/노드 상태 (Hardware & OS)
    • 전체 CPU 사용량
    • 메모리 부족으로 OOM(Out of Memory) 킬러가 동작하지 않는지
    • 디스크가 꽉 차지 않았는지, 읽기/쓰기 속도가 느려지지 않았는지
    • 물리 NIC의 대역폭이 포화되지 않았는지
  • 오픈스택 서비스 상태 (Control Plane Health)
    • API Up/Down : Nova, Neutron, Keystone, Glance API가 200 OK 정상 응답을 주는가
    • Service State : nova-scheduler, neutron-l3-agent 등이 살았는가
  • 테넌트 리소스 현황
    • Hypervisor Capacity: 전체 CPU/RAM 중 몇 %가 할당되었는가? (Overcommit 비율 관리)
    • Active VM Count: 현재 총 몇 대의 VM이 돌아가고 있는가?
    • Floating IP Usage: 공인 IP가 고갈되지 않았는가?
• Prometheus와 Grafana를 Docker로 띄워서 모니티링 시스템 구축
  • Prometheus : 데이터를 수집하는 서버 (TSDB)
  • OpenStack Exporter: 오픈스택 API의 정보를 가져오는 수집기
  • Node Exporter: 리눅스 서버(노트북)의 CPU/RAM 정보를 가져오는 수집기
  • Grafana: 수집된 데이터를 대시보드로 보여주는 도구

과정

• 프로메테우스가 어디서 데이터를 가져올지 정의하는 설정 파일 작성 (prometheus.yml)

global:
  scrape_interval: 10s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'openstack-exporter'
    scrape_interval: 60s  # 트러블 슈팅 부분에서 설명
    scrape_timeout: 50s   # 트러블 슈팅 부분에서 설명
    static_configs:
      - targets: ['localhost:9180']

---

• docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    network_mode: "host"

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    network_mode: "host"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    network_mode: "host"

  openstack-exporter:
    image: ghcr.io/openstack-exporter/openstack-exporter:latest
    container_name: openstack-exporter
    network_mode: "host"
    volumes:
      - /home/name/.config/openstack/clouds.yml:/etc/openstack/clouds.yaml
    environment:
      - OS_CLIENT_CONFIG_FILE=/etc/openstack/clouds.yml
      - OS_CLOUD=my-openstack

• 컨테이너 실행 및 상태 확인

docker compose up -d
docker compose ps

• 192.168.35.100:<>
• Prometheus : http://localhost:9090
• Grafana : http://localhost:3000
• Metrics
  • http://localhost:9100/metrics
  • http://localhost:9180/metrics

---

• 그라파나 대시보드 구성
  • Connections > Data Source > Prometheus > Connection : http://localhost:9090 > Save & Test
  • Dashboards > Import > ID : 1860 (Node Exporter용 대시보드)
  • Dashboards > Import > ID : 21085 (OpenStack Exporter용 대시보드)
    
    
    

---

학습

• prometheus.yml의 targets 섹션에 적힌 포트 (9090, 9100, 9180)
  • targets에 정의된 포트는 각 애플리케이션이 HTTP 프로토콜을 통해 메트릭을 노출하고 있는 TCP 리스닝 포트이다. 프로메테우스는 이 포트로 주기적인 HTTP GET 요청을 보내 데이터를 수집(Scraping)한다.
  • 9090 (Prometheus Server)
    • 역할 : Prometheus 자체의 웹 UI 및 API 엔드포인트
    • 기능 : 수집된 데이터를 조회(Query)하거나, Prometheus 서버 자체의 상태 메트릭을 노출한다. Grafana가 데이터를 요청할 때도 이 포트를 사용한다.
  • 9100 (Node Exporter)
    • 역할 : 호스트 하드웨어 및 OS 레벨의 메트릭 수집 에이전트
    • 기능 : /proc이나 /sys 같은 리눅스 커널 파일시스템을 읽어서 CPU, 메모리, 디스크, 네트워크 I/O 정보를 텍스트 포맷으로 변환해 9100번 포트에 띄운다.
  • 9180 (OpenStack Exporter)
    • 역할 : OpenStack 클라우드 서비스 메트릭 수집 에이전트
    • 기능 : OpenStack API(Nova, Neutron 등)에 REST API 요청을 보내 리소스 상태를 조회한 뒤, 이를 Prometheus가 이해할 수 있는 포맷으로 변환해 9180번 포트에 띄운다.

---

• network_mode: "host"의 의미와 사용 이유
  • => 네트워크 네임스페이스 공유
  • Docker 컨테이너는 기본적으로 호스트와 분리된 별도의 네트워크 네임스페이스를 가진다. 하지만 network: "host"를 설정하면 컨테이너가 독자적인 네트워크 스택(가상 IP, vETH 인터페이스 등)을 생성하지 않고, 호스트 머신의 네트워크 네임스페이스를 직접 사용한다.
    • 컨테이너 내부의 네트워크 인터페이스가 호스트의 인터페이스와 동일해진다.
    • 컨테이너의 포트가 호스트의 포트와 직접 매핑된다. (Docker의 NAT/Bridge 과정을 거치지 않음)
• 프로메테우스가 데이터를 수집하려면 각 Exporter의 IP 주소를 알아야 한다.
  • Bridge 모드 사용 시 : 컨테이너마다 172.17.0.x 같은 내부 IP가 할당되므로, 프로메테우스 설정 파일에 각 컨테이너의 IP나 Docker DNS 이름을 등록해야 하는 복잡함이 있다.
  • Host 모드 사용 시 : 모든 컨테이너가 호스트의 네트워크를 공유하므로, localhost 주소 하나만으로 서로 통신이 가능하다. => 설정 파일 관리가 용이

---

• 오픈스택 상태 시각화 과정
  • 데이터는 소스 > 수집기 > 저장소 > 시각화 도구 순서로 이동한다.
  1. 데이터 생성 (Source)
     • 사용자가 오픈스택에 리소스를 생성하면, Nova, Neutron 등의 컴포넌트가 DB에 상태를 기록한다.
  2. 데이터 추출 및 변환 (OpenStack Exporter)
     • Exporter 프로세스가 설정된 주기마다 오픈스택의 REST API 엔드포인트로 HTTP 요청을 보낸다. (ex. GET /servers/detail)
     • 받아온 JSON 응답을 Prometheus Metrics Format (Key-value 형태의 텍스트)으로 파싱한다.
     • 이 데이터를 자신의 9180번 포트에 HTTP로 서빙한다.
  3. 데이터 수집 및 적재 (Prometheus Server)
     • 프로메테우스 서버의 스크래이퍼가 prometheus.yml에 설정된 주기마다 http://localhost:9180/metrics로 HTTP GET 요청을 보낸다.
     • 응답받은 텍스트 데이터를 시계열 데이터로 변환하여 내부의 TSDB(Time Series Database)에 타임스탬프와 함께 저장한다.
  4. 데이터 질의 및 렌더링 (Grafana)
     • 사용자가 그라파나 대시보드에 접속하면, 그라파나 백엔드는 설정된 패널의 쿼리(PromQL)를 프로메테우스 API(9090)로 전송한다.
     • 프로메테우스는 TSDB에서 해당 기간의 데이터를 검색하여 JSON 형태로 반환한다.
     • 그라파나는 반환된 데이터를 브라우저에서 그래픽으로 랜더링한다.

---

트러블 슈팅

• 상황 : 프로메테우스 Web UI에서 PromQL에 openstack을 입력하면 사진과 같이 오픈스택과 관련된 자동완성이 표시된다. 하지만 openstack_glance_images를 검색해보면 아무런 결과가 뜨지 않는다.
• 해석 : 자동완성 리스트가 뜬다는 것은 프로메테우스가 Exporter와 연결에는 성공했고, 어떠한 메트릭들을 수집할 것이라는 메타데이터까지는 받아왔다는 뜻이다.
• 원인 : 스크랩 시간이 너무 오래 걸려서 타임아웃이 발생했기 때문이다.
  • 오픈스택 API는 응답 속도가 느린 편인데, 프로메테우스의 기본 타임아웃(10초) 내에 데이터를 다 스크랩하지 못해 수집 실패(Up=0) 처리 된 것이다.
• 타임아웃 문제가 맞는지 확인하기 위해 up 지표를 통해 연결 상태 확인
  • PromQL : up{job="openstack-exporter"}
    
    • 1 : 정상 / 0 : 연결 실패 (타임아웃이나 에러)
      
      
• 해결 : prometheus.yml 파일을 수정하여 수집 대기 시간을 늘린다.

- job_name: 'openstack-exporter'
    scrape_interval: 60s    # 수집 주기를 1분 정도로 넉넉하게
    scrape_timeout: 50s     # 50초까지 기다려주도록 설정
    ...

# 설정 적용을 위해 프로메테우스 컨테이너 재시작
$ docker restart prometheus