Продуктивність

Історія навантаження сервера: 24 години, 7 або 30 днів (збір — раз на 5 хвилин)

Load Average (1m)
1.51
CPU
5.1%
RAM
31.3%
ESTABLISHED
57
Процеси
3 / 445
На цьому періоді показано середні значення за годинами, а не окремі заміри.
Load Average
CPU
Пам’ять
Мережа (KB/s)
Диск I/O (KB/s)
TCP-з'єднання
Диск і ліміти (%)
MySQL
Процеси в останньому замірі 00:40
Процес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
Процеси в момент піку за добу 11.10 08:20 · load 2.74
Процес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

Історія навантаження сервера без Prometheus і Grafana

Команда top відповідає на питання про поточну секунду, а питають зазвичай про минулу ніч: чому о третій усе стало й повернулося саме. На той момент дивитися вже нема на що — дані ніде не збереглися. Розгортати заради одного VPS зв'язку Prometheus і Grafana теж сумнівно: стек, що спостерігає, виходить важчим за сервер, за яким спостерігають.

Збирач раз на п'ять хвилин дописує рядок до бази, а сторінка малює за ним останню добу. Load average, завантаження CPU й окремо I/O wait, RAM і swap, прийом і передача мережею, читання та запис диска, кількість встановлених TCP-з'єднань, процеси, заповнення розділу, inodes і файлові дескриптори у відсотках від ліміту, з'єднання MySQL. Усе на одній сторінці й в одному масштабі часу, тож збіги видно оком.

Читати ці графіки варто парами. Високий I/O wait при спокійному CPU означає, що сервер чекає на диск, і додавати процесорних ядер марно. Swap, який одного разу виріс і не повернувся до нуля, каже, що пік пам'яті вже стався, навіть якщо зараз усе виглядає спокійно. Дескриптори, що підійшли до ста відсотків, — це майбутня помилка too many open files за кілька годин до того, як вона трапиться. А inodes на більшості серверів закінчуються помітно раніше за вільне місце.