오픈소스 컨테이너 모니터링 툴 Prometheus(1) : 이론편

반응형

오픈소스 컨테이너 모니터링 툴 Prometheus(1) : 이론편

안녕하세요 김민욱입니다.

 

이번 포스팅은 대표적인 컨테이너 모니터링 툴인 prometheus에 대해서 포스팅하고자 합니다. 아마 많은 분들이 prometheus에 대해 접해보셨을 테고 실질적으로 이를 이용해 인프라에 적용해보셨을 것으로 예상됩니다. 저는 prometheus의 공식 문서를 기준으로 이를 작성하고 실제로 설치 및 실험을 통해 어떤 범위까지 모니터링이 가능한지 궁금했던 부분에 대해 기록해 놓았던 것을 공유드리는 포스팅으로 생각해주시면 될 것 같습니다. 

 

그림 1. Prometheus  심볼

Prometheus는 2012년에 SoundCloud에 의해 개발된 오픈소스 시스템 모니터링 프로젝트입니다. 그리고 CNCF(Cloud Native Computing Foundation)에 2016년 Kubernetes에 이어 합류하게 되었습니다. 제가 생각하는 Prometheus의  특징을 뽑으라면 하나는 Pull 방식의 모니터링과 컨테이너 모니터링 그리고 다른 모니터링 프로젝트와는 다르게 단일 에이전트가 아닌 모니터링 대상에 따라 전용 Export로 모니터링한다는 점을 뽑을 수 있을 것 같습니다. 그럼 지금부터 Prometheus의 구조를 보고 하나씩 살펴보도록 하겠습니다. 

 

Prometheus 데모 사이트 : http://demo.robustperception.io:9090/graph

 

 

Architecture & Feature

Prometheus는 HTTP 기반으로 Pull 방식의 모니터링을 사용하고 있기 때문에 기존의 모니터링 시스템과 조금은 다른 구조를 가지고 있습니다. 특히 Prometheus는 컨테이너를 기반으로 운용되기 때문에 쉽게 설치 및 배포할 수 있었습니다. 그럼 지금부터 Prometheus 구조를 보고 하나씩 살펴보도록 하겠습니다. 

 

그림 2. Prometheus 구조

먼저 Prometheus 서버를 구성하는 주요한 컴포넌트는 Retrieval, Storage, PromQL이 있습니다. Retrieval은 자동으로 모니터링 대상을 찾고, Storage는 말 그대로 수집된 데이터를 저장합니다. PromQL은 수집 된 데이터를 필터링하기 위한 쿼리문을 담당하고 있습니다. 

 

Pushgateway는 짧은 시간 동안 발생하는 데이터, 쉽게 표현하자면 모니터링 대상에서 발생하는 휘발성 데이터를 가지고 있습니다. 모니터링 대상에서 시간이 지나면 데이터가 사라지기 때문에 Pushgateway에 데이터를 보내고 Prometheus 서버는 Pushgateway에서 데이터를 가져오게 됩니다. 

 

AlertManager는 이름에서도 알 수 있듯이 알람을 관리하고 있습니다. 이는 별도의 서버로 동작하게 됩니다. 알람에는 http, email, hipchat, slack 등이 있고 이는 Prometheus 서버의 구성 정보에서 설정할 수 있게 됩니다. 

 

Prometheus의 Alertmanager는 4가지의 특징을 가지고 있습니다. 

 

* Grouping : 유사한 알람을 그룹핑하여 불필요한 부하를 줄입니다. 

 

그림 5. Alert Features[1]

* Inhibition : 유사한 알람이 이미 실행 중이면 특정 알람을 표시하지 않습니다. 

* Sliences : 알람을 무시합니다. 

* High Availability Support : 고가용성을 위한 클러스터 구성을 지원합니다.

 

위에서 말씀드린 내용은 공식 문서에서 언급하고 있는 Alertmanager의 특징입니다. 구조에서 보시는 것처럼 다수의 Prometheus 서버는 계층적으로 서로 연결될 수 있고 각 Prometheus 서버로 부터 발생하는 알람은 하나의 AlertManager에 장애 알람이 전달될 수 있습니다. 

 

그림 6. Exporter

그림 6에서는 Prometheus의 Exporter를 나타내는데, Prometheus는 Zabbix와 달리 단일 Agent를 사용하지 않고 특정 대상에 대해 각각의 exporter를 가지고 있습니다. 이들은 커뮤니티에 의해 구현되어지는 경우도 있습니다. 공식 홈페이지를 보시면 GO, Pthon, Java, Ruby 등과 같이 exporter를 구현할 수 있는 프레임워크와 같은 틀을 각 언어마다 제공하고 있습니다. 관심이 있으시면 한 번 확인하셔도 좋을 것 같습니다. 

 

Visualization

지금부터는 모니터링 프로젝트의 꽃인 Dashboard에 대해서 한번 차이를 확인해보도록 하겠습니다. 그전에 Prometheus는 타임 시리즈 데이터베이스를 사용합니다. 이는 시간에 따라 데이터 등을 저장하고 있습니다. 타임 시리즈는 요즘 모니터링에서 많이 나타나는 특징이며, Prometheus는 수집된 데이터에 쿼리문을 넣어 필터링할 수 있습니다.

그림 7. Prometheus Data Model

이렇게 수집 된 데이터를 본인이 원하는 데로 쿼리문을 작성하여 필터링해 원하는 그래프를 도출할 수도 있습니다.

다음은 기본적으로 Prometheus에서 제공하는 Dashboard입니다. 

그림 8. Promethus 대시보드

그림 8에서는 기본적인 대시보드를 나타내는데 특별한 기능은 없고 현재는 Node Exporter 즉 Node를 수집하는 Exporter를 사용하여 CPU, memory, disk 등을 모니터링하고 있는 그림입니다. 

 

그림 8. Grafana 연동

Grafana는 시각화 프로젝트입니다. 아주 화려하고 한눈에 식별이 용이하도록 시각적인 효과를 많이 포함하고 있습니다. 2.5.0 버전부터 정식으로 Prometheus가 데이터 소스로써 기본으로 포함되어 있습니다. 만약 Prometheus를 사용하시는 분들은 Grafana와의 연동을 추천드립니다. (쿼리문을 잘만 사용한다면, 실제로 적용하기에도 충분하다고 생각 됩니다)

 

Container Monitoring

이번에는 cAdvisor와 Prometheus를 연동하여 컨테이너 모니터링을 하고 특정 실험을 진행해보도록 하겠습니다. 먼저 cAdvisor는 컨테이너의 자원 사용 및 상태에 대한 데이터를 수집하여 Prometheus에게 전달할 수 있습니다. 이는 실행 중인 컨테이너에 대해 정보를 수집하고, 처리하는 exporter의 기능을 가지고 있습니다.[2]  cAdvisor는 개별적으로 컨테이너로 존재할 수도, POD로 존재할 수도 있기 때문에 두 개의 차이가 궁금했습니다. 

 

그림 9. cAdvisor 테스트 구조

그림 9에서는 cAdvisor를 이용한 컨테이너 모니터링 테스트 구조를 나타냅니다. case1의 경우 미니 온 안에 cAdvisor가 있는 것이고 case 2는 POD 안에 cAdvisor가 존재합니다. 그럼 두 개의 차이에 따라 변화가 있을까요? 먼저 각각의 cAdvisor컨테이너는 는 아래와 같이 배포하였습니다.

 

그림 10. pod cAdvisor
그림 11. Minion cAdvisor

 

그림 10에서는 kubernetes의 pod를 이용하여 cAdvisor를 배포하였고 그림 11에서는 docker를 이용하여 Minion에 직접 cAdvisor를 배포 하였습니다. 

 

Case1 : cAdvisor in Pod

pod 안에 있는 cAdvisor는 pod와 minion 모두에 대한 리소스를 모니터링 할 수 있었습니다. 따라서 배포 된 pod를 모니터링하기 위해서는 각 pod 마다 cAdvisor를 사용하는 것이 좋지만 이는 한 minion에 여러개의 pod와 cAdvisor가 존재한다면 데이터가 중복 수집 될 수 있습니다.

 

Case2 : cAdvisor in Minion

수집의 범위는 Case1과 동일합니다. 해당 minion에서 프로세스와 pod를 모두 모니터링 할 수 있습니다. 클러스터의 모든 컨테이너를 모니터링하려면 각 minion마다 하나의 cAdvisor를 배치하는 것이 좋습니다. 

 

case1,2,는 pod 또는 minion을 동일한 범위를 모니터링 하지만, 특정 pod를 추적하고 해당 pod를 모니터링하기 위해서는 pod에 cAdvisor를 설치해야합니다. 

 

결론

이번 포스팅에서는 Prometheus의 기본과 컨테이너 모니터링에 대한 간단한 실험을 작성하였습니다. 제가 느꼈던 부분은 pod 단위로 모니터링 하기 어려웠고, 다소 사용이 까다롭다는 생각이 들었습니다. 하지만 굉장히 가볍고 훌륭한 쿼리 기능으로 사용법을 조금만 익히면 훌륭하게 모니터링 프로젝트로 기능을 다할 것으로 생각됩니다.  다음 Prometheus 포스팅에서는 설치와 활용에 대해서 설명 드리겠습니다. 부족한 점이 있다면 언제든지 연락주시면 감사하겠습니다.

인용글

[1] Prometheus : https://prometheus.io/

[2] cAdvisor : https://github.com/google/cadvisor

업데이트로그

------------------------------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.

 

반응형

댓글

Designed by JB FACTORY