[Prometheus] - CentOS에서 모니터링 & Pushgateway & AlertManager 구축 해보기!(이론)

 

Prometheus

• 모니터링을 위한 오픈소스 시스템으로 
  주로 "Metric" 정보를 수집하기 위한 용도로 사용된다.
• 다양한 시스템의 상태를 쉽게 확인 및 분석할 수 있다.
• 특정 rule을 위배하는 트리거가 발생하면 경고를 보내 미리 장애를 예방할 수 있다.

장애 예방에 대한 Observability에 대한 내용은 아래 포스팅에서 확인 할 수 있다.

2023.12.29 - [Data Engineering/Observability] - [Observability] - 1. Observability란 & 도구

[Observability] - 1. Observability란 & 도구

Prometheus 구조

Prometheus 서버

• Retrieval에서 다른 서버에서 메트릭 정보들을 pull 한다.
• TSDB는 Time Series Database로 timestamp를 기반으로 데이터를 저장한다.
  • 시간을 기준으로 partiion을 나누고 그 아래 데이터를 저장한다. 
    

    

  • 이렇게 하여 실시간으로 쌓이는 대규모의 시간기반 데이터들을 저장(Write)에 특화되어 있으며,
    다양한 시간 기반 쿼리가 가능하다.
  • 기존 RDB에 비해 처리속도가 빠르고 데이터 증가에 따라 급격한 성능저하가 없다.
    • RDB는 인덱스의 재정렬 등으로 인해 대규모 데이터 저장 시 성능저하가 발생한다.
      하지만, TSDB는 시간 기준으로 파티션을 나누기 때문에 인덱스 재정렬이 필요 없다.
      

      

  • 효율적으로 메모리 로드를 할 수 있다.
• HTTP server
  • prometheus 자체에서도 http를 통해 메트릭 등 prometheus가 제공하는 기능들을 확인 할 수 있다.

메트릭 수집 방식 - PUSH vs PULL

메트릭 수집 방식에서 push와 pull 이 있다.

우선 PUSH 방식에서는
대상 서버가 직접 모니터링 서버로 전송해야한다.

장점 - 여러 가변적이 서버에서도 메트릭 정보를 모니터링 서버로 전송할 수 있다.

단점 - App에 부하를 줄 수 있으며, App이 과부하 상태가 되거나 문제가 생기면 전송하지 못할 수도 있다.

 

그래서 PULL 방식을 많이 사용한다.
모니터링 서버가 직접 타겟 서버에 접근하여 가져가는 구조이다.

장점 - 모니터링 하는 주체가 원할 때 가져갈 수 있으며, 기존 타겟 서버에 부하를 주지 않는다.

단점 - 모니터링하려는 대상 서버가 가변적 IP이면 수집하기 어려우며, 단발적인 프로세스일 경우 효율적이지 못하다.

이러한 PULL 방식의 단점 해결을 위해 

Pushgateway 와 Service discovery 기능이 있다.

Pushgateway

Pushgateway란,
단발적이거나 가변적으로 만들어진 데이터들을 Pushgateway로 전송하여 수집하고 
이를 다시 Prometheus 서버가 주기적으로 가져가는 기능이다.

UseCase - 주로 Batch Job에서 사용한다.
주기적으로 필요한 데이터는 아니지만 해당 job이 정상적으로 마무리가 되었는지 아닌지는 수집할 만한 중요한 정보이기 때문이다.

Service discovery

Service discovery는
모니터링 시스템에서 동적으로 수집 대상을 관리하는 기능이다.

VM이나 컨테이너들을 내부 DNS에 등록 해놓고,
DNS에서 현재 가동 중인 VM/컨테이너 목록을 얻어와 해당 목록의 IP들로 연결한다.

Alert Manager

Alert Manager란,
Prometheus 모니터닝 시스템의 경고 관리 도구이다.

Alert Manager가 alert에 대한 queue를 제공하고,
Prometheus는 PromQL로 등록된 Rule을 기반으로

경고 메세지를 다양한 수신자(email, slack 등)로 보내준다.

실습은 이어서 다음 포스팅에서 진행할 예정이다.