| プロセス | CPU % | RAM % |
|---|---|---|
| falco | 10.1 | 10.0 |
| crowdsec | 5.2 | 15.9 |
| apache2 | 3.6 | 5.9 |
| suricata | 2.5 | 2.1 |
| php-fpm | 1.5 | 13.9 |
| プロセス | CPU % | RAM % |
|---|---|---|
| suricata | 9.0 | 17.7 |
| falco | 5.5 | 15.6 |
| fail2ban-server | 2.5 | 16.4 |
| apache2 | 1.7 | 11.1 |
| clamd | 1.0 | 13.5 |
top が答えるのは今この一秒についての問いですが、実際に問われるのはたいてい昨夜のことです。なぜ午前三時にすべてが止まり、そして勝手に戻ったのか。その時点ではもう見るものが残っていません。どこにも記録されていないからです。かといって一台の VPS のために Prometheus と Grafana を立てるのも、それ自体が問題になります。観測する側のスタックが、観測される側のサーバーより重くなってしまうからです。
コレクターが五分ごとにデータベースへ一行ずつ書き足し、このページはそこから直近 24 時間を描きます。load average、I/O wait を分けて示した CPU 使用率、RAM と swap、ネットワークの受信と送信、ディスクの読み書き、確立済みの TCP 接続、プロセス、パーティションの使用量、inode とファイルディスクリプタの上限に対する割合、MySQL の接続数。すべて一つのページに、同じ時間軸で並ぶので、同時に起きた事柄が目で見て分かります。
これらのグラフは対で読むとよいでしょう。CPU が落ち着いているのに I/O wait が高いなら、サーバーはディスクを待っているのであり、コアを増やしても意味がありません。一度上がったきり零に戻らない swap は、いま静かに見えてもメモリのピークがすでに過ぎたことを語っています。百パーセントに近づいたファイルディスクリプタは、実際に too many open files が出る数時間前の姿です。そして多くのサーバーでは、空き容量よりずっと先に inode が尽きます。