Моніторинг для команди з трьох: мінімум, який справді працює
Мала команда зазвичай має два стани моніторингу: немає нічого, або є дашборд, у який ніхто не дивиться. Обидва означають одне — про падіння ви дізнаєтесь від користувача. Ось мінімум, який змінює це за один день.
Чотири сигнали, з яких варто почати
Не «зберемо всі метрики», а чотири, які відповідають на питання «чи працює продукт»:
- Доступність зовні. Проба з іншої машини на головну сторінку. Якщо вона не відповідає, решта метрик неважлива.
- Частка помилок. Відсоток відповідей 5xx. Не абсолютна кількість — вона росте разом із трафіком.
- Латентність по перцентилю. p95, не середнє. Середнє ховає саме тих користувачів, яким погано.
- Довжина черги. Якщо фонові задачі накопичуються, лист про заявку прийде завтра, і формально все «працює».
Зовнішня проба — найдешевший сигнал
Внутрішній health-check не бачить впалого nginx, простроченого сертифіката й помилки в DNS. Проба ззовні бачить усе це одразу. Достатньо запиту раз на хвилину з фіксацією коду відповіді й часу.
Зберігайте не кожну пробу, а денний підсумок: скільки успішних, скільки повільних, скільки провалених. Тоді 90 днів історії — це 90 рядків на сервіс, а не сотні тисяч, і сторінка статусу будується миттєво.
Інцидент замість потоку алертів
Головна причина, чому алерти перестають читати: одне падіння генерує сорок повідомлень. Лікується моделлю інциденту: коли сервіс уперше перестав відповідати — відкриваємо інцидент і надсилаємо одне сповіщення. Поки він відкритий — мовчимо. Коли відновився — надсилаємо друге.
Два повідомлення на подію замість сорока. Це різниця між алертами, які читають, і алертами, для яких зробили окрему папку.
Алерт, на який ніхто не реагує, гірший за відсутність алерту: він створює відчуття, що ви під контролем.
Канали
Три штуки, і кожен має свою роль:
- Месенджер (Telegram, Slack) — те, що треба побачити зараз. Тільки інциденти.
- Пошта — те, що можна прочитати ввечері: тижневий підсумок, вичерпані спроби відправки, аномалії.
- Сторінка статусу — те, що читає клієнт замість того, щоб писати вам.
Метрики й помилки
Prometheus-ендпоїнт у застосунку — це десяток рядків, і він дає латентність, помилки й довжину черги без зовнішніх сервісів. Навіть якщо у вас поки немає Prometheus, ендпоїнт краще додати одразу: коли він знадобиться, це буде найгірший момент щось інтегрувати.
Окремо — збір помилок зі стектрейсом. Логи контейнера гортати неможливо, а сортування «однакових помилок за частотою» економить години. Sentry або сумісний із ним самохост — питання бюджету, не архітектури.
Одне правило
Кожен алерт має відповідати на питання «що я маю зробити просто зараз». Якщо відповіді немає — це не алерт, а метрика для дашборда. Дотримання цього правила зберігає моніторинг живим довше, ніж будь-який інструмент.
- Зовнішня проба бачить те, чого не бачить внутрішній health-check
- Денні підсумки замість кожної проби — 90 днів історії в 90 рядках
- Модель інциденту: два повідомлення на подію замість сорока
- Алерт без відповіді на «що робити зараз» — це метрика, а не алерт
Сам сервер — не обов’язково одразу. Ендпоїнт із метриками варто додати відразу: це десяток рядків, і він знадобиться саме тоді, коли інтегрувати щось буде найгірше.
Денних підсумків за 90 днів вистачає і для сторінки статусу, і для розмови про SLA. Сирі проби зберігати немає сенсу — вони ростуть нескінченно і нічого не додають.
