프로메테우스란? - 모니터링? 메트릭(Metric)? 그라파나?

회사에서 우리 서비스에 대한 모니터링 요구사항이 생겼다. 그래서 프로메테우스라는 것에 대해 알게 되었고 찾아보게 되었다. 내가 해야할 것은 프로메테우스 쪽이 아닌 프로메테우스에 Metric을 Export해주는 Metric Exporter를 개발하는 것이다. 일단 요구사항에 맞춰서 Metric Exporter를 개발을 했는데 코드도 그렇고 좀 맘에 안들어서 다시 제대로 공부하고 하려고 한다.  먼저 프로메테우스가 무엇인지에 대해서 제대로 공부를 좀 해놓고 나서 진행해보려고한다.

 

https://prometheus.io/docs/introduction/overview/

Overview | Prometheus

여기에 있는 내용들 중 필요한 내용을 번역하려고 한다.

 

프로메테우스란?

프로메테우스는 SoundCloud에서 만든 모니터링과 알림을 위한 오픈소스 시스템이다.

프로메테우스는 시계열의 메트릭 데이터를 수집하고 저장한다, 즉 메트릭 정보는 메트릭이 측정되는 시점의 timestamp와 같이 저장이 된다. 그리고 저장되는 시점에 labels라고 불리는 optional한 key-value 쌍도 같이 저장이 된다.

 

특징

• multi-dimensional 데이터 모델 : 메트릭이 저장될 때 함께 저장되는 key-value들을 위에서 말했듯 메트릭의 labels라고 할 수도 있고 어디선가의 용어로는 dimensions이라고도 하는데 key-value쌍이 여러개가 될 수 있고 그것들 때문에 메트릭을 다양한 디멘션으로 검색할 수 있기 때문에 multi-dimensional한 데이터모델을 자기들 특징으로 말한 것 같다.
• 시계열의 데이터 모델 : 모든 메트릭들은 저장이 될때 측정된 timestamp값이 같이 저장되므로 시간의 흐름에 따른 무언가를 할 수 있는 강점이 있다. 구체적인 예시들은 아직 실제로 시각화해보지 않아서 감이 오지 않는다.
• metric name과 key-value쌍으로 메트릭은 식별된다 : 메트릭을 검색할때 metric name 뿐만 아니라 key-value쌍까지 해당 메트릭의 키값이 된다는 얘기이다.
• 메트릭의 Multi-dimensional함을 이용할 PromQL이라는 유연한 쿼리 언어를 사용한다 : 이 PromQL의 특징 및 강점은 나중에 시간날 때 따로 알아보겠다. 지금은 일단 프로메테우스는 PromQL을 사용하는 구나 그런게 있구나만 알아두자
• 분산 스토리지에 의존하지 않는다. Single Server Node는 자주적이다 : 프로메테우스 서버는 각자 로컬 스토리지를 두고 그것을 사용한다는 점이 특징이라고 한다. 이게 왜 특징이 되는지도 나중에 알아봐보자.
• 시계열 정보의 수집은 HTTP를 통한 PULL을 할 때 발생된다.
• pushing time series는 중간 gateway에 의해서 지원된다 : pushing metric의 timestamp는 pulling할때의 timestamp를 저장하는 것이 아니라 중간의 gateway(push gateway)에서 지원을 한다는 것 같다.
• 메트릭을 수집할 타겟은 Service Discovery라는 곳에서 정보를 얻을 수도 있고 설정 파일에서 얻을 수도 있다. : 나중에 쿠버네티스와 관련해서 같이 알아볼 것들이 많은듯.. Service Discovery관련해서
• 여러가지 그래프 모드나 대쉬보드 모드가 지원이 된다.

메트릭이란??

여태까지 메트릭 메트릭 했는데 메트릭이 뭔지 아직 감이 안올수도 있다. 하나의 용어로 그냥 메트릭을 이해해야한다.

 

일반인의 용어로 메트릭은 무언가의 측정된 수치이다. Time series(앞에서 시계열 시계열 했던 원래 영어단어, 이제는 그냥 원문 그대로 받아들이자) 의 의미는 변화는 시간이 지날때마다 계속 측정된다는 의미이다. 유저가 측정하고자 하는건 어플리케이션마다 다른데 웹서버 같은 경우에는 http request 횟수가 될 수 있고 데이터베이스 같은 경우에는 연결되어있는 connection 개수같은게 될 수도 있다.

메트릭은 우리의 어플리케이션이 어떤 현상을 보일 때 왜 그러는지를 이해하는데 매우 중요한 역할을 한다. 만약 당신이 어플리케이션을 실행시켰고 어플리케이션이 느리다는 것을 알아차렸다면 어플리케이션이 왜그런지 정보가 필요하다. 예를 들어 http request 횟수가 많으면 어플리케이션이 느려질 수도 있다. 만약 당신이 http request 횟수에 대한 Metric을 측정중이 였다면 어플리케이션이 느려지는 이유를 찾고 서버의 개수를 늘리는 식으로 대응할 수 있었을 것이다.

이것을 보면 메트릭이 어떻게 생겼는지 감이 확 올것이다.

구성요소

프로메테우스 생태계는 많은 구성요소들로 이뤄져 있는데 이들중 많은 것들은 optional하다

• 메트릭을 수집하고 저장할 메인 프로메테우스 서버
• 어플리케이션에서 Metric을 수집할 Client Library
• short-lived job을 위한 push gateway : 원래는 프로메테우스 서버가 특정 End point에 http 요청을 날려서 메트릭을 pull 해오는데 금방 떴다가 사라지는 job에서는 메트릭을 어디에다가 넣어야 하기 때문에 push gateway가 필요하다. 그렇지 않으면 프로메테우스 서버에서 접근할 http endpoint가 없기 때문이다.
• 특별한 목적의 exporter들 : exporter란 프로메테우스 서버에서 메트릭을 수집하기 위해서 붙어야하는 Endpoint를 가진 애들을 Exporter라고 한다.
• 알림을 담당할 Alert Manager

아키텍처

일단 내가 조만간 볼 부분은 Jobs/exporters 쪽이다. 내가 집중할 부분은 어떤 exporter 라이브러리로 어떻게 깔끔하게 metric을 export하는 코드를 짤지이다.

 

언제 적합할까?

시계열의 수치데이터를 측정할 때에 적합하다.

언제 적합하지 않을까?

100퍼센트의 적합성을 가져야하는 경우에는 적합하지 않다.

 

더 알아볼점

이렇게 프로메테우스에 대해서 간단하게 알아봤다.. 나중에 프로메테우스를 제대로 써볼 뭔가 나만의 간단한 서비스를 만들어봐야겠다. 현재 회사 서비스에서는 내가 프로메테우스의 모든걸 적용할 필요가 없으니까..

• PromQL
• 분산 스토리지에 의존하지 않는다.. 가 왜 특징인지 무슨 의미인지..
• Service Discovery 관련..

 

막 공부를 하는중이라 모르는점도 많고 잘못된 내용이 있을 수 있습니다.. 지적 및 내용 보충은 감사합니다..