[ 모니터링 시스템 구성현황 ]

[4whomtbts]

모니터링 시스템 구성

1. Prometheus ( [3]의 exporter 데이터를 수집하는 중앙시스템) -> 210.94.223.123:8089
2. Grafana (Prometheus에서 수집한 데이터를 기반으로 시각화) -> 210.94.223.123:7079
3. node_exporter(CPU, Network, Disk monitoring), dcgm_exporter(GPU temp, utilization)
   -> node_exporter는 각 서버 9100번 포트, dcgm_exporter 는 각 서버 9400번 포트

Alert 의 경우 Reminder 설정을 하여서
메트릭이 경보수준에 있는 동안은
Slack은 5분마다 지속적으로 Reminder 전송
Email은 15분마다 지속적으로 Reminder 전송

(Alertering->Send reminder every 에서 설정)

Prometheus 구성 현황(http://210.94.223.123:8089/targets)

Grafana 대시보드 현황(http://210.94.223.123:7079)

1. 통합 GPU 알람 대시보드

-> 모든 서버의 GPU 메트릭을 확인할 수 있는 대시보드
적용된 Alert
GPU 과열 주의경보 : 특정 서버의 GPU 75도 이상 -> Slack, 이메일 알림
GPU 과열 경고경보 : 특정 서버의 GPU 80도 이상 -> Slack, 이메일 알림

2. 서버별 GPU 대시보드

-> 각 서버별로 GPU 메트릭을 확인할 수 있는 대시보드

3. 공통 메트릭 대시보드

-> 모든 서버의 CPU 온도 메트릭을 확인할 수 있는 대시보드
적용된 Alert
CPU 과열 주의경보 : 특정 서버의 CPU 80도 이상 -> Slack, 이메일 알림

4. 서버별 운영체제 메트릭

-> 각 서버별로 CPU, Memory, Disk usage 및 각종 커널 메트릭을 확인할 수 있는 대시보드

가동중인 알림현황

슬랙 Alert 결과

관련된 Survey 정리

정확하고 의미있는 파일시스템 모니터링

서버별 운영체제 메트릭 대시보드에서 DIsk Space 관련 메트릭을 확인하면
여러가지 마운트 포인트들에 대한 디스크 사용률을 볼 수 있음

• /
• /home
• /294t
• /run
• /run/(으로시작하는 모든 subpath)

여기에서 /boot, /run(Filestystem 에서 tmpfs, udev) 는 커널 시작시에 임시파일을 저장하는 용도이며
필수적이지만, 매우 적은 용량을 차지하기 때문에, 감시 및 관리 대상은 아님

/294t 는 연구실 클러스터 스토리지의 NFS 마운트포인트이기 때문에
로컬 디스크 용량 관리와는 무관함

결국에는 '/' 마운트 포인트의 Available space 관리가 중요하다.
따라서, 공통 메트릭 대시보드 에서 파일시스템 경보를 울리는 지표로 사용할 데이터를
각 서버의 mountpoint 가 '/' 인 디스크로 설정하였다.

관리 포인트

시스템 특성상, 루트파일시스템에 생기게 되는 대형 파일들은 아래와 같다

1. Docker image
   Docker image는 일반적으로 매우 용량이 크다. 따라서 주기적으로
   사용되지 않거나 dangling 된 이미지들을 정리해주는 것만으로도
   많은 여유공간을 확보할 수 있다.

2. Docker volume
   학습용 데이터들은 모두 스토리지나 NAS의 NFS에 저장하도록 하고 있지만
   사용자들이 모든 데이터를 NFS에만 저장하리라는 이상적인 기대를 할 수 없다.
   예를들어 현재(2021.06.23) 3번 서버의 경우 70.9% 의 파일시스템이 사용되고 있는데
   불필요한 Docker image도 모두 삭제된 상태임에도 불구하고 높은 사용량을 보이는 이유는
   Python, Anaconda 와 같은 binary의 용량과 더불어 각종 라이브러리(tensorflow, pytorch ..etc) 용량과
   일부 사용자가 스토리지가 아닌 컨테이너의 루트파일시스템에 학습 데이터를 저장하고 있어서이다.
   특히, 이러한 학습 데이터는 용량도 큰데 갯수도 상당히 많으므로, 디스크 관리의 주요 포인트이다.
   컨테이너 내에서 차지하는 용량이 많은지 확인하는 방법은 아래의 항목에서 서술한다

컨테이너 디스크 용량관리

현재 시스템은 사용자에게 Docker bind mount만 해주고
컨테이너의 루트파일시스템에 저장되는 데이터들은 호스트의 /var/lib/docker/overlay2/* 라는
위치에 임시적으로 저장되다가, 컨테이너 삭제와 동시에 삭제된다.
문제는 수명이 긴 컨테이너들은, 데이터가 누적되기 때문에 호스트에서 많은 용량을 차지하는 것이다.

따라서, 디스크 용량확보가 필요할 시, 컨테이너에 저장된 임시파일을 확인하여
사용자에게 스토리지로 이동 혹은 삭제 조치를 취하도록 지시하여야 한다.

컨테이너내의 파일을 찾는 커맨드는 아래와 같다

# 1G는 1GB를 의미하며, 상황에 따라 100MB , 10G 등 다양한 옵션으로 파일크기를 지정하자
$ sudo find / -xdev -type f -size +1G | grep docker

이 명령어로 컨테이너에서 가지고 있는 임시 데이터들의 목록을 확인할 수 있고
이 목록을 기반으로 로컬 파일시스템에 지나치게 많은 데이터를 저장하고 있는
컨테이너를 확인할 수 있다.

이 작업을 CRON 으로 수행해서, 대형 파일을 스토리지가 아닌 로컬에 저장하고 있는
컨테이너를 찾고, 리포팅하는 방식으로 관리하는 방법도 존재한다

컨테이너 저장공간 변경

앞의 '컨테이너 디스크 용량관리' 에서 서술했듯이 컨테이너의 임시 데이터는
/var/lib/docker/overlay2/* 와 같은 경로에 저장되어 있다가, 컨테이너 삭제시에 삭제되게 되어
루트파일시스템의 공간을 차지하고 있게 된다.
하지만, 1~6번 서버는 '/'가 마운트된 /dev/sda (약 1TB) 외에도 /dev/sdb, /dev/sdc (약 3.9T) 라는
데이터용 디스크가 따로 존재하고 있다.
대량의 데이터는 스토리지 서버에 저장하고 있기에, 해당 디스크들을 활용하지 않고도
운용할 수 있었지만, 이제는 컨테이너의 임시데이터를 루트파일시스템이 아닌
/dev/sdb, /dev/sdc 에 저장하여 운용할 수 있도록 해야한다.

이 작업은 링크 를 참고하여 할 수 있다.
서버에 운용하고 있는 컨테이너들이 있기에, 바로 적용할 수는 없다.

후속작업

Email 알림 작업 -> 완료
disk storage shortage alert 추가 -> 완료
Docker 임시파일 저장 디스크를 변경

관련 문서

모니터링 시스템 구축과정 문서 -> #6
추가작업 백로그 -> #7 , #8, #9
이메일 Alert 작업 -> #11