Производителност

История на натоварването на сървъра: 24 часа, 7 или 30 дни (събиране — веднъж на 5 минути)

Load Average (1m)
2.40
CPU
11.6%
RAM
31.8%
ESTABLISHED
42
Процеси
3 / 419
За този период се показват средни стойности по часове, а не отделните измервания.
Load Average
CPU
Памет
Мрежа (KB/s)
Диск I/O (KB/s)
TCP връзки
Диск и лимити (%)
MySQL
Процеси при последното измерване 02:41
ПроцесCPU %RAM %
apache2 13.5 6.6
falco 9.2 4.1
mysqld 6.0 7.4
php-fpm 4.4 6.4
fail2ban-server 2.9 13.1
Процеси при пика за денонощието 11.10 08:56 · load 3.61
ПроцесCPU %RAM %
mysqld 18.0 7.1
apache2 8.1 1.6
crowdsec 3.9 1.5
fail2ban-server 2.6 3.5
suricata 1.6 2.7

История на натоварването без Prometheus и Grafana

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-ите свършват доста преди свободното място.