Prometheus + Grafana — моніторинг сервера та додатку

Моніторинг сервера на Prometheus і Grafana

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

Що налаштовую

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

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

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

Найкорисніша метрика

За досвідом — місце на диску. Найчастіша причина раптових збоїв не атака й не навантаження, а банально закінчилось місце: база перестала писати, сайт віддає помилки. Сповіщення на 80% заповнення закриває цей ризик повністю.

З чого почати, якщо бюджет обмежений

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

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