Історія навантаження сервера: 24 години, 7 або 30 днів (збір — раз на 5 хвилин)
| Процес | CPU % | RAM % |
|---|---|---|
| apache2 | 10.1 | 13.5 |
| fail2ban-server | 7.5 | 1.9 |
| mysqld | 4.4 | 2.1 |
| php-fpm | 2.1 | 11.3 |
| falco | 1.1 | 16.8 |
| Процес | CPU % | RAM % |
|---|---|---|
| crowdsec | 10.3 | 12.4 |
| falco | 5.3 | 3.1 |
| mysqld | 3.3 | 7.0 |
| suricata | 1.6 | 2.3 |
| php-fpm | 1.1 | 0.7 |
Команда 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 на більшості серверів закінчуються помітно раніше за вільне місце.