서버 모니터링 도구 비교 — top, htop, Grafana 등

서버 모니터링 도구 비교 — top, htop, Grafana 등

서버를 운영하다 보면 갑자기 사이트가 느려지거나 접속이 안 되는 상황이 생깁니다. 이때 가장 먼저 해야 할 일은 서버 상태를 확인하는 겁니다. CPU가 과부하인지, 메모리가 부족한지, 디스크가 꽉 찼는지를 알아야 원인을 찾을 수 있습니다. 리눅스에는 서버 상태를 확인할 수 있는 도구가 여러 가지 있는데, 터미널에서 바로 쓸 수 있는 간단한 것부터 웹 대시보드로 보는 본격적인 모니터링 시스템까지 다양합니다. 이번 글에서는 실무에서 자주 쓰이는 모니터링 도구들을 하나씩 살펴보고 어떤 상황에서 어떤 도구를 쓰면 좋은지 정리해보겠습니다.

top — 리눅스에 기본으로 들어있는 모니터링 도구

top은 리눅스라면 어디에나 설치되어 있는 기본 도구입니다. 별도 설치 없이 터미널에서 top을 입력하면 바로 실행됩니다.

top

실행하면 화면 상단에 시스템 전체 요약 정보가 나옵니다. 서버가 켜진 시간, 현재 접속 중인 사용자 수, 로드 애버리지, 전체 CPU 사용률, 메모리 사용량이 표시됩니다. 아래쪽에는 실행 중인 프로세스 목록이 CPU 사용률 순으로 나열됩니다.

로드 애버리지는 서버 상태를 빠르게 판단할 때 유용한 지표입니다. 세 개의 숫자가 나오는데 각각 1분, 5분, 15분 평균입니다. 이 숫자가 서버의 CPU 코어 수보다 높으면 서버에 부하가 걸리고 있다는 뜻입니다. 코어가 4개인 서버에서 로드 애버리지가 4를 넘으면 처리 대기 중인 작업이 쌓이고 있는 상태입니다.

top 화면에서 특정 작업을 할 수도 있습니다. Shift+M을 누르면 메모리 사용량 순으로 정렬되고, Shift+P를 누르면 다시 CPU 순으로 돌아옵니다. 숫자 1을 누르면 CPU 코어별 사용률을 개별로 볼 수 있습니다. 특정 프로세스를 종료하고 싶으면 k를 누르고 PID를 입력하면 됩니다. 나가려면 q를 누릅니다.

top의 장점은 어디서든 바로 쓸 수 있다는 겁니다. SSH로 접속해서 서버 상태를 빠르게 확인할 때 가장 먼저 사용하는 도구입니다. 다만 화면이 투박하고 프로세스를 시각적으로 구분하기가 어렵습니다. 정보는 다 있는데 한눈에 파악하기가 불편합니다.

htop — top의 개선 버전

htop은 top과 같은 역할을 하지만 화면이 훨씬 보기 좋습니다. 색상이 들어가 있고 CPU와 메모리 사용량이 막대그래프로 표시되어서 직관적입니다.

Ubuntu에서 설치하려면 이렇게 합니다.

sudo apt install htop

설치 후 htop을 입력하면 실행됩니다.

htop

화면 상단에 CPU 코어별 사용률이 색깔 막대로 나옵니다. 초록색은 사용자 프로세스, 빨간색은 커널 프로세스, 파란색은 저우선순위 프로세스입니다. 메모리와 스왑 사용량도 막대로 표시됩니다. top에서는 숫자만 보고 머릿속으로 계산해야 했던 걸 htop에서는 눈으로 바로 확인할 수 있습니다.

프로세스 목록도 top보다 다루기 편합니다. 마우스로 클릭해서 프로세스를 선택할 수 있고, F6을 눌러서 정렬 기준을 바꿀 수 있고, F9를 눌러서 프로세스에 시그널을 보낼 수 있습니다. 트리 뷰도 지원하는데 F5를 누르면 프로세스의 부모-자식 관계를 트리 구조로 보여줍니다. Nginx 마스터 프로세스 아래에 워커 프로세스들이 달려 있는 걸 한눈에 볼 수 있어서 프로세스 구조를 파악하기 좋습니다.

F2를 누르면 설정 화면이 나오고 표시할 항목을 커스터마이즈할 수 있습니다. 화면 하단에 기능 키 안내가 나오기 때문에 단축키를 외우지 않아도 됩니다.

개인적으로 서버에 접속하면 top 대신 htop을 먼저 치게 됩니다. 설치가 간단하고 정보량은 top과 같은데 가독성이 훨씬 좋기 때문입니다. 새 서버를 세팅하면 거의 습관적으로 htop부터 설치합니다.

vmstat — 시스템 자원을 숫자로 빠르게 확인

vmstat은 CPU, 메모리, 스왑, I/O 상태를 한 줄로 보여주는 도구입니다. top이나 htop처럼 실시간으로 갱신되는 화면이 아니라 스냅샷을 찍어주는 느낌입니다.

vmstat 2 5

이 명령어는 2초 간격으로 5번 측정해서 보여줍니다. 출력 결과를 보면 procs, memory, swap, io, system, cpu 항목이 있습니다.

여기서 주로 보는 건 몇 가지입니다. r 값은 CPU를 기다리고 있는 프로세스 수인데 이게 코어 수보다 많으면 CPU가 부족한 겁니다. si와 so는 스왑 인과 스왑 아웃인데 이 값이 지속적으로 높으면 메모리가 부족해서 디스크를 메모리처럼 쓰고 있다는 뜻입니다. 스왑이 많이 발생하면 서버가 급격하게 느려집니다.

vmstat은 서버에 문제가 생겼을 때 원인이 CPU인지 메모리인지 디스크 I/O인지를 빠르게 판별하는 데 유용합니다. 스크립트에서 결과를 파싱하기도 편해서 모니터링 자동화에 활용하기도 합니다.

df와 du — 디스크 용량 확인

서버가 갑자기 이상해지는 원인 중 의외로 많은 게 디스크 용량 부족입니다. 로그 파일이 쌓여서 디스크가 꽉 차면 데이터베이스가 멈추거나 새 파일을 생성하지 못해서 서비스가 중단될 수 있습니다.

df는 파일 시스템별 디스크 사용량을 보여줍니다.

df -h

-h 옵션을 붙이면 사람이 읽기 편한 단위(GB, MB)로 표시됩니다. Use% 칼럼이 90%를 넘어가면 조치가 필요합니다.

du는 특정 디렉토리가 얼마나 많은 용량을 차지하는지 확인할 때 씁니다.

du -sh /var/log/*

-s는 요약, -h는 사람이 읽기 편한 단위입니다. 어떤 디렉토리가 용량을 많이 잡아먹고 있는지 찾을 때 유용합니다. 로그 디렉토리에서 몇 기가짜리 파일이 발견되면 이전 글에서 다뤘던 크론탭으로 주기적으로 정리하는 설정을 추가하면 됩니다.

iotop과 nethogs — 디스크와 네트워크 사용 추적

CPU와 메모리는 정상인데 서버가 느리다면 디스크 I/O나 네트워크가 병목일 수 있습니다.

iotop은 어떤 프로세스가 디스크를 많이 읽고 쓰고 있는지 보여줍니다.

sudo apt install iotop
sudo iotop

htop이 CPU와 메모리 기준으로 프로세스를 보여준다면 iotop은 디스크 I/O 기준으로 보여줍니다. 데이터베이스가 디스크를 과도하게 사용하고 있다거나 백업 작업이 I/O를 잡아먹고 있다거나 하는 걸 확인할 수 있습니다.

nethogs는 프로세스별 네트워크 사용량을 보여줍니다.

sudo apt install nethogs
sudo nethogs

어떤 프로세스가 네트워크 대역폭을 많이 차지하는지 실시간으로 확인할 수 있습니다. 의도하지 않은 프로세스가 외부로 트래픽을 보내고 있다면 보안 문제일 수도 있으니 주의깊게 봐야 합니다.

Prometheus와 Grafana — 본격적인 모니터링 시스템

지금까지 다룬 도구들은 전부 터미널에서 서버에 직접 접속해서 확인하는 방식입니다. 서버가 한두 대일 때는 이걸로 충분하지만 서버가 여러 대이거나, 시간에 따른 추이를 보고 싶거나, 특정 조건에서 알림을 받고 싶으면 별도의 모니터링 시스템이 필요합니다.

Prometheus는 모니터링 데이터를 수집하고 저장하는 도구입니다. 각 서버에 설치된 에이전트(Node Exporter)가 서버의 CPU, 메모리, 디스크 같은 지표를 수집하고, Prometheus가 주기적으로 이 데이터를 가져와서 시계열 데이터베이스에 저장합니다.

Grafana는 저장된 데이터를 웹 대시보드로 시각화하는 도구입니다. Prometheus에 쌓인 데이터를 가져와서 그래프, 차트, 게이지 같은 형태로 보여줍니다. 브라우저에서 접속하면 서버의 CPU 사용률이 시간에 따라 어떻게 변했는지, 메모리가 언제부터 부족해지기 시작했는지를 시각적으로 확인할 수 있습니다.

전체 구조를 정리하면 이렇습니다. 서버에 Node Exporter가 설치되어 지표를 노출하고, Prometheus가 이걸 수집해서 저장하고, Grafana가 Prometheus에서 데이터를 꺼내와서 대시보드에 그려줍니다. 세 가지가 각각 다른 역할을 하면서 하나의 모니터링 파이프라인을 구성합니다.

Grafana의 가장 큰 장점은 대시보드를 자유롭게 구성할 수 있다는 점입니다. 직접 만들 수도 있고, Grafana Labs 커뮤니티에서 다른 사람들이 만들어둔 대시보드를 가져와서 바로 쓸 수도 있습니다. Node Exporter용 대시보드를 임포트하면 서버 모니터링 화면이 몇 분 만에 완성됩니다.

알림 설정도 가능합니다. CPU 사용률이 90%를 넘으면 슬랙으로 알림을 보내거나, 디스크 사용량이 80%를 넘으면 이메일을 보내는 식으로 설정할 수 있습니다. 문제가 생겼을 때 서버에 직접 접속해서 확인하는 게 아니라 알림을 받고 대응하는 구조를 만들 수 있습니다.

다만 Prometheus와 Grafana는 설치와 설정이 위에서 다룬 도구들에 비해 복잡합니다. 서버를 처음 운영하는 단계에서 바로 도입하기보다는 서버 운영이 어느 정도 익숙해지고, 관리할 서버가 늘어나거나 안정적인 서비스 운영이 필요해질 때 구축하는 게 현실적입니다.

클라우드 모니터링 서비스

AWS, GCP 같은 클라우드를 사용하고 있다면 클라우드 자체에서 제공하는 모니터링 서비스도 있습니다. AWS의 CloudWatch, GCP의 Cloud Monitoring이 대표적입니다.

이런 서비스들은 별도 설치 없이 클라우드 콘솔에서 바로 서버의 CPU, 메모리, 네트워크, 디스크 지표를 확인할 수 있습니다. 알림 설정도 콘솔에서 클릭 몇 번으로 됩니다. 직접 Prometheus를 구축하는 것보다 훨씬 간편합니다.

단점은 클라우드에 종속된다는 점과 세밀한 커스터마이즈가 어렵다는 점입니다. 그리고 무료 범위를 넘어가면 비용이 발생합니다. 서버가 적고 해당 클라우드를 이미 사용하고 있다면 충분히 실용적인 선택입니다.

상황별 도구 선택 가이드

서버에 문제가 생겨서 지금 당장 상태를 확인해야 한다면 top이나 htop을 씁니다. SSH로 접속해서 바로 확인할 수 있고 별도 설치가 필요 없거나 간단합니다.

CPU인지 메모리인지 디스크인지 원인을 빠르게 분류하고 싶으면 vmstat을 씁니다. 디스크가 의심되면 iotop, 네트워크가 의심되면 nethogs를 추가로 확인합니다.

디스크 용량이 문제인 것 같으면 df와 du로 어디가 꽉 찼는지 찾습니다.

서버를 지속적으로 모니터링하면서 시간에 따른 추이를 보고 싶고 알림까지 받고 싶으면 Prometheus와 Grafana 조합을 구축합니다.

클라우드 서버를 쓰고 있고 간편하게 모니터링하고 싶으면 CloudWatch나 Cloud Monitoring 같은 클라우드 내장 서비스를 활용합니다.

처음에는 htop 하나만 잘 써도 대부분의 상황에 대응할 수 있습니다. 거기서 시작해서 필요에 따라 도구를 하나씩 추가해나가면 됩니다.

마무리

서버 모니터링은 문제가 터진 뒤에 하는 것보다 평소에 상태를 파악해두는 게 중요합니다. 정상일 때의 CPU 사용률이나 메모리 사용량을 알고 있어야 비정상인 상황을 감지할 수 있습니다. htop으로 수시로 서버 상태를 확인하는 습관을 들이고, 서비스가 커지면 Grafana 같은 시각화 도구를 도입해서 체계적으로 관리하는 방향으로 나아가면 됩니다. 다음 글에서는 HTTP와 실시간 통신의 차이를 이해할 수 있는 WebSocket에 대해 다뤄보겠습니다.