Monitoring та Alerting

частка відповідей із кодом 5xx;

Для ресурсів і залежностей також важливі:

• використання CPU та пам’яті;

• кількість з’єднань до бази даних;

• довжина черги;

• кількість повторних спроб;

• доступність зовнішніх залежностей;

• насичення пулів потоків або з’єднань.

Метрики, логи та трасування

Ці типи телеметрії доповнюють один одного.

Метрики — числові часові ряди. Вони добре підходять для:

• побудови графіків;

• виявлення трендів;

• автоматичних alert-ів;

• оцінювання SLO.

Логи — окремі події з контекстом. Вони допомагають з’ясувати:

• який запит завершився помилкою;

• з якими параметрами він виконувався;

• яка саме помилка виникла;

• який ідентифікатор запиту використовувався.

Трасування показує шлях одного запиту через кілька сервісів. Воно корисне, коли загальна затримка відома, але незрозуміло, яка залежність її спричинила.

Практичний порядок аналізу інциденту часто виглядає так:

1. Метрика показує симптом.

2. Логи допомагають знайти конкретні помилки.

3. Трасування показує проблемну ділянку запиту.

Спочатку визначте, що вважається проблемою

Alert не повинен бути довільним порогом на графіку. Його варто пов’язати з очікуваною поведінкою системи.

Наприклад, для API можна визначити:

• доступність не нижче 99,9%;

• частка помилок не більше 1%;

• 95-й перцентиль затримки не більше 500 мс;

• повідомлення з черги обробляються не довше 2 хвилин.

Ці цілі називають SLO — Service Level Objective.

Показник, за яким вимірюють SLO, називають SLI — Service Level Indicator.

Приклад:

• SLI: частка успішних HTTP-запитів;

• SLO: не менше 99,9% успішних запитів за 30 днів.

Alert має сигналізувати не просто про незвичне значення, а про ризик порушення SLO або про стан, який уже впливає на користувачів.

Симптоми проти причин

Найнадійніші alert-и зазвичай описують симптом, а не внутрішню причину.

Симптом:

Частка помилок API перевищує допустиме значення протягом 10 хвилин.

Можливі причини:

• база даних недоступна;

• помилка в новому релізі;

• зовнішній сервіс повертає помилки;

• вичерпано пул з’єднань;

• неправильна конфігурація.

Якщо створити окремий alert на кожну можливу причину, під час одного інциденту можна отримати десятки сповіщень. Alert на симптом дає змогу побачити вплив, а додаткові метрики та логи використовуються для діагностики.

Причинні alert-и все ж корисні, якщо вони:

• вимагають іншої термінової дії;

• стосуються критичного ресурсу;

• дозволяють виявити проблему до появи користувацького впливу.

Які alert-и справді потрібні

Хороший alert має відповідати чотирьом умовам:

1. Він важливий. Проблема впливає на користувачів, дані або надійність системи.

2. Він терміновий. Реакцію не можна відкласти до планового аналізу.

3. Він достатньо точний. Нормальна поведінка не породжує постійних сповіщень.

4. Він спонукає до дії. Черговий інженер розуміє, що робити далі.

До кожного alert варто додати:

• короткий опис проблеми;

• сервіс і середовище;

• рівень критичності;

• поточне значення;

• посилання на дашборд або інструкцію, якщо такі є;

• початкові кроки діагностики;

• умову автоматичного завершення alert-а.

Наприклад, повідомлення:

HighErrorRate для payments-api у production: 8,4% відповідей 5xx протягом 10 хвилин. Перевірити останній реліз, доступність бази даних і помилки залежностей.

значно корисніше, ніж:

Error rate high.

Рівні критичності

Кількість рівнів має бути невеликою. Наприклад:

• critical — потрібна негайна реакція; є значний вплив на користувачів або ризик втрати даних;

• warning — проблема потребує уваги, але не обов’язково нічної реакції;

• info — інформаційна подія, яка зазвичай не повинна переривати роботу.

Не слід надсилати warning у той самий канал і з тією самою терміновістю, що й critical. Інакше черговий інженер почне ігнорувати всі повідомлення.

Приклад правил Prometheus

Нижче наведено приклад правил для сервісу, який експортує стандартні метрики HTTP-запитів:

• http_requests_total;

• http_request_duration_seconds_bucket.

Правила перевіряють частку помилок і 95-й перцентиль затримки. Параметр for захищає від коротких сплесків.

Вираз для частки помилок обчислює:

Період for: 10m означає, що умова має залишатися істинною 10 хвилин. Короткий сплеск помилок не створить alert.

Під час використання таких правил потрібно переконатися, що:

• усі метрики мають однакові потрібні мітки;

• лічильник запитів справді містить статус відповіді;

• знаменник не дорівнює нулю;

• latency записується як histogram із bucket-ами;

• високі значення severity справді відповідають процесу чергування.

Як уникати шуму

Шум — це повідомлення, які не потребують дії або повторюються надто часто. Він зменшує довіру до системи alerting.

Використовуйте часові вікна

Не реагуйте на одиничне значення. Перевіряйте умову протягом певного часу:

• помилки перевищують поріг 10 хвилин;

• черга зростає 15 хвилин;

• сервіс недоступний протягом кількох послідовних перевірок.

Тривалість має відповідати проблемі. Для повної недоступності сервісу вікно може бути коротшим, ніж для поступового зростання використання диска.

Встановлюйте пороги на основі поведінки

Поріг CPU > 80% не є універсальним правилом. Сервіс може нормально працювати з високим CPU або, навпаки, мати проблеми при низькому CPU через блокування на базі даних.

Краще враховувати:

• вплив на користувача;

• історичний базовий рівень;

• місткість ресурсу;

• час до вичерпання ресурсу;

• співвідношення між кількома сигналами.

Групуйте пов’язані сповіщення

Одна проблема може спричинити alert-и для багатьох екземплярів сервісу. Їх варто групувати за:

• середовищем;

• сервісом;

• кластером;

• спільним інцидентом.

Наприклад, замість 20 повідомлень про недоступність екземплярів можна показати одне повідомлення про недоступність сервісу з інформацією про кількість уражених екземплярів.

Розділяйте alert-и та дашборди

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

Не потрібно створювати alert на:

• кожну зміну CPU;

• кожен одиничний timeout;

• кожен перезапуск контейнера;

• тимчасову зміну кількості запитів;

• метрику, яку ніхто не перевіряє та не використовує.

Хибні тривоги та пропущені проблеми

Є два типи помилок системи alerting:

• false positive — alert виник, але реальної проблеми не було;

• false negative — проблема була, але alert не виник.

Хибні тривоги часто спричиняють:

• надто низькі пороги;

• відсутність for;

• alert-и на нестабільні або неповні дані;

• різкі, але короткі сплески;

• однакові пороги для різних сервісів;

• моніторинг причини замість користувацького симптому.

Пропущені проблеми часто виникають через:

• моніторинг лише ресурсів, а не функціональності;

• перевірку лише середніх значень;

• занадто довгі часові вікна;

• відсутність перевірки зовнішнього шляху користувача;

• метрики, які перестали надходити, але це не виявляється.

Середнє значення особливо небезпечне для latency. Невелика кількість дуже повільних запитів може бути непомітною в середньому, але суттєво погіршувати досвід користувачів. Тому для затримки часто використовують перцентилі.

Виявлення відсутності даних

Відсутність метрики не завжди означає нормальну роботу. Експортер або сам сервіс могли перестати надсилати дані.

Важливо окремо контролювати:

• доступність endpoint-а метрик;

• успішність збору метрик;

• час останнього оновлення критичних даних;

• стан самого моніторингу та системи сповіщень.

Такий контроль називають моніторингом моніторингу. Якщо система не може отримувати або доставляти alert-и, це також критична проблема.

Водночас не кожна відсутня метрика є помилкою: новий екземпляр сервісу може ще не мати жодного запиту. Тому перевірку потрібно будувати з урахуванням життєвого циклу сервісу та очікуваної поведінки.

Сповіщення під час інциденту

Під час інциденту корисно розділяти:

• сигнал — alert, який вказує на проблему;

• підтвердження — перевірка впливу на користувачів;

• діагностику — пошук причини;

• відновлення — дія, яка повертає систему до нормального стану.

Alert не повинен намагатися виконати всі ці ролі одночасно. Його завдання — швидко повідомити про важливий стан і дати достатньо контексту для наступного кроку.

Для кожного критичного alert бажано мати короткий runbook:

1. Перевірити, чи є користувацький вплив.

2. Подивитися зміни, релізи та конфігурацію.

3. Перевірити залежності.

4. Оцінити масштаб проблеми.

5. Виконати безпечну дію для відновлення.

6. Переконатися, що alert завершився після нормалізації.

Перегляд якості alert-ів

Alerting потрібно регулярно переглядати, а не налаштувати один раз і забути.

Для кожного alert корисно аналізувати:

• скільки разів він виникав;

• скільки разів вимагав реальної дії;

• скільки тривали спрацювання;

• чи був поріг занадто чутливим;

• чи зрозуміле повідомлення;

• чи достатньо контексту для діагностики;

• чи не дублює він інші alert-и.

Якщо alert регулярно ігнорують, це сигнал для зміни правила. Можливі рішення:

• підвищити поріг;

• додати час стабілізації;

• змінити канал або рівень критичності;

• об’єднати дублікати;

• перетворити alert на показник дашборда;

• повністю видалити непотрібне правило.

Типові помилки

Alert на кожен показник

Велика кількість alert-ів не означає високу надійність. Вона часто лише збільшує шум.

Alert без опису дії

Повідомлення має пояснювати не тільки, що сталося, а й що перевірити спочатку.

Надто коротке часове вікно

Одиничний сплеск або короткий збій мережі може створити непотрібний alert. Використовуйте for або інший механізм стабілізації.

Поріг без зв’язку з SLO

Порогове значення має бути обґрунтованим. Інакше alert може спрацьовувати часто, але не показувати реальний ризик.

Моніторинг лише інфраструктури

Нормальні CPU, пам’ять і кількість процесів не гарантують, що користувач може успішно виконати операцію. Потрібні сигнали на рівні сервісу та бізнес-критичного шляху.

Відсутність перевірки самого alerting

Сповіщення можуть не доставлятися через помилку в маршрутизації, конфігурації або каналі зв’язку. Систему alerting потрібно періодично перевіряти контрольним alert-ом.

Немає власника alert-а

Для кожного важливого правила повинно бути зрозуміло:

• хто реагує;

• у якому середовищі воно працює;

• який сервіс охоплює;

• де знайти інструкцію;

• коли правило потрібно переглянути.

Summary

• Моніторинг збирає дані про систему, а alerting повідомляє про стани, що потребують дії.

• Для сервісів корисно починати з Rate, Errors і Duration.

• Alert краще будувати на користувацьких симптомах і ризику порушення SLO, а не на кожній внутрішній причині.

• Хороший alert має бути важливим, терміновим, точним і таким, що спонукає до конкретної дії.

• Часові вікна, групування та обґрунтовані пороги допомагають зменшити шум.

• Відсутність метрик також може бути проблемою, тому потрібно контролювати працездатність самої системи моніторингу.

• Alert-и потрібно регулярно переглядати: непотрібні або надто шумні правила знижують надійність усієї практики спостережуваності.