| 进程 | CPU % | RAM % |
|---|---|---|
| apache2 | 13.4 | 4.7 |
| clamd | 9.8 | 5.3 |
| crowdsec | 6.6 | 9.6 |
| suricata | 4.7 | 0.9 |
| falco | 2.6 | 16.5 |
| 进程 | CPU % | RAM % |
|---|---|---|
| falco | 19.5 | 5.3 |
| mysqld | 13.1 | 9.6 |
| fail2ban-server | 8.1 | 8.8 |
| crowdsec | 5.7 | 13.6 |
| apache2 | 3.5 | 11.0 |
top 回答的是关于当前这一秒的问题，而人们真正要问的往往是昨夜：为什么凌晨三点一切停住，又自己恢复了。到那时已经无从查看，因为什么都没有留下。为了一台 VPS 去搭 Prometheus 加 Grafana 也自成问题：观察用的那一套比被观察的服务器还重。
采集器每五分钟往数据库里追加一行，本页据此画出最近二十四小时。load average、CPU 占用并把 I/O wait 单列、内存与 swap、网络的收与发、磁盘的读与写、已建立的 TCP 连接、进程、分区占用、inode 与文件描述符占各自上限的百分比，以及 MySQL 连接数。全部在同一页、同一条时间轴上，因此同时发生的事情一眼就能看出来。
这些曲线宜成对来读。CPU 平静而 I/O wait 很高，说明服务器在等磁盘，加核心不会有用。swap 曾经涨上去、之后再没回到零，说明内存峰值早已发生过，哪怕此刻看着风平浪静。文件描述符逼近百分之百，就是 too many open files 在真正报错前几个小时的样子。而在多数服务器上，inode 会比可用空间早得多地耗尽。