들어 가며
분산 환경에서 많은 시스템의 자원과 애플리케이션의 상태를 모니터링 하는 것은 시스템 운영자에게 중요한 임무입니다. 그러나 분산된 많은 시스템을 모니터링 하는 것은 결코 쉬운 일이 아닙니다. 그래서 지금까지도 기업은 전문 회사가 제공하는 고가의 모니터링 솔루션을 사용하는 경우가 많았습니다. 그러나 몇 년 전 오픈 소스 커뮤니티에서 Prometheus 와 Grafana 프로젝트가 등장하고 모니터링 기능을 좀 더 잘 사용할 수 있는 확장 오픈 소스 들도 지속적으로 발전하면서, 오픈 소스로도 기업 분산 환경의 많은 시스템과 애플리케이션을 모니터링 할 수 있는 길이 열리고 있습니다.
위와 같은 상황에서 필자는 분산 환경의 시스템 자원과 애플리케이션 상태를 모니터링 할 수 있는 기술을 오픈 소스로 구성하는 실험을 이 글에서 공유합니다.
실험 환경 개요
실 분산 시스템을 모니터링 하기 위해서, 우선 실험 환경을 구성해야 합니다. 실험 환경은 또한 실 분산 환경으로 확장될 수 있게 구성해야 합니다.
실험 의도와 가정
필자는 분산 시스템을 모니터링 하기 위해서 아래와 같은 실험 환경을 구성했습니다.
- 실험에 사용된 VM 은 분산 시스템의 모니터링 대상 시스템에 대응됩니다.
- 실험은 대상 VM 에 node-exporter 와 process-exporter 를 프로세스로 실행했습니다.
- 실제 운영 시스템 환경에서 node-exporter 와 process-exporter 는 시스템 서비스로 실행될 것입니다.
- 실험에서 Prometheus 와 Grafana 의 실행은 Docker 컨테이너 기술을 사용했습니다. 실험 실행 환경에 최소의 자원을 사용하면서 실험 환경을 실 환경과 유사하게 꾸미고, 독자들에게 컨테이너 기술도 소개하려는 의도였습니다.
- Docker 컨테이너 기술은 이후 OpenShift/kubernetes 플랫폼에 Prometheus 와 Grafana 를 실행하게 확장될 수 있을 것입니다.
- 실험은 도메인 이름 기반 시스템 아키텍처를 권장하기 위해 dnsmasq 를 이용한 DNS 서비스 기술을 포함했습니다.
실험 환경 구성도
분산 시스템을 모니터링 하기 위한 최소 실험 환경을 로컬 PC 에 다음과 같이 구성했습니다.
위 구성도는 각 요소들이 사용하는 tcp 포트와 접속 정보를 보입니다. 그러므로 위 정보를 잘 숙지하면 이후 설명을 이해하는 데, 도움이 될 것입니다. 각 요소들의 자세한 설명은 이후 내용을 참조해 주십시오.
참고) VM 을 실행하는 로컬 PC 의 hosts 파일에도 VM 도메인 이름을 등록한다는 점 주의해 주십시오.
실험 환경 준비
VM 환경
실제 분산 환경을 준비하기는 어렵습니다. 그러므로 분산 환경으로 확장할 수 있는 최소의 실험 환경을 구성해야 합니다. 최소의 실험 환경은 1 개의 Linux 가상 머신입니다. 이 가상 머신의 OS 는 Red Hat Enterprise Linux 8 의 커뮤니티 버전인 Rocky Linux 를 사용했습니다. Rocky Linux 를 사용한 이유는 필자가 docker 기술을 테스트할 때 사용하는 머신이라 선택됐습니다. 시스템 모니터링에 사용하는 node_explorter 가 동작하는 Linux 환경이면, 어떤 Linux 버전도 특별히 문제되지 않을 것입니다. 요즈음 Linux 들은 설치가 어렵지 않으니, 독자들도 가상 머신에 설치해 테스트할 수 있을 것입니다. 필자가 사용한 Linux 는 다음과 같습니다.
실험을 편하게 하기 위해, 고정 ip 를 사용했습니다. 그리고 이 실험은 도메인 이름 기반 시스템 아키텍처를 사용하므로, 호스트 이름을 monitoring 란 이름으로 지정했습니다. 실험에 사용한 도메인 이름을 다른 이름으로 변경하는 것으로 어렵지 않을 것입니다. CPU 나 메모리는 실험 VM 치고는 큽니다. 그 이유는 다른 실험도 하는 VM 을 이번 실험에 사용했기 때문입니다. 실험을 위한 사양으로는 1 CORE, 4 GB 도 가능할 것으로 보입니다. 문서 후반 부에 시스템 모니터링 결과를 보면 이점을 좀더 잘 이해할 수 있을 것입니다.
Docker 와 docker-compose 설치
Docker 를 설치하는 이유는 Prometheus 와 Grafana 를 Docker 컨테이너로 실행하기 위해서 입니다. 두 프로세스를 컨테이너로 실행하는 이유는 분산 모니터링을 위한 실험을 편리하게 하기 위해서 입니다. 컨테이너를 사용하면 기동 종료가 손쉬울 뿐 이나라, 실험이 끝난 후, 자원 회수도 간단하기 때문입니다. 실제 운영 환경에서는 컨테이너를 사용할 지, 패키지를 설치할 지, 아니면 전용 VM 에 설치할 지 등, 분산 환경의 규모나, 안정성 확보 등, 여러가지 영향도를 파악해 구성해야 할 것입니다. 필자는 이 실험에서 사용한 컨테이너 기술을 OpenShift/Kubernetes 로 확장할 것을 고려하고 있습니다.
Rocky Linux 는 Red Hat Enterprise Linux 8 의 호환 OS 이므로, 컨테이너 엔진을 기본적으로는 podman 으로 설치합니다. 그런데 인터넷에서 참조하는 문서의 Docker 기술은 Docker 컨테이너 엔진을 사용할 때, 더 잘 동작합니다. 그래서 필자의 Rocky Linux VM 에 podman 이 아닌 docker 커뮤니티 버전을 설치했습니다. 설치 절차는 다음과 같습니다.
sudo dnf update -y
sudo reboot
sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install docker-ce --allowerassing -y
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER
docker run hello-world
sudo dnf install -y curl
sudo curl -L "https://github.com/docker/compose/releases/download/v2.4.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version
Dnsmasq 설치와 VM 도메인 이름 등록
도메인 이름 기반 시스템 아키텍처를 사용하는 테스트 환경을 꾸밀 때 설정할 수 있는 네임 서버가 필요합니다. 네임 서버 중 dnsmasq 네임 서버를 설치하면 손쉽게 분산 시스템의 도메인 이름을 설정할 수 있습니다. 다음은 이번 실험에서 사용하는 VM 호스트 이름을 도메인 이름으로 사용하기 위해 Rocky Linux VM 에 dnsmaq 를 설치하고 docker 도메인 이름을 등록하는 절차입니다.
sudo dnf -y install dnsmasq
sudo vi /etc/dnsmasq.conf
# 다음 두줄을 추가합니다.
no-resolv
server=8.8.8.8
sudo vi /etc/hosts
# 다음 줄을 추가합니다.
192.168.181.100 monitoring
sudo systemctl enable dnsmasq
sudosystemctl start dnsmasq
# 필요 시, 방화벽 개방
sudo firewall-cmd --add-service=dns
sudo firewall-cmd --runtime-to-permanent
# dnsmasq 설정 다시 읽기
sudosystemctl restart dnsmasq
로컬 PC hosts 등록
VM 을 실행하는 로컬 PC 에도 VM 의 도메인 이름을 hosts 파일에 등록해야 합니다.
# Rocky Linux VM
192.168.181.100 monitoring
실험 전 도메인 이름 점검
실험자는 Rocky Linux VM 과 로컬 PC 에서 ping 등을 이용해, Rocky Linux VM 의 ip 주소가 정상적으로 반환되는 지 확인합니다.
$ ping monitoring
PING monitoring (192.168.181.100) 56(84) bytes of data.
64 bytes from monitoring (192.168.181.100): icmp_seq=1 ttl=64 time=0.055 ms
64 bytes from monitoring (192.168.181.100): icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from monitoring (192.168.181.100): icmp_seq=3 ttl=64 time=0.062 ms
모니터링 에이전트 설치 및 실행
Prometheus 로 시스템 자원이나 애플리케이션 정보를 수집하기 위해서는 VM 에 Prometheus 에이전트를 설치해야 합니다. 다음 절차에 따라 에이전트를 설치하고 설정하고 실행하고 수집한 측정값을 확인합니다.
실험 디렉토리
실험자는 아래와 같이 monitoring 이라는 디렉토리를 생성하고, 이 디렉토리를 실험 root 디렉토리로 시작합니다.
mkdir -p monitoring
cd monitoring
node_exporter 설치와 실행
node_exporter 는 Prometheus 프로젝트에서 시스템 모니터링을 위해 진행하는 서브 프로젝트입니다. node_exporter 를 이용하면 시스템 자원(CPU/Disk/Mem/Network)을 상세히 모니터링 할 수 있습니다.
설치에 사용된 node_exporter 버전입니다.
- node_exporter-1.3.1.linux-amd64.tar.gz
설치와 실행 절차는 아래와 같습니다.
cd monitoring
# node_exporter 가 시스템 정보를 수집할 수 있게, 커널 패러미터 조정
sudo sysctl -w kernel.perf_event_paranoid=0
# node_exporter 설치 실행
wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.3.1.linux-amd64.tar.gz
cd node_exporter-1.3.1.linux-amd64
sudo mv node_exporter /usr/bin/
sudo chmod +x /usr/bin/node_exporter
node_exporter --web.listen-address=:9100
node_exporter 는 유저 권한 실행이 가능하다고 문서에 나오므로 유저 모드로 실행했습니다.
process-exporter 설치와 실행
process-exporter 는 시스템에서 실행되는 애플리케이션 프로세스를 모니터링할 수 있게 합니다. process-exporter 실행하면, Prometheus 는 top 명령 등으로 확인할 수 있는 정보들을 수집할 수 있습니다.
설치에 사용된 node_exporter 버전입니다.
- process-exporter-0.7.10.linux-amd64.tar.gz
설치와 실행 절차는 아래와 같습니다.
wget https://github.com/ncabatoff/process-exporter/releases/download/v0.7.10/process-exporter-0.7.10.linux-amd64.tar.gz
tar xvf process-exporter-0.7.10.linux-amd64.tar.gz
sudo mv process-exporter-0.7.10.linux-amd64/process-exporter /usr/bin/
sudo chmod +x /usr/bin/process-exporter
sudo curl -o /etc/process-exporter.yml https://gist.githubusercontent.com/hinunbi/7efd77affeb09b9947bff2fd29806f87/raw/a2e1e314ccf4e85a64da13db90277897142dfb94/process-exporter.yml
sudo process-exporter --config.path /etc/process-exporter.yml \
--web.listen-address=:9256
process-exporter 는 실행에 권한 문제가 있을 수 있어 sudo 를 사용해 실행했습니다.
위 명령 실행 중 다운로드하는 process-exporter.yml 파일의 내용은 다음과 같습니다.
process_names:
- name: "{{.Comm}}"
cmdline:
- '.+'
위 설정은 모든 프로세스를 모니터링하는 것입니다.
수집 테스트
위 절차에 따라 node_exporter 와 process-exporter 가 정상적으로 설치 및 실행되면 각 아래 명령으로 각 수출자가 시스템에서 수집하는 저수준 측정 값들을 확인할 수 있습니다.
node_exporter 시스템 정보 조회
open http://monitoring:9100/metrics
process-exproter 프로세스 정보 조회
open http://monitoring:9256/metrics
Prometheus, Grafana 실행 준비 및 실행
수출자들이 모두 정상적으로 실행되면, 각 시스템 측정값들을 수집할 Prometheus 와 측정값들을 대시보드로 시각화 할 Gafana 를 설치합니다.
Prometheus 설정
이 글에서 사용하는 Prometheus 설정(prometheus.yml)은 다음과 같습니다.
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
- job_name: 'node monitoring'
static_configs:
- targets: ['monitoring:9100']
- targets: ['monitoring:9256']
참고) https://gist.github.com/hinunbi/d20a020ba4f1b31b74d15c40299ed945
targets 항목에 node_exporter 접속 정보와 process-exporter 접속 정보를 포함합니다. 아래 명령들은 위 설정 파일을 포함해, Prometheus 컨테이너가 실행 할 수 있는 환경을 구성합니다.
cd monitoring
# Prometheus 실행 준비
sudo rm -rf data/prometheus
sudo mkdir -p data/prometheus/etc/prometheus
sudo curl -o data/prometheus/etc/prometheus/prometheus.yml https://gist.githubusercontent.com/hinunbi/d20a020ba4f1b31b74d15c40299ed945/raw/46bb4686fedee6c744dc4c240c033d2468730fe4/prometheus.yml
sudo chmod -R a+w data/prometheus
Grafana 설정
Grafana 는 GUI 환경으로 접속 정보를 설정할 수 있으므로, grafana.ini 파일은 Grafana 컨테이너 이미지 내 파일을 그대로 사용했습니다. 대신 Grafana 가 구성한 디렉토리와 파일을 호스트로 노출시키게, 볼륨 마운트를 시도했습니다. 그런데 호스트 유저가 생성해 마운트한 디렉토리 권한과 Grafana 컨테이너에서 내부 유저(grafana)가 접근하려는 디렉토리의 기대 권한이 서로 다릅니다. (Docker 가 호스트 볼륨 마운트 시 사용한 유저와 기동 후 해당 디렉토리에 접근하는 컨테이너 유저가 달라저셔 생기는 문제입니다.) 그 결과 Grafana 이미지는 컨테이너로 실행하는 데, 호스트 파일 디렉토리에 Grafana 사용 파일을 마운트 하는 경우, 권한 부족 오류가 발생합니다. 실제 운영 환경에서는 좀더 섬세한 제어를 포함한 방법을 사용해야 할 것이지만, 실험 관점에서는 실행될 수 있는 우회 방법을 찾아 적용했습니다. 그럼에도 필자가 보기에는 Grafana 프로젝트가 언제부터인가 변경되어 사용하고 있는 사용자 실행 권한 처리는 문제가 있다고 보여집니다. 현재 기준으로 Grafana 가 제공하는 문서의 해결책으로는 해결되고 있지 않습니다. 그러므로 커뮤니티 사용자들은 Grafana 컨테이너 실행 시, 호스트 디렉토리를 마운트 하는 경우, 접근 권한 문제를 만나는 한바탕 고생을 해야 하고, 또 찾은 방법도 이후 Grafana 버전이 업그레이드 되면 계속 동작한다는 보장도 할 수 없습니다. 필자도 이런 점을 고려해 현재 기준으로 가장 최신이지만 특정 버전의 Grafana 컨테이너 이미지를 사용하게 Docker Compose 파일 설정을 구성했습니다. 다음은 Grafana 컨테이너를 실행하기 전에 Grafana 컨테이너에 마운트할 호스트 디렉토리를 먼저 생성하고 권한을 설정하는 명령입니다.
cd monitoring
sudo rm -rf data/grafana
sudo mkdir -p ./data/grafana/etc/grafana/provisioning
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/datasources
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/plugins
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/notifiers
sudo mkdir -p ./data/grafana/etc/grafana/provisioning/dashboards
sudo mkdir -p ./data/grafana/var/lib/grafana
sudo chmod -R a+w ./data/grafana
Docker Compose 설정
Prometheus 와 Grafana 컨테이너는 Docker Compose 를 이용해 실행합니다. 실행을 위한 Docker Compose 설정(docker-compose.yml)은 아래와 같습니다.
version: '3'
services:
prometheus:
image: prom/prometheus:v2.35.0
container_name: prometheus
command:
- '--web.listen-address=0.0.0.0:9099'
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
- '--web.console.libraries=/etc/prometheus/console_libraries'
- '--web.console.templates=/etc/prometheus/consoles'
- '--storage.tsdb.retention.time=168h'
- '--web.enable-lifecycle'
volumes:
- ./data/prometheus/etc/prometheus:/etc/prometheus
- ./data/prometheus:/prometheus
ports:
- 9099:9099
networks:
- monitoring-network
grafana:
container_name: grafana
image: grafana/grafana:8.5.0
environment:
- GF_SECURITY_ADMIN_USER=cat
- GF_SECURITY_ADMIN_PASSWORD=meow
- GF_USERS_ALLOW_SIGN_UP=false
volumes:
- ./data/grafana/etc/grafana/provisioning:/etc/grafana/provisioning
- ./data/grafana/etc/grafana/provisioning/datasources:/etc/grafana/provisioning/datasources
- ./data/grafana/etc/grafana/provisioning/plugins:/etc/grafana/provisioning/plugins
- ./data/grafana/etc/grafana/provisioning/notifiers:/etc/grafana/provisioning/notifiers
- ./data/grafana/etc/grafana/provisioning/dashboards:/etc/grafana/provisioning/dashboards
- ./data/grafana/var/lib/grafana:/var/lib/grafana
ports:
- 3000:3000
depends_on:
- prometheus
networks:
- monitoring-network
networks:
monitoring-network:
참고) https://gist.github.com/hinunbi/426ee6792ad25dd9a210c2d89a87334a
위 설정에서 Grafana 의 호스트 디렉토리 마운트 목록은 Grafana 컨테이너 실행 후 발생하는 여러 로그를 분석해, 위 Grafana 설정에서 언급한 내용과 더불어, 정상적으로 실행될 수 있게 구성한 것입니다. Grafana 컨테이너 실행 메커니즘을 좀더 분석한다면 개선된 구성을 찾을 수 있을 것으로 보입니다. 그러나 실험은 기능과 가능성을 입증하는 관점에서 컨테이너가 정상 실행되는 정도에서 구성을 맞췄습니다.
Prometheus 와 Grafana 컨테이너 실행
위 설정 과정을 정상적으로 실행했으면, 마지막으로 docker-compose.yml 파일을 다운로드 해서, docker-compose 명령으로 Prometheus 와 Grafana 컨테이너를 실행합니다.
cd monitoring
sudo curl -o docker-compose.yml https://gist.githubusercontent.com/hinunbi/7efd77affeb09b9947bff2fd29806f87/raw/9fbb4fe1d1290654d0f606b39e9c09df69ce458c/docker-compose.yml
docker-compose up
# 아래는 정상적으로 실행한 콘솔 로그입니다.
Starting prometheus ... done
Starting grafana ... done
...
# backgroud 로 실행 시
docker-compose up -d
Prometheus 를 이용한 모니터링
위와 같이 모든 요소들이 실행되면, 웹브라우저를 이용해 Prometheus 에 접속할 수 있고, 모니터링 중인 시스템에 대한 상태와 수집된 측정값들도 확인할 수 있습니다.
Prometheus 접속
위 과정에서 Promheus 컨테이너가 잘 실행되면, 다음 접속 URL 을 이용해 Prometheus 에 로그인 할 수 있습니다.
open http://monitoring:9099
위 화면에서 PromQL 을 이용해 여러 시스템에서 수집된 측정값을 조회할 수 있습니다.
시스템 모니터링 측정값 확인 예
다음은 시스템에서 동작 중인 시스템의 애플리케이션 프로세스의 CPU 사용 시간을 아래 측정 이름을 이용해 확인한 예입니다.
- namedprocess_namegroup_cpu_seconds_total
위 결과는 Grafana 를 이용해 시각 정보로 표현될 수 있습니다.
시스템 모니터링 대상 시스템 확인
아래 접속 정보로 Prometheus 에 접속하시면 Prometheus 가 현재 모니터링하는 시스템을 확인할 수 있습니다.
open http://monitoring:9099/targets
위 화면은 node_exporter (9100) 와 process-exporter(9256) 에서 정상적으로 수집이 일어나고 있다는 보여줍니다.
Grafana 를 이용한 모니터링
이 실험의 최종 목표는 시스템 측정값을 시각화 하는 데 있다고 해도 과언이 아닙니다. 이제 그 과정을 단계 별로 설명합니다.
Grafana 접속
위 docker-compose 를 실행해, Grafana 컨테이너가 잘 실행되면, 다음 접속 URL 을 이용해 Grafana 대시보드에 로그인 할 수 있습니다.
open http://monitoring:3000 2 3username: cat, Password: meow
참고) username 과 Password 는 docker-compose.yml 설정에서 지정했습니다. 수정이 필요하면 docker-compose.yml 파일을 수정하면 됩니다.
Data Source 연결 설정
로그인 후, 왼쪽 아래에서 두번째 버튼을 선택하면 Data Source 를 추가할 수 있습니다. 추가할 Data Source 는 위에서 실행한 Prometheus 컨테이너입니다. 아래 화면에서 “Add data source” 버튼을 클릭합니다.
“Add data source” 버튼을 클리해 나온 아래 화면에서 “Prometheus” 를 선택합니다.
아래 Data Sources/Prometheus 설정에서 HTTP/URL 입력 값을 다음 접속 정보로 입력합니다. 이 접속 정보는 앞서 Prometheus 접속에서 사용한 접속 정보입니다.
위 화면 아래 “Save & test” 버튼을 클릭해 접속이 성공하면 아래와 같은 화면을 볼 수 있습니다.
위 과정을 마치면 정상적으로 Prometheus 데이터 소스가 성공적으로 연결된 것입니다.
시스템 CPU/Mem/Disk/Network 자원 모니터링
시스템 CPU/Mem/Disk/Network 자원 모니터링 정보는 node_exporter 가 제공합니다. 이 정보는 이미 Grafana 대시 보드로 잘 표현되고 있습니다. 이 모니터링 과정은 다음 몇 번의 클릭으로 완성됩니다.
우선 Grafana 대시 보드의 왼편 “+” 메뉴를 선택해 나온 화면에 “Import via grafana.com” 에 다음 숫자를 입력하고 “Load” 버튼을 클릭합니다.
- 1860
Load 하는 과정에서 Data Source 를 앞서 만든 값을 지정합니다. 그러면 아래와 같은 멋진 대시보를 를 확인할 수 있습니다.
위 화면을 보면 이 실험에서 모니터링되는 VM 의 CPU 사용률은 1 % 미만이고, 메모리도 위 그림에서는 잘 보이지 않지만 1GB 이하임을 확인할 수 있습니다. 즉 필자가 이 실험에서 사용한 VM 보다 적은 VM 으로도 실험이 가능할 것으로 예상할 수 있습니다. 현재 모니터링 되는 VM 에는 node_exporter, process-exporter, Prometheus, Grafana 가 모두 실행되고 있습니다. 이런 점을 참고해 독자들은 실험에 사용할 VM 자원을 설정해 주시면 될 것입니다.
애플리케이션 모니터링
애플리케이션 모니터링 정보는 process-exporter 가 제공합니다. 이 정보도 이미 Grafana 대시 보드로 잘 표현되고 있습니다. 이 과정은 다음 몇 번의 클릭으로 완성됩니다.
우선 Grafana 대시 보드의 왼편 “+” 메뉴를 선택해 나온 화면에 “Import via grafana.com” 에 다음 숫자를 입력하고 “Load” 버튼을 클릭합니다.
- 1860
Load 하는 과정에서 Data Source 를 앞서 만든 값을 지정합니다. 그러면 아래와 같은 멋진 대시보를 를 확인할 수 있습니다.
위 화면을 보면 애플리케이션 프로세스가 개수, CPU, Memory 등 표준 상태 값을 확인할 수 있습니다.
맺음말
이 글에서는 분산 환경에서 시스템의 자원과 애플리케이션 프로세스를 오픈소스 모니터링 도구인 Prometheus 와 Grafana 를 이용해 모니터링 하는 기술을 실험했습니다. 오픈 소스로 시스템과 애플리케이션 모니터링에 관심을 갖는 독자는 이 글을 따라하면 큰 문제 없이 기대한 결과를 맛볼 수 있을 것입니다.
분산 시스템 모니터링을 위해 고가의 상용 제품을 사용하는 기업에게 오픈 소스를 이용한 모니터링의 가능성을 제공하면서 필자가 하고 싶은 이야기는, 2016 년 SpaceX 에서 팔콘 로켓을 발사할 때 모니터링 대시 보드로 Grafana 가 사용돼 화제된 이야기입니다. 우주 항공 기술이 오픈 소스를 활용한다는 점에서 시사점이 큰 사건이었습니다. 바꿔 말해, 일반 기업이 오픈 소스 기술을 도입하지 못할 이유에 대해서도 고민해야 할 것이라고 말할 수 있을 것입니다. SpaceX 사례는 아래 참고 자료 링크로 확인할 수 있습니다.
오픈 소스는 사용하기에 따라, 상용 제품을 대체할 수 있는 강력한 가능성을 제공한다는 점에서 엔지니어라면 꾸준히 탐색하고 공부해야 할 영역입니다. 그러나 항상 부딪치는 문제는 오픈 소스 문서의 모호성, 불일치성, 문서화되지 않는 정보와 같은 것들입니다. 그 결과 원하고자 하는 목표를 달성하기 위해 오픈 소스를 이용하려면 생각보도 많은 노력을 기울여야 하는 경우도 빈번합니다. 그래도 소스가 공개돼 있으니, 노력하면 문제 해결 뿐만아니라, 구현 노하우도 습득할 수 있을 것입니다. 그 과정을 즐기는 것도 엔지니어로서 좋은 태도일 것입니다. 그러나 기업이나 기업 내 엔지니어 입장에서 모든 것을 스스로 하지 않고, 주변의 오픈 소스 전문 회사나 전문가의 도움을 받은 것도 현명한 생각일 것입니다. 기업은 자사의 엔지니어가 오픈 소스 전문 기업 또는 전문가와 협업해 기업의 IT 환경을 가치있게 만들면서 서로가 기술을 공유한다면, 오픈 소스가 추구하는 가장 이상적인 협업 모델일 것입니다. 이를 위해 오픈 소스 기업이 발전 성장할 수 있는 생태계도 반드시 지속돼야 할 것입니다.
이 글이 분산 환경에서 시스템과 애플리케이션을 모니터링을 하려는 분들에게 조금이나마 도움이 됐으면 합니다.
