Справжній тест моніторингу — не дашборди
Будь-яка команда вміє робити дашборди. Справжній тест системи моніторингу — 3-я ночі, коли спрацював pager: інженер знає, що робити, чи перші 20 хвилин блукає неактуальними графіками? Якщо друге — ваш моніторинг театр.
Цей посібник — структурований огляд моніторингу, що не кричить «вовк»: чотири золоті сигнали як фундамент, SLI/SLO/error budgets простою мовою, правила гігієни алертів і чеклист аудиту для того, що вже є.
План
- Чотири золоті сигнали
- SLI, SLO та error budgets без жаргону
- Гігієна алертів — правила, що захищають людей
- Логи vs метрики vs трейси: коли що
- Синтетичний моніторинг та RUM
- Вибір стеку
- Розумний on-call у малій команді
- Чеклист аудиту наявного моніторингу
1. Чотири золоті сигнали
Для кожного user-facing сервісу спершу міряйте лише ці чотири:
- Latency — час обслуговування успішного запиту. p50, p95, p99.
- Traffic — запити на секунду або бізнес-еквівалент (замовлення/хв).
- Errors — провалені запити як rate, з розбивкою за категорією.
- Saturation — наскільки заповнена система (CPU, RAM, глибина черги, пули).
Ці чотири добре — і ви покрили 80 % інцидентів. Інфраструктурні метрики (диск, мережа, host) додавайте лише коли вони справді прогнозують бізнес-вплив.
2. SLI, SLO і error budgets простою мовою
- SLI — що ви міряєте: «% запитів < 300 мс».
- SLO — ціль: «99,5 % запитів < 300 мс за 30 днів».
- Error budget — скільки можна витратити: 0,5 % у цьому прикладі.
Error budget — не покарання. Це явний trade-off між надійністю і швидкістю фіч. Спалили бюджет — заморожуєте випуски і вкладаєте в стабільність — рішення керівництва, а не драма інженера.
3. Гігієна алертів — правила, що захищають людей
- Кожен alert потребує runbook. Інакше — це тікет.
- Кожен alert будить людину або йде в backlog. Третьої категорії немає.
- Алерти на rate-of-change замість фіксованих порогів, де baseline чисті.
- Алерти на симптоми перед причинами. «Сервіс не відповідає» б'є «CPU > 80 %».
- Щотижня переглядайте топ-5 найгаласливіших — три тюнте або вимикайте.
Команда з двома реальними actionable інцидентами на тиждень здоровіша за команду з 30 page шуму.
4. Логи vs метрики vs трейси
| Сигнал | Найкраще для | Найгірше для |
|---|---|---|
| Метрики | Alerting, SLO, дашборди | Чому конкретний запит провалився |
| Логи | Форензика, аудит, debug | Дашборди високої кардинальності (вартість вибухає) |
| Трейси | Root cause латентності між сервісами | Дешеве довге зберігання |
Не логуйте те, що має бути метрикою. Не трейсіть те, що має бути логом.
5. Синтетичний моніторинг та RUM
Синтетичний (скриптові перевірки ззовні щохвилини) ловить падіння і прострочені сертифікати до того, як побачить користувач. RUM каже, що користувач справді переживає — повільні мережі та старі браузери, яких у стейджі немає.
Запускайте обидва. Алертте з синтетичного. Розслідуйте через RUM.
6. Вибір стеку
Єдино правильного стеку немає. Чесна матриця:
- Prometheus + Grafana + Loki + Tempo — найкращий TCO для команд з одним інженером, який любить це експлуатувати. Найгірший — для тих, кому не любить.
- Zabbix — сильний для важко-інфраструктурних середовищ, on-premise, мішаних парків Linux/Windows. Слабший в application-observability.
- Datadog / New Relic / Dynatrace — найшвидший time-to-value, високий ціник, lock-in через data model. Часто правильний для 20–100 осіб, які не хочуть експлуатувати платформу.
- Hyperscaler-native (CloudWatch, Azure Monitor, GCP Cloud Monitoring) — зручно, слабше cross-cloud або cross-on-prem.
Три критерії: TCO на 3 роки (з часом інженера), портативність даних, чи on-call дійсно хоче ним користуватися.
7. Розумний on-call у малій команді
- Мінімум двоє інженерів on-call. Один — людський SPOF.
- Primary ротується щотижня. Secondary прикриває primary. Без 24/7-героїв.
- Передача в понеділок: відкриті інциденти, найгаласливіші алерти, що фіксити цього тижня.
- Політика компенсації письмово.
- Після кожного інциденту — п'ятирядковий blameless postmortem у спільних docs.
8. Чеклист аудиту наявного моніторингу
- Чи є чотири золоті сигнали для кожного user-facing сервісу?
- Чи має кожен активний alert письмовий runbook?
- Тижневий обсяг алертів vs інциденти, що вимагали людини?
- Коли востаннє успішно відпрацював синтетичний моніторинг вашого критичного flow?
- Логи і метрики в одному місці (хоч у тому ж UI)?
- Ваш інструмент коштуватиме скільки треба за 12 місяців при прогнозованому зростанні?
- Чи ротація on-call задокументована, оплачена і без SPOF?
Якщо хоч одне не можете відповісти одним реченням — там і починати.
Ключові висновки
- Будуйте на чотирьох золотих сигналах, не на інфраструктурній дрібниці.
- Error budget — розмова керівництва про швидкість vs надійність.
- Кожен alert потребує runbook і дії; решта — тікет.
- Логи, метрики і трейси доповнюють одне одного — не замінюють.
- Вибір інструменту — рішення TCO на 3 роки, не чекбокс фіч.
Якщо хочете зовнішній огляд вашого моніторингу по цьому чеклисту — зв'яжіться. Говоритимете з інженером, не з продавцем.