Як аналізувати навантаженість VPS-сервера?

Bпав сервер? Що робити, які метрики дивитись? Як знайти і зрозуміти джерело походження проблеми. Огляд стандартних інструментів, сервісів, команд і утиліт для аналізу навантаженості VPS-серверів під управлінням ОС Linux.

Аналіз системних процесів

Якщо ситуація дозволяє, то перше з чого варто почати — перевірити фонові системні процеси, аби зрозуміти на яких сервісах відбувся перегруз.

Утиліта Top

З допомогою утиліти top (від англ. table of processes) можна швидко викликати таблицю процесів. Вона є своєрідним аналогом “Диспетчера задач” у Windows. Наглядно демонструє: хто і скільки споживає ресурсів. Також варто звернути увагу на рядок Load Average — там буде три цифрових значення, що означають середнє навантаження на VPS за 1, 5 і 15 хвилин. Чим нижче ці показники — тим краще. Їх співвідношення вираховується відповідно до кількість ядер процесора. Наприклад, якщо у вас одноядерний CPU, а Load Average показав 1,1,1, то це значить навантаження на 100%. Відповідно, якщо значення LA 2,2,2 для двоядерного — аналогічна ситуація. Load Average можна подивитися окремо командою терміналу: cat /proc/loadavg.

Гарячі клавіші (hot keys) утиліти TOP:

• 1 — Статистика відображення на всіх ядрах процесора;
• M — сортувати за навантаженням на оперативну пам’ять;
• P — Сортувати за навантаженням на CPU;
• Shift + T — Сортувати за часом (дозволяє зрозуміти, який з процесів він триває довше);
• Shift + N — Сортувати за ідентифікаційним номером PID;
• Shift + F — поле вибору поля (ми знаходимо потрібний індикатор та виправлення клавіш D у таблиці);
• n — змінити кількість переміщених процесів (команда попросить вас ввести номер);
• S — інтервал оновлення змін;
• C — вивести всі варіанти та аргументи в таблиці;
• = — скидання фільтрів;
• K — знищити процес (команда попросить вас вказати процес PID);
• R — змінити пріоритет процесу;
• Z — змінити колір підсвічування процесів;
• Bakspace — оновлення;
• h — довідка;
• Q — вихід.

Швидкі команди:

• top -n 1 — одноразово отримати статистику;
• top -n 5 — запустить почергово 5 оновлень статистики;
• top -u username — показати статистику споживання ресурсів для заданого користувача системи;
• top -n 1 -b > output.txt— експортувати вивід команди в файл;

Утиліта TOP має безліч аналогів (форків), наприклад — ATOP, HTOP, VTOP, MYTOP, PowerTop та ін. За замовчуванням вони не включаються до Linux і повинні бути встановлені окремо.

Bashtop

Вдосконалений форк утиліти TOP, який виводить комплексну статистику. Bashtop швидко встановлюється і характеризується чудовою інформативністю. Особливо сподобається естетам — уся статистика відстежується в реальному часі, зібрана на одному псевдографічному дашборді й розділена на різні блоки:

З допомогою bashtop дуже легко “тримати руку на пульсі” сервера. Завше усе під рукою. У будь-який момент можна відкрити і подивитись, що на фоні. За потреби можна також перейти в меню й обрати необхідний режим:

Ps

Ще одна службова утиліта для моніторингу запущених процесів. Може застосовувати для цифрової форензики, реверс-інженерії.

Приклади команд:

• ps -A — вивід усіх процесів;
• ps -x — вивів усіх процессов, які належать поточному користувачу;
• ps -U root -u root — вивід усіх процесів з правами заданого користувача, наприклад root;
• ps -e --forest — дерево процесів;
• ps -eM — список запущених процесів у контексті безпеки, із вказаними LABEL, PID, TTY, TIME, CMD;
• ps -p 22813 — вивід статистики по окремому процесу за вказаним ідентифікатором PID.

Комбінована команда, яка виводить ТОП-10 процесів, які навантажують систему:

ps axo rss,comm,pid \
| awk '{ proc_list[$2]++; proc_list[$2 "," 1] += $1; } \
END { for (proc in proc_list) { printf("%d\t%s\n", \
proc_list[proc "," 1],proc); }}' | sort -n | tail -n 10 | sort -rn \
| awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}'

Аналіз оперативної пам’яті

Іншою проблемою, чому може падати сервер — це відсутність необхідного резерву оперативної пам’яті. Трафік на сайті може коливатися стрибкоподібно, і в залежності від відвуваності, у потрібний момент сервер просто використає усі ресурси. Тому, варто дивитися оперативку. Часто проблема вирішується просто її збільшенням, тобто масштабуванням VPS-сервера.

Free

Класична утиліта командного рядка Linux. Виводить статистику використання оперативної пам’яті в системі (базуючись на даних з cat /proc/meminfo):

Тут варто звертати увагу на значення:

• total — повний об’єм оперативної пам’яті;
• used — показує скільки використано оперативної пам’яті;
• free — показує кількість вільної (невикористаної) оперативки;
• shared — оперативна пам’ять, яка розшарюється з системними службами, програмами, процесами;
• buff/cache — зарезервована (буферна) оперативна пам’ять для кешу;
• available — орієнтовна кількість доступної оперативної пам’яті для запуску нових процесів/програм/додатків;
• Swap — віртуальна оперативна пам’ять, тобто файл підкачки, або SWAP-файл.

Дуже часто буває, коли SWAP-файл не налаштований і дорівнює нулю, як показано на скрішноті. Це означає, що при високих навантаженнях система не буде мати де черпати запас і сервер відразу впаде. Якщо SWAP виділений і правильно налаштований — то сервер може протриматися довше, або навпаки збалансується.

Аби виводити статистику у зрозумілішому вигляді, варто застосувати ключ:

free -h

Швидкі команди утиліти Free:

• free -s 5 — оновлювати статистику що 5 хвилин;
• free -w — розширений вивід команди;
• free -h -l — статистика по найбільш високим та низьким значенням;
• free -h -t — вивід загального значення по використанню пам’яті;
• free -h -c2 -s60 — команда виконається вказане число раз із s затримкою;
• free -V — виводить поточну версію програми;
• free --help — довідка.

Аналіз файлової системи

Ще одна причина, чому може впасти сервер — забиті диски. Тимчасовими файлами (tmp), кешами, логами.

Df

Команда df виведе на дисплей статистику по всім дисковим накопичувачам та їх розділам:

Швидкі команди Df:

• df -h — виведе статистику в Мб/Гб;
• df -T — відобразить додатково тип файлової системи;
• df -hT /home/dirname/ — відобразить статистику для заданої директорії.

Du

Du (disk usage) — стандартна утиліта Linux для оцінки дискового простору. Дозволяє підрахувати місце для будь-якої директорії.

Швидкі команди утиліти Du:

• du -hs /* — вивід на екран розмір усіх директорій;
• du -sh — підрахувати скільки займає активний каталог;
• du -s Downloads — підрахувати скільки займає місця заданий каталог.

Аналіз системних логів (журналів)

Ось ми і підібралися до найцікавішого. Фактично, можна було спочатку перевірити логи, а потім все решта. Але ця операція забирає більше всього часу та уважності, тому, як говориться, залишив “найсмачніше на потім”.

Log-файли — це історична хроніка вашого VPS-сервера. Файли, які реєструються будь-які події на сервері. Фактично, логи це — офіційний документ, з яким ви можете навіть звернутися до суду, у разі несанкціонованого втручання в роботу вашого сервера. У 90% випадках саме логи дають можливість знайти першопричину усіх навантажень, адже вони містять усі запити до вашого сервера.

Системні журнали (логи) сервера діляться на два файли:

1. Access.log —це журнал відвідуваності, логи усіх звернень, запитів і зовнішніх переходів на сервер або ресурс. Показує час і дату звернення (dd/mm/yyyy: hh:mm:ss), тип і протокол (/його версію) запита (GET/HTTP), код відповіді сервера (200/301/404/504 і т.д.), IP-адресу або ім’я хоста/доменв, з якого відбувся захід, кількість переданих байтів, User-Agent браузера/клієнта/бота, а також іноді геодані (якщо збір такої інформації включено на сервері). Для сервера Apache логи відвідуваності зберігаються в : /var/log/apache2/access.log Для сервера Nginx: /var/log/nginx/access.log
2. Error.log — це журнал помилок, які виникали під час відвідуваності сервера. У ньому вказані дата і час, тип помилки (Notice/Warning/Fatal), джерело помилки (назва модуля, компонента, бібліотеки, який видав помилку), URL-адреса сторінки/файлу/ресурсу, на якому була зареєстрована помилка, IP-адреса клієнта, при запиті якого була показана помилка. Для сервера Apache логи помилок зберігаються в файлі: /var/log/apache2/error.log Для сервера Nginx: /var/log/nginx/error.log

Частенько, логи наочно демонструють як ті чи інші шкідливі боти (Bad Bots) вбивають сайт великою кількістью HTTP-запитів, намагаючись спарсити/вкрасти чужий контент. Особливо від цього страждають незахищені, слабкі сервери із застарілим програмним забезпеченням. Як протидія їм — перехід на CDN/DNS сервіс Cloudflare. Альтернативний варіант — прописати правила індексування сайту в файлі Robots.txt, використовуючи директиву Disallow (заборона) або Crawl-Delay (затримка).

Інші системні логи

У папці /var/log можна найти цілий ряд інших корисних логів, наприклад:

• /var/log/php-fpm.log — аналіз логів PHP;
• /var/log/syslog — глобальний системний журнал Linux;
• /var/log/lastlog —останні входи в систему;
• /var/log/auth.log — журнали авторизація, включно з усіма спробами входу на сервер;
• /var/log/btmp — журнал невдалих спроб входу на сервер;
• /var/log/wtmp — ще один журнал входів в систему.

Решту журналів, наприклад логи хостинг-панелі, або поштового сервера, можна знайти також в директорії: /var/log.

Аналіз бази даних

Черговою поширеною проблемою, котра впливає на стабільність сервера є сильне навантаження на базу даних, або некоректно налаштована база даних.

Логи помилок MySQL-бази даних можна знайти в файлі: /var/log/mysql/error.log

Для відлагодження проблем з базою даних можна створити так-званий Журнал повільних запитів (задавши права доступу mysql:mysql) і вказати його у файлі конфігурації MySQL: /etc/mysql/my.cnf У блок [mysqld] необхідно додати наступні рядки:

• slow_query_log=1 – увімкнення журналу повільних запитів;
• slow_query_log_file=/var/log/mysql/mysql-slow.log – расположение файла журнала;
• long_query_time=5 – заданий критерій повільних запитів, в секундах;
• log-queries-not-using-indexes – правило враховувати запити без індексу.

Аби зміни вступили в силу необхідно перезапустити MySQL-сервер: sudo systemctl restart mysql

Тепер, щоби переглянути журнал повільних запитів виконайте команду: sudo tail -f /var/log/mysql/mysql-slow.log

Може виникнути ситуація, коли файл журналу повільних запитів розростеться до неймовірних розмірів. У такому випадку, краще застосовувати утиліту mysqldumpslow:

• mysqldumpslow /var/log/mysql/mysql-slow.log
• mysqldumpslow -t 5 -s /var/log/mysql/localhost-slow.log – вивід перших 5-ти повільних запитів, відсортованих за часом виконання

Ще одна утиліти для читання логів повільних SQL-запитів — pt-query-digest. Вона входить в склад Percona Toolkit — популярний набір інструментів з обслуговування БД.

Не зайвим буде окремо протестувати роботу SQL-бази даних з допомогою утиліти MySQLTuner — вона наочно продменструє “що не так”. Пам’ятайте, хибно налаштована база даних — головне джерело нестабільності та проблем VPS-сервера.

Аналіз повідомлень ядра Linux

Якщо на попередніх етапах проблему усе ще не вдалось ідентифікувати, то можливо вона криється на рівні ядра. Переглянути повідомлення ядра Linux можна з допомогою утиліти DMESG — дозволяє дізнатись, що робиться “за кадром”. Щохвилини ядро Linux генерує нові повідомлення, які потрапляють в буфер, а вже звідти DMESG їх дістає й виводить на екран. В процесі комплексної діагностики та форензики ця команда може видатися дуже корисною:

• dmesg | tail#вивід останніх 10-ти повідомлення дра Linux;
• dmesg -H — вивыд повідомлень ядра у зручному вигляді з підсвідкою;
• dmesg --level=emerg,alert,crit,err,warn #вивід тільки найважливіших повідомлень ядра;
• dmesg -u #вивід усіх повідомлень з блоку користувача системи.

Аналіз історії операцій

До журналів, я б також відніс історію команд, виконаних у Bash-терміналі (консолі Linux) користувачами системи. Вона зберігається в файлі .bashrc або .bash_history. Адміни рідко туди заглядають, але часто саме там можна зафіксувати будь-які таємні несанкціоновані дії на сервері.

Щоб переглянути історію останніх виконаних команд треба запустити:history

Логи WordPress

Окремо хочу згадати про системні логи CMS WordPress, якою багато-хто користується в наш час. За статистикою, майже 80% сайтів в інтернеті виконаній на ній.

Найперше потрібно увімкнути запис логів в файлі конфігурації wp-config.php:

• define( 'WP_DEBUG', true );
• define( 'WP_DEBUG_DISPLAY', false ); – приховання помилок від відвідувачів;
• define( 'WP_DEBUG_LOG', true );

Тепер усі логи будут записуватися у файлі /wp-admin/debug.log.

Тільки не забудьте обмежити доступ до них для всіх бажаючих в інтернеті. Інакше вони стануть публічними (!).

Автоматизовані системи обробки та аналізу логів

Ну, і не можу забути про інструменти, які допомагають автоматизувати обробку і прочитання log-файлів.

Нижче подано список безкоштовних та найбільш ефективних:

• GoAcces — популярна утиліта командного рядка Linux для оперативної обробки та аналізу системних журналів, а також підготовки візуально-привабливих, інформативних звітів на їх основі;
• SEP Screaming Frog Log Analyser — кросплатформна програма від широко відомого SEO-виробника Screaming Frog. Утиліта проста, зі зручним і зрозумілим інтерфейсом, її під силу опанувати кожному;
• Logwatch — ще одна зручна утиліта для прочитання логів та підготовки звітів, які програма може надсилати на електронну пошту;
• Webalizer — програма-ветеран log-file аналізу, існує ще з 1997 року, входить у склад деяких хостинг-панелей;
• Elastic Logstash — безкоштовний професійний лог-аналізатор Premium-рівня з широким набором функцій та інтеграцій.

Централізовані системи моніторингу

Переважно застосовуються в корпоративних системах зі складною й розгорнутою інфраструктурою та мережею або різних трафікових проєктах, коли звичайних лог-аналізаторів буде замало, та й фізично неможливо ними усе охопити.

• Grafana — open source система моніторингу, яка візуалізує і виводить усі дані на численні дашборди, які можна створити на базі різних серверів, логів, метрик. Програма гнучка. Уміло сортує зібрану статистику і гарно візуалізує їх;
• Kibana — ще одна професійна система моніторингу, збору і візуалізації даних, яка входить у стек ELK (Elastic + Logstash + Kibana). Подібно Графані, підійде для габаритних IT/VPS/Cloud інфраструктур, проєктів, систем;
• Zabbix — більш легка і популярна система моніторингу комп’ютерних мереж, серверів, хмарних Cloud-платформ.

Автор: © Konrad Ravenstone, KR. Laboratories Research