Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Dmitry Tsepelev
April 27, 2024
84

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

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

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

Dmitry Tsepelev

April 27, 2024
Tweet

More Decks by Dmitry Tsepelev

Transcript

  1. @DmitryTsepelev DUMP’24 Время ответа начинает расти под нагрузкой • у

    нас нет никакого мониторинга; • кажется, что сам бэкэнд работает быстро; • возможно у нас есть медленные запросы? посмотрим EXPLAIN… 3
  2. @DmitryTsepelev DUMP’24 План • антипаттерны мониторинга; • как начать наблюдать

    за компонентами системы; • как объединить изолированные метрики в систему, которая будет помогать; • как настроить алерты так, чтобы они были чувствительными, но не шумели. 6
  3. @DmitryTsepelev DUMP’24 Зачем вообще заниматься мониторингом? • планировать ожидаемый эффект

    от оптимизаций; • находить источник проблемы быстро; • находить индикаторы будущих проблем. 7
  4. @DmitryTsepelev DUMP’24 👎 “Checkbox monitoring” Мониторинг настроили, потому что он

    у всех есть, нам тоже надо. • что–то мониторим, но всё равно временами падаем; • алерты есть и часто игнорируются; • данные собираются очень редко; • исторических данных нет. 10
  5. @DmitryTsepelev DUMP’24 👎 Одержимость инструментами • у вас только один

    инструмент мониторинга; • у вас много инструментов мониторинга, и постоянно добавляются новые. 11
  6. @DmitryTsepelev DUMP’24 👎 Метрики изолированы друг от друга • у

    базы высокий CPU, это плохо? • у нас много сообщений в MQ, это плохо? • бэкэнд долго отвечал, это код тормозит? если да, то где? 14
  7. @DmitryTsepelev DUMP’24 Теория очередей: базовые понятия • очередь — место,

    где что–то накапливается (очередь сообщений, очередь веб–сервера, очередь БД, …); • job/unit of work/задача — одна обрабатываемая единица; • worker/server — место, где мы обрабатываем то, что копится (приложение, БД, …). 16 ⚠ Дисклеймер: во время этого доклада, когда я употребляю эти термины — это термины теории очередей ⚠
  8. @DmitryTsepelev DUMP’24 Counting и sampling • counting metrics используются, когда

    мы наблюдаем за чем–то, что может быть посчитано в конкретный момент времени (например, размер очереди); • sampling metrics используются для показателей, которые могут давать разный результат даже в казалось бы одинаковых условиях (например, время ответа сервера); • в идеале мы должны собирать всё, но это дорого. 17
  9. @DmitryTsepelev DUMP’24 👍 Начните с верхнеуровневых метрик • очереди, заполняемые

    извне: • RPM/RPS; • очереди пользовательских фоновых задач; • среднее время ответа каждой из очередей; • число серверных ошибок. 18
  10. @DmitryTsepelev DUMP’24 Система выглядит медленной. Она медленная? • возможно, графики

    врут; • долго процессим каждую задачу; • мало воркеров; • слишком много задач в очереди. 19
  11. @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
  12. @DmitryTsepelev DUMP’24 👍 Посмотрите на распределения измерений • среднее может

    показать результаты в более или менее выгодном свете; • лучше почистить выбросы; • нужно группировать результаты и визуализировать размеры групп. 22
  13. @DmitryTsepelev DUMP’24 Квантили 23 • квантили это значения, которые разбивают

    отсортированные значения на равные группы; • перцентиль — процент значений ниже данного. 0 0,75 1,5 2,25 3
  14. @DmitryTsepelev DUMP’24 Гистограммы 24 • способ представления табличных данных в

    графическом виде — в виде столбчатой диаграммы; • детализация управляется числом столбиков.
  15. @DmitryTsepelev DUMP’24 Иногда выбросы важны 25 • иногда гистограмма показывает

    не обычное нормальное распределение с длинным хвостом; • дополнительные сегменты справа показывают, что это другие выбросы; • попробуйте разобраться, в чем дело. Число запросов 0 300 600 900 1200 Время ответа 200 400 600 800 1000 1200 1400 1600 1800
  16. @DmitryTsepelev DUMP’24 👍 Сделайте отдельные чарты для специфических сегментов 26

    • иногда приложение ведет себя иначе для специфических владельцев данных; • например, некоторые пользователи могут иметь значительно больше данных, чем другие; • если ваше приложение может себя так повести — попробуйте измерить производительность для отдельных пользователей (с помощью гистограмм). Примеры приложений: маркетплейсы, социальные сети со “знаменитостями”.
  17. @DmitryTsepelev DUMP’24 Теория очередей: USE • Utilization — доля занятых

    workers; • Saturation — количество ожидающих jobs; • Errors — количество ошибок; • в идеале utilization = 100%, saturation = 0. 28
  18. @DmitryTsepelev DUMP’24 Теория очередей: USE 29 App Instance 1 App

    Instance 2 Load balancer Utilization 0% Saturation 0
  19. @DmitryTsepelev DUMP’24 Теория очередей: USE 30 App Instance 1 App

    Instance 2 Load balancer Utilization 50% Saturation 0
  20. @DmitryTsepelev DUMP’24 Теория очередей: USE 31 App Instance 1 App

    Instance 2 Load balancer Utilization 100% Saturation 0
  21. @DmitryTsepelev DUMP’24 Теория очередей: USE 32 App Instance 1 App

    Instance 2 Load balancer Utilization 100% Saturation 3
  22. @DmitryTsepelev DUMP’24 Закон Литтла 33 Среднее число задач в очереди

    = Среднее время обработки задачи × Число новых задач за период queue 8 задач в секунду 1 2 3 4 250ms/задача Среднее число задач в очереди 2 Утилизация 50% Пул воркеров
  23. @DmitryTsepelev DUMP’24 RED — альтернатива USE 34 • Rate —

    число запросов за период; • Errors — количество запросов, завершившихся с ошибкой, за период; • Duration — время обработки одного запроса. Обратите внимание: эти метрики дают те же данные, что и USE. Выбирайте на свой вкус.
  24. @DmitryTsepelev DUMP’24 👍 Ищите скрытые очереди • мы всё померили,

    всё хорошо, но система всё равно тормозит; • возможно у нас скрытая очередь, которую сложно/невозможно мониторить. 35
  25. @DmitryTsepelev DUMP’24 Пример: скрытая очередь в PostgreSQL 37 x 1

    5 2 6 ⚠ hidden queue 3 7 4 8 x 1 2 CPUs PostgresSQL connections app
  26. @DmitryTsepelev DUMP’24 👍 Постройте иерархию метрик 39 • стрелки —

    очереди; • прямоугольники — воркеры; • БД имеют сложное устройство и могут содержать много всего внутри. Puma App Instance Redis Sidekiq Server Postgre SQL Sidekiq Client Cron
  27. @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 “Внешние” метрики
  28. @DmitryTsepelev DUMP’24 SLA/SLO 42 • максимальное время простоя за период;

    • высокие проценты стоят дорого; • у инфраструктуры тоже есть SLA.
  29. @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
  30. @DmitryTsepelev DUMP’24 Apdex: пример 44 Apdex = 500 + 200

    2 750 = 0.8 Satis fi edCount ToleratingCount TotalCount
  31. @DmitryTsepelev DUMP’24 Смотрим сверху вниз 47 • HTTP server queue

    — в порядке; • Ruby — в порядке; • время ответа БД — растет; • количество IO–операций в секунду — не растет.
  32. @DmitryTsepelev DUMP’24 👍 Алерты чувствительные, но не шумные • Apdex

    — хорошая метрика для алерта; • избегайте алертов, которые не требуют действий или чинят сами себя; • странные вещи стоит мониторить и логгировать, но алерты не нужны; • определите порядок эскалации; • подумайте на алертами для неожиданных изменений метрик. 50
  33. @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
  34. @DmitryTsepelev DUMP’24 Спасибо! Вопросы? 52 👍 Начните с высокоуровневых метрик

    👍 Следите за распределениями значений 👍 Постройте отдельные чарты для специфических сегментов 👍 Выберите метод оценки производительности очередей 👍 Ищите скрытые очереди 👍 Стройте иерархии метрик 👍 Исследуйте иерархию сверху вниз 👍 Алерты чувствительные, но не шумят 👎 Мониторинга нет 👎 “Checkbox monitoring” 👎 Одержимость инструментами 👎 Метрики изолированы или находятся вне контекста Оцените доклад