모니터링 시스템 구축 기록

Seokbin·2021년 9월 26일
4

Kubernetes

목록 보기
3/3

1. Overview
회사에서 빅데이터 시스템 개발을 진행하는 프로젝트에 참여하게 되었습니다. 규모가 있는 프로젝트에 참여하다 보니 빅데이터 시스템의 파이프라인에 해당하는(데이터 수집,DB 엔진,스토리지 등) 각각의 솔루션에 대한 통합 모니터링 시스템이 필요했습니다. 이를 위해 모니터링 도구를 조사했지만 이미 시작부터 프로메테우스-그라파나 조합으로 잠정적으로 결정 되어있는거 같았습니다. 현재 가장 핫한 도구이기도 하고 다양한 장점이 있지만 결국 가장 크게 작용한 요인은 오픈소스와 그라파나의 멋진 UI가 아닌가 싶습니다. 기존에 프로메테우스를 맛보기만 해봤지만 실제 구현을 해야하는 상황이 되어서 각종 삽질과 공부를 진행하며 겪은 경험을 기록합니다.

2. Why Prometheus?
기존에 쿠버네티스 기반의 플랫폼 개발을 진행 할 때 차후에 모니터링 시스템을 개발 할 것을 대비해 프로메테우스에 대해 어깨 너머 보고 이야기 들은게 다였습니다. 그 당시부터 지금 모니터링 시스템 개발을 진행하기 까지 왜이렇게 프로메테우스가 인기가 많은지 궁금증이 있었습니다. 오픈 소스로 사용할 수 있다는게 굉장히 큰 장점이지만 이것만으로는 평소에 들었던 프로메테우스에 대한 칭찬이 이해가 되진 않았습니다.

Pull based vs Push based
결국 프로메테우스의 가장 큰 특징을 알기 위해서는 Pull 기반의 모니터링 시스템을 알아야 될 거 같았습니다.여기서 Pull 과 Push는 메트릭을 수집하는 방법을 말합니다. 예를 들어 CPU 사용량과 같은 수치가 존재할 때 Push base는 메트릭을 수집하는 서버로 전송하고, Pull 베이스는 메트릭이 발생하는 서버에서 끌어온다고 생각하면 됩니다. 여기서는 Pull base의 장점만 간략하게 알아보겠습니다.

  • 데이터의 정확성 : Pull base의 경우 메트릭이 발생하는 port를 항상 listening인 상태로 유지해 직접 접근이 가능하기 때문에 데이터의 적확성이 높습니다.Push base의 경우 메트릭을 보낼 때만 임시적으로 수집 서버와 연결합니다.
  • 데이터의 양 조절 : Pull base의 경우 수집하는 서버에서 targets을 지정해 메트릭을 수집하기 때문에 문제가 없지만 Push base의 경우 지정된 서버외에도 메트릭을 보낼 수 있습니다. whitelist와 같은 방법으로 제한을 할 수 있지만 기능을 지원하지 않은 시스템이 대부분입니다.
  • 보안 측면 : Push 기반에서 메트릭을 전송할 때 client 서버에서 TLS를 통해 연결하고 메트릭을 전송하는 일은 복잡하고 쉽지 않습니다. 이에 반해 Pull의 경우 HTTP로 안전하게 메트릭을 수집할 수 있습니다.

Pull base가 Push base보다 뛰어난 것은 아닙니다. Pull 방식의 경우도 메트릭 복제나 Batch-job에서의 단점도 존재합니다. 두 시스템을 잘 비교해서 상황에 맞게 사용해야 합니다. 주로 Prometheus 와 비교되는 InfluxDB(Push based)의 경우 이벤트 로깅에 적합하고 SQL 문을 사용해 비교적 사용이 쉬울 수 있습니다.(PromQL 또한 SQL문과 유사하나 처음 접할 때 어려움을 겪었습니다) 하지만 Prometheus의 가장 큰 강점은 활발한 커뮤니티와 확장성입니다. CNCF를 졸업한 프로젝트이기 때문에 많은 CNCF 어플리케이션(특히 쿠버네티스)과 연결이 좋습니다. 또한 많은 플러그인을 지원해 다양한 기능을 사용 할 수 있습니다. 프로젝트에 쿠버네티스 기반의 어플리케이션이 존재하기 때문에 이에 대한 모니터링이 필요하 프로메테우스를 선택하게 된 거 같습니다. 두 방식 비교에 대한 블로그

3. Prometheus Component
프로메테우스는 다음과 같은 컴포넌트로 구성되어 있습니다. 모니터링 과정으로 각각을 역할을 알아보겠습니다.
1. 모니터링이 대상의 서버에 Exporter를 설치 후 메트릭을 발생 시킵니다.
2. Prometheus에서 메트릭을 수집할 타겟을 설정해 해당 서버의 Exporter로 연결해 메트릭을 수집해 저장합니다.
3. 수집한 메트릭을 PromQL로 데이터를 정재해 Grafana에서 시각화 합니다.
4. 기준을 설정 해 이상 감지가 되면 Alertmanager를 통해 사용자에게 알람을 전송합니다.
기본적인 동작과정은 이해하기 쉽고 설치 또한 쉽습니다. 이번 글에서는 간단하게 설치 후 다음에 좀 더 세부적인 설정을 시도해보겠습니다.

  • Node_exporter 설치
    노드익스포터는 공식 홈페이지에서 바이너리로 다운받아 압축을 풀어 실행합니다. 실행 후 9100(기본 포트) Metrics에서 메트릭을 확인 할 수 있습니다.service로 등록해 오류가 발생하거나 재시작 했을 때 자동으로 실행 하도록 설정합니다.
#/etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Restart=on-failure
ExecStart=/home/ubuntu/node_exporter/node_exporter

[Install]
WantedBy=default.target

이후 systemctl daemon-reloadsystemctl statud node_exporter 를 통해 정상적으로 실행되는지 확인 합니다.

  • Prometheus 설치
    프로메테우스 또한 위의 노드 익스포터와 같이 공식 홈페이지에서 바이너리를 다운받아 설치 합니다.
    설치 후 prometheus.yml 에서 노드익스포터 타겟을 설정합니다. 이후 ./prometheus --config.file= prometheus.yml 를 통해 프로메테우스를 실행 합니다.
  - job_name: "prometheus"

    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "node-exporter"
    static_configs:
     - targets: ["3.38.93.74:9100","localhost:9100"]

이후 프로메테우스(9090)으로 접속해 targets를 확인해 연결이 정상적으로 되었는지 확인합니다.

  • Grafana 설치
    그라파나 또한 공식 홈페이지에서 바이너리파일을 다운받아 설치 합니다. 가이드의 명령어를 수행시 그라파나가 공식적으로 실행됩니다. 이후 3000번 포트로 접속하게 되면 그라파나를 확인 할 수 있습니다. 그라파나의 설정은 /etc/grafana/grafana.ini 파일에서 변경 할 수 있습니다. 이후 Data Source 에서 프로메테우스 주소를 입력해 연결합니다. 정상적으로 연결 후 메트릭이 정상적으로 수집된 것을 확인 할 수 있습니다.
    위의 방법으로 Prometheus-node_exporter-grafana를 설치 해보았습니다. 일반적으로 편리한 도커를 많이 사용하지만 저희는 도커 환경이 구축이 안되어있어 다음과 같이 서비스로 등록해 사용합니다. 또한 쿠버네티스에서 사용할 경우 네트워크와 권한 설정이 필요하기 때문에 복잡한 과정을 겪었습니다. 다음 포스팅에서 쿠버네티스에서의 모니터링 시스템 설정 방법을 알아보겠습니다.

0개의 댓글