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


Archive»


 
 



프로메테우스 #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 를 필드에 입력한다.



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





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

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

댓글을 달아 주세요

프로메테우스

#2 Hello Prometheus 조대협 (http://bcho.tistory.com)

프로메테우스에 대해서, 이해하기 위해서 간단한 테스트를 진행하는데, 테스트는 http://www.katacoda.com/ 를 이용하였다. 웹상에서 쿠버네티스, 프로메테우스,텐서플로우등 다양한 기술을 별도의 설정이나 서버없이 해볼 수 있기 때문에, 기술에 대한 개념을 잡는데 매우 유용하다. 

설정 파일 정의 

프로메테우스의 설정은 prometheus.yml 파일에 정의 한다. 아래는 간단한 예제이다. 


global:

  scrape_interval:     15s

  evaluation_interval: 15s


scrape_configs:

  - job_name: 'prometheus'


    static_configs:

      - targets: ['127.0.0.1:9090', '127.0.0.1:9100']

        labels:

          group: 'prometheus'


scrap_interval은 타겟 시스템으로 부터 메트릭을 읽어오는 주기이다. 읽어온 메트릭을 기반으로 룰에 따라서 alert을 보낼 수 있는데, alert을 보낼지 말지 메트릭을 보고 판단하는 주기가 evaluation_interval 이다. 


scrap_configs 부분이 데이타 수집 대상과 방법을 정의하는 부분인데, 먼저 job에 대한 개념을 이해해야 한다. job은 대상 그룹에서 메트릭을 수집해오는 내용을 정의하는데, job은 하나의 시스템이 아니라 특성이 같은 하나의 시스템 그룹정도의 개념으로 생각하면 된다. 예를 들어 오토 스케일링 그룹으로 묶여 있는 웹서버 1,2,3을 수집한다고 했을때, 이 3개의 메트릭을 수집하는 것이 하나의 job으로 정의되고, 각각의 서버를 instance라고 한다. 


위에서는 127.0.0.1:9090, 127.0.0.1:9100 에서 메트릭을 수집하도록 job을 하나 정의 했는데, prometheus 가 기동되고 있는 서버로 부터 메트릭을 읽어오도록 설정하였다. 앞에는 프로메테우스 시스템 자체의 메트릭이고, 두번째는 프로메테우스가 기동되고 있는 VM(또는 서버,또는 도커)의 시스템 메트릭을 수집하도록 정의하였다.

프로메테우스 서버와 node exporter 기동

설정의 끝났으면 프로메테우스 서버를 기동하다. 설치에는 여러가지 방법이 있지만, 간단하게 도커 이미지를 이용하여 기동하였다. 

docker run -d --net=host \

     -v /root/prometheus.yml:/etc/prometheus/prometheus.yml \

     --name prometheus-server \

     prom/prometheus


프로메테우스를 기동하였으면, 프로메테우스 모니터링 대상이 되는 프로메테우스의 노드(VM)의 지표를 수집하여 프로메테우스로 전송하는 node exporter를 설치해서 기동해야 한다. node exporter는 머신의 CPU,메모리,네트웍등과 같은 메트릭을 수집해서 프로메테우스가 가지고 갈 수 있도록 한다.

마찬가지로 도커 이미지로 기동하는데, quay.io/prometheus/node-exporter 의 이미지를 사용한다. 


docker run -d \

   -v "/proc:/host/proc" \

   -v "/sys:/host/sys" \

   -v "/:/rootfs" \

   --net="host" \

   --name=prometheus \

   quay.io/prometheus/node-exporter:v0.13.0 \

     -collector.procfs /host/proc \

     -collector.sysfs /host/sys \

     -collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"


node exporter 가 제대로 작동하는지 확인하려면, 

% curl https://{프로메테우스 서버 IP}:9100/metrics

명령을 실행해보면 다음과 같이 메트릭 정보들이 리턴되는 것을 확인할 수 있다. 

흥미로운것이 metric 수집을 HTTP GET 방식으로 하도록 되어 있다. 

이 관점에서 봤을때 구현이 매우 쉬울것 같은 장점도 있고, 별도의 포트를 오프하지 않아도 되는 장점은 있지만, 보안적으로 어떻게 접근 제어등을 할지는 나중에 별도로 한번 찾아봐야 하지 않을까 싶다. 


# HELP go_gc_duration_seconds A summary of the GC invocation durations.

# TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 3.9293000000000005e-05

go_gc_duration_seconds{quantile="0.25"} 3.9293000000000005e-05

go_gc_duration_seconds{quantile="0.5"} 5.0119000000000006e-05

go_gc_duration_seconds{quantile="0.75"} 5.0119000000000006e-05

go_gc_duration_seconds{quantile="1"} 5.0119000000000006e-05

go_gc_duration_seconds_sum 8.9412e-05

go_gc_duration_seconds_count 2

# HELP go_goroutines Number of goroutines that currently exist.

# TYPE go_goroutines gauge

go_goroutines 8

# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.

# TYPE go_memstats_alloc_bytes gauge

go_memstats_alloc_bytes 6.234016e+06

# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.

# TYPE go_memstats_alloc_bytes_total counter


대쉬보드 접속

프로메테우스와 exporter 가 기동이되었으면, 메트릭이 제대로 수집이 되는지 확인하자. 

http://{프로메테우스 서버 ip}:9090 에 접속하면, 대쉬보드가 나오는데, 검색 쿼리 부분에 보고 싶은 메트릭에 대한 쿼리를 넣으면, 테이블이나 그래프 형태로 볼 수 있다.

아래는 node_cpu 항목을 넣어서 프로메테우스가 기동 중인 서버의 CPU 사용률을 모니터링해서 그래프로 나타낸 화면이다. 



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

댓글을 달아 주세요

프로메테우스 #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가 내려간 값만 관측이 될 수 있다. 스냅삿에 대한 연속된 모음일 뿐이고, 근사값의 형태라는 것을 기억할 필요가 있다. 

싱글 호스트

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




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

댓글을 달아 주세요