Мониторинг бэкенда с нуля, или Куда смотреть и зачем

Почти у всех есть мониторинг. Часто он становится надёжным инструментом обнаружения неисправностей и их предотвращения на ранней стадии. Не менее часто в качестве мониторинга выступает APM на бесплатном плане с отчётами «из коробки», где что-то меряется, какие-то алерты падают в чат, никто на них не реагирует, и в один прекрасный солнечный день приложение ложится так, что поднимать его приходится до поздней ночи.

В докладе:
обсудим антипаттерны мониторинга;
научимся представлять систему в терминологии теории очередей;
выберем самые критичные метрики и настроим их;
разберёмся, какие есть менее критичные метрики, и научимся видеть смысл в их графиках;
разберёмся, зачем нужны алерты и когда они не нужны.

Transcript

1. Однажды вечером (это не название доклада, вы пришли куда надо 🙂)
2. @DmitryTsepelev DUMP’24 Время ответа начинает расти под нагрузкой 2 Requests per second Web response 90p, ms
3. @DmitryTsepelev DUMP’24 Время ответа начинает расти под нагрузкой • у нас нет никакого мониторинга; • кажется, что сам бэкэнд работает быстро; • возможно у нас есть медленные запросы? посмотрим EXPLAIN… 3
4. Мониторинг бэкэнда с нуля или Куда смотреть и зачем Дмитрий Цепелев
5. @DmitryTsepelev DUMP’24 GitHub/Twitter: @dmitrytsepelev TG: @dmitry_tsepelev Блог: https:/ /dmitrytsepelev.dev 5
6. @DmitryTsepelev DUMP’24 План • антипаттерны мониторинга; • как начать наблюдать за компонентами системы; • как объединить изолированные метрики в систему, которая будет помогать; • как настроить алерты так, чтобы они были чувствительными, но не шумели. 6
7. @DmitryTsepelev DUMP’24 Зачем вообще заниматься мониторингом? • планировать ожидаемый эффект от оптимизаций; • находить источник проблемы быстро; • находить индикаторы будущих проблем. 7
8. Антипаттерны мониторинга
9. @DmitryTsepelev DUMP’24 👎 Мониторинга нет 9
10. @DmitryTsepelev DUMP’24 👎 “Checkbox monitoring” Мониторинг настроили, потому что он у всех есть, нам тоже надо. • что–то мониторим, но всё равно временами падаем; • алерты есть и часто игнорируются; • данные собираются очень редко; • исторических данных нет. 10
11. @DmitryTsepelev DUMP’24 👎 Одержимость инструментами • у вас только один инструмент мониторинга; • у вас много инструментов мониторинга, и постоянно добавляются новые. 11
12. @DmitryTsepelev DUMP’24 NewRelic и a–ha moment 12
13. @DmitryTsepelev DUMP’24 NewRelic и a–ha moment 13
14. @DmitryTsepelev DUMP’24 👎 Метрики изолированы друг от друга • у базы высокий CPU, это плохо? • у нас много сообщений в MQ, это плохо? • бэкэнд долго отвечал, это код тормозит? если да, то где? 14
15. Делаем MVP мониторинга
16. @DmitryTsepelev DUMP’24 Теория очередей: базовые понятия • очередь — место, где что–то накапливается (очередь сообщений, очередь веб–сервера, очередь БД, …); • job/unit of work/задача — одна обрабатываемая единица; • worker/server — место, где мы обрабатываем то, что копится (приложение, БД, …). 16 ⚠ Дисклеймер: во время этого доклада, когда я употребляю эти термины — это термины теории очередей ⚠
17. @DmitryTsepelev DUMP’24 Counting и sampling • counting metrics используются, когда мы наблюдаем за чем–то, что может быть посчитано в конкретный момент времени (например, размер очереди); • sampling metrics используются для показателей, которые могут давать разный результат даже в казалось бы одинаковых условиях (например, время ответа сервера); • в идеале мы должны собирать всё, но это дорого. 17
18. @DmitryTsepelev DUMP’24 👍 Начните с верхнеуровневых метрик • очереди, заполняемые извне: • RPM/RPS; • очереди пользовательских фоновых задач; • среднее время ответа каждой из очередей; • число серверных ошибок. 18
19. @DmitryTsepelev DUMP’24 Система выглядит медленной. Она медленная? • возможно, графики врут; • долго процессим каждую задачу; • мало воркеров; • слишком много задач в очереди. 19
20. Как найти выбросы?
21. @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
22. @DmitryTsepelev DUMP’24 👍 Посмотрите на распределения измерений • среднее может показать результаты в более или менее выгодном свете; • лучше почистить выбросы; • нужно группировать результаты и визуализировать размеры групп. 22
23. @DmitryTsepelev DUMP’24 Квантили 23 • квантили это значения, которые разбивают отсортированные значения на равные группы; • перцентиль — процент значений ниже данного. 0 0,75 1,5 2,25 3
24. @DmitryTsepelev DUMP’24 Гистограммы 24 • способ представления табличных данных в графическом виде — в виде столбчатой диаграммы; • детализация управляется числом столбиков.
25. @DmitryTsepelev DUMP’24 Иногда выбросы важны 25 • иногда гистограмма показывает не обычное нормальное распределение с длинным хвостом; • дополнительные сегменты справа показывают, что это другие выбросы; • попробуйте разобраться, в чем дело. Число запросов 0 300 600 900 1200 Время ответа 200 400 600 800 1000 1200 1400 1600 1800
26. @DmitryTsepelev DUMP’24 👍 Сделайте отдельные чарты для специфических сегментов 26 • иногда приложение ведет себя иначе для специфических владельцев данных; • например, некоторые пользователи могут иметь значительно больше данных, чем другие; • если ваше приложение может себя так повести — попробуйте измерить производительность для отдельных пользователей (с помощью гистограмм). Примеры приложений: маркетплейсы, социальные сети со “знаменитостями”.
27. 👍 Выберите метод оценки производительности очередей
28. @DmitryTsepelev DUMP’24 Теория очередей: USE • Utilization — доля занятых workers; • Saturation — количество ожидающих jobs; • Errors — количество ошибок; • в идеале utilization = 100%, saturation = 0. 28
29. @DmitryTsepelev DUMP’24 Теория очередей: USE 29 App Instance 1 App Instance 2 Load balancer Utilization 0% Saturation 0
30. @DmitryTsepelev DUMP’24 Теория очередей: USE 30 App Instance 1 App Instance 2 Load balancer Utilization 50% Saturation 0
31. @DmitryTsepelev DUMP’24 Теория очередей: USE 31 App Instance 1 App Instance 2 Load balancer Utilization 100% Saturation 0
32. @DmitryTsepelev DUMP’24 Теория очередей: USE 32 App Instance 1 App Instance 2 Load balancer Utilization 100% Saturation 3
33. @DmitryTsepelev DUMP’24 Закон Литтла 33 Среднее число задач в очереди = Среднее время обработки задачи × Число новых задач за период queue 8 задач в секунду 1 2 3 4 250ms/задача Среднее число задач в очереди 2 Утилизация 50% Пул воркеров
34. @DmitryTsepelev DUMP’24 RED — альтернатива USE 34 • Rate — число запросов за период; • Errors — количество запросов, завершившихся с ошибкой, за период; • Duration — время обработки одного запроса. Обратите внимание: эти метрики дают те же данные, что и USE. Выбирайте на свой вкус.
35. @DmitryTsepelev DUMP’24 👍 Ищите скрытые очереди • мы всё померили, всё хорошо, но система всё равно тормозит; • возможно у нас скрытая очередь, которую сложно/невозможно мониторить. 35
36. @DmitryTsepelev DUMP’24 Пример: скрытая очередь в PostgreSQL 36 app x 1 2 PostgresSQL connections x 1 2 CPUs
37. @DmitryTsepelev DUMP’24 Пример: скрытая очередь в PostgreSQL 37 x 1 5 2 6 ⚠ hidden queue 3 7 4 8 x 1 2 CPUs PostgresSQL connections app
38. От отдельных графиков к системе мониторинга
39. @DmitryTsepelev DUMP’24 👍 Постройте иерархию метрик 39 • стрелки — очереди; • прямоугольники — воркеры; • БД имеют сложное устройство и могут содержать много всего внутри. Puma App Instance Redis Sidekiq Server Postgre SQL Sidekiq Client Cron
40. @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 “Внешние” метрики
41. Как оценить общую производительность системы
42. @DmitryTsepelev DUMP’24 SLA/SLO 42 • максимальное время простоя за период; • высокие проценты стоят дорого; • у инфраструктуры тоже есть SLA.
43. @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
44. @DmitryTsepelev DUMP’24 Apdex: пример 44 Apdex = 500 + 200 2 750 = 0.8 Satis fi edCount ToleratingCount TotalCount
45. Прохладная история основанная на реальных событиях, но все совпадения случайны и слегка приукрашены
46. @DmitryTsepelev DUMP’24 Время ответа начинает расти под нагрузкой 46 Requests per second Web response 90p, ms
47. @DmitryTsepelev DUMP’24 Смотрим сверху вниз 47 • HTTP server queue — в порядке; • Ruby — в порядке; • время ответа БД — растет; • количество IO–операций в секунду — не растет.
48. @DmitryTsepelev DUMP’24 48 effective_io_concurrency = 1
49. Алерты
50. @DmitryTsepelev DUMP’24 👍 Алерты чувствительные, но не шумные • Apdex — хорошая метрика для алерта; • избегайте алертов, которые не требуют действий или чинят сами себя; • странные вещи стоит мониторить и логгировать, но алерты не нужны; • определите порядок эскалации; • подумайте на алертами для неожиданных изменений метрик. 50
51. @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
52. @DmitryTsepelev DUMP’24 Спасибо! Вопросы? 52 👍 Начните с высокоуровневых метрик 👍 Следите за распределениями значений 👍 Постройте отдельные чарты для специфических сегментов 👍 Выберите метод оценки производительности очередей 👍 Ищите скрытые очереди 👍 Стройте иерархии метрик 👍 Исследуйте иерархию сверху вниз 👍 Алерты чувствительные, но не шумят 👎 Мониторинга нет 👎 “Checkbox monitoring” 👎 Одержимость инструментами 👎 Метрики изолированы или находятся вне контекста Оцените доклад