Затримка, Трафік, Помилки, Насиченість

Чотири показники покривають більшість операційних завдань

З книги Google SRE. Чотири сигнали, які ви вимірюєте на кожному рівні сервісу. Якщо ви правильно інструментуєте ці чотири показники, ви виявите більшість проблем у продакшені до того, як їх помітять користувачі.

Затримка: скільки часу займає обробка запиту? Звітують розподіли, а не лише середні значення. p99 (99-й перцентиль затримки) важливіший за середнє значення, оскільки саме хвостова затримка сприймається користувачами як «повільність». Сервіса із середньою затримкою 50 мс та p99 у 5 000 мс має реальну проблему, яку більшість користувачів навіть не помічає, але найпостраждаліші 1% відчувають це на власній шкурі.

Трафік: скільки запитів на секунду? Загальна кількість запитів, за ендпоінтами, за кодами статусу, за регіонами. Базовий рівень відомий; оповіщення про аномалії (раптове падіння = проблема з інгредом; раптовий стрибок = наплив або атака).

Помилки: частота невдалих запитів. Розрізняйте 4xx (помилки клієнта, не ваша вина) та 5xx (помилки сервера, ваша вина). Відстежуйте частку помилок як відсоток від трафіку, а не як абсолютні значення, щоб оповіщення працювали на різних рівнях навантаження.

Насиченість: наскільки система навантажена? Використання CPU, пам’ять, глибина пулу з’єднань, довжина черги. Це провідний індикатор. Насиченість зростає до того, як погіршуються затримки або зростає кількість помилок. Тір із 90% насичення — це одна погана хвилина до колапсу черги.

На рівні проксі-тіру зокрема

Кожен сигнал проявляється на крайовому шарі:

- Затримка на проксі: тривалість TLS-рукопожаття, час підключення до апстріму, загальний час запиту-відповіді. Вимірюються окремо, оскільки вони належать до різних частин шляху.

- Трафік на проксі: загальна кількість запитів/сек, розподіл за бекендами (гарячий бекенд вказує на перекіс балансуванника навантаження), розбивка за кодами статусу.

- Помилки на проксі: 4xx від клієнтів (ваші користувачі звертаються до некоректних ендпоінтів), 5xx від бекендів (ваші сервіси збиваються), внутрішні помилки проксі (502 = бекенд недоступний, 504 = тайм-аут бекенду).

- Насиченість на проксі: кількість TLS-сесій, глибина пулу з’єднань з upstream, CPU самого проксі (термінація TLS є CPU-інтенсивною).

Порада: різке зростання 502 за умови низької латентності бекенду означає, що бекенд розриває з’єднання до надсилання відповіді (скидання з’єднання, збій, OOM). Зростання 504 означає, що бекенд повільний, але все ще відповідає. Читайте код помилки; він вказує, де саме відбувається збій.

Читання сигналів

Ваша дашборд показує наступне за останні 10 хвилин:

- Трафік: приблизно стабільний на рівні 800 зап/с (без стрибка)

- Латентність: p50 стабільний на 40 мс, p99 зріс зі 200 мс до 2 500 мс за 5 хвилин і продовжує зростати

- Помилки: частота 4xx стабільна на рівні 0,3% (нормальний фоновий рівень); частота 5xx зросла з 0,1% до 1,2% (переважно 504 Gateway Timeout)

- Насиченість: CPU бекенду зріс з 45% до 78% протягом тих самих 5 хвилин; CPU проксі стабільний на рівні 30%

Коли масштабувати, коли зменшувати навантаження, коли викликати людей

Рішення щодо потужності потребують тригерів

Спостереження за метриками — це просто. Розуміння того, коли діяти на їхній основі, — це дисципліна.

Масштабуйте вгору, коли: насичення перевищує стійкий поріг (наприклад, CPU бекенду >70% протягом 5 хвилин), або глибина черги зростає понад цільове значення, або p99 затримки перевищує SLO. Тригер має спрацювати до того, як система зламається, а не в момент збою.

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

Викликайте людину, коли: SLO порушується швидше, ніж може витримати бюджет помилок, або тригер насичення спрацьовує, але автоскалування не поглинає навантаження, або з'являється каскадний патерн (рівень помилок та рівень повторних спроб одночасно зростають).

Не викликайте людину, коли: одна погана хвилина вирішується сама собою, або фонові пакетні завдання спричиняють очікувані періодичні сплески, або шум перевищує поріг (помилковим є поріг, а не система).

SLO та спалення бюджету помилок

SLO (ціле значення рівня обслуговування) визначає прийнятну продуктивність: «рівень успішності >= 99,9% протягом 28-денного вікна». Додаток (0,1%) є бюджетом помилок.

Швидкість спалення (burn rate): наскільки швидко ви витрачаєте бюджет помилок. Якщо ви спалюєте 10% бюджету за 1 годину, швидкість у 240 разів вища за стійку (1 година становить 1/672 від 28-денного вікна; спалення 10% за цей вікно = 10% × 672 = 6720% прогнозу для всього вікна, тоді як дозволено лише 100%).

Алерти спалення за багатовіконною моделлю: сигнал надсилається, коли обидва вікна — коротке (5 хвилин зі швидкістю 14,4x) та довге (1 година зі швидкістю 6x) — спалюють бюджет швидше, ніж стійка швидкість. Це виявляє як раптові збої, так і повільне погіршення.

Чому це важливо для потужності: сервіс, що працює з SLO 99,9% і має запас 1%, може поглинати незначні спотворення. Сервіс на рівні 99,93% (лише-лише відповідає SLO) може порушити ціль у будь-який поганий день. Рішення щодо потужності мають орієнтуватися на комфортний запас SLO, а не на мінімум, що відповідає вимозі.

Рішення щодо потужності під спостереженням

Ваш сервіс має SLO 99,9% успішних запитів протягом 28 днів. Поточний стан за даними моніторингу за останню годину:

- Рівень успішності: 99,5% (тримається протягом 30 хвилин)

- CPU бекенду: в середньому 82% по всій флоті (ціль 70%)

- Затримка p99: 800 мс (ціль SLO: <500 мс)

- Трафік: 1 400 зап/с, зростання з базових 1 000 зап/с (на 40% вище норми; тенденція продовжує зростати)

- Автоскейлінг: налаштовано додавати репліки, коли CPU > 80% протягом 5 хв; поточний процес масштабування вгору додасть 3 репліки приблизно за 90 секунд

Розробіть план спостережності за запуском

Синтез

Тепер ви можете розробити /health, який виявляє реальні збої, /version, який дозволяє верифікувати розгортання, дашборди з чотирма «золотими» сигналами на рівні проксі та тригери пропускної здатності, пов'язані зі швидкістю спалювання SLO.

Застосуйте всі чотири.

Ваша команда запускає search.example.com (сервіс пошуку з уроку про режими збоїв). Команда хоче впровадити спостережність, яка виявляє проблеми до того, як їх помітять користувачі, з чіткою матрицею рішень «попередження чи ні». SLO: 99,9% успішних запитів, p99 затримки < 300 мс, за 28-денне вікно.

Закриття курсу

Закриття курсу

Ви завершили всі п'ять уроків:

- Проксі та джерела: форма шару на межі, яку використовує майже кожна публічна веб-служба

- Безстанове горизонтальне масштабування: чому безстановий шар множиться дешево та як визначити його розмір

- Розділення вхідного та вихідного трафіку: чому один вузол стає двома та режим відмови, який це примушує

- Режими відмов та радіус ураження: однократні точки відмови, каскади, розбори інцидентів, безвинні дії

- Наблюдабельність та потужність (цей урок): що вимірювати, щоб проблеми з'являлися до того, як їх помітять користувачі

Головна ідея: розподілена система веб-масштабу — це не магія. Це невеликий набір патернів (зворотний проксі, безстанові репліки, розділення вхідного/вихідного трафіку, переборти та обвідні контури, чотири золоті сигнали), які продумано поєднуються. Щойно ви розпізнаєте ці патерни, ви бачите їх у кожній продуктивній архітектурі.

Супутні уроки: п'ять уроків про геометрію-* переосмислюють той самий матеріал як теорію графів та геометрію. Вони добре поєднуються в будь-якому порядку.

Молодці.