📊 인프라/어플리케이션 메트릭 모니터링 (Prometheus, Telegraf, PostgreSQL)

 
airflow, kubeflow, trino의 cpu, memory 데이터는 Prometheus로 가져와서 telegraf를 통해서 postgresql db에 저장한다.
db에 저장하는 이유는 분기마다 데이터를 누적해서 보고싶기 때문이다. Prometheus는 기본 데이터 보관기간이 15일이다. 

 

Prometheus의 데이터 보관기간을 늘리면 되는데, 왜 Telegraf를 통해서 Postgresql에 데이터를 보관하는 것일까?

그 이유는 스토리지 용량 증가로 오래된 쿼리 조회 시 속도가 느려지고 디스크I/O 부하가 발생할 수 있다. 또한 Prometheus는 데이터를 영구적으로 쌓아두고 분석하는 데이터 웨어하우스(DW) 목적으로 설계되지 않았기에 장기보관에 적합하지 않다. Prometheus 로컬 스토리지는 백업과 복구가 DB만큼 유연하지 않아서 안정성을 위해서도 Postgresql를 선택했다. 나중에 여러 매트릭 데이터와 비즈니스 데이터를 조인해서 엑셀로 추출하기에도 DB에 저장해야 쿼리 유연성을 보장할 수 있다.
 
Trino에 테이블에 있는 airflow 내 특정한 dag와 kubeflow의 모델의 cpu, memory와 사용자 데이터를 postgre로 저장하기 위해서 sync-worker를 사용했다. 5분에 한번씩 데이터를 가져오게 하였고 postgre로 데이터를 insert하는 파이썬 코드다.
 
Grafana에서는 postgresql DB만 커넥션으로 연결하면 된다.
 

아키텍쳐 설계 시 고민한 점

1. 메트릭 데이터가 Postgre에 많이 쌓이면 grafana에서 조회 속도가 느려질텐데 이걸 어떻게 해결할 수 있을까?
-> postgre extension인 Timescale 형식으로 변경하면 된다. postgre config 파일에 추가만 하면 돼서 변경은 어렵지 않지만, 다만 Timescale로 변경하는 건 DB 재시작이 필요하다.
 
2. NAS 용량 데이터를 가져올때 왜 cronjob을 사용했을까?
-> telegraf sidecar로 스토리지를 가져오지 않고 cronjob을 선택한 이유는 스토리지 용량 계산에 순간적으로 메모리를 많이 쓰면서 I/O와 메모리 부하 문제가 발생할 경우,  telegraf sidecar는 telegraf pod에도 영향을 주기 때문이다. 보통 스토리지 용량 계산하는데 시간이 오래 걸린다. Trino와 연동된 스토리지 용량 확인은 자주 바뀌는 상태 데이터도 아니고 배치 이후에 용량 체크를 위해서 k8s 크론잡으로 딱 하루 한번 실행되게 하였고 shell 파일(mc du)로 용량을 influxdb 형식으로 telegraf에게 전달한다.
 

트러블 슈팅

1. trino의 cordinator와 woker를 구분해서 메트릭 데이터를 가져오려면 어떻게 해야할까??
-> Trino JMX Exporter의 k8s service의 셀렉터를 구분해서 띄워야한다. service를 각각 띄우기 위해서는 pod에 lable이 구분되어져야한다. 그래야 telegraf의 tag 필드에서 구분해서 cordinator와 woker를 구분해서 값이 들어온다. Trino는 기본적으로 JMX 형태로 메트릭을 제공하는데, 이를 프로메테우스가 pull 할 수 있도록 HTTP로 변환해주는 JMX Exporter가 필요하다.
 
2. 메트릭 이름을 지정해서 특정 메트릭만 가져오도록 telegraf.conf 파일을 수정하였는데 왜 메트릭을 안가져올까??
-> 프로메테우스에서 telegraf가 데이터를 가져올때 메트릭 이름과 태그로 분리한다. 그래서 딱 일치하는 값이 아니면 아예 수집이 안된다. Telegraf는 fieldpass에 적힌 이름과 100% 일치하는 필드만 가져오기 때문에, 글자 하나만 틀려도 데이터를 안가지고 온다. 그래서 fieldpass를 전부 없애서 Telegraf를 띄운 다음에 Postgresql에 데이터가 어떻게 들어오는지 확인하고 fieldpass를 다시 넣어줬다.