Однажды вечером
(это не название доклада, вы пришли куда надо 🙂)
Slide 2
Slide 2 text
@DmitryTsepelev
DUMP’24
Время ответа начинает расти под нагрузкой
2
Requests per second Web response 90p, ms
Slide 3
Slide 3 text
@DmitryTsepelev
DUMP’24
Время ответа начинает расти под нагрузкой
• у нас нет никакого мониторинга;
• кажется, что сам бэкэнд работает быстро;
• возможно у нас есть медленные запросы? посмотрим EXPLAIN…
3
Slide 4
Slide 4 text
Мониторинг бэкэнда с нуля
или Куда смотреть и зачем
Дмитрий Цепелев
@DmitryTsepelev
DUMP’24
План
• антипаттерны мониторинга;
• как начать наблюдать за компонентами системы;
• как объединить изолированные метрики в систему, которая будет
помогать;
• как настроить алерты так, чтобы они были чувствительными, но не
шумели.
6
Slide 7
Slide 7 text
@DmitryTsepelev
DUMP’24
Зачем вообще заниматься мониторингом?
• планировать ожидаемый эффект от оптимизаций;
• находить источник проблемы быстро;
• находить индикаторы будущих проблем.
7
Slide 8
Slide 8 text
Антипаттерны мониторинга
Slide 9
Slide 9 text
@DmitryTsepelev
DUMP’24
👎 Мониторинга нет
9
Slide 10
Slide 10 text
@DmitryTsepelev
DUMP’24
👎 “Checkbox monitoring”
Мониторинг настроили, потому что он у всех есть, нам тоже надо.
• что–то мониторим, но всё равно временами падаем;
• алерты есть и часто игнорируются;
• данные собираются очень редко;
• исторических данных нет.
10
Slide 11
Slide 11 text
@DmitryTsepelev
DUMP’24
👎 Одержимость инструментами
• у вас только один инструмент мониторинга;
• у вас много инструментов мониторинга, и постоянно добавляются
новые.
11
Slide 12
Slide 12 text
@DmitryTsepelev
DUMP’24
NewRelic и a–ha moment
12
Slide 13
Slide 13 text
@DmitryTsepelev
DUMP’24
NewRelic и a–ha moment
13
Slide 14
Slide 14 text
@DmitryTsepelev
DUMP’24
👎 Метрики изолированы друг от друга
• у базы высокий CPU, это плохо?
• у нас много сообщений в MQ, это плохо?
• бэкэнд долго отвечал, это код тормозит? если да, то где?
14
Slide 15
Slide 15 text
Делаем MVP мониторинга
Slide 16
Slide 16 text
@DmitryTsepelev
DUMP’24
Теория очередей: базовые понятия
• очередь — место, где что–то накапливается (очередь сообщений,
очередь веб–сервера, очередь БД, …);
• job/unit of work/задача — одна обрабатываемая единица;
• worker/server — место, где мы обрабатываем то, что копится
(приложение, БД, …).
16
⚠ Дисклеймер: во время этого доклада, когда я употребляю эти
термины — это термины теории очередей ⚠
Slide 17
Slide 17 text
@DmitryTsepelev
DUMP’24
Counting и sampling
• counting metrics используются, когда мы наблюдаем за чем–то, что
может быть посчитано в конкретный момент времени (например,
размер очереди);
• sampling metrics используются для показателей, которые могут давать
разный результат даже в казалось бы одинаковых условиях (например,
время ответа сервера);
• в идеале мы должны собирать всё, но это дорого.
17
Slide 18
Slide 18 text
@DmitryTsepelev
DUMP’24
👍 Начните с верхнеуровневых метрик
• очереди, заполняемые извне:
• RPM/RPS;
• очереди пользовательских фоновых задач;
• среднее время ответа каждой из очередей;
• число серверных ошибок.
18
Slide 19
Slide 19 text
@DmitryTsepelev
DUMP’24
Система выглядит медленной. Она медленная?
• возможно, графики врут;
• долго процессим каждую задачу;
• мало воркеров;
• слишком много задач в очереди.
19
Slide 20
Slide 20 text
Как найти выбросы?
Slide 21
Slide 21 text
@DmitryTsepelev
DUMP’24
Почему среднее не подходит
21
• допустим у нас есть некий
эндпоинт;
• измерения: 0.22, 0.24, 0.23, 0.27, 0.31,
0.25, 0.22, 0.23, 2.7, 0.19;
• среднее: 0.49.
0
0,75
1,5
2,25
3
Slide 22
Slide 22 text
@DmitryTsepelev
DUMP’24
👍 Посмотрите на распределения измерений
• среднее может показать результаты в более или менее выгодном
свете;
• лучше почистить выбросы;
• нужно группировать результаты и визуализировать размеры групп.
22
Slide 23
Slide 23 text
@DmitryTsepelev
DUMP’24
Квантили
23
• квантили это значения, которые
разбивают отсортированные
значения на равные группы;
• перцентиль — процент значений
ниже данного.
0
0,75
1,5
2,25
3
Slide 24
Slide 24 text
@DmitryTsepelev
DUMP’24
Гистограммы
24
• способ представления табличных данных в графическом виде — в
виде столбчатой диаграммы;
• детализация управляется числом столбиков.
Slide 25
Slide 25 text
@DmitryTsepelev
DUMP’24
Иногда выбросы важны
25
• иногда гистограмма показывает не
обычное нормальное
распределение с длинным
хвостом;
• дополнительные сегменты справа
показывают, что это другие
выбросы;
• попробуйте разобраться, в чем
дело.
Число запросов
0
300
600
900
1200
Время ответа
200 400 600 800 1000 1200 1400 1600 1800
Slide 26
Slide 26 text
@DmitryTsepelev
DUMP’24
👍 Сделайте отдельные чарты для специфических сегментов
26
• иногда приложение ведет себя иначе для специфических владельцев
данных;
• например, некоторые пользователи могут иметь значительно больше
данных, чем другие;
• если ваше приложение может себя так повести — попробуйте измерить
производительность для отдельных пользователей (с помощью
гистограмм).
Примеры приложений: маркетплейсы, социальные сети со “знаменитостями”.
Slide 27
Slide 27 text
👍 Выберите метод оценки
производительности
очередей
Slide 28
Slide 28 text
@DmitryTsepelev
DUMP’24
Теория очередей: USE
• Utilization — доля занятых workers;
• Saturation — количество ожидающих jobs;
• Errors — количество ошибок;
• в идеале utilization = 100%, saturation = 0.
28
Slide 29
Slide 29 text
@DmitryTsepelev
DUMP’24
Теория очередей: USE
29
App Instance 1
App Instance 2
Load balancer
Utilization 0%
Saturation 0
Slide 30
Slide 30 text
@DmitryTsepelev
DUMP’24
Теория очередей: USE
30
App Instance 1
App Instance 2
Load balancer
Utilization 50%
Saturation 0
Slide 31
Slide 31 text
@DmitryTsepelev
DUMP’24
Теория очередей: USE
31
App Instance 1
App Instance 2
Load balancer
Utilization 100%
Saturation 0
Slide 32
Slide 32 text
@DmitryTsepelev
DUMP’24
Теория очередей: USE
32
App Instance 1
App Instance 2
Load balancer
Utilization 100%
Saturation 3
Slide 33
Slide 33 text
@DmitryTsepelev
DUMP’24
Закон Литтла
33
Среднее число задач в очереди = Среднее время обработки задачи × Число новых задач за период
queue
8 задач в секунду 1
2
3
4
250ms/задача
Среднее число задач в очереди 2
Утилизация 50%
Пул воркеров
Slide 34
Slide 34 text
@DmitryTsepelev
DUMP’24
RED — альтернатива USE
34
• Rate — число запросов за период;
• Errors — количество запросов, завершившихся с ошибкой, за период;
• Duration — время обработки одного запроса.
Обратите внимание: эти метрики дают те же данные, что и USE.
Выбирайте на свой вкус.
Slide 35
Slide 35 text
@DmitryTsepelev
DUMP’24
👍 Ищите скрытые очереди
• мы всё померили, всё хорошо, но система всё равно тормозит;
• возможно у нас скрытая очередь, которую сложно/невозможно
мониторить.
35
Slide 36
Slide 36 text
@DmitryTsepelev
DUMP’24
Пример: скрытая очередь в PostgreSQL
36
app x
1 2
PostgresSQL connections
x
1
2
CPUs
Slide 37
Slide 37 text
@DmitryTsepelev
DUMP’24
Пример: скрытая очередь в PostgreSQL
37
x
1
5
2
6
⚠ hidden queue
3
7
4
8
x
1
2
CPUs
PostgresSQL connections
app
Slide 38
Slide 38 text
От отдельных графиков к
системе мониторинга
Slide 39
Slide 39 text
@DmitryTsepelev
DUMP’24
👍 Постройте иерархию метрик
39
• стрелки — очереди;
• прямоугольники — воркеры;
• БД имеют сложное устройство и могут содержать много всего внутри.
Puma App
Instance
Redis
Sidekiq
Server
Postgre
SQL
Sidekiq
Client
Cron
Slide 40
Slide 40 text
@DmitryTsepelev
DUMP’24
👍 Следите за иерархией сверху вниз
40
Puma App
Instance
Redis
Sidekiq
Server
Postgre
SQL
Sidekiq
Client
Cron
RPM RPM
# of
jobs
# of
requests
# of
requests
# of
jobs
# of jobs
# of
requests
“Внешние”
метрики
Slide 41
Slide 41 text
Как оценить общую
производительность
системы
Slide 42
Slide 42 text
@DmitryTsepelev
DUMP’24
SLA/SLO
42
• максимальное время простоя за период;
• высокие проценты стоят дорого;
• у инфраструктуры тоже есть SLA.
Slide 43
Slide 43 text
@DmitryTsepelev
DUMP’24
Apdex
43
• Application Performace Index;
• выберите T–value;
• посчитайте запросы:
• < T — satis
fi
ed;
• T…4*T — tolerating;
• > 4*T либо ошибка — frustrated.
Apdex =
Satisis
fi
edCount + ToleratingCount
2
TotalCount
Slide 44
Slide 44 text
@DmitryTsepelev
DUMP’24
Apdex: пример
44
Apdex =
500 + 200
2
750
= 0.8
Satis
fi
edCount
ToleratingCount
TotalCount
Slide 45
Slide 45 text
Прохладная история
основанная на реальных событиях, но все совпадения случайны и слегка
приукрашены
Slide 46
Slide 46 text
@DmitryTsepelev
DUMP’24
Время ответа начинает расти под нагрузкой
46
Requests per second Web response 90p, ms
Slide 47
Slide 47 text
@DmitryTsepelev
DUMP’24
Смотрим сверху вниз
47
• HTTP server queue — в порядке;
• Ruby — в порядке;
• время ответа БД — растет;
• количество IO–операций в секунду — не растет.
@DmitryTsepelev
DUMP’24
👍 Алерты чувствительные, но не шумные
• Apdex — хорошая метрика для алерта;
• избегайте алертов, которые не требуют действий или чинят сами себя;
• странные вещи стоит мониторить и логгировать, но алерты не нужны;
• определите порядок эскалации;
• подумайте на алертами для неожиданных изменений метрик.
50
Slide 51
Slide 51 text
@DmitryTsepelev
DUMP’24
Куда пойти дальше
• Practical Monitoring: E
ff
ective Strategies for the Real World, Mike Julian,
2017
• Systems Performance: Enterprise and the Cloud, Brendan Gregg, 2013
51
Slide 52
Slide 52 text
@DmitryTsepelev
DUMP’24
Спасибо! Вопросы?
52
👍 Начните с высокоуровневых метрик
👍 Следите за распределениями значений
👍 Постройте отдельные чарты для
специфических сегментов
👍 Выберите метод оценки
производительности очередей
👍 Ищите скрытые очереди
👍 Стройте иерархии метрик
👍 Исследуйте иерархию сверху вниз
👍 Алерты чувствительные, но не шумят
👎 Мониторинга нет
👎 “Checkbox monitoring”
👎 Одержимость инструментами
👎 Метрики изолированы или находятся
вне контекста
Оцените доклад