쿠버네티스 Prometheus, Thanos 연동하기

k8s 멀티 클러스터 Prometheus, Thanos 연동하기

팀에서 클라우드 프로젝트를 수행하면서 모니터링 부분을 맡게되어 Promtheus를 포함한 Grafana, Loki, Jaeger등등 여러가지 모니터링에 필요한 오픈소스 프로그램들을 활용하는 중입니다.

그중 Prometheus는 여러 종류의 메트릭 데이터(Resource, Redis, Kafka...)들을 수집하는 역할을 하고 주로 Grafana와 연동하여 메트릭 모니터링 대시보드를 구성하는데 쓰입니다.

 

[프로메테우스 간단 개념]

[Prometheus] 프로메테우스의 기본 개념, 시계열 메트릭 정보수집 #metric #time serise

 

Prometheus 로컬 스토리지

반응형

프로메테우스는 기본적으로 메트릭 데이터를 로컬 스토리지에 시계열 데이터 형태로 저장하는데 몇가지 특징이 있습니다.

• 로컬 스토리지에 데이터를 저장하기 때문에 응답 시간이 매우 빠르다.
• 단일 서버에 설치되므로 설치 및 설정이 간단하다.
• 데이터를 영구적으로 보존하여 장애 복구, 장기적인 추세 분석에 유용하다.

 

한계점

• 확장성 제한: 로컬 스토리지는 단일 서버에 종속되기 때문에 확장성에 제한이 있다. 대량의 데이터를 처리하거나 고가용성을 위해 분산 스토리지 시스템이 필요한 경우 로컬 스토리지 방식은 한계가 존재한다.
• 용량 제한: 서버의 디스크 공간에 의존하기 때문에 디스크 용량이 한정되어 있다. 디스크 용량이 부족해지면 데이터의 보존 및 수집에 문제가 발생할 수 있다.
• 장애 복구 문제: 노드에 의존하기 때문에 서버 장애가 발생하면 데이터 손실이 발생할 수 있다.

 

이러한 로컬 스토리지의 한계를 해결하기위해 프로메테우스는 원격 스토리지를 사용할수있는 인터페이스를 제공합니다.

 

Prometheus 원격 스토리지

프로메테우스의 원격 스토리지 구조는 아래 그림처럼 프로메테우스와 써드파티 스토리지 사이에서 메트릭 데이터를 읽고 쓰는 작업을과 메트릭 데이터 요청을 전달해주는 어댑터가 있는데 이 글에서 설명할 어댑터는 Thanos 라는 오픈소스입니다.

 

Thanos(타노스) 란?

Thanos는 클라우드 환경에서 프로메테우스의 확장성과 내구성을 향상시키기 위한 오픈 소스 프로젝트입니다. 프로메테우스의 메트릭 데이터를 분산된 원격 스토리지에 저장하고 조회할 수 있게 해주는 기능을 제공합니다.

• Long-term Storage: 원격 스토리지에 데이터를 안정적으로 저장하여 장기적인 데이터 보존을 가능하게 합니다.
• Global Query: 여러 원격 스토리지에서 데이터를 통합하여 조회할 수 있는 Global Query 기능을 제공하여 분산된 데이터에 대해 단일 쿼리를 실행할 수 있어서 데이터 분석과 모니터링에 유용합니다
• HA(고가용성): 원격 스토리지에 데이터를 복제하여 프로메테우스 서버 중 하나가 장애가 발생하더라도 데이터의 고가용성을 보장할 수 있습니다.

 

Prometheus & Thanos 연동 구조

프로메테우스와 타노스를 연동하는 방법은 크게 2가지가 있습니다.

• 타노스를 Sidecar 형식으로 Prometheus 서버와 같은 파드에 실행하여 데이터를 오브젝트 스토리지에 데이터 저장
• 타노스를 별도의 서버로 실행하여 Prometheus에서 remote_write 방식으로 데이터를 전송하고 타노스에서 오브젝트 스토리지에 데이터를 저장.

 

이 글에서 설명할 방법은 두번째 방법인 별도의 타노스 서버를 구성하여 remote_write 방식으로 데이터를 전송하는 방법입니다.

 

Thanos 주요 구성요소

• Receive: 프로메테우스 서버에서 remote_write를 통해 메트릭 데이터를 받으며 기본 2시간 단위로 TSDB 블록을 만들어 오브젝트 스토리지에 저장합니다.
• Query: 여러 원격 스토리지에 전역 쿼리를 실행하여 분산된 데이터에 대한 효율적인 조회를 가능하게 합니다.
• QueryFrontend: Query 앞단에 배치되어 PromQL 요청을 받으면 Query에 전달하고 응답을 사용자에게 전달합니다.
• Compact: 오브젝트 스토리지에 저장된 블록 데이터를 압축하여 저장공간을 절약하는 최적화 작업을 합니다. 동시성이 보장되지 않으므로 전체 클러스터에서 싱글톤 형식으로 배포해야 합니다.
• Store Gateway: Store와 같은 개념, API Gateway 역할을 하며 오브젝트 스토리지에 접근하는 모든 작업은 Store API를 사용합니다. Query, Receive, Ruler 등에 존재합니다.

 

반응형

멀티클러스터 연동 Thanos 설치

반응형

멀티클러스터 Prometheus, Thanos 구상도

• 각각의 클러스터에 Prometheus, Thanos가 설치됩니다.
• Grafana에서 요청하는 PromQL을 Query, Store Gateway를 통해 Cluster #A, #B 모든 메트릭에 대해 조회합니다.
• Thanos compact는 현재 단계에선 중요도가 높지 않으므로 사용하지 않았습니다.

 

[준비 사항]

• Prometheus 설치: kube-prometheus-stack 참조

 

Thanos는 공식 helm chart를 제공하지 않기 때문에 가장 많이 사용되는 bitnami의 Thanos로 설치합니다.

• https://artifacthub.io/packages/helm/bitnami/thanos

 

helm add, update

• bitnami 저장소를 추가하고 helm 업데이트를 진행합니다.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

 

helm pull

• bitnami helm chart에서 thanos를 다운로드 합니다.
• 2023/05 기준 chart 버전이 12.6.2 이므로 thanos-12.6.2.tgz 파일이 생성되면 압축을 해제 합니다.

helm pull bitnami/thanos
tar xvfz thanos-12.6.2.tgz

 

values.yaml 수정

• 편의상 클러스터는 #A(sub), #B(main) 이라고 명칭하겠습니다.
• query, storegateway, receive 사용을 위해 enabled: true로 변경합니다.

query:
  ## @param query.enabled Set to true to enable Thanos Query component
  ##
  enabled: true
...
...
storegateway:
  ## @param storegateway.enabled Enable/disable Thanos Store Gateway component
  ##
  enabled: true
...
...
receive:
  ## @param receive.enabled Enable/disable Thanos Receive component
  ##
  enabled: true

 

• #B 에서 #A의 Thanos Receive에 접근하기 위해 #A의 Thanos Receiver 서비스 타입을 로드밸런스로 변경합니다.

  service:
    ## @param receive.service.type Kubernetes service type
    ##
    type: LoadBalancer

 

• #B의 Thanos Query 부분에 Store API를 사용하기위해 #A의 로드밸런서 주소를 입력합니다.
• #A의 Receive의 포트는 grpc, http 두가지가 있는데 grpc포트인 10901로 사용합니다.

  ## @param query.stores Statically configure store APIs to connect with Thanos Query
  ##
  stores:
  - monitoring-thanos-receiv-******:10901

 

반응형

Thanos 연동 확인

#B(main) 에서 실행중인 thanos-query 서비스를 NodePort나 포트포워딩 방식으로 변경하여 웹 브라우저에서 접속할수 있는데 Prometheus UI와 비슷한 모습입니다.

 

현재 제가 테스트중인 환경에서 #A, #B 클러스터의 노드는 각각 2개씩 존재하여 총 4개가 있으므로 노드를 조회하는 PromQL을 실행했을때 4개가 모두 보인다면 멀티 클러스터 연동은 잘 되었다고 볼수 있습니다.

# 노드별 cpu 사용량 조회 PromQL
100 * (1 - avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])))

 

오브젝트 스토리지 업로드 확인

현재 테스트중인 환경은 NCP 공공 클라우드의 오브젝트 스토리지 서비스를 이용중인데 #A, #B의 Thanos-receive에서 오브젝트 스토리지로 TSDB 블록 데이터를 정상적으로 업로드 하고있는지 확인해보겠습니다.

 

#A thanos receive 로그 확인

level=info ts=2023-05-25T01:00:23.313142215Z caller=shipper.go:334 component=receive component=multi-tsdb tenant=default-tenant msg="upload new block" id=01H186Q119K1NCG6H3X2FHNNAG

 

#B thanos receive 로그 확인

level=info ts=2023-05-25T01:00:22.889100398Z caller=shipper.go:334 component=receive component=multi-tsdb tenant=default-tenant msg="upload new block" id=01H186PY21HXTF8TF3CE04S5P9

 

#A, #B 각각 01H186Q119K1NCG6H3X2FHNNAG, 01H186PY21HXTF8TF3CE04S5P9 라는 이름으로 가장 최근에 업로드를 했다는 로그를 확인할수 있고 실제 NCP 오브젝트 스토리지에 해당 파일이 있는지 확인합니다.