| プロセス | 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 を立てるのも、それ自体が問題になります。観測する側のスタックが、観測される側のサーバーより重くなってしまうからです。
コレクターが五分ごとにデータベースへ一行ずつ書き足し、このページはそこから直近 24 時間を描きます。load average、I/O wait を分けて示した CPU 使用率、RAM と swap、ネットワークの受信と送信、ディスクの読み書き、確立済みの TCP 接続、プロセス、パーティションの使用量、inode とファイルディスクリプタの上限に対する割合、MySQL の接続数。すべて一つのページに、同じ時間軸で並ぶので、同時に起きた事柄が目で見て分かります。
これらのグラフは対で読むとよいでしょう。CPU が落ち着いているのに I/O wait が高いなら、サーバーはディスクを待っているのであり、コアを増やしても意味がありません。一度上がったきり零に戻らない swap は、いま静かに見えてもメモリのピークがすでに過ぎたことを語っています。百パーセントに近づいたファイルディスクリプタは、実際に too many open files が出る数時間前の姿です。そして多くのサーバーでは、空き容量よりずっと先に inode が尽きます。