현재 근무하는 회사의 팀에서는 항상 주기적으로 발생하는 이벤트가 있다.
그것은 API 서버 or DB의 CPU 리소스가 과부하되면서 서비스에 문제가 발생하는 이벤트이다.
위 상황에서는 리소스 모니터링을 위해서 AWS의 CloudWatch 같은 기본 모니터링을 통해 리소스를 체크한다.
하지만 기본으로 제공되는 모니터링 대시보드는 상세 매트릭 정보를 전달받지 못한다는 문제가 있다.
=> 무슨 소리냐? 1분 단위로 상세 매트릭도 구성이 가능하고 대시보드도 원하는 형태로 커스텀이 가능할텐데???
커스텀이 가능한것은 사실이지만, 상세 매트릭 정보를 전달 받지 못한다고 표현하는 이유는 우리팀은 돈에 매우 인색하기 때문이다.
비용 문제 + 시간 문제로 현재 팀에서는 클라우드 서버 or 온프레미스 서버 등의 하이브리드 구성에 대한 종합 모니터링 도구가 없다.
그래서 지금까지는 서비스를 관리하는 담당자들은 필요하다면 직접 수동으로 모니터링 했었다.
무한 루프마냥 반복되는 이 과정을 더이상 겪고 싶지 않아서 서버들의 리소스 모니터링 도구로 대표적으로 사용되는 조합인 Grafana + Promethues 조합을 활용해서 모니터링 시스템을 도입했다.
=> 모니터링 시스템을 도입했으니 서버들의 자원 리소스 모니터링이나 상태 체크가 편해졌을건데 뭘 더 추가하냐? 너무 게으른거 아니냐?
리소스 모니터링 대상에 대한 기본적인 관리 방법은 리스트는 정적 형태의 설정으로 관리하는 구조이다.
그래서 새롭게 추가되는 서버가 생기게 될때마다 서버리스트에 직접 추가해야한다.
아래는 모니터링 리스트를 설정하는 Promethues에서 사용되는 config 파일인 prometheus.yml이다.
## prometheus.yml
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['dashboard-prod-1:9100']
labels:
instance: dashboard-prod-1
- targets: ['dashboard-prod-2:9100']
labels:
instance: dashboard-prod-2
- targets: ['dashboard-prod-3:9100']
labels:
instance: dashboard-prod-3
# 아래로 모니터링이 필요한 신규 서버에 대한 추가 정보 입력
....
서비스를 운영하는 서버가 추가되면 모니터링 대시보드에서 보여지도록 연결하는데까지 다음의 과정이 수행된다.
[서버 내 리소스 수집을 위한 Exporter 설치 -> 방화벽 내 Exporter 전용 포트 개방 설정 -> 공인 IP 확인 -> config 수정 -> config 적용을 위해 모니터링 시스템 리로드]
=> 어 뭐야? 별거 없는 그냥 반복 작업 아닌가요?
제목을 보면 알다싶이 나는 매우 게으른편에 속하기 때문에 삭제하고 추가하고 하는 과정을 반복하는게 싫었다.
이 생각을 하던 도중에 "정적 파일을 추가 or 삭제하는 과정을 없애버리면 되는것 아닌가?" 라는 생각이 들었고, 그래서 Consul이라는 도구를 도입하기로 결정했다. (무엇인지 궁금하시다면 설명하기 귀찮기 때문에 링크를 넣어두겠습니다.)
Consul 공식 사이트 : Link
=> 한대 맞기 전에 빨리 Consul이 무엇인지 잘 설명해봅시다.
정확한 설명은 링크(Link)에서 보시고.. 대신 Consul을 사용한 목적을 빠르고 뇌에 정확히 꽃히도록 설명해드리겠습니다.
정적으로 관리되는 서버 목록을 동적으로 편하게 관리하기 위한 목적으로 사용했으며, 아래 이해하기 쉽도록 동작 방식을 정리했습니다.
이제 Consul을 도입하기 위한 과정을 아래 순서대로 작성하겠습니다.
- Grafana + Promethues + Consul 서비스에 대해서 구성했다는 전제하에 작성합니다!
▶ Promethues의 정적 설정 대신 Consul의 서비스 목록을 바라보도록 config 수정 (promethues.yml)
주의 : docker-compose로 구성해서 사용중이기 때문에, 도입 환경에 따라 설정값이 달라질 수 있습니다.
global:
scrape_interval: 15s
scrape_configs:
# Consul 설정
- job_name: 'consul-discovered-services'
consul_sd_configs:
- server: 'consul:8500'
datacenter: 'dc1'
tags:
- monitoring
# 서비스 이름을 job 레이블로 설정
relabel_configs:
- source_labels: [__meta_consul_service]
target_label: job
# 서비스 주소와 포트 설정
- source_labels: [__meta_consul_service_address, __meta_consul_service_port]
target_label: __address__
separator: ':'
▶ Consul 서비스가 정상적으로 동작한다는 가정하에 아래 캡처 이미지처럼 확인 가능합니다.
▶ Consul에 서비스를 등록하는 방법은 2가지가 있다.
- Consul Agent를 리소스 모니터링이 필요한 해당 서버에 설치하는 방법
- HTTP API를 통해 직접 등록하는 방법
나는 유연한 방식을 선호하기 때문에 API 방식으로 Consul 서비스 목록을 등록하는 방법을 사용했다. (반대로 API를 통해 서비스 목록에서 제외하는것도 가능합니다.)
서비스 목록 리스트에 동적으로 추가되는것을 확인할 수 있습니다.
또한 Grafana 대시보드에서 Consul에서 추가한 리스트가 자동으로 반영되는것도 확인 가능합니다.
=> 그 Node Exporter랑 Consul 서비스 목록에 등록할때 사용한 스크립트 정도는 제공해주셔야하지 않겠습니까?
그러실줄 알고 제가 사용했었던 설정 스크립트를 파일로 첨부했습니다!
이 글을 읽는 분들도 Consul을 도입해서 리소스 모니터링에 필요한 서버 리스트를 편하게 관리할 수 있게 한번 도전해보시면 좋겠습니다.
저의 부족한 글에 관심을 가지고 읽어주셔서 정말 감사합니다.
마침