Four Golden Signals
Це концепція з книги “Site Reliability Engineering” (Google SRE Book).
Основна ідея: замість того щоб моніторити все підряд (сотні метрик), фокусуйся лише на тому, що безпосередньо відображає досвід користувача.
1. Latency — час відповіді
Час обробки запиту від отримання до відповіді.
Важливо розділяти успішні запити від помилкових — помилка за 1ms не означає що система швидка.
Треба трекати перцентилі, а не середнє — середнє приховує аномалії:
| Перцентиль | Що показує |
|---|---|
| p50 | Медіана — “типовий” користувач |
| p95 | 95% запитів вкладаються в цей час |
| p99 | Найгірший досвід 1% користувачів |
2. Traffic — навантаження на систему
Міра того, скільки “роботи” зараз виконує система.
| Компонент | Метрика |
|---|---|
| HTTP API | RPS (requests per second) |
| Proxy (Squid/HAProxy) | Connections/s, bandwidth MB/s |
| База даних | Transactions/s, queries/s |
Без Traffic інші метрики втрачають сенс — ти не знаєш чому щось змінилось.
Приклади кореляції:
- Errors зросли з 10 до 100? — Якщо трафік теж зріс в 10 разів, це нормально. Якщо трафік той самий — alarm.
- Latency збільшилась? — Може просто прийшов spike навантаження.
3. Errors — частота помилок
Частота запитів, що завершились помилкою:
- Явні: HTTP 5xx, таймаути
- Неявні: відповідь 200, але з некоректним вмістом
4. Saturation — насиченість ресурсів
Наскільки ресурс вичерпаний — не просто “скільки використовується”, а скільки ще залишилось.
Ключова відмінність від utilization:
Utilization 80% CPU → є запас, система справляється
Saturation → є черга задач, що чекають на CPU → система вже деградує
Saturation — це випереджувальний сигнал. Система ще не падає, але вже “захлинається”.
Що моніторити
| Ресурс | Метрика насиченості |
|---|---|
| CPU | Load average / run queue length |
| RAM | Swap usage, OOM events |
| Disk | I/O queue depth, await time |
| Network | Interface errors, drops, TX queue |
| HAProxy | Connections queue (qcur) |
| Squid | File descriptors usage |
# HAProxy — черга з'єднань (якщо > 0 — вже saturation)
haproxy_backend_current_queue
# Linux — disk I/O saturation
node_disk_io_time_weighted_seconds_total # "pressure"
Навіщо: Це єдиний сигнал, який дає попередження до того, як система впаде. Latency і Errors — це вже наслідок. Saturation — це причина, яку ти бачиш раніше.
Як вони пов’язані між собою
Traffic зростає
↓
Saturation починає рости (ресурси заповнюються)
↓
Latency починає рости (черги, wait time)
↓
Errors починають рости (таймаути, відмови)
↓
Користувач відчуває деградацію
Ідеальний алерт — спрацював на Saturation, ти виправив до того, як дійшло до Errors.