что такое синтетический мониторинг

Мониторинг производительности: реальные пользователи и их эмуляция

Синтетический мониторинг

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

Контролируя переменные окружения, вы можете понять, где в производительности узкие места и каковы их источники. Однако, все эти данные не отражают реальный пользовательский опыт, особенно если поведение пользователя не ограничивается только лишь просмотром страницы.

Синтетический мониторинг может быть важным компонентом тестирования регрессий и средством мониторинга выпущенного и работающего приложения. Ухудшение базовых метрик производительности в ходе CI/CD-процесса должно вести к приостановке релиза, по крайней мере до тех пор, пока не выяснится, почему метрики ухудшились. Если проблема возникает только в Production-режиме, синтетические тесты предоставят информацию, которая поможет идентифицировать, изолировать и решить проблему, прежде чем она отразится на пользователях.

Мониторинг реальных пользователей (RUM)

В отличие от синтетического мониторинга, RUM собирает данные от настоящих пользователей, вне зависимости от их устройств, браузеров, сети или геолокации. Пока пользователь взаимодействует с приложением, тайминги такого взаимодействия записываются, вне зависимости от того, какое действие выполняется в конкретный момент. Такой мониторинг собирает данные о реальном использовании приложения, а не о том поведении, которое ожидают разработчики или, скажем, отдел маркетинга. Это особенно важно для больших веб-сайтов или сложных приложений, где функциональность или содержимое постоянно меняются, а количество пользователей может очень сильно расти, создавая новые нагрузки и требования.

Используя RUM, бизнес может лучше понять своих клиентов и определить зоны сайта, которые требуют большего внимания. Более того, RUM может помочь понять географию или канал распространения приложения. Знание своих пользователей и трендов поможет вам выстроить бизнес-планы и думать наперёд, позволяя вам определить приоритетные зоны, которые требует оптимизации и улучшения производительности.

Сравнение подходов

Синтетический мониторинг хорошо подходит для отлавливания регрессий в ходе разработки приложения. Особенно полезным может оказаться занижение скорости сети (network throttling (en-US) ). Такой подход довольно прост, недорог и великолепно подходит для тестирования определённых точек приложения по мере того, как вы вносите изменения в код. Но он даёт лишь узкий обзор производительности и не говорит о том, что испытывает пользователь.

Тестирование на реальных пользователях, в свою очередь, даёт информацию о настоящих пользователях, которые используют приложение или веб-сайт. И хотя получение и обработка таких данных обходится дороже и не так проста, такой подход даёт жизненно важные данные о пользовательском опыте.

API для измерения производительности

Источник

Синтетический мониторинг производительности

Благодаря внедрению клиентского мониторинга производительности, мы с полной уверенностью можем диагностировать проблемные места проекта и составить план для дальнейшей оптимизации.

Однако было бы неплохо иметь инструмент, который еще на этапе разработки позволял бы выявлять возможные регрессы производительности. Именно так родилась идея о создании синтетического мониторинга.

Содержание

Мониторинг

Perfectum Synthetic — это инструмент для измерения синтетических показателей производительности. Рассмотрим основные требования, которые мы предъявляли к будущему мониторингу.

Гибкая конфигурация

С самого начали разработки мы понимали, что вариантов и условий использования мониторинга может быть много, а значит, от проекта потребуется возможность максимальной конфигурации.

Для удобства работа с инструментом мы разработали утилиту Perfectum CLI и добавили файл конфигурации perfectum.json.

Сочетание возможностей утилиты командной строки и файла конфигурации дает существенную гибкость в использовании мониторинга, начиная от определения бюджетов производительности, заканчивая динамической подменой аудируемых страниц.

Сборка и запуск проекта

Для нас было важно, чтобы инструмент, помимо выполнения основных функций, обеспечивал удобную работу с проектом на всех этапах разработки.

Поэтому возможность автоматической сборки и запуска проекта при внесении изменений избавляет от ручных пересборок, что значительно упрощает локальное использование мониторинга.

Возможность аутентификации

Некоторые наши проекты недоступны для публичного использования и требуют предварительной аутентификации. Поэтому такая возможность доступна через указание пути к файлу auth-скрипта, который выполнится непосредственно перед началом мониторинга.

В процессе аутентификации используется Puppeteer, поэтому содержимое скрипта должно соответствовать правилам использования данного инструмента.

Воспроизводимость результатов

Одним из основных требований, которые предъявляются к подобному виду мониторинга, является воспроизводимость и точность результатов.

Для аудита производительности используется Lighthouse, который в условиях изолированной среды показывает стабильные результаты между запусками.

Также наш мониторинг дополнительно определяет медианный результат среди всех запусков аудита, что позволяет получить наиболее стабильный отчет о производительности.

Метрики

Как упоминалось ранее, Perfectum Synthetic использует Lighthouse. Поэтому рассмотрим, как в этом инструменте происходит общая оценка производительности проекта.

Lighthouse использует значения шести метрик. Каждая метрика отражает состояние разных стадий загрузки страницы и имеет собственный вес, который показывает степень влияния метрики на общий результат.

Ниже приведена соответствующая таблица:

Метрики FCP, LCP и CLS подробно рассматривались в статье о клиентском мониторинге производительности, поэтому в этой мы рассмотрим остальные — SI, TTI и TBT.

Speed Index

Speed Index (SI) показывает, насколько быстро отображается содержимое страницы в процессе загрузки приложения.

Принцип работы

В основе работы SI лежит понятие визуального завершения (Visually Complete, VC):

Рассмотрим два возможных варианта загрузки страницы:

Оба варианта начинают загрузку и становятся визуально завершенными (VC) за одно и тоже время (5 секунд). Но очевидно, что вариант А гораздо предпочтительнее с точки зрения пользователя. И чтобы увидеть количественную разницу между подобными вариантами загрузки, используется показатель SI.

SI оценивает процент визуального завершения в разные моменты времени:

Стандартный механизм определения VC, используемый, к примеру, в WebPageTest, основывается на анализе оттенков цветовой палитры страницы. Каждые 100 мс происходит сравнение количества оттенков между двумя соседними фреймами:

Однако следует отметить, что в Lighthouse применяется другая модель определения визуальной завершенности. Вместо сравнения количества оттенков цветовой палитры используется индекс структурного сходства (SSIM), который основывается на оценке воспринимаемого качества изображения, включая информацию об изменениях яркости и контраста.

Разобравшись с тем, как происходит расчет показателя VC, представим графически рассмотренные варианты загрузки страницы:

Графики отображают отношение времени загрузки и процента визуальной завершенности.

Область графика под кривой можно представить как отрендеренную часть страницы в определенный момент времени:

Для вычисления SI мы могли бы использовать площадь данной области, однако есть важный нюанс. Напомню, что 5 секунд загрузки которыми мы оперируем, являются временем визуальной завершенности (VC), но они не являются показателем полной загрузки страницы. Это значит, что область под кривой будет увеличиваться пропорционально времени загрузки, при этом увеличивая результат показателя SI.

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

Именно поэтому алгоритм работы SI использует данную область при вычислении результата.

Разумеется, для нахождения площади указанной области (плоской криволинейной фигуры) формула расчета использует определенный интеграл и выглядит следующим образом:

Поэтому чем меньше площадь данной области, а соответственно, и значение SI — тем лучше:

Оценка результатов

При оценке результатов показателя рекомендуется использовать следующие градации:

Способы оптимизации

Как правило, любые оптимизации, направленные на увеличение скорости загрузки страницы, положительно скажутся на показателе SI.

Список данных оптимизаций я приводил в статье о клиентском мониторинге производительности.

Дополнительной рекомендацией будет проверка на отсутствие явления FOIT (Flash Of Invisible Text).

Time To Interactive

Time To Interactive (TTI) измеряет время с момента начала загрузки страницы до момента стабильного реагирования на ввод пользователя.

Принцип работы

В основе работы TTI лежат три понятия: время первой отрисовки контента (First Contentful Paint, FCP), продолжительные задачи (Long Tasks) и временной интервал с отсутствием продолжительных задач и сетевых запросов (Quiet Window).

Для начала посмотрим на временную шкалу, представляющую типичную загрузку страницы:

Кроме выполнения сетевых запросов на ней также отмечено событие FCP и продолжительные задачи основного потока рассматривавшиеся в предыдущей статье.

Для полноты картины осталось определить, что такое Quiet Window.

Quiet Window — это временной интервал (5 секунд), на протяжении которого отсутствуют продолжительные задачи и выполняется не более двух сетевых запросов (GET). Отметим его на временной шкале загрузки:

Значением TTI будет время окончания последней продолжительной задачи перед наступлением Quiet Window.

При отсутствии продолжительных задач значение TTI будет равняться значению FCP.

Оценка результатов

При оценке результатов показателя рекомендуется использовать следующие градации:

Способы оптимизации

Основным улучшением, которое может оказать влияние на показатель TTI, является уменьшение количества JS-ресурсов на странице. Соответствующие рекомендации я приводил в предыдущей статье.

Дополнительные улучшения, направленные на увеличение скорости загрузки страницы, такие как минификация, компрессия, предварительные соединения и прелоадинг ресурсов, также положительно скажутся на значении показателя.

Total Blocking Time

Total Blocking Time (TBT) измеряет общее количество времени, в течение которого страница была недоступна для пользовательского ввода.

Принцип работы

Рассмотрим уже знакомую нам временную шкалу загрузки страницы:

Алгоритм работы TBT использует информацию о задачах основного потока, которые выполнялись между событиями FCP и TTI.

Поэтому оставим на шкале только нужную нам информацию:

и обозначим время выполнения каждой задачи:

Показатель TBT оперирует понятием времени блокировки пользовательского ввода.

Из спецификации продолжительных задач и модели производительности RAIL, мы знаем, что любая задача, выполняющаяся больше 50 мс, будет заметным образом блокировать взаимодействие со страницей. Поэтому время, оставшееся после первых 50 мс выполнения задачи, будет являться временем блокировки пользовательского ввода.

Отметим данное время на шкале загрузки:

Значением TBT будет сумма всех периодов блокировки, которая в нашем случае составляет 310 мс (200 + 70 + 40).

TBT является отличным дополнением к показателю TTI. Поскольку последний, в силу эвристики алгоритма (Quiet Window), не способен отобразить разницу между следующими сценариями.

Представим, что на протяжении 10 секунд загрузки приложения в основном потоке браузера возникли три продолжительные задачи длительностью 51 мс:

При таком варианте загрузки значение TTI составит около 9 секунд, а TBT — 3 миллисекунды.

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

При таком сценарии значение TTI будет тем же, однако значение TBT заметно увеличится и составит 7950 миллисекунд.

Оба варианта загрузки имеют одинаковое значение TTI, но с точки зрения пользователя, это абсолютно разные сценарии взаимодействия со страницей. И показатель TBT способен такую разницу отобразить.

Оценка результатов

При оценке результатов показателя рекомендуется использовать следующие градации:

Способы оптимизации

Рекомендации по оптимизации TBT те же, что и для показателя First Input Delay.

Анализ данных

Результат работы синтетического мониторинга отображается в виде двух отчетов Lighthouse. Один отчет генерируется для десктопной версии страницы, другой — для мобильной:

Определить собственные характеристики среды можно через настройки аудита.

Для мониторинга сразу нескольких страниц приложения достаточно перечислить необходимые адреса в файле конфигурации.

Для предварительной аутентификации, необходимо указать путь к файлу auth-скрипта.

Бюджеты производительности

О том, что такое бюджеты производительности, я рассказывал в предыдущей статье.

Для работы с бюджетами в Perfectum Synthetic используется соответствующий раздел конфигурации мониторинга. Можно установить бюджет как для временных, так и для ресурсных показателей проекта.

Для отдельных страниц приложения могут устанавливаться собственные бюджеты. А каждый показатель может иметь бюджет как для десктопной, так и для мобильной версии страницы.

Вся информация о превышении бюджетов будет отображаться в соответствующем разделе отчета производительности:

Заключение

Хорошая производительность проекта не является приложением к экспертизе отдельного человека или целой команды — это всегда результат целенаправленной работы.

И если вы заботитесь не только о скорости разработки, но и о качестве продукта, то внедрение подобных инструментов этому только поспособствует.

Источник

Мониторинг производительности приложений и метрики здоровья без APM

Привет, Habr! Я уже рассказывал про AIOps и методы машинного обучения в работе с ИТ инцидентами, про зонтичный мониторинг и различные подходы к сервис менеджменту. Сейчас хотелось бы поделиться вполне конкретным алгоритмом, как можно без особых затрат быстро получить информацию о работоспособности бизнес-приложений с помощью синтетического мониторинга и построить на базе этого метрики здоровья бизнес-сервисов. Рассказ будет построен на кейсе внедрения подхода в одной авиакомпании.

Сейчас есть много APM систем, таких как Appdynamics, Dynatrace, и других, где есть внутри модуль контроля UX через синтетические проверки. И если стоит задача быстрее пользователей узнать о сбое, я расскажу почему все эти APM не нужны. Также модной фишкой APM являются метрики здоровья, я покажу как можно их построить без APM.

Зачем еще одно решение, когда уже есть несколько ИТ-мониторингов?

Хорошо настроенный ИТ-мониторинг позволяет снять множество задач поддержки ИТ, но они ограничены в решении сразу нескольких проблем:

1. Первым делом самолеты

Технический мониторинг не позволяет оценить состояние бизнес-функций систем и инфраструктуры на площадках. Например, когда пропадает канал связи на площадке – это событие для сетевого инженера, но не для бизнеса. У нас есть более сложные кейсы, когда есть несколько помещений с терминалами, где лётный состав должен пройти check-in. В каждом помещении до пяти терминалов, во время «разлёта» мы понимали, что поломка одного-двух терминалов в комнате не влияет на процедуру, однако три-четыре – создадут очередь среди лётного состава, что может повлиять на выполнение одной из важных метрик – «выполнение плана полётов», и часть лётного состава нужно отправить в другую комнату. При потере пяти терминалов – мы теряем в этом помещении ряд бизнес-функций и запускается BCP (Business Сontinuity Planning) – план действий, когда бизнес работает без ИТ. Настроить подобные кейсы простым техническим мониторингом сложно, а продуктовым командам нужен простой инструмент, которые не требует больших компетенций в ИТ-мониторинге.

2. Проводить проверку производительности приложений, но не «закопаться» в обработке результатов

Комплексные системы практически невозможно на 100% покрыть мониторингами метрик или логов. Всегда найдётся что-то, не покрытое мониторингами, из-за чего бизнес-функция системы может оказаться недоступной или деградированной. И тут приходит на помощь способ проверки через эмуляцию работы бизнес-функций методом синтетических транзакций, то есть имитация того, как человек в браузере или на «толстом» клиенте нажимает на кнопки и получает некий результат. Она гарантированно скажет о доступности бизнес-функции для остальных пользователей. Но систем и тестов много, просматривать результаты каждого — трудозатратно и долго. Нужен еще инструмент «оркестрации» синтетических тестов, визуализации результатов.

3. Перестать звонить и спрашивать «единственного, кто знает»

В организациях с крупным IT все системы переплетены друг с другом интеграциями настолько, что порой сложно понять, где кончается одна система и начинается другая. В результате в случае сбоя одной системы совершенно не очевидно, как он может повлиять на другие системы. Информация о взаимосвязи систем обычно только в одном «хранилище» — в головах техлидов продуктовых команд. Нужно было сделать эти данные открытыми и доступными, чтобы в случае сбоя не нужно было опрашивать сотрудников, которые обладают какой-либо информацией. Решить эту задачу могла бы ресурсно-сервисная модель, которая отражала бы влияние различных элементов инфраструктуры на стабильность работы бизнеса.

4. Хьюстон, у нас проблемы. или нет?

Конкретно в этой авиакомпании использовалось несколько мониторингов:

А) мониторинг «коробок» и каналов связи – Zabbix, Prometheus для систем в kubernetes

Б) мониторинг логов на платформе семейства ELK (elastic – logstash – kibana).

Любой из них мог сообщить об отклонениях, не было одного места, где можно узнать о состоянии компонентов в целом.

5. Отчёты не отчётов ради

Руководство компании хочет видеть состояние бизнес-функций, а не ИТ-компонентов, причем как в ретроспективе, так и в реальном времени. Отчеты должны быть доступны в одном месте, с понятной «не для технарей» визуализацией, а не в интерфейсах, созданных инженерами для инженеров (вроде дашборда Zabbix или Grafana). Такие отчеты должны быть ежедневными и отражать, что происходило за сутки в зоне ответственности разных исполнителей и какие именно события повлияли на деградацию того или иного сервиса. Раньше такие отчеты были часто субъективными – они были основаны на передаваемых инженерами сводках о значимых событиях. С каждой ответственной, как правило приходилось созваниваться лично и уточнять детали.

6. Куда бежать в первую очередь?

Также была потребность считать SLA с учётом влияния на бизнес. К примеру, в определенный город есть рейс по средам. Недоступность связи с аэропортом в другие дни, а также в день полёта в районе пяти часов до вылета на самом деле никакого влияния на работу не оказывает. Это хотелось бы учитывать при анализе SLA за период. Кроме того, SLA должны помогать инженерам расставить приоритеты в действиях: одно дело, если событие происходит в районе вылета – на это необходимо реагировать 24/7 и срочно, другое дело – если в ближайшее время ИТ функциями никто пользоваться не планирует, и такие события можно брать в работу в порядке очереди. Решить указанные проблемы хотелось инструментом интуитивно понятным, не требующим наличия глубоких технических компетенций в продуктовых командах.

Мы начали внедрять решение, которое закрыло бы все эти задачи, которые не решаются ИТ-мониторингом.

В итоге мы получили следующий набор компонентов мониторинга:

Zabbix и Prometheus для анализа метрик

ELK для анализа логов

Jenkins для управления запуском синтетических проверок, по сути это автотесты, плюс Selenium, как библиотека с помощью которой пишутся на Python эти автотесты

Monq для агрегации всех событий, оркестрации синтетических проверок, зонтичной аналитики и автоматизации процессов

При этом первые два компонента уже были, а вторые два надо было поднять и интегрировать между собой.

Необходимо было решить следующие задачи:

Убедиться, что решение может выступать единым место для агрегации данных по текущим системам мониторинга;

Визуализировать и свести в одну систему результаты выполнения функциональных синтетических тестов, как для web интерфейсов, так и для desktop приложений;

Построить ресурсно-сервисную модель сервисов в рамках всего ИТ;

Настроить автоматизацию по оповещениям и проверить возможности автоматизации на базе скриптов.

Для инсталла платформы и необходимого окружения по функциональному мониторингу нам потребовалось выделить 11 виртуальных машин (4 ушло под monq, 7 для нод Jenkins). Выделение ресурсов было, пожалуй, самым длительным этапом нашего проекта.

Синтетический мониторинг

Как я уже писал выше, в этом проекте нам надо было показать клиенту, что мы можем тестировать web-интерфейсы, desktop приложения и проверять доступность бизнес-функций.

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

Пример проверки авторизации на интранет-портале

Пример проверки доступности табло рейсов

Опишу подробнее логику одного web-теста по шагам:

2. Проходим авторизацию. Вводим необходимые данные, нажимаем на кнопку «Вход»

3. Открываем страницу с информацией по рейсу. Выбираем рейс, кликаем на него, открывается информация по рейсу и проверяем наличие текста «Информация по рейсу»

Цифровое здоровье сервисов

Мы поделили все терминалы на точки присутствия (аэропорты) и их фактическое местоположение внутри здания, чтобы можно было проще ориентироваться визуально и в последствии можно было проще настраивать автоматизацию, в зависимости от локации и важности.

На РСМ видна взаимосвязь элементов и их влияние друг на друга. В случае сбоя в одной КЕ «красным» загорятся связанные с ней

А так можно смотреть на состояние элементов на карте РСМ с их привязкой к состоянию здоровья

Для удобства настроили несколько различных представлений РСМ, для разного уровня сотрудников.

Так на верхнем уровне видно здоровье основных ИТ сервисов компании

Источник