Панелі стану застосунків

Моніторинг і усунення несправностей в AWS

John Q. Martin

Principal Consultant

Дизайн дашборду: ієрархія інформації

Трирівнева піраміда: вузький темний верхній рівень, ширший бірюзовий середній рівень і найширший зелений нижній рівень

Як у лікарні: реєстратура → відділення → консультант

Верх — короткий підсумок

Загальний стан системи
Ключові бізнес-метрики, SLA, поточні інциденти

Середина — стан сервісів

Частота помилок, перцентилі затримки, пропускна здатність

Низ — детальна діагностика

Трейси, логи, використання ресурсів, стан залежностей

Чотири золоті сигнали

Чотири золоті сигнали моніторингу: затримка, трафік, помилки та насичення

Закрийте ці чотири — і ви покриєте більшість проблем, з якими зіткнетеся.

Метод RED

RED для сервісів, що обробляють запити:

Патерн методу RED, що показує rate, errors і duration для сервісів, керованих запитами

Звʼязок із золотими сигналами:

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

Почніть з RED, додайте насичення для глибшої діагностики.

Три джерела даних

Діаграма трьох джерел даних для дашборду: метрики CloudWatch, трейси X-Ray і CloudWatch Logs

Віджети метрик CloudWatch

Обсяг запитів:

["AWS/ApplicationELB",
 "RequestCount",
 {"stat": "Sum"}]

Частота помилок (metric math):

"metrics": [
  ["AWS/Lambda", "Errors",
   {"stat":"Sum","id":"errors"}],
  [".", "Invocations",
   {"stat":"Sum","id":"invocations"}],
  [{"expression":
    "(errors/invocations)*100",
    "label":"Error Rate %"}]
]

Перцентилі часу відповіді:

["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p50"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p95"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p99"}]

Обсяг запитів з ALB RequestCount
Частота помилок через metric math — errors / invocations × 100
Час відповіді як перцентилі p50, p95, p99

Віджети X-Ray і логів

Віджети X-Ray:

Service map — топологія застосунку з індикаторами стану
Trace statistics — середній час відповіді, частота помилок, частота збоїв
Service latency — порівняння часу відповіді по сервісах

Віджети CloudWatch Logs:

Запит для нещодавніх помилок:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Кількість помилок за типами:

filter @message like /ERROR/
| stats count(*) as errors
    by errorType
| sort errors desc

Повний макет дашборду

Макет дашборду стану: зверху віджети-підсумки, посередині карта сервісів, нижче — логи помилок

Розвʼязання інцидентів: робочий процес

Бланк тріажу в приймальному відділенні з кольоровими смугами пріоритетів і стетоскопом

Як у тріажі ER: стабілізувати → діагностувати → лікувати → перевірити

Виявити — червоні/жовті індикатори, стрибки помилок
Окреслити — які сервіси? коли? погіршується?
Корелювати — помилки + затримка, трафік + ресурси
Заглибитись — карта сервісів → трейси → логи
Первинна причина — залежність, БД, памʼять, конфіг
Виправити — circuit breaker, масштабування, відкат, failover
Перевірити — помилки нормальні, карта зелена, тривоги знято

Сценарій 1: раптовий сплеск трафіку

Дашборд моніторингу під час сплеску трафіку: лінійні графіки різко вгору, індикатори в червоній зоні, червоні банери тривог

Що видно на дашборді:

Обсяг запитів у 10× від норми
Частота помилок 25%
Затримка 3000 мс
CPU 95%

Аналіз: Ресурси перевантажені сплеском трафіку

Дії:

Негайно масштабуватися горизонтально
Увімкнути авто-масштабування
Упровадити лімітування запитів
Додати кешування, щоб зменшити навантаження на бекенд

Сценарій 2: вузьке місце в базі даних

Дашборд моніторингу з вузьким місцем у БД: тріснута червона іконка БД, індикатори CPU та зʼєднань на максимумі, графік затримки запитів стрімко зростає, басейн зʼєднань майже заповнений

Що видно на дашборді:

CPU БД 95%
Зʼєднання БД 95/100
Затримка запитів 5000 мс
Затримка застосунку 5500 мс

Аналіз: Вузьке місце — база даних; повільні запити виснажують пул зʼєднань

Дії:

Знайти повільні запити в логах
Додати індекси, оптимізувати запити
Збільшити розмір пулу зʼєднань
Масштабувати базу даних

Сценарій 3: каскадна відмова

Що видно на карті сервісів:

Каскад на карті сервісів: вузол A бурштиновий із клієнтськими помилками, B і C червоні зі збоями сервера, D темний і повністю недоступний, стрілки вниз по ланцюгу

Аналіз:

Невелика проблема в Service A спричинила каскад у ланцюгу залежностей

Дії:

Circuit breakers, щоб зупинити каскад
Тайм-аути на кожному рівні сервісів
Резервні механізми для відмов залежностей
Виправити першопричину в Service A

Найкращі практики дашбордів

Шість рекомендованих найкращих практик для дашбордів моніторингу стану застосунків

Підсумок відео та завершення курсу

Проєктуйте за ієрархією інформації та чотирма золотими сигналами
Поєднуйте метрики CloudWatch, трейси X-Ray і логи в одному поданні
Семикроковий процес інцидентів: виявити → окреслити → корелювати → заглибитись → причина → виправити → перевірити

Тепер ви вмієте:

Моніторити за допомогою CloudWatch metrics, logs і dashboards
Налаштовувати тривоги й сповіщення через SNS і SQS
Упроваджувати розподілене трасування з X-Ray
Будувати дашборди стану застосунків для операційної досконалості

Панелі стану застосунків

Моніторинг і усунення несправностей в AWS