Prometheus

모니터링 툴 - 프로메테우스 

 

 인류에게 불을 전해주었다는 프로메테우스와 같은 이름의 솔루션이다. 그래서 로고도 불꽃 모양을 가지고 있다. 기존의 모니터링 시스템들은 push 방식으로 구성된 경우가 많다. 서버의 상태를 직접 서버에 알려주고 서버는 그것을 취합하여 이미지화 하는 시스템들과 달리 프로메테우스는 구독 방식을 가지고 있다. 

 

위 그림이 가장 구조를 잘 보여주는 그림인거 같다. 프로메테우스는 단일 서비스로 모든것을 처리하는것이 아니라, 데이터구독을 위한 클라이언트( Expoter) 가 있고 특정기준 발생시 알람을 발생시켜주는 AlertManager 가 있다. 그리고 기본적으로 Web UI 를 제공하여 간단한 서버 상태나 그래프를 볼수 있다. 

 프로메테우스의 특이점 중 또다른 하나는 프로메테우스 서버를 프로메테우스가 모니터링이 가능하다. 프로메테우스를 구축하면서 우려 된건 프로메테우스는 클러스터나 이중화를 지원하지 않는 단일 서버 구성만 가능하다. 그렇다면 하나의 프로메테우스 서버가 100개... 200개.. 300개 ... 계속 늘어난 서버들을 전부 감당이 가능할까? 라는 생각이 들었다. 

 결론부터 보면 프로메테우스서버를 다수를 만들고 그 프로메테우스 서버를 모니터링 하는 프로메테우스 서버를 또 두어서 관리하는 방식이 가능하다. 개인적으로는 이런 구성이 바람직 한지 모르겠지만 이중화 같은 것을 지원하지 않는건 조금 아쉬운 부분이였다. 

 

 프로메테우스의 핵심은 expoter 이다. expoter 는 설치된 곳의 서버 정보를 모두 수집하여 metrix 를 api 형태로 제공을 하는 역할을 한다. 공식사이트에 보면 약 100개정도의 expoter 들을 제공한다. mysql 부터 시작해서 nosql 정보를 수집이 가능하며 간단한 하드웨어 정보는 node_expoter 를 사용하면 대부분 수집이 가능하다. 

 프로메테우스 서버는 expoter 가 수집해놓은 metrix 를 api 콜방식으로 주기적으로 수집하며 그 주기는 설정에 따라 바꿀수 있다. 그리고 expoter 들 중에 내가 원하는 대로 수집하고 싶다면 기존에 제공되는것이 아니라 직접 제작도 가능하다. spring 으로 간단하게 서버를 만들고 프로메테우스 라이브러리를 추가해놓고 한번에 여러가지 expoter 타입을 정의 하면 충분히 커스텀이 가능하다. 

 

그라파나와의 연결 결합이 아주 좋은편이다. 설정도 간단하며, 설치또한 쉽다. 시각화 툴을 굳이 만들지 않고 그라파나를 연동하는것이 좋을거 같다. 단지 그라파나 구성에 있어서 작업이 필요한다. 굳이 귀찮다면 그라파나 템플릿 구성을 다운 받아 사용이 가능하므로 남이 만들어 놓은 구성을 사용해도 된다. 

 

 프로메테우스의 알람 서비스는 굉장이 흥미롭다. 자체적으로 클러스터 구성이 가능하다. 서버는 클러스터가 안되는데 알람은 클러스터가 되니 좀 아이러니 하지만 나름 괜찮은 기능을 제공한다. 이메일, 메신저 연동은 기본적으로 활용이 가능하고 webhook 도 지원이 되어 여차하면 다른 것들을 커스텀해서 연동도 가능하다. 

 

 프로메테우스 서버 

 

 설치는 간단하다 https://prometheus.io/download/ 에서 서버를 다운로드 받고 압축을 풀고 prometheus를 실행해주면 된다. 

 개인적으로 좀 마음에 안드는 부분인데 모니터링 설정은 yml 에 대상 정보를 적어 줘야한다. 그리고 변경시 무조건 프로세스를 다시 실행 시켜주어야 한다. 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).
external_labels:
monitor: 'codelab-monitor'
# Alertmanager configuration
alerting:
alertmanagers:
- scheme: http
static_configs:
- targets: [ xxx.xxx.xxx.xxx:9093]

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
- "prometheus.rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'

# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
scrape_interval : 5s
static_configs:
- targets: ['localhost:9090']
labels:
alias: my


- job_name: 'mariaDB'
scrape_interval : 5s
static_configs:
- targets: ['xxx.xxx.xxx.xxx:9093' ]
labels:
alias: mariaDB
group: 'test'

- job_name: 'heath_checker'
static_configs:
- targets: ['xxx.xxx.xxx.xxx:9093']
labels:
alias: health_Checker
group: 'production'

- job_name: 'redmine'
static_configs:
- targets: ['xxx.xxx.xxx.xxx:9093']
labels:
alias: redmine
group: 'redmine'

 

 

scrape_configs 에다가 각각의 job 을 등록이 가능하고 그 주기도 개별로 설정이 가능하다. 개별로 주지 않으면 맨위에있는 global 옵션이 적용된다. job 은 서비스 단위로 설정하는게 좋고 한서비스에 서버가 다수로 있을시 배열에 ip 를 여러개 추가해주면 된다. alias 를 주어서 기본적은 라벨을 설정이 가능하다. 

그리고 이 설정중에 aleting 이라는 옵션은 alertManager 을 사용하기 위한 설정이다. 프로메테우스 서버에 자체적으로 들어가있는게 아니라 alertManager 은 다운로드 사이트에서 별도로 받아서 설치후 실행을 해줘야 한다. 기본 포트는 9093으로 설정되있고 개인적으로는 같은 서버에 두 서비스를 다 올려놨지만 alertManager 를 클러스터 구성을 한다면 별도 서버로 분리하는게 맞는거 같다. 

 alertManager 를 별도로 관리하기위해 rule_files 란곳에 alert 설정 파일을 별도로 만들어 놓았다. 일반적으로 알람은 장애 직전 혹은 장애가 난 경우 메세지 전달을 위한것이지만  난 alertManager 를 이용하여 현재 정보를 webhook 방식으로 지속적으로 보내는 구성을 만들었다. - scheme: http 이라고 명시 할경우 webhook 방식을 사용하겠다는 의미이다 보고 방식은 자신이 사용하는것에 맞게 다른걸로 변경해도 될것 같다. 

 

groups:
- name: normal
rules:
- record: job_service:rpc_durations_seconds_count:avg_rate5m
expr: avg(rate(rpc_durations_seconds_count[5m])) by (job, service)


# heartbeat alert
# - alert: Heartbeat
# expr: vector(1)
# labels:
# severity: informational

# service availability alert
- alert: service_down
expr: up == 0
labels:
service: Platform
severity: major
correlate: service_up,service_down
annotations:
summary : down
description: Service {{ $labels.instance }} is unavailable.
value: DOWN ({{ $value }})

- alert: service_up
expr: up == 1
labels:
service: Platform
severity: normal
correlate: service_up,service_down
annotations:
summary : up
description: Service {{ $labels.instance }} is available.
value: '{{ humanize $value }}'

# system load alert
- alert: high_load
expr: node_load1 > 0.5
annotations:
description: '{{ $labels.instance }} of job {{ $labels.job }} is under high load.'
summary: Instance {{ $labels.instance }} under high load
value: '{{ $value }}'

# disk space alert (with resource=<instance>:<mountpoint> event=disk_space
- alert: disk
expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) * 100 / node_filesystem_size_bytes > 1
labels:
instance: '{{ $labels.instance }}'
annotations:
summary : disk_usage
value: '{{ humanize $value }}'

- alert: memory
expr: (node_memory_MemFree_bytes+ node_memory_Cached_bytes+ node_memory_Buffers_bytes ) / node_memory_MemTotal_bytes * 100
labels:
instance: '{{$labels.instance}}'
annotations:
description:
summary: memory_free
value: '{{ humanize $value }}'

- alert: cpu
expr: node_load1*100
labels:
instance: '{{$labels.instance}}'
annotations:
description:
summary: cpu_usage
value: '{{ humanize $value }}'

 

체크하는 항목은 cpu, memory , heartbeat, service up/down , disk 정도이다. expr 라는 부분에 조건을 넣어주게 되며 지금은 단순 값을 불러오는것이기 때문에 비교문이 들어가지 않았지만 간단한 부등호를 붙여 주어서 알람 레벨을 컨트롤 할수 있다. webhook 으로 지정할경우 $value 라는 부분이 측정된 값을 의미한다. 앞뒤로 문자를 넣어주면 문장으로 전달도 가능하다. summary 같은곳에 간단하게 내용을 작성해서 전달도 가능하다. 난 summary 를 체크한 서비스 명을 입력하여 사용 하였다. 

 

프로메테우스 서버와 alertmanager 를 설치하고 프로메테우스 서버에 rule 설정파일과 기본 yml 설정 파일을 생성해두고 실행 시켜 놓는다면 기본적인 알람 서비스와 프로메테우스 서버 사용 준비는 완료 된 셈이다. 

마지막은 각 노드 별 에이전트들 설치가 필요하다.  난 기본적인 node_expoter 를 다운받아서 설치해주었다. 

 압축해제후 단순 실행만 하면 바로 정보수집이 가능하다. 

 

이 모든것들을 구성하는데 1시간도 안되는 시간이 걸렸다. alertmanager 사용법에 대한 학습시간과 webhook 서버 제작시간을 제외 한 시간이지만 결코 오래 걸리지 않은것같다. 

일단, 기본제공되는 100개의 expoter 가 수집해주는 내용이 아주 디테일하게 잘 수집해준다. 크게 특이사항이 없는한 기존 expoter 로만으로도 모니터링 시스템을 구축하는데 부족함이 없을 거같다. 구축하면서 expoter 를 섞어서 사용하면 안되나라고 생각할수 있는데 그렇다면 expoter 를 만들어서 사용할것을 추천한다. spring 으로 제작하는 예제가 생각보다 잘 나와있으며 라이브러리를 받아서 사용하면 생각보다 굉장히 만들기 쉽게 구성이 가능하다. 

 일단 오픈소스라서 돈도 안들고 사용가능하다는 강점이 있는거 같다. 그리고 커스텀도 생각보다 용이하고 잘만 이용하면 여러가지 변형에 대응도 쉬운거 같다. 

 아쉬운점은 이중화나 클러스터가 안된다는것과 효율적으로 보이지않는 설정파일이다. 그럼에도 불구하고 괜찮은 모니터링 솔루션 같다!