Моніторинг VPS без нагляду: як сервер кричить про допомогу, а ви цього не чуєте

Уявіть: ваш сервер горить. Не буквально, звісно, - але CPU на 98%, диск забитий логами, а RAM тріщить по швах. А ви дізнаєтесь про це від клієнта, який написав у підтримку: "Чому сайт не відкривається?" Знайомо? За моїм досвідом, 7 із 10 власників VPS дізнаються про проблеми саме так - від розлючених користувачів. Не від системи моніторингу, не від алертів у Telegram. Від людей, яким вже поламали нерви.

Моніторинг - це не розкіш для DevOps-інженерів з великих компаній. Це ваш цифровий стетоскоп. І якщо ви досі не прикладаєте його до грудей свого серверу, ця стаття покаже, де саме слухати і що робити з тим, що почуєте.

Чому "працює ж" - найнебезпечніша фраза в серверному світі

Є одна когнітивна пастка, в яку потрапляють навіть досвідчені адміни. Сервер працює. Сайти відкриваються. Все ок. А потім одного ранку все падає, і ви судорожно згадуєте, коли востаннє перевіряли вільне місце на диску.

Проблема в тому, що VPS деградує поступово. Це не вибух - це повільна ерозія. Диск заповнюється по 200 МБ на день. Пам'ять "підтікає" через забутий процес. З'єднання з базою даних накопичуються, як немиті тарілки в раковині. Кожна окрема проблема - дрібниця. Усі разом - катастрофа.

"Більшість серверних аварій - це не раптові події. Це накопичення ігнорованих сигналів протягом тижнів або місяців." - Tom Limoncelli, автор "The Practice of Cloud System Administration"

Без моніторингу ви керуєте автомобілем із заклеєною приладовою панеллю. Бензин є? Невідомо. Масло в нормі? Хто знає. Температура двигуна? Побачимо, коли піде дим.

П'ять метрик, які потрібно відстежувати вже сьогодні

Не треба моніторити все підряд - це шлях до "алерт-фатіги", коли сповіщень так багато, що мозок починає їх ігнорувати. Сфокусуйтесь на п'яти критичних метриках, і ви закриєте 90% потенційних проблем:

1. CPU Load Average - не плутайте з CPU usage. Load average показує чергу процесів, які чекають на процесорний час. Якщо значення перевищує кількість ядер вашого VPS - у вас проблема.
2. RAM + Swap - коли система починає активно використовувати swap, продуктивність падає в рази. Swap - це ваш диск, що прикидається пам'яттю. Уявіть бігуна з рюкзаком каміння.
3. Дисковий простір (і inode!) - класика жанру. Логи ростуть, бекапи накопичуються, тимчасові файли живуть вічно. Окремо стежте за inodes - можна мати вільне місце, але не мати можливості створити жоден файл.
4. Мережевий трафік - аномальні сплески вхідного трафіку можуть сигналізувати про DDoS. Сплески вихідного - про те, що ваш сервер розсилає спам без вашого відома.
5. Час відповіді сервісів - HTTP-відповідь за 3 секунди замість 200 мс? Це не "Інтернет гальмує". Це ваш сервер задихається.

Кожна з цих метрик - як індикатор на приладовій панелі. Одна жовта лампочка - нічого страшного. Три червоних одночасно - зупиняйтесь і відкривайте капот.

Інструменти: від безкоштовних до "бізнес-класу"

Гарна новина - вам не потрібно писати моніторинг з нуля. Погана - інструментів так багато, що вибір може паралізувати. Ось чесне порівняння найпопулярніших варіантів:

Мій особистий фаворит для старту - Netdata. Встановлюється однією командою, показує 2000+ метрик у реальному часі, має вбудовані алерти. Для одного-двох серверів - ідеально.

Якщо у вас 5+ серверів і виділені машини - переходьте на Zabbix або зв'язку Prometheus + Grafana. Так, налаштування займе день-два, але потім ви матимете повну картину інфраструктури в одному дашборді.

Алерти: як налаштувати, щоб не зійти з розуму

Ось парадокс моніторингу: надто мало алертів - і ви пропустите катастрофу. Надто багато - і ви почнете ігнорувати всі, включно з критичними. Це як хлопчик, що кричав "вовк!"

Золоте правило - три рівні серйозності:

• Info - логується, але не турбує вас. CPU тримався на 70% більше 5 хвилин? Записали. Працюємо далі.
• Warning - повідомлення в Telegram/Slack. Диск заповнений на 80%? Є час відреагувати. Не панікуємо, але плануємо дії.
• Critical - дзвінок, SMS, пуш. Сервіс не відповідає 3 хвилини? Все, підривайтесь. Навіть о третій ночі.

Ще одна порада, яку я виніс з болючого досвіду: налаштуйте гістерезис. Якщо поріг спрацювання алерту - CPU > 90%, то поріг зняття повинен бути, скажімо, CPU < 80%. Інакше при коливанні навантаження біля 90% ви отримаєте 47 повідомлень за годину. Повірте, ваш телефон цього не переживе.

Окремо скажу про канали доставки. Email для критичних алертів - погана ідея. Ви можете перевірити пошту через годину, а сервер вже лежить 55 хвилин. Telegram-бот + push-повідомлення - мінімум для серйозного проекту. PagerDuty з ескалаціями - для бізнесу, де даунтайм коштує грошей.

Виділений сервер: окремий звір з окремими потребами

Якщо VPS - це квартира в багатоповерхівці, то виділений сервер - приватний будинок. І моніторити його потрібно глибше. Тут ви відповідаєте за "залізо", яке може фізично зламатися.

Що додається до списку метрик для виділеного серверу:

• S.M.A.R.T.-статус дисків - жорсткі диски і навіть SSD попереджають про свою швидку смерть. Ігнорувати ці сигнали - як ігнорувати біль у грудях.
• Температура CPU і материнської плати - перегрів скорочує життя процесора і викликає раптові вимкнення. Критична межа для більшості серверних CPU - 85-90°C.
• Стан RAID-масиву - деградований RAID з одним вибитим диском - це бомба уповільненої дії. Другий диск може відмовити будь-якої миті.
• Апаратні помилки в dmesg - повідомлення про ECC-помилки пам'яті, помилки контролера дисків, проблеми з мережевою картою.

Для моніторингу "заліза" на виділеному сервері використовуйте IPMI/iLO/iDRAC - це вбудовані контролери управління, що дозволяють бачити стан компонентів навіть коли основна ОС вже не відповідає. Більшість провайдерів дають до них доступ - якщо не дали, попросіть.

Автоматичне реагування: коли моніторинг стає розумнішим за вас о 3 ночі

Бачити проблему - це половина справи. Друга половина - реагувати на неї, поки вона не переросла в аварію. І тут починається найцікавіше: автоматичне виправлення типових проблем.

Ось реальні сценарії, які можна автоматизувати за одну вечір:

1. Диск заповнений на 90% - скрипт автоматично чистить логи старші 7 днів, видаляє файли з /tmp, ротує великі лог-файли. Виграш часу: від кількох годин до "проблеми не було".
2. Nginx/Apache впав - systemd з параметром Restart=always перезапустить сервіс за секунди. Monit або Supervisord зроблять те саме, але з повідомленням вам.
3. RAM на межі - скрипт знаходить процес-пожирач і перезапускає його. Або скидає кеш (echo 3 > /proc/sys/vm/drop_caches) як тимчасовий захід.
4. Підозрілий трафік - Fail2ban автоматично блокує IP після N невдалих спроб входу. CrowdSec робить те саме, але з колективним інтелектом.

Важливий нюанс: автоматичне реагування повинно завжди повідомляти вас про свої дії. Інакше ви ніколи не дізнаєтесь, що проблема існує і що її треба вирішувати на кореневому рівні, а не латати скриптами.

Ваш сервер вже щось говорить. Питання - чи слухаєте ви

Моніторинг - це не проект на тиждень і не пункт у чекліст, який можна відмітити та забути. Це звичка. Як чистити зуби або перевіряти замок на дверях. Спершу незручно, потім автоматично, а через місяць ви не зможете уявити, як жили без цього.

Починайте з малого. Встановіть Netdata або Uptime Kuma прямо сьогодні - це 10 хвилин. Налаштуйте три базові алерти: диск, CPU, доступність сайту. Підключіть Telegram-бота. Ці 30 хвилин інвестицій можуть зекономити вам десятки годин аварійного розгрібання наслідків.

А тепер запитайте себе чесно: коли востаннє ви заходили на свій сервер просто перевірити, як він себе почуває? Якщо відповідь "давно" або "ніколи" - ваш сервер, можливо, вже кричить. Просто ви ще цього не знаєте.