블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 


문제 정의 

프로메테우스가 좋은 모니터링 시스템이긴 하지만 두가지 결정적인 문제점을 가지고 있다. 결정적으로 클러스터링 구조를 지원하지 않기 때문에, 확장성과 가용성 문제를 가지고 있다. 

확장성 측면에서는 디스크를 증설하거는 것과 같은 하드웨어 스펙 증설로 어느정도는 해결이 가능하지만 데이타 볼륨이 늘어나고 모니터링 대상이 늘어나면 하나의 프로메테우스 인스턴스로는 감당이 어렵다. 


이런 문제를 해결하는 방법으로는 Federation 이라는 방법을 사용한다. 프로메테우스 인스턴스를 여러개를 기동한 다음에, 중앙에 다른 프로메테우스로 부터 메트릭을 수집하는 다른 프로메테우스를 놓는 방식이고, 데이타 양에 대한 문제는 데이타의 해상도 (예를 들어 전면에 데이타 수집 서버가 10초 단위로 수집 했다면, 중앙 서버에서는 1분 단위로 수집 한다는 등)를 줄이거나 평균이나 합과 같은 대표값을 사용해서 해결할 수 있다. 




다른 문제로는 가용성 문제를 들 수 있다. 프로메테우스는 하나의 서버로 기동되기 때문에 그 서버가 장애로 내려가거나 또는 패치나 서버 리스타트와 같은 유지보수 업무에 의해서 프로메테우스 서버가 내려가더라도 그 시간동안에는 매트릭을 수집할 수 없다는 단점을 가지고 있다. 클러스터링 기능이 없기 때문에 이를 해결하기 위해서는 프로메테우스 인스턴스를 두개 이상 띄운 다음에 같은 대상 시스템으로 부터 매트릭을 수집하는 방식인데, 이렇게 하면, 한 서버가 내려가더라도 다른 서버에 매트릭정보가 수집이 된다.



그러나 역시 불편하고 아키텍쳐가 왠지 제대로 되어 보이지는 않는다.


Thanos (타노스)

그래서 이런 문제를 해결하기 위한 오픈소스가 타노스이다.

기본적인 구조는 다음과 같은 컨셉이다.


여러개의 프로메테우스로 부터 매트릭을 조합해서 타노스에서 전체 프로메테우스의 메트릭을 볼 수 있도록 해주고, 수집된 메트릭을 스케일이 가능한 스토리지에 저장해서 특정 프로메테우스 인스턴스가 다운이 되더라도 그 인스턴스가 담당하는 메트릭을 조회할 수 있도록 해준다. 


개념 이해를 돕기 위해서 아키텍쳐를 살펴보자

Thanos Side car & Querier

먼저 데이타 수집과 쿼리 방식을 보면, 프로메테우스 서버에 타노스 에이전트가 인스톨 되서 데이타를 조회할 수 있게 해준다. 프로메테우스는 데이타를 로컬 디스크에 저장하기 때문에 타노스 에이전트 (Thanos Sidecar : 마이크로 서비스 아키텍쳐 패턴중 사이드카 패턴을 사용하기 때문에, 타노스 사이드카라고 부른다.)는 디스크에 저장된 내용을 읽어서 필요시에 쿼리 엔진 (Thanos Querier)에 전달한다. 

여러개의 프로메테우스 인스턴스가 있더라도, 각 프로메테우스 마다 사이드카 에이전트가 설치되서 쿼리 엔진에 전달하기 때문에 사용자 입장에서는 하나의 타노스 쿼리 엔진(UI)만 가지고도 전체 프로메테우스를 통해서 모든 모니터링 대상의 메트릭을 조회할 수 있도록 되는 것이다. 


HA 지원

기본적인 HA 지원 방식은 기존 방식과 다르지 않다. 아래 그림과 같이 프로메테우스 인스턴스를 동시에 두개를 띄워서 같은 모니터링 대상을 모니터링 해서 각각의 지표를 저장하는 방식이다.


그러면 타노스로 인해 오는 장점은 무엇인가? 기존 방식의 경우에는 프로메테우스 인스턴스 각각의 메트릭으로 모니터링 해야 하지만 타노스는 특정 그룹의 프로메테우스 인스턴스들의 지표들의 하나의 인스턴스로 처리해서 메트릭을 보여준다. 즉 두개의 인스턴스에서 수집된 메트릭을 합쳐서(merge) 해서 볼 수 있도록 해주고, 당연히 같은 모니터링 대상을 모니터링 하기 때문에 중복되는 메트릭 값이 있을 수 있는데, 이 중복 값을 제거 해주는 De-duplication 기능을 가지고 있다. 

오랜된 값 저장

앞에서 언급은 하지 않았지만 프로메테우스의 다른 문제점 중의 하나는 로컬 디스크를 사용하기 때문에 일정 기간이 지난 오래된 데이터는 삭제가 된다. 그래서 오래된 데이터에 대한 조회가 불가능하다. 

타노스 입장에서는 오래된 데이터 저장 문제 뿐만 아니라 여러 프로메테우스를 동시에 모니터링 하게 되면 마찬가지로 메모리와 로컬 디스크의 용량 문제로 인해서 여러 프로메테우스를 모니터링 할 수 없는 문제가 발생하는데, 이를 해결하기 위해서 타노스는 외부 스토리지를 사용한다. 


프로메테우스에서 수집된 데이타는 2시간 정도 메모리에 저장이 되었다가 로컬 디스크로 덤프가 된다. 저장된 파일을 타노스 에이전트가 수집해서 외부 스토리지에 저장한다. 외부 스토리지는 Ceph와 같은 분산형 파일 시스템이나 Google Cloud Storage, AWS S3와 같은 클라우드 오브젝트 스토리지를 사용한다. 


그리고 쿼리 엔진에서 근래의 데이타를 조회할때는 프로메테우스 인스턴스에 설치된 타노스 사이드카 에이전트를 통하지만 오래된 데이터는 스토리지에 저장된 데이터는 Thano Storage Gateway라는 컴포넌트를 통해서 조회된다. 이 컴포넌트는 스토리지에 저장된 데이타를 Storage API를 통해서 쿼리엔진과 통신 하는 역할을 한다. Gateway는 단순 쿼리를 API로 저장하는 역할뿐만 아니라 중간에 캐쉬를 제공하여, 빠른 응답 시간을 제공한다. 


이 구조를 이용함으로써 메트릭 데이터의 보관 주기를 늘릴 수 있게 된다. 


스토리지에 저장된 메트릭을 장기 보관하게 되면, 디스크 용량에 대한 문제도 있지만 아주 오래된 데이타(1~2년전)의 데이터를 조회하고자 하면, 많은 데이터를 스캔해야하기 때문에 성능에 있어서 많은 문제가 생길 수 있다. 그래서 스토리지에 저장된 데이타를 관리하는 컴포넌트로 Compactor 라는 컴포넌트가 있다. 기본적으로 데이타 파일을 압축할 뿐만 아니라, 다운 샘플링을 하는데, 다운 샘플링이란, 매트릭이 1분 단위로 샘플링 되었다면, 10분이나 1시간 단위로 샘플링 기준을 다운해서 (해상도를 낮춰서) 전체 데이타 저장 용량을 낮추는 방법이다. 


이외에도 Alert과 룰 관리, UI를 관리하는 Thanos Ruler 라는 컴포넌트가 있으나 여기서는 자세히 설명하지 않는다. 상세한 설명은 타노스 공식 문서를 참고하기 바란다. https://thanos.io


사실 프로메테우스의 한계를 해결하기 위해서 오픈소스 쪽에서 타노스가 좋은 솔루션이기는 하지만, 개인적으로 운영환경에 올린다면 이렇게 복잡한 설정 대신 프로메테우스를 앞에 놓고 (구글 클라우드 엔지니어니까는) 뒤에 타노스 대신 구글 스택 드라이버를 놓는 것이 여러모로 편하겠다는 생각은 좀 든다. https://cloud.google.com/monitoring/kubernetes-engine/prometheus


타노스 온라인 튜토리얼 https://katacoda.com/bwplotka/courses/thanos


참고 자료 : https://www.youtube.com/watch?v=Fb_lYX01IX4



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요



프로메테우스 #3. 그라파나를 이용한 시각화

조대협 (http://bcho.tistory.com)


그라파나(Grafana)는 메트릭을 시각화 해주는 오픈소스 도구이다. Graphite, Prometheus, InfluxDB등 다양한 데이타베이스와 메트릭수집 시스템을 지원하고, 하나의 대쉬보드에 동시에 여러 메트릭 시스템들의 지표를 표시할 수 있고 무엇보다 설치 및 사용 방법이 쉽기 때문에 널리 사용되고 있다

특히 프로메테우스를 잘 지원하고 있기 때문에, 프로메테우스의 메트릭을 그래프로 시각화 하는데도 많이 사용된다. 

그라파나의 설치는 비교적 간단한 편이기 때문에 여기서는 별도로 설명하지 않는다. 설치 방법은 공식 문서 https://grafana.com/docs/grafana/latest/installation/debian/ 를 참고하기 바란다. 

이 문서에서 사용한 테스트 환경은 katakoda.com에서 그라파나 튜토리얼 환경을 이용하였다. https://www.katacoda.com/courses/prometheus/creating-dashboards-with-grafana


앞의 문서 (https://bcho.tistory.com/1373) 에 따라서 프로메테우스를 설치하였으면, 그라파나를 설치한다. 

다음 그라파나 웹 관리 화면으로 접속을 하고 로그인을 하면 아래와 같은 화면을 볼 수 있다. 



이 화면에서 Add Data source를 선택해서 프로메테우스 서버를 새로운 데이타 소스로 등록할것이다.

아래 메뉴에서 데이타 소스의 이름을 “Prometheus”로 설정하고, 타입을 Prometheus로 선택한다.

다음 Http Setting 부분의 Url 부분에, Prometheus 서버의 주소를 적어넣는다. 이 예제에서는 로컬에 프로메테우스를 기동 시켰기 때문에, http://localhost:9090 을 입력하면 된다. 



이제 프로메테우스 서버와 그라파나가 연결되었다. 

이제 그래프를 그려볼 예정인데, 초기 화면으로 돌아가서 “Create your first dash board” 메뉴를 선택한다. 다음 New Dash 보드 메뉴를 선택하여 비어 있는 대쉬 보드를 하나 만든다. 



다음에 그래프를 하나 선택하면 아래와 같이 빈 그래프가 나오는데, 이 그래프를 프로메테우스의 메트릭과 연결할것이다. 




그래프에서 상단의 “Panel Title” 를 누르면 아래 그림과 같이 메뉴가 나오는데, 여기서 “Edit” 메뉴를 선택한다.  그러면 아래와 같이 설정을 할 수 있는 화면이 나오는데, 여기서 “Metric” 메뉴를 선택한다.




Metric 메뉴에서는 시각화 하고 싶은 프로메테우스의 필드를 선택하면 되는데, PrometheusQL을 사용해서 정의할 수 도 있다. 여기서는 간단하게 node의 CPU정보를 시각화 하기 위해서 node_cpu 를 선택하였다. 그러면 아래와 같이 node_cpu 메트릭에 대한 정보를 그래프로 그려주는 것을 확인할 수 있다. 



그라파나에서는 널리 사용되는 시스템에 대한 대쉬보드를 템플릿 형태로 만들어서 사용자들이 서로 공유할 수 있도록 하는데, 템플릿은  https://grafana.com/dashboards 에 가면 찾아볼 수 있다.

여기서는 프로메테우스 node_exporter에 의해서 제공되는 메트릭을 모니터링할 수 있는 대쉬보드를 import 해서 사용해보자. 


초기화면에서 대쉬보드 생성 메뉴로 들어 간 후에, 아래 그림에서 import dashboard 메뉴를 선택하자


그러면 아래와 같이 import 화면이 나오는데, 대쉬 보드 설정을 json 파일로 업로드 할 수 도 있지만, 그라파나 대쉬보드 웹사이트에 있는 경우에는 아래 처럼 URL이나 dashboard id를 넣으면 된다.

아래 그림처럼 https://grafana.com/dashboards/22 를 필드에 입력한다.



로딩된 대쉬 보드를 보면 다음과 같다.





지금까지 프로메테우스에 대한 소개와 내부 구조, 그리고 간단한 사용법 및 시각화 방법에 대해서 알아보았다. 이 정도면 기본적인 모니터링 시스템 구성에는 문제가 없지만, 프로메테우스는 앞선 글에서도 언급 하였듯이 싱글 서버가 기동되는 구조이기 때문에, 확장성과 장애에 취약한 단점을 가지고 있는데, 다음글에서는 이 문제를 어떻게 해결할 수 있는지에 대해서 알아보도록 하겠다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

프로메테우스 #1 기본 개념과 구조

조대협 (http://bcho.tistory.com)


프로메테우스는 오픈 소스 기반의 모니터링 시스템이다. 

ELK 와 같은 로깅이 아니라, 대상 시스템으로 부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있는 시스템이다. 

구조가 간단해서 운영이 쉽고, 강력한 쿼리 기능을 가지고 있으며, 그라파나(Grafana) 를 통한 시각화를 지원한다. 무엇보다 넓은 오픈 소스 생태계를 기반으로 해서, 많은 시스템을 모니터링할 수 있는 다양한 플러그인을 가지고 있는 것이 가장 큰 장점이다. 

특히 이런 간편함 때문에 특히나 쿠버네티스의 메인 모니터링 시스템으로 많이 사용되면서 요즘 특히 더 주목을 받고 있다. 

기본 구조

프로메테우스의 기본적인 아키텍처 부터 살펴보자

먼저 수집 저장 저장 아키텍처를 보면 다음과 같다. 




메트릭 수집 부분

수집을 하려는 대상 시스템이 Target system이다. MySQL이나, Tomcat 또는 VM 과 같이 여러가지 자원이 모니터링 대상이 될 수 있다. 이 대상 시스템에서 메트릭을 프로메테우스로 전송하기 위해서는 Exporter 라는 것을 사용한다. (다른 방법도 있지만 이는 나중에 따로 설명한다. )

풀링 방식

프로메테우스가 Target System에서 메트릭을 수집하는 방식은 풀링 방식을 사용한다. 프로메테우스가 주기적으로 Exporter로 부터 메트릭 읽어와서 수집하는 방식이다. 보통 모니터링 시스템의 에이전트 들은 에이전트가 모니터링 시스템으로 메트릭을 보내는 푸쉬 방식을 사용한다. 특히 푸쉬 방식은 서비스가 오토 스켈링등으로 가변적일 경우에 유리하다. 풀링 방식의 경우 모니터링 대상이 가변적으로 변경될 경우, 모니터링 대상의 IP 주소들을 알 수 가 없기 때문에 어려운 점이 있다. 예를 들어 웹서버 VM 2개의 주소를 설정 파일에 넣고 모니터링을 하고 있었는데, 오토 스케일링으로 인해서 VM이 3개가 더 추가되면, 추가된 VM들은 설정 파일에 IP가 들어 있지 않기 때문에 모니터링 대상에서 제외 된다. 

이러한 문제를 해결하기 위한 방안이 서비스 디스커버리라는 방식인데, 특정 시스템이 현재 기동중인 서비스들의 목록과 IP 주소를 가지고 있으면 된다. 예를 들어 앞에서 VM들을 내부 DNS에 등록해놓고 새로운 VM이 생성될때에도 DNS에 등록을 하도록 하면, DNS에서 현재 기동중인 VM 목록을 얻어와서 그 목록의 IP들로 풀링을 하면 되는 구조이다.

서비스 디스커버리 (Service discovery)

그래서 프로메테우스도 서비스 디스커버리 시스템과 통합을 하도록 되어 있다. 앞에서 언급한 DNS나, 서비스 디스커버리 전용 솔루션인 Hashicorp사의 Consul 또는 쿠버네티스를 통해서, 모니터링해야할 타겟 서비스의 목록을 가지고 올 수 있다. 

Exporter

Exporter는 모니터링 에이전트로 타겟 시스템에서 메트릭을 읽어서, 프로메테우스가 풀링을 할 수 있도록 한다. 재미 있는 점은 Exporter 는 단순히 HTTP GET으로 메트릭을 텍스트 형태로 프로메테우스에 리턴한다. 요청 당시의 데이타를 리턴하는 것일뿐, Exporter 자체는 기존값(히스토리)를 저장하는 등의 기능은 없다. 

Retrieval

서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오고, Exporter로 부터 주기적으로 그 대상으로 부터 메트릭을 수집하는 모듈이 프로메테우스내의 Retrieval 이라는 컴포넌트이다.

저장

이렇게 수집된 정보는 프로메테우스 내의 메모리와 로컬 디스크에 저장된다. 뒷단에 별도의 데이타 베이스등을 사용하지 않고, 그냥 로컬 디스크에 저장하는데, 그로 인해서 설치가 매우 쉽다는 장점이 있지만 반대로 스케일링이 불가능하다는 단점을 가지고 있다.  대상 시스템이 늘어날 수 록 메트릭 저장 공간이 많이 필요한데, 단순히 디스크를 늘리는 방법 밖에 없다. 


프로메테우스는 구조상 HA를 위한 이중화나 클러스터링등이 불가능하다. (클러스터링 대신 샤딩을 사용한다. HA는 복제가 아니라 프로메테우스를 두개를 띄워서 같은 타겟을 동시에 같이 저장 하는 방법을 사용한다. 이 문제에 대한 해결 방법은 Thanos 라는 오픈 소스를 사용하면 되는데, 이는 다음에 다시 설명하도록 한다. )

서빙

이렇게 저장된 메트릭은 PromQL 쿼리 언어를 이용해서 조회가 가능하고, 이를 외부 API나 프로메테우스 웹콘솔을 이용해서 서빙이 가능하다. 또한 그라파나등과 통합하여 대쉬보드등을 구성하는 것이 가능하다. 


이 외에도 메트릭을 수집하기 위한 gateway, 알람을 위한 Alert manager 등의 컴포넌트등이 있지만, 기본적인 엔진 구조를 이해하는데는 위의 컴포넌트들이 중요하기 때문에, 이 컴포넌트들은 다른 글에서 설명하도록 한다.


프로메테우스 아키텍처에서 주의할점

간단하게 프로메테우스 아키텍처를 살펴보았는데, 이 구조에서 몇가지 생각해볼만한 점이 있다. 

어디까지나 근사치라는 점

일단 풀링 주기를 기반으로 메트릭을 가지고 오기 때문에, 풀링하는 순간의 스냅샷이라는 것이다. 15초 단위로 폴링을 했다고 가정했을때, 15초 내에 CPU가 올라갔다 내려와서, 풀링 하는 순간에는 CPU가 내려간 값만 관측이 될 수 있다. 스냅삿에 대한 연속된 모음일 뿐이고, 근사값의 형태라는 것을 기억할 필요가 있다. 

싱글 호스트

프로메테우스는 싱글 호스트 아키텍처이다. 확장이 불가능하고, 저장 용량이 부족하면 앞에서 언급한데로 디스크 용량을 늘리는 것 밖에 방안이 없다. 특히나 문제점은 프로메테우스 서버가 다운이 되거나 또는 설정 변경등을 위해서 리스타트등을 하더라도 그간에 메트릭은 저장이 되지 않고 유실이 된다는 점이다.




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


쿠버네티스 #14

모니터링 2/3 Prometheus를 이용한 모니터링


조대협 (http://bcho.tistory.com)

프로메테우스

그동안 주요 모니터링 솔루션으로 사용되던 힙스터는 1.13 버전 이후로 deprecated 될 예정이고, 그 이후를 맏을 모니터링 솔루션으로 가장 많이 언급되는 모니터링 솔루션은 프로메테우스 (Prometheus)이다.


프로메테우스는 SoundCloud (http://soundcloud.com/)에서 개발된 모니터링 툴로, 2016년에 CNCF  (Cloud Native Computing Foundation)에 오픈소스 프로젝트로 기부되었다. 지표 수집을 통한 모니터링을 주요 기능으로 하고 있다.


쿠버네티스 모니터링뿐만 아니라 애플리케이션이나 서버, OS 등 다양한 대상으로 부터 지표를 수집하여 모니터링할 수 있는 범용 솔루션으로, 아래와 같은 구조를 가지고 있다.



<그림. 프로메테우스 모니터링 아키텍처>

데이타 수집 부분

기본적으로, 프로메테우스는 데이타 수집을 PULLING 모델을 사용한다. 모니터링 대상이 되는 자원이 지표 정보를 프로메테우스로 보내는 것이 아니라, 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽어 오는 모델을 사용한다.


모니터링 대상이 프로메테우스의 데이타 포맷을 지원할 경우 바로 읽어올 수 있고, 만약에 지원하지 않는다면 별도의 에이전트를 설치해서 지표를 읽어올 수 있는데, 이를 exporter라고 한다. exporter는 mysql,nginx,redis와 같은 패키지는 미리 개발된 export가 있어서 다양한 서비스의 지표까지 쉽게 읽어올 수 있다.

이런 패키지 애플리케이션이 아니라, java 나 node.js와 같은 사용자 애플리케이션의 경우에는 Exporter를 사용하는 방법 말고도, 프로메테우스 클라이언트 라이브러리를 사용하게 되면, 바로 지표를 프로메테우스 서버로 보낼 수 있다.

마지막으로, Push gateway를 사용하는 방법이 있는데, 배치나 스케쥴 작업 같은 서비스의 경우에는 항상 서비스가 떠 있는 것이 아니라, 필요한 경우에만 떠 있다가 작업이 끝나면 사라지는 경우가 있다. 그래서, 이런 서비스를 Pulling으로 지표를 얻어오기가 어려울 수 있는데, 이를 보완하기 위해서, 이런 서비스들이 Push 방식으로 Push gateway에 지표를 쏴주면, Push gateway가 지표를 보관하고 있다가 프로메테우스 서버가 Pulling 을 하면, 저장된 지표 정보를 리턴하도록 한다.

서비스 디스커버리

그러면 프로메테우스는 모니터링 대상을 어떻게 알 수 있을까? 당연히 모니터링 대상 목록을 유지하고 있고, 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면, 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다.

그러나 오토스케일링을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너 환경에서는 모니터링 대상의 IP가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정파일에 넣는데 한계가 있다. 이러한 문제를 해결 하기 위해서 프로메테우스는 서비스 디스커버리 를 사용하는데, 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태이다.


프로메테우스는 DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해서 자동으로 모니터링 대상의 목록을 가지고 올 수 있다.

저장 및 시각화

이렇게 수집된 지표 정보들은 프로메테우스 내부의 시계열 데이타베이스에 저장이 되고, 프로메테우스 웹 콘솔을 이용하여 시각화 되거나 또는 API를 외부에 제공해서 Grafana와 같은 시각화 툴을 통해서 지표를 시작화 해서 볼 수 있다.

알림 서비스

부가 기능중의 하나로, alerting 컴포넌트는, 지표에 대한 규칙을 걸어놓고 그 규칙을 위반할 경우에는 알림을 보낼 수 있는 기능을 가지고 있다. 알림을 보내는 대상은 이메일이나 pagerduty와 같은 notification 서비스 등과 연동이 가능하다.

쿠버네티스 연동 아키텍처

그러면, 쿠버네티스와 프로메테우스는 어떻게 연동이 될까? 여기서 오해하지 말아야 하는 점은 Heapster,cAdvisor 스택과 같이 딱 정해진 아키텍쳐는 없다는 것이다. 프로메테우스는 범용 모니터링 솔루션으로 프로메테우스 서버가 지표정보를 읽어올 수 만 있다면 거의 모든 정보를 읽어올 수 있는 구조이기 때문에, 쿠버네티스 연동에 있어서도 자유도가 매우 높다


단 레퍼런스 할 수 있는 구성은 있는데, 다음과 같은 구조를 갖는다.


먼저 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 (Service discovery) 메카니즘이 필요한데, 이를 위해서 쿠버네티스 API를 호출해서, 자원들의 목록 (Pod,Node, Service,Ingress,Endpoint 등)의 목록을 라벨 셀렉터(label selector)를 이용하여 수집한다.

다음 수집된 모니터링 대상에 대해서 모니터링을 수행하는데, 쿠버네티스는 apiServer에서 /metric 이라는 URL을 통해서 기본적인 지표 정보를 리턴하기 때문에, 쿠버네티스 자원들에 대한 모니터링은 이 API를 통해서 수집하게 된다.


아랫단에 하드웨어 즉 node에 대한 정보는 API를 통해서 수집하기가 어렵기 때문에, node에 node exporter를 설치해서 하드웨어와 OS에 대한 정보를 수집한다. 컨테이너에 대한 정보는 node별로 배포되어 있는 cAdvisor가 이를 수집하여 프로메테우스에 제공한다.


컨테이너내에서 기동되는 애플리케이션에 대한 정보는 필요한 경우, 클라이언트 SDK나, 솔루션에 맞는 exporter를 이용해서 수집한다.

쿠버네티스 연동하기

그러면 실제로 프로메테우스를 설치해서 쿠버네티스 클러스터를 모니터링 해보자. 앞의 아키텍쳐에서 봤지만, alert server, exporter, prometheus server 등 설치해야 하는 서버들이 많아서, 일일이 설치하는 것이 쉽지 않다. 여러가지 설치 방법이 있지만 여기서는 쿠버네티스의 패키지 매니저인 Helm 을 이용해서 프로메테우스를 설치하도록 한다. Helm 은  Linux의 RPM이나, Node.js의 npm같이 소프트웨어 스택을 명령으로 손쉽게 설치할 수 있도록 해주는 패키지 매니져의 개념으로 쿠버네티스 버전의 npm 툴이라고 이해하면 된다.


참고로 여기서 설치는 로컬 PC의 minikube 환경을 이용해서 설치하였다. 클라우드 환경에서 제공되는 쿠버네티스 클러스터의 경우에는 다소 차이가 있을 수 있으니, 각 벤더에서 제공되는 가이드를 참고하기 바란다. 아울러 아래 설치 내용은 운영 환경에서 적용하기는 어렵고, 운영환경 적용을 위해서는 적절한 디스크 타입과 Pod의 사이즈등을 다시 클러스터 환경에 맞도록 설정해야하고 어디까지나, 테스트 용임을 인지하기 바란다.

Helm 인스톨

Helm은 클라이언트와 서버 두개의 모듈로 나뉘어 진다.

인스톨은 어렵지 않은데, 클라이언트 OS에 따라 약간씩 차이가 있다. 자세한 인스톨 방법은 https://docs.helm.sh/using_helm/ 문서를 참고하면 된다.

클라이언트 인스톨

맥에서 클라이언트 인스톨은 brew를 이용하면 쉽게할 수 있다.

%brew install kubernetes-helm

명령을 이용하면 Helm 클라이언트가 로컬 PC에 설치된다.

서버 인스톨

Helm 서버를 Tiller라고 하는데, Tiler 서버의 인스톨은 어렵지 않으나, 클라우드 벤더나 설치 환경에 따라서 약간씩의 차이가 있다.


Minikube  환경에서 인스톨

Minikube 환경에서 인스톨은 Helm 클라이언트를 인스톨 한 후에, 아래와 같이

%helm init

명령어를 실행하면 쿠버네티스 클러스터에 Tiller 서버가 자동으로 설치된다.


구글 클라우드 쿠버네티스 엔진 (GKE) 환경에서 인스톨

GKE 환경은 약간 설치 방법이 다른데, 보안적인 이슈로 인해서 계정에 대한 권한 컨트롤을 상대적으로 까다롭게 하기 때문이다.

(참고 : https://cloud.google.com/solutions/continuous-integration-helm-concourse )


아래 명령을 이용하면 kube-system 네임 스페이스에 tiller라는 이름으로 서비스 어카운트를 생성할 수 있다.

% kubectl create clusterrolebinding user-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)

% kubectl create serviceaccount tiller --namespace kube-system

% kubectl create clusterrolebinding tiller-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:tiller


다음 Tiller를 생성할때, --service-account=tiller 옵션을 줘서 tiller 가 실행될때, 해당 서비스 어카운트의 권한을 가지고 실행되도록 한다.


헬름 서버 (Tieller) 인스톨

./helm init --service-account=tiller
./helm update


이렇게 설치 하지 않으면 Tiller 자체는 설치가 될 수 있지만, Tiller에 의해서 인스톨 되는 패키지들이 권한 오류로 인해서 제대로 설치되지 않을 수 있다

Helm Chart를 이용한 Prometheus 설치

Helm이 준비되었으면 프로메테우스 를 설치해보자


% git clone https://github.com/kubernetes/charts

명령을 이용하여 Helm chart를 다운 받는다. Helm chart는 npm 파일과 같이 인스톨 스크립트를 모아놓은 것으로 생각하면 된다. 프로메테우스외에도 다양한 설치 스크립트가 있다.


$ cd charts/stable/prometheus

를 이용해서 프로메테우스 디렉토리로 들어간 후에, 아래 명령을 이용하면 prometheus 네임스페이스에 프로메테우스가 설치된다.


$ helm install -f values.yaml stable/prometheus --name prometheus --namespace prometheus


설치가 끝났으면 이제 프로메테우스가 제대로 작동해서 지표를 수집하고 있는지 확인하자. 프로메테우스 서버는 디폴트로 9090 포트를 통해서 웹 인터페이스를 제공한다. 프로메테우스 서버를 외부 서비스로 expose 하지 않았기 때문에 포트 포워딩을 이용해서 프로메테우스 서버의 9090 포트를 포워딩 해보자


%kubectl get pod -n prometheus

명령을 이용해서 prometheus 네임스페이스에 있는 pod 목록을 다음과 같이 가지고 온다.



prometheus의 pod 명이 “prometheus-server-5695758946-gdxjx” 인것을 알았으면,localhost:9090을 이 pod의 9090포트로 포워딩하도록 설정한다.

%kubectl port-forward -n prometheus prometheus-server-5695758946-gdxjx 9090


포트 포워딩이 설정되었으면 localhost:9090으로 접속하여 프로메테우스의 웹 콘솔을 접속해보자

처음에는 아무것도 나오지 않을텐데, metric을 PQL (프로메테우스 쿼리)를 이용해서 선택하면 아래와 같이 해당 지표에 대한 값이 나오는것을 볼 수 있다. 아래는 node의 disk_io 정보를 살펴보는 쿼리이다.



이 메뉴에서 지표를 모니터링 하거나 또는 모니터링된 지표를 Graph 탭을 눌러서 그래프로 시각화 할 수 있다. 메뉴를 조금더 둘러보면 상단의 Status 메뉴에서 Service Discovery 메뉴를 눌러보면 다음과 같은 결과를 얻을 수 있다.


모니터링해야 하는 자원들의 목록으로 node, node-cadvisor, pods, services 등에 대한 정보를 모니터링할 수 있는 것을 확인할 수 있다.


Target 메뉴를 클릭하면 다음과 같은 정보가 나오는데,


어디로 부터 지표들을 수집해오는지 URL등을 확인할 수 있다. apiserver의 URL, node metric 정보 수집 URL node cAdvisor 수집 URL등을 확인할 수 있다.

Helm Chart를 이용한 Grafana 설치

프로메테우스를 설치했으면 이를 시각화 하기 위해서 Grafana를 설치해서 연동해보도록 하자.

Helm chart 디렉토리에서 stable/grafana 디렉토리에 values.yaml 파일이 있는데, 이 부분에서 adminPassword 부분을 찾아서 admin 사용자의 비밀 번호를 세팅하도록 하자.


adminUser: admin

adminPassword: mypassword


다음 Helm chart를 이용해서 Grafana를 설치한다.

stable/grafana 디렉토리에서 앞에서 수정한 values.yaml 파일을 이용한다.

%helm install -f values.yaml stable/grafana --name grafana --namespace grafana


설치가 종료되었으면 Grafana 콘솔에 접속해보자.

%kubectl get pod -n grafana 명령을 이용해서 grafana 서버의 pod 명을 알아낸다.


Grafana 서버는 외부 서비스로 Expose 되지 않았기 때문에, 포트 포워딩을 이용해서 해당 서버에 접속하도록 한다. Grafana는 3000번 포트로 웹 접속을 허용한다.


% kubectl port-forward -n grafana grafana-679cdd7676-zhwnf 3000

명령을 이용하면 localhost:3000을 Grafana 웹 서버로 포워딩 해준다.

localhost:3000에 접속해보면 다음과 같은 로그인 창이 나온다.


로그인창에서, 사용자명을 admin으로 입력하고, 비밀번호는 앞의 설정에서 입력한 비밀번호를 설정한다.

다음으로 프로메테우스 서버를 데이타 소스로 설정해야 하는데, grafana 메뉴에서 Configuration > Data source 메뉴를 선택한다.



Data source를 추가하기 위해서는 프로메테우스 서버의 URL 을 알아야 하는데, 프로메테우스 서버는 내부 IP를 가지고 있는 서비스로 Expose 되어 있다. 서비스명을 알기 위해서 다음 명령어를 실행한다.

%kubectl get svc -n prometheus

다음과 같이 서비스명이 prometheus-server이고 cluster-IP가 10.102.173.250 인것을 확인할 수 있다.




HTTP URL은 http://prometheus-server.prometheus.svc.cluster.local 게 된다.

그러면 이 정보를 Grafana datasource 쪽에 추가한다.



데이타소스 명은 Kuberentes로 지정하고, 타입은 Prometheus로 지정한다. 그리고 HTTP URL은 위의 http://prometheus-server.prometheus.svc.cluster.local 를 사용하고 Access 타입은 Server를 선택한다.


이 과정이 끝나면, 프로메테우스를 Grafana의 데이타 소스로 사용할 수 있다.

이 데이타 소스를 이용해서 대쉬 보드를 구성해야 하는데, 수동으로 일일이 구성할 수 도 있지만 Grafana 커뮤니티에는 이미 미리 구성되어 있는 대쉬보드 템플릿이 많다. 이 템플릿을 그대로 import 해서 사용해보도록 하겠다.

Grafana 메뉴에서 아래와 같이 Create > Import 메뉴를 선택한다.


다음 대쉬보드 설정 JSON을 넣을 수 있는데, 또는 Grafana.com에 등록된 대쉬보드 템플릿 번호를 넣을 수 도 있다. 여기서는 쿠버네티스 클러스터 모니터링 템플릿을 사용하도록 하겠다. 이 템플릿의 ID는 1621번이기 때문에 아래와 같이 템플릿 ID를 입력한다.

이 템플릿 이외에도, 노드 모니터링을 위한 템플릿등 여러 종류의 대쉬 보드 템플릿이 있기 때문에 용도에 맞게 선택해서 사용하면 된다.


템플릿 ID를 선택하면 다음 화면에서 데이타 소스를 선택해줘야 하는데, 아래 그림과 같이 Prometheus 부분을 앞에서 만든 데이타 소스 이름인 Kubernetes를 선택한다.


설정이 끝난후에 대쉬보드를 확인하면 아래와 같이 쿠버네티스에 대한 전반적인 모니터링 정보가 나오는 것을 확인할 수 있다.




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요