История на натоварването на сървъра: 24 часа, 7 или 30 дни (събиране — веднъж на 5 минути)
| Процес | 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 отговаря на въпрос за текущата секунда, докато въпросът, който наистина се задава, е за изминалата нощ: защо в три сутринта всичко спря и се върна само. Дотогава вече няма какво да се гледа, защото нищо не е било записано. Да вдигнеш Prometheus и Grafana заради един-единствен VPS също е съмнително: наблюдаващият стек тежи повече от наблюдавания сървър.
Събирачът добавя по един ред в базата на всеки пет минути, а тази страница чертае от тях последното денонощие. Load average, натоварване на CPU с отделно показан I/O wait, RAM и swap, входящ и изходящ мрежов трафик, четене и запис на диска, установени TCP връзки, процеси, запълване на дяла, inode-и и файлови дескриптори в проценти от лимита им, връзки към MySQL. Всичко на една страница и по една времева ос, така че съвпаденията се виждат с просто око.
Тези графики си струва да се четат по двойки. Висок I/O wait при спокоен CPU означава, че сървърът чака диска, и добавянето на ядра няма да помогне. Swap, който веднъж е нараснал и никога не се е върнал до нулата, казва, че пикът на паметта вече е бил, колкото и спокойно да изглежда сега. Файлови дескриптори близо до сто процента са too many open files няколко часа преди грешката да се случи. А на повечето сървъри inode-ите свършват доста преди свободното място.