Prometheus의 특징과 아키텍처
Prometheus란?
Prometheus(프로메테우스)는 SoundCloud라는 해외 음악 관련 서비스 엔지니어가 개발한 감시 시스템이다. 원래, Kubernetes의 전신이었던 Google의 내부에서 사용되고 있던 Borg(보그)라고 하는 시스템이 있었는데, 그것을 감시하기 위한 소프트웨어로서 Borgmon이라고 하는 것이 Google 사내에서 만들어 졌다. 그 Borgmon을 흉내내어 오픈 소스로 공개한 것이 Prometheus이다.
Prometheus는 시계열(time series) 데이터베이스를 채택하고 있는 Pull 형의 데이터 모델을 가지고 있어, Service Discovery(서비스 디스커버리)라는 기능에 의해 대상을 자동적으로 모니터링을 해준다. 또한 PromQL(프롬 큐엘)이라는 전용 쿼리 언어가 있으므로 이를 사용하여 간단하고 유연한 쿼리를 실행할 수 있다. 그러고, 다양한 Exporter(익스포터)라는 것이 준비되어 있다. 이른바 감시 에이전트이다. 이것을 사용하는 것으로 서버 뿐만이 아니라 특정의 소프트웨어나 서비스 등 여러가지 것을 모니터링할 수가 있다.
Prometheus의 어떤 점이 대단한가?
Prometheus의 어떤 점이 대단한가? 하는 이야기를 여러가지 하려고 하는데, 먼저 아래 내용을 보자. 이는 2016년의 PromCon 이라는 해외 컨퍼런스에서 발표된 내용을 인용한 것이다.
DreamHack의 시스템 모니터링에 Prometheus가 사용되었다 ( 출처 )
이에 따르면 DreamHack이라는 게임 관련 이벤트가 이전에 행해졌는데, 이 이벤트의 백그라운드의 시스템을 감시하기 위해서 Prometheus가 이용되었다고 한다. 이 때는 10,000대의 컴퓨터, 그리고 500대의 스위치를 감시하는 것으로 매우 유명해졌다. 이는 2016년에 있던 이야기로 그 무렵에 이미 이만큼의 컴퓨터를 감시할 수 있었고, 지금은 그 이상의 업데이트가 되어 있을 것이며, 퍼포먼스는 더욱 더 높아졌을 것으로 기대할 수 있는 것이 아닐까 생각된다.
Prometheus 아키텍처
Prometheus 문서를 보면 Prometheus 아키텍처로 아래와 같은 그림이 나와 있다.
Prometheus 아키텍처
이 그림은 크게 6개로 나눌 수 있다.
- Prometheus Server(Prometheus 본체)
- Service Discovery
- Exporter라는 감시 에이전트
- 경고의 기능을 잡는 Alert(경보)
- 그리고 쿼리의 언어인 PromQL
- 시각화 기능인 Visualization
이렇게 6개로 구성된다. 이에 대해 각각 설명해 보도록 하겠다.
Prometheus Server
Prometheus Server은 앞에서 말했듯이 Prometheus 본체이다. 이 Prometheus Server 자체는 각 모니터링 대상에서 Metrics(메트릭스)를 수집하거나, 수집한 Metrics에 대해 쿼리를 실행하여 Metrics 정보를 참조하거나, 자동으로 내부적으로 정기적으로 쿼리를 실행하여 경고를 관리하거나 하는 것을 담당한다.
또한, 이 Prometheus Server를 시작으로 Prometheus의 에코시스템에 포함된 소프트웨어의 많은 싱글 바이너리로 동작해 준다. 즉, 1개의 바이너리를 다운로드하여 오는 것만으로 동작할 수 있다. 예를 들어, Zabbix를 이용하려면 먼저 Zabbix 서버의 설치 절차가 발생한다. 그러고 그 뿐만 아니라 MySQL을 준비하거나 그 주변의 설정이 의외로 번거로운 것이 있을 수 있다. 여기서 Prometheus Server에서는 정말로 바이너리를 1개 실행하는 것만으로 동작시킬 수 있다는 특징이 있다.
Service Discovery
Service Discovery는 모니터링되는 정보를 자동으로 받아오는 구조이다. 이를 사용하므로써, 클라우드 플랫폼 또는 특정 소프트웨어 등의 해당 API를 주기적으로 호출하여, 거기에 등록된 인스턴스 정보를 수집한다.
예를 들어, 어느 클라우드 서비스에 서버가 3대 있고, 그 서버들의 이름과 IP 주소 정보를 API를 통해서 받아와 그것을 타겟 정보로써 Prometheus에 전달한다. 그 후에 서비스를 스케일 해야 할 필요가 있어, 서버 3대를 추가하게 되었다. 이제 서버가 6대가 된 것이다. 이 3대가 추가되었다는 것도 API를 주기적인 호출로 함으로써 알 수 있으므로, 자동으로 추가된다. 그러고, 과부하 상태가 종료되어 서버를 3대 삭제하게 되면, 이는 3대로 돌아갈 것으로 이런 경우도 API를 주기적인 호출로 부터 3대가 줄었다고 하는 정보를 받아올 수 있으므로, 자동적으로 타겟을 3대 줄이는 동작을 한다. 이런 구조 인해 지금까지 1개씩 1개씩 수동으로 등록하거나, 전용 파일에 등록하는 것과 같은 번거로운 작업을 자동화할 수 있는 것이다.
이것으로 우리가 기뻐할 있는 것은, 현대의 클라우드 서비스라든지 혹은 마이크로 서비스라고 불리는 시스템을 이용하는 경우에 각각의 인스턴스의 정보는 매우 빈번하게 바뀌게 된다. 이야 말로 지금은 Docker라든지 Kubernetes라고 하는 컨테이너가 당연시 되었다. 컨테이너는 오래동안 계속 사용하는 일도 있지만, 어느 쪽은 생성했다가 사라지고, 다시 또 생성되었다가 하는 것을 반복하는 것이 전제로서 되어 있다. Service Discovery를 사용하면 이러한 경우에도 더 쉽게 대응할 수 있게 되었다.
Service Discovery가 지원하는 플랫폼은 Azure, AWS EC2, GCP GCE, OpenStack 이고, 물론 Kubernetes에도 대응하고 있다. 이 외에도 추가 확장을 통해 다른 플렛폼에서도 이 Service Discovery을 사용하여 정보를 얻을 수 있다.
Exporter
Exporter은 이른바 감시 에이전트이다. Exporter는 모니터링 대상에서 Metrics를 수집하여 Prometheus에 공개한다. 예를 들어, Nginx의 CPU 사용률이 어떤지, Request가 몇 건 오고 있는지 등의 정보는 받아올 수 있는 있지만, 각각의 포맷을 Prometheus는 모른다. 매번 그것에 대한 형식을 Prometheus 측에서 유지 보수하는 것은 어렵다. 그래서, 대신에 이 Exporter라고 하는 것을 사이에 두므로써, Exporter가 Nginx라든지 Apache라든지, 대상의 시스템으로부터 Metrics 정보를 받아올 수 있다. 받아오는 방법은 API이거나 직접 특정의 커멘드를 실행하거나, 여러가지 있다. 그렇게 해서 받아온 Metrics 정보를 Prometheus가 읽을 수 있는 형태로 변환해 주는 것이 이 Exporter라는 시스템이다.
Exporter는 현재 600종류 이상이라는 엄청난 개수가 있다. 커스텀으로도 만들 수도 있으므로, 다른 시스템에서는 할 수 없었던 감시도 간단하게 감시할 수 있다.
Alerting
다른 모니터링 시스템에서는 경고 메커니즘이 표준으로 제공되어야 한다는 것이 당연하다고 생각된다. 그러나 불행히도 Prometheus의 경우는 경고 기능 자체는 없다. 그래서 AlertManager(경고 관리자)라는 컴포넌트를 사용한다. 이는 Prometheus 커뮤니티의 의해 유지 관리하는 소프트웨어 중 하나이지만, 이 AlertManager가 훌륭하다. 예를 들어, 여러 Prometheus를 배포하여 때에 경고 처리를 1개의 AlertManager로 되어 있다면, 자동으로 중복을 제거한다. “이 경고와 이 경고는 같은 경고이기 때문에 2개를 내야 할 필요가 없어요"라는 것으로 1개로 만들거나, 여러 유사한 경고를 모와서 “이런 장애가 발생하였다"라는 형태로 그룹화해 주거나, Prometheus의 Metrics의 라벨을 보고 “이것은 A팀, 이것은 B팀"이라고 하는 형태로 라우팅하거나, 이러한 유연한 구조로 AlertManager는 동작해 준다.
즉, 이러한 경보에 관련된 유연한 구조를 Prometheus 본체에서 만드는 것이 아니라 굳이 분리함으로써 각각의 라이프 사이클을 격리하고, AlertManager는 경보에 대해 보다 전문적으로, 보다 신속하게 개발을 진행해 간다 라고 하는 것으로 컴퍼넌트가 나뉘어져 있는 것이다.
PromQL
PromQL은 Prometheus Query Language의 약자이다. 이것은 나중에 다시 자세히 소개하지만, 매우 간단하고 시계열 데이터와 매치되는 형태로 사용할 수 있다. 이 PromQL의 훌륭한 점은 Metrics 라벨로 필터링 할 수 있다. 예를 들어, 인스턴스의 이름, IP 주소, 클라우드 플랫폼의 리전 등을 라벨로 사용할 수 있다. Metrics에 등록된 라벨로 필터링할 수 있으므로 매우 직관적이다.
또한, PromQL은 필터링 외에도 함수를 사용하여 집계를 수행하거나, 경고를 실행하는 등 폭넓게 사용되고 있다. PromQL은 Prometheus를 이용할 때, 반드시 알아야 할 요소 중 하나이다.
Visualization
Prometheus에서 시각화를 할 때, 두 가지 방법이 있다. 그 하나는 Prometheus에 있는 가진 웹 UI를 사용하는 방법이다. React로 만든 웹 UI가 Prometheus 본문으로 제공되며 Prometheus 엔드포인트에 액세스하여 간단한 Metrics 쿼리를 실행할 수 있다. 예를 들어, 다음 그림은 Prometheus를 실행하는 서버의 메모리 사용률을 보여준다. 이러한 간단한 Metrics라면 이 웹 UI에서도 볼 수 있다.
Prometheus 웹 UI를 사용한 Visualization
그러나, 더 복잡하거나 기존 패널과 그래프를 저장하고 싶다면, 이 웹 UI으로는 부족하기 때문에 보다 전문적으로 향샹된 Grafana를 사용할 수 있다. Grafana는 Prometheus를 지원하며 표준 데이터 소스로 Prometheus를 선택할 수 있다. 아래 그림은 NodeExporter라고 하는 서버를 감시하기 위한 Exporter의 정보를 표시한 대시보드인데, 이런 형태로 상당히 풍부한 대시보드를 만들 수 있다.
Grafana를 사용한 Visualization
이 Grafana와 방금 전의 Web UI의 2개가 있는데, Grafana가 더 기능이기 많기 때문에 이것만 사용하면 좋겠다는 것은 아니고, 자주 보는 대시보드나 보존해 두고 싶은 대시보드는 Grafana로 사용하고, 그 자리에서 인스턴스에 발행하고 싶은 쿼리, 예를 들어, 실패가 일어났을 때에 조사하기 위해 여러가지 쿼리를 만들어 발행하는 경우에는 Prometheus 표준의 Web UI를 활용하면 좋다.
Prometheus의 컴포넌트 요약
이런 식으로 Prometheus의 아키텍처는 주로 6가지 구성 요소로 구성된다. 이렇게 보면 의외로 심플하다고 생각된다. Service Discovery는 Prometheus의 기능 자체이므로 Prometheus Server를 사용하면 최소한의 모니터링이 가능하다.
다음은
다음은 Prometheus를 사용하면서 꼭 알았으면 하는 이야기로서, CNCF라고 하는 조직과의 관계나 Observability(옵서버빌리티)에 대해 다뤄보려고 한다.