Linux

서버 모니터링 명령어

서버 모니터링 명령어 모음입니다. CPU, 메모리, 디스크, 네트워크, 로그를 장애 분석 순서로 묶고 결과 해석 기준을 정리했습니다.

devmes

• 조회 190

서버 모니터링 명령어는 “CPU 몇 퍼센트”를 보는 도구가 아니라 장애 원인을 좁히는 도구입니다. 운영에서는 CPU, 메모리, 디스크, 네트워크, 프로세스, 로그를 같은 시간대 기준으로 묶어서 봐야 합니다.

전체 상태 빠르게 보기

hostname -f
date --iso-8601=seconds
uptime
who
last -n 5
sudo systemctl --failed

uptime의 load average는 CPU 개수와 함께 봐야 합니다. 1분 load가 높아도 CPU 병목인지 I/O wait인지 다음 단계에서 분리해야 합니다.

CPU

top
mpstat 1 5
pidstat -u 1 5
ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head

mpstat에서 %iowait가 높으면 CPU가 계산을 못 하는 것이 아니라 디스크나 스토리지를 기다리는 상황일 수 있습니다.

메모리

free -h
vmstat 1 5
cat /proc/meminfo | head -n 20
ps -eo pid,comm,rss,%mem --sort=-rss | head
sudo journalctl -k --no-pager | grep -Ei "oom|out of memory|killed process"

Linux는 사용하지 않는 메모리를 page cache로 적극 활용합니다. free에서 used만 보고 장애로 판단하지 말고 available, swap 사용량, OOM 로그를 같이 봅니다.

디스크 용량과 I/O

df -hT
df -ih
du -xhd1 /var | sort -h
lsblk
iostat -xz 1 5
sudo lsof | grep deleted | head

용량이 충분해도 inode가 가득 차면 파일 생성이 실패합니다. 로그 파일을 삭제했는데 용량이 줄지 않으면 삭제된 파일을 프로세스가 잡고 있는지 lsof로 확인합니다.

네트워크

ip -br a
ip r
ss -lntup
ss -ant state established | head
ping -c 3 8.8.8.8
dig example.com
mtr -rw example.com

서비스 접속 장애는 listen 여부, 로컬 방화벽, 라우팅, DNS, 외부 경로를 분리해서 봅니다. ping이 막힌 환경도 있으므로 TCP 확인은 nc나 curl을 같이 사용합니다.

로그

sudo journalctl -p warning -S -1h --no-pager
sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/messages 2>/dev/null
sudo tail -n 100 /var/log/syslog 2>/dev/null
sudo dmesg -T | tail -n 100

장애 리포트에 남길 값

  • 서버명과 시간대
  • 장애 시작/종료 시각
  • CPU load와 iowait
  • 메모리 available, swap, OOM 여부
  • 디스크 용량, inode, I/O wait
  • 서비스 로그와 kernel 로그
  • 최근 배포/설정 변경 여부

주의할 점

  • 로그 내용에는 내부 IP, 사용자명, 토큰, 요청 본문이 들어갈 수 있으므로 외부 공유 전 마스킹합니다.
  • 한 번의 스냅샷보다 1초 간격 5회처럼 짧은 추세를 보는 편이 좋습니다.
  • 모니터링 도구 수치와 서버 현장 명령 결과가 다르면 수집 지연과 에이전트 장애도 의심합니다.
BGM EVER