1. 기존 프로메테우스 데이터 마이그레이션
현재 테스트로 프로메테우스를 구성하여 node exporter를 통해 몇몇 리눅스 서버를 모니터링하고 있다.
별 다른 설정 없이, 단순 프로메테우스 이미지를 컨테이너 실행 시킨 것 뿐이라, 데이터 등도 컨테이너 내부에서 쌓이고 있다.
대강 이런 형식인데, 문제는 모니터링 대상이 추가되거나, 구성에 변경이 있을 시 컨테이너를 재시작하면 쌓여있던 데이터가 전부 날아가는 것이다..
(당연히,, 컨테이너를 새로 빌드하면 그렇지..)
그래서 지금 동작중인 해당 프로메테우스의 저장된 3개월치의 데이터를 가지고
신규 구성한 컨테이너로 마이그레이션하는 작업을 진행해보겠다.
신규 구성 프로메테우스 구성은 기존 글을 참고하시라
https://cwpack0730.tistory.com/101
2. 프로메테우스 메트릭 저장 경로
# 데이터 저장 설정
tsdb:
path: /data # 데이터 저장 경로
retention_time: 30d # 데이터 보관 기간 설정
wal_compression: true # WAL 압축 설정
신규로 구성한 프로메테우스 yml 중 일부이다.
현재 /data 경로로 tsdb를 설정하여, 해당 경로로 메트릭이 쌓이는 것을 확인할 수 있다.
그리고 다음은 현재 운영중인 프로메테우스 컨테이너다.
기본 구성으로는 프로메테우스 메트릭 데이터는 /promethus 경로에 쌓이게 된다.
😎 프로메테우스 저장소가 작동하는 방식은, 일단 일정한 크기의 chunk로 구성된다. 새로 수집된 데이터는 head chunk에 기록되며, memory에 저장되다 일정한 크기를 할당하고 disk로 chunk를 이동시킨다.
* chunk : 데이터 저장 단위
chunk가 쌓이는 날짜를 확인해보면, 더 잘 이해할 수 있다.
컨테이너 내부 파일을 로컬로 복사하였다.
docker cp cw-prometheus:/prometheus/ ./data/
잘 복사된 것을 확인하였고, 이를 신규 컨테이너에 넣어보도록 하겠다.
tar로 압축하여 신규 서버에 전달하겠다.
tar cvf cw-data.tar *
scp -P [SSH 포트] cw-data.tar root@[대상IP]:/home
그리고 해당 데이터가 정상적으로 적용되는 것을 확인하기 위해 신규 컨테이너를 생성한다.
다음 웹으로 접근하여 수집한 메트릭 정보를 확인한다.
생성한지 얼마 지나지 않아, 데이터양이 적게 나타나있는 것을 확인할 수 있다.
여기에, 이전 프로메테우스에서 수집했던 한달간의 데이터를 넣어보겠다.
파일로 저장되는 chunks 디렉터리들만 이동하였다.
이후 다시 웹으로 접근해 확인해보면, 신규 생성한 컨테이너에서 쌓이는 메트릭은 빨간 네모로 잘 쌓이고 있고,
노란색 네모에 기존 한달가량의 데이터 정보가 나타난 것을 확인할 수 있다.
즉, 프로메테우스에서 수집한 메트릭 데이터 정보를 백업하러면, 해당 chunks 디렉터리를 관리하면 될 것으로 보인다.
(요건 추후에 따로 cron을 돌려서 백업받아야겠다.)
3. 왜 influxDB를 사용하지 않고 직접 메트릭을 관리해요?
물론 장기적으로, 그리고 안전하게 메트릭 데이터를 보관하러면 influxDB를 사용해야 하나,
본인은 다음과 같은 이유로 prometheus와 grafana를 직접 연결해서 사용하기로 하였다.
- 추가 리소스 비용
- influxDB를 추가로 구성해서 관리할만큼 고도화된 모니터링이 아니다. influxDB가 추가될 만큼의 리소스를 생각해본다면, 현재 수준에서는 과한 구성이라고 생각된다.
- 즉각적인 사용 가능
- 1번과 비슷한 이유인데, influxDB에 대해 추가로 학습하고 관리하기에 혼자 하기에는 시간이 부족하다. 그리고 데이터 보관보다 현황을 확인하는 것을 목적으로 진행중이기 때문에, 오히려 데이터가 다른 서비스를 거치지 않고 바로 대시보드에 표현되는것이 속도적인 측면에서 조금이나마 장점이 있을 것 같았다.
- 1번과 비슷한 이유인데, influxDB에 대해 추가로 학습하고 관리하기에 혼자 하기에는 시간이 부족하다. 그리고 데이터 보관보다 현황을 확인하는 것을 목적으로 진행중이기 때문에, 오히려 데이터가 다른 서비스를 거치지 않고 바로 대시보드에 표현되는것이 속도적인 측면에서 조금이나마 장점이 있을 것 같았다.
influxDB까지는 현재 배보다 배꼽이 커지는 느낌이 있어서 일단 빠르게 구성하고 점차 개선해 나갈 생각이다,
(사실 처음부터 제대로 만드는게 훨신 좋긴한데... 서비스 오픈이 코앞이라 업무도 많고 같이 할 사람이 없다보니 어쩔수 없는 것 같다..)
지금 모니터링을 초기 구성하는 단계에서 운영되는 서비스와 시스템 수준을 생각하면 순서가 맞지 않는다고 느껴진다.
일단 시스템과 서비스 운영 환경 수준이 개선된 다음에 진행해도 무방하다. (우선 순위가 존재한다.)
지금 요구사항은 사이트의 모니터링이 관리가 되지 않기 때문에 통합하려는 목적으로, 빠르게 통합 환경을 구성한 뒤 개선해도 늦지 않다고 생각한다.
어느정도 구성이 완료되면 influxDB를 붙여보는 과정을 진행해보겠다!!
'DevOps > Monitoring_모니터링' 카테고리의 다른 글
[Prometheus] 프로메테우스 config reload (0) | 2024.08.05 |
---|---|
[Prometheus] 프로메테우스 데이터 기본 저장경로 (+docker compose) (0) | 2024.07.09 |
[Prometheus] 프로메테우스 기본 구성 (docker compose 생성) (0) | 2024.06.17 |
[Grafana] Grafana Image Renderer (1) | 2023.11.20 |
[모니터링] Grafana Slack 연동 (0) | 2023.11.16 |