Slide 1

Slide 1 text

Однажды вечером (это не название доклада, вы пришли куда надо 🙂)

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

Мониторинг бэкэнда с нуля или Куда смотреть и зачем Дмитрий Цепелев

Slide 5

Slide 5 text

@DmitryTsepelev DUMP’24 GitHub/Twitter: @dmitrytsepelev TG: @dmitry_tsepelev Блог: https:/ /dmitrytsepelev.dev 5

Slide 6

Slide 6 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–операций в секунду — не растет.

Slide 48

Slide 48 text

@DmitryTsepelev DUMP’24 48 effective_io_concurrency = 1

Slide 49

Slide 49 text

Алерты

Slide 50

Slide 50 text

@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” 👎 Одержимость инструментами 👎 Метрики изолированы или находятся вне контекста Оцените доклад