| 프로세스 | CPU % | RAM % |
|---|---|---|
| falco | 7.4 | 5.6 |
| mysqld | 4.4 | 7.3 |
| crowdsec | 2.6 | 15.6 |
| apache2 | 1.4 | 4.5 |
| fail2ban-server | 0.7 | 17.1 |
| 프로세스 | CPU % | RAM % |
|---|---|---|
| apache2 | 18.0 | 9.3 |
| mysqld | 12.8 | 14.0 |
| clamd | 8.9 | 14.3 |
| falco | 6.2 | 11.0 |
| suricata | 2.8 | 18.4 |
top은 지금 이 순간에 관한 물음에 답하지만, 실제로 던지는 물음은 대개 지난밤에 관한 것입니다. 새벽 세 시에 왜 모든 것이 멈췄다가 저절로 돌아왔는가. 그때가 되면 들여다볼 것이 남아 있지 않습니다. 아무것도 기록되지 않았기 때문입니다. 그렇다고 VPS 한 대를 위해 Prometheus와 Grafana를 세우는 일도 그 자체로 문제입니다. 관찰하는 쪽의 스택이 관찰당하는 서버보다 무거워지기 때문입니다.
수집기가 5분마다 데이터베이스에 한 줄씩 덧붙이고, 이 페이지는 그것으로 지난 24시간을 그립니다. load average, I/O wait를 따로 떼어 보여 주는 CPU 사용률, RAM과 swap, 네트워크 수신과 송신, 디스크 읽기와 쓰기, 맺어진 TCP 연결, 프로세스, 파티션 사용량, 한도 대비 백분율로 나타낸 inode와 파일 디스크립터, MySQL 연결 수. 모두 한 페이지에 같은 시간축으로 놓이므로 동시에 일어난 일이 눈에 들어옵니다.
이 그래프들은 짝을 지어 읽는 편이 좋습니다. CPU는 한가한데 I/O wait가 높다면 서버가 디스크를 기다리는 것이고, 코어를 늘려도 소용없습니다. 한 번 올라간 뒤 영영 0으로 돌아오지 않은 swap은 지금이 아무리 잠잠해 보여도 메모리 정점이 이미 지나갔음을 말해 줍니다. 100퍼센트에 가까워진 파일 디스크립터는 실제로 too many open files가 터지기 몇 시간 전의 모습입니다. 그리고 대부분의 서버에서 inode는 남은 공간보다 훨씬 먼저 바닥납니다.