DataBase/Monitoring

프로메테우스 Aurora MySQL 성능 지표 모니터링 구성

개요

기존 RDS 모니터링 시스템의 경우 Cloud Watch의 지표를 수집하여 한정된 정보만 수집이 가능하기에 성능 지표를 수집할 수 있는 시스템이 필요했습니다. 프로메테우스의 Mysqld-exporter를 사용할 경우 MySQL 서버의 다양한 지표 수집이 가능합니다. 진행하기에 앞서 간략하게 프로메테우스에 대해 알아보겠습니다.

프로메테우스란

대상 시스템으로부터 각종 모니터링 지표를 수집하여 저장 및 검색할 수 있는 오픈 소스 시스템입니다. MSA 환경에서 다수의 시스템을 모니터링 하기 편리하며 특히 쿠버네티스의 메인 모니터링 시스템으로 사용되고 있습니다. 아래는 프로메테우스의 대표적인 특징입니다.

메트릭 키/값으로 식별되는 다차원 데이터 모델
PromQL을 사용한 유연한 쿼리
그라파나를 통한 시각화가 용이
HTTP GET 형태로 메트릭 정보를 Pulling 하는 방식

아키텍처

메트릭 수집 방법

프로메테우스 서버가 타겟 시스템의 메트릭을 수집하기 위해서는 해당 타겟에 Exporter가 구성되야합니다. Exporter는 해당 시스템의 메트릭 정보를 수집한 후 /metrics형태의 HTTP 엔드포인트를 제공합니다.

아래는 Exporter 구성 후 메트릭 수집 절차입니다.

Service Discorvery로부터 현재 기동중인 서비스들의 목록과 IP 주소를 확인
Retrieval HTTP GET 요청으로 메트릭 데이터를 수집(Pulling방식)

Service Discovery
현재 기동중인 모니터링 대상 서비스의 목록 및 IP 주소를 가지고 보관합니다.

Exporter
모니터링 에이전트로 타겟 시스템에서 메트릭을 읽어 HTTP GET 형태로 프로메테우스가 수집할 수 있도록 합니다. 이때 요청 시점의 데이터만 전달할 뿐 로깅하지는 않습니다.

Retrieval
서비스 디스커버리로부터 모니터링 대상 목록을 받아오고 대상 시스템의 Exporter로부터 주기적으로 메트릭을 수집하는 컴포넌트입니다.

데이터 저장 및 관리

데이터 저장에 대해서는 간략하게만 설명하고 추후 포스팅하도록 하겠습니다.

프로메테우스는 수집된 정보를 로컬 TSDB에 저장합니다.

아래는 수집된 샘플 데이터의 처리 순서입니다.

수집된 샘플 데이터(분홍색) 가 인메모리 부분인 Head에 저장됩니다.
샘플을 청크로 커밋하는 동안 내구성을 위해 디스크의 WAL에 checkpoint 를 기록합니다. (충돌이 발생하더라도 메모리 내 데이터 복구가 가능합니다)
Head에 저장된 데이터는 디스크의 M-map chunks로 옮겨집니다.
이후 chunks가 가득 차거나 별도의 설정이 없다면 2시간 단위로 블록으로 압축합니다.

./_data
├── 01BKGTZQ1SYQJTR4PB43C8PD98    
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── chunks_head
│   └── 000001
└── wal
    ├── 000000002
    └── checkpoint.00000001
        └── 00000000

데이터 보관은 플래그에 따라 다를 수 있으며 기본 보관 주기는 15일이며 수집하는 타겟 수, 주기에 따라 용량은 달라질 수 있습니다.

-- 대략적인서버 용량 공식(단순히 참고만)
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

(예로 수집 대상 200개 이상, 보관 주기 3개월, 10초 단위 수집했을 때 300GB 정도였다고 함) 참고 : 정보의바다님 블로그

프로메테우스 스토리지 운영의 단점은 클러스터나 복제 구성은 지원하지 않습니다. 단일 노드로 구성되어있기에 스케일링을 위해서는 단순히 디스크의 크기를 늘리거나 프로메테우스에서 제공하는 인터페이스를 사용하여 원격 스토리지를 구성할 수 있습니다.

주의할 점

풀링하는 순간의 스냅샷이 관측되기에 주기 사이에 발생하는 현상에 대해서는 관측이 불가능합니다. 근사치를 표시하기에 100퍼센트 정확도는 보장하지 않습니다.

If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough

단일 노드로 구성되어 있기에 확장 및 HA 구성이 불가합니다. 이 때문에 서버가 다운되거나 설정 변경을 위해 서버가 내려갔을 경우 그 시간 동안의 메트릭은 저장되지 않고 유실됩니다.

시작하기

테스트는 도커 환경 단일 EC2 서버에서 구성을 진행하였습니다. 어떻게 단일 EC2에서 데이터를 수집할 수 있는지는 아래에서 설명하도록 하겠습니다.

prometheus.yml

프로메테우스의 설정은 prometheus.yml 파일에 정의합니다.

파일의 위치는 root 디렉터리의 prometheus_test 폴더를 생성한 후 하위로 넣어줍니다. (/prometheus_test/prometheus.yml)

global:
  scrape_interval:     15s    -- 15초 주기로 메트릭 수집

scrape_configs:
  - job_name: 'prometheus'    -- Prometheus 자신을 수집할 Job
    static_configs:
      - targets: ['127.0.0.1:9090']    --프로메테우스 자신 
        labels:
          name: 'prometheus'

  - job_name : 'rds'    -- RDS를 수집할 Job
    static_configs:
      - targets: ['엔드포인트주소:9094']  
        labels:
          name: 'test-1'    --표시될 라벨명 
      - targets: ['엔드포인트주소:9105']
        labels:
          name: 'test-2'

Docker로 배포하기

컨테이너 중지 시에도 프로메테우스 데이터를 유지하기 위해 볼륨을 생성해줍니다.

docker volume create prometheus_volume

이후 프로메테우스를 도커로 배포합니다.

docker run --rm -d -p 9090:9090 \
           --name prometheus \
           -v /prometheus_test/prometheus.yml:/etc/prometheus/prometheus.yml \
           -v prometheus_volume:/prometheus \
            prom/prometheus

--rm : 컨테이너를 일회성으로 실행할 때 사용. 컨테이너가 종료될 때 관련된 리소스 파일 제거
/prometheus_test/prometheus.yml:/etc/prometheus/prometheus.yml : 설정한 promethues.yml 파일을 컨테이너 내의 prometheus.yml 파일과 동기화 시킴
-v prometheus_volume:/prometheus : 컨테이너가 삭제되어도 데이터를 유지할 수 있도록 볼륨 구성

Mysqld-exporter 구성

Mysql 메트릭을 수집하기 위해서는 프로메테우스에서 제공하는 mysqld-exporter를 구성해야 합니다. node-exporter와는 다르게 설정한 설정한 엔드포인트로 쿼리를 날려 지표들을 수집하는 방식이기 때문에 MySQL 서버에 접근하지 않아도 구성이 가능합니다. 그렇기 때문에 하나의 인스턴스에서 다수의 RDS를 모니터링할 수 있습니다. 어차피 Aurora는 서버리스기 때문에 서버에 접근이 불가합니다. 권한의 분리는 항상 중요하기에 exporter를 위한 계정을 별도로 생성해줍니다.

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'exporter'@'localhost';
GRANT SELECT ON performance_schema.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES

Mysqld-exporter의 경우 별도의 설정이 없을 경우 기본 항목의 지표들을 수집합니다. 필요시 Flag 값을 설정하여 다양한 값을 추가로 수집할 수 있습니다. 수집하는 항목의 경우 Mysql Server에 쿼리를 전달하여 해당 지표를 가져오는 방식이니 쿼리 실행시간이 길 경우 주의해야합니다. 여기서는 processlist를 수집해보겠습니다.

mysqld_exporter collecoter리스트

docker run --rm \
-d -p 9104:9104 \
-e 'DATA_SOURCE_NAME=user:passoword@(엔드포인트)/' \
prom/mysqld-exporter \
--collect.info_schema.processlist

--collect.info_schema.processlist : processlist 수집을 위한 데이터 수집
만약 메트릭 정보에서 해당 지표만 수집해야할 경우 prometheus.yml 파일의 static_configs의 job 하위에 아래의 구문을 추가합니다.

params:
  collect[]:['collect.info_schema.processlist']

각 Flag 값이 어떤 지표를 표시하는지는 Mysqld-exporter collector 소스에서 해당 쿼리를 확인할 수 있습니다.

Mysqld_exporter collector Query 목록

다수의 인스턴스를 모니터링할 경우 포트 번호를 변경하여 mysqld-exporter를 추가할 수 있습니다.

docker run --rm \
-d -p 9105:9104 \
-e 'DATA_SOURCE_NAME=user:passoword@(엔드포인트)/' \
prom/mysqld-exporter

성능 지표 수집

브라우저에서 설치된 포트의 9090포트로 접근합니다.

RDS의 메트릭을 조회해보면 현재 processlist를 확인할 수 있습니다.

Mysqld-exporter의 경우 MySQL 지표를 Count, Sum 과 같이 수치화하기 때문에 아래와 같이 그래프로 표시할 수 있습니다.

마무리

프로메테우스의 Mysqld-exporter를 이용하면 Table Lock, Thread, 오픈된 파일 수등 다양한 지표를 필터링해서 수집할 수 있기에 성능 관점에서 세부적인 트랜잭션 지표를 수집할 수 있는 점이 매력적이라고 생각됩니다. 어떤 지표를 좀 더 효율적으로 모니터링할 수 있을지 고민해본 후 기회가 된다면 포스팅하겠습니다.

저작자표시

'DataBase > Monitoring' 카테고리의 다른 글

Grafana Cloud Watch 대시보드 구성 (0)	2022.03.29

Contents

당신이 좋아할만한 콘텐츠

Grafana Cloud Watch 대시보드 구성 2022.03.29

새소식

인기 검색어