리눅스 로그와 모니터링 — journalctl·logrotate·vmstat
"서버가 느려요", "왜 멈췄죠?" — 그때 어디부터 보나. 로그를 읽고, 자원을 보고, 병목을 찾는 순서입니다.
23편에서 grep·sed·awk 를 배웠죠. 그 도구를 어디에 쓰느냐 — 가장 자주 쓰는 곳이 로그 분석입니다. 그리고 "느려요/멈췄어요" 같은 문제는 추측 말고 순서대로 보면 거의 다 원인이 잡힙니다. 이번 편은 ① 로그 어디서 보나 ② journalctl (systemd 시대의 로그 1순위) ③ logrotate (로그가 디스크 안 잡아먹게) ④ free·top·vmstat·iostat·df 로 병목 찾는 진단 순서.
vmstat·iostat)는 보통 깔려 있고, 없으면 sudo apt install sysstat(11편). 모니터링 명령은 다 읽기 전용이라 안전합니다.로그 어디 있나 — /var/log 와 tail -f, 그리고 grep
전통적인 로그 파일들은 /var/log/ 아래 있습니다:
| 파일 | 무엇이 들어 있나 |
|---|---|
/var/log/syslog | 시스템 일반 로그 — 대부분의 데몬·서비스 메시지가 여기로. "뭔가 이상한데?" 하면 첫 번째로 보는 곳. |
/var/log/auth.log | 인증 관련 — 로그인 성공/실패, sudo 사용, SSH 접속. 보안 점검의 출발점(25편에서 다시). |
/var/log/kern.log · dmesg | 커널 메시지 — 디스크 에러, 메모리 부족(OOM 킬러), 하드웨어 문제. dmesg -T 로 사람이 읽을 시간 표시. |
/var/log/dpkg.log | apt/dpkg 패키지 설치·제거 기록 — "언제 뭘 깔았더라?" 추적용(11편). |
/var/log/nginx/·/var/log/mysql/ 등 | 앱별 로그 폴더. 웹 서버라면 access.log(요청)·error.log(에러)가 핵심. |
읽으려면 보통 sudo 가 필요합니다(/var/log 는 권한 보호 — 9편). 그리고 23편의 grep | awk | sort | uniq -c 패턴이 여기서 그대로 쓰여요: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head → IP별 요청 수.
journalctl — systemd 로그 한 곳에서
19편에서 봤듯 우분투는 systemd 기반이고, 그 로그는 journalctl 로 봅니다. 파일 여기저기 뒤질 필요 없이 한 명령으로 — 요즘 서버에선 이게 1순위:
옵션을 조합해서 "어제 9시 이후 이 서비스의 에러만" 같은 걸 한 줄로: journalctl -u myapp --since "yesterday 09:00" -p err. 그리고 journalctl 출력도 23편 도구로 더 거를 수 있어요(| grep ...).
systemctl status 서비스 — 살아 있나, 죽었으면 마지막 에러 몇 줄(19편) ② journalctl -u 서비스 -n 50 -p err — 그 서비스 최근 에러 ③ journalctl -b -p err — 이번 부팅 전체 에러. 이 셋이면 "왜 안 되는지"의 단서가 거의 나옵니다.logrotate — 로그가 디스크를 안 잡아먹게
로그는 그냥 두면 무한히 커집니다 — 어느 날 df -h 했더니 / 가 100%인데 범인이 access.log 80GB… logrotate 가 이걸 막아요: 일정 크기/주기마다 로그를 회전(app.log → app.log.1 → app.log.2.gz …)하고, 압축하고, 오래된 건 삭제합니다. 보통 자동으로 돌아갑니다(systemd timer로 매일).
내 앱 로그(예: /var/log/myapp/app.log)도 같은 형식으로 /etc/logrotate.d/myapp 파일 하나 만들면 자동 관리됩니다 — 14일치 보관, 매일 회전, 7일 지난 건 압축, 식으로. (참고: journalctl 로그는 systemd가 따로 크기 관리 — /etc/systemd/journald.conf 의 SystemMaxUse.)
"느려요" 진단 — free·top·vmstat·iostat·df, 그리고 정리
"서버가 느려요"는 보통 CPU·메모리·디스크 I/O·디스크 공간 넷 중 하나입니다. 순서대로:
top — 누가 CPU/메모리 먹나? 범인 프로세스가 보이면 거기서 끝(14편의 kill로 정리하거나, 그 앱 설정 보기). ② 안 보이면 free -h — 스왑 도나? → 메모리 늘리거나 메모리 큰 프로세스 줄이기. ③ df -h — 디스크 꽉 찼나? → du -h --max-depth=1 / | sort -h(15편)로 범인 폴더, 보통 로그(위 logrotate) 또는 캐시. ④ vmstat 1 의 wa 가 높으면 I/O 병목 → iostat -x 1 로 어느 디스크. ⑤ 그래도 모르면 journalctl -p err · dmesg -T — 에러·OOM 흔적. 이 순서면 "느려요"의 90%는 30분 안에 원인이 잡힙니다.여기까지 배운 걸 합치면 작은 모니터링 스크립트도 만들 수 있어요 — "디스크가 80% 넘으면 알려줘"를 21~23편 총동원으로:
시리즈 흐름
- 1~23편 입문~고급(스크립트·텍스트 처리) ✔ 24편 로그와 모니터링 (이 글) ✔
- 25편 — 서버 보안 하드닝(SSH 강화·fail2ban·자동 패치·최소 권한) — 오늘의
auth.log가 거기서 핵심 - 26편 — 도커 입문 on Ubuntu (시리즈 완결)
정리하면 — 로그는 /var/log(전통)와 journalctl(systemd, 1순위)에서 보고, 23편 grep·awk 로 거르고 집계합니다. 디스크를 안 잡아먹게 logrotate 가 알아서 회전시키고요. "느려요"는 top → free → df → vmstat → iostat → journalctl 순서로 보면 원인이 거의 잡힙니다. 25편에서는 이 로그(특히 auth.log)를 들고 서버를 실제로 단단하게 만드는 법을 다룹니다.
참고: 본 글은 우분투(systemd·GNU 도구) 기준이며 2026년 5월 13일에 작성되었습니다. vmstat·iostat 는 sysstat 패키지에 들어 있고, 일부 클라우드 인스턴스는 로그 경로·journald 설정이 다를 수 있습니다.
우분투·리눅스 입문 시리즈
문제 났을 때 어디부터 보나 — 24편입니다. 25편 "서버 보안 하드닝"으로 이어집니다(auth.log 가 거기서 첫걸음).
다음 편은 junai.ai/blog 에서 — 26편까지 차례로 올라옵니다.