서비스 모니터링 (2)

C173] 모니터링 시스템에는 메트릭 수집을 위한 두가지 방식의 메커니즘이 존재합니다. 바로 Pull 방식과 Push 방식입니다.
프로메테우스는 어떤 방식의 메커니즘을 사용하나요? 또한 Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해보세요. 

 
 

*프로메테우스의 수집 저장 아키텍처

 
프로메테우스는 오픈 소스 기반의 모니터링 시스템이다 대상 시스템으로 부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있고 그라파나를 통한 시각화를 지원한다.

메트릭 수집 부분

수집을 하려는 대상 시스템이 Target system이다.

MySQL이나, Tomcat 또는 VM 과 같이 여러가지 자원이 모니터링 대상이 될 수 있다.

이 대상 시스템에서 메트릭을 프로메테우스로 전송하기 위해서는 Exporter 라는 것을 사용한다.

 

프로메테우스가 Target System에서 메트릭을 수집하는 방식은 풀링 방식을 사용한다.

프로메테우스가 주기적으로 Exporter로 부터 메트릭 읽어와서 수집하는 방식이다.


 

 

어디까지나 근사치라는 점

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

Exporter

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

pull vs push method in metric collection

 CPU 사용량과 같은 수치가 존재할 때 Push base는 메트릭을 수집하는 서버로 전송하고, Pull 베이스는 메트릭이 발생하는 서버에서 끌어온다고 생각하면 됩니다. 여기서는 Pull base의 장점만 간략하게 알아보겠습니다.

푸쉬방식

보통 모니터링 시스템의 에이전트 들은 에이전트가 모니터링 시스템으로 메트릭을 보내는 푸쉬 방식을 사용한다.

특히 푸쉬 방식은 서비스가 오토 스켈링등으로 가변적일 경우에 유리하다. 풀링 방식의 경우 모니터링 대상이 가변적으로 변경될 경우, 모니터링 대상의 IP 주소들을 알 수 가 없기 때문에 어려운 점이 있다.

예를 들어 웹서버 VM 2개의 주소를 설정 파일에 넣고 모니터링을 하고 있었는데, 오토 스케일링으로 인해서 VM이 3개가 더 추가되면, 추가된 VM들은 설정 파일에 IP가 들어 있지 않기 때문에 모니터링 대상에서 제외 된다. 

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

데이터의 정확성 : Pull base의 경우 메트릭이 발생하는 port를 항상 listening인 상태로 유지해 직접 접근이 가능하기 때문에 데이터의 정확성이 높습니다.Push base의 경우 메트릭을 보낼 때만 임시적으로 수집 서버와 연결합니다.

데이터의 양 조절 : Pull base의 경우 수집하는 서버에서 targets을 지정해 메트릭을 수집하기 때문에 문제가 없지만 Push base의 경우 지정된 서버외에도 메트릭을 보낼 수 있습니다. whitelist와 같은 방법으로 제한을 할 수 있지만 기능을 지원하지 않은 시스템이 대부분입니다.

보안 측면 : Push 기반에서 메트릭을 전송할 때 client 서버에서 TLS를 통해 연결하고 메트릭을 전송하는 일은 복잡하고 쉽지 않습니다. 이에 반해 Pull의 경우 HTTP로 안전하게 메트릭을 수집할 수 있습니다.

  • 푸시 , 메트릭은 모니터링되는 각 시스템에서 중앙 수집기로 주기적으로 전송됩니다. 푸시 아키텍처의 예로는 sFlow, Ganglia, Graphite, collectd 및 StatsD가 있습니다.
  • Pull 은 중앙 수집기가 모니터링되는 각 시스템에서 주기적으로 메트릭을 요청합니다. 풀 아키텍처의 예로는 SNMP, JMX, WMI 및 libvirt가 있습니다.
출처: https://bcho.tistory.com/1372 [조대협의 블로그]
 

모니터링 시스템 구축 기록

Overview 회사에서 빅데이터 시스템 개발을 진행하는 프로젝트에 참여하게 되었습니다. 규모가 있는 프로젝트에 참여하다 보니 빅데이터 시스템의 파이프라인에 해당하는(데이터 수집,DB 엔진,스

velog.io

* [C174] 어떤 조직의 SLO가 다음과 같습니다. "GET 호출의 99%는 10ms 이내에 수행되어야 한다" 그렇다면, 이러한 SLO를 달성하려면 어떤 메트릭을 수집하고 어떻게 계산해야 할까요? (척도는 표준화된 범용 지표를 사용합니다) *

 

JUNE .

20'S LIFE IN SYDNEY and BUSAN

    이미지 맵

    DevOps Bootcamp/Assignments 다른 글

    이전 글

    다음 글