Моніторинг сервера: Prometheus і Grafana на практиці

Моніторинг потрібен не для гарних графіків, а щоб дізнаватись про проблему раніше за клієнтів. Різниця між «сайт лежав годину вночі» і «сайт лежав до ранку, поки хтось не написав» — саме в ньому.

Три рівні спостереження

• Доступність. Найпростіше й найважливіше: сайт відповідає, віддає очікуваний код, сертифікат не протермінований. Це можна налаштувати за пів години.
• Ресурси сервера. Процесор, пам'ять, диск, мережа. Показує тенденцію — коли поточної конфігурації перестане вистачати.
• Прикладні метрики. Час відповіді, кількість помилок, черга воркерів, стан бази. Найкорисніше для діагностики, але потребує налаштування.

Що варто відстежувати для сайту

• Місце на диску — найчастіша причина раптових збоїв: закінчилось місце, база перестала писати.
• Пам'ять і момент, коли система починає вбивати процеси.
• Кількість зайнятих PHP-воркерів: якщо вони постійно всі зайняті, відвідувачі стоять у черзі.
• Час відповіді сервера в динаміці — щоб бачити деградацію до скарг.
• Помилки 5xx: різкий стрибок означає проблему просто зараз.
• Термін дії сертифіката.

Головне правило сповіщень

Сповіщення, на які перестають реагувати, гірші за їх відсутність. Якщо система шле десяток листів на день, за тиждень їх переносять у окрему теку й більше не відкривають.

Тому мінімум: сповіщення лише про те, що вимагає дії просто зараз, і різні канали для «важливо» та «критично». Решта лишається на графіках, які дивляться при розборі проблеми.

З чого почати

Не з розгортання складної системи. Спершу — проста перевірка доступності ззовні й сповіщення про падіння. Це закриває найбільший ризик. Повноцінний збір метрик має сенс, коли є що аналізувати: кілька серверів або регулярні проблеми з навантаженням.

Налаштування — моніторинг Prometheus та Grafana. У парі корисні централізовані логи і бекапи: моніторинг покаже проблему, логи пояснять причину, бекап дозволить відкотитись.